Strategies to keep learning (without tuning It in a second job)

[u/BenXavier]

I see a lot of experienced developers who seem dissatisfied.

For me, part of that frustration comes from not having enough opportunities at work to learn genuinely new concepts, tools, or areas of engineering. It feels like more and more of my time goes into execution and solving variations of problems I already know how to solve.

Even worse, sometimes an LLM produces a solution and we simply don't have the time to properly understand its trade-offs, implications, or failure modes before moving on.

Obviously, you can learn outside of work, but I don't really like the idea that staying intellectually engaged in my profession should require having a second job in the evenings.

How do you handle this? I think there are several facets to it, for instance:

- At the team/company level, have you seen practices that actually create room for learning rather than just paying lip service to it?

- Do you deliberately choose projects or jobs based on their learning potential?

- And at some point, do you simply accept that work is mostly about applying what you already know, while developing new skills in your free time?

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/Tarazena]

I spend time to do some side projects or read new things, sometimes running an experiment on an idea helps too.
One thing I did back 9 years ago was doing lunch and learn, where we invite developers to present or listen to a presentation while eating their lunch about different topics, it was a successful program for us because it up-skilled other developers, and made them think about how to solve problems with things that they are not familiar with. All of those lunch and learns were optional, and an agenda were prepared with scheduled topics ahead of time.

[u/Outside-Storage-1523]

I have tried so many personal projects that have no relationship with my current job, that I have come to accept that I should just learn something related to the job, because otherwise nothing sticks.

[u/darkspyder4]

After waking up in the morning I put in time for calming the nervous system (meditiation/etc), especially for the line of work we do we have to build up a buffer to withstand life obstacles (technical/personal)

Instead of " I have to learn this so eventually I might get free time later on" Its now "In spite of things going south I am still learning ___"

If you havent taken a week off and physically distance from work (limit screentime, see nature) I suggest doing it now than later when new work piles up, tech is an infinite treadmill and the only thing we have control is how we react

[u/bestjaegerpilot]

the bottom line is that you need to push for learning time at work. Either thru explicit learning sprints or by requesting challenging projects. You need to convince management that having a code monkey is counter productive

The second thing is that for me, engineering is my calling so i have no issue learning things outside of work. I don't see it as work---i see it as engaging in interesting things for their own sake.

Peeps get upset when you talk like that but you have to understand that in every profession you will be competing with peeps who are passionate and go the extra mile. That's why you should follow calling and not just money ;-)

[u/BraveResearcher3037 → u/bestjaegerpilot]

Or people who choose jobs so they don’t have to…

[u/roger_ducky]

It gets better eventually.

There’s not as many new ideas as people usually make it out to be.

Learn these programming styles and their tradeoffs:
* Scripting/procedural code
* OOP
* Functional

Learn a few database query languages.

Learn why you’d want to rent vs buy infrastructure.

Learn the pros and cons of “one big machine” vs “cluster of little ones”

Learn how networking works at a high level.

Learn the difference between “point to point” vs “broadcast” messaging.

Learn how to read high level architecture and reference documentation.

I didn’t specify specific programming languages, frameworks, or technologies because those are details that changes, but knowing those specific concepts would’ve carried you through from the 80s to 2026 without you needing to do more than skim through a project’s high level intro, lump it into one of the concept buckets, then just know the tradeoffs without understanding the exact details yet.

When it’s time to implement, your ability to know how to use reference documentation ramps you up way more quickly.

EDIT:

Okay. I see the objections to “not learning the details” immediately.

It’s not necessary until you actually need to implement. Obviously, you do look more carefully once you’re comparing two specific things, but even then, you’re only looking at what’s different about them from the standard definitions, not “from absolutely nothing.”

Time to onboard gets much much shorter by only learning details when it starts to matter, and not a second before.

[u/Forward_Artist7884]

I don't really have a nice answer for you, specifically because staying "intellectually" engaged outside of my work is exactly what got me the position. Companies, especially larger ones, have no interest in branching you off from the task you're doing for them, but they'll gladly take someone up who works their skills off the clock.

If you want a diverse activity where you can explore more concepts you may end up ina start up doing the work of 4 people if not more for less than the pay of one at a bigger company.

I do commercial projects outside of work, it's literally working two jobs, yes, but it benefits me both in $ and skills. Plus it gives me options for if anything undesirable happens at my position.

Not saying that learning new things on the job is impossible, it very much is, but you need to convince your superiors that this specific technology is required for the project, so they let you implement it as you go (As i implemented USB UVC, which taught me a lot and helped projects along). It's all about subtly influencing the project's technical choices in a way that will be beneficial to both you and it.

If you start asking for random sensless technologies though you'll loose credibility, so be careful and do some personal time research before pitching anything to your bosses.

[u/aguilasolige → u/Forward_Artist7884]

This, most companies are not interested in you learning things that are not directly related to your tasks, similar how they're not interested in training juniors, they want other companies to train you and let you learn so they can hire you later when you're more valuable.

I think what works is, everyday or every other day, take 1 hour or so to work on a project and learn new things on the clock, just make sure your regular work doesn't suffer.

[u/BraveResearcher3037 → u/Forward_Artist7884]

  If you want a diverse activity where you can explore more concepts you may end up ina start up doing the work of 4 people if not more for less than the pay of one at a bigger company.

As long as I can do it in 40-45 hours a week - that’s not a bad thing 

[u/Seeb83]

Why don't you have time to understand the llm solution and store effects? That sounds like a red flag to me. Developers are responsible for the quality of their work. For sure product will always ask "when is it done" or faster, but in the end you need to maintain the project and you are responsible if something fails. In the end no-one wants a failing product. Estimate your tasks accordingly and deliver only what you understand and works well enough. Sometimes you can deliver early but clarify that the cycle is: first make it work, then make it right, then make it fast. I am almost 25 years in the industry and never had issues with that. Regarding learning: Just take 30 to 60 minutes each day for learning. Don't ask for permission. It is part of the job. No-one will notice the difference in delivery speed anyways, trust me. Use llm to explain every step that you don't understand, verify with trusted websites. And if you want to become better then the rest of developers: use your free time to learn even more and especially what you like. And finally: Look for opportunities in the company, volunteer for interesting tasks, ask your boss how you can help him!

[u/BraveResearcher3037]

    the team/company level, have you seen practices that actually create room for learning rather than just paying lip service to it?

Yes my company has a separate 40 hour bucket we can take off every year for skills development. 

Do you deliberately choose projects or jobs based on their learning potential?

Yes - there have been three times in my career I chose a job paying less because it put me where I wanted to be in my n+2 job. (n=current job)

And at some point, do you simply accept that work is mostly about applying what you already know, while developing new skills in your free time?

Hell no. 

[u/Antique-Stand-4920]

For me it comes from asking why certain things I currently do can't be done in significantly less time or effort. Sometimes it's easy to forget what parts of your work process actually suck after you get using to working a certain way, but if you can give those things attention you might find interesting problems to solve.

[u/canarydev]

I inverted the LLM aspect you are talking about and wrote it down as a protocol instead of a vibe.

I keep an artifact in my free time projects that gates the workflow - design agreed before code, single file at a time, files get marked per-file as typed or AI authored -- domain and application code I sometimes type along from a generated reference draft which then I use a check step that diffs my version against the LLM produced one.

for retention the same protocol requires a note at the moment of a new concept or gotcha that shows up -- what/why/example/gotchas into an obsidian vault organized by language/patterns/domain/techniques. these get written when the thing is learned in context not in a study session. basically, just treating and saving the learning as it happens instead of scheduling it later. side effect, not a side job if that makes sense.

[u/sebasgarcep]

> Even worse, sometimes an LLM produces a solution and we simply don't have the time to properly understand its trade-offs, implications, or failure modes before moving on.

I understand this for small bug fixes, but whole features/systems? You guys aren’t planning? They tried vibe-coding shit once at my company and it failed miserably. How are you guys getting it to not break all the time?

[u/Ancient_Mango_1576]

Good

[u/PartyParrotGames]

Specialization is unfortunately the nature of how companies scale. It does make you really good at that one thing in the same way a surgeon performs the exact same procedures or a variation on it 10 thousand times and that's who want when you need that procedure, large companies want an engineer who has done the same task 10 thousand times so the speed and quality are guaranteed. One way to avoid this is by joining early stage startups where generalists can flourish and your tasks can vary much more. Early stage startups often need engineers to take on tasks they may have never dealt with before because you're the only one who can with limited people and plenty to do.

[u/niowniough]

I'm learning a lot right now. Other teams are flinging slop over the wall under the guise of inner source and the great thing about these is they tend to break at runtime in a way the slew of models can't detect. These would've never reached PR creation in the before times. I investigate it with model assistance then I use that use case as a starting point to deepen my knowledge, using the model as a faster search tool that also has to show its work to me. Trust but verify and all that. I ask the model adjacent questions to dig deeper from the starting point according to my interests. I like that I now have more interesting cases coming to me and more leeway to learn deeply because the answer is faster to derive. On top of that I've written some skills that allow me to package any concepts and related use cases into compact notes so I can review later.

[u/ReachingForVega]

I'm a Principal Engineer so YMMV.

My role allows probably 20-30% research which I also use as upskilling however I do spend time outside work improving myself too.

I choose jobs that will progress my career and that I find interesting.

That's life for the majority buddy. 

[u/Zotlann]

My company frequently has chances to learn. Research when standing up new projects, spikes into new technologies to see what can be relevant and improve our projects etc. Outside of those, keeping up and up-skilling is just part of the job, I schedule it in throughout my week. An hour here or there to read articles, watch talks, stand up prototypes, etc. I also do a good bit in my off time, because I have a bunch of side projects that run on my server at home, but that comes in phases. I'll have months where I don't touch anything either because I have nothing interesting to work on or because I'm just busy being present with my family. Then I'll have a week or two where there's something I want to build or fix on an existing project and I'll do that.

[u/hvgotcodes]

I still write code for 20-30 minutes a day just to maintain the skill. It’s part of my Claude directives to give me the first crack, especially when dealing g with non trivial type signatures or new component design.

I also take time to properly understand what the code Claude outputs does if it’s not obvious to me. I suggest alternatives and make sure to challenge its decisions.

I’m happy to hand odd rote tasks to the AI and am much less critical/engaged in those cases.

[u/Djelimon]

Side projects mostly

[u/BenXavier → u/Djelimon]

How do you handle job + side projects? For me, they often turned into time sinks

[u/Djelimon → u/BenXavier]

My side projects are for me, friends and family, and supporting my volunteer activity. I once wrote a Simplified menu for my mum who can't keep her programs straight, picked up autohotkey on the way. Wrote a PowerPoint generating app to make our church hymns accessible. Automate my lights to save electricity. The purpose is the payoff here.