It’s 1 pm on the final day of the Hackathon, 5 hours left. For the last 2 hours, we made ZERO progress. I’m cursing the day Lovable was born. As soon as I fix one problem, another one appears, and our app is barely usable.
The start was very promising. I joined 2 engineering friends and 3 recruiters to build ‘HoneyCrew’, a smart referral system (the goal was to send a weekly summary to every employee with potential candidates from their network for our open roles. Here’s an open source version). We decided to go with Lovable so the recruiting team can maintain it themselves later.
On the first day, we just FLEW, completing 90% of the project. Scraping, scoring, Slack integration, admin - things looked almost ready.
On the 2nd (and final) day, we worked on some minor improvements, and things just… Completely broke. Endless bugs everywhere, slowness, everyone super stressed.
The recruiters on our team couldn’t understand what went wrong. We were on the path for an amazing product, and now we were in danger of not having anything ready for the demo.
An allergy to ‘infra work’
I used to work with a senior leader who loved to say that he has an allergy to the words ‘refactor’ and ‘infra work’. He couldn’t understand why we couldn't build it right from the beginning, and why we were always so slow. After LLMs appeared, it became even worse. He constantly asked: “Can’t you just give this task to ChatGPT? What’s the problem?”
To his credit, he at least asked this to our faces. I know many non-technical leaders who think engineers always exaggerate and work too slowly. It’s a flavor of the same old software engineering war I talked about last week.
A coworker (and a good friend) once framed it like this: “You write code, which is just words in a language I don’t understand, right? With fixed meaning. And you know what you want to say, as you have the specs you need to follow. How come it always gets more complicated?”
I’ve been struggling to explain this, until I almost bought a house:
Imagine if your software was a house
Last October, we saw a house for sale near my parents-in-law. It looked like a great deal - good location, nice neighbors, a garden like we wanted, and very affordable. It was small and 30 years old, but the low price left us extra to spend on it.
So we asked a contractor: “How much would it cost to renovate it and expand by 2 additional rooms?”
I couldn’t stop laughing at his response:
“I wouldn’t recommend it. It’s too old. It’d be much simpler and cheaper to destroy it and build from scratch”.
He could have been a great software engineer…
We passed on it, but since then I’ve been using the house analogy quite a lot when talking about software.
The house-building process has been known for thousands of years, and still every new one has different problems. And everyone lives in one, so it feels relatable. For example:
Why can’t you just fix the issue fast? Why does it always get bigger?
Your roof leaks. You can either put a bucket on the floor, or find the root cause. If it’s your own home, what would you do?
Yeah, a bucket might be ok for a couple of days, but you need to constantly empty it, and you risk the real issue becoming worse.
Why can’t you just solve this specific use case, without all that “infra”?
Let’s say you build a new house for your family. You have enough budget for only the first floor, but you have a big family, and you know you’ll want a second one in a couple of years.
Adding the infrastructure to support a 2nd floor is MUCH cheaper right now than it will be when you actually want that 2nd floor.
The house you never finish
So it’s 1 pm on the final hackathon day, and everything feels broken.
We didn’t really have any other choice. We stopped our vibe coding frenzy and carefully went over one area at a time until we had a simple demo-able flow working. Understand, plan, implement. Much slower than our day-1 pace, but we at least ended up with a working demo-able flow.
This process is how good software is built, but it gets so easily forgotten, just rushing forward. And unlike a house, you never really finish building it, so you constantly need to update the facilities while people already live inside.
My favorite reads of the week
Stop being the code review bottleneck. A very interesting and practical take on handling code review fatigue differently (hint: not doing them faster, and not delegating everything to agents).
What being "inspiring" actually means. You are not Viggo Mortensen rallying men to fight Sauron. You are an Engineering Manager in tech. Here's what it means to inspire in this context.
How tech workers are feeling in 2026: a workforce splitting in two. A very interesting survey in Lenny’s newsletter. Takeaway #9 is especially relevant for us:
Workers with an extremely effective manager report roughly 65% higher job enjoyment and dramatically lower burnout than those with an ineffective one. Yet only 25.5% of tech workers rate their manager as highly effective, while 36.5% rate theirs as ineffective