I like to read technical blogs. I do it daily since a few years now, and I really enjoy the way in which this community is sharing in order to improve. I would argue that it’s an efficient way to raise the bar of the software industry. There is one thing I regret though: we almost never talk about our failures. We talk about concepts, implementations, and how we think the industry can be better. But we very rarely share about our failures. I do meet failure more often than success. I think it’s a good idea to share about it, because people who read us without working with us may think that we are kind of “super developers”. We are not. Let’s talk about how we fail and why.
When the pressure comes back
I’m bad to work under pressure. I mean like really bad. My brain is just in panic mode and seems to hide data from myself when I’m stressed. I can physically feel the pain when I try to focus in this situation.I have no way to clear out my ideas, my mind goes in many directions and I almost systematically miss obvious stuff. The usual result is that I push code I should never have committed (like code I changed “just for test”), and/or that I need lots of time to sort out simple problems. In this situation, I may bypass some quality practices because you know… We’re in a hurry!
Where does this pressure comes from?
In ten years, I learned to say no, thus it generally does not come from other people. It’s usually my own commitment due to my own estimation. And in ten years I learned to be very careful about my estimation.I know that unexpected things happened all the time. And still, the pattern is almost always the same. First I commit to a deadline that seems correct to me.Then I’m not as fast as expected, and I feel like I lose time on trivial stuff.Finally, I feel guilty that it takes “so long” for this “trivial” thing. I feel like it’s “almost done” and work extra hours in order to finish it. I see the pressure growing. At some point, I bypass some quality practices (no one is here to validate my pull request after 8 pm anyway… And do I really need this test? This piece of code seems so simple…)
Consequences
The consequences are most often the same. The few hours of extra work cost me a few hours/days to fix it. My colleagues usually look at the PR in the morning, and it took them a few minutes to spot my mistakes. That was the cost of my extra work. That is how productive I am when I work 10 hours a day.
A developer with good practices
It reminds me this truth from Kent Beck I know for a while: I’m not a great developer, I’m a developer with great habits. Losing these habits make me much less efficient. And even after 10 years as a software developer, it’s still easy for me to discard these practices.
Being a code crafter is a continuous challenge.