Skip to the content
Software Made Clear
About

Career · 10 nodes

Growing as a developer

The only path here that is not about a system. It runs from shipping work without supervision to being asked what the team should build next, and it ends where the hiring conversation starts.

Is this path right for me?

ASSUMES

That you can already write and ship code someone else depends on.

GIVES YOU

A concrete account of what each step up actually asks of you, instead of a list of adjectives.

LEADS TO

Architecture, where the decisions this path teaches you to influence are the ones being made.

Nothing is tracked and nothing is locked — the map exists so you can see where an article sits.

Suggested start Written Not written yet Optional or subtopic

  1. NODE 01 · REQUIRED Suggested start

    Shipping without supervision

    See what actually earns you the right to ship without someone checking first, and how to keep that trust once nobody is looking over your shoulder.

    • Small, reversible changes
    • Saying when you are stuck

  2. NODE 02 · REQUIRED Written

    Writing it down before you build it

    See why most design docs go unread, and how to write one that gets real comments before the build starts, instead of complaints after it ships.

    • The design doc that gets read
    • Who has to agree

  3. NODE 03 · REQUIRED Not written yet

    Owning a feature end to end

    • The part after the merge
    • Who you have to tell

  4. NODE 04 · REQUIRED Written

    Reviewing without starting a fight

    See how to leave review comments that get taken well, and which battles are worth blocking a merge over, rather than quietly letting them go.

    • Comment as question
    • What not to block on

  5. NODE 05 · REQUIRED Written

    Estimates you can defend

    See where estimates actually go wrong and why the error compounds across tasks, so you can give a number you are able to stand behind later.

    • Where the error comes from
    • Compounding across tasks

  6. NODE 06 · REQUIRED Written

    Influencing a design you do not own

    See how to push back on a design you do not own without losing the argument or the relationship, by writing your case down first, in detail.

    • Disagreeing upward
    • Writing it down first

  7. NODE 07 · REQUIRED Written

    Making the case to the people who fund it

    See how to make technical debt make sense to the people who fund the work, by trading it for scope instead of arguing over code quality itself.

    • Debt in their language
    • Trading scope, not quality

  8. NODE 08 · REQUIRED Written

    What changes between mid and senior

    See what a step up in seniority really asks for, why it is not more code, and how to tell whether you are already doing it in your current job.

    • The decision moves earlier
    • Judgement over throughput

  9. NODE 09 · OPTIONAL Written

    Senior, staff, and the ladder above

    See what actually separates a senior engineer from a staff one, and whether that title is worth chasing before your day-to-day scope changes.

    • Scope versus depth
    • When the title stops helping

  10. NODE 10 · OPTIONAL Written

    Getting the title to match the work

    See what actually belongs in a promotion packet, and how to gather the evidence for it before the case has to be built entirely from memory.

    • The promotion packet
    • The interview, from the other side