What 5+ years actually taught me.
Less "10x developer" hustle, more honest reflection. This category is where I write about engineering as a craft and a career — what worked, what didn't, what nobody told me when I started, and what I'd tell a junior engineer today. It's the genre of post that's easy to write badly (performative hustle), easy to skip entirely (because it's less technically substantive than other writing), and hardest to do well — but when it works, it's some of the most useful content a senior engineer can publish.
The posts here are written from the position of someone who's shipped 70+ products over five years, mostly working closely with founders, occasionally on larger teams, almost always with constraints that didn't allow for ideal engineering. The lessons are filtered through that lens. They'd apply differently if I'd spent those years at FAANG, or in a regulated industry, or building developer tools. The audience that gets the most from these posts is the engineer with a similar shape of career — early- to mid-stage products, small teams, real-world constraints — but the patterns generalise more than they don't.
Why this category exists
Most career content for engineers online is one of three things. First: the algorithm grind / interview-prep genre, which is useful for a specific phase of career but skews the whole conversation toward "how do I get hired at FAANG" instead of "how do I have a satisfying career." Second: the founder/influencer genre, where someone with a specific atypical path writes generic advice that doesn't apply to most engineers' actual situation. Third: the inspirational platitudes, which are pleasant to read and entirely useless.
This category aims for the fourth thing. Specific reflections on engineering practice and career — from someone with a particular kind of experience, with the limitations of that experience acknowledged. Not "do this and you'll be successful." More "this is what I learned, here's what was specific to my situation, here's what might generalise." The honest framing is the point.
The posts are also explicitly written from the perspective of a working engineer, not a manager or executive. The career advice that gets the most airtime online is usually from people who left engineering and are now writing about it from the outside. There's nothing wrong with that, but it leaves a gap for advice from people who are still in the trenches and writing about what works at the IC level.
What you'll find here
The posts in this category cover five broad areas: engineering practice and habits, technology selection and learning, working with founders and small teams, code review and engineering culture, and career arc — switching jobs, growing into senior roles, the unglamorous parts of compensation.
- Engineering practice — the habits that have served me across many projects, the specific patterns I avoid, the meta-skills (debugging, code reading, working with ambiguity) that matter most
- Picking what to learn — how I evaluate new technologies, why I ignore most hype cycles, and the small set of skills that have paid off disproportionately
- Working with founders — the dynamics that work, the failure modes, what changes when you're employee #1 vs. employee #10, and the trust patterns that matter
- Code review and culture — what makes a code review actually useful, the dynamics that kill team velocity, the small habits that compound over years
- Career arc — switching jobs, evaluating offers, growing into senior roles, the salary negotiation realities, and the long-term thinking that's hard to hold when you're heads-down on shipping
The technology learning meta-skill
The most important career skill I've developed is not a specific stack — it's the ability to evaluate new technologies quickly and decide which ones deserve serious attention. The signal-to-noise ratio in technology choices is brutal. There are dozens of new frameworks every year. Most of them won't matter in five. A few will become indispensable. The cost of learning the wrong thing is enormous; the cost of missing the right one is bigger.
The heuristic that's served me best: ignore the first 12 months of a new technology's hype cycle, evaluate seriously at the 18-24 month mark, decide based on whether real production projects (not demos) are succeeding with it. By the 18-month mark, the early adopters have surfaced the rough edges, the community has settled into recognisable patterns, and you can read post-mortems from teams that picked it for real work. Before that, all the available content is hype-shaped.
The technologies I learned early and the technologies I deliberately ignored both shaped my career in non-obvious ways. Learning React in 2016, Next.js in 2019, and React Native in 2020 each paid off enormously. Ignoring blockchain entirely from 2017–2022 saved a significant amount of time and energy. Posts here cover the specific framework I use to make these calls, with the heuristics I trust and the ones I've abandoned.
The corollary skill: deciding when to abandon a technology. I've held onto stacks past their usefulness because of sunk-cost bias. I've abandoned stacks too early because of impatience with rough edges. Both are common failure modes. The posts here cover the signals I now watch for in each direction.
Working with founders: the specific dynamics
Most of my career has been working closely with founders — small teams, fast iteration, the engineering work intertwined with the product and business decisions. This shape of work has its own dynamics that aren't covered well in standard career content. The lessons I've learned about it are some of the most-asked-for posts I've drafted but not yet published.
The most important pattern: founders move fast and you have to be able to either match the pace or push back constructively when the pace is wrong. The engineers who thrive in founder-led environments are the ones who can confidently say "what you're asking for is going to take three weeks, here's why, and here's a one-week version that gets 80% of the value." The engineers who struggle are usually the ones who either say yes to everything (and burn out) or say no to everything (and get pushed aside).
Trust is the load-bearing element. Founders are taking enormous risks on every decision; they're looking for engineers they can trust to execute without micromanagement. Building that trust requires consistently shipping things that work, communicating proactively when things go wrong, and being honest about what's possible. None of this is unique to founder dynamics — it's just engineering professionalism — but the stakes are higher and the feedback is faster.
The compensation conversation in founder dynamics is its own topic. Equity, salary tradeoffs, and the realistic odds of outcomes vary enormously. Posts here cover the frameworks I now use for evaluating these tradeoffs and the conversations I wish I'd had with my younger self about them.
Code review: the small habits that compound
Code review is the highest-leverage engineering practice for teams that are bigger than one person. It's also the practice most teams get wrong, in ways that are subtle and cumulative. A code review culture that's mildly off — slightly too nitpicky, slightly too lax, slightly too slow — can quietly kill a team's velocity over months without anyone noticing it as the cause.
The patterns that work: reviews focused on substantive concerns (correctness, design, edge cases) and not on style (which should be automated). Reviews that come back within 24 hours, not 72. Reviews that explicitly flag the comments as either "blocker" or "nit" so the author knows what's worth addressing. Reviews that include praise for the parts that were done well, not just critiques of the parts that need work.
The patterns that destroy velocity: reviews that take weeks. Reviews that nitpick formatting on every PR (even with prettier set up). Reviews that change the requested behaviour halfway through the review cycle. Reviews where the reviewer doesn't actually understand what the change is doing and just leaves vague comments. Each of these compound — a team where reviews are mildly broken in any of these ways will be measurably slower than a team where they're not.
The post on "what makes code review actually useful" is one of the most-requested in this category. The framing that's worked across multiple teams: code review is a teaching and learning practice as much as a quality practice. The goal isn't just to catch bugs — it's to spread knowledge of the codebase, transmit engineering judgement, and onboard new team members. Once you frame reviews this way, the right behaviours follow.
The salary and career-arc conversation
The salary and career arc topic is where engineering career content online is weakest. The advice that's available is either vague ("know your worth!") or hyper-specific to FAANG-style total comp packages that don't apply to most engineers. Most engineers are working at companies where salaries are simpler but the negotiation dynamics are the same.
The most useful framing I've learned: salaries are set by the market, not by your skills. Your skills determine which market you're in, but within a market, the salary range is pretty narrow. The lever isn't "get better skills" (necessary but not sufficient) — it's "be in a higher-paying market." That means changing job, often. The single biggest career-comp move for most engineers is the next job change.
The negotiation patterns that work are unsexy: get multiple offers in parallel, have a clear walk-away number going in, communicate calmly, never accept the first number. The mistakes I see repeated: accepting the first offer without negotiation, not understanding that the offered number is usually 15-30% below the maximum the company would pay, not factoring in the total comp picture (equity, sign-on, benefits) which is often where the actual movement is.
The career arc question is harder. Whether to specialise vs. generalise. Whether to stay at one company and grow or move every 2-3 years. Whether to chase title or compensation. The honest answer is "it depends on your specific situation" — but the framework for thinking about it generalises. Posts here cover the framework with the tradeoffs explicit.
The meta-skills that compound
The skills that show up on resumes are stack names. The skills that actually distinguish senior engineers are the ones that don't fit on a resume: debugging mystery production issues, reading unfamiliar codebases quickly, working productively under ambiguity, asking the right clarifying questions in product discussions. These compound over years and outlast specific technologies.
Debugging is the highest-leverage meta-skill. Most engineers stop developing it after a few years because they get good enough at it to not feel the pain. The engineers who keep improving — who learn to read flame graphs, trace distributed transactions, debug across language boundaries — become disproportionately valuable. Posts here cover the specific debugging frameworks I've adopted and the resources that helped most.
Code reading is the underrated cousin. Most senior engineers can read code at maybe 3-5x the speed of a junior, but the skill is rarely taught explicitly. The patterns: read entry points first, follow only the relevant call paths, build a mental model of the data shapes before diving into logic. Posts here include the explicit workflow I use when joining an unfamiliar codebase.
Common regrets and lessons
The things I'd tell my younger self, if I could:
- Write more publicly, earlier — the posts I waited too long to publish are the ones that would have compounded the most
- Ship faster, optimise less — the early optimisations rarely paid off and the time would have been better spent shipping more features
- Take career bets earlier — the riskiest job changes were the highest-return; waiting for "the perfect opportunity" cost real time
- Spend more time on the meta-skills — debugging, reading codebases, working under ambiguity all matter more than any specific framework
- Build relationships proactively — the engineers who maintain a network of trusted colleagues have dramatically more options than those who don't
- Read the postmortems — the public engineering postmortems from larger companies are some of the highest-density learning available, and most engineers don't read them
- Accept that production is messy — there's no perfect system, only systems that fail in known ways; the goal is to fail predictably and recover quickly
What's coming next in this category
The next few posts on the docket: the deep version of "how I evaluate new technologies" with the specific framework, a piece on working with founders that covers the dynamics most career advice misses, the code review post that's been in drafts for too long, a long-overdue write-up of the job-change framework and the salary negotiation realities I wish I'd known earlier, and a piece on the meta-skills (debugging, code reading, working under ambiguity) that compound over years.
If there's a specific career or engineering-practice topic you'd like me to write about, the contact form on the homepage works. The posts that resonate most are usually the ones that came from a specific reader question.