Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
Posted by Niclas Nilsson on Aug 02, 2007
In a time when many job advertisements are flooded with technology buzzwords (sometimes even requiring longer experience with a technology than it existed), Dan Creswell found an interesting difference in Amazons job opening for a senior research engineer. Dan asks: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.
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
Regaining control of the data centre
Technical Debt and Design Death
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
The hiring mantra at my company, a small IT/BP consulting firm in VA, is Attitude > Aptitude > Skills. And I think that's the right approach. We certainly desire people with expertise in OOP, databases, and systems architecture; but if somebody has an awesome attitude and good aptitude, we can always teach them the skills.
Unless you're a staff augmentation company, hiring based on skills is extremely myopic. I thought that was a well-understood idea in most professions.
I wrote a whole software hiring manifesto on my blog a few weeks ago.
When looking for a candidate, I care about intelligence, curiosity, dedication, personality, and last, and definitely least, relevant experience. Experience with a library can be taught. A smart, curious developer who has never used JBoss before will quickly be more productive in the environment than a mediocre developer who has experience with the tool.
The reason that you get the technology lists is that it is the easiest way to put out help wanted ads and to filter out unqualified candidates. When searching for a job on-line, most candidates enter technology keywords that describe where they want to work. This often includes specific technologies. It would be hard to come up with effective search terms in the supplied ad other than "Amazon.com".
Also, when a resume is sent to a company, it usually is filtered first, either using software or by a member of the HR department. Whenever a help wanted ad is put out, most of the resumes that come in are no where near qualified for the position. Using a list of keywords helps the software or HR person screen out obviously wrong resumes.
There are some exceptions to this rule, usually in pretty senior positions where I need someone who already knows the problems with the technologies we are using.
I wrote a whole software hiring manifesto on my blog a few weeks ago.
Beautiful !!
Also, when a resume is sent to a company, it usually is filtered first, either using software or by a member of the HR department.
Unfortunately , lot of companies do "keyword searches". Not many companies allow you to reach a stage where they can really test your problem solving capabilities.
I hope that this will reach some! A pretty good moment for such a post :)
I think most IT job postings on major job sites are crap. They often are LISB (List of Insipid, Stupid Buzzwords). But they can tell you a lot about that organization, so smart developers usually answer smart job postings. Here in Italy the criterion for hiring developers is even simpler, they usually hire the one who ask for the smaller salary... In Italy CS graduates until six / eight years ago were used to have a very strong background in math, physics and theoretical CS (in fact here we do not say "Computer Science" but "Informatica", which is more like "Information Science"), but maybe very little programming experience. However people with a solid cultural and scientific background can normally learn quickly and develop an open mind. Now schools produce more specialized people, maybe more productive developers in the beginning but, as explained in other comments here, they often lack the necessary theoretical preparation to "see beyond". I don't mean that every developer should be a computer scientist, but it's a matter of awareness about what you are doing and where you are going. If I had to hire someone I would prefer to discuss about design patterns and architectures instead of the latest J2EE-related buzzword. One of the fundamental requisites is, as DeMarco underlines, whether the guy fits the team, as development teams can be very fragile organisms and you just need to keep them into "the zone".
I love Rob's software hiring manifesto, I think it's extremely good even if there is maybe too much emphasis on writing code "on the fly". I know really good developers who can be very nervous and shy to type code during an interview, so I would prefer to discuss with them an already written piece of code. And what about working under pressure? Do you know any IT environment not putting even too much pressure on people? The problem is that nowadays we are putting too much hopes on modern tools instead of good people and every project suffers because of unrealistic deadlines, even more than a few years ago.
All huge laundry lists of tech skills encourage is:
1) lying
2) people to learn things only trivially (for the interview)
3) penalizes fundamentals (as described above)
4) penalizes people with varied backgrounds (which can provide insights into architecture, debugging, and problems)
NEWSFLASH:
The server-side, client-side and the browser-side are totally fragmented in terms of technology/language/frameworks.
It's all luck who you get stuck with and when you get stuck with them. If you're looking through a filter or laundry list it is only an effective means to fool yourself and is in fact a waste of time.
Hi Niclas,
We discussed a similar topic in January at SAW Arosa. The key output was exactly the same. Specific skills can be learnt by a motivated, clear thinker at any point in time. The ability to think abstractly was considered more important than knowing a particular language, tool, technologie, etc.
Given that you have found someone that is a good abstract thinker, social compatibility was second highest qualifier. Sometimes, social compatibility was considered more even important than other factors. In other words, "Would I be able to have a beer/coffee if we just met by accident?".
I have to agree with Joel on this one. In my company and country (South Africa) we are seeing similar trends. I now focus on recruiting Engineering graduates because they seem to do formal courses on design techniques, lateral thinking, problem solving etc. I then take the risky position of teaching, informally, the fundamental abstractions, theories and techniques of computer science that Joel talks about. It seems to work for us, for now.
Aslam
"How many gas stations are there in Philadelphia?"
A colleague got this question a few weeks ago (in London UK). Is 'I don't know' a satisfactory answer?
My favourite (and still used) approach is also from the Spolsky stable: you should keep reminding yourself you are looking for "smart people who get things done".
Smart people are rare, but just because you find one doesn't mean they are a shoe-in - being smart without being practical may only get you elaborate designs that can't be realised.
Similarly someone who's gung ho on delivery will probably take so many short cuts, you'll be forever trying to catch up with your design debt.
What the right balance is, is different for each circumstance (and the characters you've already hired), but I find it a useful mantra.
The right level of exposure to the technology-du-jour in your organisation is clearly a benefit, but not always critical (unless, as the article says, you need code going out the door by Friday).
I must admit, I sometimes wonder if there's a Platonic job description out there, one per job title, that everyone is copying.
The more a job description resembles this template, the less likely I am to apply... I figure there probably is no relationship between what's posted and what's really wanted, so I really have no idea what the job is. I also presume that, if the person filling the position really cared who they got, they'd put something into the posting to attract a creative, versatile person like me. Vogels' posting, referenced above, gives me an idea of who I'd be working for and with.
Use of only technology or methodology buzzwords in a job description suggests to me that I'll end up dealing with some HR person who doesn't know a RUP from a FitNesse, and who won't appreciate my resume properly, either. I don't waste any time on these. I wonder if these are the people crying "we can't find qualified candidates!!" ?
I really wonder if a phd is worth it... I've met an awful lot of CS phd's who make me wonder how they got a phd. Ten years of experience is worth more than 10 years of education.
Abstraction is the real key. If you can't abstract, you can't do any real work. I don't think any curriculum can teach this. You either have the knack or you learn it the hard way.
A great many schools have a vested interest in dumbing their curricula down, especillay at the MS level. They can charge through the nose for CS or IS degrees for the same reason that they can charge a mountain for MBAs... most folks in the program are after the degree so they can make more, so there's an investment. The schools use the professional degree programs to pay for their more academic degree programs. Where I did my MS, degrees in CS or business at the master's level cost double per credit that history or art degrees cost. I'm not griping about it... it was an investment. I'm just pointing it out.
In general I agree with the approach for a very senior position though... I'd rather work for the right place than figure out whether I'm using .net, jee, or lamp. I think its like learning spoken languages. After you've done it 3 times, you begin to figure out how to learn new techs quickly.
The fact is that the IT industry is held to ransom by IT recruitment agencies who are almost all (in my experience) terrible. They are staffes by sales types who really don't care about either clients on either side (the searching, and the searchers).
Until IT companies pull their recruitment in house again and stop allowing these vultures to make a quick buck while still providing a terrible service we will continue to see buzzword driven CV's - they are required to get past the "select statement" candidate selection.
There is a lot of value in recruiting for specific skills - if you actually need somebody who has those specific skills - if you need a good technical person then if they know [languageA] or [languageB] makes little real difference.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
13 comments
Watch Thread Reply