What is this

I’m going to try to write, and film, one of these every week. It’s a short log of what it’s like to leave a job and build something on my own. I am treating this as a “documenting” style but will try to make it as coherent as possible.

I think this journey of mine is going to be interesting, so I want to share it with everyone but I also didn’t want to disrupt my current newsletter. So, I create a new “section” on Substack.

And if you don’t want to follow along or read this, no problems, you can always unsubscribe to this section at the bottom while still getting the normal CodedShapes issues every week.

Rules

I adding this to my already pretty long things to do weekly, so I made some rules to prevent this from sucking up too much of my time.

• Writing and editing, can only take 1 hour

• Filming and editing, can only take 1 hour

  • During filming, no more than 5 re-takes.

• Publishing (in all it’s nitty gritty), can only take 30 minutes

I am going to set a time for each and when the time is up, I’ll wrap up and publish. The whole point is for this to be rough and it’s a log, not “content”.

Week 1

It’s the end of week 1 of going independent for me.

And if I could sum it up in two words, it would be: freeing and exhausting.

Like the start of most journeys, I’m find myself wanting to do many things. Filled with excitement and busier than ever.

I got more done than I had in weeks.

Just as a summary,

• I got the company setup and all its accounting logistics and tax implications

• I got the CodedConstructs site up and running

• I have been doing some outreach every day

• I had some meetings with new people (Just meeting interesting people)

• I had some discussions about new projects to collaborate

• I have been doing some product development too

Every evening, I am exhausted. But there’s a strong sense of accomplishment each day. There’s just something about being able to own the end-to-end process that makes working on it, so great. Maybe it’s the control and also the fact that I am able to execute on my “vision” for what digital work looks like.

It’s also the small things too. Like being able to go to the gym before lunch instead of “slumming” it with the after work crowd. Or meeting people and not worrying about my lunch break ending and having to rush the end of a great conversation. Since, I just started being able to work from my “office” at home is way better than the pressure of needing to go to the an office (although I imagine, this will get lonely soon).

All of this in the first week has made imagine going back to a full time job unimaginable.

As Naval once said:

But it’s not all glorious.

The elephant in the room here is that at some point, all of this has to make money.

Freedom is great and all but so is being able to pay the bills.

And it’s a sneaky one. Because now that I am alone and every decision is on me. Which leaves room for a lot of doubt and questions. No more manager or “management” to blame. Everything is on me.

Which when I am tired, can feel overwhelming.

It’s a strange to feel so free and also feel that time is running out at the same time.

It’s led me to understand burnout better now than I ever did on a salary. Because there is just an infinite things to work on at a given time. There’s just always more to do.

Actually, the hardest part might even be to trust myself more. Because well I making decisions that need to have a positive and monetary impact and a lot of that is trusting my own instincts and processes.

In a few moments of weakness I have thought of reaching out to the less savoury kind of people ~asking~ begging for a project just because it seemed easier than to stand my ground. But I’m hoping I never go through with that.

That’s week one in a nutshell.

I am going to try and keep these up each week because I find it interesting to see how this unfolds.

Thanks for reading.

I’ve spent months deliberating this and everyone tells you how scary it is to “take the leap”. But no one warns you how weird the time leading up to the jump actually is. I have pivoted between being grateful and then wanting to be rid of the job. And the best of all, teetering between full of self-doubt and full of confidence.

It’s really was a strange time to be in.

I’m allowing myself to feel all of it because I think that’s the best way forward.

The weirdness of being a digital person in the AEC

CodedShapes has been my way of trying to make sense of this weird field. Working through story on what it actually means to be a technology person inside an industry that doesn’t need technology to deliver its work.

AI and Grasshopper are great, but at the end of the day, a building just needs a drawing printed on paper. As long as getting there isn’t too expensive, most companies actually don’t care.

Through these articles, I kept circling the same question from different angles. Finding the right things to build. Debating billable vs internal tools. Hammering on the point of understanding first, before building.

All of it has been me trying to answer: how does digital work actually fit inside AEC?

When I say “digital” I mean everything : Building plugins, Excel macros, Grasshopper scripts, standalone applications, web applications, … everything

Proving Ground put it well in 2017 when they wrote that computational design was largely misunderstood. That it should be treated like a problem solving methodology instead of an actual role. The article even goes on to suggest ways of working with digitally forward people at a time where “computational design” was just a new thing.

But here we are, almost a decade later and no one has a good answer. People still don’t know if the computational designer is a BIM person or an engineer or just a software developer. And even operation wise, is the role project focused? Is it just R&D? Is it both? How do we budget it?

And now with AI, we’ve arguably moved even further from understanding what these roles are. Since it’s made tool-building more accessible, a lot more “normal” people are making tools now, which blurs this line even more.

Is a senior structural engineer that uses AI to build tools the same as computational design? I don’t think so, but some companies might.

I still believe in the vision of “describe a computational vision that can help lead your business to the best possible solution” but I just don’t think doing it from a company works anymore.

What working inside taught me

I’ve spent most of my career working inside structural engineering consultancies. Building tools, scripts, workflows, and digital systems around the company and it’s projects. And it’s been a bumpy ride. I’ve built tools that entire projects depended on. And I’ve built tools that never saw the light of day, months of work just sitting in a folder somewhere because it wasn’t thought out properly. Or because someone thought it was a good idea to automate the small 1% of their work.

And what I have found is that even though it’s a deeply technical area, the things that actually dictate the value of computational design are communication and understanding, which are both very human problems.

As I “climbed the ranks”, I kept pushing to understand the entire delivery chain for digital work in this industry. Not just the tool building but the scoping, the selling, the maintaining, the finances, basically, everything.

But as I pushed for more ownership while working for companies, I met an equally increasing resistance that stemmed from all the classic “corporate” reasons. Politics, budgets and status games.

It was reaching a point where the role didn’t fit the work I wanted to do anymore.

Walking the walk

It’s easy to complain about companies not giving me what I want. It’s much harder to do something about it. So, this is me walking the walk.

I’ve spent years writing about how computational design works (and should work) in our industry. And now I want to put that to the test on my own terms. Going independent forces me to stress-test my own philosophy, which has always been to understand first, then build.

In a world where building new tools is fast, focusing on the human elements like communication and understanding seems counter-intuitive but it’s the right instinct to act on now.

The industry still doesn’t know how to position this work. And just building things quicker with AI is not going to solve that.

But the other hard truth is that I also don’t know what the answer here is either.

Starting my own consultancy forces me to find that answer because you can’t sell something you can’t explain. I can’t hide behind budgets or politics anymore, I am forced to confront the market with my ideas. I have to find the fit between what I believe and what people actually need.

Which is why it’s taken a lot of deep soul searching and incredibly difficult work to arrive at this decision. But ultimately it became clear that this was the only way forward.

What is CodedConstructs

To me, CodedConstructs is not a completely new thing. It doesn’t change the work or who I am. It’s a clearer container for the work I’ve already been doing and want to do more of. Well, this container needs to pay my bills at some point.

I want to build tools and workflows that teams can actually adopt, maintain, and use to be more efficient. Not built for marketing or because some director decided the company “needs to do more AI.”

The work I care about sits between design, delivery, and software. And it’s always been about ensuring the tool fits the way the team actually works.

What’s next

Nothing changes on the CodedShapes (this newsletter) front. But it does mean I am fully open for business.

If your team has a design, modelling, documentation, or reporting workflow that feels too manual, too fragile, or too dependent on one person, I’d be happy to chat. Even if it’s just to think through what makes sense, that conversation is free.

If it doesn’t work, I’ll tell you and I’ll never take payment from you before the next steps are clear.

For the first few years after graduating, this single question kept me up at night the most.

I was lucky (and maybe not so lucky) because early in my career, I got a job at a structural engineering company that just started a digital team, and I was their first computational design graduate.

The concept was a team that knew engineering and code, helping create tools and workflows that made everyone else in the company more efficient. Grasshopper was all the rage back then and this company wanted to use that as an advantage. Well, and normal programming to build proprietary tools.

But really, no one knew what that actually meant. Like what progressing in the role looked like. What the team structure was going to be. How to discuss salary. Or even how to budget the team. It was all so new to everyone.

And as a graduate, I couldn’t help but worry about my future.

Especially when the rest of my cohort from university were discussing their careers. They talked about getting to senior level. About being fast-tracked to manager. Or even negotiation tactics on how to get the salary they thought they should be getting.

They looked to the future with certainty while I didn’t even know what my next year would look like. Does “senior” even mean anything in a field of less than a 100 people?

So, again, the question kept haunting me.

Am I wasting my time by doing computational design?

I wanted someone to tell me what the next step was. To show me what it meant to “climb the ranks.” To give me a promotion checklist to work on. Most importantly, I wanted someone to tell me that I was learning useful stuff for the future.

But as uncertain as things were, the work was too interesting to give up. I was coding, I was scripting, I was exploring digital concepts with clients and directors. It was one of the most interesting times of my career.

So, I soldiered on, hoping the company would overcome the growing pains of starting a new digital team.

A few projects and tools (and years) later...

We still didn’t know a damn thing.

And like anything new, the interesting bits started to go stale. And this idea of being a digital person in this structural company started to really weigh on me.

I got promoted to senior. Cool, but again, no one knew what that meant. Every fortnight, we had meetings about budgets and R&D initiatives.. We had directors chasing us to create concepts that never saw the light of day.

On paper, cool stuff but no one knew how all of that got translated into value for the company and into our roles. Every performance review was tense as I kept pushing for a clearer direction and more pay (as does everyone).

At some point, I stopped waiting for the moment when the path would become obvious. And kept questioning whether I had made a terrible career decision.

Then AI showed up

At first, it was amazing.

I ignored everyone who said “AI would take our jobs” because I found myself performing at a higher level. I was executing at a speed that wasn’t possible before. Tools and workflows got created much quicker because of it. Maybe this was a way of proving my value and finally getting some direction. Maybe, this will bring back the glory days.

But then, engineers, drafters, …. everyone started using it.

And not just chatting with it, they started building their own automations, creating custom tools, connecting AI directly to their workflows. When the digital team couldn’t respond to them because of budgets or politics, they simply used AI.

Suddenly, the threat seemed real.

If people can build their own tools now, why would they need me?

In fact, a quick google tells you that domain experts make the best use of AI. If you’re an expert drafter or engineer, you can use AI to build something amazing because you know the field so well.

So, if my value is connecting people to digital tools, and AI can now do that, what is my value?

If I had focused on being a structural engineer from the beginning, I could be using AI right now to build tools because I would’ve have been a domain expert.

Instead, I’m in this weird middle ground, knowing a lot about software and the AEC industry, but not enough in either domain to be a true expert. If I had stuck to a typical engineering career and just learnt to code as a hobby, would I be in a better position?

Almost a decade later, I guess it’s the same question that still keeps me up at night.

But there’s no such thing as certainty

When I was a graduate, I wanted someone to show me the path to senior.

Then, I wanted to know how to climb the ranks. To know what was next apart from making tools and concepts.

Now, with AI so good at executing and people building their own tools, how do I move forward?

The good news is, as humans, we’re good at recognizing patterns. And the pattern here is that my career has always been uncertain. AI is just the latest version of the same feeling… I think.

And as intoxicating as it is to daydream about “if I just stuck to engineering, my life would be better”, the truth is, I wouldn’t be here if it wasn’t for this weird intersection.

I wouldn’t have started this newsletter or delivered all the incredible projects and tools in the past if I had just been a regular engineer.

And you might be feeling this too

Maybe not about computational design. But about something.

Maybe it’s the job market or the economy. Maybe, like me, it’s the thought that AI is coming for our jobs.

But as the saying goes, “the only constant is change”.

Which means, I’ll never get the certainty I crave.

Which as uncomfortable as it feels (all the damn time), it’s a good thing. It’s what I’ve had to remind myself while writing this. Certainty was never the thing that moved me forward anyway. It was following what was valuable and interesting at the time.

Whenever I waited for the path to become clear, nothing happened. But every time I just did the work because it was interesting, it opened up new pathways for me.

P.S. If you can’t tell, this article is more for me than it is for you. I’m dealing with a lot of uncertainty right now and writing this has reminded me how much I’ve had to navigate to get here.

P.P.S. I’ve got an announcement next week. Let’s just say I’m done waiting for the path to become clear.

Meet Nate.

He’s a senior structural engineer. The kind of person that’s always looking for ways to make delivery less painful.

He was working on a high-rise project which has concrete columns. It was a 23 floor building with about 20 or so columns per level. What engineers then typically do to assess the columns, is a technique called a “column load rundown”.

You take results from the analysis model, put them into a design program, and check that every column works. The problem though, is you have to do this for each column on every floor. On this project, that’s more than 400 columns. And every time there’s a design change, you do it again.

It is as tedious as it actually sounds.

Which is why it’s known as a “rite of passage” for graduate engineers. Because it’s labour intensive and considered as “engineering grunt work”, most companies make graduates do them. That solves the cost issue but it still takes a long time to do them.

So, most companies have some sort of workflow to speed this up. Not fully automated but not entirely manual either. Generally, enough for new graduates produce results in a decent amount of time but still too tedious for senior engineers to use.

In this company, Nate built that workflow. It was an Excel spreadsheet that would take the results from an analysis model and through some inputs, it would design all the columns per floor. That meant, the graduates on this project only had to do this 23 times instead of 400+ times. What used to take three days now took about four hours.

But the spreadsheet wasn’t perfect. It only supported one analysis program and it only handled single-storey columns. And since Nate is busy with other projects all the time, the spreadsheet fell behind with each new requirement it couldn’t handle.

Not to mention, fixing a spreadsheet he built for other teams isn’t in his KPIs. It won’t get him promoted. Upper management only cares about how billable he is, not what tools he’s made. It’s not something he can justify spending a Tuesday on when there are deadlines to hit.

And so, the spreadsheet remains out of date. People still use it because it’s still better than doing the rundowns manually. But they start working around it, adding band-aids to cover for the things it can’t do.

In fact, there’s a new graduate working on this project, her name is Rey, and she’s using AI to build a new column rundown spreadsheet because she can’t get Nate’s to work.

But we all know how that goes...

The tension of being billable vs internally useful

Nate’s story, unfortunately, represents most internal tools ever built in the AEC (Architecture, Engineering, Construction) industry. Unless it’s a company’s core business offering, tools like these always follow a similar story.

Nate wasn’t trying to build a product. He was just trying to get through a painful process faster. He saw a problem, and he built something that fixed it. Which is most people in this industry. No one is thinking about “internal tooling” or “automation strategy.” Everyone just wants something that makes their lives easier.

Not to mention, building something that solves your exact problem is fun and creative. Chatting to AI or even building a new spreadsheet is more fun than doing a column rundown for 400+ columns over and over again.

But the minute you build something useful that everyone else wants, there’s a tension on your time that didn’t exist before. You now have to teeter between being billable and being internally useful because you now accidentally own what you’ve built

Doing a column rundown one by one is slow, but you’re making progress. And you can charge that time to the project because that’s just what it takes to get it done. But if you work on Nate’s tool, how do you charge your time to something that helps on all projects?

It becomes a battle of solving today’s problem vs solving it in a way that lasts.

And companies usually only rewards the first because anytime that isn’t charge to projects is considered overhead. And when the company looks to promote Nate, it’ll be because of his projects, not because of the spreadsheets he made. Nobody gets promoted for maintaining an Excel sheet.

So, you build something useful, and now you’re accidentally responsible for a product. With no time, no incentive, and no support to keep it alive.

If we look at pure software development, there’s a reason why “product management” exists as a completely separate role. It’s the work of tracking what’s broken, deciding what to improve, and checking its alignment with the current business.

It’s maintenance, and it’s treated as real work.

AEC has nothing like this. The person who builds the tool is the product manager, the support team, the developer, and they’re also a full-time engineer with billable targets. Which is why most of these tools die.

The Rebuild Reflex

With AI in the mix now, building things is faster than ever. You can get a working macro, a script, even a small app in a few a hours. The barrier to creating something has basically collapsed.

Which means the ownership problem gets worse.

Before AI, building something took enough effort that most people wouldn’t bother. They’d work with whatever tools they had, even if those tools were somewhat broken. But now, instead of wrestling with Nate’s semi-broken spreadsheet, anyone can just build their own version. I call this the rebuild reflex. It’s when it feels easier to rebuild something from scratch than to understand and maintain what already exists.

And project deadlines accelerate this. You’re even more inclined to build rather than maintain because the known effort of creating something new feels safer than the unknown effort of debugging someone else’s thing. Even if it’s objectively slower, it feels more in your control.

So, instead of one well-maintained tool, you end up with a dozen half-working ones. All doing roughly the same thing but uniquely for each project.

And well, from a numbers point of view, individual productivity goes up because everyone has a new tool that solves their problem. But what companies miss is the drift in quality and standards. When everyone does things their way, there’s no consistent bar for delivery anymore. How do you standardize the way people do things if they are all on unique tools ?

Not to mention, a graduate and a senior can both ask AI to build a column rundown spreadsheet. But the senior knows which features actually matter. They know enough to hone in on where normal spreadsheets fail. They know what “correct” means in context.

But a graduate who just started might just listen to the AI, even when it’s wrong. And if their manager is too busy to do a thorough review, that could lead to a real problem. I don’t even want to think about what happens when that graduate-made spreadsheet ends up in the hands of other graduates. (Yes, I’ve seen this happen.)

The Missing Role

So what did Nate’s team actually need? Well, they needed someone who owned the tool. Someone who could filter through requests, decide what changes mattered, and actually had the time to make them.

In other words, a product owner.

Now, I know that sounds like a role most 20-person AEC firms can’t justify. And that’s kind of true because the reality is that most firms don’t have the volume of tools or the budget to warrant a full-time hire for that.

But that doesn’t mean the work doesn’t need to happen. It just means you have to be intentional about how it happens. Because if you make “being billable” compete against “working on internal tools” for the average person, being billable will always win. Which is why the tools die.

One option is working with someone external who can fill that role for you. Someone who helps develop and maintain your tools without pulling your billable staff off projects. That’s a lot of what I do for my clients. It means you don’t have to keep someone fully resourced on just the tools, and there’s no battle between being billable and internal development.

Not to mention I work with you to figure out the direction of the tools, I don’t just come in and assume control, we’ll still work together on it.

If that sounds like something that could help, reply to this email or book a time to chat through the button below.

Thanks for reading.

Being a “digital” person in the AEC (Architecture, Engineering, Construction) is a weird place to be. Especially, if you work for a consultancy.

To put it simply, there are two modes of operating. Fire-fighting or tool building.

Fire-fighting is solving problems on projects. Scripting, pulling data, fixing models, whatever it takes to get the job done as quick as possible. These are where tools like Grasshopper, Dynamo or Python shine because no one cares about how robust your solution is. They just want results.

Tool building is the polar opposite. It’s when you’ve seen a problem enough times that you decide to invest in a proper tool, something reusable. It’s more like conventional software development, and it’s probably why I got into this field in the first place.

But the problem though is that these two operating modes are not equal. Working on projects is billable to clients. Tool building, even though more beneficial in the long run, isn’t.

So, there’s always a bias towards fire-fighting.

The Competence Trap

If you’ve been doing this for a while, you know how this plays out. You start out as someone who can solve problems quickly. You’re good with Grasshopper or Dynamo or whatever the tool is. People notice and love having you on their projects because you’re efficient and deliver at a high quality.

You start earning a reputation of putting out fires. You solve problems well, deliver at a high quality and let’s face it, you’re also cheap. So, to some extent, putting out fires becomes your value.

So, what happens when you want to build something? You’ve been fire-fighting long enough to see where a proper tool would help everyone. But the team doesn’t see you as the person who builds things, they see you as the person who fixes things.

And those are two very different roles, even if they use the same skills.

You know that if you could free up a week or two, you’d be able to build something that would make things just way more efficient. A true proper tool that could solve the pain points that you’ve been seeing so often on projects.

But every time, you sit to start, you get interrupted. Someone, somewhere needs your help. You’re just too good at putting out fires. And because it’s urgent and billable, you say yes.

Why “Just Block Time” Doesn’t Work

All the time hacks in the world can’t save you here. You can’t just “carve out time” or try one of those calendar-blocking things. If a project needs you, it doesn’t care when you’ve blocked your calendar or what AI tools you’re using. It needs you to put out those fires now.

And if you do manage to protect a few hours, building and fire-fighting require completely different kinds of energy. You can’t fix someone’s Revit model all morning and then design a new tool in the afternoon.

Well, you can. You just won’t do it well. If you’re like me, you’d be tempted to rush the tool building process because you don’t know when is the next time you will get to it.

Building requires a clear head, a longer time horizon, and the mental space to think about problems that aren’t screaming at you. You really do need the space to just sit with the problem.

What Actually Helps

The antidote, as you might guess, is simple.

If you can’t carve out time within a day, you have to carve out whole days or even weeks.

And that means choosing which fires to fight and which to let burn. I said it was simple but it definitely isn’t easy.

Essentially, you have to say no. Which means letting people down. And being okay with people seeing you as the “bad guy” because you didn’t help them. That’s unfortunately, the cost of setting boundaries. You have to learn to undo the reputation that got you where you are.

I don’t know about you, but that’s the hardest part for me. Even though fire-fighting is stressful, there’s a camaraderie to it. You have people around you trying to solve the same problem and when you do, you feel like a hero.

That elated sense of accomplishment when you fixed something under pressure or delivered when the timeline was ridiculous is unparalleled.

When you’re building things that prevent the next ten fires, nobody even knows it happened. The system rewards the dramatic rescue, not the prevention. And unfortunately, making people more efficient is less dramatic than rescuing them from projects.

Balancing Tools and Projects

I’ve definitely not figured this out. I still have weeks where every day is reactive. But I am trying to get better at protecting that all too important tool-building time.

Also, I have noticed that if you’re only valuable because you fix things, that’s a trap. I mean, my value isn’t speed or being “on-call” all the time. It should be my expertise and that means I should be working on things that bring the most value.

That could be fire-fighting if the project was really high profile and valuable. Or it could be tool-building because there is something vital that needs to be built.

The point here is that if I see something that I can build that prevents fires, I should do that, instead of wanting to work on projects all the time. Because it’s all too easy to get swept up by the urgency of projects.

The art is in balancing the billable and urgent projects with building things that actually make a long term difference.

If you’ve been in the same spot as me, I hope this article helped you think through things a bit more and if you’ve been wanting to build something for a while now but are stuck in fire-fighting mode, reach out by either replying or emailing me at braden@bradenkoh.com. Maybe we’ll find something awesome to work on together.

As always,

Thanks for reading.

~Braden

About ten years ago, a steel roof panel fabrication company built an internal tool that changed how they worked. With some inputs and a button, the tool turned an engineer-designed Excel spreadsheet into a 3D model and drawings. It became an integral part of their client delivery process.

For what they needed at the time, it was perfect. They delivered faster and more consistently than they ever had before.

But over the decade, things changed. The company grew and started taking on more custom projects from clients. They expanded from one product line to five. They are now also looking to migrate to Tekla Structures, a more modern program than what they were using. And all this while, there were no updates to the tool. It still used the same templates and workflows from a decade ago.

I was brought in because they wanted to explore migrating their tool to Tekla. I thought it was going to be straight forward, after all, most companies don’t have such a strong workflow. But what I found instead, was a tool that was poorly designed, full of hard-coded variables and worst of all deeply entwined with old processes. The kind of thing where changing one thing breaks everything else, a glass cannon, if you will.

The tool also only worked for one out of five product lines. The templates that once standardized their process now blocked the custom work their clients were asking for. And moving to Tekla meant an overhaul of 15 years of accumulated process decisions and assets.

Needless to say, the quote was expensive. And sadly but unsurprisingly, they didn’t accept it.

How tools drift

So this is actually one of the most common ways internal tools become a problem. The tool was right when it was built. It met the needs of the entire business. In fact, it even enhanced their delivery.

But time doesn’t stop and neither do the needs of the business. As they grew, the people that worked on the tool left and it was never maintained nor updated. When that happens, the context for why the tool was built the way it was goes with them. The tool bifurcated from what the business needed it to do. Yet, they kept using it because it was easier to workaround it than to update it, at least, until now.

In my experience, there are three ways a tool falls out of alignment with the people using it.

The process changed but the tool didn’t.

The team refines how they work. They adopt new standards, restructure how they deliver projects, maybe even expand into a new line of business. But the tool stays locked in time.

Sometimes it’s because nobody budgeted for updates or maintenance. But most of the time it’s the sunk cost fallacy, companies think once they invested in building the tool, they should only reap the rewards. That they’ve invested three months into development, so why would they keep putting money into it?

Success expanded the scope.

Counterintuitively, sometimes success is why internal tools fail. I’ve seen cases where the first release was so well-received that requests flooded in. And instead of redesigning and integrating those properly, new features just got tacked on. And on. And on. Until updating it means untangling years of organic growth that was never structured to scale.

The tool kept taking on more responsibility without the proper foundations to support it. Making a tool for one person and making a tool for a company are very different endeavors. So, it becomes more brittle as time passes, making both the usage and maintenance of the tool progressively harder.

The team outgrew it.

Tools work best when there’s a solid process behind them. The fabrication company built templates for their tool, which is smart because the more standardized the process, the easier it is to automate on top of it. That meant for repeat clients, they could save about 50% of turnaround time.

But adding templates also meant tightly coupling the tool to their old program. And as the company took on more custom work and expanded their product lines, they outgrew those templates. Every time they tried to update them, something broke. So they stopped trying and just worked around it instead.

Now, the templates that once sped up their delivery, now hindered the work they actually needed to do. The tool went from working for them to working against them.

Why it’s hard to notice

These three things happen when nobody’s monitoring the alignment between the tool and the company. It also doesn’t help that the tool doesn’t give you any indication of misalignment.

The tool technically still works and since it’s too fragile to update, people just work around it. They add a manual workaround here, a workaround there. Each one doesn’t feel like a big deal. But, over time, these workarounds then become the default mode of operating.

The fabrication company only found out about this misalignment when market pressure forced them to move. By then, fixing it was expensive and an operational nightmare, when it could have been a series of small, incremental updates spread over years.

Functional vs alignment

So, it comes down to what I call functional vs alignment.

Most tools work, they are functional. You put in the inputs and it spits out a result. It does exactly what it was designed to do.

But that’s the baseline, it’s what any tool should do at its minimum. The better question is whether the tool is aligned to the way you work. As in, when you have new processes, does the tool work the way we want it to?

“Functional” is a technical question. “Alignment” is then a people and process question. It’s about whether the tool matches the way the team actually operates right now.

A tool can pass every technical check and still be the wrong tool for the job. And depending on how far the tool has drifted from the current process, it becomes a burden rather than an advantage.

That’s much harder to find because you can’t test for it. There’s no error message that says “this tool no longer fits your process.” And in fact, what people don’t always realize is that the more you build now, the more you have to maintain.

Misalignment is dangerous precisely because it’s not visible until it’s already expensive to fix.

What actually fixes this

The instinct is usually to rebuild. A clean slate with new requirements and fresh energy. That’s what the fabrication company wanted. They didn’t want to deal with the complexity of an old, poorly designed tool. So the idea, was to migrate what made the old tool work into a new one.

Which for them, even though they declined my offer, is the best move. Because the old tool has diverged too far from the original design. But if they simply rebuilt the tool and not maintained it, they would be repeating this cycle over again.

The good news, is that there are two things anyone can do to break the cycle. They are simple but like most things, they aren’t easy.

Check the fit regularly.

This is the biggest lever you have. Any time an existing tool causes friction or you find yourself making a workaround, ask: does this tool still fit our process?

This single question combined with having regular review sessions will ensure that the tool is aligned with how any business is moving. If there’s friction between the tool and the way you’re working, it’s a signal that the tool might be out of date and it’s time to put in a fix while it’s small.

And if you can document everything diligently, you end up with a history of how both the tool and your process have evolved, which is incredibly useful the next time someone asks “why does it work this way?”

Make room for small changes.

If the person closest to the tool can see the drift but can’t do anything about it, you’re just watching the problem grow. It doesn’t always mean rebuilding. Sometimes people just need the room to make incremental changes without it turning into a budgetary affair.

I have seen this time and time again when drafters make manual workarounds for internal Revit plugins. Whether the plugin really should just be updated but the company didn’t want to invest in the plugins anymore until it was causing them too much trouble.

If you budget for maintenance from the beginning, smaller adjustments made earlier will cost a fraction of what they cost later. Let the problems accumulate and the effort / time it takes to fix them will compound.

When the tool has already drifted too far

Okay, what if you’re already in trouble? The workarounds have calcified and incremental updates just makes things worse.

Then, unfortunately, you do have to rip off the band-aid and rebuild. But this time you have the chance to do it right, with proper design, documentation, and communication. You give the new tool a better chance of surviving longer than the old one.

It’s expensive but there are some suggestions on how to ease the cost of it. Like building features incrementally or rolling out new updates over a period of time rather than a hard switch between the old and new.

The hard part was never building it

Building the right tool is a moment in time. The requirements are clear, there’s energy and momentum. People are excited, you have AI, and it can even be fun.

The hard part is keeping it the right tool as time goes on. I keep coming back to maintenance because I’ve seen tools that had good intentions and design decay from the harsh reality of time and changing business needs. If a tool is critical to your business, it should evolve with the business. Not stop the day it launched.

And I get why companies don’t prioritize this. Tool maintenance isn’t a full time job, it needs attention regularly but not constantly. The problem is that hiring someone just for that is hard to justify. Which is why the default is to only work on it during their “free time”. Maintenance, as important as it is, gets squeezed in-between projects.

That’s a lot of what I do. Yes, I build tools but I also stay close to the work after we’re done. After we build something, we have what I call a “Hypercare phase”. A dedicated time each month specifically for the kind of alignment work that we’ve seen here. It’s not squeezed into free time nor is it only when something breaking, it’s built into the engagement from the start.

If you’ve got a tool that still works but doesn’t quite fit anymore, or if you’re about to build something, I’d love to hear about it. Simply reply to this email or use the button below to book a call.

Thanks for reading,

Braden

I had this colleague, I’ll call him Marco, who made Grasshopper look easy.

You could throw almost any problem at him and he’d find an answer. It was honestly a little annoying.

So when we ended up working on the same Grasshopper script together, I figured I could just sit back and watch. I had my own ideas on how to solve it, but I was sure Marco would just bulldoze his way through like he always did.

I remember walking into our meeting ready to defend myself. Ready to make the argument about why my approach was better. But there was no argument, in fact, Marco actually asked for my approach. Instead of a fight, we had a good discussion about the scripting approach. Marco wanted my help and opinion more than I thought. Could it be, that Perfect Marco needed help?

The script was a tricky problem to solve. We’d brainstorm something, test it, hit a wall, re-convene to try something else over and over again. Eventually, we got it working and it became the cornerstone of that project. The project could not have been delivered if it wasn’t for us.

I should be proud but all I could think about was how horrible I was to Marco.

In the beginning, instead of trying to solve the problem, I kicked back and let Marco handle everything. Even after he sought my help, I just watched intently, waiting for the moment he’d trip up. I wanted to see the cracks. To be the one who got to say “ha I knew you weren’t perfect.”

But when we worked together, Marco continuously valued my work. It felt more like a partnership figuring things out instead of him bulldozing me with his ideals. What made me open up more was when I realized Marco didn’t actually know everything. He wasn’t in his Ivory tower looking down at me, he was figuring things out the same way I was, just with less insecurity about asking for help.

After the project finished, I took some time to reflect on why Marco had bothered me so much in the beginning. And it sounds cliché, but I had confused fluency with certainty. Watching someone move quickly and decisively through problems had made me feel small. Like I had missed something. Like maybe if I just studied more, spent more time on problems, I too would be Marco.

But working with him reminded me that there’s no promised land. Not for Marco. Not for me. Not for anyone. The people who look like they have everything figured out have their own battles too. And just because they seem so certain, it’s not a reflection of my own incompetence.

I knew I didn’t have to know everything but part of me always thinks that I should know more than I actually do. Like I should know more about structural analysis since I have been working in a structural firm for 6 years. Or I should know more about software since I have been a computational designer for 8 years now. There’s always a “I should know this...”.

I am still trying but I now know that other people’s certainty is not a reflection of my incompetence. In fact, if I don’t know something I should just ask. Just because I am in the same field as someone and that someone knows more, it doesn’t mean I am less skilled.

So if you’ve been hesitating to ask for help because you feel like you should already know, the people you’d ask probably feel that way sometimes too. I definitely feel that way all the time.

We’re all just doing our best to figure it out.

This is part 4 of the Winton Guest House walk through. The series:

• Part 1: Modelling the Fireplace, Living Room and Bedroom

• Part 2: Modelling the Garage and Loft

• Part 3: Modelling the Second Bedroom

• Part 4: Script Organisation (this article)

Read more

Most companies have internal tools nobody’s happy with but nobody will touch.

You know the ones. The tool sort of works, sort of doesn’t. The person maintaining it can see what’s wrong but can’t fix it. Leadership knows it’s not great but won’t approve rebuilding it. So it just sits there, collecting dust or whatever digital tools do when they aren’t used.

The inheritance problem

Here’s how it happens. Someone builds an internal tool. It works well enough that everyone starts using it. It becomes a part of the core process of the company. But then that person leaves.

The company scrambles because they can’t afford to lose the tool, so they hand it to someone else. But when you inherit a tool, you don’t just get the code. You take on all the assumptions, decisions, and constraints that went into building it. And none of that is written down anywhere.

Sure, if you’re lucky, you get a handover. Maybe a few meetings where the original developer dumps information on you. Maybe even some documentation (hopefully readable, not 100% AI-generated). But that only tells you how the tool works. You don’t get the why. Why this approach? What were the constraints? What assumptions were made? What’s the guiding principle of the entire codebase?

All of that is tucked neatly in the head of the person who just left.

So now you’re stuck reverse-engineering intent from output. AI is really good now but even it can’t tell you why things are created a certain way. And when you can see problems but don’t have the context to understand what’s safe to change, you’ve got two options.

Fully Rebuild

Pitch a full rebuild. You put together a business case with a timeline, a budget and reasons why starting from scratch is better. It’s the whole “I can do this better and 10x cheaper” attitude.

But leadership weighs the cost of rebuilding something that “already works but ‘better’” and usually the answer is no.

Add to it

Which leads to the more common option of just adding to it. No refactor, just keeping adding on to the existing codebase. And soon enough it becomes a house of cards because the intent and context of the tool was never communicated.

You’re too scared to modify the core, so you build on top of it. Workarounds, band-aids, adapters, all just to keep the tool running. But each one makes the tool a bit more fragile, a bit harder to maintain.

It’s like a garage you’re afraid to clean out, it’s easier to just keep stacking boxes than to deal with what’s actually inside. But eventually, you’re going to run out of space and have to deal with the contents.

Why this keeps happening

My theory is that it’s a misplacement of our attention.

People only care about a tool twice: when it’s being built and when it breaks. Everything in between is invisible.

The building phase gets all the attention. There’s a budget, momentum and excitement in the air. There’s constant updates on the tool and when it launches, people clap for it because it works and it’s finished.

From that point on, no one actively working on it and there’s no budget for maintenance. Maintenance doesn’t look like work. You can point at a new feature, a launch, a demo. But you can’t point at “keeping something running that everyone assumes just runs.”

The reality is that there’s no “finish” when it comes to tools. They still need to be documented, updated and maintained.

Part of me understands this because if you think about it from leadership’s perspective. They approved the budget. They gave someone time to build it and they’ve rolled it out. Success. The tool is done, so it must be working. Move on to the next thing.

Maintenance is not a full time job and it’s harder to justify it in your timesheet. Which is why it’s often just squeezed in with the other more pressing things. Well, until it breaks, then everyone rushes you to fix it.

What actually fixes this

The real fix here is the structure around it. Software developers, whose full time job is to deliver products to customers, have figured this out. And we can learn from them.

Document the assumptions, not just the code. Most handover docs explain how a tool works. What’s missing is why. Why this approach? What were the constraints? What depends on what? When assumptions are visible, the next person can make informed decisions instead of guessing. This is hard to do after the tool is done, the best way is to document as you build.

Give the maintainer real authority. If someone’s responsible for a tool, they need the power to act on what they see. That means either decision-making authority over the tool’s direction, or a clear escalation path that actually leads somewhere.

Treat tools as living systems, not finished products. A tool isn’t done when it launches. It’s done when it’s decommissioned. Everything in between is active work that needs to be planned for, budgeted for, and respected as real work.

None of this is glamorous and can feel like a waste of money. But it’s the key to long lasting tools beyond a single developer.

The hard part was never building it

Building an internal tool is exciting. There’s momentum, there’s a vision, there’s someone who knows exactly what they’re doing and why.

But that moment is temporary. The person leaves and the tool keeps running on assumptions that no one knows.

The hard part was always what comes after. Making sure the tool outlives the person who built it. Making sure the next person who touches it has the context to make good decisions.

If any of this sounds familiar, that’s because it’s happening at most companies right now. Somewhere in your organization, there’s a tool nobody’s happy with but is critical to how the company operates. What you need is a way to ensure continuity.

That’s the kind of problem I help teams solve. Not just building the tool, but ensuring that it doesn’t fall apart when the people change. If you want to talk about what that looks like for your team, reply to this email or book in a call with the button below.

Thanks for reading.

This is part 3 of the Winton Guest House walkthrough. The series:

• Part 1: Modelling the Fireplace, Living Room and Bedroom

• Part 2: Modelling the Garage and Loft

• Part 3: Modelling the Second Bedroom (this article)

• Part 4: Script Organisation

If you’ve read through Part 2, you now have five of the six structures in your script.

Hopefully, you’ve been building along and giving it a go yourself. Either ways, it’s time to show you how I built the last one.

Before we dive in, a reminder: the best way to learn is to try it and be uncomfortable on your own, then use this guide as a reference against your own. That’s the whole point of these guides.

Okay, without further delay, let’s start.

Read more

Fifteen script versions and 26 versions of the model.

No, not fifteen variations. Fifteen different scripts. And, 25 freaking new models. Each one was created because nothing could be locked down and “something more important” always kept coming up.

Ten months ago, it was the material, we changed from timber to steel. Then, the start of this year, we took out the bracing between the modules. Just last month, we went from 6 columns to 24 then back down to 20.

The best part? We were delivering in a construction stage. Which is typically when things should have been decided. We should be documenting for the actual construction not deciding on parameters.

Yes, it’s a complex project with many moving pieces. Yes, things change, we get new requirements. But somewhere around script number 8, we were no longer iterating, we were starting over again. And again. And oh, again. Oh, wait and again.

The false promise of “it’s just a script”

This client had been sold the dream that with scripts, you move fast even while changes were happening. You know, explore options, generate variations, instant turnaround, that sort of thing. And that’s technically not wrong. But it only works if the core logic of the workflow stays the same.

The videos you see on LinkedIn about sliding parameters and getting new models is true. But it’s not the full story.

There are an infinite number of ways to solve any given problem. So, to say a script can handle all those changes is an unfair assumption. It’s a good tool but it’s not magic.

When you see a model being generated by a script, the output might look the same, but the process is not. Which is why when someone keeps introducing changes without knowing the impact, it can mean the difference between sliding a parameter and rebuilding the entire script.

It’s why I focus so much on the intent of the script rather than the logic of it. With AI and tools like Grasshopper, it’s now possible to solve problems any way you like. What then makes a good workflow is one that focuses on the key principles of the problem. It’s one that aligns to the parameters that are important for the project.

If you’re building a tower and the floor area is important, the design your script around that. Or if you know the client’s data is never clean, trying to create a layer between them and the tool is safer than processing their raw data.

The point here is to identify the overall behaviour of the problem and distill that into rules for the workflow

There are a million and one parameters that you can tweak to solve a problem. You cannot create something that accounts for all of them. So, a good digital workflow is based on the vital ones and uses the rest as assumptions.

Not all assumptions are equal

So, if the problem is that changing assumptions breaks scripts, does that mean nothing can change? No. Things change all the time. That’s the very nature of projects.

But not all changes carry the same weight.

Any changes to the key principles will require a rebuild but “small” changes can be incorporated with little to no impact. The idea is to think of workflow variables as “hub and spoke”. Changing any “hub” parameters has a huge impact, possibly a rebuild. Changing a “spoke” parameter should ideally be accounted for or have little impact.

The point here is that we can’t have an infinitely flexible workflow if we want to make our (normally very) tight deadlines.

So the framework makes sense. But most of the time, no one knows which changes actually cause the most impact. The person asking for the change doesn’t know they’re touching something foundational. And the person who built the script never made that distinction visible. And to make matters worse, the person that accepts the change from the client isn’t always the person that built the script.

But it’s really a communication problem

That’s what this really comes down to. A gap between what the script assumes and what everyone else understands about those assumptions.

When I look back at this project, the pain wasn’t that things changed. It’s that we didn’t have a shared understanding of the impact of changes before it was accepted. No one knew what was priority and what other teams were dealing with. There was a lack of clarity.

The ideal scenario would have been, when there’s a change, everyone should know what that means for both a timeline and a budget point of view.

But even though it’s simple to say, it’s not easy to achieve. In complex projects, there are many teams and some politics that get in the way of clear communication. And understanding the downstream effects can be hard. A director I once worked with put it well:

“On a project, we’re building the plane and flying it at the same time”

It’s hard to understand the effects of our changes because we are trying to make sense of things at the same time.

But we have to try because the alternative is timeline delays, very late nights and budget blowouts. Putting in the work to clarify all assumptions and effects is one of the most valuable things you can do on a project.

So, how do we get better at this ?

The best way I have found is to communicate everything, and I do mean everything. And again, easy to say but much harder to achieve in practice.

It means letting your manager know what assumptions you are making in the script and why.

It means letting the client know your modelling process even when they think it’s not relevant.

And it means that every time there’s a change, you need to bring up why and whether the ripple effect is worth it

Currently, there is no good way to communicate all of this. People don’t read the documents being sent. Some meetings are so long and drawn out that most people don’t even pay attention. Even emails get conflated with people defending their own work or assigning blame.

These days I use a combination of Figma boards, live documents and AI meeting transcripts to try and keep everyone on the same page. I bring these to every meeting. I’ve even sent notes from internal meetings to clients explaining how their change will impact our timelines. That was an uncomfortable thing to do but it’s part of being open and communicating more. The one thing that I have seen some other companies do is play around with AI knowledge agents to help with this.

But, it’s still messy, most projects are. And half the time, I’m reorganizing everything while trying to keep up with the project itself. But it’s better than having all those assumptions in your head and then having them sprung on you at the worst time. And how you do it isn’t really the point. The conversation and clarity is the point. The act of sitting down and saying “if this changes, here’s what it affects” is extremely valuable.

And it doesn’t prevent changes. It just makes the cost of those changes visible before someone assumes it’s a quick update and agrees to it.

Communication is always messy

If you are extremely busy, communicating your needs and impacts is hard. It’s likely not even on your todo list. Leveraging AI has been helpful but it still requires your time and when your deadline is tomorrow, I know every minute counts.

With so many moving pieces, different teams involved and let’s be honest, politics. Being transparent about everything is almost impossible. And trying to do this within a live project time frame makes it even harder.

But this communication debt is something that we don’t talk about enough. We spend so much time learning the tools, Grasshopper, Dynamo, Python, and not enough time learning how to make the assumptions behind our work visible to everyone else.

A vital skill here is knowing which parts of the project hold everything else up, and making sure the people around you know that too.

Fifteen scripts taught me that. Hopefully you won’t need that many.

If this sounds familiar, or you’re in the middle of a project right now, I’d love to hear about it. Reply to this email, or if you want help thinking through how your workflows handle change, book a discovery call.

As always, thank you for reading.

This is part 3 of the Winton Guest House walkthrough. The series:

• Part 1: Modelling the Fireplace, Living Room and Bedroom

• Part 2: Modelling the Garage and Loft

• Part 3: Modelling the Second Bedroom (this article)

• Part 4: Script Organisation

If you’ve read through Part 1, you now have the Fireplace, Chimney, Living Room and Bedroom in your script.

Hopefully, you’ve read the the brief and have been trying to model this on your own too.

Before we dive in, a reminder: the best way to learn is to try and solve it on your own, then use this guide as a reference. That’s the whole point of these guides. To give you a problem / project to anchor your own learning to.

Okay, without further delay, let’s start.

Read more

I’m on a call with Jack. We’re going through the analysis model for what seems like the 300th time.

“Try reducing the size there, oh and we need to ensure we have the right beam releases. Can you also just put in a simple truss here?”

I am frantically clicking away trying to keep up with the changes that “we” want to make to the model. After about 15 minutes of silence (which is a very long time on a call), I re-run the model and Jack unmutes himself.

“Okay, we are getting closer. Can you try reducing the loads on level 10 to see what happens ? Also, can you add a new freedom case in to mimic the stiffness of the floors ? Let me give you the spring values”

So, I do what he asks and this time, 20 minutes go by before we look at the model and try some other modifications again. None of these are big changes, they are Jack experimenting with different analysis parameters to get the model to work. It’s actually the kind of thing I do with my scripts and programs. He needs to see the results of all these changes to get a sense of the model and to know what to try next.

So, this is what an LLM feels like.

Nothing I do here is computational. Yes, I am learning a lot about what makes a good structural analysis model but is that really the best use of my time here? It might help me write better scripts in the future but right now I’m just clicking where I’m told to.

Jack knows exactly what he wants. He has the structural expertise, the intuition for what to test. . So why isn’t Jack just doing this himself?

Well he has no idea how to use the current program, so I become his hands because I made the script that created the model. And aside from this inefficient way of working, there are two things going on here and they’re easy to confuse because they look the same from the outside.

The wrong analysis program

This entire thing started because of the complexity of the model. Jack reached out because the geometry was impossible to do by hand.

So, I decided that Grasshopper was the best tool to generate the geometry. And at the time, the only analysis program that would work well with Grasshopper was a program called Strand7.

But, Jack was not a good Strand7 user. He knew how to extract data from it and spin the model around, but he could not use it well. I, on the other hand knew the program quite well because of it’s connection to Grasshopper.

Jack reassured me a few times that the analysis we needed to run was simple. It was a proof of concept and that everything could be done through the script. Not manual changing or prodding required. What he needed from me was an understanding of the geometry and some basic loading given his client’s constraints.

Well, the client loved it. But we never change analysis models. The Strand7 model is now really complex. Packed to the brim with freedom cases, restraints, beam end releases, etc. All done manually on the analysis side. In fact, there was little to no Grasshopper work anymore because all the changes and additions we made to the model were normal structural engineering changes.

It was at this point that we should have paused and re-evaluated if this hybrid of computational and manual approach was still the most effective way of working. Where it’s no longer a proof of concept but rather a fully featured structural analysis model that should be managed by someone else.

Because the amount of manual changes that Jack could have done on his own has surpassed the benefit of using Grasshopper. In fact, it got easier to define a split between scripting and manual fixes because we moved from geometry to analysis as the project evolved.

By planning that, we would have come up with a much more efficient way of working. Not to mention the experts in analysis would be able to make changes to the model without having to contact me all the time. I wouldn’t have been on hour long calls with Jack just for him to tell me where to click and what numbers to put in.

And if we ever wanted to bring some scripting functionality back in, I’m sure we would have found a way with Grasshopper. Maybe creating the model in Rhino, then importing it in and applying the loads. At this point, we should have stopped and re-evaluated our options and what it was costing us by staying with this workflow.

Accidental ownership

The second cascading problem to this is me “owning” the model.

Because it came from a Grasshopper script, everyone was asking me to make changes and review them. Me, the person that hasn’t done a lot of structural engineering work and has pretty much rote learned it by making tools for people. Combine that with the fact that Jack can’t use the program well and you have now made a bottleneck. You now have someone under qualified making changes in critical areas.

The ownership of the model became a by-product of using a script and from choosing the wrong analysis program. It’s the part that bothers me the most because accidental ownership is the kind that’s hardest to undo. I can’t one day just say that I am not making changes anymore.

And this isn’t a one-off. I’ve seen the same thing happened a few times. There was this one tool that I build in Grasshopper to run vibration checks and suddenly, I am the “vibration guy”. Everyone came to me for help on why their models weren’t working or why they didn’t get the results they wanted.

just because I made it, I suddenly own the space surrounding it

In both cases, I ended up owning something that should live with someone else.

Hindsight, and the uncomfortable conversation

Maybe it’s the hindsight bias talking, but I should have pushed back more. I should have had this conversation with Jack and ask more questions about ownership and process. Things like who makes the manual changes, should we change programs, or do we need another engineer to help us.

It would have meant asking questions he might not have been ready for or might not have known the answer to yet. “How complex do you think the analysis side will get?” is not a question anyone wants to hear when they’re just trying to get the geometry into a model.

And the real skill is knowing when to introduce friction. When to set boundaries with people.

Pushing back when you’re given work is uncomfortable in the moment. Especially when you always want to go a good job with people. Pushing back creates the friction that slows things down when everyone just wants to get started. It’s hard to be that reason things aren’t moving as quickly.

But the alternative is hundreds of long calls where I am just clicking where Jack is telling me to.

When you’re too busy to set boundaries, that’s when you need boundaries the most.

If you’re about to kick off a project and you’re not sure how automation or computational stuff will fit in then that’s the kind of thing I help people think through. Reply to this email or book a discovery call. Even if it’s just to talk it through and nothing comes out of it, the conversation is free.

This is part 1 of the Winton Guest House walkthrough. The series:

• The Brief

• Part 1: Modelling the Fireplace, Living Room and Bedroom (this article)

• Part 2: Modelling the Garage and Loft

• Part 3: Modelling the Second Bedroom

• Part 4: Script Organization

If you’ve read through the brief, you now have everything I had when I first started. The reference images, a sense of where the six structures sit in relation to each other, and my modelling approach.

Hopefully, you’ve given it a shot or are in the process of trying it yourself.

Either way, it’s time to show you how I built this.

Before we dive in, a reminder of the principle I want to keep coming back to throughout this whole guide: the best way to learn is to try it and be uncomfortable on your own, then use this modelling guide as a reference against your own. The whole point of these guides is to give you context and a problem to anchor your learning.

Okay, without further delay, let’s start.

Read more

For some reason, I am getting a phone call from Jay.

He’s a client I’ve built a few Dynamo scripts a couple of months ago. The project went well. We solved all the problems, tested the scripts and trained the team on how to use it. I even wrote some documentation for them too.

You know what, I think he’s got a new project for me. You know what they say, when you do good work, good work finds you.

I picked it up and heard his voice come through.

“Hey Braden, the scripts you made for us aren’t working anymore. I swear we followed everything you showed us in the workshop and it’s been working well but it’s now broken.”

Well, that’s not the call you want on a Thursday afternoon.

“That’s weird,” I said. “Are you free for a Zoom call in about an hour? Share your screen and we can go through it ?”

“Yep. See you then.”

So I finish what I was doing and jumped on the call. Jay shared his screen and showed me what was happening. He’d open the model, open the Dynamo script, hit run, and Revit would freeze and soon after, it would crash.

The perfect problem, no error message or warning, just… dead.

Maybe it was the model, so we tried again on a blank model. Same thing. A freeze and then crash. Okay, maybe it was the one of the plugins they had installed. Maybe it was….

This cycle of testing a hypothesis, then crash, then another hypothesis turned the call into 2 hours of agony. For each hypothesis, we had to wait for Revit to restart and well… nothing is more awkward than sitting with a client in silence hoping praying that it will work the next time.

To make things worse, all the hypothesis didn’t work. So, instead of wasting more of Jay’s time. I asked him to send me the model and the script so I could debug it on my end. At least, I didn’t have to keep telling Jay where to click. But he needed this done by Friday and it’s Thursday afternoon.

Once I got the files, I opened the model, loaded the script and hit run.

Do you know what’s worse than things breaking for clients?

It working for you.

I didn’t have any problems, the script ran fine for me. No crash or freezing on my end.

I ran all the scripts across every relevant model I could find from our testing period. And it all worked, nothing was wrong. Maybe there was a setting on Jay’s computer that was causing it. So I shut Revit down, wanting to send him another email, requesting for a call. Mind you, it was 6pm on a Thursday.

That’s when I noticed Revit had an update waiting.

So, I updated it and just just to rule it out, I ran the script again.

And….. shit.

That was the catch. It froze and crashed, just like on Jay’s computer.

It was Revit (If you know Autodesk, this isn’t surprising). An update had broken something in Dynamo. I then spent the night re-writing all the scripts to account for whatever the update had changed. That just meant starting from scratch again and trying to copy the functionality of the old scripts.

It took me about four hours and two cups of coffee to get it done. But on Friday morning, I jumped on another call with Jay and his team. I shared my screen, showed them the new scripts and explained what caused the issue. We tested it on their models, walked through it together, made sure everything was working.

The thing nobody tells you

When I called Jay a couple of weeks later to check in, he was sympathetic to what happened. He was forgiving because he had used the scripts before and it had always pulled through for his previous projects. But when I pushed a little more in the conversation, there was some hesitation.

“So what happens with the next Revit update? Should I call you first? Should we test it on one computer before asking everyone to update? Maybe we’ll just have to run this with a bit more time to spare next time”.

These are questions you start asking after you’ve been burned. When you’re less confident in the tool delivering well. Before that Thursday, Jay didn’t think about any of this. Now he’s worried that an update might break the scripts again. He’s worried that he and his team have to stay late if I wasn’t available.

And if I were Jay, I’d feel the same way. You start second guessing things. Maybe things aren’t as solid as they seem. Maybe next time you run the scripts, you try a small portion first. Or maybe you save a version of Revit on a computer and never update it.

And even on my side, it’s a horrible feeling. Apart from the loss in trust, I didn’t get paid for that extra time (and stress). We were just lucky that I was relatively free that day to handle this emergency fix.

It’s a lose-lose situation, I stay up late fixing something that was stable before and Jay loses some trust. All because Revit decided to push an update.

The reality of building on another platform

But no amount of testing and planning could have predicted this. Dynamo relies on the Revit API, and the Revit API changes when Autodesk decides it changes.

That’s the reality of building on another platform.

And that’s the part when I don’t see people talking about, the maintenance of these tools.

No single tool is a once-off investment. Things in the world keep changing. Revit will update again and that means, some tools will break. The skill then is how you handle the change, not trying to prevent it. That’s why I always say that maintaining a tool is just as important as building it.

What should have happen with Jay, is that when Revit releases a new update, we re-test the scripts again in a non-project timeline. Ensuring that things are still working, if it’s not, then we plan again about how to best fix the scripts and maybe add any missing features we couldn’t before.

Why I take this so seriously

I’ve been on the other side of this too. I’ve depended on tools that have failed me in critical moments. When no one is around to help and you have something to deliver in 4 hours, you plow through it manually because it has to be done.

So even though I make the tools, I understand why people are hesitant to adopt new ones. It’s horrible, being left alone when something you depend on breaks. But the answer is to not avoid tools, it’s to be on top of the changes and handle them well.

So what do you actually do about it?

During development, I still test things thoroughly. I still write documentation and run workshops so everyone knows how things work and why. By the time I hand something over, it’s been put through its paces. Everyone that I work with should have a good understanding of the behavior of the tool. In fact, they should feel confident in it’s robustness and quality.

But testing, in all its glory, cannot simulate a Revit update that hasn’t been released yet. It can’t predict which API function Autodesk will change six months from now.

And that’s exactly why I offer what I call Hypercare support. It’s a retainer for small features, changes and any critical bugs that come up after deployment. It gives you someone to call when things go wrong, someone who already knows the scripts, knows the dependencies, and can diagnose the problem without starting from scratch.

I do this because I can’t predict when a Revit update is going to break something. Nobody can. But I can make sure that when it does, I’m at least available to hop on and fix that error.

If I’d scoped that into Jay’s original engagement, the Thursday night rewrite wouldn’t have been unpaid. And more importantly, Jay wouldn’t have spent two hours watching his screen restart wondering if he’d made a bad investment. He would have just called me, and we’d have handled it. Not to mention, everyone would have been less stressed.

That’s why you’ll never see me saying automation is easy. Because the building part is “easy”. It’s the part everyone on LinkedIn shows. But hardly anyone shows what comes after that. The maintenance, the support and bug fixes when other stuff changes.

Okay, that’s it from me.

If you want to talk through whether automation makes sense for your project, or if you’ve already built something and want to make sure it’s supported, I’m always happy to chat. Reply to this email or schedule a call. That conversation is free.

Previously, I wrote about why learning with a real problem in front of you is different from any tutorial. But it’s not good enough for me to just say “go find your own problems to solve”. So, this is the first article in rectifying that.

It’s the start of me giving you a real problem to work with in case you don’t have your own.

Below is everything I had when I started modelling the Winton Guest House. Treat it as a brief. If it helps, think of it as an assignment. Go through the reference images, do some googling of your own and read the modelling approach I have taken.

Then, when you’re ready, start modelling it on your own.

Yes, I know that can be scary and it can be overwhelming but that’s part of the process and the learning. The struggle is how you earn to look at something and build a Grasshopper script from it.

Then, when you are truly stuck or maybe you’ve made your own solution, reference it to mine. In the coming weeks, I’ll be publishing a modelling guide that shows the script I made. It’s my answer to the brief.

The Winton Guest House

It consist of six distinct structures, each with its own type of geometry.

To make sure we are on the same page, here are the names and locations of each structure:

And the plan view, which, to me, is the most useful reference for setting out the geometry:

If you do need more information, you can always find them online.

My (recommended) approach

When I look at a building I have never modelled before, I am not thinking about the architecture. I am looking for the logic. Where does this start? What depends on what?

The Winton Guest House has a clear one to me.

The fireplace is the anchor. Everything else in the script works from it in some way. The chimney grows out of the fireplace. The living room grows out of the fireplace. The garage grows out of the living room. The loft sits alongside the garage. The second bedroom is the last piece to slot in.

Of course, if you do want to start from another building like the living room, please feel free to

Once you see that flow, the model becomes one problem with six big steps, each one using what came before it as its starting point. That order is why the guide starts with the fireplace rather than whichever structure looks most interesting.

The fireplace is really just a box with another taller box on top that makes the chimney. The roof of the living room is a trapezium and the rest are also combinations of simple shapes with the exception of the bedroom. So, leave that for last. And if you get really stuck on that, part 3 of my guide will show you how I did it.

Start now, don’t worry about perfection

You do not need to get everything right, and you do not need exact dimensions. Focus on the relationships between the structures rather than precise measurements. What we want from these modelling challenges is for you to build the instinct of creating your own workflow and pulling components to solve problems.

When you are ready to compare notes, or when you hit a wall, the modelling guide is split into four weekly parts:

• Part 1: Fireplace, Living Room and Bedroom

• Part 2: Garage and Loft

• Part 3: Second Bedroom

• Part 4: Script Organisation

Each part has a script file so you can check your work section by section. Part 1, starts next week.

But as you go through it, remember that my approach is just one way. There is no “ultimate“ way to model this. But we all have to start somewhere, so if your script differs from my guides, it’s okay. We’re just getting the reps in.

Happy scripting!

There’s this satisfying feeling that happens after you finish a tutorial or a lesson in a course.

You know what I mean. You’ve watched the whole thing, maybe you’ve followed along, maybe you even took some notes. After that, you’ve definitely mastered “data-trees for Grasshopper”.

So, why is it that when you open up Grasshopper on your own, the only thing you can do is stare? You should have mastered this, you watched the tutorial. You even took notes. But all you have are more questions.

What components do you use ?
How do you even start, a point ? a curve ?
Where’s the list to graft ?

If any of that sounds familiar, it’s because it’s the classic “I don’t know how to apply what I’ve just learnt to the real world” problem. That’s why even after 4 years of going to Unviersity, most people will still treat graduates as “starry eyed fledglings”.

I have written about this a couple of times now. One piece was about why I would learn Grasshopper differently if I started over. Another, was about the moment the tool finally made sense to me. And this one was about why learning through tutorials only won’t get you very far. I even made a LinkedIn post about it.

The TLDR of all of them is that tutorials and online courses teach you what the components do and where they are. But they don’t teach you how to use them to solve real world problems. That part only comes from getting more experience.

The responses I got from those pieces told me that a lot of people understand this. They have done the tutorials. Understand the material in the moment. And then nothing transfers to their jobs. They can take every “masterclass” under the sun and still feel like they are starting from scratch every time they open Grasshopper.

Context is key when learning

I got lucky because my job at the time gave me context while I was learning Grasshopper for the first time. I had a real task with real deadlines and a real manager to hold me accountable. He was also a manager that would occasionally pull up a chair when I was completely lost and say, here, think about it like this.

He gave me direction, so that I wasn’t completely lost. He gave me some breadcrumbs to follow. But I still had to find my way there. It was still up to me to learn the right techniques to solve the problem.

I did end up learning the fundamentals of Grasshopper though. But not because a course told me to, because it was the only way I was going to solve my problem. I had to learn about data-trees because my situation demanded it. I wanted my scripts to work well and for that, the fundamentals are important. But doing it for the sake of doing it is how you get so bored that you rather run into a wall.

Learning in context is different to your regular online course or tutorial. Because it means you have to intentionally get lost and find your way back on your own. Which can be an extremely uncomfortable feeling, especially if you’re paying for a course to be reassured you’re on the “right” path. It’s weird to say “I am buying this course to feel lost and find my way back”. It’s much easier to buy a course that spoon feeds you problems and answers.

But all you’re doing is accumulating carnival cash. It feels great in the moment but means nothing in the real world.

The part that is hard to replicate

The problem is that most people learning Grasshopper today don’t have access to their own problems. They have jobs, but Grasshopper is not central to them yet. Or they are students, or they are trying to upskill before a role that needs it. They can’t find their own context to make the learning stick.

Telling you to find your own problems doesn’t help if you don’t know what can be done. It also doesn’t help if it’s too overwhelming to go through it on your own. I even made a course on how to find your own problems but it still doesn’t help if you are very new at this.

So, I have been trying to figure out how to give someone that project experience if they don’t have one? How do I structure a problem in a way that is not too overwhelming, that challenges you and still gives you enough direction?

The inspiration of modelling challenges

That is what I am trying to build here. A series of modelling challenges that give you that context for learning and forces you to come up with your own workflows.

Okay, why modelling?

For starters, I think it’s the most common use case for Grasshopper. I also think it teaches you the most about how the tool works. From there on, if you wanted to branch off to urban analysis or optimization, it’s not a huge leap anymore.

I know how overwhelming that all sounds. But the point here is to challenge yourself to come up with your own way of solving problems. That’s how you build that instinct.

So, if you’re interested in getting some reps in for Grasshopper or you want hone your skills, I encourage you to join me.

We are going to start with a model brief which is basically summary of what you are going to start modelling. In the brief, you’ll have reference images, how I would model it and also what to look out for. Then, you just have to start.

But I did say that to learn effectively, you also need direction. Which is why after you’ve tried or if you’re feeling extra stuck, I’ll be publishing a modelling guide too. It’s basically my “answer” to the brief.

It’s not like I am giving you a problem and then leaving you alone. I am going to solve it too and show you how I did it. Mostly for you to reference and compare against your method. The key here though is that you have to try and solve it on your own first.

P.S. if you’ve never opened Grasshopper before, I’d suggest going through my primer in Grasshopper first to get up to speed on the basics. It’s only six lessons and it gets you to the point where you can read a script and know what you are looking at. Start there and come back.

What we are working through

Starting tomorrow, I am introducing the first building we are going to look at: Frank Gehry’s Winton Guest House, completed in 1987. It’s six distinct structures, each with its own geometry.

I chose it deliberately because it is complex enough to be challenging. But it also has a quality that I think makes it a good teaching vehicle, there is a clear logic to the order of things. Each part of the building follows what came before it.

The brief will walk through what the building is, how I see the building in terms of “plan of attack” and how to approach modelling it. Think of it like a mentor giving you a task and some direction and your job is to use Grasshopper to solve it.

From then on, there will be four parts to the guide, published every Tuesday for next few weeks. Each guide also comes with a script, so you can see how the solution progresses along with my thinking. And they are all available for paid members of CodedShapes.

If you are on the fence about subscribing, this might be a good chance. You can always subscribe to learn from it and then quit after you got what you needed, no hard feelings at all. The pool of resources will always be here.

Closing thoughts

Learning in context is one of the most effective ways I’ve found to learn. After going through it, it’s hard to imagine ever sitting in a classroom or a tutorial learning for no reason. With anything that I am trying to learn (Grasshopper or not), I always anchor it to a problem/project.

This though, is a much harder way of learning and the effort you need is a lot higher than just kicking back and watching tutorials. Just be mindful of that. But that is the point of all of this. I don’t want you to memorize things for the sake of it, I want to give you a reason and some meaning to it.

The first model brief is now live!

Check it out here :

I was part of a digital team that built an analysis tool for a project.

It managed data between a main model and many sub models for structural analysis. The idea was for each engineer on the team to work on their own model, then use our tool to combine everything into a single main model. It made modelling collaborative which if you know how analysis programs worked, was a big deal. Most, if not all analysis programs only allow one person at a time.

That meant the project team could put almost every engineer (junior to senior) on the modelling without having to copy and paste between models. This was actually where most of the errors and problems come from. People model the paste the wrong thing or they accidentally delete something important in the main model.

But with our tool, a click of button would solve all of that. You’d get a team-built and expertly led analysis model as many times as you needed.

It was so good and we wanted to present it to other project teams. The hope was that they, too, could experience the future of modelling through the same system. Even though our tool only worked for this project, it wouldn’t have been hard to tweak it for others. In fact, with enough motivation, we could build the same system for everyone. We were creating collaborative editing for models

So, present we did. Hoping to get more interests and ideally, more funding. For 30 minutes, everyone watched us explain this magical process. Parallelize the modelling, click this button, and have all your complex analysis woes solved.

At the end of it, all I could think was: “This is why no one trusts us.”

Because the truth hurts

The tool actually made the project worse.

The one-click reality was people still had to manually copy and paste between models. The very thing the tool was designed to prevent. But now, they also had a tool that would get it wrong, so sometimes, they had to spend even more time cleaning up after the tool.

To make things worse, after we made the tool, there was also a period where the original developer who built the tool was on leave. He didn’t give any handover notes or access to the original code. So, when the tool broke and there was no one around to fix it. I helped out the project team by also manually copying and pasting between models. Not fixing the tool, actually placing lines and copying numbers. Again, the very thing the tool was designed to prevent.

Before we showed up to this project, the team had a workflow. It was manual, error prone and slow, but it was theirs. They understood it and knew exactly what to do. Now, they had a tool they didn’t fully understand, that occasionally saved them time and occasionally broke at the worst possible moment. So, they ended up with a workflow that was slower, more error prone than just doing it manually.

Now, imagine you’re a manager. You’ve been promised that you get a tool that would almost half your turnaround time. What do you tell the clients?

Well, you tell them you can do it faster.

Which is exactly what made the deadlines of this project so tight. The team was depending on the tool working. They’d planned a tighter turnaround because the tool was meant to handle it. But because the tool broke so often and the team weren’t available, they dug their own graves. They had to work long hours to make up the tight deadline that the tool was supposed to prevent.

And after everything, we still presented it to everyone like it was the next best thing since sliced bread.

I bet the project team were laughing at us during the presentation. They would never work with the digital team again. I mean would you ?

That feeling must have bled to the other teams too. Because as “game-changing” as our tool was, no one reached out to us. I swear we looked like clowns up there. The tool also never saw the light of day again.

We sold the dream, not the reality

The thing that bothers me most about that presentation isn’t the overselling. It’s the eroded trust with the team.

The project team trusted us. They built their entire schedule around it. They told their clients they could turn things around faster. They took on tighter deadlines. They made commitments based on our promises.

They basically believed that we would together to deliver a product that was better than the sum of it’s parts. And we let them down an threw them under the bus.

And while they (and I) stayed late delivering the project while the tool broke, we still stood up there and called it the best tool.

That’s no longer overselling, that’s taking someone’s trust and using it against them.

I don’t blame people for not trusting the team again.

Then we disappeared

But the biggest crime isn’t the broken tool. It’s disappearing after you’ve sold the magic. Especially when people have build their deadlines and budgets around it actually working.

The guilt from this project still stays with me.

There were days where the project team needed help. The tool broke, which was common, but our team had moved on to other things.

I remember our replies all fell along the lines of: “Yes, that’s a bug, but I’m busy. I’ll get to it in 2-3 days.”

But they had a deadline tomorrow. So they stayed up that night doing things manually. And eventually, they stopped asking.

The kicker? When we finally had time to look at it, we’d say something like:

“Oh, you shifted the geometry. Our tool doesn’t support that. So, you broke it.”

The tool broke and we didn’t fix it. They still had a deadline, so they fell back to the manual way to get it over the line. And then, when we did have time, we blamed them for breaking the tool that we made.

If that happened to you, how hard would you kick us?

Two sides of the same coin

Of course, it’s not always this one-sided. There have been times where there are bad inputs or assumptions. Or people try to use the tool outside it’s design and expect it to perform magic.

But the common piece on both sides is trust and reliability.

Trust goes both ways. You need to trust that the tool will consistently deliver. And I need to trust that you’ll use it within the agreed conditions.

Reliability also goes both ways. Before I completely handover the tool to you, we have to ensure that it’s tested well and that you’re confident it works the way you need it to. Of course, there is another piece that when something breaks after, I’m there to fix it, not leave you hanging.

If you can’t trust or rely on the digital solution, then nothing will go well.

We have to align on the direction

I still think computational design is worth it. I wouldn’t be writing this newsletter if I didn’t. The time savings are real, and the problems we can solve now are genuinely amazing. And the whole idea is to build something better than the sum of it’s parts.

But we need that trust and reliability on both sides first.

We can’t sell magic and then disappear when it breaks. And we can’t expect our tools to solve every problem when the only instruction was “fix it for me”

The way to close that gap isn’t to be more impressive. It isn’t to use more AI. It’s to be more reliable and honest about everything we make, like what it can do, what it can’t, and what happens when it breaks.

Thanks for reading.

If you’ve used Grasshopper for anything remotely complex, you’ll know how annoying it is when you open the script and forgot to lock your canvas.

Even worse is if you’ve forgotten a stream of components that take a lot of time to run and you accidentally “resolve” the canvas.

Obviously, I’m speaking from experience here.

A small but vital component is the False Start Toggle.

It looks like an ordinary Toggle but defaults to False all the time. That means when you restart your script, the value of the toggle will be False.

Now, why?

Well, like a data dam, that means you can actually choose when to run things in Grasshopper instead of having it run all the time.

The biggest difference between the false start toggle and a data dam, is that I don’t have to click on it every time. I just have to do it when I restart my script.

Where to find this ?

Like most things, it’s a plugin and it’s actually part of the entire suite of components in LadyBug.

Which yes, I know it’s annoying to install the entire suite of tools just to get the False Start Toggle. So, I’ve actually separated it out for you.

I’ve attached the standalone component file below. You can drop it directly into your Grasshopper libraries folder without installing anything else.

→ Get the False Start Toggle here

I hope that helps.

Thanks for reading.

About a year ago, a site coordinator came to me with a request. Let’s call him Marcus.

He was confident, specific, and he knew exactly what he wanted. That’s actually a rare case. Most of the time, people know they have a problem but they don’t know what they need to solve it.

Marcus wanted a script that colours panels in a Revit model based on their installation status. His company was installing panels across a few storage warehouses and he wanted to know the statuses of the panels. The current workflow was every day, contractors on site would update an Excel sheet with that status. Marcus would then review that status but it was hard to know where those panels actually were. I mean they had IDs but how do you know where those panels actually are ?

So, he wants a script to read it and update the colours in the model.

I remember thinking, oh, this is straightforward. He’s already done the thinking, I just need to build it. The problem was clear and the solution made perfect sense. We signed. And a week later, I showed him the script.

Marcus nodded. “Yeah, that’s cool and all, but how do I see what the panels the contractors last installed? I need to see if we are on schedule”

I replied, “Uh.... you don’t. This reads the Excel sheet and colours the model. Like you wanted.”

“Okay, but I need to see which panels were installed before and which are installed today”

It turns out what Marcus actually needed was a way to retain the history of installation not just show the status of the panels. He wanted to see movement and statuses over time, not just update the model with the latest information.

The script worked perfectly. It just solved the wrong problem.

It would have been easy to blame Marcus for not communicating properly. But I also never asked why he needed to see the install statuses in the model. I didn’t ask why he wanted that information. He only told me after seeing the script for the first time.

I got lucky though. The rework was a straightforward addition. But if Marcus had wanted the site contractors to run the tool, or if there were more complex requirements buried in that brief, I would have been rebuilding from scratch. And I would be having an awkward conversation with Marcus about the fee.

Walking Into the Middle

This is, unfortunately, a more common experience that I would like.

Digital projects almost never start from a blank slate. Normally, someone already has some ideas about what should happen but they may not communicate that to you because it’s “common knowledge”. And if we take them at face value, we might end up building something completely off the mark.

I remember another time where I walked into the middle of a client’s political debate to switch from using Solidworks to Tekla Structures. I was told to write two proposals for two different programs because they wanted to understand the impact of switching programs.

To them, it made sense. Get the expert to vet the processes and then figure out which is the better option. But they wanted two proposals written up in a week without any additional meetings. They said “it’s all common sense”, so this should be easy.

But I am not apart of their processes, what may seem like common sense to them are assumptions and decisions that I don’t know. So, it was damn near impossible to come up with accurate requirements.

There’s always more than meets the eye

The better the work looks, the easier it seems. And the easier it seems, the more likely you will build the wrong thing.

“Just add this” is never just adding a feature. If something sounds too good to be true, we have to stop and assess whether there are any other hidden complexities behind it.

Of course, we won’t be able to predict everything but we can’t be too reductive about complexity. Especially, when we aren’t steep in their environment.

It takes two to build the right thing

I had another client who wanted a plugin in Tekla. The brief was was also clean, go from a quotation spreadsheet to a 3D model. And their instinct, like Marcus’s, was to fast track things. Give the fee, the timeline, approve it, and let me handle it.

After having learnt my lesson with Marcus, I reined it in and asked more questions.

It was uncomfortable because it seemed like I was skeptical but it was actually because they didn’t have a clear picture of what a Tekla plugin meant for their workflow. I was worried that they were developing their workflow and plugin at the same time, which is never a good idea. A good plugin needs to be embedded into a process not a new one.

After some pushing and prodding, we finally agreed to a discovery phase first. We went through the spreadsheet together. We explored what deployment would look like. We even checked if another program was a better fit.

And two things came out of that phase that we couldn’t have found on our own.

First, they were already working on a new version of the spreadsheet. If I’d built the plugin to the existing one, it would have broke within months.

Second, they had only one Tekla license, which meant only one person needed to run it. That cut the deployment complexity significantly because I didn’t have to worry about company wide IT policies yet.

We ended up waiting two more months to build the plugin. And, I’m glad that we did because it ended up being more stable and much closer to the workflow they wanted. The overall delivery was slower but it was more intentional and more valuable to everyone.

You want a discussion not instruction

The best tool or script isn’t one person building exactly what the other person asked for. If you want that, LLMs are getting really good at that.

It’s actually, two people figuring out what should actually be built given the situation and the problem.

That starts with a client who’s willing to share the context, not just the brief. And a digital person who’s willing to ask, not just build.