Connecting the dots: how software engineers actually make money

Most conversations about money in this field get flattened into one question: what does the job pay. That is a real question and worth asking, but treating it as the only question is where people leave a lot on the table. I have moved through three very different setups in about eight years, a local PHP shop in Kathmandu, a remote contract with a company in the US, and now a senior engineering and management role at a company based in Tokyo. Looking back, none of those moves happened because I found a bigger number on a job board. They happened because something I did in one place became leverage somewhere else.

That is the actual shape of it. Not separate income streams sitting side by side, but one skill compounding through different channels, each one making the next a little easier to reach.

The job is still the base case

Whatever else is on this list, the salaried job comes first, and I do not think that is a controversial thing to say even in a post about other ways to make money. It is the steadiest income you will have, and more importantly it is where the actual skill gets built. Nobody pays freelance rates to someone who cannot ship, and nobody buys a side project from someone who has never shipped one either. The job is where you get thousands of hours of feedback on real systems, with someone else absorbing the cost of your mistakes while you are still making them.

The mistake is treating the job as a ceiling instead of a floor. A job title caps how much a single employer will pay for your time. It does not cap what the skill underneath that title is worth once you start pointing it in other directions.

Specialization is the actual lever, not job hopping

The biggest jump in what I could ask for did not come from switching employers more often, it came from getting specific about what I was actually good at. Early on I described myself as a developer who does PHP. That is replaceable in a way that “someone who has fixed production database bottlenecks under load” is not. The second description is a story with a specific outcome attached, and stories with outcomes are what get repeated by other people on your behalf, which is worth more than any single negotiation tactic.

This matters for everything else on this list too. Writing, consulting, building something small on the side, all of it depends on being known for something specific. Nobody hires a generalist consultant, and nobody subscribes to a blog that could be about anything.

Writing is the cheapest way to compound the job you already have

This blog is the clearest example I can point to. It costs nothing to run beyond the hosting bill, and every post is a slightly more permanent version of something I already had to figure out for work anyway: a bug, a migration, a decision between two approaches. The job produces the material, the writing just stops it from disappearing into a closed pull request.

The payoff is not direct. Nobody has paid me to write a blog post. What it does is make the specialization from the previous point visible to people who were not in the room when you fixed the thing. A resume line says you worked with Postgres at scale. A post that walks through exactly what broke and why says the same thing with evidence attached, and evidence travels further than a bullet point.

Side projects only pay off if they are downstream of something you already understand

I am wary of the advice that everyone should be building a product on the side, mostly because most side projects die from lack of a real problem behind them, not lack of code. The side projects that actually go anywhere, from what I have seen watching other engineers as much as from my own attempts, are the ones built on a problem the person already understood deeply from their day job, not a problem picked because it looked good on a landing page.

Put differently, the side project is not a separate bet from the job, it is a bet placed with information the job already gave you for free. That is the connection people miss when they treat “build something on the side” as generic advice, detached from whatever they actually do Monday to Friday.

Open source and community work compound the same way, just slower

I think about open source contribution the same way I think about writing: it is not a direct paycheck, it is a public trail of specific, verifiable work. A pull request against a real project, with a real discussion attached to it, is a harder thing to fake than a resume line. It rarely pays immediately. What it does is put your name next to your actual skill level somewhere a hiring manager or a client can go check for themselves, without having to take your word for it.

None of this works without the boring part first

If I had to compress all of this into one thing, it would be this: get good at the job first, specialize enough that the good part is describable in one sentence, then let that sentence show up in more places than just your paycheck. Freelancing, writing, side projects, and open source are not four separate ways to make money as an engineer. They are four places the same underlying skill can show up once you have actually built it. Skip the first step and the other three have nothing to point back to.