A place to discuss Joel on Software. Now closed.
This community works best when people use their real names. Please register for a free account.
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot
The Old Forum
Albert D. Kallal
Thank you to everyone who replied to my post a couple days ago. I now have had a huge number of responses from a number of sources. I decided to try to correlate the results and have produced the following draft diagram:
If you have any comments especially if I have missed things out or put something in the wrong place I would be delighted to know.
Saturday, May 02, 2009
Very interesting. I would quibble about the placement of specific elements but I think the bigger question is, how do you determine which factors are more important, more critical?
For example, some people would argue that the "un-learnable" skills on the right side trump the skills on the left. The map however suggests that the more elements you can check off on the left, the more likely the candidate is going to be a good hire.
One thing I would try doing is expressing the map at the same level of abstraction, i.e., limiting how deeply you can go into a tree. For example, if you go no deeper than the third level, you have 13 unteachable traits verses 8 teachable traits which would then imply interviewers should look for people matching more of the unteachable traits.
I think, as is, the map only really shows that it's easier to describe and explain teachable skills, and you can go into an amazing level of detail on that side of the map.
This is just a checklist in sheep's clothing.
What's more, many of the things are both subjective and impossible. "doesn't make assumptions"? Everyone makes assumptions.
Whats worse, most of these things can be faked. I think your time would be better spent hiring people, tracking why you felt they were good, seeing how they turn out, see how far off you were, adjust, and do it again, aka get experience in hiring developers.
No checklist in the world is going to tell you how to hire a good developer, regardless of the format.
It is not a check list for hiring and I agree using it that way would be a mistake. The aim is to help new graduates understand that employers look for skills in developers other than purely technical ability :)
It is work in progress though and any feedback is very useful.
Saturday, May 02, 2009
Before we go too far, what I'm quibbling about is the presentation format. The way information is presented often does shape how people perceive that information, and unfortunately, a long list of attributes tends to get perceived as a checklist.
A mind map is a great way to make sure you've thought of and accounted for each major factor. We do want candidates with a positive attitude and candidates that work well in a team. We also want candidates that are passionate and write good code. However, if you presented a map like this, then the feeling is, "yes, I want as many of these attributes as possible."
I think we should see the next step, where you roll up all the data and present some conclusions. For example, it is easier to measure teachable attributes than "un-learnable" attributes and we as an industry probably should spend some time thinking about how to measure the latter. Alternatively, if you're looking for a job, these attributes will be the most significant factors and by comparison, you shouldn't worry about those other attributes. Etc.
If you don't provide a thesis, then people will just continue to nitpick the checklist absent anything better.
Thanks TheDavid. I agree this IS a check-list of sorts but don't worry I have no intention of using it in any sort of recruitment process.
Around 100 people responded to my initial question. What I was looking for was how a person's position effected their answers as for most people I know their backgrounds. This means I can determine patterns. For example managers tended to highlight different areas from everyday developers and high end developers different areas again.
The purpose of the diagram was just to correlate the results in a raw form and give some feedback to the people who had contributed.
I now will probably go back and look at ways of determining relative importance of various factors.
Sunday, May 03, 2009
Not that I really want to defend check lists but isn't the famous "Joel Test" exactly that a 12 point check list for you to grade potential employers on? I know I have used that before and found it useful :)
Sunday, May 03, 2009
The "Joel Test" is a prime example of something past its prime. While it may have been a great idea during the dot-com days, its usefulness from dot-bomb forward isn't there.
It should be replaced by more relevant questions such as
- who pays for equipment (desktop, laptop, etc)
- if equipment IS provided when was the last time a technology refresh happened (the major defense contractor I worked for in 2002 was doing kernel development work on Pentium 75s - circa 1994)
- who pays for development software (Visual Studio, Dreamweaver, whatever)
- how are project leads chosen (I've seen someone fresh out of college picked as the lead because he seemed like a go getter - we fell behind almost instantaneously and started missing deadlines)
- do benefits continue (medical, dental, 401k) should I go from one program to another
- do I get reimbursed for expenses incurred during required travel
- how are raises determined (SLOC is not the metric to use)
No one really cares anymore if you can make a build in a single button press.
All that aside, a candidate and company could be great fit without having to worry about how many red tick marks are on the checklist.
I agree the phrase "lacks ego" is not right because as you say pride in your work is important. I will revise it. I think the point the original contributor was making that within a team environment having such a big ego and so not being able to take onboard suggestions causes problems.
As you move up in a company a big ego can cause more severe problems such as pursuing what you realise is a flawed strategy because you don't want to loose fact by admitting you are wrong.
There is actually a good book on the subject: http://www.amazon.com/egonomics-Makes-Greatest-Expensive-Liability/dp/1416533230
Monday, May 04, 2009
You can spend a lot of time hiring a developer and looking for the 'primo rock star 1000 pages a day candidate' all you want.
If you get them in the door and treat them like dog poop or the ever escalating deadlines/project juggling, your going to be hiring the next zombie sooner or later.
Dan V.: I figured that was what was really meant. A few-word description really does not suffice.
There was a talk at given Google that I viewed. The speakers were serious about so-called poisonous individuals. Imagine wanting to see your name in the code of an Open Source project. The speakers' names were given. Are they poisonous, too?
Gene, sounds interesting but I don't fully understand what you mean. Were the Google guys saying there were poisonous individuals with egos so big that people did not want them on open source projects?
Wednesday, May 06, 2009
No, it was that people wanting their name in code that they wrote were poisonous individuals.
Yes, there are people who have the attitude of "How dare you change my code?", but there are also people who like to point to their work: "See? I did that bit."
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz