- Alejandro's Eclectic Newsletter
- Posts
- EN 31: Challenge, struggle, victory, endorphins
EN 31: Challenge, struggle, victory, endorphins
This week, I’ve experienced a common frustration as a developer, a mix of banging your head against a wall and trying to get out of an infinite maze. To me, it even turns into physical discomfort. It’s the pain of realizing that what should be an easy change is a behemoth, and that untangling the spaghetti might be an odyssey worth being recorded in the annals of history. Soon the odyssey will be forgotten with the next similar challenge, business as usual.
Hours fly by with no progress. At some point, the thought of hacking it might cross my mind, “to hell with it, I just want to move on”. I resist the temptation to hack it because one hack here, one hack there, time over time, only make things worse.
For each desired change, make the change easy (warning: this may be hard), then make the easy change.
The compound effects of hacking it will only make future change more difficult, and even “seemingly easy” changes will be even more difficult to make. Future me won’t be enjoying my hack. But as I sit thinking about the world of endless possibilities and the massive undertaking of the change— compared to what it should’ve been—the value we’re getting from it, and the state of the system, I doubt. In general, my goal is to improve the code in some way with every change, and take many more much smaller steps.
In many situations like this, when I’m stuck, going for a walk, sleeping, taking a break, or just forgetting about it until the next day works best. Letting the subconscious brain do the work works wonders and if nothing happens, at least you see things with fresh eyes and replenish your focus.
Sometimes, it turns out the massive change is not that big when I change the angle of attack. Other times, I realize I was just missing something (knowledge, understanding). The times when it’s really a mess, there could be tons of reasons for it, but two of them appear frequently: the codebase/architecture is not adaptable or the model of the business is obsolete or doesn’t really represent the business.
Physiologically, after banging my head against the wall for hours, the payoff of solving the challenge is like a drug. There’s this immense satisfaction and exhilaration. It’s similar to when you play a difficult video game, die innumerable times, and, with extreme focus and dedication, you beat the boss, or when you finally solve a tricky puzzle in an adventure game. Maybe it’s the sense of discovery, achievement or improvement, like opening a door that was closed until now.
Interesting links
First One, Then Many. A great article by Kent Beck about succession, which refers to creating a design in stages, starting with a simple design that satisfies the user needs that we know now and evolving it in a lean way.
Inside Linear: Building with taste, craft, and focus. Lenny from Lenny’s Podcast interviews the CEO of Linear, Karri Saarinen. They discuss the way the company operates and see product, design and software development. Linear is an interesting example of a different way of doing things as a start-up.
Classic rock, Mario Kart, and why we can't agree on Tailwind. I’ve found this article, by Josh Collinsworth, fascinating. Tailwind has risen in popularity in the past years, but there are two camps of people: the love it people and the hate it people. Josh separates these two camps into builders and crafters respectively and argues that it’s all about tradeoffs and about what we value.
Reply