The Job Is Knowing When.

Every first call starts the same way: "Can you build this?"

After twenty years the honest answer is almost always yes, and that's the problem with it. Yes is cheap now. A working demo of nearly anything is a weekend away, the tools keep getting better, and plenty of people can get you to a demo. Being able to build the thing stopped being rare a while ago.

So what does two decades actually buy you? A junior developer hears your idea and asks: can I build this? The senior question is longer by three words: should we build this, now, this way? Every expensive mess I've been hired to clean up started as a yes that skipped the second question.

When I wanted my bits back

I know the junior question from the inside. I came up on a 28.8k modem, where a song was an overnight download and a JPEG rendered one scanline at a time. Every byte had a price you could feel. At seventeen I looked at how the internet double-checks everything it sends and resented the overhead. All that bandwidth spent making sure. I wanted those bits back. At one point I searched for a way to convert ECC RAM into regular RAM, because there was a whole chip in there doing nothing except catching errors I had never personally met.

The instinct was right. Why are we paying for this, and can I get it back is most of engineering. I was just aiming it at the wrong overhead. That error-catching chip is the reason the machine never quietly lies to you. The double-checking is the internet working. Twenty years is roughly how long it takes to learn which overhead is waste and which is the only thing holding up the house, and that calibration is what this essay is about. Everything below is one instance of it.

When to learn the business before the schema

At Instant Checkmate I built the attribution system with the marketing team: which ad, which affiliate, which email gets credit for a sale. The code was the easy part. The hard part was the weeks of conversations pinning down what "a conversion" even meant, because marketing, finance, and the affiliates each had a different answer, and the data model had to hold all three without lying to any of them.

Business logic runs deep, and the schema comes last. If the person writing your code doesn't understand how your company makes money, you don't have an engineer. You have a very expensive typist.

When "scalable" and "over-built" part ways

Juniors hear "make it scalable" and reach for machinery. Sharding for a database with four users. Microservices before there's a product. All of it carries a monthly bill and a debugging surface, and most of it exists because it resembles the diagrams in the architecture talks.

The scalable that matters is a handful of cheap seams cut on day one. The web tier keeps no state, so the day traffic shows up you can run ten of them. Files go to object storage. Data goes to the database. Nothing important lives on a machine that can disappear. Cut those seams early and they cost nothing extra: the same code, pointed in a smarter direction. Instant Checkmate grew past a million unique visitors a day on seams like these, cut long before the traffic arrived.

When one codebase becomes two

I was the third developer at Instant Checkmate. Ten years later it was two national brands, three offices, and a call center, and I was writing backend APIs for teams I no longer sat near.

Somewhere in that growth is a moment when a codebase needs to split along team lines, and calling it carries real money on both sides. Split too early and you maintain scaffolding for an org chart that doesn't exist yet. Split too late and every deploy is a negotiation between departments. The code starts leaving hints well before the deadline. The job is having someone around who reads them.

When the law walks into the codebase

Some features carry legal weight. Email at scale answers to CAN-SPAM. Card numbers pull your architecture into PCI scope. A checkout that a screen reader can't finish is an ADA complaint waiting on letterhead. I've shipped under all of those, and I built pipeline software for a genetics lab, where the testing culture was the heaviest I've worked under before or since.

I'm not a lawyer, and I don't play one. The job is flagging which features carry that weight while they're still diagrams, so the conversation with your actual lawyer is short and cheap instead of long and urgent. Retrofitting compliance is how a two-week feature becomes a two-quarter one.

When to build less than you can

RoadsideAttracts is a side project of mine: a worldwide search engine for roadside attractions. I could have generated the whole directory at once, millions of pages live by morning. Search engines have seen that trick, and it reads as spam because it usually is. So the directory grows the way real things grow: page by page, language by language, at the pace people actually browse it. Slower on purpose, and worth more for it.

Anybody can add. Knowing what to leave out, and when adding would quietly cost you, is the restraint that takes longest to learn.

When fast is a sequencing skill

Small builds here go from cocktail napkin to shipped in one to two weeks. The national platforms I helped run went on for years, and something real shipped every week there too. Same rhythm, different size.

The speed comes from sequencing. Which piece gets built first so nothing waits on anything else. Which corner is safe to cut this week because it's cheap to fix next week. Which corner would quietly bill you for a year. Prioritizing is what keeps fast work efficient; get the order wrong and "fast" becomes "twice."

The question to take with you

You don't need to hold any of this in your head. That's what hiring is for.

But here's a cheap test that works on any developer, including me. Bring them your idea and listen for which question comes back."Can we build it?" is enthusiasm, and enthusiasm is nice."Should we, now, this way?" is judgment.

Ability is everywhere. The job is knowing when.