What makes a good programmer? A lot of people will tell you it's someone who is lazy; it's not that the lazy are inherently less inept, but rather that a good programmer will try to find the least difficult path for a solution to a problem and go with that, until and unless it proves futile; then they'll find the next least difficult and continue. Others will tell you it's someone who accounts for the most possible problems that may arise with a system and either codes so as to avoid them, or at least notes to managers that they could be an issue in the future. Heck, I'm sure we all have our own rules for what we need to check before we push anything to our source control servers to ensure we didn't break anything, for example, and a good programmer might be someone who has a lot of those rules.
But how can you tell if a person could become a good programmer? Can you tell? I don't mean find a child and determine if they can program. I mean take any ordinary person off the street and ask a couple questions about how they solve problems; if they answer in a certain way and meet certain criteria, they may be a person who could pick up programming and succeed. What questions would you ask, and what criteria would need to be met? Can you train someone to think differently so that the answers to the questions change over time, and they begin to meet the criteria? This would be useful to know for workforce rehabilitation and such, so that's why I think it would be an interesting area of research.
And what does this have to do with Conway's Law, Kyle, you stupid jerk? I'm sure you're asking yourself that very question right now. What I propose is that people who are good at programming are capable of and regularly do store, organize, and access information in their brains the same way that a computer does. In essence, the structure of the person's brain will closely reflect the structure of a well-thought-out computer program and vice versa. I call this Conway's Law of the Mind.
What does a well-thought-out computer program have? This is, of course, entirely subjective, but I think a few attributes would probably be: High cohesion, low coupling, strong modularity, responsive to errors. I don't think anyone would argue that those would constitute a likely-well-written program. There may be other attributes, but those are a good place to start. So how do those map to human personality traits, and how can they be divined from a simple question and answer scenario? Let's go through them.
High cohesion
Cohesion is a fairly simple concept which, loosely stated, goes as, "The responsibilities of a code entity are focused toward one goal." Put even simpler, a piece of code isn't trying to do too many things at once.I would argue that this has a very interesting corollary already in an interview room. When a person is trying to solve a problem, do they say a lot of irrelevant things, little details that make no difference to the actual answer or problem? Are their questions actually related to the problem? These are the types of things I've looked for, and are useful for determining if a candidate is thinking clearly. Conversely, it's easy to confuse the negation of this with incorrectness; I don't believe it's correct to assume that if a person seems a little scatterbrained that they are therefore not going to be a good programmer. The simple reason for this is that they could just be very nervous, as interviews often cause similar feelings to White Coat Syndrome, though that's just my belief, not a factual statement that I researched.
Low coupling
Coupling is the idea that a code entity has dependencies on other code entities, and hence low coupling means the first one doesn't have too many dependencies on other code entities. High coupling means a piece of code depends on numerous other pieces of code, and that can be a really big issue, for the simple reason that code changes to the dependencies will likely cause the initial code to break, or at least potentially not be stable.
In this sense, when interviewing, I like to know how a person gets along with the rest of the team. I will usually have several people from the team interview them. I think this is likely something we've all come to do, but for each person, I have them talk with the previous interviewer in-between sessions so that they can stagger a series of questions that build upon each other. Finally, I have someone toward the end make a change to an earlier requirement. If the person identifies that this will break code from previous interviews, then that's VERY good, and a very good sign that they will be a good programmer, in my book. However, I believe the same negation problem as with high cohesion, where if a person doesn't see it, it doesn't mean they'll be a bad programmer necessarily; it likely could just mean they've had a long and exhausting interview process. We've all had them!
Strong modularity
Modularity the idea that a program is broken up into multiple entities that clearly define their boundaries and separate their responsibilities out cleanly so that they don't have too many dependencies, they each have high cohesion, and they're very, very difficult to break when used in the way they were intended.
This has rather a simple corollary to the interview room: If a person takes the problems given and breaks them up into small steps, clearly elucidates and enumerates the steps required to solve the problem, and executes those steps accurately, probably they will be a good programmer. This is almost the most important rule, I think, frankly. To me, this one almost doesn't have the negation problem that the previous two did. If a person can't clearly think through the steps to solve a problem, while you can say they may be tired or nervous, it will be their job in the hot-seat to kick ass in scenarios just like this, and if they can't cut the mustard, probably they can't be a good programmer. On the other hand, if they admit that they don't know how to solve the problem because they've never encountered anything like it, but they do make an attempt using all the knowledge they have available, I do actually really like that, as long as they clearly explain their steps and execute them the way they say they will. The difference is simple: They don't have to get the right answer, so long as they get AN answer, and have clear, logical steps that are close. In this sense, the solution to the problem is almost irrelevant; in an ideal world, everyone would get every problem right, but that just will never happen, especially since interview questions can and should be different per business. A person who has the right thoughts will be easier to train than one who does not.
Responsive to errors
Being responsive to errors means a program won't just blow up as soon as something unexpected happens. It will not become entirely inoperable, either, hopefully. We see this happen all the time, unfortunately, but this is mostly because a lot of problems can't be solved by the program itself, but require the operating system to get involved (think things like stack overflows, out of memory errors, etc.). Ideally, a program would be able to handle all other errors safely and recover appropriately, e.g. if a person attempts to log in using the wrong password by accident, instead of crashing, the application notifies the user of a typo and lets them attempt to correct it.
I find this one has a rather strange associated interview question: What if the interviewer gets something wrong? I like to see how people react to things they (should) know are wrong. Is the interviewee confident in their knowledge? When something is wrong, can they identify what it is and are they not afraid to speak up? Depending on the company you work for, do they over-react to error? This can be a serious problem in big, political corporations, and is certainly something to look out for: As much as we want a person who is able to get the thought-processes correct and also get the correct answer, so also do we want a person who isn't going to implode if they see an error, but rather someone who is capable of handling those errors in a sane and rational way.
Conclusion
This more or less concludes my post. I really like the idea of Conway's Law of the Mind, and was wondering if you had any interview tips to see if a person's mind is structured well to be or become a programmer.
No comments:
Post a Comment