Phew. I just stepped out of a company-wide presentation. Not just any presentation, a computational design update to the entire company including all the directors. Talk about high pressure. It was a presentation about How computational design actually helped our projects. I know it was just a presentation. But it felt like my job was on the line.
I think it went well (I’ll know soon enough if it didn’t). I went through all the benefits of computational design and even threw in examples of recent projects. All positive stuff of course.
Afterwards, Tom, one of our structural engineers, came up to me to ask some questions about a slide I had on a recent project. He'd been working on an old building with a long history of re-modelling. That also meant a long history of outdated drawings: over 20 sets, across five levels. That’s 100+ drawings to sift through, just to figure out which ones actually reflected the current state of the building.
There had to be a better way. Maybe something computational that could at least speed things up.
My mind went into problem solving mode. Thinking about what plugins in Grasshopper can help with identifying shapes. But before I could say anything, Tom interrupted my train of thought.
“This one’s not urgent,” he said. “I want to try solving it myself. Can I come to you for advice as I go?”
Honestly, that was awesome to hear. Most people just want to offload the work. But Tom? He wanted to learn.
So we did just that. I went back to my usual work, and Tom would swing by every now and then with questions or ideas. At the start, we met a few times a week. As he got more confident, it dropped to once a fortnight. Eventually it became an on demand thing. He’d pop over when he got stuck or wanted to bounce around some ideas.
Three months later, he showed me what he’d built.
He used Rhino to overlay all the drawing sets. Then he imported a point cloud survey from the contractor (which I didn’t even know was possible in Rhino). Using Grasshopper, he controlled the camera views to compare drawing overlays with the point cloud. He even built a feature to flag which drawing appeared to be correct.
A few days of polishing later, Tom presented it to the office and I couldn’t have been prouder.
It made me realize the biggest flaw in the presentation I gave to the office. While I was delivering positive news about efficiencies and time saved on projects, every solution was handled and delivered by me.
And while that might be the most efficient use of my time right now, it’s not a scalable approach. Long-term, the better move is to empower others to work with computational design themselves.
The Dilemma, teach a man to fish or ...
Since then, I’ve found myself asking the same question every time someone brings me a problem.
Do I solve the problem myself or help others learn how to do it?
It’s easy to quote the classic:
"Give someone a fish and they eat for a day. Teach them to fish and they eat for a lifetime."
But in the real world, teaching takes time. And when deadlines are tight, that time feels like a luxury. Imagine a person dying from hunger, haven't eaten in several days, and instead of giving him a fish, you teach him how to use set a bait. He might just eat the bait.
In Tom’s case, he had enough breathing room to make learning part of the process. That won’t always be the case.
Still, learning by solving real project problems is the best way to get better at computational design. It keeps what you’re learning relevant. So if you ever do find that bit of breathing room—use it.
Here are three ways to get started.
1. Identify boring tasks
What tasks drain your energy?
What repetitive thing makes you dread opening your laptop?
Those are goldmines.
They might not all lead to a Grasshopper solution, but they give you a concrete starting point. Something more relevant than simply following random tutorials online.
Most of us know exactly where our time goes. But we rarely pause long enough to rethink how we work. We finish the task, move to the next, and repeat.
So next time you have some time, like a public holiday or a gap between deadlines, take a moment to reflect. Is there a better way you could’ve solved that last task? Would a colleague have approached it differently? Could a script, a rule-based method, or a smarter workflow help?
Sometimes that reflection is all it takes to unlock a better approach.
2. Scroll more social media
I never thought I’d say this, but, scroll more social media.
Follow computational designers on LinkedIn (cough, cough, like mine). Let the algorithm do its thing and inspire you with different ways people are using computational design.
Your feed will fill up with scripts, workflows, real-world applications across disciplines. Yes, there’s a lot of noise, but when you’re just starting out, you don’t know what’s possible yet. You need to be exposed to a wide variety of things before you can make that call.
And who knows? One day, something you see might find a solution to a problem you've been wrestling with. It's one of the reasons I post frequently on LinkedIn, not just to show off the interesting stuff I’m working on (okay, maybe a little of that), but to highlight all the weird and wonderful ways computational design can be applied.
Inspiration and exposure matters. Sometimes, a random post is all it takes to unlock a solution to a problem you didn’t even realise you could solve.
3. Don't deliver too fast (make room for learning)
Okay, don’t tell the managers—but sometimes, slowing down is the smart move.
We don't have to be so fast all the time. it pays dividends to slow down and use that time to explore other ways of working, computational or not.
If you’re on a project you know you can deliver in two weeks, but you’ve got four, use some of that buffer to explore a new way of working. Try a new tool. See if Grasshopper or AI can help. Experiment.
Learning doesn’t always feel efficient in the short term, but over time, it pays off. To quote another cliche:
"One step back, two steps forward"
It’s hard to learn and deliver at the same time but finding that balance is part of the job.
Final Thoughts
These days, I try to be more mindful. Instead of jumping in to solve everything, I’ll first ask:
“Do you want to learn how to do it?”
Most of the time, I still end up doing it. But every now and then, someone like Tom says yes. And that makes all the difference.
People teach me so much about their field when we collaborate, it feels right to return the favour. You don’t need the perfect project to explore computational design. Start small and look for pain points. And when you can, make space to learn.
Because sometimes, the best way to get better at your job...
is to make your job better.