I came away from CALMalpha with a profound sense of depression.
Our industry is in an awful state. A really awful state. It took me a day and a half to recognize one of the problems. There’s a prevailing sentiment that I keep hearing that, “If only we provide the right bucket for them to deliver in, teams will deliver.”
You know what? This isn’t true.
Of the many developers I’ve worked with over the years, I’ve been lucky enough to work with the best. These are the developers who can code well, work in teams, learn quickly and respect and learn from differing opinions.
I shouldn’t have to be lucky to work in teams like this. Engineers don’t get away with it. Architects, pilots, restaurant staff and dustbin men don’t get away with it*. We have such a low barrier to entry in this industry, it hurts. I shouldn’t have gotten away with it for as long as I did!
While I was at the conference, a gentleman linked to one of my blog posts about Scrum and Kanban, calling it “pontificating rubbish”. I wrote it mostly because I was already fed up of the fighting between the two communities: there’s more similarity than difference. This gentleman said, “Can we just ship some software already?” Iain, I need to thank you. Your comments must have stuck with me, because by the second day I found myself thinking, “He’s right.”
One of the things we strive for in Agile and Lean is a high-trust environment; one in which the business give us the space and time that we need to deliver the things that they really want. As an industry, though, we don’t have that trust, because we haven’t deserved it. Even Agile and Lean haven’t solved the problem. Even Agile and Lean don’t ship on time, and even Scrum projects occasionally wait until the last moment to tell people it’s going to be late (and yes, I know this isn’t how you ought to run a Scrum project). So here’s the first problem:
Many of the developers I’ve interviewed over the last decade can’t communicate. They can’t code, even when they’ve been told that it’s part of the interview. I had one dev provide a code sample that they were completely unable to work with – I’m guessing a friend wrote it. I’ve had samples submitted which were ripped off of the internet. I’ve worked “with” devs who were sidelined onto useless projects, deleted afterwards, because they were no good at coding and too nervous to help. No wonder, as an industry, we can’t ship. No wonder those of us who spend our time at conferences and self-improvement workshops are befuddled as to why. The faculty at CALMalpha talked about how crews work, and the training they undergo. We don’t do that.
One of the things that David Snowden taught us is to aim for fail-safe probes – a thing that we try, in order to make a change, which might fail and which is safe to do so. He also taught us not to attack the problem directly. I’m not sure that this is even a complex problem, but the fact that it hasn’t been solved yet suggests it might be. So rather than saying, “Just ship it already!”, here’s what I suggest (and please, if you have an understanding of complexity theory and can see some stuff that might not be safe to fail, let us know quickly – I’m new at this).
Get devs to code in the interviews.
Do it, and spread your success stories. I’ve not yet found a company who’s done this and stopped. Code with them – pair on some silly, simple problem – and you’ll also find out what they’re like to work with, and whether they’re able to learn and talk to you.
The idea is not necessarily to filter the developers. If this happens industry-wide, we’ll quickly run out of devs who can code, and something else will happen. Perhaps a lot of them will be able to learn quickly, and you may find after some time that you’re frustrated looking for the ones who can code and you’ll settle for the ones who can learn. Or maybe the universities will up their game. Perhaps it will become accepted practice that developers spend time learning, and companies will give them more space.
If this fails, and we find that we can’t get people to code in the interview, we’ll be no worse off than we were and we might find out something more about the problem.
*Dear Dustbin Men
Without you life would very quickly grind to a messy and disease-ridden halt. You are my heroes. You do the job that I do least want to be doing, for a lot less pay than I’d do it for. This is why I’ve picked on you – not because I think you’re low on the list of people who need to work as a team, but because your job is so stressful in my estimation that I believe you have the right to work in any way you want. That I always see you working together, usually smiling, carting away all our rubbish and doing extra work to make up for Christmas etc., is amazing. Thank you.
(I have never yet seen a Dustbin Woman).
Devs, our job is ranked as really not all that stressful. We do not have the excuse.
Liz Keogh, lunivore 
actually, I think fixing the state of our industry is a perfect example of a complex problem–possibly even chaotic.
One of my several standard rants has been that most people in our game have never seen a good team, they literally don’t know what they’re missing. Who knows what to do about that.
And, yes to coding tests (in the room with discussion, not to be sent back later). Some of us have been doing this for a decade and I know of one case where a candidate got to release production code in his interview (of course he got the job).
Seconded, and not just for devs: The company I work at now has a much higher average programmer quality than any I’ve worked with in the preceding 20 years. And interviews consist almost exclusively of pairing. I don’t think that this is a coincidence. Recently, our SaaS product is in a phase of its growth where we’re hiring much more rapidly in non-development roles than for developers. And our hiring there has been hit-and-miss. And our current plan to fix this is to “pair” in interviews for other things: to actually do real work side-by-side with the applicant. It’s too early to judge yet, but I’ve got a lot of hope that pairing during interviews will allow us to match our currently excellent support, QA, etc. people with the ones we’re going to be brining on. Fingers-crossed.
I have no problem with devs having to code in interviews but I think coding is close to the bottom of the issues facing us. Developers, even the ones that are up there with the best, are often shamefully poor at communicating with humans. I think this leads to a sense that the code is everything. The code isn;’t even close to the most important thing. I’d rather someone copy and example they found on google and discuss it with me in a way that demonstrates an ability to comprehend something they’ve never seen or possibly even heard before. I want to see someone demonstrate an ability to run with a user interaction problem and see how they solve it, and why. I want to see developers interact with the people that can’t code in a way that reassures me that the real goals are going to be solved rather than endlessly refactoring the code because a) it’s not perfect and b) it didn’t do what it needed to to solve the larger goals of the project.
Although I agree wholeheartedly with your main idea for improving (interview pairing) and I find your passion for improvement laudable and admirable, I feel obliged to say something in defence of ‘our industry’. Compared to all the professions you named (and pretty much any other profession you might care to name with the possible exception of astronaut), the professional developer and their industry are a brand new phenomenon. And still it’s true that software has become almost ubiquitous in but a few short decades. Simply put, it has transformed our lives, and will probably continue to be the most profound agent for change for some time to come. Pick any (medium to large scale) project at random from any industry you choose and many of the problems we experience with delivering software are evident there as well – muddled (or megalomaniac) vision, delays, budget overruns, shoddy execution etc. And we’ve been building with bricks and mortar for thousands of years…
Yes. But things are they way they are. If you really care about this it’s not really enough to just lament the poor state of things. If you really care you need to DO something. Talk changes nothing. I care and I have DONE something.
I have built CyberDojo. So now there is NO excuse not to practice doing coding in interviews. It’s just a URL away … http://www.cyber-dojo.com
Ericsson have been using CyberDojo to code during interviews (in pairs) and they report the number of interviewees getting offers has gone down markedly.
So please, help me promote CyberDojo.
Musicians need to show competence at making music inorder to get work. Actors need to show competence at acting. No one would dream of creating a band by hiring commodity musicians in India they had never heard play, relying solely on getting the production process right. Yet we do this in software all the time.
We have the wrong metaphor. What we do is not a science, the label of “Engineering” doesn’t fit either. What we do is more of an art, more akin to the work of the Musician or the Actor. Like these and other creative professions, we need to put the practitioner at centre stage.
This realisation isn’t new. The frustration between what really works and our prevailing approach is what lead to the Agile movement in the first place. Like Steve says most people haven’t experienced “good”, simply because their environment doesn’t allow for it.
The saddest thing for me is that in our eagerness to gain traction with the mainstream we have diluted our central theme of individuals and interactions over proces and tools.
Leaving another generation to learn the lesson all over again!
Pingback: Nice and Respectful « Think Different
I’ve introduced coding interviews in our company recently. I think it adds a lot.
As far as the state of the industry is concerned, I do think that Ciarán has a point that most industries have their dysfunctions, and often those are more seen from inside the particular industry that from outside.
One common complaint I hear, both in IT and in other places, is the remarkable lack of people that are consistently learning to do their jobs better. Or even to do anything better. Whether it’s experiences at school, or simply lack of interest in general I don’t know. It just seems to be rare that people try to get better by either practice or study. Most courses and trainings are followed because required by the boss, not because of a challenge identified by the people themselves.
Actually, I wouldn’t be surprised if that particular problem is not less in IT than it is elsewhere, with our relatively high rate of intelligence/geekiness. But it’s still quite common.
Pingback: Doing pair programming tests right – Steve Freeman
The problem is of course that there’s money to be made, whether you do a good job or a bad job. And there are plenty of companies who will do anything to get staff in the door, whether good or bad.
Another issue I think is that there is no standard way to mentor a developer and review that progress is adequate. So taking on both graduates and new staff is a dice roll. Certainly certification is not a good metric for adequacy.
If you offer enough to get shysters in (and pretty much all dev jobs are in the category) you could keep a number of additional metrics to reduce the list to an interviewable number (open source commits), a portfolio project (bring you source code to a show and tell), invite a treatment of the last technology they finished a tutorial on. I’m sure there are more possible – especially in the softer skills such as comms, time-management, team work, and doing all the parts of development:
* Testing
* Design
* Documentation
* Requirements validation
* Logging
* Error and exception handling
* Version management
* Learning a new library
* release notes
* Running static analysis
* Configuring CI for your library
I have given many coding tests in interviews, and I am a big fan. The purpose of coding in an interview though is not to see how well a developer codes, but how well they work with another person, communicate and work through problems. The last thing I am looking for in an interview is the quality of a devs code, we can change that in a few code reviews. I tell the candidate that I am most interested in how they work, not how they code, and that they will score the most points if they bounce ideas off me, and the least if they code in silence. And then at the end of the interview, I ask miself, would I want this person on my team? I take into consideration their problem solving abilities that I observed, the way they worked with me, if when the encountered a bug they just stared at the code dumb for half an hour or if they used a debugger etc.
Pingback: Agile punks – Go write an app | Convivial Coding
Nice post Liz, I really enjoyed it. I was working for a company which stopped doing pair programming during interviews, because the interviews were the “thing” of the managers and since they cannot code nothing really happened.
What I don’t understand is why organizations don’t fire employees during their trial period if they don’t fit into the organizations’ environment. First I thought it has a psychological background: if you fire someone you hired will make you look incompetent in the eyes of your colleagues and this makes you week. But it turned out that the situation is much simpler: large companies don’t care they need numbers and the new employee is a problem of another person who cannot fire anyone, which is sad.
I think the key is to have coding and checking on soft skill during the interviews and say goodbye during the trial period if necessary.
I work for a well known British Media company, and we do lots of hiring, most recently for the Olympics. Over the last year or so we’ve been trying a different approach. We found that sometimes really good devs need to think about solving problems, and asking them to crack through some simplified test is akin to pressure cooking them, and not in a good way – we don’t (always) work like that. Instead, ee send out a problem – a real one we’d ask them to build if they worked on the project – and they complete that, taking in guidelines about what we want to see – testing, correct use of progressive enhancement etc. This code them forms the basis of the interview. They need to reason the design, suggest improvements and critique their work i.e. its a code review. It seems to work well so far. Pairing is another nice approach though agreed.