I wouldn’t necessarily say it’s critical thinking as that’s too wide a term to be useful. What I would put in my top 3 skills are:
- problem decomposition
- curiosity
- being open to feedback / criticism
Problem decomposition allows you to take huge problems and fix them as if they’re nothing more than a few tiny issues.
You won’t learn anything after the initial knowledge required to do your job and keep on growing without being curious.
The same can be said for feedback, a lot of people attach their ego to their work. This is such a limiting factor, holding you back from improving in areas you weren’t aware of.
I like problem decomposition a lot as a discrete step. There’s a huge tendency to go, I have problem A, let’s just solve with it B. Many times the nuance of why A occurred, whether it’s a symptom of something, and what are the different subproblems that comprise A are skipped.
This often causes solutions which don’t actually solve the problem, or just mask it. That extra effort up front, leads to the proper solution, and as you said, very tactical fixes instead of huge unnecessary solutions.
I’d say the ability to understand a problem set and break it down into pieces is the most important skill for software engineers. You can have all the AI tools you want, but if you don’t truly understand what it is you are trying to solve, you will likely end up at an over-engineered solution that requires consistent iteration.
Critical thinking is definitely important, but I would say that the most underrated skill is communication (spoken and written).
Definitely agree there! Communication is super underrated, especially with how difficult it can be to align people and teams across organizations.
Also communication: issues, blockers, requirements, expectations. Nothing works without these things and the ones you mentioned.
Yep, first thought I had when I read the title.
I was lucky I didnt faced this dumb attitude of locking others out of conversation. My experience from my early days is that seniors used jargon, but made sure that everyone understands what is means without any kind of shaming.
That’s why I always considered jargon as useful. It is just some kind of model of point of wiew on some part of reality that we already agreed on (and must be clear to everyone in conversation). There is a saying “all models are wrong, some are useful”. And critical thinking helps you determine if the presented model is useful in your context… or anywhere at all.
So I think it is good to understand some jargon, so you can determine if it fit your needs and brings any value, also you can be the hero who makes sure everybody understands.
Jargon is great for consolidating complexity into just a few words, reducing the things you have to think about. It can be equally valuable though to poke into implicit assumptions that are commonly made.
It’s definitely a balance, and being inclusive in conversations is super important as you mentioned. It allows newer folks to get up to speed much faster in comparison, and allows more engagement across the people within the discussions.
After the last six hours of programming I’d say another huge factor is being able to keep a huge set of logic in your head as you switch between different parts of either the same or multiple projects.
For example, I’m changing one web app to push builds (rather than deploying) and then notifying another web app of the pushed build.
The receiving website authenticates via an nginx forward auth proxy so I had to learn to do basic HTTP authentication against that, actually implement the model, create an API endpoint for it, write tests, etc.
For the sending app, I need to keep track of how the data will be sent, do research on how to make it happen within the context of GitHub Actions, etc.
This is my side project. I’m keeping track of a whole host of issues for what I do at work with Kubernetes and another web app that manages clusters.
Context size is huge, as well as the ability to context switch effectively. It can mean the difference between solving something in a day or weeks.
There we go! That’s what I was trying to spit out.
It’s definitely up there.
Recently in my career I’ve been leading more and larger projects, and a lot of the skills I think more junior devs prioritize, I’ve found myself without. As you move into L4+ roles, I find the more important skills will come from team management, how to decompose problems, and delegate those components correctly given the talents of your other engineers. Critical thinking is important at every step of your career, but probably too broad to say it’s the most important. I feel the very senior engineers at my company are solving broad, architectural and operational issues rather than the individualized or hyper specific issues of the more junior devs. That’s not to say one set of problems is easier or harder than the other, but the senior devs need more “political” or managerial skills, for lack of a better term.
Wow, this blog post does not know itself. It goes into some details, but completely misses the glaringly obvious fact that this is not “critical thinking” issue but one of Professional Communications. Our technology industries are overrun with weak communicators. We all receive gargantuan tech educations, either formally or self taught, but no where in these common and ever present tech education efforts is there any Professional Communications training. This is why the blog author feels afraid to speak up, and is also why his coworkers just nodded along - they have zero training how to speak up! They don’t know how, feel inferior because they don’t know how, and basically get talked into situations they cannot defend against because they can’t explain themselves, cannot explain why some aspect they sense is not correct without emotional baggage and a sense of “insulting the information source”.
We need to recognize our profession needs quality professional communications training across the board in order to prevent the nonsense situations and loss of quality forward progress as described by this blog post.
They don’t know how, feel inferior because they don’t know how, and basically get talked into situations they cannot defend against …
This rings so true to me!
It’s a shame to see clever people get lost in the minutiae. There are good managers out there who can spot these problems and help out. But they’re few and far between. So without good management nor the ability to communicate for themselves you get eye-watering levels of wasted effort.
It depends…
Withought being facetious. It’s genuinely important to understand what problem you’re trying to solve. If stakeholders are running wild, then critical thinking and good communication is important. If engineers are muddying up progress, then more optimistic and enabling mindset, could be what’s needed more.
