If there’s one thing that’s always true about software development, it’s that it just never sits still. Just when you think you’re on top of things, a new framework comes along and suddenly you feel out-of-date and you’re worried all the cool kids will laugh at you.
But there’s some bits of evergreen advice I can give.
Realize that ‘knowing’ something is on a spectrum with several steps.
- Awareness: “I’ve heard the word before.”
- Familiarity: “I’ve read some stuff about it and know the general idea behind it.”
- Tinkerer: “I’ve tried it out to evaluate it or made something small.”
- Experienced: “I’ve shipped a real product that uses it.”
- Expert: “I know it inside and out and can make it do things the author never intended.”
That’s a lot of steps, and it can be easy to set unrealistic expectations about how many things you can be an expert on.
One thing? You’re doing well.
And you can say you ‘know’ something long before you work your way through all of them and definitely when you’re experienced.
You might imagine that if someone else says they ‘know’ something that they’re an expert, but then you look at your own skillset and think “I still have to check the docs every five minutes and Stack Overflow several times a day”. We all do. That’s okay.
If you squint a bit, new developments follow a metronome pattern.
There’s a tick phase where people have a new problem of some kind. They solve it by adding or replacing a thing in their system’s tech stack. Then there’s a tock phase where people look at that solution and try to do the same thing only better: merge two things together, make it faster, give it a better developer experience, more repeatable, whatever.
It’s okay to ignore the tick phase altogether. When you start a new system, start at the last tock and skip from there to the next tock when it comes along. Usually at that point there’s usually a clear advantage to moving from one tock to the next. You don’t have to stay on the bleeding edge.
But even then make sure it makes sense for you and your customers compared to everything else you could be spending time working on.
It’s rarely necessary to use a tick technology unless it’s a specific competitive advantage for you. You might want to anyway if that’s fun for you, but you don’t have to.
Don’t let ideologues fool you. Building software in the real world is never as neat and tidy as we’d like. Real software always has dust bunnies under the couches.
When you decide to adopt a new technology, you do not have to adopt it 100%. Invest in it where it makes sense to, leave things as-is when there’s no reason to change it.
Are you using fancy new-fangled client-rendered React but there’s some dusty corner of your system where things are plugging along with server-rendered JSP templates? Relax, don’t worry about it.
If you have to come back to that dusty corner, perhaps because it’s producing bugs or because you need to modify it for some new work, then think about updating it then. But if it’s quietly doing its thing? Let it be, focus on more important things.
Never forget that no matter what framework you’re using, how it’s built, or how it’s delivered to your users, the same fundamentals apply. It’s all just code.
Optimize for being able to come back later, understand the code easily, and change it without breaking other stuff.
Do you feel like you can never keep up-to-date with all the new stuff? Being a software developer can feel like you’re always on a treadmill going just a bit too fast. You’re always worried you’re one misstep away from face-planting.
Take a breath. If you’re even reading posts like this one and thinking these thoughts, you’re already doing plenty. Do a good day’s work, leave your code in a better place than it was yesterday, then go home. Spend time with your family and friends, read a book, do some Judo 🥋. Whatever helps give you perspective about how insane our industry can be.
Most importantly, realize that everyone else around you feels insecure about this too. Be kind and helpful to each other as we all muddle through this together.