Stop Calling Yourself a Software Engineer. You’re a Digital Artisan.

You feel it every sprint retro. The backlog is a swamp. The deployment breaks for reasons no one can name. But you still call it ‘engineering’ because that’s what the job title says.

Here’s the truth no one in tech will admit: software development is not engineering. It never was.

Engineering works because bridges obey gravity. Steel bends in predictable ways. Concrete cures on a timetable. Your code? It does whatever the hell the operating system, the network, and the moon phase decide at 3 AM. There are no immutable physical constants in a Rust compiler.

Yet we cling to the label. Why? Because ‘engineer’ sounds serious. It promises deterministic rigor. It makes venture capitalists nod. And it makes you feel legitimate when you estimate a feature will take three days and it takes three weeks.

We forced a civil engineer’s mindset onto a medium that is fundamentally fluid, creative, and alive. The result? Burning sprint ceremonies, imposter syndrome disguised as experience reports, and a whole industry pretending that ‘best practices’ are laws of nature.

I saw this firsthand building a payment system at a fintech startup. The PM wanted a ‘specification document’ that was ‘complete.’ I asked him how many edge cases he wanted covered. He said ‘all of them.’ I laughed. He didn’t. That moment was a microcosm of the entire field: we expect absolute predictability from a system that changes its behavior every time a dependency updates.

Real engineering has empirical constants. Young’s modulus. Thermal conductivity. Software has undefined behavior, race conditions, and a framework maintainer who just rage-deleted a repository on GitHub.

The twist? Thinking like an engineer makes your code worse. It makes you over-plan, under-adapt, and treat refactoring as a failure instead of a feature. The most successful developers I know don’t think in terms of ‘requirements specification.’ They think in terms of material properties of code: malleability, readability, and the ability to evolve under uncertainty.

That’s why the best teams use agile not as a dogma but as a recognition that software is alive. They prototype, they test on real users, they rewrite. They don’t pretend a design document is a blueprint.

You want a better career? Stop apologizing for not being a structural engineer. Start owning that you are a digital artisan. Your craft is heuristic, iterative, and deeply human. The sooner you drop the ‘engineering’ mask, the sooner you’ll build systems that actually work for people, not for a false ideal of precision.

The bridge stands for a century. Your code lives for a sprint, then gets rewritten. And that’s not a failure. That’s the nature of building with bits.

FAQ

Q: Are you saying we should abolish the term 'software engineer'?

A: Not abolish, but stop pretending it describes the work. Use 'software developer' or 'digital artisan' internally to set accurate expectations. Keep the title for HR filters if you must, but don't let it dictate how you think.

Q: What's the practical implication for my team tomorrow?

A: Stop writing specs that pretend you can predict everything. Start coding prototypes and iterating based on what actually happens. Replace 'engineering estimates' with 'exploratory timeboxes.' You'll burn less time and ship more.

Q: But isn't there value in engineering discipline—testing, design patterns, code reviews?

A: Absolutely. But those are craft practices, not laws of physics. Use them as tools, not identities. The moment you treat a design pattern as 'the right way' instead of 'a way that works for now,' you’re back to false engineering thinking.

📎 Source: View Source