Regarding your question, why not find a new job / role? For example, I was curious about VR but knew nothing about it. So I got a VR gaming company to hire me as a freelancer at a much reduced rate for a few weeks. It was a great way to delve into the technical aspects of the space. Alternatively, you could start a hobby project where you go into depth.
1: https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...
My long answer is that the job is - despite the money - quite "blue collar". I guess an effect of it becoming mainstream among other things. A vast majority of programmers' jobs are connecting various types of tubes together and endlesly discussing minor variations of the same basic themes. You will find yourself (re-)implementing CRUD interfaces, auth flows, database models. If you're lucky you'll spend some time messing with your cloud provider of choice's various control panels or may work on massaging some data for the AI guys. That's basically it and you're getting paid for it quite handsomely so I'm not sure we should voice our concerns too loudly, but it can be soul-draining nonetheless.
What works for me is to get a job that's not micromanaged to the death. Some jobs, especially at smaller companies, pose a very interesting challenge. I guess the restricted resources, (usually) passionate leadership and sense of personal achievement makes these types of jobs more fun for me. There are usually no playbooks, no protocols. There might not even be an understanding of "user stories": you'll be the one that'll introduce it. It'll teach you all kinds of interesting things about management, planning, people etc. There can be excitement there that is completely drained out of the larger corporations. It could also be hell, so your mileage may vary.
Examples:
Instead of using a middleware between a web server and an application, write one (of course it was easier when I did it in 1994.)
Instead of using an IDE that magically recompiles Java and brings you to the errors, write the code that monitors the file system and runs javac, etc (2005).
Instead of using a CMS, write one (did it in Perl in the 90s.)
Instead of using a JS framework, write one (I kind of tried but no time for it.)
You'll find something that's relevant today and for your work.
There is no need to go on for too long because this approach is good for learning but bad for productivity. The problems to solve and the plausible solutions get clear pretty soon. The problem, as always, is the time.
Also like going to the gym, it's extremely hard to maintain the required regularity if you aren't enjoying it. The only way I have found to consistently work out is to find a deeply technical sport (BJJ, not that it matters) that I actually care to do well. It's the same with technical subjects; the only ones I'm able to study deeply are the ones I find deeply interesting.
With this in mind, my advice is as follows: approach "deep study" in a playful way, and study topics that interest you without regard for whether or not they are "useful". The utility is never far behind, anyway.
If you feel you don't have access to real problems, go and work for tech support a bit. You'll get them eventually.
What at your job pushes you just beyond your current skill level?
The top answer as I'm writing this says coding is a blue-collar profession, very well, a lot of it is. I don't know if this is current, but we used to call these "line coders", nothing wrong with it, it's honest work.
But coding is also a specialist occupation with many niches. Find one you like, and master it, to the point where you're advancing the state of the art.
Congratulations, you're an expert now. The color of your collar should matter a lot less.
Parts of the code nobody wants to touch. Tasks that seem too big.
Work on those. Attack the hard problems.
And if your work code doesn’t have those hard problems, you probably have a lot of free time, so get a compiler course somewhere or something.
That's it.
If you want anything else from your programming career then you'll need to do it yourself.
I mainly work in React with TypeScript, and most of the devs I know rely heavily on plain objects and arrays, writing a lot of glue code to squeeze these square pegs into all the different shapes holes they need. There is a lot of opportunity to model your state and data flows using whatever programming technique I'm interested in, along with the added challenge of implementing those in a way that other devs will be able to understand. Trying to straddle this line has absolutely made me a better developer.
Some examples: - Forth emphasizes using small, reusable "words" which you then build on top of each other to essentially create a DSL for describing your app / data. - Rust has a great type system which improved my understanding of TypeScript. It also has really sexy monadic data types like Either and Result that you can implement in TS/JS. - Elm is a pure functional language that compiles to HTML CSS and JS. Any amount of time spent with Elm will make a better React dev. - Lua is close to JS but lacks a lot of the niceties. If you want classes or arrays or anything like that, you pretty much have to implement them yourself.
None of my side projects are world changing, but the effect they have had on my day-to-day code is significant. Programming teaches you new modes of thought, and the more you are aware of what goes on in these other parallel worlds, the more fun it becomes to try and tackle problems that are hard in your language / framework, but easier in others.
I also spend a lot of time listening to technical podcasts. I always recommend that JS / TS devs listen to the LambdaCast, which hasn't produced an episode in 3 years, but is still a very valuable resource. I also like the ArrayCast (array programming language nerds talking about array programming).
Three options:
1. Go back to university, get a PhD
2. Go work for a research institute (may require (1))
3. Become a subject matter expert (SME) and focus on one area of the business
> I find myself finishing endless user stories but my technical skills seem stagnant
Well, you already aren't a pragmatic programmer then. You should be constantly learning, constantly looking for new and interesting work (internal or external to your employment). Engaging with your management to get put on the more interesting tasks.
Want an example of a pragmatic SME I knew? He was a EE, wanted to do software. So he bought a couple embedded dev boards and started learning. He brought in a demo to the software manager and said, "I want to be on your team, here's what I can do now." The manager was impressed and they moved him over to that team. He was truly a subject matter expert, and also pragmatic. Funny, no conflict between the two.
A big part of learning is making mistakes and learning from them. As you grow in seniority, mistakes become more expensive in money and or stress. Trying new things on stable products in big companies is hard. So how do we keep learning? How do we get updated? How do we try new stuff to be seniors on it five years from now? Run a side non-commercial project.
Why no commercial? I will get deeper into this soon, but if people are paying for it, downtime, bugs, and instability are not quite acceptable. While learning, you probably have all of those, sometimes multiple of them, at the same time.
My experience has been that research teams allow their members to organize their work however suits them, if that's stories then do stories, if it isn't then no stories needed.
Edit: I should note either of these will probably involve a pay cut.