Approximately 4 years ago, a senior developer at the company I was working for responded to a feedback request for my annual review. While the phrasing of this particular piece of feedback made it immediately apparent who authored it, I'll forgo sharing his name. The feedback itself left an immediate impression and remains with me to this day, as vibrant as when I first received it:
"CoE asks a lot of good questions and, often, his questions have the effect of bringing everyone to a uniform level of understanding."
While I pride myself on finding the right questions to ask, I'm not sharing the above to sound my own trumpet. Instead, I'm sharing it as there's a powerful message within. Before I attempt to convey it, however, allow me to paint a rather plausible picture for you.
You're on a project and a developer on your team is tasked with the troubleshooting and resolution of a particular defect. Further, the project manager informs this developer that this issue is very important and needs resolved as soon as possible. Let's call this developer "CoE". CoE nods in affirmation and gets to work.
The next day, your team has standup and CoE shares that he is still working on it but is making progress. Another developer chimes in with some feedback:
"Hey, I was thinking about this a bit. Have you done a sanity check by going through all our bundles in Felix and seeing if any services are failing to resolve?"
"Well, I've poked around Felix and, yeah, I'm not seeing anything jumping out at me there but I can take another look. Thanks."
Another day goes by and another standup arrives. CoE chimes in with his update and it sounds very, very similar to yesterday's:
"I'm currently looking into bug ABC-123. I should have it done today but will reach out if I get stuck."
A member of the team speaks up:
"Have you confirmed that the service is even being injected properly? Like, do you have an instance within the class?"
CoE doesn't hesitate with his response:
"Oh, yeah, it looks like I have an instance or at least last time I checked. I mean, I didn't see anything that would lead me to believe there's no instance."
What's wrong with the above picture? It's not as if CoE isn't working hard. He probably is. And it's surely not the case he wants to just spin on this particular issue. I'm sure he wants it done and off his plate just as bad as you do. So what gives?
Often times, the culprit is simply a matter of programmer pride or, what I jokingly refer to as "proudgramming".
In the IT industry, there's an unspoken, self-applied stigma associated with not knowing something. It's often considered taboo to admit ignorance and this results in several negative behaviors:
- Reluctance to ask for help
- Claiming understanding within areas of deficiency
- Mistaking "working hard" and "putting in hours" for "providing value"
The rub, though, is that it's only taboo because we allow it to be. We reinforce this behavior through repitition. Everyone wants to be seen as competent in all things and, quite frankly, that's not realistic. For CoE, the fruitless hours of poking around to no avail are better than an alternative where he "admits defeat" and asks for help.Consider, though, an alternate reality where he asks the second developer for assistance with debugging. Consider the learning experience available to CoE were they to sit down together and, within 10 minutes, unveil that the service instance is always null because whomever wrote this WCMUse class didn't understand that OSGi dependency injection would have already fired by the time this particular class is instantiated. Picture the log tailing by on CoE's second monitor with a big, old NullPointerException.
The unfortunate reality is that we all have been CoE in the past and it's extremely likely we'll be CoE again in the near future. The self-perceived embarassment resulting from ignorance on any topic seemingly always trumps the alternative where we actually learn something new and grow as a developer. This is sad news indeed.
So what can we do to combat this?
For those in a position to help on a given topic, I encourage you to never, under any circumstance, meet someone's question with disdain or indifference. Realize that, for each answer which comes easily to you, there's myriad potential answers to unasked questions which would all be news to you...
For those with questions, which is to say literally everyone, ask. Be shameless. If you are unclear on any particular topic, ask a question and ask it aloud. There is a better than average chance that someone else in ear shot will benefit from your initiative.
And, lastly, for everyone: when discussing things amongst your team, be diligent and proactive in establishing a base level of understanding. Let no one off the hook with an incorrect, partial, or completely absent understanding.
Remember: only you can prevent proudgramming.