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!

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.

When learning on my own, I I prefer to learn things that will last decades rather than years or months. Examples: Linux (bash, core utils, containers), CS (algorithms, data structures), compilers, other paradigms (functional, logic, oop), hardware architecture (logic gates, cpu design, assembly), encryption algos, Vim, etc.

Stuff that I think will only last a few years I will learn as needed on the job or at least on the clock.

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.

Learn to talk to people and maintain connections. It is most invaluable skillet that will help you both carreer wise and professionally. The more people you know the better it is for your carreer. Learn to present yourself. Visibility matters very much, so it also good to “sell yourself” sometimes. There is really fine balance between making a sell and just bragging, people don’t like second, but okay with first. Learn to teach other people and help them. Most troubleshooting experience I get now is from helping other people. They have a completely different way of doing code that I am (as a whole) and I am just getting this free xp by helping them and also adding one more trouble to my personal solution cupboard.

As for technology, pick what you like and master it, but also make a peeks at what is currently “in vogue”. For example I really have no depth knowledge in the current frontend space, but I did take a passing looks (and build simple tutorial projects) with react, angular and dart. It didn’t really required a much effort from me, but this helped in the long run to be aware.

What is “LOE” short for?