Down the rabbithole

ekov @ pm.me

On doing what you want (and getting there)

I first started programming a bit more than six years ago. I have worked in good teams, bad teams, for good money, for very little money… It’s been said enough times that between nice coworkers, cool product and money (maybe add exciting tech stack), you can choose two (or three if you are lucky), but not all of them.

However, you don’t have to settle on the same aspects forever.

Entry level: learn as much as you can *

When you start working as a junior, you might not be able to choose — you get what you can. So your goal, initially, should be to get to a point where you can choose, as soon as possible. But how? Well, you have to get better at your craft, fast. You can do this in two ways (and please, do both):

  1. Learning on the job. When you’re interviewing, look out for signs of support and opportunities for growth. For me, these include smart and experienced colleagues, using the latest technologies (at least partially), and assigned mentors for junior team members.
  2. Learning off the job. Read books (yes, physical, printed books), watch videos, solve coding challenges, work on pet projects. Play around with programming languages and frameworks that you don’t use at work.

Level up: find what you like and what you’re good at *

After the first 2-3 years, you might start noticing the areas where you generally make a strong contribution. Equally, you will know what you hate.[1] These preferences might change a lot; for now, just start noticing them.

This is also an excellent time to develop your T-shape[2] and mix things up a bit professionally. Transfer to a different team, a new project, or a new company. Changing employers is also more likely to bump your salary up — although at this stage, exposure to a wide array of tech and tools is a bigger investment.

Cash rules everything around me *

Got your exposure? Time for that famed ‘competitive compensation package’. When you’ve been in the trade for 3-4 years at least, you should be making more money than ever before,[3] ask for a raise, get promoted, or find a better-paying job.

Repeat this a few times, and come up with a realistic (read: fair and achievable) number that you desire to reach.[4] This number will help you not to be blinded by the money later, when you have maximised your money-related happiness[5], and other aspects of the job will become more important.

Getting serious: specialize *

Now that you make enough money, aim for roles that require deeper knowledge in your preferred specialisation. This can be anything — I like making websites, so for me it’s usually a senior role within a growth team, with heavy use of SSR/SSG frameworks (such as Next.js and Gatsby), and lots of collaboration with design and marketing. You may like payments more, or building dashboards, who knows… whatever your chosen area is, make sure your next role allows you to dig deeper. Be the person people turn to when they have questions related to your field.

Doing what you want* *

After half a decade in the field, you can start thinking about what you’re really interested in. Is there a company you’ve always wanted to work for? Maybe you want to start consulting? Start your own company? Teach instead of code? Now is the time to start exploring these ideas.

This shouldn’t be about money now. Yes, easy to say with a software engineer salary — what I mean is, it’s not about the money in the sense that we should always choose the higher-paying offer. There is more to work than take-home pay.

If you’ve followed some kind of a career strategy, with some luck, you can switch to something that is closer to your heart. You might have to take a pay cut — however, if you maxed out (or even surpassed) your ‘happiness number’ earlier, this should not be a problem.

*100% satisfaction is, of course, not guaranteed. Even a company you admire can be an unpleasant workplace, have a toxic culture, pay too little, or disappoint you in other ways. But there’s always another opportunity just around the corner. Or the next. Keep looking, and good luck.


  1. But please don’t hate unit testing or typed languages just yet. They take some time to get used to, but trust me, both are invaluable tools that help us write better and more reliable code. ↩︎

  2. The stem of the T is your in-depth knowledge; the horizontal bar represents shallower but usable knowledge about neighbouring fields. If you are a frontend engineer, this means that you should be very good at one major JS framework (such as React), TypeScript etc., and should be able to communicate with backend engineers, understand some backend code; same with designers; maybe read up a bit about SEO, learn another frontend framework etc. ↩︎

  3. Unless you career-changed from investment banking or similar. ↩︎

  4. This should be an amount that allows you to save a significant percentage of your salary, while keeping up a comfortable lifestyle. Beware of lifestyle creep though! ↩︎

  5. I swear I have read a study about this, but can’t find a source for the life of me. The key takeaway is that more money only makes us happier until a threshold is reached. This is different for everyone, but there is an average number out there somewhere. Ages ago in some study it was $70k. This might be outdated, but your number might not be as high as you expect it to be. ↩︎

Previous: React basics: rendering a list of JSX elements