People assume I’m a programmer. I’m not. But I’ve spent two decades working alongside them — reading their code, thinking about systems, talking shop without embarrassing myself.
The most useful things I picked up from programmers have nothing to do with writing code. They’re ways of thinking. Ways of looking at problems, at systems, at tools. And I’ve been practicing most of them since I was a kid — long before I knew what programming even was.
I’ve been cataloging these thinking skills, and so far I count eight:
- Decomposition and future-proofing
- Debugging
- Intolerance for things that suck
- Abstraction and pattern recognition
- DRY thinking (don’t repeat yourself)
- Reading the error message
- Edge case thinking
- Rubber ducking
This post covers the first two. More on the rest in future posts.
My dad’s garage
My dad paid his way through college fixing the cars of other students and teachers. He always worked on our family’s cars. And when I got my first car, the first thing I had to do was learn how to work on it.
That meant learning how the parts relate to each other. What depends on what. What happens when one of them fails.
I could go to AutoZone, pick up an owner’s manual, and sit there reading it. Sometimes I did. It was interesting to see how the thing was intended to work - what the people who built it had in mind. Think of it like an onboarding doc for a piece of machinery. Most people never read the owner’s manual. They just use the handful of buttons they know and ignore the rest. I’d be willing to bet 90% of their car, they have no idea how it works.
I wanted to understand all of it. And then I wanted to go one step further: what happens if part of it goes away? If it breaks, if it malfunctions, if something needs to be replaced.
There’s a kind of causality in physical systems - and digital ones - that I just got a chance to experience from an unusually young age.
And I loved it.
Programmers call this debugging. They talk about it like it’s a technical activity - finding errors in code, tracing logic, reading stack traces. But at its core? Debugging is just deductive reasoning. Something is broken, and you’re going to figure out why - even if you don’t know how it works yet.
I learned it from my dad. It had nothing to do with computers.
The dead hard drive
We had a PC in the basement. I was the main person who used it. And when it stopped working one day, I did what made sense to me. I walked to the neighbor’s house, used their computer, and did enough research to figure out the hard drive had failed. I got a parent to take me to the store, bought a new one, figured out how to install it, and got the computer running again.
If I’m looking at a problem, I don’t have to wait for somebody else to solve it just because I don’t know how yet. A little research and a safe amount of experimentation can get me there. And once you figure that out, the question changes. It’s no longer “can I fix this?” It becomes “what else can I figure out?”
So I got good at fixing my computer. Which meant I got good at fixing other people’s computers. Which meant the teachers in school - the ones who were supposed to be teaching us about technology - started coming to me for help.
They didn’t want to admit it. But you could tell they knew. They had the vocabulary from the textbook, but they didn’t know how to think about what they were teaching.
They knew what the words were. They didn’t know how to think.
I resisted programming in the truest sense until college, when I got my first web development job and fell in love with making things on the internet. And then I fell in love with open source, because it was all the same thing. Learning how a system that influenced the world around me actually worked, so that when I ran into a problem, I had the means to at least understand it. Maybe ask better questions. And in some cases, actually solve it myself.
Fixable vs. replaceable
I watched a friend’s laptop slow to a crawl. She’d been dealing with it for months. When I asked if she’d tried to figure out why, she said “I’m probably just due for a new one.” The hard drive was 90% full of old photo backups. Fifteen minutes of cleanup and it ran like new.
She’s smart. She runs a business. But somewhere along the way, she’d picked up this idea that when something stops working, you replace it. And honestly? Most people have. Something breaks? Buy a new one. Software glitches? Work around it. The default is to give up on understanding and reach for a credit card.
And here’s the thing: when you assume everything is replaceable, you stop trying to understand how things work. You stop building the muscle that lets you diagnose a problem and fix it yourself.
Programmers don’t do this. Something breaks, they read the error, trace the cause, patch it. They don’t throw it away and start over. Well, most of the time.
And now AI has made the “fix it” path dramatically shorter. I used to have to take a picture of serial numbers and model numbers, Google a bunch of stuff, browse around and hope I could find a downloadable PDF manual on some manufacturer’s website. Now I can describe the problem in the clumsiest terms I have and in a few minutes the little research robot comes back with something useful. Sometimes I don’t even know the right question to ask. I just describe what’s happening and it gets me to the next place on the board.
It’s not solving it for me. But it is helping me put the pieces together. And you still need the instinct to look at a broken thing and say “I can figure this out” instead of “I need to call someone.”
That instinct is debugging. And it works whether you wrote the code or not.
When your tools lie to you
Programmers have strong opinions about their tools. Really strong opinions. But I think at the root of it, it comes down to the fact that because programmers understand how tools are built, they have a certain kind of expectation - and skepticism - that most users don’t. They know what’s possible. So they’re less willing to accept what’s broken.
At Indy Hall, we use a piece of software that manages our coworking space. Within its category, I do believe it’s one of the best options. The problem? It’s the best of a bunch of terrible options. This tends to be the case with any niche industry software. It’s a combination of economics and behavioral patterns - the people building these tools aren’t heavy users of them, and the cycle just reinforces itself.
So I’m frustrated with this software basically every day. We’ve been using it for years. Switching would cost a lot of time and money, and the alternative would probably be just as bad, in different ways.
Recently we hit a bug that is, objectively, a bug. They can deny it’s a bug all day long. The interface lets you do a thing. It says it succeeded. But it didn’t.
That’s a bug. I don’t care what the vendor calls it. If the UI tells me something worked and it didn’t, that’s broken.
I said to the support person - who was genuinely good at her job - “I have to ask, do other people complain about this?”
The answer was effectively no.
There’s only two ways that can be true. Either other people don’t use that feature - possible, but hard to believe for something this basic - or other people just deal with it. They assume they’re doing it wrong. They assume it’s their fault. Or they assume that’s the way it is and it’ll never change.
Because I think like a programmer - because I understand how things like this get built - I look at that and go: I would be ashamed to ship this. I would be embarrassed if a customer found it. And now that AI makes it possible for me to actually build a replacement, that intolerance isn’t just a feeling anymore. It’s actionable.
So we’re actively building a replacement. An internal tool. I do not want to run an internal tool. It is the last thing I want to do. But my tolerance for other people’s software is at the floor right now, and sometimes the only way forward is to build it yourself.
Most people just accept it.
The cost of accepting it
Every time you work around a broken feature, you’re absorbing a tax. One workaround takes thirty seconds. Doesn’t sound like much, right? But thirty seconds, three times a day, five days a week, for four years - that’s over 500 hours of your life spent compensating for someone else’s broken software. Which means you’re slower. Which means you’re more frustrated. Which means you’re more likely to make mistakes. And eventually you forget it doesn’t have to be this way, because the workaround has become the workflow.
I see this at Indy Hall with our own members. Someone mentions a friction point with a tool they use every day, and when I ask how long it’s been like that, the answer is always some version of “oh, forever.” They stopped seeing it as a problem. It became furniture.
I look at these things differently because I understand how software gets built. I know what’s possible. I know what “good” feels like. And the gap between what exists and what’s possible? It’s usually not a technical limitation. It’s that nobody pushed back.
You don’t have to be a programmer to develop this instinct. And your tolerance doesn’t need to be as low as mine - that level might be its own kind of problem. But somewhere between “I accept everything” and “I’m building my own replacement software out of spite,” there’s a sweet spot where you start noticing that frustrating is not the same as normal.
If something sucks, it’s probably not your fault. It’s somebody else not doing their job. And depending on who you are and the buying power you have, the best thing you can do - for yourself and for everyone else who uses that tool - is tell the people who built it.
Stop suffering silently.
What’s next
I learned debugging from my dad’s garage. I learned intolerance from years of knowing what good software feels like, and refusing to pretend bad software is fine.
Those are two of eight thinking skills I’ve picked up from programmers. More on the rest in part two.