I don't think it's cumbersome. After doing stuff long enough you get to the point when you realize you can't know everything, you are not perfect, and more importantly, NO ONE IS.

Also if you go back and read the software engineering conferences proceedings from 1968 and 1969, David Parnas' classic 1970s papers, and other instances of this foundational material, you realise that except that we have faster computers, higher-level languages, and version control, software engineering really hasn't changed since then.

We're still struggling with team organisation, verifying features with users before building them, choosing proper abstractions, testing for reliability and understanding, resource management, documentation, modeling the domain clearly, prototyping the right way, and so on.

All the actually difficult things today are just the same as they were 40--50 years ago.

While on the surface things look like they move quickly, what makes one a good software engineer is the same as it's always been.

Good software engineering is not about today's favourite technology. It's about building things that work and which people actually need. That is a hard-earned skill and you don't get it by chasing shiny things.

It's horrible and I wish I'd kept programming as a hobby. The continual 'evolution' is ridiculous, as we build and rebuild the same things with newer tools. Often project management is more important than building things and build tools became an obsession as more layers started to come between writing code and seeing results. Agile, TDD, Testing, Design Patterns are all topics that muddied the waters. And with people on both sides of the fence with these practices, it gets very tiring and you just want to find refuge outside of it all. A place where the tools don't change each year and a half, or where the best practices can easily be agreed upon.

Yes, it gets old and I can't wait to retire.

I’ve been a coder for over two decades, and here’s my take on this. First, good employers want smart engineers, and bet that they can learn things quickly. You don’t need to have N years of experience with Kubernetes. Second, most of your jobs later in your career will either come through your network, or will decide on you based on references from your network. Your network is the most import thing. Third, I’ve seen “new hot technologies” come and go without me ever learning them. Many are fads, you don’t need to learn them all, or even most of them. BUT, you do need to continuously learn, and ideally be able to display that in some way.

1. Learn something, be really good at it. Have demonstrable experience in that thing.

2. Learn a handful of things a little bit less well. Diversify your learnings. Some database stuff, some devops stuff, maybe some game stuff, network stuff, whatever. Try to have demonstrable experience in this stuff well.

3. In 3-5 years, repeat step 1 and 2.

Do this over and over and you'll be competitive in tech indefinitely. It doesn't really matter what you pick to be good at or care about, something current (but not bleeding edge), and then dabble in a bunch of other current technologies and tools.

In general, don't worry about things like project management. Every company bastardizes any written practice, and every company is very different. Just do what your employer does, and then if you find a new employer, do what they do. Maybe have some opinions and reflect on what you liked and didn't like, because employers might pretend to care what you think about processes and improvements, but it's really all just buzzword nonsense. Regardless of what you pretend, it's all going to go how it's going to go.

r.e. "metas" - Play around with stuff. Spend some time reading about TDD, maybe give it a shot every now and then. Understand why it's good and understand why it's bad. Stay away from "never"s and "always"s.

As I write this, I realize you're already doing half of what I'm suggesting, which is just to pay attention to the industry and the comings and goings of tech/tools. The other half is to learn and get interested in various pieces of tech. If it feels "cumbersome", it might just not be the right career path for you. That's totally okay - the work you're doing now is totally fine! Do what you like. Don't force stuff you don't like. Most of the successful programmers I know think that toying with a new language or tool is fun/interesting. It doesn't feel cumbersome because it's both a job and a hobby.

> In general, don't worry about things like project management.

I agree with most of what you say but this sounds like terrible advice. Fixing bugs in software is cheaper the earlier they are fixed. Cheaper in testing than in prod, cheaper in design than in testing, and so on.

The cheapest place to fix them are in the processes that lead to the design.

Fixing things in the project management process is a hugely levered activity.

> Fixing things in the project management process is a hugely levered activity.

Respectfully, you're absolutely right, but at many many employers dev's opinions on project management doesn't matter and is totally ignored. That's why I say don't worry about it. The devs I've been around that get upset and dogmatic about project management principles just get burnt out faster because employers don't care/won't change. "Don't care" didn't mean "Don't know about", but moreso "Don't get worked up about" or "Don't be strongly opinionated". Of all the hills that exist in software to die on, project management is pretty much the worst one.