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!

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.

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.

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.

If you can do this while at your job, being paid, that is ideal. It’s good to unplug during time off, it will reduce risks of burnout. This can sometimes be done for small tools, or experimenting for a new project. That said, it’s not always possible to do, especially if you have interests outside of the domain you’re working in.

Regarding which to choose, that’s highly dependent on your interests. Pick something you’re excited about. That excitement will drive much more benefit and growth than slogging through to check a box will. If you’re interested in backend performant code, for example, I would recommend rust. It’s been the most loved language on SO for many years for a reason. If you want to work with robots, learn ROS2. It’s a good baseline framework to learn the subject matter, and will likely mirror architecture for projects using other platforms, as well. Etc., ad nauseam.

I mean I’m being honest I’m a little bit in love with Rust haha, so I can recommend learning that if you haven’t yet, it has teached me the most of how to design nice programs/libs (in an efficient manner) and generally just feels nice to write. And a very relevant side-effect: it seems like it has a rapid growth also on the job-market. I really feel that growth in terms of improving library quality and tooling (rust-analyzer is I think really the best language server by now), not the least seeing ever more often something like this: https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html)

What is 3 years LOE? I’ve tried searching online and the only thing coming up is “Level Of Effort,” which doesn’t seem to fit with the context.

What is “LOE” short for?

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.

I think more info is needed. Are you looking for recent developments adjacent to stuff you already work with? Or something entirely different so you get some variety? Knowing your current experience will help know what’s relevant.

As someone with more than 5LOE I’ve found that technology matters less and general concepts are more valuable.

So look at system design concepts, how infra you use typically works (pubsub, databases, etc), how companies solve problems (engineering blogs from companies like slack, meta etc)

Learning new languages only helps if you are currently working on something obscure.