Notice anything interesting? It's for a seriously heavyweight distributed systems engineer sure but look deeper. Do you see mention of a single piece of technology? J2EE? JavaScript? Ruby? No, right? How weird is that? How many job specs do you see like that? Surely what matters is whether you know JBoss or Websphere, Java or Erlang or Ruby?
Even though working directly for Werner Vogels may not be for everyone, Dan reflects on the current state in software business:
So often I see companies create job specs for engineers where the key requirement is to hire someone who can hit the deck coding like mad using whatever tools have been selected. To that end they load the specs up with endless tech hubris and at interview ask the details of this or that bit of syntax or API call. But what about the next project within the company where the tech is different? All those engineers that just got hired are now useless, they don't have the skills and we lose time whilst they learn. Or we could fire them and hire another lot?
But how did we end up here?
Years ago, the CS courses at the universities focused on the deeper, underlying principles of computer science, but that tradition seems to die away more and more. Many will argue that this is quite a threat to our industry. Joel Spolsky once wrote an article about the perils of Java Schools, where he described his experiences through the MIT-inspired Scheme course at Penn University:
… I watched as many if not most of the students just didn’t make it. The material was too hard. I wrote a long sob email to the professor saying It Just Wasn’t Fair. Somebody at Penn must have listened to me (or one of the other complainers), because that course is now taught in Java.
I wish they hadn’t listened.
Now when Joel does recruiting, he sees the other side of the coin when he realizes that a lot of developers don't know anything about functional programming, recursion or lambda calculus; concepts that are still quite useful for solving real world problems.
Without understanding functional programming, you can’t invent MapReduce, the algorithm that makes Google so massively scalable.
But they even have trouble understanding pointers.
Now, I freely admit that programming with pointers is not needed in 90% of the code written today […] But it’s still important for some of the most exciting programming jobs […]. You can’t understand a line of code in Linux, or, indeed, any operating system, without really understanding pointers.
Joel finishes:
I can’t understand why the professors on the curriculum committees at CS schools have allowed their programs to be dumbed down to the point where not only can’t they produce working programmers, they can’t even produce CS grad students who might get PhDs and compete for their jobs.
The industry complains that schools doesn’t teach students what the industry needs (read: the current buzz word technologies). The schools react by changing the courses to please the industry, but looses some of the harder parts in the process. The industry then recruits these students, who have not been taught as many different ways of thinking as before, and as Dan writes, the following scenario becomes standard practice:
Of course what happens more often than not is that companies ensure they don't use new tech. Instead they force new projects into using all the same stuff they used before. This is a design disaster as now technology is dictating not design or suitability to requirements. A company that follows the hit the deck coding mantra just has deathmarch and no career progression stamped all over it.
And finally, when a company has turned into a Java shop or a .NET shop and it’s time to recruit more developers, it’s easy to recruit people with the desired knowledge.