Recruitment and the Mythical Year of Experience December 6, 2007
Posted by Imran Ghory in recruitment, Software development.6 comments
When it comes to recruitment the basic unit of measurement for ability is “years of experience” – this is something that many developers very vocally consider inappropriate, often due to the amount of experience being requested seeming excessive. However if you consider it from the viewpoint of the company hiring, it does make a certain amount of sense.
There is a strong correlation between the years of experience an average developer has and their ability as a software developer.
You are not the average software developer.
As has been discussed elsewhere in the blogosphere recently, if you read programming blogs for fun then you are not the average. Most software developers do not read programming blogs or even programming books for fun. Not that there’s anything wrong with that, but many software developers seem to have an innate assumption that other software developers are like them (i.e. I read books, so they must read books too), which in part is responsible for the frustration with the “years of experience” measurement.
The average developer’s skills are closely correlated to the amount of experience they have because for the average developer on-the-job experience is where they learn and become better developers. Hence it makes sense to use years of experience as a measure, it’s not exactly what we want to measure but it’s a better proxy measurement then anything else in common use.
But the next obvious question is: Why do firms ask for many more years than they seem to need ?
Lets consider a company that goes out and interviews a lot of people who’ve applied for a job. Say the average applicant applying has five years of experience, and from all their interviewing they find the candidates are too weak for the role. So they bump up the requirement to seven years. Not because they don’t think there’s anyone with five years experience who can do the job, but that the average developer with five years experience can’t and that the number of people with five years experience who can do the job is significantly less than those with seven years experience.
It’s purely a number game. If only one-percent of those with five years experience are good enough for your needs but five-percent of those with seven years are, then requiring seven years of experience will significantly decrease the number of interviews you have to conduct. Say you expect to interview a hundred candidates – would you rather be left with five candidates who are strong enough (and can then be judged on other criteria such as fit, etc.) or just one candidate who may or may not be a match for your company ?
However it’s actually worse than this situation, as the average software developer is actually significantly better than the average software developer who’s on the job market. People who are above average for their level of experience get hired very quickly because firms realize a good thing when they see it. People who are below average stay on the market for longer and therefore apply for more jobs. So not only are the people looking for jobs worse than average, the worst are also applying for a lot more jobs.
This means that if you want someone with the skills of an average developer with five years of experience, you might have to actually hire someone with ten years of experience – who’s significantly below average for their level of experience but is roughly equivalent to the average developer with five years of experience.
So if you’re an above average developer, you need to realize that the “years of experience” requirement isn’t written with you in mind. Rather it’s written for the below average developer on the market for whom it actually makes sense.
The Best Software Development Books of 2007 November 30, 2007
Posted by Imran Ghory in Books, Software development.25 comments
[This list is just based upon my personal opinion and therefore only includes the books I’ve read. Any suggestions for books I’ve missed are welcome. All of the books below were published in 2007]
1) Code Craft by Peter Goodliffe
This is the book every compsci student should read before starting life as a professional developer. It covers the gap between the programming a student does at university and then real-life work of a professional software development. It covers many practical topics such as version control, static analysis tools, and variable naming conventions, all areas which are often not covered in
academia but are essential in professional life (Peter actually writes an excellent column in C Vu magazine called “Professionalism in programming”).
At the risk of sounding like a heretic, for new programmers this book is a better “Code Complete”. Don’t get me wrong, “Code Complete” is a fantastic book and it’s content is well researched and referenced. However Code Craft is a far more readable book, it’s emphasis is much more on the day-to-day practical elements (as opposed to McConnell ‘s more academic style) and is much more conversational in style. I know at least 20 people who own a copy of Code Complete and almost none of them have actually read it beyond the first couple of chapters (which are unfortunately among the worst).
Code Craft begins on the topic of defensive programming, which while not the most titillating of topics means the content is immediately applicable to most developers. Code Complete begins on metaphors for software development.
If you’ve been a professional software developer for more than a few years then you probably already know most of the material covered (although it may still be worth reading to discover any gaps) and you’ll probably be better off with “Code Complete” due to it’s greater coverage of topics, but if you’re a new developer then this book is a gold mine of information.
There are only two significant gripes I have with this book, firstly the quality of the binding is not great. It’s a standard “no starch press” paperback – I suspect the binding will come apart with frequent use. Secondly there are a number of minor errors throughout the text, they’re not significant enough to take away from the overall quality of the text but they can be distracting and potentially misleading. A corrected second edition printed in hard-back would be most welcome.
2) Smart and Gets Things Done by Joel Spolsky
This is in a slightly different category to the others, it’s not about software development per se, but rather about the recruitment and retention of the best technical talent.
I actually disagree with a lot of Joel’s opinions on recruiting, but that’s not to say his opinions aren’t worth reading and considering. Like him or hate him Joel is probably the most influential figure in technical recruitment at the top end of the software development talent market. You can go for an interview at pretty much any top technical firm knowing with near certainty that interviewers at that firm are familiar with Spolsky’s essays on the topic
And that more than anything makes his new book worth reading.
3) Programming Erlang by Joe Armstrong
Probably the most anticipated software development book of the year. If you haven’t been hiding under a rock for the past year you’ll almost certainly have heard of Erlang, a language which 
originally came out of Ericsson that is rapidly popularizing the concurrent programming style that it champions. It’s a functional language that originated out of industry rather than academia.
Armstrong started working on Erlang in 1986 – twenty-one years later his book “Programming Erlang” is introducing the language into the mainstream and attracting many developers who have never coded in a functional language before. The book is almost certainly destined to be a classic, at the very least rivalling the Camel Book in terms of influence.
Put basically: this is the book that all the cool kids are reading.
4) The Complete Guide to Capital Markets for Quantitative Professionals by Alex Kuznetsov
When someone says “Investment Bank” people inevitably think of traders on an open-outcry floor. At the average investment bank there are five software developers for every one trader. The finance industry probably swallows more developers than any industry outside of the tech industry itself; in major financial cities (New York, London) more software developers are employed in finance than in any other industry. It’s not unusual for a large bank to have several thousand developers on the payroll.
Yet almost no-one outside the industry knows anything about what these software developers get upto. Even within the industry most people only know their little part of the world, living in complete ignorance to even what the developers down the aisle from them are working on.
This is the problem that this book aims to solve, and does it reasonably successfully. It gives a broad overview of the financial markets and the industry players from the point of view of a developer. Despite the fact it has “quantitative professional” tacked on the end of it’s title the book is probably more appropriate for software developers than anyone else.
While the book tries to explain everything without making any assumptions about the readers background knowledge of finance, it does on occasion fail, throwing in basic financial vocabulary without explanation. However these occasions are rare and on the most part unexplained terms can be quickly looked up on Wikipedia.
If you’re working in the financial industry as a developer, or perhaps are looking to enter the industry then this book is well worth the read for the broader picture it will give you. Even for the curious passerby this book may make interesting reading, however it is clearly targeted at those who are in or want to be in the financial sector.
The Worst C Example Ever May 21, 2007
Posted by Imran Ghory in Software development.43 comments
The Example:
strcpy(str, getpass("Enter password: "));
The first time I saw this I was shocked at how many problems this tiny example of code has (there’s a list of problems further on – if you want to try and figure out the problems yourself try to write a working getpass() function based upon this caller).
To put this example in context it came from Question 6.5 of the comp.lang.c FAQ in which this example is given as an example for how to achieve what the following piece of code is trying to do:
extern char *getpass();
char str[10];
str = getpass("Enter password: ");
For those of you who aren’t C programmers the above chunk of code won’t work as getpass() is returning a pointer to an array (in C strings are represented as arrays of chars) and C doens’t support implicit array copying.
However the “fixed” example is almost as bad as the original, only made marginally better by the fact it technically works. However it is horrendous as an example of good coding practice.
So what’s wrong with it ?
The newbie programmer has almost certainly implemented getpass() using the following method:
char* getpass(void)
{
char password[10];
scanf("%s\n", password);
return password;
}
This reads the password into a local variable which it then returns a pointer to it. The worst thing about this is the code will actually work sometimes and not other times leaving the programmer in a terrible confusion (local variables are allocated on the stack hence will get overwritten after the function ends).
A more spohisticated way to write this function and how it would be generally be done would be to use dynamically allocated memory as in the following:
char* getpass(void)
{
char* password = (char*) malloc(10);
scanf("%9s\n", password);
return password;
}
However in the original bad example the code is throwing away the pointer which getpass() returns, which means that it’s not possible to free that memory. Hence you end up with a memory leak, not good. So this solution is not good in the context.
The best possible getpass() you could get away with is to declare a static char array variable which you return a pointer to
char* getpass(void)
{
static char password[10];
scanf("%9s\n", password);
return password;
}
However this makes the function non-thread-safe and non-renterant which limits its use, and as well as that you end up storing the password in memory for the permanent life of the program.
So as you can see it’s impossible for even a good programmer to write a good getpass() function that can be called by strcpy(str, getpass(“Enter password: “)) , let alone the beginners that this document is targeted at.
A bonus bug
Plus for bonus points, there’s yet another sutble bug in this code. It uses strcpy() in an unsafe manner. Even professional developers often slip up when using strcpy, generally professionals always want to use strlcpy as strcpy is almost never used correctly. The reason it’s bad is the following scenario, imagine getpass() was changed to be the following:
char* getpass(void)
{
static char password[100];
scanf("%99s\n", password);
return password;
}
What makes it unsafe is that strcpy doesn’t know how many characters to copy, hence it just keeps copying from the source to the destination until it runs out of characters. Now that getpass() returns more than ten characters what happens ? – if you’re lucky the program will crash – if you’re unlucky the person typing in the password can take over the program and bypass the password protection.
So What ?
Well hopefully the above has convinced you that if you’re writing for beginners you should try to write examples that not only work, but also show good development practices. Especially online where space isn’t as major a consideration as it is in books.
Imran On Tech 