How to Tell if a Programmer is Competent or Not
--
First of all, why would you want to? Why not just hire this guy? He seems likable.
Well…
Bad Programmers Overpromise and Underdeliver
Programmers tend to read headlines and will tell you they can deliver on things that aren’t actually possible. You’ll realize this 2 months into the project when suddenly a myriad of technical problems pop up, which are always “unfortunate,” which they’ll express with technical jargon that probably causes your eyes to glaze over.
Then costs and timelines (that you put your name on!) spiral out of control. Incompetent programmers are notoriously bad at estimating the amount of time that something takes, and then, problem after problem, the time ends up being double what it was initially estimated to be.
Bad Programmers Deliver Buggy Software
If you’re lucky to actually see the project delivered (never mind on time), you start to use it and, lo and behold, it doesn’t work!
“Works for me,” they say.
So a huge amount of your time is being spent tracking down and logging bugs. And they never end. Every new release, more of your time is spent clicking around, looking for problems.
Bad Programmers Argue About Stupid Things With Other Bad Programmers
The brilliant book Peopleware states that most software projects fail because of people problems, not technical problems.
Less experienced developers will spend a half a day arguing about whether to use spaces or tabs in the code. This is called “bike shedding” (or BS for short).
Bad Programmers Simply Can’t (or Won’t) Communicate With You
Welcome to another meeting about how “two components’ component-did-mount hooks are conflicting because of a set-timeout we set in a library component, but, we can create a fork of this UI library...”
You Can’t Fire a Bad Programmer and Replace Them
…without losing a lot of time and money. It’s generally harder to read code than it is to write code. If a programmer has been running around producing garbage, it’s actually faster and cheaper for another programmer to just start over.
What Do??
You need to assess technical ability before hiring.
This can be difficult for nontechnical people. You might have to Google a lot. But there are a good amount of “tells” that let you assess ability without knowing everything.
Ask About Books They’ve Read
The first thing that can get rid of 80% of bad applicants is asking about what books they’ve read. Good, practical programmers take their craft seriously. They read the literature.
Here’s a list of books that signal competence:
- Code Complete — a very thorough book on code construction.
- Structure and Interpretation of Computer Programs — intense book from MIT on crafting software from the ground up.
- Anything by Martin Fowler — Fowler is an excellent architect of enterprise software.
- Design Patterns (“Gang of Four”) — good book on composing large software systems.
Anyone who says they’ve read “Head First JavaScript” or “Python Crash Course” — really anything with a specific language or library — these are essentially the equivalent of the “For Dummies” series, so careful hiring these people.
Ask if They Write Tests
Good programmers write automated tests (though, not too many) for their software, to make sure it works before delivering it. And they should run these tests in something called a “CI” or “Continuous Integration” environment. Ask what they use for “CI” and expect to hear something like “CircleCI” or “Jenkins” (and you can google “circleci vs” for a list of more).
Careful of demanding for tests, because programmers can test the s!@# out of their software which, sure, you’ll have working software, but it could double or triple the price.
There’s another buzzword, “TDD,” which stands for “Test-Driven Development.” It prescribes a specific way of writing tests. There is some research that suggests it increases software quality at the expense of more development time. Doesn’t matter too much. Just matters that there are tests, and not too many.
Ask Them to Evaluate Themselves With a Roadmap or “Competency Matrix”
A couple really cool tools have come out in the last few years that make programmer competency a lot more transparent.
One is roadmaps, and the other is the competency matrix.
Ask programmers to honestly evaluate themselves on each of these. Note though, that not all skills (especially in the competency matrix) are relevant for every job.
Ask Them for a Breakdown of Competing Libraries
Usually there are multiple “libraries” or “frameworks” (collections of code) that can get the job done. Ask them which they prefer and why.
Obviously this is something you can easily Google (for example, “React vs”), so what you’re looking for is reaffirming what you read from Google, and, more importantly, things you didn’t read in Google, especially things backed up by references to general programming books.
Do a Test Project
This one is obvious, but, do a test project and pay very careful attention to:
- Did they actually deliver when they said they were going to?
- Are there easily identifiable bugs?
Hire a Technical Person to Review Their Code and Ask Deeper Questions
This is probably the most sure-fire ways to know whether a dev is good or not.
There are countless micro “tells” in the code. To name a few:
- Lack of linting — linting automatically checks and fixes simple code quality problems
- Proprietary code that should be open-source — you shouldn’t pay someone to re-invent the wheel
- Lack of comments — human-readable comments are crucial for any project where there are multiple devs or a project that lasts more than 3 months
- Non-standard architecture — there are a million complex ways to do architecture, but few that are standard and well-recognized among other developers
I’m happy to help you vet developers out, provide architecture and structure for other developers, or to take your project start-to-finish. Reach out to web@tuckerconnelly.com.
