Turning Screws - The hidden complexity of easy tasks
Several years ago, I shared enhancements I had made to a script with a colleague, enhancements that would enable many software developers working on the product to have a more productive experience with our benchmark system. He was impressed with these enhancements, and asked how I achieved that. I started to explain: It was very easy, I did this and that, and this other thing…
He stopped and provided me with a lesson that lives in my mind rent free to this day: Don’t say it was easy, don’t downplay your work. I may not have the exact words here, but the lesson was imprinted in my mind.
You might have heard this one: a technician called to fix a machine. With a simple turn of a screw, the technician solved a problem that perplexed everyone else, charging $501 for this work. When questioned why charging so much for a simple screw turn, the technician explains that turning the screw is just $1, knowing which screw to turn was $500, thus, integrating their prior knowledge into the solution’s value.
This story, humor aside, exemplifies a deep truth about the nature of expertise in any field. In software engineer is not different. We may often relate the sophistication of a solution to the complexity of the problem, but in reality, there’s no general rule for that. I have countless examples where the solution of a critical and demanding issue was a simple but surgical if-clause which I would address in a matter of minutes and while doing so, I may overshadow other aspects such as my prior expertise, or the time it took for me to debug and isolate the issue. Depending on how I put it to the world, it sure might look like an “easy” fix, after all, it was just an “if”.
The tendency to understate the complexity of our work can stem from a variety of cultural and personal reasons such as humility and impostor syndrome. However, when we downplay our contributions, we inadvertently diminish the value of our expertise and the effort behind acquiring it.
When it comes to reporting our work, either on a daily stand up meeting, on your weekly report, or even on a yearly employee performance review, communicating the value of our work effectively is crucial. It’s not all about the code we check in, but the value we are adding to the product, to the team and to the company.
I’m not saying the you should simply start boasting your achievements, this is not only a terrible career advice, but will only get you so far in life. What I want is to invite you, my dear reader, to reflect on the times where you may be belittling the challenges you are facing. You would be surprised by the things you may be leaving out because it fells easy to you. Remember that effective communication about your contributions will not only improve your sense of accomplishment, but also influence your career positivaly.
Returning to my initial example, after other “easy” and “simple” enhancements during the course of some months, the work I did contributed to the drastic reduction of the time necessary to analyze a run of the benchmark from 2-4 weekly hours, to merely a few minutes every week. And I must say that as I’m writing this, it still feels odd to share such a significant result stemming from such “easy” changes, but we both know better by now, right?
(Image was generated by DALL-E)