Flow vs YAGNI
YAGNI – You Ain’t Gonna Need It – is a famous software engineering maxim. Predicting the future is notoriously difficult. When we guess at future requirements, we often guess wrong, so any code we write for them is usually wasted and makes the program more complex and less maintainable.
Another maxim is that flow is sacred. When you’re in flow, you’re a superhero. You hold the entire system in your head, code faster than a speeding cursor, leap seven layers of abstraction in a single file.
Flow is built out of context. When all the context is humming inside your head, that flow state is glorious, but getting there takes hard mental labor. Usually it takes reading code, lots of different code, which is harder than writing it. This is why we go to extra lengths to add comments and refactor and try to make code readable. They’re all context shortcuts. Continue reading
The year is 2040
Don McCullough
This is the first “homework” assignment for a Terra.do class I’m taking on the climate crisis:
The year is 2040. The world has figured out a pathway to radically reduce our greenhouse gas emissions, while also rapidly developing local communities’ capacity for resilience to climate impacts….You feel happy, and proud, because you played a role in making this happen. Please write a blog post…telling your story.
It’s been a rough couple decades. The COVID-19 pandemic shook the world to its core, grounding it like a misbehaving teenager. The few countries that managed to get on top of it early emerged into an oddly balkanized world, with neighbors and trading partners still locked down, and economies and supply chains in disarray.
The demand shock cost the world trillions of dollars and decades of growth. ESG budgets were slashed worldwide. Carbon pricing schemes were postponed, neutered, and in some cases, rolled back altogether. COP26 in Copenhagen was delayed, delayed again, reluctantly moved online, and passed with barely a whimper. Delegates who’d based whole careers on body language and facial micro-expressions suddenly found themselves lost in a sea of pixellated heads and muted voices. Not a single resolution was passed. Continue reading
Theory: every comment or question in a code review should result in a change at that exact point in the code. Even if it’s just a misunderstanding, or triggers a change elsewhere, the explanation usually still deserves to go into a comment right next to the code in question.
Years down the road, someone else will need to read your code and understand it. Code review is a dry run for that day. If your reviewer misunderstood something, your future reader will too. They won’t go dig up the review, but they will see the comment, right where they need it.
Me: "Why do you think they call it the Golden Gate Bridge if it’s red?"
5 yr old: "Oh, that’s actually International Orange Color."
🧐
I’ve been curating this collection of software engineering quotes for a while now. Practical, funny, wise, surreal. I add a new one every week and inflict it on my team at the beginning of our weekly team meeting.