Kyle Simpson recently shared something that caught my attention: "If you don't like coding, and/or want to avoid writing code, you're not a coder." He immediately followed that with a tone many people miss in these debates: you might be "something different, and maybe better, and certainly more efficient" and that is "cool." That combination of clarity plus respect is worth expanding into a fuller conversation.

I want to respond to Kyle in the spirit he intended: not to police who belongs, but to stop flattening two very different kinds of work into one label just because the outcomes can look similar from a distance.

The uncomfortable point: words should mean something

Kyle is pushing on a linguistic problem as much as a technical one. When we call everything "coding" or everyone a "coder," we lose the ability to talk precisely about:

The skills being applied
The risks being managed
The kinds of decisions being made
The craft a person is investing in

That loss of precision shows up in hiring, career development, team collaboration, and even self-expectations.

"I just dunno why we have to pretend/insist that those wildly different approaches are the same 'work' just because they might create outcomes that on the surface seem similar?"

I agree with the premise: building an outcome and writing code are related, but not identical activities.

Two camps, two joys: building faster vs writing deliberately

Kyle describes himself as someone who likes "code writing, too much" and enjoys doing it "slowly and deliberately" with "obsessively precise" communication. That is a real craft mindset: the joy is in the expression, the correctness, the clarity, and the elegance of the solution.

At the same time, he celebrates the other camp: makers, builders, directors, orchestrators. People who may prefer no-code, low-code, scaffolds, templates, or AI-assisted workflows because they want to ship outcomes fast.

"Your way will easily produce 10x (maybe 50x) what I can produce."

There is no insult embedded in that. It is an acknowledgement that abstraction and automation can multiply output. The tension starts when output volume becomes the only metric anyone cares about.

The hidden trade: where did the complexity go?

A useful way to frame this is not "code" vs "no-code" but "where does the complexity live?"

In hand-written code, complexity is explicit. You see it, you name it, you test it, you version it.
In no-code or highly abstracted tools, complexity is often hidden inside the platform. That can be a huge win, until you hit an edge case where the platform's assumptions do not match your needs.

Neither approach is morally superior. They simply optimize for different constraints.

Why calling everything "coding" creates real problems

Kyle is anticipating the classic response: "gatekeeping." The risk is real. Labels can be used to exclude people unfairly.

But there is also a different risk: erasing distinctions that matter. When we collapse roles, we also collapse:

1) Accountability boundaries

If someone is "coding" in the sense of writing and maintaining software in production, they are accountable for things like:

Performance characteristics
Security posture
Data integrity and migrations
Dependency management
Incident response and debugging

A no-code builder can be accountable too, but often within a different boundary: platform constraints, configuration correctness, workflow design, and stakeholder alignment. Calling both "coding" can confuse expectations about who owns what when things break.

2) Skill development paths

If a person wants to become a stronger programmer, they need deliberate practice in reading and writing code, debugging, testing, and reasoning about systems. If we tell them that assembling tools is the same as programming, we may accidentally short-circuit the learning path they actually want.

Conversely, if a person wants to become a stronger product builder or automation designer, they need practice in process design, UX judgment, constraints mapping, and business prioritization. Forcing them into "coder" identity might undervalue their real strengths.

3) Team communication

On teams, vague labels lead to vague handoffs:

"The coder will handle it" can mean anything from writing a secure API to connecting two SaaS tools.
"We already coded it" might mean "we configured it" which changes how you think about testing and maintainability.

Language is a coordination tool. Precision helps teams move faster with fewer surprises.

A healthier framing: different crafts, shared respect

What I appreciate most about Kyle's post is that it is not a takedown. It is a request for mutual respect.

"It should be totally OK to celebrate both camps."

So what does celebrating both camps look like in practice?

Use role names that match the work

Instead of fighting over "real developer" labels, consider using clearer role language:

Software engineer / programmer: writes and maintains code as the primary medium
No-code builder / automation designer: assembles systems using platforms, integrations, and configuration
Product engineer / app developer: blends both, choosing the medium that fits the constraints
Technical lead / orchestrator: coordinates architecture and delivery across multiple mediums

These names are not rankings. They are descriptions.

Measure outcomes, but do not ignore the medium

Kyle's point about loving deliberate code writing matters because the medium affects:

Long-term maintainability
Ability to debug deep issues
Portability across platforms
Testability and observability

If you built a workflow in a no-code tool and it meets the need, that can be the best possible choice. But if the organization expects custom behavior, strict compliance, or unusual performance constraints, code might be the safer choice.

Avoid the "productivity shame" loop

Kyle mentions he has "never liked any accelerations" he has been exposed to. Many engineers feel pressure to adopt tools that change the feel of their work. Builders feel pressure to prove they are "technical enough." Both pressures create resentment.

A better cultural rule is: pick tools that fit the problem, and let people take pride in the craft they are actually practicing.

Where this lands for me

Kyle's post is ultimately about honesty. If you do not like writing code and you intentionally avoid it, you may still be creating valuable software outcomes. But calling that "coding" can blur the very distinctions that help teams collaborate and help individuals grow.

I read Kyle as saying:

No-code and high-level tools can be incredibly efficient and produce quality outcomes.
Writing code is its own craft with its own joys and responsibilities.
We do not need to pretend those experiences are identical to respect both.

That is not gatekeeping. That is clarity, paired with appreciation.

This blog post expands on a viral LinkedIn post by Kyle Simpson, Looking for tough engineering problems to solve. View the original LinkedIn post →