fix: removed sharpie from whiteboard

Did you know you can get Sharpie off of a whiteboard? You don't need to scrub it. You don't use rubbing alcohol, although that also works, and it's a whole separate story. But what you do is you take a dry erase marker, you color it directly over the permanent ink, and then you erase it like normal. The dry erase solvent lifts the Sharpie right off of it.

Both inks come off together. I learned this fact in a single most uncomfortable meeting in my career. I was a senior engineer at the time at a golf company, and I'd been sent to New York, somewhat against my will, to evaluate a piece of software. My company was thinking about buying it. I looked at the code beforehand.

It was rough, and I wanna be diplomatic and say rough and let it sit there for now.

We were in a room with their team going through the system, and someone on my side asked a completely reasonable technical question, nothing hostile, the kind of question you ask when you're doing your job, and the lead architect in the room stood up, walked to the whiteboard, and lost it. And I mean lost it.

He grabbed a marker, started drawing and yelling at the same time we tried to say something. Somebody on our side actually said out loud, like, "Wait, that's a Sharpie," because it was, and everyone could see it was, and he was drawing his entire system architecture in permanent marker on a whiteboard that was very much not going to survive this.

Their executives just looked at us, not embarrassed, more like, "Let him finish." He did not hear a word we said. He filled the board, diagram, arrows, boxes, more arrows. Then he threw the marker down and walked out of the room. Silence. A really long, uncomfortable silence. Long enough that I started doing math about how much of my remaining life I was going to spend in this room.

And then one of their executives stood up without a word, walked to the whiteboard, picked up a dry erase marker, and started drawing directly on top of the Sharpie. Nobody explained what he was doing. He just did it, and it worked. The board came clean. That wasn't the first time the architect had done something like that,

And I found that about 90 seconds later, because while their exec was midway through the trick, one of the other executives leaned over to us and said, completely casually, "Oh, he does that a lot." I remember sitting there thinking, I don't fully understand what I just watched. I have a recommendation to write, and it's not going to be complicated, but I'm fairly sure the recommendation is not actually the point of this trip.

And it took me years to understand exactly how right that instinct was. Welcome back to Chaotic Commits. I'm Joanne Skiles, and today I wanna tell you about the time I flew to New York to evaluate a piece of software, watched a grown man draw out his own diagram in real time with his own rage, and then spent the next several years of my career figuring out why none of that mattered.

Today's episode really isn't about the whiteboard, although it was a funny moment in retrospect,

and I promise we will go back to the whiteboard scene, but the real point is what happened in that trip to New York. The question I think a lot of engineers run into eventually, and usually the hard way: what do you do when you did your job correctly, you gave the right answer, and the organization did the opposite thing anyway?

And spoiler, sometimes it's because you weren't actually being asked the question you thought you were being asked. So let's get into it. So some context on the company I was at during all of this. It was a golf company, one that had built a real-time based inventory system of its own, tee times, essentially.

Treat it the way an airline treats seats. You have a finite number of slots. They expire the second the window passes, and if you don't sell a seven fourteen AM tee time by seven fourteen AM, that inventory is gone forever. No back order, no rain check. It either sold or it didn't. And we were good at this.

We were frankly the team other people asked about time-based inventory, which matters because it's the exact lens I walked into that New York meeting with. The company we were evaluating made a point of sale software for country clubs, not just golf, golf and the restaurant, one system doing tee times and dining service, which if you think about it for even a second, it's a strange pairing.

A tee time is a hard, discrete, disappearing slot. Seven fourteen AM, four golfers, gone the second it passes unsold. A restaurant table is not that. A table sits for however long the party wants to sit there. Someone orders an appetizer, and then they decide on a second round. Then the kids want dessert.

Then somebody wants to split the check four ways and put two of the four ways on separate room charges. A table doesn't expire on a timer. It turns over based on human behavior, and it's editable up until the second the final payment closes it out. Trying to run both of those through the same inventory model is like designing one set of traffic lights to control both a highway on-ramp and a four-way stop in a neighborhood.

Technically, both are traffic. Practically, they are different problems wearing the same board. I read through their code before I ever got on the plane, and I could already tell that it's roughly what had happened. The system read like tee time logic that dining service had been bolted onto afterward, instead of a system that had been designed to hold both from the start.

Rough is the diplomatic word I used earlier. What I actually wrote in my notes on the flight was closer to, "I don't understand how this doesn't break constantly," which foreshadowing it did. Nobody had fully explained to me why I was on this trip. I'd been told, "Go evaluate the software. Tell us if it's any good."

I assumed that meant my opinion on the software was the thing that mattered to the decision, and I want you to hold onto that assumption. We're going to come back to exactly how wrong it was.

So let's go back to the whiteboard. We're in the room, their team is walking us through the architecture, and because we built a real-time based inventory system ourselves, we knew exactly which question to ask. And we ask it in, I think, the most polite way, most normal, most just doing my job way a question can be asked.

Something like, "When a dining check gets split across a table, how does that relate back to the original reservation record? What's the actual relationship in the data model between a tee time slot and the restaurant check?" That's it. That probably was the whole question. It might be even actually more wordier. And I watched a man's face change in real time.

Not confusion, recognition. The specific look of someone who's been asked the one question they have spent a long time hoping no one would ask. By someone who clearly already suspects the answer. He stood up. He went to the whiteboard. He picked up the nearest marker, and it happened to be a Sharpie, and none of us clocked that fast enough to matter.

And then he started drawing his architecture while yelling at increasing volume about how people don't understand the complexity of what he built, about how everyone always underestimates this system, about, and I'm not exaggerating the register here, things that sounded a lot like personal grievances that had nothing to do with tee times or cheeseburgers.

And we said, "Wait, that's a Sharpie." I think twice, actually. He did not hear either time. Their executives had the exact expression of people watching a fire they've watched before. Not alarmed, just, "There it goes again." Nobody moved to stop him. Nobody looked surprised. He filled the entire board. A genuinely elaborate diagram, boxes and arrows drawn at speed, narrated at volume in permanent ink on a whiteboard that belonged to a room he presumably had more meetings in after ours.

Then he threw the marker down on the table hard enough that it bounced and walked out. I have sat in a lot of quiet rooms in my career. This was a specific flavor of quiet. Nobody on our side wanted to be the first to speak because nothing that could be said out loud was going to be professional. And then one of their executives stood up, walked over, picked a dry erase marker off of the tray like it was just a normal Tuesday, and started coloring over it.

No announcement. No, "Don't worry, I got this." Just methodical, practiced, over the top, fresh ink, then erased the whole thing, while he was mid-stroke, the other executive leaned towards us almost cheerfully and said, "Oh, he does that a lot." Not defensive, not apologetic, just information, like he was telling us the elevator sticks on the third floor.

And that's the detail I want you to hold onto because it was doing more work than the yelling is. The yelling was one guy's bad day or bad decade. "He does that a lot," said in the tone by his own leadership in front of people who value whether to buy the company, is an organization telling you exactly what it's decided to live with.

So I went home and wrote my recommendation. It was short. Don't buy this. The architecture doesn't hold up. The team dynamic around it is worse than the architecture, and I said so plainly. And then we bought it anyway. For a long time, I thought this meant my recommendation hadn't been good enough, that I hadn't made the technical case clearly, or I hadn't flagged the severity properly, or that leadership simply hadn't understood what the data model doesn't cleanly separate reservations from checks actually meant in practice.

None of that was it. What actually happened in the years after close was what you would expect from a system the way I described. It broke constantly in the specific way that a system breaks when two incompatible models have been forced to share a spine. Checks that didn't reconcile with reservations, billing errors at the point where the dining party's tab was supposed to hand off cleanly to what our tee time side of the system thought was happening.

The kind of bugs were the fix for one country club's specific setup didn't generalize to the next club because nothing about the underlying model had ever been generalized in the first place. It was so fragile that we ended up building a dedicated internal team whose entire job for years was traveling to country clubs to keep this specific system running, not improving it, not modernizing it, showing up in person when it broke because it broke in ways that were hard to diagnose remotely and easy to make worse if you touched the wrong part of it from a distance.

Eventually, it got rewritten. Eventually, it got absorbed properly into the rest of our system, and eventually is doing a lot of work in that sentence. It took years. So here's the question I sat with for a long time. If the recommendation was accurate and the aftermath proved it was accurate, why did we buy it?

The answer, once I actually let myself see it, is that the recommendation was never what the deal hinged on. We didn't buy that company for the software. We bought it for the client list. Every country club already running that system was already a customer relationship, already onboarded, already paying, already using the product day to day.

That's not a thing you build with clean architecture. That's the thing you build with years of sales relationships, trust, and inertia. And there is no clean, fast way to acquire that except to acquire the company that already has it. The codebase wasn't the asset. It was the tollbooth you had to drive through to get to the asset.

It's the real estate version of buying the worst house on the best street. Nobody falls in love with a water heater from 1987. You fall in love with the street, the school district, the walk to everything. You knew before you signed anything that you'll be gutting the kitchen. You just didn't put that part in the offer letter.

My recommendation wasn't wrong. It also wasn't the question being asked. I was evaluating a system. The company was evaluating a customer base. Those can produce completely different, completely correct answers to what looks like the same due diligence trip.

So I want to be careful here because it would be easy to turn this into, "Executives don't care about engineering," and that's not actually the lesson, or really honestly not the interesting one. The lesson is that a due diligence process that only asks engineers to evaluate the code is asking half a question and presenting it as a whole question.

If the real acquisition target is the client relationships, then say that. Tell the engineer being flown to New York, "We already know that the codebase probably isn't great. We need you to tell us how bad, because we're buying this regardless and we need to know what we're inheriting." That's a completely different trip.

I would have written a completely different memo. Not, "Don't buy this." Something closer to, "Buy this with your eyes open, budget for a multi-year rebuild and staff a team whose whole job is standing in the blast radius until it's done." Instead, I was sent to answer a question that wasn't actually the one being decided, and the gap between those two things got paid for later by engineers who had no vote in the original decision, showing up in person at country clubs for years to keep a fragile system breathing.

This isn't unique to one golf company or one deal. I've watched this pattern in other acquisitions since. The target is the customer base, the market access, the thing that took someone else years to build the relationship for.

The codebase underneath is treated as a cost of entry rather than a variable in the decision, which is sometimes a completely rational trade. Buying years of customer trust is valuable, sometimes more valuable than good code, and I'm not arguing that it's always the wrong call. I'm arguing that when it's the actual call being made, somebody should say so out loud to the person being sent to evaluate the code before that person spends a plane ticket in a very uncomfortable meeting answering a question nobody was actually asking.

It's the parenting equivalent of a juice stain on the couch. You can throw a blanket over it before company comes. Nobody at the dinner party sees the stain. It is however still very much there, and at some point you either clean it properly or you accept you're buying a new couch. What you don't get to do is pretend the blanket was the fix.

So here's what I actually took from that trip once I stopped being annoyed that my very correct memo got ignored. The codebase was never going to be the deciding factor, and that's fine as long as somebody is honest about what the deciding factor actually is. The failure wasn't the decision to buy a messy system for a good client list.

Companies do that trade all the time, and sometimes it's the right one. The failure was running a whole evaluation process that pretended the code was the question when the code was already a foregone conclusion, and the real question was being answered somewhere else entirely. If you're the one being sent on that trip, ask directly before you get on the plane, "Is my recommendation actually going to change the outcome here, or am I going to be sent to size the cleanup?"

Both are legitimate things to be asked to do. Only one of them is what most people assume when someone says, "Go evaluate this." And if you're the one making that call, tell the person you're sending. Let them write you the memo you actually need instead of the memo you asked for. You can cover a mistake.

You can even cover it cleanly, so cleanly nobody at the table can tell it happened. I watched a man do it with a dry erase marker in about 90 seconds. But covering it and resolving it are two different verbs, and only one of them means the ink is actually gone.

That's this episode of Chaotic Commits. I'm Joanne Skiles, and I still to this day know exactly how to get Sharpie off of a whiteboard, which remains the single most practically useful thing that entire trip taught me. New episodes wherever you get podcasts. No highlight reel, just the commit history. I'll see you in the next one.