The smallest fix is the most critical release you will make to your software. It is the most critical because it is the most overlooked. “I ran it on my machine.” “It’s just this one isolated thing.” “It won’t affect anyone.” “We don’t have to tell anyone we’re deploying it.” Because it’s small we decide (for some odd reason) to treat it differently than our most significant releases and as such when something goes wrong,…
It should be testable. It should defend. It should be clear to understand. It should catch errors. If it is not the sole source of all the logging, it should provide valuable fragments that render what it logs usable. It should do what it is meant to do, not what we hope it to do
You have 8 eight hours to fix this issue that you know nothing about with minimal logging, maybe a screenshot, and 5 customers all complaining about similar issues but not really the core of the issue. Go. No one wants to work like that and yet we let it happen again and again and those that do it are proclaimed as heroes for saving the day. Here’s the hero I want – the one that…
We all have leftover code lying around ready to be used. But like any type of leftovers, they are not perfect. They need to be reheated, perhaps rejigged into something else, maybe even dressed up a little more. No one eat’s leftovers as is, code snippet leftovers are the same, they are a start to something better.
I love the thrill coming out of a good meeting – one where a problem was discussed, a plan put in place, and the next steps laid out. It is the perfect definition for a meeting if ever there was one. Then there are the meetings to “talk”, where we schedule up the talk and take time from people’s day to have the talk. That is called a conversation, it doesn’t need to be scheduled,…