I spoke at the Legacy of SoCraTes 2020 conference, a conference about legacy code.
The audience asked me some questions, which I’d like to answer here.
What would you tell a person that did micro-committing in a way, where most commits don’t work, might even not compile?
It’s easy to say that all commits must work. It’s easier to say that all commits must compile. I’ve probably been guilty of saying that in the past, but I wouldn’t say it now.
Let me clarify: I don’t mean that it’s “OK” to allow commits that don’t compile; I’m merely saying that we have to make room for the possibility that, on occasion, it’s useful to commit code that doesn’t compile. I can’t think of any possibilities at the moment, but I can’t say that it could never ever happen. Instead, I encourage us to remember that I commit frequently in order to have useful undo points. I want the option to roll back my changes and if I don’t have good tests to support me, then I prefer to have more rollback points than fewer. If you decide that it’s worthwhile to have the option to roll back to some totally broken code, then do it. I have my doubts!
I see a clue in that sentence.
When faced with this situation, I would apply a simple formula:
- Ask them why they do the thing that I find strange. Listen carefully.
- Imagine myself in their situation and think about what I would do instead.
- Ask them whether they would agree to do what I would do instead. Listen carefully.
- Repeat until I find a satisfactory result.
In this situation, I try to understand the reasons that they do what they do, then offer them an alternative that gives them what they want in that moment while also giving me what I want in that moment. If I can find such a thing, then we both win. I might approach this specific situation like so:
I like that you’re micro-committing, because we agree that having more rollback points helps us. I’m worried about how often you’re committing code that doesn’t compile, because I’m really used to the confidence I get from knowing that any version of the code that I check out will build correctly. (I even prefer it if that code passes all the tests!) If I wanted a rollback point to code that didn’t compile, I probably would only want it a for while; I would imagine amending that commit a few minutes later in order to at least make it compile. Worst case, I’d comment out the code so that the build would pass. That would let us continue to feel confident that the code always builds, even when we need really fine rollback points. Are you willing to start doing that?
Why never check email in the morning? I recommend Julie Morgenstern’s book on the subject, Never Check E-mail in the Morning. It might well feel outdated by now in spots, but its general tone continues to ring true. I think of a few primary reasons:
- Many (most?) people get more done in the morning due to having more energy, so it follows that one ought to capitalize on that by doing more of the clearly-significant things in your backlog.
- Many (most?) people check email in a very disorganized fashion, which leads to wasting time when they (probably) have the most energy.
- Your email inbox is essentially a loose collection of other people’s demands on your time. By definition, putting energy there means doing what other people want rather than what you already believe you want or need to do.
- Recency bias causes many (most?) people to overestimate the urgency of requests they’ve received recently. Whatever you’ve chosen to do (and not merely thrown away), you’ve probably spent more time evaluating that for urgency than whatever sits waiting for you in your inbox, so start your day doing something that you’ve decided to do, rather that something whose urgency you might overestimate.
I know that when I check email, I feel guilt and shame for always “being behind” on what the world wants from me. Assuming that I have a backlog of significant things to do
I recommend the book for even more on this topic.
Not really a question: working remotely due to the COVID-19 pandemic has relieved much of the stress that legacy code imposed. I feel more in control of my time, and am more courageous to make the right decision. Excellent! I’m glad to hear it.