As I found out very early on in my career, building software is as much about communicating as about programming. Why is that? Yes, being the stereotypical developer sitting in one's basement alone, without talking to anybody, may be possible while building an MVP. But as soon as the software grows beyond the capability of one individual, communication will become part of the process.
I definitely observed this change during the growth of the company I currently work for. We started out with just a few devs and now there is half a dozen of us. Not only that, we also created other departments like sales and marketing. With all of them, there is communication, and that is the reason why I see a need to improve my own communication patterns.
The one that I want to tackle first is the phrase I usually say after working on an issue someone else has pointed out to me:
"It should work now"
Why Bother?
You might have heard this phrase from others, or maybe you are saying it regularly yourself. (Please note that in this post, I am exclusively referring to my personal relationship with this phrase when I say it myself.) But what does it imply?
Especially in the context of a problem solution, saying "It should work now" lets me keep some wiggle room if it, in fact, does not work. Since if I had known for sure that it worked, I would have said "It works now" instead, right?
And there lies the issue I take with myself when utilizing this word when making statements. It hides the fact that I am not completely sure about the quality of my work! Well, it does not actually hide it. Rather, it packages it innocently.
Shifting the Blame
Another problem I see when I use "It should work now" is the implicit expectation I put on the reporting party.
They already had to discover a problem and report it to me, which means they did their part and are relying on me doing mine. But with such a response, I try to share the responsibility for the solution: I create a fix, then use them as testers, and if it breaks later on, they were part of the verification process.
That is unfair and definitely not how I would like to be treated. By saying "It works now", I would make a clear statement about my work while simultaneously taking full responsibility for it.
Root Cause Analysis
In software engineering, we often do a root-cause analysis of a problem. It makes the assumption that observable problems are often just symptoms of deeply hidden ones.
In this case, using "It should work now" is the observable problem that makes me feel like I am not reliable and responsible enough. The surface-level solution would be to just use "It works now" from now on. But that would start to make me feel like I was not fully truthful.
There, we can see the deeper issue: "It should work now" is a defensive mechanism of mine to hide my missing trust in my work.
Understanding and Solving the Problem
But why do I not know with certainty that I have solved the problem? That can depend on various factors, like not fully understanding the problem or me failing to reproduce it. Especially the latter one often leads to a back-and-forth between me and the reporting party when a supposed solution does not actually solve anything.
Therefore, since I discovered this, my approach to fixing it is to use the urge to write "It should work now" as a trigger: Whenever I find myself wanting to write this phrase, I ask myself what I could do to better verify my solution.
Then, after doing just that, I can confidently write:
"It works now"
Thanks for reading
Chris
P.S. Acknowledging Toxic Culture
I am absolutely aware of the fact that there are companies out there where you constantly need to cover your ass and avoid making yourself vulnerable with absolute statements that might be used against you in the future.
My experience has luckily been only in positive work environments where honesty and reliability are valued and mistakes are seen as opportunities to learn.
If you work in a toxic culture where this is not possible, I can fully understand if you disagree with my stance on this phrase!