Three years at Metacell: a reflection on software engineering

Three years in

Three years ago I joined Metacell not fully knowing what "software engineer" would come to mean once I was actually doing the job, instead of studying it. This is a reflection on what changed — in how I write code, how I think about problems, and what I now believe the next few years of this profession look like.

What I thought engineering was, versus what it is

Early on, I measured myself by output: lines shipped, tickets closed, features landed. Over time the job revealed itself to be mostly about judgment — deciding what not to build, reading a system well enough to know where the real risk lives, and communicating a tradeoff clearly enough that someone else can disagree with it intelligently.

Code is the easy part. Knowing which code deserves to exist is the actual skill.

The good

• Ownership compounds. The projects where I was trusted to own a problem end-to-end — not just implement a spec — are the ones I grew the most from, because I had to live with the consequences of my own decisions.
• Working close to real systems teaches things tutorials can't. Production incidents, migrations, and the slow decay of an under-maintained service taught me more about architecture than any course did.
• Good collaborators change your ceiling. The engineers I learned the most from were not the ones with the most polished code, but the ones who asked the sharpest questions in review.

The bad

• Velocity pressure can quietly erode judgment. It is easy to ship the fast version of a decision instead of the correct one, especially under deadline pressure, and not notice the debt until much later.
• Not everything worth doing is visible. Refactoring, deleting dead code, writing the doc nobody asked for — this work rarely gets credit in the moment, but it is often the difference between a codebase that stays healthy and one that doesn't.
• Burnout doesn't announce itself. It shows up as declining curiosity before it shows up as declining output, and by the time output drops, it's already late to intervene.

What I'd tell myself three years ago

Optimize for the reps that teach you something, not the ones that look good on a resume. Ask more questions in code review than you're comfortable asking. And write down why a decision was made, not just what was decided — future-you and future-teammates will thank you.

Where I think this is heading

The mechanical part of engineering — boilerplate, glue code, first-draft implementations — is increasingly something you delegate to a tool rather than type yourself. That doesn't shrink the job; it shifts it further toward the parts that were always the hard parts: defining the right problem, evaluating whether a solution actually holds up, and taking responsibility for systems you didn't write every line of.

Three years from now, I expect the engineers who matter most won't be the ones who type the fastest. They'll be the ones with the best judgment about what's worth building at all.