Finding the best programmers can be a daunting task. For non-technical people like entrepreneurs and small business owners, the job can be downright nerve racking. People search for the one elusive “Super Developer” or “Uber Programmer” to solve all their software problems, in half the time, with no bugs. These super programmers do exist. I’ve met them. I’ve lived with them. They live on a different plane than us mere mortals. And they all work at Google.
But you can find excellent developers who will complete projects in a timely fashion, with the desired specifications. One key to finding awesome developers is knowing how to evaluate them. This article will help you through the process of selecting programmers with the right qualities.
Because everybody’s into acronyms let’s coin one to describe the traits of an excellent developer – JUICED (despite the word’s negative connotation with steroid use and OJ Simpson.) Although you don’t want your programmers to kill to get code out on time, you are looking for somebody aiming for the goal post.
Let’s start with J (being the first letter in the word “Juiced”) which represents Judgment. Not judgment as in you’re waiting till judgment day for your web developer to finish the project. Judgment as in your programmers have good judgment and they exercise it. To emphasize why judgment is so important I’ll let you in one big secret of software development:
Most software projects fail because people work on the wrong things.
You can forget anything else in this article and still be more informed about software development than 97% of businessmen (without having to spend thousands of dollars on expensive degrees). What does it mean to “work on the wrong things?” I’ll give you an example. Say you have a project to build a website tracking gas prices by geography. The user enters an address and sees a list of gas stations and the most recent prices submitted by a user.
Now your developer might want to code up a Google map, because it’s cool an interesting. But, he may spend too much time, when a simple list may have sufficed. Before spending a lot of time coding one particular feature, a good programmer will use judgment and check with the customer or project manager to make sure time spent is consistent with budget, timeline, and priorities.
Of course a programmer needs to understand the application in order to make it work as the customer desires. At a basic level, it helps for the programmer to have a solid grasp of written and spoken English. I’ve managed many programmers with English as a second language with excellent results. These days you’re likely to run into programmers with English as a second language, so it’s not really a problem.
While the spoken language is important, the programmer needs to learn the language of the client’s business. Each industry and project has its own set of terms, a unique nomenclature. A good programmer will understand the language and how it relates to the final application.
In addition to comprehending the problem space, an excellent programmer will accurately read and interpret the project specifications. Because no spec is perfectly written, a great developer will ask relevant questions after reviewing the functional specifications. These questions will demonstrate an understanding of the application and could reveal missing details or an inconsistent design.
While a good developer doesn’t need to be a Star Trek big brain alien genius, they do need a certain type of intelligence. Programming requires traits beyond simple problem solving and pattern recognition. Writing code involves a good deal of abstract thought. A person needs to hold in mind several interconnecting concepts, select the software design patterns and tools appropriate to the problem at hand, recall the correct syntax, and write the code. Aptitudes in math, science, and Rubik’s cube solving would put you on the right track to finding a qualified candidate.
Mental focus plays no small part in programming. Finding a bug in several thousand lines of code can be a most frustrating game of “Where’s Waldo?” A decent developer will be able to troubleshoot bugs, regain the state of mind when the code was originally written, and make the appropriate corrections. Beyond having good bug fixing skills, an intelligent programmer designs software that inherently reduces bugs through modular design.
A competently written program looks good inside and out. From the outside (the all important customer’s point of view) the application has a good user interface and fulfills the functional requirement. The system behaves as expected, solves the desired problem, and provides peace of mind. For a well written application, the whole is greater than the sum of its parts. It possesses smoothness. To achieve this quality, the developer takes the end user’s perspective when creating the application. How many times have we used troublesome websites or applications and thought “Did the programmer even try to use this?” Thinking about the end user shows courtesy as well as competence.
While users know well written applications when they see them, it takes a fellow programmer to spot competently written code. What does this mean? Competently written code is extensible – written with future changes in mind. Extensible code has ample comments, functional organization, meaningful variable names, and manageably sized modules. A decent programmer can write code that works and meets requirements, but be difficult to add features to. A super developer writes code knowing it will need to be maintained – either by him or somebody else. Programmers of this caliber not only write extensible code, they recognize and appreciate other developers who do the same.
This is one of the most controversial areas when judging potential programmers, so let’s spend some time exploring it. Experience can be categorized in two ways – the buzzword approach and the expert approach. The buzzword approach, also known as the HR (Human Resources) method, involves scanning a candidate’s resume looking for a minimum number of years using certain languages, technologies, databases, software packages, etc. Unless the HR person checks the right boxes on her or his list, the developer never gets past the first round. Programmers themselves refer to this as the “grep” method, named after the Linux command line tool that scans files for a particular string.
A strict buzzword approach fails on several counts. Using the right words does not make a classic novel, or even a good read. I’ve personally worked with programmers with a decade of 9-5 experience in a particular language, who still didn’t grasp fundamental concepts of software design. Their code was difficult to maintain, and the overall system suffered. I’ve also trained people who had never written a line of code who intuitively understood software design. Within six months of programming, their code quality surpassed the person with ten years of experience. Ultimately, the buzzword method fails because HR people lack the mindset to spot excellent programmers.
The second way to judge a programmer is the expert method. You look for depth of knowledge in a particular technology and the difficulty of the problems solved. Programming is about problem solving more than about knowing the commands in any one language. Here’s another secret – look for programmers who have worked on or taken a course in compilers. Once a developer understands how to make his own programming language, mastering a new one becomes routine.
Again let’s use the natural language analogy. Say you needed to write a novel in Spanish. You have two candidates: one who took three years of Spanish in high school and one who translated a 500 page novel from French to English in one year. The HR method would pick the first candidate and not even consider the second. Which would you choose?
Ultimately when we think about experience, we’re talking about the difference between theory and practice. In theory, somebody with three years of Spanish should write a better Spanish novel than somebody with a year experience in French. And at first, the Spanish student will produce more words for you novel. But in the long run, the translator will outperform and create a better work.
So how do you find great programmers based on experience? Use a hybrid approach. Search for somebody with depth of experience in a particular area, then evaluate for adaptability. We use a custom selection process that screens for problem solving abilities in addition to knowledge of a particular language.
While dependable developers might be an oxymoron, as the personality type who enjoys and excels at programming ironically dislikes structure (at least social structure). The “Tao of Programming” tells a parable about programmers who rebelled when told they had to work 9 to 5. But given the freedom to make their own schedule, “they came in at noon and worked to the wee hours of the morning”. This story illustrates why people say managing programmers is like “herding cats.”
The last trait of a solid developer could just as well be “Trustworthy”, but “Juicet” is not a word. As programmers often have access to critical business and personal information, the importance of trust cannot be underestimated. Your best developers will hold to a personal standard of trust and integrity, deliver code dependably, and possess a skeptical eye to societal norms. It’s all about balance.
So you’re looking for a programmer who you can trust and who has self discipline enough to stay on schedule. Give this developer scheduling flexibility and interesting projects and he’ll achieve maximum productivity.
Final Words on Juiced
There’s an overall quality to a “Juiced” programmer – being juiced about what you do. Good programmers have passion for their craft. They’re excited to solved problems and work on new and interesting things. Quality developers see programming as art; albeit art sometimes only another practitioner can appreciate. When searching for developers, look for people who program because they love it.