Where is the Blue Collar Programmer?
During my most recent spat of interviewing, I've witnessed a trend of sorts. The vast majority of firms test only for White Collar programmers. Very few even consider Blue Collar Programmers. They take the candidate and give them a coding test which does not really test their coding ability, but instead tests whether or not they can solve some crazy algorithm which is more suited for a math exam. They quiz on knowledge, seeing whether or not the candidate knows the definition of such book terms as Polymorphism. More or less a test on whether or not the candidate studied recently for a CS exam, how good is their memory, than if they can really code. By doing this process they ensure themselves to always get the best of the best. The brightest, smartest out there wearing the title of software developer.
Once they have a shop filled with all these very bright people, they then wonder why the production output is poor. Why the deadlines cannot be met? Why the designs can never be agreed upon. Why is the code constantly being rewritten with the latest technology and why it's impossible to actually produce working software? Development practices such as the Agile Methodology are brought in to solve the issue. To corral all of these very bright people into a focused team that can actually produce what the customer requires. The old concept of Lead Programmer is lost in exchange for Scrum Master and Product Owner. Pieces are interchangeable and production resumes. Many times though something is still missing. That technical overall knowledge of how all the pieces fit together. The intimate knowledge of the software, the API, the inter-process communication is substandard. The overall knowledge of all the guts somehow gets lost in the process.
It is my assertion that this is a result of only testing for and hiring White Collar Programmers. By that I mean those guys that got 100 on their CS exams, the ones that can recite the syntax of any function by memory. These guys can usually hear a problem and come up with the best solution in technology today. They read all CS journals, attend user groups, and are great to have on any team. They stay on top of technology studying the latest solutions. But like the difference between the people that design an engine and the one that puts the entire car together, they are not always the best at putting the pieces together. Many times they can give you the best and strongest engine, but do not realize how it affects the rest of the car. How their solution affects the overall performance. How to put all the pieces together as well as how to recognize and use the rest of their resources to the best of their ability.
What they lack are Blue Collar programmers. They complement each other. The Blue Collar is the one that gets things done. They know all the parts of the app that need to get finished. They take the White Collar answers and make it happen. They make their dates and are more concerned about delivering a finished product than using the latest technology. They tend to the more creative side, and can envision the entire product in their head. They ask questions, they are experienced at using the White Collar resource available to finish. Just like the White Collar needs the Blue Collar to practically apply and complete the project. It's a perfect match, but interviews recently show that only White Collar is tested. Many companies have never had the Blue Collar, have no idea what they bring to the table. It's a tough sell, but when you get both, then you'll be amazed at what can get done.
How do you tell? How do you know where a candidate lands? How do you tell where you are yourself?
Given a new task, something you know nothing about and have only heard of a few times. You are assigned a major effort involving this technology. You are offered one of two items to help you with this task. Either a very thick book with a ton of research, explanations, code snippets, details on exactly how this new technology works and how it was developed and how to use it. OR you are offered a sample working program that has no comments, is not written very well, but implements the new technology not exactly how you need it, but it's a working sample. Which do you choose? If you take the sample program, you might be a blue collar programmer. If you take the book, you are probably a white collar programmer.
If you are looking for the person to design the car, you don't make them develop an engine. You give them the pieces and have them design the car. You give them too many pieces and make them choose which to use. Too few pieces and have them identify which are missing. You put them on a team and make them create software. Give them a working or non-working app and have them identify the problems. The best process I've witnessed for this is the group interview. Take different candidates, make them a team, give them a customer, some software, and have them solve the customer's problem. Usually you will see the ones that consider the entire scope of the project, take in the big picture. Others will focus on certain areas of code, making smaller sections the best they can be. You can almost determine if they are Blue are White collar by asking which they prefer. White Collars are usually more comfortable with the hackathon, Blue with the overall group dynamic and how the pieces combine together.
Both types of programmers are assets to your group. I am not disparaging either. But as with a football team, you don't get 11 Quarterbacks and have them play every position. You examine your team and your candidates and find the best at each position. If you find the person that has both, hire them right away. But you are probably too late, as they often are the ones that have started their own business, created their own software. I've worked with a few of those guys and I can say that they have taught me the most. But in my experience I have found that most lean to one side or the other. I have also found that the current interview methods are geared towards the White Collar, and therefore shops are predominately lacking the other side. The innovators, risk takers, the balancing act the leads. The ones that cannot quite remember the exact definition of Polymorphism, but apply its definition every day in their code.