I love ideas that turn my world around. They typically come via books, articles, and talks but, in some rare occasions, it is just a simple quote that produces that effect.
The impact of such quotes highly depends on your background and context. Here are three examples that, in hindsight, had a huge impact on me.
Programming habits
I’m not a great programmer; I’m just a good programmer with great habits.
By Kent Beck, quoted by Martin Fowler in Refactoring (1st ed), June 1999
When I read the Refactoring book in the early 2000s, this quote strongly caught my attention. In a time where you could often hear that programming was a second-class activity for a real engineer™ (foolishness that some still perpetuate today), books like this one, XP Explained, or The Pragmatic Programmer, placed the focus on practices for writing better and more robust code. And this quote made me want to learn about those: automated testing, the importance of readable code, implementation patterns, refactoring, continuous integration, etc.
Above all, this quote made me respect the craft of writing code. In those days, I had professors who told us that our job should be drawing comprehensive diagrams and writing long documents that others would code. Imagine having paid attention to those! I still carry a subtle and unjustified aversion to the term engineer from those times.
Feedback loop
As an engineer, you should constantly work to make your feedback loops shorter in time and/or wider in scope
This sentence put a name to a concept that wasn't even on my radar: feedback loop. Today, I believe it is a key factor in developer happiness. It refers to the cycle of writing some code and validating its effects. You are going through that cycle countless times while coding anything, so you better pay attention to how it unfolds.
The feedback loop is often associated with automated testing. You want your tests to be fast (shorter in time) and test the real thing as much as possible (wider in scope), which are usually opposite attributes. Indeed, having an effective feedback loop is an excellent reason for writing a test, although that is not always possible or suitable.
I think testing is just one side of the problem. Here are some assorted thoughts:
- Improving the feedback loop is worth investing time. For example, I created this to avoid having to use JRuby because of its slow startup time. And also this command-line tool for another system for the same reason.
- A fast load time is a crucial feature for users, but it is also essential for programming happiness. Apps that are slow to load can quickly drain your happiness at development time.
- REPL shells are a terrific tool for experimenting and troubleshooting in many scenarios. Immediate responses make for a great feedback loop.
- When doing performance work, automate as much as possible whatever mechanism you are using. In some recent profiling work I did, just running the profiler and opening the generated report in the browser automatically with a keystroke improved my experience significantly.
- When it comes to user interfaces. Modern browsers dev tools offer wonderful mechanisms for manipulating HTML and CSS directly. Hot reload in React and Vue is fantastic, as much as I don't love the SPA scene. And SwiftUI looks amazing. An immediate feedback loop is so convenient for UI work!
Scope and deadlines
“Fixed deadline, negotiable scope” has to be the most underrated pattern in product management. It’s the secret to shipping.
This idea just blew my mind when I first read it. Until then, I had come to consider deadlines in software as something negative. I had never thought of them as a mechanism for narrowing down scope. And it clicked because this solved two problems I was very familiar with:
- Missing deadlines because finger-in-the-air estimations at the beginning of the cycle were always wrong, no matter how much you shortened the iteration.
- Not knowing when a project was done since there were always pending refinements that looked so important.
Programming is a wicked problem: you don't understand the problem until after having solved it. If you are allowed to modify the scope, you can adapt the amount of pending work as you progress through the project and, that way, honor the deadline. And you also have a mechanism to decide when the project is good enough and ship.
I think this is one of those ideas that, while simple, is hard to put in practice successfully. If you are interested, the book Shape Up explains how they do it at Basecamp, and it is one of the best reads I have had in a long time.
I would love to hear about similar quotes that impacted others.
Top comments (0)