Stop Coding. Start Engineering.

Jun 3, 2026 min read
Stop Coding. Start Engineering.

There’s a pattern I’ve noticed in our industry, and I’ll be honest — I lived it for years.

We are obsessed with the “how.”

Which framework is faster? What’s the trendiest language? How do I shave 10ms off this function? These are the questions that fill our Slack channels, dominate our conference talks, and keep us up at night. They’re seductive questions, because they feel productive. You’re building things.

But we rarely stop to ask the most important question: Why?

I was wrong for a long time. My mentors kept dragging me into business meetings and I resented every minute. I just wanted to build. Eventually, though, I understood something that completely changed my approach to software:

Code is the tool. The business is the problem we’re solving.

If a feature doesn’t serve a genuine business need, it’s just technical debt waiting to happen. It’s a beautiful answer to a question nobody asked.

The Two Worlds You’ll Work In

Before anything else, it helps to understand the terrain. Every project you encounter in your career will fall into one of two categories.

🌱 Green Field Projects

A green field project is one you build from scratch. No legacy codebase to wrestle with. No existing architecture to work around. A blank canvas.

This is where the software engineer’s role expands dramatically. You’re not just implementing; you’re designing the foundation that everything else will be built upon. The decisions you make here — about architecture, data models, team structure, and technology choices — will echo through the system for years.

The Software Engineer’s core responsibilities here:

DimensionWhat It Means in Practice
CodingWriting maintainable, well-structured code that other humans can work with
System AnalysisUnderstanding the domain deeply enough to model it accurately
Problem-solvingTranslating ambiguous business requirements into concrete technical decisions
Cross-team collaborationWorking with product, design, and business stakeholders — not just other engineers

And the roles you’ll find yourself wearing:

  • Developer — writing the actual code
  • System Analyst — mapping requirements to architecture
  • Software Architect — designing the big-picture structure that scales

🏗️ Brown Field Projects

A brown field project already exists. Someone else started it. There’s history, decisions with context you weren’t around for, technical debt accumulated over years, and a team who has their own mental model of how it all works.

This is where understanding before building becomes absolutely critical. Charging in and rewriting things because they look wrong to you — without understanding why they were built that way — is how you break production and lose the trust of your team.

The Brown Field Playbook: From Discovery to Delivery

Working on an existing system is a process of earned understanding. Here’s the approach I’ve come to rely on.

1. Data Collection

You cannot model what you don’t understand. Before you open your IDE, you need to gather context — from the people who know the system best.

  • Stakeholder interviews — Talk to the people who actually use the system, make decisions based on it, or own the business processes it supports. Ask open-ended questions. Listen more than you talk.
  • Surveys — When you can’t interview everyone, surveys help you collect structured feedback at scale.
  • Document review — Dig through existing docs, architecture decision records, old tickets, wikis. The answers to a lot of your questions are already written down somewhere.

2. Needs Analysis

Not all needs are created equal. Once you’ve gathered your raw material, the work is to identify, clarify, and prioritize. What are the actual user needs? What are the business constraints? Where do they conflict?

This is where you separate the “it would be nice if…” from the “the system cannot function without…”

3. Modeling

This is the step most developers skip entirely, and it’s where the most value lives. Translating your understanding into formal models — visual representations of how the system works — forces you to confront gaps in your knowledge before they become bugs in production.

More on the two key modeling approaches below.

4. Test and Feedback

Your models are hypotheses. Put them in front of stakeholders and find out where your understanding diverges from theirs. Revise. Repeat. The goal is a shared, accurate mental model before a single line of code is written.

BPMN: Speaking a Language Everyone Understands

I’ll be honest about something. A few weeks ago, I was deep in a side project — an abstract product store, something I was building just to experiment — and I decided, for the first time in my career, to not open my IDE first. Instead, I opened Bizagi Modeler and started mapping the business processes before writing a single line of code.

It felt slow. It felt unnecessary. And then, somewhere around the third revision of my checkout flow diagram, I caught a fundamental flaw in my own mental model of how orders and inventory were supposed to interact. A flaw that would have cost me days of refactoring if I’d discovered it in code.

That was the moment it clicked.

Business Process Model and Notation (BPMN) is the standard for modeling and documenting business processes. And I want to emphasize something: it’s not just a tool for business analysts. It’s a communication layer between technical and non-technical people.

When you draw a BPMN diagram, a product manager can read it. A stakeholder can point at it and say “no, that’s not how the approval process actually works.” A developer joining six months later can understand the business context of the code they’re maintaining.

Why this matters:

  • Non-technical stakeholders can validate your understanding directly — without needing a translator
  • Teams coordinate better when they share a common visual language
  • Processes become measurable, which means they become improvable

The BPMN Process

Identify the Processes → Use Symbols → Draw Diagram → Review & Approval

It sounds simple, but each step requires real discipline. Identifying the right level of granularity for your processes is an art. Using BPMN symbols correctly ensures your diagrams are readable by anyone trained in the standard. And the review step is non-negotiable — a diagram that hasn’t been validated with stakeholders is just a guess with good formatting.

Here’s an example of a diagram I built for the product store’s order flow in Bizagi. Notice how every lane, event, and gateway tells a story that a business person can follow without any technical background:

BPMN diagram of a product store order flow built in Bizagi Modeler Order flow for an abstract product store — modeled in Bizagi Modeler before a single line of code was written.

Recommended tools:

  1. Visio — Microsoft’s classic, well-integrated with Office environments
  2. Lucidchart — Great for collaborative, browser-based diagramming
  3. Bizagi Modeler — Purpose-built for BPMN, free for individuals, and the tool I’ve been living in lately

🎓 Free Courses to Get Started with Bizagi & BPMN

If you want to go deeper, here are the best free resources I’ve found:

ERD: Mapping the DNA of Your Business

After I finished the BPMN for the product store, I moved to the next step: what are the actual things in this system, and how do they relate to each other?

This is where I opened Visual Paradigm and started building an Entity Relationship Diagram.

I’ve used plenty of database design tools over the years. But there’s something different about Visual Paradigm — it treats the ERD as a first-class engineering artifact, not just a quick schema sketch before you go write SQL. You define entities with precision. You establish relationships with cardinality. You think about the data model the way an architect thinks about load-bearing walls — because get it wrong here, and everything built on top of it will be crooked.

The ERD for the product store looked deceptively simple at first. Products, categories, orders, customers. But as I started mapping the relationships, questions surfaced that I’d completely glossed over when I was thinking in code: Can a product belong to multiple categories? What happens to an order line item if a product gets deleted? Is a “discount” a property of a product, or an entity in its own right?

These aren’t coding questions. They’re business questions. And an ERD is the tool that forces you to answer them before they become production bugs.

Where BPMN shows you how things flow, an ERD shows you what things are and how they relate to each other. In database terms, this is your schema design. But in business terms, it’s a map of your domain’s DNA.

The real power of ERD in engineering:

  • It forces you to design software around the business model, not the other way around
  • It ensures your data structure aligns with business goals from the start
  • It makes the implicit explicit — every relationship, every constraint, every cardinality choice is a business decision made visible

Here’s the ERD I built for the same product store in Visual Paradigm — the same system, now seen through a completely different lens:

ERD of a product store built in Visual Paradigm Entity Relationship Diagram for the abstract product store — designed in Visual Paradigm. Every line is a business decision.

The best tool for this, without question: Visual Paradigm. It’s the closest thing I’ve found to a single source of truth for a system’s data model, and it has become a permanent part of how I start any new project.

🎓 Free Courses to Get Started with Visual Paradigm & ERD

The Mindset Shift

Here’s what I want to leave you with.

The best engineers I know don’t just write good code. They have a genuine curiosity about the domain they’re working in. They ask questions in business meetings instead of checking their phones. They build models before they build features. They see their job not as translating requirements into syntax, but as solving business problems with software.

That’s the difference between a coder and an engineer.

Spending these past few weeks in Bizagi and Visual Paradigm — away from my IDE, away from Stack Overflow, away from the comfort zone of syntax — was genuinely uncomfortable at first. But I came out the other side with a product store design that I’m actually confident in. Not just technically, but structurally. The business logic is sound. The data model reflects reality. The processes are documented in a language my whole team can read.

The technical skills — the frameworks, the languages, the algorithms — those are learnable. The hard part is cultivating the patience and discipline to understand the problem deeply before you start solving it.

When you start a new feature, ask yourself:

  • What business need does this actually serve?
  • What happens in the business process before and after this feature is used?
  • How does this relate to other entities and data in our system?
  • What would a non-technical stakeholder say if they saw a diagram of what I’m about to build?

Spend time on those questions. Model the business logic. Draw the BPMN. Sketch the ERD. Then open your IDE.

The code will be better for it. I promise.

I’m currently writing a deeper technical series on business process modeling with Bizagi and Visual Paradigm — practical walkthroughs, real examples, the whole thing. If this resonated with you, stay tuned.

And I’m curious: when you’re building something new, how much time do you spend modeling before you write the first line of code? I’d genuinely love to hear how other engineers approach this.