Yes, though it does give a feel of dismissing people who mostly learned on their own.
In my experience, these two learning sources - your peers at work, and your own research - yield different type of knowledge. To show you what I mean, let's dissect an example from the article:
> Think about the difference between being able to write functions that print out to your terminal versus creating a class with methods that return text to pass to other methods that checks for sanitized inputs, and then passes it to a front-end.
This belongs to "objective level" of working with code: how to write correct and efficient code, how to build the right abstractions, how to make it work in context of a larger system, etc. This kind of knowledge is something very amenable to self-directed learning: studying books, writing code, reading code, playing around, getting a feel for handling complexity, for how thoughts map to code, and code maps to execution.
> Now imagine that that class is a function that has to be packaged to work in the cloud. And, on top of that, imagine that the function has to be version-controlled in a repo where 5-6 people are regularly merging code, pass CI/CD, and is part of a system that returns the outputs of some machine learning model with latency constraints.
This belongs to "meta level" of working with code: how to write code in business context, how to collaborate with colleagues. It's not software skills - it's business skills and people skills. Both learned best through experience on the job.
Point being, the two types of knowledge/experience are somewhat orthogonal, though they reinforce each other. You won't learn how to write good code by just interacting with your peers at work, not unless one of those peers is learning independently and applying their knowledge to raise the craftsmanship level in the shop. But then, working in a team, under time and budget pressure, introduces tradeoffs that affect the way you code, in a way you just can't reproduce on personal projects.
To sell your skills to a business, and for that business to make use of them, you really need both types of learning. Companies understand the need for learning from peers well (perhaps too well, it's becoming a pro-office argument), but I wish they also understood the need for self-directed learning better, and allocated resources accordingly. As things are right now, I feel the progress in our industry mostly rests on people who are either paid to do R&D, have time to do learning off-work, or are just learning independently at work and not telling their boss.
As someone who’s had a grand total of 3 CS courses, in which were mostly taught things I already knew, I didn’t find it at all dismissive. Remember, it says “no one becomes a good software engineer by themselves,” (emphasis added), not “you can’t learn to program well on your own, or “you can’t effectively self-study CS.” There’s a big difference.
In my experience, these two learning sources - your peers at work, and your own research - yield different type of knowledge. To show you what I mean, let's dissect an example from the article:
> Think about the difference between being able to write functions that print out to your terminal versus creating a class with methods that return text to pass to other methods that checks for sanitized inputs, and then passes it to a front-end.
This belongs to "objective level" of working with code: how to write correct and efficient code, how to build the right abstractions, how to make it work in context of a larger system, etc. This kind of knowledge is something very amenable to self-directed learning: studying books, writing code, reading code, playing around, getting a feel for handling complexity, for how thoughts map to code, and code maps to execution.
> Now imagine that that class is a function that has to be packaged to work in the cloud. And, on top of that, imagine that the function has to be version-controlled in a repo where 5-6 people are regularly merging code, pass CI/CD, and is part of a system that returns the outputs of some machine learning model with latency constraints.
This belongs to "meta level" of working with code: how to write code in business context, how to collaborate with colleagues. It's not software skills - it's business skills and people skills. Both learned best through experience on the job.
Point being, the two types of knowledge/experience are somewhat orthogonal, though they reinforce each other. You won't learn how to write good code by just interacting with your peers at work, not unless one of those peers is learning independently and applying their knowledge to raise the craftsmanship level in the shop. But then, working in a team, under time and budget pressure, introduces tradeoffs that affect the way you code, in a way you just can't reproduce on personal projects.
To sell your skills to a business, and for that business to make use of them, you really need both types of learning. Companies understand the need for learning from peers well (perhaps too well, it's becoming a pro-office argument), but I wish they also understood the need for self-directed learning better, and allocated resources accordingly. As things are right now, I feel the progress in our industry mostly rests on people who are either paid to do R&D, have time to do learning off-work, or are just learning independently at work and not telling their boss.