The Difference Between Development and Engineering | by Ian Johnson | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

The Difference Between Development and Engineering

Ian Johnson

13 min read·<br>Just now

Listen

Share

I once lost an entire afternoon to a bug that wasn’t real.<br>The symptom looked like a race condition: two requests landing in the wrong order, the second one quietly overwriting the first. I read the code, formed a theory, threw in a mutex, ran it locally, watched the test pass. Shipped it. The same bug showed up in production the next day, on a different code path, in a way the mutex couldn’t possibly fix.<br>I had been so confident I was looking at a race that I never tested the theory. I jumped to a conclusion, picked a fix that matched the conclusion, confirmed the conclusion by running the fix, and called it done. That entire afternoon was a four-step ritual with no actual investigation in the middle.<br>That’s the difference. Not engineering. Development.<br>What we call development<br>Most software work in the industry is development, and most of the time we call it engineering. The two are not the same. Development is the practice of moving a system from “doesn’t work” to “works enough to ship.” It’s debugging by intuition, fixing by pattern-matching, writing code that satisfies a Jira ticket, then moving on.<br>It is not bad work. Most teams need it. Most teams only do it. But it has a specific shape.<br>Development is reactive. A ticket comes in, you read the description, you form a guess about what’s wrong, you change some code, you check whether the symptom went away. If it did, you ship. If it didn’t, you guess again. The loop runs on intuition and confirmation bias. The unit of progress is “feature looks right” or “bug appears fixed,” and both are judged by eyeball.<br>Development optimizes for what’s visible: tickets closed, PRs merged, features demoed, business value reported. The work is cosmetic in the literal sense. It is measured by appearance.<br>This isn’t a slight on developers. Pure development is fine for problems that are well-understood and low-stakes. The trouble is what happens when you apply development thinking to problems that aren’t well-understood, and most production software is exactly that.<br>What engineering actually means<br>Engineering applies the scientific method. That’s the whole definition. Anything else is careful development with a better job title.<br>The scientific method has four parts: a hypothesis you can disprove, an experiment that tests the hypothesis, an observation of the result, and an iteration based on what you learned. Every engineering discipline that has ever earned the name (civil, electrical, mechanical, aerospace) runs on this loop. We borrowed the word engineer from those disciplines. We should at least borrow the method.<br>What does this look like in code? Take the bug from the opening. Engineering would have started with “I think two requests are racing, here’s how I’d prove it.” Maybe I add timestamps and log them. Maybe I write a test that puts two requests in flight at the same instant and watches for the failure. Maybe I check whether the symptom can show up without a race, which would falsify my theory immediately. Only after the hypothesis survives an actual experiment do I write the fix.<br>This is slower than the development loop. By a lot, the first few times. It is also the thing that stops you from shipping confident wrong answers.<br>Engineering measures progress in evidence, not in tickets. The closed ticket is a side effect. The thing you actually delivered is a body of small, reproducible facts about how the system behaves: facts the next person on the team can stand on instead of re-discovering.<br>Drawing the two loops side by side makes the difference impossible to miss.<br>Press enter or click to view image in full size

The development loop only asks whether the symptom went away. The engineering loop asks whether the hypothesis survived contact with reality.<br>How the words got tangled<br>For most of my career, “software engineer” and “software developer” have been used interchangeably. Job titles, conference badges, LinkedIn headlines. It doesn’t matter much in conversation, but it has done damage to the discipline. Once two words mean the same thing, the harder of the two stops being a goal anyone aims for.<br>In the early 2000s, the craftsmanship movement tried to push back. The Manifesto for Software Craftsmanship talked about “well-crafted software,” “steadily adding value,” “a community of professionals.” All good things. None of them are engineering. Craftsmanship is about pride and skill. Engineering is about method.<br>A medieval blacksmith was a craftsman. A modern metallurgist is an engineer. The blacksmith makes a better sword by working at it for thirty years. The metallurgist makes a better alloy by running experiments and writing down what happened. Both deserve respect. They are not the...