5 interesting career paths you can follow
What now, what next?
You have your first coding job(s) behind you, collected a bit of experience doing the same thing at a different company, or a different thing at the same. You have made those first few wage jumps, won some and lost some, and grown with your challenges, as they say.
The middle of that road can be a bit weird, and there is plenty of danger in the form of stagnation, burnout, boreout, and such waiting for you. This is also the time when everyone stops coaching you. You are no longer a junior, and nobody really cares.
And that is where a lot of people get hung up, in my experience, not just in our profession. Next thing you know, you fall behind, rush to go freelance or start your own company to catch up — and then next thing you know, you are broke because you didn’t think things through.
But there is so much more in the vast field of tech — new things you can try out and benefit from. Fun careers that are so different that their only common trait is that they pay more and require fewer lines of code.
I think we can all agree that QA and TDD range somewhere between buzzword, menial work, and a job that should be paid higher than it actually is.
But there are some great jobs that pay well and are interesting when it comes to the actual work.
Writing one unit test after the other might get boring quickly, but how about being tasked with the creation of a whole testing suite that runs automated end-to-end tests? That is interesting again, takes some planning and tooling, research, and a deep understanding of performance and the underlying code. UI-side tests with Selenium and the like can be fascinating to work with as well.
Speaking of performance: One of my most fun weeks in my first job was when we had to quickly fix a performance issue that nobody had noticed thus far. Things ran fine with a thousand tasks, but at two thousand, the whole system stalled — and we had 600k to run through. I learned so much in that one week (we mainly used dotTrace to find the bottleneck).
It was thoroughly enjoyable, and the impact of a single line of code was massive. There is a niche in there somewhere. We almost hired a professional team because of a tight deadline — only that we could find none. The company was willing to pay top dollar for a specialist, but none were available on short notice.
Now, DevOps is a huge field and some paths will require even more coding rather than less — but there is a fairly sized middle ground where you can drastically improve the lives of your fellow programmers, with relatively simple steps.
I myself find a strong passion for build pipelines, I just love tinkering with them. You set them up once, and every single change that gets committed by anyone will profit from it. You take out one of the biggest sources of programming overhead and deployment errors — let me just scare you with the words “test system running on production config file.”
And let’s be real: Duplicating an existing pipeline or even building a new one requires more thought than lines of code. It takes more time to hunt down passwords or environment variables than it takes to enter them, set them up for the different environments, etc.
Now, if you want to go past that, then setting up the framework for that same build pipeline is a good place to dedicate your efforts — and now, we are talking solid paychecks even if the prior might be entry-level work. And still, that pays well too, and the benefits are easily visible.
I want to make a distinction here because consulting work is suuuuper shitty when you end up on the wrong side of it. When you are one of those mercenaries who get sent into whatever war needs fighting, then you will likely end up hating it.
It’s a soulless world much like direct marketing. You will likely not get the interesting work and run into the same issues that many freelancers face — most general software consultant companies have little in the way of company culture. That all may be your thing, but it ain’t mine, I need me something to believe in, and people I enjoy working with.
Definitely think twice and thrice before you enter the world of consulting work; it could wreck you quick if you aren’t careful.
So, why then, am I myself entering consulting now? Because of a subniche of it that I call specialized for the lack of a better word. I am hired by a real company selling a real product, and in fact, one that I spent a long time maintaining on the other side in my first job.
This means that I get to travel (a bit, not too much, mostly remote), lend some technical expertise as well as personal experiences and practical advice — after all, I did eight years of this stuff. A real team, established processes for onboarding, a huge company around it for that stability in unstable times — a lot of things ring true.
Obviously, this is a rare chance that comes as the result of prior hard work — but similar options open up as soon as you find something to specialize in.
Now, I’m sure we all like to joke that the right people get promoted to the place where they cause the least amount of damage — but hey, good bosses exist. I worked for some, still do, and they can heal the wounds that the bad bosses rip in your heart and mind.
All the good middle managers have one common trait: They remember how it was to write code. These people can be your sword and shield, help you where you need it, and stay out of your hair otherwise. They take the brunt of the overhead, talk to the person who needs talking to, and explain technical holdups to non-technical bosses.
The problems mostly lie with people who honestly have no clue about anything or those who can not let go of their programmer days. You signed up for the suits-and-thin-air lifestyle, now live it and let us foot soldiers do the actual fighting. You blow the horn and make sure that the other generals move in the same direction we do, and together this army can win this.
If you think you have in you what it takes to be the good kind of boss — then by all means, make a dozen people’s lives easier by just existing where another person could cause harm instead. I, for one, won’t envy you the biggest paycheck you could possibly get. Go ahead and drive a car that costs more than a house if you like. I wouldn’t want your job, and if you’re happy in it, then by all means.
This is a role that you grow into more than you apply for it — being the person who constantly wonders which team they belong to, which boss they report to. My first job ended like that, and I loved it. I operated completely out of my contract scope. My boss quit and nobody came after, and the two teams that I belonged to didn’t know what to do with me.
For two years, I was my own boss. Sat in meetings, did whatever work seemed most pressing — and I also overworked myself to the point where I had to quit. But it was good years, fun years, and I doubt I will ever get a position this fun again.
Bouncing from task to task can be great for job and life fulfillment, but also for your paycheck and reducing the actual lines of code that you write. When you get called in to help, when you do some teaching of apprentices and new hires in between, then go and optimize or refactor for a while — you are suddenly as useful as hiring five programmers, all for the price of one.
And it’s a good life, with the right kind of satisfaction and interesting work, if you can balance the infrequency and ensure that you never run out of things to do. Good for the next wage negotiation meeting too.
I hope I could highlight some career paths in this post that offer calmer and more interesting work, fewer lines of code, and oftentimes more money.
In there lies the real job satisfaction and reason for making it to the end of your work life without burning out, throwing your boss off a roof or through some window, and without being the person who holds up hundreds of commuters with a heart attack on the train to work.