No matter how someone comes into the profession--be it via the traditional means of a computer science degree, an intensive bootcamp, or being entirely self-taught--the reality is that the large-scale team-driven nature of modern software is impossible to learn in a contrived setting. There are just some things that can't be taught except on the job. While no list is exhaustive, I believe that five of these skills arise more often than others.

Reading

I don't know why reading is somehow not considered a dev skill, especially reading comprehension, but you will hardly ever hear someone mention it. Yet professionals tell stories all the time about how one line hidden in a manual was all it took to solve a longstanding problem.

Today's software is a complex structure of off-the-shelf build tools, libraries, plugins, and more. The modern dev has to read and digest a lot of code and a lot of documentation if they want success.

Writing

It probably goes without saying but organizing one's thoughts and explaining complex problems and solutions is a key dev skill.

Einstein is said to have observed that "if you can't explain it simply, you don't understand it well enough."

Since code (and its surrounding documentation) has to tell computers as well as humans what needs to be done, it is absolutely vital that a dev can explain clearly what is going on.

Programming is the art of telling another human being what one wants the computer to do.
~ Donald Knuth

Breaking large problems into smaller ones

I remember how nice it was to learn to program. Can I make a clock program that actually ticks off the seconds in sync with a real clock? Yes! Can I help a robot traverse a maze? Yes! Every new program I wrote seemed like an insurmountable task at first. Then I would see the problem, solve it, and end up standing on the top of the "mountain."

Things became a lot more complex on the job. I realized that the programs I wrote while learning were single- or few-problem programs. Of course they were! While I was in school, every program I wrote was due at the end of the month or quarter at the latest. They all had to be limited in some way in order to be deliverable by the end of my time with that professor.

But on the job it's another story. The problems are abstract, large, and unsolvable. It's very important to be able to take a large problem and carefully consider how it can be split into smaller problems until solvable pieces emerge.

W. Edwards Deming once said that "it's not enough to do your best: you must know what to do, and then do your best." That's the job and while it's not easy, it's important!

It is not enough to do your best: you must know what to do, and then do your best.
~ W. Edwards Deming

I think that this is another skill that you have to learn on the job, over time, by solving bigger and bigger problems. However, I do think that a resource like Think Like A Programmer could help.

The Scientific Method

I don't mean merely knowing the scientific method or having used it in the lab portion of a science course. I mean applying it to software by means of posing hypotheses, conducting experiments, observing results, etc.

A dev's on-the-job experience of using the scientific method differs quite radically from the in-the-classroom experience. Observation of a phenomenon (let's say a race condition) is often limited or impossible with given tools. Imagine having to create your own microscope, yet that's often what devs are left with in the real world. Software is often a new abstraction that does not always come with known properties and tooling to observe those properties.

It's important for a dev to face this uncertainty with the one tool proven to bring clarity to chaos: the scientific method.

Negotiating

Devs don't make software alone. This is perhaps the biggest reality facing a dev in the real world. No matter where a dev starts--a bootcamp, a CS program, or being self-taught--it always seems to be in a room (or a chat room at least) with other devs.

Yet on-the-job negotiation requires managing the interests of stakeholders as diverse as salespeople, financiers, technical writers, support personnel, accountants, marketers, users, and many others. The art of negotiation and compromise is vital to any dev's existence.

The more I talk to mature developers who have been in their career five years or more, the more their favorite books become works like Crucial Conversations and How to Win Friends and Influence People. The human side of software becomes the hardest part of the job.

Parting words

Wherever your career takes you, I wish you luck in learning and practicing these skills. I'm on a journey with all of them myself. I don't think anyone is perfect at all of them. But I do think that being aware of these "hidden" skills of software gives anyone a leg-up on building successful, production-ready applications.