While it is true that it's hard to find very talented people, it seems to me that we only require very talented (as opposed to say "above average") people because of defects in pedagogy and engineering.
Another way of saying this
1: the number of software problems that I believe inherently require someone in the top 1% raw brain power is much lower than we think.
2: One major reason why #1 is true is that we are bad a teaching people to program
3: Another reason why #1 is true is that we are bad at managing the complexity of our systems.
So while the short term solution to #1 may be to only hire the best of the best, I think the long term solution is to address #2 and #3. I will further assert that there is probably a lot of low-hanging fruit for #2 and #3 though #3 has definitely improved a lot over my career.
I am not at all an expert on pedagogy, but I have definitely noticed learning programmers being completely baffled by things that I can teach them in an hour or two (it's obvious that having experienced software engineers tutor learning programmers is not a reasonable solution, and it's a completely non-interesting result that 1-on-1 tutoring is more effective than classroom learning) so I have some reason to think there may be improvements made there; even my 1-on-1 tutoring has greatly improved with help from my sister who is a very skilled instructor in a non-programming related field.
There is also the simple fact that the angular 2 demo app (shows 10 cards with 1 field) requires knowledge of
* bash shell
* TypeScript
* Typescript templating (and how the 2 way binding between HTML and TypeScript/Javascript works)
* HTML (at least 2 versions. I mean technically not required 2 versions, but you're going to use both flex and non-flex layouts, you're going to use HTML5 and legacy syntax, ...)
* CSS
(and various related things like DNS, how browser URL's work, including their javascript API of course,
And the use of separate frameworks:
* npm (bash)
* typescript standard library (typescript)
* angular (typescript/dart)
* rxjs (javascript/typescript)
* bootstrap (CSS)
And this is just the frontend. This does not save any data, request any data outside of the app itself or interact with anything, so let me just add what one might use as a backend on top of this:
* golang/python/java/perhaps C++ (ok I suppose you could use typescript, but ... really ?)
* protobuf (unless you want to manually sync frontend/backend)
* postgresql
I believe this to be one of the easier options for the backend. And effectively necessary:
* git or perhaps svn
* docker or something like it
* ssh
* at least one server running remote on the internet
(I would like to point out that if you wanted to that video actually shows you everything you need to make, say, a contract tracking app, whereas if you fully follow the angular demo, and then also build the backend behind it, there's more you need to know before you'll be anywhere close to that dbase app. For example that angular app will crash if you put a million records in it, and you are very far from having master-detail-detail views. Also that dBase app will actually check the fields)
(And I've been doing angular for 2.5 years. May God have mercy on your soul if your boss asks if the table can please have custom fields and sorting criteria)
> it's obvious that having experienced software engineers tutor learning programmers is not a reasonable solution, and it's a completely non-interesting result that 1-on-1 tutoring is more effective than classroom learning
For the record, it's not obvious. Many people have suggested an apprenticeship system for software engineers would be an improvement.
I'm not sure it's the system I'd choose, but it isn't obviously bad to me.
I believe programming is one of those things where 1) a lot of knowledge/ability can be transferred in a tutoring setting, and 2) the worth of this is high (considering the cost/benefit of good programmers).
While I find it hard to properly explain this, my experience is that this is not as 'obvious' for many kinds of jobs. Off the cuff I'd say it has something to do with the relatively insular/individualistic nature of programming (although I'd say this applies even to larger entities like a company), as well as the general 'craftsman' feeling I get from how my job actually feels.
Perhaps tooling also plays a big role. I'd say a sizeable chunk of my improvement when it comes to doing my job fast and well consists of using the right tools. When I sit down with other programmers, I'm often amazed by how much time they waste (and I used to waste) using suboptimal 'tooling'. These are things that are often difficult to learn from tutorials or classes.
Regardless, if I were to have junior programmers under my wing, I'd probably try to make sure there's some degree of tutoring going on, not just for the benefit of the juniors, but because I think it can really make a huge difference in their value to me.
Y'know, that's actually an interesting thought. Maybe most programming's best understood as a craft or trade, like being a plumber or electrician[1]. It's a fundamentally blue-collar job that you happen to do while sitting at a keyboard. It's like if we insisted that all electrician work, including things like house wiring and utility pole maintenance, required a full four-year electrical engineering degree.
[1]This is not an insult. "X is basically just plumbing" is said with a sneer by fools who drastically underestimate how difficult and complicated plumbing actually is. There's a reason they're so expensive.
> I will further assert that there is probably a lot of low-hanging fruit for #2 and #3
Hmm...that low hanging fruit in #2 may not be quite as low or quite as tasty as you think.
See "The Early History of Smalltalk", by Alan Kay[1], where early successes in teaching this stuff led to great optimism that was quickly dashed by reality.
"[The adults] were able to get through the initial material faster than the children, but just as it looked like an overwhelming success was at hand, they started to crash on problems that didn't look to me to be much harder than the ones they had just been doing well on. "
"They couldn't even come close to programming it. I was very surprised because I "knew" that such a project was well below the mythical "two pages" for end-users we were working within."
"Finally, I counted the number of nonobvious ideas in this little [2 page] program. They came to 17. And some of them were like the concept of the arch in building design: very hard to discover, if you don't already know them."
"Looking back, this could be called another example in computer science of the "early success syndrome." The successes were real, but they weren't as general as we thought. They wouldn't extend into the future as strongly as we hoped. "
"They can answer any question whose answer requires the application of just one of these tools. But it is extremely difficult for them to answer any question that requires two or more transformations"
Another way of saying this
1: the number of software problems that I believe inherently require someone in the top 1% raw brain power is much lower than we think.
2: One major reason why #1 is true is that we are bad a teaching people to program
3: Another reason why #1 is true is that we are bad at managing the complexity of our systems.
So while the short term solution to #1 may be to only hire the best of the best, I think the long term solution is to address #2 and #3. I will further assert that there is probably a lot of low-hanging fruit for #2 and #3 though #3 has definitely improved a lot over my career.
I am not at all an expert on pedagogy, but I have definitely noticed learning programmers being completely baffled by things that I can teach them in an hour or two (it's obvious that having experienced software engineers tutor learning programmers is not a reasonable solution, and it's a completely non-interesting result that 1-on-1 tutoring is more effective than classroom learning) so I have some reason to think there may be improvements made there; even my 1-on-1 tutoring has greatly improved with help from my sister who is a very skilled instructor in a non-programming related field.