Being a Computational Designer Is Confusing as Hell
The computational design career is confusing.
If you’ve been on LinkedIn recently, you’ll notice there’s a lot of excitement around computational design. Things like complex 3D models, talks about AI, flashy Grasshopper workflows, etc. I know this because I'm part of it too. I post about it often, trying to make the field more visible. Maybe that's why I'm seeing more it more too. And I love the work. I am genuinely think that it makes people's lives better.
So when Veronica, one of the directors, asked for help on a project, I was excited. She needed help creating an analysis model. It was the exact thing I am good at. I have made a few complex analysis models through scripts before.,
She got me in touch with the lead engineer, Rick. He shared the usual starting information. A reference model and a rough idea of how he wanted the model to behave. After that meeting, it seemed straight forwards, so I estimated two days of work. He agreed and I got to work.
I opened a blank Grasshopper script and imported the reference model.
and......
I am irritated.
Because it happened again.
This wasn’t a computational design task. It was an engineering one. Every part of the model needed some decision-making. Decisions that need to be backed by years of engineering experience. A skill I don't have.
I know what's going on. This isn't the first time it has happened. Maybe it's an honest mistake, so I keep my cool and go back to Veronica. "What's my role here?" I asked.
She immediately knew what I meant. "Well, we are short on engineers, so I need you to do this".
"This project has a tight deadline, we've promised the clients results this Friday, I need you to get this modelling done ASAP" Veronica continued.
“I’m not an engineer,” I said. “I do computational design.”
“We're understaffed and you’re one of the few who knows how to use the program.”
And that was that. There was not more arguing with her. I knew she just wanted the problem solved regardless of who or how.
So, I put my head down for the next two weeks and manually built the model. But of course, since it needed engineering judgement, I pestered Rick the whole time. We met the Friday deadline and most deadlines after that, but at the cost of Rick’s time and focus. And of course, I had to push aside all my other work too.
I know how to use these programs. I’ve worked with the APIs. But I don’t have the engineering experience to make those kinds of decisions.
Which is exactly why a career in computational design is so confusing.
We sit in this strange awkward middle. Not quite software developers. Not quite engineers or architects either. Yet we know most of their problems better than they do because we know the ins and outs of their tools so well.
But no one really knows what computational design is. And that's okay, it's actually part of what makes the it valuable. We can pull different domains together to make a solution that is more than the sum of it's parts.
The problem is, when people (clients or companies) don't understand that and try to squeeze you back into the nearest box they can find.
And that tension never goes away. Some days you're doing high-value work. Other days, someone panics about costs and you're back doing drafting tasks again.
Computational design doesn’t exist alone. It’s always tied to something else. And most of us usually get into this field from something else. We used to be architects, engineers, drafters, etc. That makes things blurry.
What does a computational designer actually do?
In traditional roles, what people do is clearer. If you're a structural engineer, you design and analyze things. If you're a drafter, you document and create models. But a computational designer, what do we do ?
Do we write scripts? Build tools? Support project teams? Develop automation?
Yes, it's all of the above. We don't replace people, we work to enhance their work. That’s what makes us different from pure software developers. We understand the domain well enough to bridge the communication gap. But that's much harder to quantify. Especially when you think about it in terms of billable vs non-billable work.
But when that role isn’t clear to others, we get defaulted into the work we used to do.
Get my free guide on how to apply computational design to your work.
Why it's a problem
I’ve seen this again and again. ... and again and again.
A project is understaffed, and I’m asked to step in as a drafter. Or worse, make engineering decisions I’m not qualified for.
It’s not that I think those jobs are beneath me. If anything, I think I’m not good enough to do them. I don’t have the experience to make critical calls, and I shouldn’t be pretending otherwise. I’d rather automate a thousand boring tables than pretend to be an engineer.
It’s like asking anyone that can drive to haul freight in a semi-trailer just because there aren't enough truck drivers. Sure, it's technically possible, but it's slower, riskier, and a misuse of everyone's time. Unless that person wants to learn to drive a semi-trailer, then it's a different story.
The more time computational designers spend doing conventional tasks, the more it reinforces the idea that that’s all we are, just engineers or drafters who dabble in Grasshopper. Like it's a hobby not a discipline.
That perception erodes the real value of computational design.
Think like a consultant
That’s why I’ve started thinking of computational designers more like consultants, even when we’re embedded in teams. The work that we need to do is actually very similar, if you think about it, we have to:
Market our work
Communicate our value
Find and shape the right kind of problems
We have to put in the effort to find alignment in the work that we do.
That doesn’t mean we only chase the cool stuff. Or say no to everything. But it does mean being intentional. It means building the habit of setting boundaries and advocating for what we do.
And that’s hard. It's really hard. Heck, after 5+ years, I am still trying to understand what it means to “draw the line”.
Especially when you have managers and directors that are overworked and just want the problem gone. Especially when they have targets to meet and you seem like the overhead.
But every “yes” to misaligned work is a “no” to work that fits. It eats into your time and energy. You also end up responsible for it too. You get pulled into purgatory. Not quite doing what you’re hired for, not quite doing what you want to do.
So how do you get the right work?
It starts by being clear, really clear, on what you do and don’t do. What kinds of problems you solve. What outcomes you aim for.
There’s no universal definition of computational design, so you’ll have to write your own. But once you do, you'll need to get good at communicating it. That part is hard because this field is still new and still changing. Even after years of doing this, I still struggle to explain the value of what I do. I've gotten better but there's a long way to go.
Getting that clarity also helps you say no. Because if you keep saying yes to everything, people will keep giving you the same kind of work, even if it doesn’t fit.
Now, I know this advice only works if you’re in a safe position. I’ve taken plenty of misaligned tasks myself, simply because saying no would’ve cost me more. Like with Veronica, even after telling her it wasn’t a computational task, I still did it. Sometimes, that’s the tradeoff you have to make.
But if you never draw the line, no one else will do it for you.
Final thoughts
Computational design is still new. Most people still don’t fully understand what it is. That means it's up to us to shape the narrative. Not only do we have to do the work, we also have to communicate it and find the right kind of problems.
We didn’t join this field just to be engineers who know Grasshopper, or drafters who can use Dynamo. We came here to help others work better by putting computers to better use.
But that only happens when we take the time to show the value. To communicate and to make it clear how this work fits into the bigger picture.
Because if we don’t do that work, no one else will.
Thank you for reading. Consider subscribing if you haven’t, it really helps me know my writing here is useful.