We Write Code, But We're Not Software Developers

It's time to stop pretending

There are days when I think computational design is the best thing in the world.

We solve real problems. Problems that no one else can solve. We build tools that save people hours. Tools that traditional software developers wouldn't even know how to start.

We can do this because we understand the industry works. We know how people think, how models are made, the processes in a project. We understand geometry, Grasshopper and can build bespoke tools for projects at almost the speed of light. It's amazing.

Then, there are days I feel like a fraud.

Because somewhere along the way, we started to do more. We started building company-wide platforms and said yes to everything. Yes, to making our scripts company policy on projects. Yes, to overhauling our documentation system because we found something free online.

Of course we can do it, we've done some cool shit. I made a script that reads a reinforcement data from plans, cross-references that with standard details and visually reported it to the engineers for any model. It saves them 3 days of work every week. I can do anything.

Well... this is starting to sound familiar. Like this has happened before…

Don’t Fly Too Close To The Sun, Icarus

— Daedalus, Icarus' father

That doesn't mean we shouldn't push ourselves. But building scripts and small tools is not the same as building platforms. Not even close.

There’s a reason software development is a whole other industry. And as much as I want to believe we’re one of them, we’re not. We do different things. Yes, we both write code. But we bring very different skills and values to the table. We know more about geometry, engineering, drafting. And they know more about servers, databases, containers, and system architecture than we do.

Both are hard. Both are valuable. But they are not the same.

So, let’s talk about some of the ways we’re not like software developers and why pretending we are might just ruin us.

Computational design encourages short-term hacks

Grasshopper and Dynamo are amazing tools. But they also make it dangerously easy to move fast. That speed becomes addictive. And in this industry, speed equals value. The first time you deliver something faster than expected, that speed becomes the new baseline. It changes from “how can we help?” to “how fast can you solve this?”. Everyone that comes to you with a problem expects it solved yesterday.

It turns computational design into a world of quick wins and dirty scripts.

But reliable tools, the ones that are robust and deliver repeated value, take time to make. Even with ChatGPT, they still take time, longer than most people think. People forget that. They see scripts as the golden goose, write once and quickly for Project A, reuse forever on Projects B through Z.

This is meant to be a company policy script by the way.

Talk to any good software developer and they'll tell you the same thing. That speed is for prototyping. When it comes to building something real and valuable you need time. In computational design, it feels like we’re always prototyping.

Speed Makes Us Overconfident

Speed itself isn’t the problem. It’s one of the best things about computational design. We can spin up an impactful workflow in days, sometimes hours.

The real problem is that speed makes us overconfident.

We start to conflate our quick solutions for critical workflows. We start thinking we can build platforms. We start thinking we can replace core workflows in people’s lives, without truly understanding what’s going on behind the scenes. We start thinking everyone should use Grasshopper because it would make life so much easier.

But no one thinks about that. About the impact of their work if something goes wrong. Or about the monumental effort it takes to scale a solution.

If building robust software was easy, everyone would do it. Again, that's why there is a whole industry out there. There’s a reason there are whole companies built around just one product. Here we are, trying to do the same with 5 people.

We’re Not Taught Software Development

Most of us didn’t come from software companies. We picked up programming on the job. Learned by doing. We figured out what worked by trial and error. And that's still amazing because we provide value from day one.

But we didn’t learn testing. We didn’t learn documentation, version control, deployment pipelines, or system design. Not in the way software engineers do. Even if you have a computer science degree, you probably didn’t get the industry experience needed to build long-lasting, stable tools.

And yet here we are, taking on platform-level work.

That doesn’t mean we should stop building. But it does mean we need to be honest with ourselves.

If we’re serious about doing bigger things, we need to work with people who’ve done it before. Maybe our job isn’t to build everything. Maybe it’s to translate business and project needs into digital logic, so software developers can do what they do best and we can do what we do best.

Why are we trying to be everything all at once?

So, what now ?

We’re not software developers. We’re computational designers.

That doesn't mean we're less valuable, but it does mean we're different. And pretending otherwise will burn us out and make people stop trusting what we build because things keep breaking.

We sit at a weird intersection between industry knowledge and programming. That’s actually a good thing. We can translate project needs into computational logic. We can make workflows smarter. We can build prototypes that show what’s possible.

But that doesn’t mean we should also build the entire system behind it.

Let’s keep pushing boundaries. Let’s build smarter workflows. Let’s try new tools. Let’s use AI. But let’s also be mindful of what we don’t yet understand.

Thank you for reading.
Subscribe to CodedShapes and I'll send you my free guide on applying computational design.