I found it crazy useful to study old, established, mature technologies, like relational databases, storage, low-level networking stack, optimizing compilers, etc. Much more valuable than learning the fad of the year. For example, consider studying internals of Postgresql if you’re using it.

I’m going on 25+ years and at principal eng/architect level. My take would be to find something, try it, and find if it excites you. There isn’t a wrong answer. At worst you’ll become a generalist, fluent with more and more until you find a niche in an array of things you’re conversant in. At best you’ll dive deep into a specific area and become more and more of an expert on a topic.

Right now I’m really into rust, rewriting tons I’ve done in the past with more experience under my belt, and learning more about web assembly. Running rust in web assembly on any platform including the user’s browser without really having to think about distribution targets is something that excites me. I think I can gleam a future that might compete with how revolutionary kubernetes has been, but even if I’m wrong the things I’ve learned will still hold up.

If the huge array of things overwhelms you, find a problem and try to solve it. Just the act of doing that and heading into that rabbit hole can open up new worlds you never even knew existed, and helps strengthen one of what I would consider the best qualities in good devs: competent independent troubleshooting. The fun I’ve had trying my hand at bypassing att router restrictions, extracting certificates from roms, architecting my home network with self hosted kubernetes and all the home automation stuff, low level c embedded systems programming for homemade iot sensors… The things you can do with tech is usually always in reach of anyone with some time and an Internet connection.

Also, don’t neglect the open source community. Start a project, contribute to someone else’s… Probably the biggest leap I took as a dev consisted of a simple change to a large oss project. The mentality, guardrails, rule self imposed on the project we’re incredibly impressive to me and I learned so much about the benefits of code quality, good review, automated, well everything, really opened my eyes to what a small team can do given a common goal they are passionate about, something that at times can be missing from enterprises that might have profit as king.

Let us know what you end up at. You never know if you might inspire another dozen people with something that interests you. Good luck!

Depends on what you already know and have experience with, where you’re looking to go or are interested in.

Work should provide the opportunity and capacity to explore alternatives where they may make sense for work/projects.

There’s three approaches I use here.

1. Find some bit that you bonk your head into regularly. Maybe it’s query optimization. Maybe encryption or auth. Maybe infra setup. You can usually muddle through it by reading the 5th comment on SE or finding a coworker’s working code. But you don’t actually understand how or why it works.

2. Think more broadly of where you want your career to be in 5 years, or what you want your next job to be. Map out what you know and what you need to know to be successful in that role. Study the gaps. Sometimes it’s not technical skills.

3. Pick a project you find interesting that has nothing to do with your current job responsibility. Frontend? IoT? Systems level stuff? Dig in! You will find that unrelated computer stuff is in fact all related in some way.

The least adventurous approach is to work at the edges of what you’re already doing. Are your apis usually consumed by react components but you’ve never written one? Try writing a react app that consumes one of your services and see where the pain happens. Even if you never use react again you’ll have learned something about your work from a new perspective.

Don’t spend too much time on anything that isn’t fun. Chase joy and fail fast.

What is “LOE” short for?