# Three years at Metacell: a reflection on software engineering

> What the job actually taught me, and where I think the craft is headed

Author: D. Gopal Krishna
Published: 2026-09-27
Category: software
Tags: #career #software-engineering #reflection
URL: https://www.dgopalkrishna.com/posts/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.