Back in old country, I once had a programmer working for me who made himself famous with the following quote:
"I have fixed that bug, do you want me to compile it too ?".
In his mind, he was done as soon as he identified the bug and put the fix in the code. All the rest was trivial and unimportant routine.
During last 20 years I have worked with many very different developers and learned the hard way, how very many different meanings the word "done" can have. For some, done means that coding just finished and he/she successfully compiled the projects and stepped through some of the code paths with debugger with negligible occurrences of major crash. Whether the code is in CVS, commented - who cares ?
For others it meant that unit test was written and run, code is commented and documented, everything is properly tagged and version-ed in source control system, built and deployed via automated build system (now do NOT laugh, the later are not mythical creatures, I really met few guys like that). The problem is that it takes some time while you find out who is where on the done-ness scale and making sure that the whole team is on the same degree of "done-ness" or at least in agreement what done means, can present quite some challenge and consume considerable amount of time from the project manager and/or team lead.
What is your degree of done is a great question to ask when you are building new team and hiring developers. We had interesting discussion with Connie on the topic of hiring criteria and both came to a conclusion that biggest mistake you can make is to put too much weight on best technical skill-set match. The longer is the project, the less emphasis should be placed on skillset match - simply because skills will evolve but non-technical personality treats do not change - and in the long run, these may cause most troubles. For smart person, with good education and wide enough experience it is much easier to fully master some special area of expertise, especially when there is some time available. On the other hand, things like teamwork, work ethic, social skills, communication or "degree of done" are very hard to get and even harder to fix/develop.
The other reason why hiring only by skill match can be tricky is: how do you evaluate a supposed expert's expertise ? If do not have another expert (ideally better one), how do you validate how much of claimed experience is truly there and how much is just a nice wrapping, an empty shell lacking depth ? The risk in hiring somebody with boasted experience but lack of depth is that this person will inevitably become the key design/implementation influencer and decision maker in the given area of expertise. Eventually, as the project moves ahead, other team members will catch up and understand more and will question some of expert decision made - and the fun begins.
Another important "must have" for a good hire is multicultural background. No, I do not mean *that* type of multiculturalism as the politicians like to use: I mean the information technology cultures such as platforms, operating systems, languages and the person's exposure to multiple of them.
If you have a guy who worked on non-Microsoft platforms, it will be much easier to make him understand why the automated builds, scripted installs and all that old fashioned command line stuff is so important - because that person will see the value and power of scripting, repeatability and automation. This is very hard to explain to a guy who was all his life just clicking buttons and checkboxes in GUI tools and the black box of command line prompt either scares or annoys him. (OK, let's be fair here: until Powershell's availability, the command prompt in Windows was both scary in its ineptitude and annoying compared to e.g. Bash)
If you have a seasoned Oracle database guy who used the database on Solaris, Linux and Windows, you will never have to mentioned and explain that you need scripts for things like create schema, load demo data etc. You will get nice, handwritten, commented, parametrized scripts for everything whether you ask for it or not. These guys just operate that way because until recently there was no GUI and because this is fastest way (hi Bob :-)). On the other hand - ask a SQL Server database developer to work using "script first" approach and you may find out that it is something not so obvious, the guy does not get it (just keeps on clicking in Management Studio) and that the scripts you eventually get are far from good - because they are generated from changes done via GUI, not really written. To be left maintaining such code - good luck.
So what is the best hire ? Smart people, with good education and problem solving capabilities, with solid verifiable experience, wide multicultural background (in the computing sense), with proven record of working in teams of various sizes and ideally well versed in business area you are working in, with work ethic compatible to your organization, shared communication culture and similar degree of done. It does not really matter how many keywords does the resume match: if you need to have great C# programmer and have a choice of experienced Java guy who never touched .Net and 10 year senior Windows programmer who spend most of his/her career on Visual Basic like platforms, it will typically end up like this: Pick a good Java guy, give him 4-6 weeks and the reward will be beautiful, maintainable code with very natural C-sharpness. Pick a VB guy, you will "save" the start time - but you will more likely get average, harder to manage, less scalable code because the object design and object thinking just are not there to the same degree as in Java case. The longer the time was spent on VB version 6 or less, the worse.
An advanced apology to all my VB.NET loving, VB.NET writing friends - please no flame wars, all of you absolutely are the exceptions confirming the rule, you are the crowd who gets the OOP, and besides we all know that VB.NET is just syntactic sugar on top of C#, of course the "better" type of sugar :-). I am not picking on you. I said VB but I really meant Perl ...
And btw, Tidlo - if you are reading this, send me an email. Hope you are still programming and occasionally compiling after you fix the bug.
Author Miro Adamy
License (c) 2006-2020 Miro Adamy