Good Guy, Bad Developer
Today at work I approached a colleague of mine who’s a senior developer and asked him for help on the task I was currently assigned with. As I was explaining the problem and context of what I was facing he asked me one simple question.
“Why are you doing it in this way?”
I froze.
It was the end of the day and I didn’t want to handle a discussion. I didn’t really know how to explain it. The task was pretty clear in terms of specification, I had to change a few things in some test code, run the tests and check if the results added up.
However, the way the test code needed to be changed was not straightforward, it could be done in several ways. I was doing it the way someone told me to and I couldn’t explain by my own words what needed to be done. I was just following instructions instead of putting my brain to work and actually thinking of what I needed to do and how to do it.
The cost of being lazy
In the context of the conversation I said.
“We had this discussion yesterday. I’m doing this because [senior developer] told me to.”
To which he replies.
“Sure, but you shouldn’t be doing something you don’t fully understand how and why you’re doing it.”
The team had previously suffered from delays caused by people questioning the implementation of tasks too much. I didn’t want to burden the team by putting the brakes on the task until someone helped me understand it.
Still, I didn’t think about the implications of not being critical of the work I perform. I shouldn’t give up on fully analysing and understand the work I’m assigned just because someone more experienced than me told me how it should be done.
It’s like not testing code the code you just made because someone told you that it works. Then when you deploy it to production, the bugs you find will be much more expensive to solve. If only you had put your brain to work during development…
In this situation, I was trying to be the good guy who does his job without raising questions but ultimately I was just being a bad developer.
Having this kind of attitude is harmful and toxic, especially in the long run. Not only is the integrity and quality of your work and the product of your work questionable, which impacts you and the entity you work for, but it also poses a roadblock in the path of learning and aspiring to become better at what you do.
Lesson learned
In the midst of the conversation, I eventually tried to explain why I wasn’t being critical about the task. It was a mix of not wanting to delay the team’s work as well as fear of being criticised by questioning the task’s specification.
This behaviour is defensive. I’m a big advocate of being able to give and receive honest feedback but in this situation my brain triggered a defensive response. Instead of comprehending what I was being told, I was trying to excuse my laziness.
Please don’t be like me. If someone is giving you constructive criticism for free then dearly hold on to it and learn something. Excusing mistakes is a no-no. If you create excuses for every mistake you make then you aren’t able to figure out what went wrong and how to fix it, and if you can’t figure out what went wrong then you’ll learn nothing from it.
In the end my colleague sat me down, spent some time with me discussing the task at hand and explained how I should approach it. He made sure I understood what needed to be done and, most importantly, why it needed to done.
It’s not every day you’ll find people who are willing to spend their time for the benefit of others so I can only hope that I can continue to learn from his teachings and to someday be able to help others the same way I was.