That's how I read it too.

I've recently started doing that and it's been a breath of fresh air.

I don't really like the stuff I work with, which is services. I think I've become good at it given the feedback I get from my peers every review cycle, but I really don't like it.

I felt burned out for a long time because of that.

Recently I've simply been doing what I'm interested in, in my spare time. That's learning about embedded systems, something I had an interest in in college but never pursued a career. And for fun, tinkering with old stuff that makes me nostalgic. I spent this last weekend coding in Pascal and messing around with FreeDOS :)

It's hard to do just the fun stuff because that's not what makes good software. It's the unit tests and pull reviews and such that make the software reliable and covering all the niggling edge cases. And that ultimately is what makes a piece of software good.

Not so sure about that. Unit tests and pull reviews are stopgaps so that you don't have to hire 1000x engineers just to get some work done. The true masters of this craft may not need those things

Believe it or not "all the edge cases" can still be perceived by the right mind. It's just that we as an industry have done seemingly everything we can to push those folks out, just look at OP as an example

I've supported ten-digits-per-year (non-SAAS) businesses without unit tests or code reviews and oftentimes deploying straight to production. As the sole SWE for my codebase. Supporting hundreds of remote installations with nothing more than SSH tunnels relayed through an ancient, colocated linux box. And the software was very good, didn't ship with many bugs (and when it did they got fixed real quick), and there were never any catastrophic, non-recoverable issues, nor ever any questions on the integrity of the system or my reporting. We were never seriously hacked (to our knowledge). Crazy times... not sure I would do it again, but.... it can be done.

My first dev job we did most of our work in vim sessions on the development server, and more than once I was asked to hotfix live code running in production. Through the grace of God and an abundance of caution nothing ever seriously blew up as a result of all this madness. (Though, ask my boss about the time he tried to move our MySQL instance onto some very early SSDs) Again, it can be done. I'm sure most of the old hats lying around have tons of stories like this.

If your expectations are not shipping with many bugs and avoiding serious blow ups then yes that's a fine way to do things. And if we're happy relying on a single SWE (what happens if you get hit by the proverbial bus?) then yes that's fine too. And if we never need to scale then SSHing into 100s of boxes is fine too.

Most of my job is replacing stuff like you describe. And it's definitely not fine. Nobody knows how it works because that single SWE is gone. It can't scale with the business and it's a huge drag on productivity because nothing can change without a massive testing effort to ensure it's not broken.

Agreed, but who can you really get mad at? The lone, inevitably overworked SWE that was asked to shoulder the entire burden of the business he worked for? Or management, who most likely denied that SWE the support he wanted?

In my last job I'd advocate tirelessly for unit tests, code reviews, all that. And it was always denied. Ironic given that the other engineers I worked with were MEs, who had notebooks full of processes describing how they were to work so that engineering issues would be caught. But the software? "I don't care how you do it, just ship the feature"

As an aside, I've always found "nobody knows how it worked because XXXXX is gone" to be kind of funny: the code knows, so go read the code. It'll mean everything takes 100x longer but the knowledge is there.

> In my last job I'd advocate tirelessly for unit tests, code reviews, all that. And it was always denied.

My approach to that is to not ask, just write the unit tests anyways, ask a peer to code review without management permission, etc.

We are professionals. Part of that responsibility is to know the best practices for our craft and put them into practice.

We also need to be good at getting the requirements from the technical and non-technical people we work with, and being able to show consistent, incremental progress, and a willingness to quickly change direction when the requirements change.

But we do not need to get input or permission for the process we use to produce those results.

> Agreed, but who can you really get mad at? The lone, inevitably overworked SWE that was asked to shoulder the entire burden of the business he worked for? Or management, who most likely denied that SWE the support he wanted?

There are plenty of SWEs that just don't know any better. I know because I was one of them while writing a lot of software for a business.

I don’t really expect just to do the fun stuff at work, but modern technology seems to progressively burn me out more and more.

I was drawn to software at a time when it seemed like we had control over things. With the advent of the cloud I feel like that control keeps slipping away more and more. Kubernetes is my new nemesis. I seem to be in the minority that perceives it as unnecessarily complex for most tasks. Someone once commented here on HN that the k8s trend made them think people are trying to pretend their code doesn’t run on hardware anymore, and that really resonated with me.

> I seem to be in the minority that perceives it as unnecessarily complex for most tasks.

My boss recently introduced Kubernetes to our software deployment.

The first thing he said, though, is if you don't absolutely need Kubernetes, don't use it. It is extremely complicated and finicky and difficult to deploy correctly, and can bite you in subtle ways.

Then he went on to describe, for our problems, how Kubernetes was absolutely necessary to scale without constant manual intervention and configuration and deployment processes consuming our time.

I appreciated that he had thoroughly thought through the problem before adding more complexity.

That's really cool of him.

I do think there are options to achieve all of that - scale without manual intervention, etc. - without Kubernetes though. At least where I work, if I look at the deployment issues we have, those are all the product of bad decisions and lack of action due to higher priorities. There's no reason why there couldn't be more automation. They're building something new on Kubernetes which looks promising (though I really hope that as an app developer I don't have to think of Kubernetes things, which just irk me), but the current platform would work well too if investment was made into automating the parts that aren't automated.

> I do think there are options to achieve all of that - scale without manual intervention, etc. - without Kubernetes though.

Indeed. Haven't people been doing that since, well, cloud computing?

Counterpoint: Before the late 90s, neither of these things were common at all, yet great software existed.

> covering all the niggling edge cases

You don't have to always cover all the edge cases. If you write software for fun, you can often just bake-in assumptions and neglect a lot of edge cases.

Yeah, this isn't for work, this is meant to reignite your passion via personal programming.