Equating learning programming with learning a musical instrument was an interesting take. Like most analogies, it fits in some ways and doesn't in others, but the ways that it fits ring quite true. Programming is in large part an art and an act of constant 'practice'.
A lot of us divide into two camps - "self-taught is better" or "university is better". In interviews I've ran in the past, I've often been an advocate for lesser considered candidates that lacked formal degrees but showed exceptional understanding of the craft. I've also been on the side of devaluing the degree of a person due to their lack of experience or quality code that demonstrates their practical abilities. Self-taught programmers can lack some of the foundation of software craftsmenship, but not always. It usually just depends on how long they've been at it and what their exposure is to large projects. The self-taught tend to start out like self-taught musicians -- "do first" then learn the specifics later...if they're needed at all. Unlike a musician -- who might be able to get away with never learning to read music or understanding anything about music theory, it's not possible to design a supportable piece of software without understanding major core concepts of computational theory, or design practices like 'SOLID' and the Single-Responsibility Principal. The moment you have to extend a large program you've written, you discover these mistakes and tend to start learning them.
Here's the thing, though. Self-taught programmers get jobs the same way as everyone else because we're all self-taught. The moment we leave University, our skillset and even parts of computational theory, become outdated (or maybe our skillset was already outdated due to the choice of technologies that the school decided to use)[0].
Regardless of being self-taught or University trained, I look for people who can demonstrate a constant state of learning. I like a candidate who knows the language I'm targeting for a job, but comes in talking about a couple of other languages that they're poking around with and find interesting (as well as understanding why they find them interesting). Way too often we'd get University graduates who clearly chose Computer Science because someone told them that those jobs pay well[1]. They had little-to-no passion for it, had no hobby-projects[2] and had nothing to show me that would demonstrate an ability to actually write code in the language we were seeking candidates for. On the two occasions we landed a candidate with no formal education in software development, I advocated for both of them (with strong disagreement from the other interviewers)[3].
[0] I often joke that anything I've written six months ago might as well have been written by someone else... someone else who doesn't know what they're doing. Part of that is because I strive to hone my craft. I want to feel this way about old code. But there's another side to this phenomenon. If I study the code carefully, my biggest complaint is usually that I've chosen an overly complex approach when there was a much easier way to do something. Further investigation usually yields that this much easier way only became possible shortly after or during the middle of the time that the majority of this code is written due to features being added to the language or runtime that weren't there previously. I'm not sure there's another industry where I can look at a product and think 'that design is just ... ugly' when it was cutting-edge 6-months ago ... maybe hair-styling?
[1] Part of this was that the only job I had where I was regularly interviewing candidates was for a somewhat non-sexy IT development position at a large company who's primary business wasn't technology. It didn't naturally attract passionate programmers looking to solve interesting problems so we got the candidates that were probably the most appropriate for the job we were posting.
[2] And by none, I mean literally no code to show me. I wasn't even expecting them to come with a few GitHub repos of personal projects -- A blog post describing something related to programming, a Pull Request to another person's GitHub repo or even a single Stack Overflow or a programming-centric forum of some kind would have been nice. Nope. And since I refuse to do white-board coding, that pretty much disqualified the candidate.
[3] The first was somewhat reluctantly hired due to my persistence. I made the argument and backed it up with the code the candidate had showed off in the interview -- personal project code that was written very well. He was such a successful hire that I ended up doing many later interviews and the second time this issue came up, the candidate was hired on my recommendation without the required persistence. Both quickly became senior developers. Both, also, left after a couple of years for more interesting work.
A lot of us divide into two camps - "self-taught is better" or "university is better". In interviews I've ran in the past, I've often been an advocate for lesser considered candidates that lacked formal degrees but showed exceptional understanding of the craft. I've also been on the side of devaluing the degree of a person due to their lack of experience or quality code that demonstrates their practical abilities. Self-taught programmers can lack some of the foundation of software craftsmenship, but not always. It usually just depends on how long they've been at it and what their exposure is to large projects. The self-taught tend to start out like self-taught musicians -- "do first" then learn the specifics later...if they're needed at all. Unlike a musician -- who might be able to get away with never learning to read music or understanding anything about music theory, it's not possible to design a supportable piece of software without understanding major core concepts of computational theory, or design practices like 'SOLID' and the Single-Responsibility Principal. The moment you have to extend a large program you've written, you discover these mistakes and tend to start learning them.
Here's the thing, though. Self-taught programmers get jobs the same way as everyone else because we're all self-taught. The moment we leave University, our skillset and even parts of computational theory, become outdated (or maybe our skillset was already outdated due to the choice of technologies that the school decided to use)[0].
Regardless of being self-taught or University trained, I look for people who can demonstrate a constant state of learning. I like a candidate who knows the language I'm targeting for a job, but comes in talking about a couple of other languages that they're poking around with and find interesting (as well as understanding why they find them interesting). Way too often we'd get University graduates who clearly chose Computer Science because someone told them that those jobs pay well[1]. They had little-to-no passion for it, had no hobby-projects[2] and had nothing to show me that would demonstrate an ability to actually write code in the language we were seeking candidates for. On the two occasions we landed a candidate with no formal education in software development, I advocated for both of them (with strong disagreement from the other interviewers)[3].
[0] I often joke that anything I've written six months ago might as well have been written by someone else... someone else who doesn't know what they're doing. Part of that is because I strive to hone my craft. I want to feel this way about old code. But there's another side to this phenomenon. If I study the code carefully, my biggest complaint is usually that I've chosen an overly complex approach when there was a much easier way to do something. Further investigation usually yields that this much easier way only became possible shortly after or during the middle of the time that the majority of this code is written due to features being added to the language or runtime that weren't there previously. I'm not sure there's another industry where I can look at a product and think 'that design is just ... ugly' when it was cutting-edge 6-months ago ... maybe hair-styling?
[1] Part of this was that the only job I had where I was regularly interviewing candidates was for a somewhat non-sexy IT development position at a large company who's primary business wasn't technology. It didn't naturally attract passionate programmers looking to solve interesting problems so we got the candidates that were probably the most appropriate for the job we were posting.
[2] And by none, I mean literally no code to show me. I wasn't even expecting them to come with a few GitHub repos of personal projects -- A blog post describing something related to programming, a Pull Request to another person's GitHub repo or even a single Stack Overflow or a programming-centric forum of some kind would have been nice. Nope. And since I refuse to do white-board coding, that pretty much disqualified the candidate.
[3] The first was somewhat reluctantly hired due to my persistence. I made the argument and backed it up with the code the candidate had showed off in the interview -- personal project code that was written very well. He was such a successful hire that I ended up doing many later interviews and the second time this issue came up, the candidate was hired on my recommendation without the required persistence. Both quickly became senior developers. Both, also, left after a couple of years for more interesting work.