Breaking Through

Breaking Through

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:

"Josh 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, there's a powerful message I want to shine a light on. Before I do, however, let me briefly paint a 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 "Chris". Chris nods in affirmation and gets to work.

The next day, your team has standup and Chris 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 bundles in Felix and seeing if any services are stuck in installed state?" 

He responds. 

"Well, I've poked around Felix and, yeah, I don't remember seeing anything jumping out at me there but I can take another look. Thanks." 

Another day goes by and another standup arrives. Chris 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?" 

Chris 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." 

Pause...

What's wrong with the above picture? It's not as if Chris 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 repetition. Everyone wants to be seen as competent in all things and, quite frankly, that's not realistic. For Chris, 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 Chris 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 Chris's second monitor with a big, old NullPointerException.

The unfortunate reality is that we all have been Chris in the past and it's extremely likely we'll be Chris again in the near future. The self-perceived embarrassment 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.

I wrote the above post during my time at 6D Global where I learned and grew an immense amount both technically and professionally. I'd like to thank them for the permission to republish this post on LinkedIn under my own name.

Couldn't have made the point so beautifully. In an earlier company, I was told by my manager, that I ask 'stupid questions' and I should instead read - https://www.amazon.com/Art-Asking-Better-Questions-Answers/dp/0137144245 The book (and my manager's intentions) were good, but the way that was communicated could be discouraging for some. And many a times questions putting someone else in difficult situation are considered 'stupid'. My funda - A sincerely asked question with serious intent to know and learn can never be a stupid question. And depending upon how much keen you are to know and learn, ask it.

To view or add a comment, sign in

More articles by Josh Boyle

  • AEM Edge Delivery Services and AEM Sites: Competing or Complimentary?

    In a previous post, I walked through what was called at the time AEM Franklin and compared it to that time's current…

    2 Comments
  • What Exactly IS Content Supply Chain?

    You've probably heard about it from Adobe Summit 2023 and you're going to hear more about it at the 2024 edition…

  • Introduction to the AEM Universal Editor

    Authoring page content via components in a WYSIWYG manner has always been a central feature of AEM. This user…

    8 Comments
  • AEM Franklin vs AEM Sites

    As you may have heard from #adobesummit2023, Adobe's "next-gen content management system" is none other than AEM…

    27 Comments
  • An Introduction to AEM Franklin

    Adobe is constantly pushing the bleeding edge of technological innovation with their products. Whether it's the…

    7 Comments
  • AEM Tech Bits: An Introduction to AEM as a Cloud Service

    A couple days ago, Adobe officially announced the general availability of AEM as a Cloud Service. I've worked with…

    9 Comments
  • AEM Marketing Bits: Stop Trying to Please Everyone

    Introduction If I had a dollar for every project I've been on where multiple tenants fought to enforce their way of…

  • AEM Tech Bits - Useful QueryBuilder Queries

    It's been a while since my last post and, man, what a busy few months it's been. I've been hard at work at my client…

    1 Comment
  • AEM Tech Bits - A Word on Versioning

    Typically versioning in AEM is something only thought of in the context of pages. In fact, the common way in which one…

  • AEM Tech Bits - Programmatic Cache Deletion

    Every AEM infrastructure leverages the dispatcher for one or all of caching, security, and load balancing. As far as…

    4 Comments

Others also viewed

Explore content categories