The persistent inability to believe that one’s success is deserved or has been legitimately achieved as a result of one’s own efforts or skills.

Which seems to make sense in a highly cognitive environment where Software Developers find themselves.

I’m always amazed in office environments at how professional and serious everyone appears to be at first glance. When you go into an office for the first time, be it an interview or a new position, you see people sat at their desks working fastidiously on some complicated UI on the monitor. They’re dressed seriously, their expression is one of seriousness and concentration and there is that low level noise of keys being tapped and mouses (mice?) being clicked and serious work being done!

It’s even more compelling in an office full of developers. Their screens are much more elaborate and impressive. Screens filled with dark squares placed precisely into strategic compartments with rows of different coloured text flashing continuously across them. Terminal windows printing rows and rows of obscure text and different windows popping up here and there and then quickly disappearing again. It’s very easy to be convinced these people are geniuses who are operating at a super human level and that you have no right to be amongst these rarified supreme individuals.

I get it… However…

As you peer closer the illusion starts to shrink away. That terminal window you thought they were using to hack into some top secret government server is actually being used to ssh into a AWS server to check the right docker image is running. That rows and rows of different coloured text is actually some HTML which is used to render the ‘About Us’ section on the company website. That unrecognised text editor one developer is using is actually just Neovim… wait! That guy is a genius! I jest… but my point is, if you understand what these developers are actually doing its all very logical and usually not so complicated.

I Rarely Asked Questions as a Junior Developer

I remember very distinctly the feeling I felt when starting out as a developer. I started with 4 other developers of different skill levels at exactly the same time. I was the developer with the least technical experience. In all honesty I think I was lucky to get the job from a technical perspective. I had other skills from my previous working background but my technical skills were distinctly lacking.

I knew this and I couldn’t shake the thought that I ‘should know more’ (I’ve later come to realise that ‘should’ is a very dangerous word to tell oneself). I almost felt guilty for not knowing things and if anyone was to find out I didn’t know certain things then that’s it! The game is up. My head will be on the chopping board and I would be sent packing with my tail between my legs. In order to avoid this potential scenario I adopted the best strategy available to me. Silence! Silence is golden they say.

I chose this strategy because I figured if I don’t say anything, then I can’t say anything stupid. If I were to say something stupid then my colleagues would quickly figure out I am a fraud and I will be exposed. If I didn’t say or ask anything then my colleagues will just assume I already know whatever they happen to be talking about. I will be the silent developer in the corner. The mysterious quiet one. Or so I thought.

Questions are Actually Useful

This strategy however had one major downside. I couldn’t ask questions. It turns out (and this might come as a massive shock) that questions are really useful for finding out things. If you don’t know something and you’re speaking to a person who does know something, by asking questions you can find out what they know. Incredible right!

But choosing a strategy of silence makes the strategy of asking questions difficult. VERY difficult. I therefore had to resort to finding things out by other means. Reading Stackoverflow (it was a site used before ChatGPT to find answers to specific programming questions), searching through Google (it was a site used before ChatGPT to find links to specific websites that might provide insight to whatever specific problem you have) and watching tutorials (do people still watch tutorials?).

Looking back, maybe this actually had some benefits. I learnt to be self sufficient. I learnt how to be resourceful even in the face of seemingly insurmountable challenges. I learnt from other developers albeit through reading instead of talking.

Learning From Those Around You

Adopting this strategy meant I missed big opportunities to learn from those around me. This is one of the beautiful things about working in a team. You get to speak and learn directly from colleagues who will all have different levels of experience. Many would have toiled and suffered to learn certain things that they can then teach you in 5 mins. And vice versa, those things you have learnt the hard way might be just what your colleagues need on a certain project.

The Power of Questions

I am not sure exactly when the penny dropped for me, but it was after many years of developing. Maybe the fact I hadn’t been kicked out the team yet and had actually received a promotion started to alleviate fears that I was a complete imposter.

I had also read Jordan Peterson’s book where he speaks about ‘Asking Questions’. I’m paraphrasing but he basically said if you are ignorant and you ask questions, first off the person you are talking to can understand where your gaps in knowledge are so they can focus on those parts in their explanations and secondly, if you ask 1000 questions pretty soon you’re not going to be ignorant anymore.

For some reason this really clicked with me so I decided to drop my pride and when I didn’t understand what someone was talking about I would ask questions. Even if I thought I ‘should’ know the answer. Turns out this is actually a better strategy than silence.

I started getting a better understanding of problems coming my way. I started learning things that I had been too afraid to ask about previously. I started to better understand different developers’ points of views.

This strategy does come with a caveat though. You can’t just constantly be asking questions and expect all the answers to come your way. Have everyone else do the hard work of finding stuff out so you don’t have to. You have to still put effort in and do some work to find answers yourself so then when you do have questions, it’s obvious to the person you’re speaking with that you have done all you can on your side.

Bad Questions

An example of a bad question would be coming into a meeting and asking ‘What’s this meeting about?’ when the agenda has been clearly defined in the invite. This just comes across as you being lazy and unprepared which are not good traits in a professional working environment. Your colleagues will silently notice this.

Another example of a bad question is asking questions which have been answered or addressed in the recent past. Say you’re in a meeting and someone presenting is explaining what a particular section of code does. If you then ask 2 minutes later what that particular section of code does then it just looks like you weren’t listening. By all means ask questions to clarify certain aspects of what they are explaining but don’t just ask lazy questions because you weren’t listening or paying attention.

Conclusion

There is so much to know and learn in the world of Software Development and you will never know everything. To that end it’s OK to not know. It’s therefore ok to ask questions. In fact asking questions helps clarify to the other person what you understand about what they’re saying and what you don’t. It gives them hints as to what they should focus on elaborating in order for whatever is being discussed is understood by all.

Questions in team settings can also really help because if you don’t know something then chances are someone else in the room also doesn’t know so you’re doing you and that other person a favour by asking questions.

However, don’t be lazy with your questions and don’t ask questions about absolutely everything. This can have the opposite effect to what you may have hoped.