I remember this one call I had with a client. Let’s call him Adam.

yes, I am starkly aware that most of my articles these days start with a call

It was a kick-off call for Adam to brief me on a modelling package. Showing me the current model and what my part of the modelling looks like. But five minutes in to the call and Adam couldn’t get the model up because he had some problems with his network.

The call didn’t drop off but he was frantically trying to turn his VPN on to get access to the model.

“Thanks for being patient, there’s always so many steps to turn on this darn VPN. It always resets when I walk into the office” he said. “I have to keep toggling it whenever I leave the office”.

“No problem”, I said. And I spent the next ten minutes or so watching him fumble with the settings.

I did notice that I think there’s something that can be built to make his life easier. Maybe something that he can click and it just turns the VPN on/off for him without going to settings → network → advanced settings → turn VPN off all the time.

He eventually got the model opened and we went through the modelling package. But I also left that call with a curious idea that I could build something that solved this VPN conundrum of his.

A few moments later

About a week later, we had our update call as scheduled.

I started with: “Hey Adam, before we get into the modelling update, I noticed something in our last call and I made something small just to help you out, would you test it? If I did things right, it should toggle your VPN for you, so you don’t have to always find the setting.”

Adam opens the executable and just double clicks it

“Oh, shit! That’s pretty amazing, that saves me so much pain. It’s always so annoying to find that damn setting,” Adam said. “I didn’t even know you could make something like this. I thought you only do Grasshopper. Heck, I didn’t even know this was a problem that could be solved.”

That last part stuck with me. He didn’t know what was possible.

That modelling package went well and Adam has been a repeat client ever since. And now that he got a glimpse at what I do, the work that I have gotten from him has varied from regular modelling to creating plugins and standalone programs for him and the entire company.

Subscribe now

The problem with “computational design”

Seriously, one of the hardest parts of what I do is telling people what I do. I can’t just say “Grasshopper.” I can’t just say “BIM” or “software developer” either.

When Adam hired me, he hired me for Grasshopper work. Parametric modelling. That’s what “computational design” means to most people. Geometry, 3D models, and magic.

He didn’t come to me because of his VPN. Well, he didn’t even know a tool could be built to solve that problem. And he didn’t know I could solve that problem.

That’s really the issue. “Computational design” sounds fancy, but it’s actually too vague. People either don’t understand it, or they box it into a narrow category often labelled as “fancy magic”.

And because of that, they either ignore it or they reject it. Either way, they leave value on the table by not asking.

As much as I love to do Grasshopper work, I love solving these seemingly small problems with computers more. It’s why I learned to code. And it’s why I believe in understanding the full context of things before solving.

It sounds small but that executable I made saved 6-10 clicks for every VPN toggle. Between going for meetings and working from home, Adam toggled it maybe 10 times a day. That’s 50-60 clicks a day. Over 250 working days, that’s around 12,500 clicks a year. Just for a VPN.

Now multiply that across the whole company and you get an insane amount of time spent on just turning on/off a VPN. And that’s just one friction that I happened to stumble across while on a call.

A lot of the time, people don’t report these problems because they’ve normalized them. We think that’s just the way it works, but really software is meant to make our life easier, not harder.

My work is not just Grasshopper

The VPN executable took me less than 4 hours to build. It saved the average person at Adam’s company about 20 minutes a day. Which is a lot of time and annoyance saved for everyone. I know I’ve said time saved isn’t the only important metric but if you do the math here. It’s 20 minutes x 10 people x 260 working days = 52,000 minutes or 867 hours saved per year.

That’s really the value of digital solutions here. If a problem follows rules, has patterns, or is repetitive, it’s probably solvable with code. I have built things like :

A tool that saves a user clicks by helping to toggle the VPN
A tool that helps you exchange contacts more seamlessly, without the hassle of typing in numbers
A tool that helps you jump to all your folders in your network drive
A tool that helps you archive and file emails

These are all “small” problems but they deliver immediate value because they directly remove the pain from someone’s everyday work. And when you compound all those savings, it leaves you with more room to focus on the stuff that actually matters.

My value (which I often think about a lot) is not just Grasshopper or even programming. It’s developing solutions for problems like these using digital tools. It’s to bring the “expertise” of programming to these problems that people don’t know can be solved.

Solutions Developer

After working with a few clients like Adam, I’ve started to notice a pattern in why people don’t bring me these problems:

They don’t know it’s possible : “I thought you just did Grasshopper”
They’ve normalised the friction : “That’s just how the software works”
It seems too small : “It’s only 5 clicks, not worth bothering you”
The title doesn’t help : If I call myself a “computational designer,” they think geometry only

So, I’m moving away from “computational designer” and calling myself a “solutions developer.”

The title has become too vague and it’s been diluted across so many different roles and quality levels that it doesn’t communicate the scope of what I actually do anymore.

Also, description wise, I prefer “solutions developer” because it is developing solutions to problems for people instead of “computational designer” which sounds like computationally designing things.

But whether I call myself a “solutions developer” or a “computational designer,” it doesn’t change the difficulty of telling people what I do. The title helps, but what really changes things is showing people what is possible to solve.

What I’d ask you to think about

That modelling package with Adam went well, and he’s been a repeat client ever since. The work I’ve gotten from him has ranged from regular modelling to creating plugins and standalone programs for his entire company. All because of a VPN toggle he didn’t know could be fixed.

If you’re reading this and something jumped out at you, reach out to either me or a someone “digital” you know. Maybe you got a process at work that’s always been annoying but you assumed was just “how it is”. Maybe it’s the stuff you’ve stopped complaining about because it feels too small to fix.

Just reach out, because like Adam, you never know, it could be solvable and we could be changing the way you work.

Even if we end up just talking, the conversation is free and at least you’ll walk away with some direction on how to see things differently.

If it’s systematic, it’s solvable.

Thanks for reading
Subscribe to CodedShapes and I’ll send you my free guide on how to actually do that.

Subscribe now

How Do You Solve a Problem Someone Doesn't…