Some time ago I had this highly paraphrased conversion with Riley:

Riley: “So, I’m trying to decide if I should leave the company or stick it out for a while.

Me: “Really? What’s bugging you?”

Riley: “Well, in frontend world everything changes really fast. I’ve been trying to keep up with it in my spare time, but that’s becoming less and less an option and I fear I’ll fall behind other devs.”

Me: “I see. And how would changing companies make that work?”

Riley: “I would go for a company that’s using this new frontend tech so I can learn it on the job.”

Me: “Got it. So, I’m a backend engineer and know very little of frontend tech. I also know a limited set of backend technologies. I do, however, know a few backend architectures and patterns that I’ve used with tech I knew and with tech I had to learn on the job. I assume frontend has the same thing.”

Riley: “What are you trying to get to?”

Me: “My point is that while, yes, frontend tech moves fast, patterns and architectures not so much. if you focus on learning the architectures and patterns, you might not need to keep track of the new hotness in frontend. Unless, of course, new patterns/architectures emerge but those tend to have a slower pace of creation.”

A few weeks later, Riley had decided to stay at the company because they realized it gave them a lot of opportunities to apply frontend patterns that they only read about, in a real product.

The tech is the easy part

While these days I do most of my development - both professional and hobby - in Go, I’ve used quite a few languages and frameworks. All for backend coding, as I mentioned in the dialogue. I got to apply them all in real products that real users depended on and over time, a set of patterns and architectures started consistently popping up.

And you know what? It wasn’t that hard to apply them to the problems I had to solve. Sure, some were more suitable for one language than the other, but for the most part, the tech itself didn’t matter much. See, when you are trying to solve a real world problem, how to solve it is usually more important than what you will use to solve it.

This wasn’t always true, though. The tech available in the 1980’s was not suitable for solving many of the problems that we have today. It is actually quite humbling to go back and see what could be accomplished back in the day. Here in the 2020’s though, when writing software to solve a problem, the implementation details are important but they are the easy part. Once you know how to solve your problem, you should be able to map it to the dev tools that you have at your hand.

Real is better than new

Riley seemed to understand this and decided to focus on making something real and shipping it. This allowed them to be successful but also to fail and learn a few times. And with that they learned a few patterns themselves.

It might not be as exciting as learning something new every other week. But, it will definitely be what sticks with you on your path towards becoming a good engineer.