How likely are your employees to recommend you?


Want a quick and easy way to find out what your employees think about your company?  The Employee Net Promoter Score (eNPS) is a subset of the Net Promoter Score and is a survey based on one question:

“How likely are you to recommend our company to a friend or associate?”

Employees are asked to choose between 0 and 10. And are given the option to elaborate on their score. Here are the categories of employees you will identify from the survey.

  • Detractors (0-6)  Most unhappy employees who are highly likely to churn.
  • Passives (7-8) Employees who are satisfied, but somewhat unenthusiastic about working for your company.
  • Promoters (9 -10) Employees who are loyal enthusiasts of your business. They will stay with you for longer and will recommend your company to others.

The eNPS can lie between -100 to 100 and is calculated as:

%Promoters – % Detractors

Because the survey is based on one simple question, employee response rates are much higher compared to longer, more traditional surveys.

Further benefits of Employee Net Promoter Score include:

1.)  The results are easy to understand and give you a good clear idea of employee loyalty.

2.)  Allow you to identify employees at risk of churning and address their issues.

3.)  Allow you to identify promoters and what’s making them happy.

4.) More and more companies are using eNPS, so it’s great for benchmarking.

There are lots of Net Promoter Score survey tools available. Find the right one for your business and start to improve employee retention.



7 Habits of Highly Effective Programmers


What is the difference between effective programmers who get stuff done and delivered, compared to those who may be technically competent, yet struggle to translate it into delivery?
Clearly the environment a programmer works in has the greatest impact, even the best can struggle if their hands are tied by an environment where they are not empowered to deal with the issues impeding their progress.
But assuming all things are equal, the environment a programmer works in allows them the freedom and ownership to get things done, what are the habits and personality traits that differentiate the great from the good? What makes someone highly effective compared to average?

Always be learning

Great programmers are great learners. Not only when it comes to technology, programming languages and libraries, but also when it comes to learning the domain in which they are solving problems. In my opinion, in evaluating a programmer, especially when hiring, it is far more important to understand how likely they are to pick up new skills than what their current skill set is. Libraries and programming languages come and go, so having learned one 5 years ago is not nearly as useful as being able to quickly pick up new ones.
Furthermore, for every problem a programmer solve, it is likely to be slightly different than the last one they solved, even if it is appears similar at first. Programming is not manufacturing, it is new product development. This means being able to learn on the spot how to solve new problems is far more important than knowing how to solve the problems of yesterday.

Self-awareness - knowing what you don’t know

The Dunning-Kruger effect is far too prevalent both in the tech industry and in society at large. Knowing what you don’t know is almost as important as knowing what you do know. Being able to introspect yourself, know your weaknesses and know what is unknown allows you to work around your weaknesses and mitigate the risks of the unknown.

Putting the ego in the backseat

Big egos are toxic to teams and to delivering. Delivering software to solve a new problem is a perpetual state of being wrong, working towards being less wrong. People who are hung up on ”being right” are unlikely to understand this. They are also unlikely to fit the previous two criteria: Self-awareness and being perpetual learners.
Humility is important, being able to discard your previous mental model as your understanding of a problem evolves is crucial to refining your solution to a problem and delivering a better solution. Not only that, big egos can be toxic to harmony of a team, multiple big egos are almost guaranteed to spell problems to any team.

Passion for the problem, not the solution

Some people fall in love with their solutions to a perceived problem and try to find or fit a problem to their solution, rather than understand and solve a problem in itself.
This is as prevalent in technology delivery as it is for companies and their products. Ability to be passionate about a problem, instead of its suggested solutions is as rare outside of technology delivery as it is within. Programmers are not the only ones afflicted by “solutionitis”, it is equally common among entrepreneurs and corporate executives.
Being passionate about a problem and not a solution means being open-minded about your understanding of the problem, being willing to dig deeper, ask “why?” and be aware that the initial stated problem may only be a symptom of a deeper underlying problem. Understanding that there may be hidden, underlying problems also means that the initial proposed solution may not only be wrong, but solve the wrong thing altogether!

Finding the most leverage possible for your effort

The Agile community often expound the virtues of ”doing the simplest thing possible”. I believe this is good, but actually slightly misguided: it’s not about doing the simplest thing possible, it’s about finding the most leverage possible for your effort, getting as close as you can to your target for the least possible effort, but no less.
A sequence of the simplest thing possible doesn’t necessarily get you much closer to your goal, it will only make the effort required over that duration seem easier. What we really want is to get as close to our goal as possible at the least possible expense and effort.
This means being able to find non-obvious solutions, trade-offs, understanding the 80/20 rule as it applies to the problem, knowing what can be ignored and what cannot.

Finding ways of reducing features & complexity

Less is more. This also applies to features and complexity. The paradox of having lots of features is that each feature comes with its own assumptions, which as an aggregate can cause software to become more rigid and less suitable to unforeseen scenarios.
Inversely, most of the time a multitude of scenarios can better fit into a solution if a small set of patterns that capture most/all scenarios can be identified, rather than trying to deal with each scenario as a unique case. There are cases in which thinking a little bit more about a problem, reducing it to its essence and cutting down features will result in far less overall effort, far fewer defects, and far more usable and reliable software.

Productive laziness

Donal Knuth stated that “premature optimisation is the root of all evil”. This is true, as much in design as in performance. Sometimes drudgery is an unavoidable part of developing software. However, when the drudgery is long-running or repeating, the effective programmer will recognise this in time and either finds shortcuts or ways of automating the drudgery. Drudgery is a waste of effort and brain-cycles that could more productively be used elsewhere, finding the shortcuts helps increasing the time that you can devote your brain to higher value activities.


Each of the habits/traits listed above stand on their own, but there is also a thread running through them: many build and depend on each other. Passion for a problem goes with self-awareness of what you don’t know. Willingness to learn and self-awareness requires humility and an ego that is in check. Finding ways of reducing features and complexity requires you to really understand the root of a problem. Productive laziness and finding leverage for effort are two sides of the same coin, they are expressions of the same principle.

How do you identify developers that have these traits? That will be the subject of an upcoming post! If you want to get notified, sign up for new blog posts in the form below.

Recruitment is Broken


Recruitment, in particular tech recruitment is broken, there’s no two ways about it.

The CV is a useless predictor of ability or performance

The CV as a filtering mechanism will yield random outcomes at best. People looking at CVs tend to focus on keyword matching, spelling errors, grammar and previous employers. Spelling and grammar tells the person reading the CV whether the candidate used a word processor with a good spell- and grammar checker. Previous employers tells you a candidate managed to get through the recruitment process of company X, Y and Z. Given how much dead-weight a lot of organisations carry, previous employers may not tell much at all.
For programmers, the CV is almost useless as a predictor of ability or future job performance.

People who don’t know the work filtering candidates

Today, much of the initial screening of potential candidates for tech jobs is done by people who have little familiarity with the actual work they are screening for. When it comes to speaking to candidates, these sort of people will often focus on things like if the candidate “can speak confidently about their work”. This favours people who can talk a good game, rather than those who are simply capable.
What if you have a great engineer, who just doesn’t take well to the pressurised situation that is a job interview? What if you have a candidate that is incompetent, but talks a good game?
It might be worthwhile being familiar with the Dunning Kruger-effect and Impostor syndrome respectively before making quick judgements based on confidence displayed by candidates.

Recruitment thrives on conflicts of interest

Firstly, the recruitment industry currently largely functions on the basis of the activities we have debunked in the previous two paragraphs. Secondly, the industry often thrives on ethically questionable conflicts of interest, this is especially prevalent in contract recruitment:
For contract recruitment, it is often in the interest of agencies to try to extract as great a pound of flesh as they can from the hiring companies, while pressing down candidates as far as possible on their rates, so that the agency can pocket as big a difference as possible. Recruitment agencies are basically (ab)using their position as a middle-man to exploit both sides. Finding the best candidate can become secondary to extracting the biggest possible margin.

Untenable status quo for candidates or employers alike

The way the recruitment industry works today isn’t working for candidates or employers:

  • Good candidates get rejected for seemingly random reasons.
  • Processes unsuitable for finding exceptional candidates.
  • Hiring managers are met by a mountain of CVs and stream of unsuitable candidates.
  • Organisations suffer from unecessarily high employee turnover because candidates expectations are not met when they start a new job.

We find it hard to believe that anyone, candidates or employers are happy with the current situation. It surely has to change.

The Nonsense of 10X developers


This week has seen some sort of peak nonsense when it comes to the concept of relative skill among programmers and how to recognise it. First there was this article in the New Yorker talking about “10X developers”, seemingly paraphrasing conversations from the comedy show “Silicon Valley”, though I fear they where actually real conversations. Then there was this article on how to evaluate programmers by open source contributions.

There is no such thing as a 10X developer (without a 10X environment)

Let’s first start with the mythical 10X developer: there is no such thing. Yes, relative skill and productivity between programmers can vary wildly, but I would posit that most of the difference you see between organisations ability to deliver software has nothing to do with how many “10X developers” you have hired and everything to do with culture. True, hiring smarter people will make a huge difference, but ultimately their performance will be more constrained by the environment they work in than the capacity of their brains. Again, hiring smart people may in gentle ways nudge the culture and environment, but it is no guarantee.

What good is it having 10 super-smart people if your organisation has fostered a culture where they are effectively held on a leash? There can only be “10X developers” in a 10X environment & culture.
Personal experience is anecdotal, but I have seen environments where a small team of mostly individually average developers have delivered incredible value in a few short months that would make the eyes water for most companies (one example of 3 developers, 3 months and a guaranteed return of $40 million comes to mind).
I have also seen environments where individually brilliant developers achieved absolutely nothing, zilch, nada over the course of several years.

The myth of the individually brilliant hero-developer who comes in and saves the day may be an appealing one, but it is largely just that: a myth. There are far easier ways to improve results than go looking for that one superhero developer that will save your company: how about taking the leash of the developers you already have? If they’re half decent, chances are your results will sky-rocket.

GitHub & Stack Overflow as a CV: Notoriety != skill

Let me put this another way:

Someone having a loud mouth does not imply what comes out of it is wisdom

Some one being notorious online, having a high profile in project X, talking at conference Y, or having answered 20000 questions on Stack Overflow says very little about whether what they do has any substance.
Popular open source projects must be good, right? Wrong. Any project under the Apache project is almost certain to be 90% God-awful code that will make you want to rip your eyes out. Spring Framework is undoubtedly one of the most popular software libraries/frameworks in the history of mankind, yet it is an abominable bag of fail and poor engineering.
Stack Overflow then? 75% of the answers are stupid at best, misleading at worst. Popularity tells you absolutely nothing about whether something has quality.

Furthermore, many developers use GitHub as a repository for personal experiments, learning projects and hacks (I do) - in these cases the code may not have any resemblance to the quality you might expect from someone writing code for a production system.
Another large group may only have negligible GitHub repos, or, shock-horror, no presence at all. There are a variety of reasons why people don’t have code in public: they may simply, God forbid, have a life and family - this is no reason to write them off as developers.
Another, and regretably extremely common reason for no online presence may be that their employer has very strict rules about ownership of Intellectual Property, prohibiting individuals from contributing to open source or other closed source projects without their employers explicit approval. I have seen more employment contracts that have clauses like this than not (yet another good reason to stay independent).

Hiring & culture is hard, get over it!

The concept of “GitHub & Stack Overflow as your CV” is a weak cop-out by those either unwilling to make time for properly screening new hires, unknowing on how to do so, or simply those who are subject to both of the above, but want to rationalise their hiring decisions with “but he/she has an extensive public profile, so they must be good!”. GitHub may show you an indication of someones ability, but you have to dig deep, have a look, and also ask the programmer what projects he has taken seriously and which ones are just “scratchpads.

Hiring is hard, there is a multitude of factors that go into it, and most organisations have a woefully poor hit-rate when it comes to successful hiring (despite their insistence on “only hiring the best”). There really are no quick fixes. There is certainly a “minimum bar” threshold that needs to be met in terms of skill, but beyond that, the success or failure of a hire has more to do with a multitude of interacting factors which can be unpredictable.

Whether someone is going to be a successful hire or not is often more a function of the organisation they are about to enter than the person themselves. Don’t try to look for heroes and scapegoats, or resort to voodoo hiring practices when most of the performance could potentially be unlocked simply by trusting people with the freedom to do their jobs.

Why "brain teasers" are useless


A lot of companies use “brain teasers” during their interview processes - these tend to range from algorithmic problems to be solved on paper, to questions of a nature where you either know the answer or you don’t, to questions which are just nonsense to see if someone can reason about an impossible problem without getting flustered.

“Paper programming” is not programming

Solving problems or writing algorithms on paper is not a particularly accurate way of measuring someones proficiency at software development. Yes, some people may be good at it and good at programming, but that is likely more to do with how their mental process works than anything else.
If you want to see how good someone is at programming or how they think about programming, put them in front of a computer! Make them do actual programming, on a computer! Let them Google, search API docs and everything else they would do in a normal working environment. After all, we do all these things in our daily work of programming, why does a programming test need to be an artificial environment where their memory rather than proficiency is tested?

“You know it or you don’t” problems are useless

The sort of problems that “you either know or you don’t” are equally useless. All you are testing is whether someone has heard/read something or not and if they remember it. I can see why people do these things - in some cases, the knowledge may be important, but wouldn’t it be more relevant to test whether a candidate will be able to quickly grasp the concept, rather than if he already knows it?

Programming is an ever evolving, changing landscape and industry, you want to find people who can evolve and learn quickly, who can solve problems by reasoning and knowing how to acquire the relevant knowledge if they don’t already possess it. Testing their memory and whether they can jot down the relevant answers on paper from their memory is not a productive way of identifying these people, at worst it will only identify those who have become good at interviewing through repeated exposure to the defunct methods of yesteryear.

Programmer auditions - Actors do it, so why shouldn't developers?


Beyond a select few “A-listers” that are known to everyone, actors audition for roles all the time.
Even those on the so called “A-list” usually rose to fame thanks to roles they got by auditioning: Robert De Niro was virtually unknown when he auditioned for “the Godfather”. Harrison Ford had only made a few minor roles and made a living doing carpentry before he auditioned for the role of Han Solo in “Star Wars”, beating Kurt Russell to the role in the process.
Auditions is how Hollywood discover their future stars and their diamonds in the rough.

So why shouldn’t programmers be exposed to the same scrutiny when going for a job? The thought of hiring programmers, without actually having them do a little programming first seems ludicrous to me. Could you imagine someone hiring an unknown actor for a big role by merely glancing over their CV and having the following conversation?

“I see you played Hamlet in your previous role, how did you do?”
“I was great, I played the role with great emotion and really brought the character to life.”
“Great! You’ve got the job!”
It’s ridiculous of course, yet this is exactly how most programmer interviews are conducted. Maybe some throw in a little brain-teaser, or a paper-based or whiteboard exercise - but it’s still not programming.

If you want the part, show that you can play it!

If someone wants a job as a programmer, it is not unreasonable to ask them to do a little, you know, programming. Not a brain-teaser, or a few lines of code, but a proper programming task, using a real IDE, build system and version control system. Show that you can solve a problem, model the problem in a useful way, use good engineering practices solving it.

Some developers may object saying “I’m too good to take a test!” - are you really? I’m pretty sure most aren’t the “Robert De Niro” or “Harrison Ford” of software development - most have to prove themselves if they are unknown to someone, and you do not do that by providing a CV or telling someone how good you are expecting them to take your word for it.

Others may object “I don’t have the time to take programming tests in my own time” - really? You have the time to take half a day and go to an interview, not knowing what to expect and potentially flame out, but not the time to spend an hour or two in the comfort of your own home, solving a simple programming task? Wouldn’t you rather go to an interview after a test, knowing that the hirers know you can do the job, with the interview merely being a low-pressure meeting to see if there is a mutual fit and liking between the two of you?

There are plenty of developers, or I should say “developers”, who can talk the talk, but can’t walk the walk. I have interviewed plenty of candidates in my day that where really impressive in an interview situation, but utterly failed to solve even the simplest of tasks when they where sat in front of a computer and asked to solve a simple problem.
There are also likely plenty of perfectly competent or even great developers who could easily solve problems elegantly, but completely freeze up in a high-pressure interview situation where they are bombarded with questions.
Do you really want to bias your hiring in favour of the “incompetent talkers” while missing out on great developers who just get nervous with the interview format?

Developers auditioning in their own time, with their own tools

The bias may be obvious, given Code Qualified is a tool for automating “developer auditions” to a large extent.. But whatever your tools (or lack there of) and methods, it should be obvious that if you are hiring programmers, the closest you’ll get to an objective and fair way to evaluate if someone is up to the task is to actually get them to do some programming. Not on paper, not on a whiteboard, but on an actual computer.
Personally, I prefer the “audition” being a problem/task for the developer to be sent out, allowing the candidate to do the test in the comfort of their own home, with their editor or IDE of choice, using proper build- and version control tools, far from the high-pressure situation of feeling “watched” in an interview. That is after all, the closest you’ll get at that point of the hiring process to seeing the output of what they would produce on a regular day in the office.

Older Posts