Solve It Once

What a naughty little beast can teach us about eliminating technical debt from our code and our lives.

I have an awesome little Manchester Terrier named Sam. She's the best dog a guy could ask for. Good with the kids, isn't yappy or annoying like most small dogs, loves to play and keeps my knees warm during shows. But Sam has one major downside: like most Terriers, she loves to bolt.

Neighborhood kids come over? zip! she's out the door and enjoying her adventure before the first cuss word can form in my mind. Whenever I need to go check the mail I'll carefully scan the living room, making sure the beast is nowhere in sight. But as soon as I open that front door just three inches, she appears out of nowhere and dashes through.

The Breaking Point

I've put up with my little escapist for five years. FIVE YEARS. During which I made several half-hearted attempts at solving the problem. More walks, dog training, neighbor training, signs, etc. Nothing worked and I'd just go back to dealing with it. This last year since working from home it got especially annoying. I'd be working in my office, finally in that precious state of flow when all of a sudden from out my window I hear a distant rough! rough! Flow shattered, I'd grumble and retrieve my dog. It finally broke me - I had to fix the Sam problem.

That's It!

I set my mind to solving this blasted problem once and for all, and there was nothing in the world that could stop me. I brainstormed all sorts of ideas, the majority of which were legal and humane. I bought one of those electric shock collars but couldn't bring myself to using it on her. I tried a non-hurty sonar one that supposedly produces a dog-repelling sound at close proximity - talk about a scam. I even entertained the idea of inventing some kind of dog-catching robot.

Finally I realized that if my brain couldn't defeat my pup, perhaps my opposable thumbs could. I devised a contraption in the doorway that would be easy enough for a human to step over, but too hard for Sam to get through or over. With a wicked laugh I walked through the isles of Home Depot and found what I needed. Sam eyed me curiously - I let her watch - as I installed the end of her freedom: eleven bungee cords strung tight between rings drilled into the wood frame.

Sam hasn't escaped since!

I consider this one of my life's greatest achievements. I never have to worry again about my best little friend getting hit by a car. And I'm writing this article right now in a wonderful state of uninterrupted flow.

Living with Unsolved Problems isn't Stoic

This really got me thinking - why do we put up endlessly with unsolved problems? Things that cause us a lot of pain and frustration? Especially as developers, we put up with a ton of problems of our own making. Dog-slow webpack builds. Terrible home-grown abstractions. CSS that produces Jira bug tickets faster than you can squash them. Rotten areas of the codebase that use three different JS frameworks because nobody dares touch that crap. These snags cost us every time they're tripped over. New features take exponentially longer to release. Existing features get no love for the the polish they need.

But instead of eliminating problems once and for all, we let them fester. We let them strangle our productivity. We label them Technical Debt and ask for permission to solve them, knowing full well that decision makers have no idea what we're talking about. Because getting shot down by management kinda feels like "oh well I tried". It's a quick way to feel proactive without having to tackle the hard problems - plus now we can blame someone else for our situation. Victim mode FTW!

No joke - I worked at a place once that banned the phrase "Technical Debt". Developers weren't allowed to say it. Execs were tired of hearing about it and just wanted people to solve their own problems.

Weak Skills are just Unsolved Problems

We sometimes do the same thing with our dev skills. Weak skills come with a steep tax. Skilled UI devs don't settle for struggling endlessly with CSS. They master it. They don't have to stop what they're doing and look up Flexbox or Grid all the time. The good news is a weak skill is just another problem to be solved. Mastering the fundamentals of your craft pays off huge in the long run. This is why I created Flexbox Zombies and Grid Critters - so devs can solve their frontent layout problems once and for all. It's been awesome watching my students master this stuff and build amazing things on their own.

When to Stop Drop and Solve

Early computer scientist Willem van der Poel came up with a rule he called Zero, One, or Infinity (ZOI). The idea is that for frequency of occurrence there are only three categories:

• something can never happen
• something can only ever happen once
• something can happen infinite times

This zero, one, or many rule has had a huge impact in our industry. We see it in foreign keys in database design. It's been a fundamental in UX design ever since Alan Cooper's classic The Inmates are Running the Asylum. It's also a fantastic rule for knowing when to solve problems - both in your life and in your code.

Problem encountered 0 times
Don't worry about it yet. Sometimes us devs get overwhelmed thinking we have to learn every bit of tech out there, when in reality most of it exists to solve problems we don't currently have. You can be an expert UI developer by only focusing on mastering the fundamentals and picking up only the things you actually need.

Problem encountered 1 time
Make a note, but don't sic your mind on coming up with a solution. Many problems are one-time events that won't bite you again. (dog references intended)

Problem encountered 2 times
As soon as a problem gets encountered twice (twice by you, or twice by two different people in your team/family) then you're in infinity territory. If it can happen twice, it can happen a thousand times. This is the right time to solve it good and solve it once.

Solve it Once

When you set out to solve a problem, the biggest temptation is to do a quick fix. Something that mitigates the pain a little. You know you've fallen prey to this "band-aid" mindset if you hear yourself saying things like for now or V1 or first pass. Temporary fixes just aren't worth it. How many times have you encountered a //TODO: in a project from someone who doesn't even work there anymore? Their temporary fix is now one more thing you have to understand to actually fix the core problem.

Hacks upon hacks, breaks the devs' backs

Here's a better way to work: if it happens twice, solve it once. Like, actually solve it. So that the problem has no chance of wasting another engineer's afternoon ever again. You can get all fancy if you want - keeping a spreadsheet of every occurrence of every problem. But it's easy enough to just say "hey team, the wonky dropdown component took me four hours to debug, anyone else run into this?" If so - it's fixin' time and you're up! If you delay the task to the dusty backlog you'll never get around to it. Solve it now while it's fresh on your mind. Solve it good so nobody has to trip over it or even think about it ever again.

Imagine how productive your life and project would be if problems were fixed as they came up, never allowed to impact more than twice?

What's your Sam?

Think about an unsolved problem - your Sam - that you've been dealing with forever. Stop reading this right now and go take care of it. Solve it good, solve it once.

P.S. In case you're wondering from the illustrations, Sam does indeed look more like a bat than a dog. Now that I've solved the escaping problem she's a happy, safe bat-dog.