Menu

Subscribe

Is Critical Thinking the Most Important Skill for Software Engineers?

Critical thinking will only become more important as AI tools spread more. How do you get better at this, and why do yourself a service by rejecting jargon and by not taking things at face value from "thought leaders."

When I think back on the software engineers I looked up to, they all shared this trait where they never took anything at face value. They regularly questioned statements that did not make sense to them, no matter how small the topic was: even if it involved admitting they did not understand a concept. After a while, I started adopting this approach.

I still remember being in a meeting where a Very Respected Engineer was explaining how they are building a project, and they said something along the lines of "and, of course, idempotency is non-negotiable." I didn't know what idempotency was, and thus I could not tell why it was non-negotiable. I looked around, and everyone was nodding: but I knew I was missing something.

So I raised my hand and asked if they could explain what idempotency was, and why it was non-negotiable. This person explained it. As we got into details, it turned out that there was some part that was negotiable: as we didn't need idempotency for all endpoints.

After the meeting, I asked other engineers in private who were nodding along if they knew what idempotency was. Three out of the four people admitted they also had no idea, and were glad I asked. So then, why were they nodding along? And why did it feel to me that I needed "courage" to admit I did not understand something and ask for an explanation?

Jargon masks partial understanding

I can answer why I felt uneasy about asking what a term like idempotency means: it's because I was admitting that I don't understand a part of tech jargon. And, to be fair, such admission implies that my professional experience or skills are below the person who knows what this jargon means, and knows how to use it.

Or does it?

Throughout my years as an engineer and later as an engineering manager I started to observe something interesting. Some senior+ engineers loved using jargon and used it all the time. However, they did this in an odd way:

  1. They would often "shut down" less experienced engineers by throwing in jargon, and then pointing out that those engineers did not understand the conversation. Basically, they were locking out these more junior engineers from discussions: and those engineers started to avoid talking to these more experienced engineers.
  2. They would "win" some arguments by throwing in jargon, and asserting their professional dominance
  3. Their arguments were not always sound: and when I could follow along - knowing the jargon by now! - I could challenge them. But anyone not understanding jargon could not do the same.
  4. When asked to explain their ideas without jargon, they either struggled or refused to do so.

Of course, I am generalizing, and there were a few engineers who used jargon, and could also explain things simply, and were open to doing so when less experienced people were around. By I started to develop wary of engineers who refused to explain things in simple terms when asked to do so.

If someone cannot explain a concept without jargon, I now doubt they truly understand what they are talking about. The true test of properly understanding a given topic is whether you can teach it to someone else. Explaining your thoughts without the use of jargon - or gradually introducing jargon - is a form of teaching, as you need to adopt to someone who has less domain knowledge.

When you hear someone use jargon you don't understand: ask the other person to explain in simpler terms. Doing so helps with two things:

  1. It improves your understanding, and you learn what the jargon means.
  2. If the person cannot explain their thoughts with little to no jargon: either they also don't fully understand the language they use, or they struggle to communicate a complex concept in simpler terms. Either way: their ongoing jargon usage masks that they have yet to properly understand what they are talking about. Dropping some of the jargon might even be beneficial to them!

The rise of the "thought leader"

Another phenomenon I'm observing in engineering circles is the rise of "thought leader" or "tech influencer" type of people on social media. These are people who have a sizeable following or subscribers, and are often labeled like this by others, or sometimes reference themselves as such. I now also find myself in this group, thanks to larger than usual social media numbers in terms of audience and more and more people referring to me as a "thought leader" or "influencer," whether I like it or not (and I don't like it.)

These people - like myself - share opinions, observations, and views. Many less experienced engineers take these views at face value, assuming as many other people are paying attention to this person, this "famous" person must be right.  

I can assure you that this is not the case. There is little connection between social media signals like the number of followers and the depth of expertise. If anything, domain experts tend to have a much smaller profile on social media, as they are busy with work, and relatively few domain experts make regular time for social media.

I urge people to avoid taking statements from "famous" people at face value and use critical thinking. Ignore the social media signals - like views, followers, and so on - and focus on the argument. Is it an opinion that comes with no backing? Is it an observation from their environment? Do they have any references to point to?

Instead of taking recommendations from these people: take whatever they share as input, and then do your research. If it's a recommendation of a tool or technique to use: don't use it right away, but stop and think if you have a problem you need to solve that this tool or technique can help with. If so: gather alternatives, and compare them.

This point on "thought leadership" applies to me as well and to this article: I suggest you not take it at face value just because of social signals like likes, views, and so on. Those are all poor signals.

Is accepting jargon usage and giving in to "thought leadership" resulting in less critical thinking?

Both "jargon architects" and "thought leaders" are figures of unlikely authority. Even though neither group has any formal control or elevated domain expertise, I observe fewer people challenging them in a professional setting.

For "jargon architects," this tends to happen because engineers assume that as they don't understand the jargon, they must also not understand the thought process, so do not challenge them.

For "thought leaders," many people assume that because many "follow" this person, their insights must be universally applicable.

So challenge both!

Critical thinking is an approach that helps avoid being influenced by both groups: and thus helps avoid wasting time following recommendations with basic flaws, or approaches that won't work for your use case. And by questioning ideas, you also improve your critical thinking.

Improving your critical thinking muscle

The software engineers I looked up to, who always challenged when they did not understand something: they were all, without exception, critical thinkers.

So how do you get better at critical thinking? My approach is to simply 'think for yourself,' and don't move on until you understand why to do things, or how things are done. A few approaches I follow, that could also be helpful for you:

  1. Un-jargon the jargon. If you come across jargon you don't understand: get to understand this! If someone is telling you jargon terms, ask them to explain simply, and challenge them if they cannot do so. Otherwise, understand the jargon in simple terms, yourself. ChatGPT can be an unexpectedly useful to break down jargon terms: just don't forget to verify its definition, as ChatGPT can make things up.
  2. Validate information and do your research. When presented with information: don't assume it is correct. Look for sources, and question where the details come from. An example of this was how, when I was writing a book on resumes, I came across the concept of "ATSes rejecting resumes." that hundreds of sites took over on the internet. I was sceptical that any system would automatically reject resumes, because I never saw this as a hiring manager. I did research, and turns out all of this is a hoax: but many software engineers writing their resumes assume it to be true.
  3. Ask "why" and "how." Until you understand why something is done, or how something works: keep asking, and keep researching. This is a useful skill in all parts of life: from challenging the product person on why a piece of work needs to get done, to talking through with a peer on how a new system will be built, and finding edge cases that no one thought of.
  4. Avoid following the crowd, when you have not cleared #1, #2, and #3. I've observed several hype cycles in tech when people get involved in new areas in technologies, when they lack understanding of how things down. Crypto/blockchain was a good example: I observed engineers get into the space without being able to answer what blockchain was, or how it worked, and how it compared to other alternatives, and what practical use cases were. My point is not that you should not get into new areas - because you should! But do your research and apply critical thinking before you do. Despite the recent cooling, the engineers who did this are still in the space because they know why they got involved. People who did not such research and just followed the crowd, hoping to make a lot of money: they got disappointed and left, feeling burnt.

Critical thinking will only become more important as AI tools spread more. Without critical thinking, you let others do a lot of the thinking for you, and fail to spot problems with arguments. When encountered with jargon, you assume the other person must know better. Similarly, when coming across a "thought leader," you assume they must be right.

What happens as AI-generated text becomes more common, and perhaps some of your colleagues will "outsource" their thinking to these tools?

There will be the people who don't fully understand the output, but assume it must be right. And there will be the critical thinkers, who question the parts they don't understand.

It's not hard to predict which group will be more successful, professionally.

Featured Pragmatic Engineer Jobs

The above jobs score at least 9/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.