Summary
A business owner at a workshop I held made the very disturbing comment that he thought that 70% of programmers were "rowing backward," doing things that you had to fix in order to keep the boat moving in the forward direction.
Advertisement
This person had created a software tool company of about 25 people that he later sold to a much larger company. Based on his descriptions of his company before it sold, I guess he is referring to his after-sale experience with the much larger company. Or it could just be his experiences with customers using his tools.
His anecdotal "70% Rowing Backwards" sounds roughly right to me, and it bothers me a lot. Studies show that programmers derive their primary satisfaction by being productive, so such an environment sounds downright depressing. But managers obviously don't want this kind of thing to happen either. It's wasteful and costly. Of course, if you believe that you're a productive programmer you may think that you're rowing in the right direction when you're not (actually, I know I've gone in the wrong direction while thinking I've done the right thing, and I think we can discount the small percentage of people who are intentionally causing trouble as being mentally unbalanced). If you're a manager, presumably you are getting information that makes you believe you're making the best decisions given the situation.
And still, we are only fractionally productive compared to what we know we can do. How did we get here? (Jerry Weinberg says: "one logical step at a time.") Why do we stay here? (Because we think we're doing the best we can in the given situation, and change is hard.)
Is there some way we can change things?
Instead of holding a session that discussed the problem, I decided to go out on a limb and hold a session to try to come up with an answer. My fantasy would be to come up with something like Open Spaces, where the solution is so topsy-turvy that you have a hard time believing it works, but when it does work (because it relies on everyone acting in their own self-interest), it works better than anything else you've seen before. And requires minimal leadership and structure.
I believe such an organization can be created, but I haven't imagined it yet. When it became clear that we weren't going to get very far in the session, I suggested that we go around and describe the best job we've ever had. This turned out to provide great insight.
To a person, everyone described the best team they'd ever been on. The actual state of the company was unimportant; it could be falling down around their ears and if the team was great, they were very happy.
Six Hiring Points
Later, at one of the meals (these are not formalized during the JPR, but happen in various and sundry different ways), the discussion turned to the most important factors in hiring. The hiring process in most companies amazes me because it seems to be a short courtship for such an important choice. I suppose this happens because "hire a database programmer" becomes a to-do item that someone would really, really like to cross off. Everything is being held up, and if we could "just" fill that position we can move forward. Thus it becomes a short-term urgency, and the thought of both the short- and long-term damage that the wrong choice can cause is pushed to the background.
Our group came up with six things that you should test for when hiring someone, each of which is critical for the well-rounded programmer that everyone wants to have on their team.
Technical Knowledge. This is the easiest thing to test for, and it's what most companies fall back on. It's ingrained from our own decades of schooling. However, technical knowledge is a relatively small part of the picture, and only for the short term. Even though it's what is typically tested, the remaining points on this list are the truly important ones.
Critical Thinking. This industry is full of new technologies that promise to solve all your problems. Architects like to think they have it all under control, and hand out a system design to be consumed without question. When the programmer encounters a real system, are they capable of expressing doubt and asking the right questions?
Can You Solve Problems? The college teaching system trains people to learn for tests that have one right answer. A system like this often produces people who believe that programming is a bunch of rules that you simply apply. What does the candidate do when they encounter a real problem where the answer is not clear and balancing tradeoffs is necessary?
Can You Learn? A hire that self-teaches is very valuable. This is less about classroom situations than it is about learning from other outside influences. Can you learn on your own, and more importantly, do you want to? What have you learned recently, under your own motivation?
Can You Change Based on Environment and Evidence? Which means: Are you open to a better way of doing things? However, not every single "better" way of doing things that comes along. This requires a balance between the ability to see and adopt a change when that change is truly an improvement, but at the same time having a highly developed sense of skepticism and a good BS detector.
Are You Toxic? The worst person to hire is the one that passes tests 1-5, but turn out to have some kind of quirk or imbalance that causes destructive behavior. There's nothing worse than dropping a toxic person into a team.
When you see these in a list, they may seem fairly obvious. Of course everyone wants to know about these things in an interview. Why doesn't everyone find out about these things? It's because they're harder to test for, sometimes much harder to test for, than technical knowledge alone. Even though you know hiring the wrong person is like accumulating credit-card debt (easy to get into, but costly to carry and hard to get rid of), the temptation is great to just hire the person, check that task off the list, and hope that they will work out. But as I learned from some workshop, "Hope is not a strategy."
Testing for the Six Points
The success of a new employee is going to depend far more on points 2-6 than point one. So to become more successful as an employer, you really do need tests for those points, and you need to apply them on every single candidate, or else you're going to end up with a lot of employees that are rowing in the wrong direction.
Technical Knowledge.Of course you need to know what level of technical knowledge a candidate has; the problem is only testing for technical knowledge. And consider this: someone with a hard technical background, such as physics or chemistry or engineering, may be a much better candidate because they can learn faster and tackle harder problems, even if they have relatively little formal training in programming. So they might not know how to write an insertion sort from memory, but they also might be more valuable than someone who does. Remember that code reviews are an incredibly valuable way to discover problems. So show them some code and have them review it, and see what kinds of problems they can discover and improvements they can make. That's likely to be far more revealing than whether they have something memorized. A good programmer looks things up anyway, so memorization is not a skill you really want to test for.
Critical Thinking. Ask the candidate to compare two technologies that they know about (EJB vs. Hibernate/Spring, for example), or to talk about the applicability of a tool (what aspects of UML are commonly useful, and which are rarely used?). If they know more than one language, ask where one language might be more appropriate than another. Show them a design or an architecture and ask if they see problems and how they might improve it.
Can You Solve Problems? You want to see problem-solving in action, so give them a problem and watch. Two that I like (I think I heard them from the same person) are: "make an object model of a chicken" and "design an online monopoly game." I think it's important that such problems be open-ended, because that adds an extra dimension to the problem-solving experience. Challenges that involve back-of-the-envelope calculations or estimates are good, because software design is an inexact art and if someone cannot move forward unless they have an exact right answer they may not be a match for your team. Another thing to notice is whether they ask questions during the process; this gives an indication of whether they consider software a team sport or if they are a "lone wolf" developer.
Can You Learn? Ask the candidate what kinds of things they have done to enhance (if they were in school) or continue (if they were working) their education. User group meetings are a good indicator, as are conferences, workshops, and seminars. What books have they read? Have they learned new languages or technologies? If these are self-taught this is a very good sign.
Can You Change Based on Environment and Evidence? For a programmer, the most telling fact may be the editor they use. If a programmer is hardwired to only use emacs or vi (for example) and could never consider using anything else, they may also fight any efforts to do unit testing or use version control or your build system. Or to use any other tool that might improve productivity. Ask what kind of editors and development environments they have used; ask them to create something with that tool. If you really want to see them in action, walk them through the development environment that your team is using.
Are You Toxic? Testing for toxicity is the trickiest and most difficult of these tests, primarily because bad behavior doesn't show up until a person perceives that they are in a position of adequate power, which is to say, after they've been hired and very often after they've been working at a place long enough to know what they can get away with. There are three approaches I can see to the problem:
Follow up on references -- former employers tend to be very careful because they fear lawsuits, but if you give the former employers lots of room, they might say things between the lines that allow you to pick up important clues. If there are gaps in employment, find out about those. If an employer won't speak to you at all, that's an important clue.
A simulation of some common activity where the toxic individual is likely to lose themselves and expose a problem. For a programmer, pair programming with someone on the team may show certain kinds of behaviors.
There must be a probationary period where, if the new hire turns out to be toxic they are dismissed. Yes, this is painful because you have to go back through the hiring process (although you may be lucky enough to tap your second or third choices from the original process), but if you don't do it you will either greatly reduce the productivity of your team or destroy it altogether.
The No-Asshole Rule is a book that was highly recommended by a friend, though I have yet to read it myself. It may or may not help here.
How would you test for these points? Are there other points you consider important during an interview?
Further Reading
I found The Five Dysfunctions of a Team to be a very insightful and helpful book for understanding what a team needs to do in order to work well, and the numerous ways that a group can fail to be a team. The dysfunctions and their effects are:
Absence of trust, which causes "invulnerability" in each individual; Fear of conflict, which produces "artificial harmony"; Lack of commitment, creating ambiguity in the team's goals; Avoidance of accountability, leading to low standards; and inattention to overall results, which causes individuals to pursue results for themselves, increasing their status and feeding their ego. The book also had a great definition for "politics": "Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think." Also, there are supplements to the book, including a workbook showing how to administer the team-fixing process.
Well, in Enterprise these days (Fortune X00), the biggest impediment (and might be quite different with start ups, although not different at the ones I have been at) to productivity is the reversion to the 1970s COBOL/file view of development: the code has dominion over data.
Dr. Codd (and others) realized that the data was what counted, and so devised/discovered a way to build systems from the data outward.
The java folk have convinced themselves that data is secondary to code, and thus have created a new generation of bloatware.
In ten years, maybe someone will have the vision to undo the IMS/xml reversion. Pascal, I have concluded, is probably right to have departed the field. Nonsense has triumphed.
Specifically on the hiring question, one thing that I've found is similar to pair programming: give someone a problem that's fairly difficult, ask them to solve it, and then see how well they respond to help or criticism. Some people will accept it and say things like, "Oh, yeah, you're right" or "Ah, okay, that makes sense," or even "Hmm, that's interesting . . . let me try to explain why I think what I have is actually right." Others will immediately get defensive at any suggestion that their code/thinking is flawed or that they might want assistance; rather than working with you to get to the right answer, they'll try to fight you to prove that they're right. The interview situation is certainly high-pressure for everyone and can contribute to people getting defensive, so it's maybe not a perfect litmus test, but in general it demonstrates a certain kind of insecurity and/or arrogance that's toxic to work with, so people that respond that way don't make the cut.
Employers always wonder if the employees are good enough or not. But really they should be asking themselves, "Am I a good employer? Why should anyone work with me?"
From what I understand, no one is randomly toxic. The difference is in how various people respond to abuse. When you abuse people they respond differently (not in any particular order):
1. Some leave the company. 2. Some try to talk to management in private and leave it at that. 3. Some will escalate the issue to upper management. 4. Some just grit their teeth and bear it, assuming (incorrectly) that it just doesn't get any better, and that nothing can be done. 5. Some become toxic (as described in point 6). 6. Some become fiscally violent -- you may get your servers wiped or you may get your router configurations deleted, etc. 7. Some become physically violent (a.k.a "going postal"), and may shoot you in the face. 8. Some start an internal revolution, such as starting to work on side projects unrelated or even detrimental to company goals and can even get wide support from their teams. Alternatively they continue to work for the good of the company but completely disregard company directives/suggestions and may encourages others to ignore the executives layers of the company. 9. Some get angry and start asking for bigger than expected raises, thinking, "If I have to suffer this much, at least I should get paid for it."
And so on. I'm sure I'm missing about a 100 other ways a person could respond.
The point I am trying to make is that people, in my experience, do not "just become toxic". There is usually a good motivation for it. You may not think it's good, but it makes sense from that person's point of view.
If your company is having issues with people who seemingly "just become toxic", I suggest you take a long look in the mirror. The problem is probably with you and your company.
That said, I believe the interview process is something that's going to go away. You simply cannot interview for good programmers. You have to see them work. The best way to hire a good programmer is to simply see them work for a while. You have to find a way to arrange it. If you cannot find a way to do it, you lose. Those who figure out how to hire programmers without interviews, but rather, by actually putting them to work, will win.
Look at the open source projects. How is it they secure the best programmers in the industry? There is no interview process. You simply submit a patch. If it's good, it gets accepted. If not, it gets rejected. If you submit 15 good patches you get commit access. It's a natural and organic process where good programmers self-select themselves into the right "jobs". Business must find a way for these lessons to affect their hiring practices. And whatever you do, DO NOT let HR department act as a filter. They just do not know what they are doing. If you want to hire some janitors, HR is fine. But if you want to hire good creative people, you cannot get them by putting the resumes through a filter run by incompetent people (HR people are never programmers) who merely look for buzzwords, recognizable logos and trademarks and dates on resumes. It just does NOT work.
> That said, I believe the interview process is something > that's going to go away. You simply cannot interview for > good programmers. You have to see them work.
To that point, in my experience the best way to hire good programmers is to know them ahead of time. Really good programmers generally don't need to send out resumes anyway, so if you're relying entirely in resume screening you're already in trouble. So the best way to build an effective team of good programmers is to network as much as possible and then hire those people that you already know are good, or people that the people you know trust, etc. That just doesn't naturally scale very far . . . but then again, neither do most development organizations.
As you say, as long as you have to do an interview, you're going to be taking a risk. The best you can do is raise the bar so that you get fewer false positives, but you generally end up getting more false negatives (i.e. people you rejected but should have hired) that way, it slows hiring down, and you're still going to make some mistakes.
> To that point, in my experience the best way to hire good programmers is to know them ahead of time. [snip] > As you say, as long as you have to do an interview, you're going to be taking a risk.
Alan, both networking and soliciting resumes are strategies businesses do today. These are old.
Maybe I am not being sufficiently clear. I am saying that there is a radically different way of hiring programmers that relies on neither networking nor on screening out resumes. You simply put the programmers to work, or you find them already working somewhere and examine how they work. Now, I don't know the specifics (or maybe I don't want to say what the specifics are). I leave it to the business owners to figure out the best mutually acceptable way to arrange this. Businesses that find the best way (or ways) to arrange these kinds of programmer-at-work examinations/trials are going to come out ahead. Right few or no companies hire programmers like that. Those who do and those who start will have a huge advantage in the market.
Business people need to vastly open their minds. The hiring process as has been traditionally practiced for thousands of years is outdated and insufficient. There is no reason to stick with it after it has been shown not to work time and time again. The only reasons I can see people continue to stick with a hiring process that does not work are closed-mindedness and lack of imagination.
Step outside the box please. There is something big here. Something Henry Ford big.
From what I remember Gerald Weinberg wrote about auditioning for developer jobs a long time ago. Are you proposing something different?
One technique I use is remote pair-programming with the candidate using Webex or similar. You can learn a lot about a developer in 20 to 40 minutes that way. This saves everyone loads of time. I usually have one simple from-scratch problem, one refactoring problem, and one search the docs/Google problem.
This is a service I offer to my clients.
David Vydra www.itarra.com
You simply put the programmers to work, or you > find them already working somewhere and examine how they > work. Now, I don't know the specifics (or maybe I don't > want to say what the specifics are). I leave it to the > business owners to figure out the best mutually acceptable > way to arrange this. Businesses that find the best way > (or ways) to arrange these kinds of programmer-at-work > examinations/trials are going to come out ahead. Right > few or no companies hire programmers like that. Those who > do and those who start will have a huge advantage in the > market.
> Dr. Codd (and others) realized that the data was what > counted, and so devised/discovered a way to build systems > from the data outward. There are also cases where making the data "King" is equally flawed. Mandating that all data be represented in tables is flawed too. No doubt there are domains where it works and works well, but there are others where it does not do so well.
On the backward rowing analogy..I have just re-read Richard Dawkin's "The Selfish Gene", a book that warrants re-reading every few years for its sheer genius and simplicity.
He uses the rowing analogy to describe groups of genes that work together to create evolutionarily successful attributes of living creatures. He imagines a large squad of rowers and a coach who is testing various teams made up from this squad. He points out that after trying a variety of different teams, certain rowers will emerge as good, winning rowers, by having being a part of most of the successful teams, and likewise, some will emerge as bad.
What is key, though, is that the best team is not necessarily made up of all the best rowers. A gene for big nostrils might be successful because the potentially more accute sense of smell might be an evolutionary advantage, but only if twinned with genes which ensure a good olfactory sense. Big eyes might be an obvious strength, too, but the other "good rower" a big nose, might get in the way of the eyes and diminish that advantage.
Without wanting to take the analogy too far, there is a "whole is greater than the sum of the parts" effect, going on, and if some developers are writing code that needs to be scrapped, they might actually be doing some good for the team as a whole. In fact, if there is an actively bad developer who likes to rush in to things, he or she might well be the advance guard of the team and be performing an important function (within reason).
I think it is very hard to measure a team's potential based on the sum total of the individuals' potentials. I think it's accepted that 2 developers can do almost twice as much as 1 developer and from there the added benefit of adding extra people obviously tails off proportionately.
I am not saying that we can't measure or improve teams, just that I think that some backward rowing is inevitable and possibly not as destructive as it might intuitively appear.
One other consideration is the type of team format. In formula-one motor racing, a "team" is a collection of drivers, more or less competing against each other. Your "team" does well by having the largest number of drivers in the top few places. This kind of team could not obviously not tolerate backward rowing.
> The hiring process as has been traditionally practiced for > thousands of years is outdated and insufficient.
I think your rhetoric might be getting ahead of you. Hiring processes as they are practiced today aren't even hundreds of years old. They are almost entirely a 20th century phenomenon. Before that you had small communities with well known individuals, apprenticeships, hereditary job selection, serfdom, slavery, and a wide variety of other institutional practices. Most of which were significantly worse than the interview process of the modern corporation.
Which is not to say that we can't do better. Companies like Canonical who hire based on a proven track record in open source projects are paving a new path forward. But, in a sense this is the same path that many others have already paved. When you look for a job as a designer people look at your portfolio, when you try to get a job as a writer people read things you have written.
The fact that source code has traditionally been utterly closed is part of the problem. It locks hiring managers away from the some of the most valuable information about programmers. Hiring open source developers is not the only way forward, but it certainly is one of the easiest things to do, because you have a public track record of success or failure.
In general I think the solution involves, looking backwards to apprenticeships, sideways to portfolio based hiring in design fields, as well as forwards to creative data-mining of open source code to find potential candidates.
> Maybe I am not being sufficiently clear. I am saying that > there is a radically different way of hiring programmers > that relies on neither networking nor on screening out > resumes. You simply put the programmers to work, or you > find them already working somewhere and examine how they > work. Now, I don't know the specifics (or maybe I don't > want to say what the specifics are). I leave it to the > business owners to figure out the best mutually acceptable > way to arrange this.
I've seen this done where developers are hired as contractors and then offered full-time positions after they have shown their value.
The problem with this approach is that this kind of arrangement is stressful to the employee which, on a side note, is being shown to negatively affect one's health and lifespan above all other factors, environmental or genetic. Many people will choose a permanent position over a temp-to-hire one. So by using this system, you put yourself at a disadvantage with other employers willing to hire outright. In fact I've seen a number of good candidates in this system slip through employers' fingers before an offer could be made.
In other words, you might avoid picking up a bad employee or two but you will also lose access to a number of good employees. I read an article about Google not too long ago talking about how their intensive candidate selection process was making it hard for find experienced candidates. A lot of the candidates would just say "I don't have time for this" and drop out.
> > Dr. Codd (and others) realized that the data was what > > counted, and so devised/discovered a way to build > systems > > from the data outward. > There are also cases where making the data "King" is > equally flawed. Mandating that all data be represented in > tables is flawed too. No doubt there are domains where it > works and works well, but there are others where it does > not do so well.
The relational model is not about tables, that's just an artifact of SQL implementation, currently. There are, as yet niche, RM databases which are column stores. Whatever can be specified in hierarchical/network terms can be built better (more compactly and efficiently) in a relational database. One does need some training to know that.
Dr. Codd proved, since he was out to skewer IMS (aka, xml in today's jargon), that the relational model of data was not only the best, but first, model of data. The hierarchical (xml) and network (sorta kinda, object) databases of the time were passive stores for the code, generally COBOL, with a bit of PL/1 to the side. It's the ignorant younguns who, not having done or studied databases, think that xml (the usual suspect, but OODBMS too) is some brand new magic bullet. It is not. It is a proven dead end.
Those who ignore the past are doomed to repeat it. And so it is in IT; perhaps more than most other "professions". I mean, would any civil engineer now build a bridge in the manner of the Brooklyn one? That way was abandoned, for good reason. But IT folk will hype old wine in new bottles, if they see a way to make a buck; or lack the smarts to understand the math.
The notion that xml is a data model is false. But one needs to have read the history of data and data models (as distinct from specifications). xml is a specification. It has no algebra.
The point of my comment, in context of the OP, is that by returning to the thrilling days of yesteryear where data is subsumed to (by definition) client code, we return to the bad old days of fragile data. Worrying about *coders* is the problem. Coders view data as mud, to be shaped as they see fit. For some kinds of systems (games, for example) this is fine. For multi-user, transaction driven systems, this is the wrong question. For such systems to be robust, the data must have precedence. Clients only draw pictures of the data.
The cure is to seek and employ smart data folk, whenever the system is multi-user, transactional, and has a need for "data persistence". That's not all systems, just the ones that matter.
To the extent that au courant buzzwords like SOA and RIA get managers and the like thinking that they can ignore the database's natural control of the data, and have "intelligent clients" reading and writing where they will when they will; there lies the path of perdition.
> The point of my comment, in context of the OP, is that by > returning to the thrilling days of yesteryear where data > is subsumed to (by definition) client code, we return to > the bad old days of fragile data. Worrying about *coders* > is the problem. Coders view data as mud, to be shaped as > they see fit. For some kinds of systems (games, for > example) this is fine. For multi-user, transaction driven > systems, this is the wrong question. For such systems to > be robust, the data must have precedence. Clients only > draw pictures of the data.
It seems to me that no matter what the subject, your 'point' is always the same: "Relation databases! rah rah rah sis boom bah!"
It just seems to me if SQL was the ultimate solution that resolved everyone's problems, it would surely have won out by the forces of natural selection. But you are basically saying everyone that doesn't worship at the altar of Dr. Codd is stupid and/or ignorant so I guess that explains it. Perhaps we should let you lead the way given your superior education and intellect. Of course each time I've asked you to explain how to solve a specific problem without any of that nasty 'code' you've chosen not to reply. It just seems selfish to not share your god-like wisdom with we the unwashed masses.
Everywhere I've ever worked the database has been king. At the last few jobs I've had I guess they were more of an oligarchy since there were so many of them. Everyone's model is 'the model' so we must support them all. It would be great if applications could just be 'code' and not depend on a specific data model allowing us to avoid a dozen parallel databases (maybe you sell storage) but that would be a mortal sin, I suppose.
Previous Topic
