It’s definitely up there.

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.

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.

Critical thinking is definitely important, but I would say that the most underrated skill is communication (spoken and written).

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.

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.