I’m often thinking about what qualities make for a good software developer. One attribute that I think may be important is the capacity to keep the details of a large system in your head. What I mean is, the ability when someone brings up a new feature, to quickly know exactly how it should be implement in the context of the existing system. Or, to be able to recall where the code is in the system that performs some function that needs to be added to some other part of the system. These days, between search tools and the code navigation capabilities built into the better development tools, there are lots of ways to find things in a large body of code, but I think that having a mental map of a system remains valuable. I also think that having this ability may signify the presence other valuable traits that a developer should possess. After all, it’s not fundamentally different from having a good working knowledge of the Java collections framework or the popular Ruby gems or the massive number of PHP string functions.
Two questions for Friday afternoon:
- Am I correct in assuming this is something you should look for in developers?
- What questions would you ask in an interview to find out whether someone possesses this quality?
February 12, 2010 at 5:24 pm
1) Yes 2) Let me know if you figure this one out
Honestly, I think the ability to consider code in this way is rare enough that trying to select developers based on this criteria is too limiting. Developers without this skill can still be productive members of a team. Sure, you may wonder why they don’t see the code the way you do, but you can’t have everything.
February 12, 2010 at 5:39 pm
Actually, I think this is a great skill to look for in project/program managers as well, which is why I like to work with P*Ms with a technical background.
Put them in front of a whiteboard. Draw the system they’ve been working on recently. Throw new features at them, see where they put them.
February 12, 2010 at 5:43 pm
I’m going to have to say “no” to the first part.
Maybe it’s the scope of the projects I’ve worked on, but I’ve met very few people who can keep an entire design in their heads. And some of those that can express a certain reticence for adequate documentation.
And so you end up with the one person that knows the whole design, and limited documentation. Maybe there’s some niche version of extreme/tag-team programming where you can pair a master documentarian with a designer like you describe above, but most of the time you end up with a single point of failure.
February 12, 2010 at 7:37 pm
Whump’s comment reminds me of something that Grady Booch likes to do when doing “archeological digs” on significant software-instensive systems for his Handbook of Software Architecture project. When he meets with a designer of a large system one of the first things he does is to ask the person to draw the system on a piece of paper or a whiteboard. If memory serves the reason he does this is as much to learn about the designer’s perception of the system as much as to learn about the actual system. For instance, what subsystems does the person think of first? What other things does the designer remember after he or she has been drawing for five minutes.
On my own (smallish) team where I am the development manager (but still a developer), I tend to give my developers clear areas of responsibility so that when an issue comes up if I don’t know the answer immediately I can ask the appropriate person. Also, if there’s a new feature or a problem I can delegate it to the person who owns that area of the code.
February 12, 2010 at 7:46 pm
This is why I love reading your blog – always the ego boost 😉
I think it is a good thing to be able to do, but it’s also dangerous. If someone can keep a lot of complexity in their head, then some bad things can happen: * they don’t pass the information on (Jason! mentioned this above) * they get annoyed when people just don’t “get it” like they do * they end up being the “hero” that everyone is forced to turn to in an emergency
As for how to test for it, I think that’s MUCH harder. There was a piece about how world class chess players can remember board positions so much better than new players. Until, that is, they put the pieces randomly (not in valid chess positions). When they did that, they fared the same as the newbies. I worry that any artificial test you could come up with would suffer from the same pitfall.
If you can get access to some piece of code they’ve worked on for a while (go OSS!), then it might be possible to take a file they know about and ask them randomly who wrote which lines.
February 12, 2010 at 8:14 pm
Pretty much everybody remembers things they like! If they remember systems, those systems have spent a lot of time going through their minds or they enjoyed the structure of those systems. While actually remembering is useful, it’s more interesting as a signifier of their relationship to the system.
February 12, 2010 at 9:25 pm
FWIW, my own criteria for hiring developers is actually pretty simple and not very scientific but has worked out pretty well so far:
February 12, 2010 at 9:41 pm
It depends on the project. There’s only so much one developer can keep in his head.
I worked for someone who designed a complex app. One core component of it was a calculation engine (written in Delphi), and maintained by two developers. The president was playing with Lisp and code generation. As a way to learn Lisp, and to try out some of his ideas about code generation, he rewrote the calc engine.
He had designed it and thought he had kept current on the changes made to it. But in rewriting the calc engine in Lisp, he reduced the LOC by about 2/3rds. And discovered that he didn’t know it as well as he thought he did. He also make it significantly faster.
But most importantly, he was now able to model it entirely in his head, and in doing so he discovered a number of bugs that had crept in and that no one had discovered. And the two developers maintaining the code were some of the best we’d ever seen (in terms of raw ability). One of them, however, had the nasty habit of making his code as difficult to understand as possible – he thought that ensured job security.
So maybe the test for a developer is not so much the ability to model the app entirely in his head, but to know when the code has become too complex to do so, and raising a flag or three.
February 12, 2010 at 11:17 pm
These are great comments. I need to post more surveys …
I do think that being able to keep the whole system in your head can have many of the negative effects that people mentioned. Often people who can see the whole picture are very impatient with people who cannot and can potentially make for poor teammates.
Bill, your criteria map pretty closely to my own. The basic thing I want to know is, do you really enjoy this job. If the answer appears to be no, then it’s a definite no from me.
Being able to recruit people at a level where you don’t have to plumb for their technical chops is a luxury, though. I’ve found that for most of the positions I interview for, I need to go deep with the candidates to make sure they can really program.
February 12, 2010 at 11:20 pm
Re: Keeping a complex system in your head. I saw something pretty amazing the other day. I have a friend at IBM who works on the internal supply chain architecture (i.e. the systems we use to sell of our hardware / software / services to customers large and small in > 150 countries around the world). As you can imagine, this is a complex system of systems. He had created a model of the system using a our UML tool and the model had something like several hundred top-level components, hundreds of more nested components, and several thousands of connections between components. He’s been assiduously modeling this thing over the past year using only very simple UML elements (I think just components and component relationships) for the sole purpose of being able to quickly get to a set of facts during a design discussion (as opposed to people arguing about something based on a different version of facts because the system is so big).
The coolest thing about the model is that when you zoom out enough it looks like a circuit board 🙂
So I guess the moral of this story is that as a system gets bigger you can only remember high level abstractions and it’s hard to keep concrete facts in your head without a tool to record and persist facts that can be consulted as the point of truth during discussions.
February 13, 2010 at 12:49 pm
Actually, I would rather like to see developers keep data flow paths in their head. The UML idea about is interesting, but a bit too complex, IMHO. The developer should be able to separate (potentially complex and random) business rules from the important data flow system(s) and encapsulate them in a black box.
An exploded view can show details, while the overall 10000 foot view shows the big picture.
February 13, 2010 at 9:34 pm
I agree with Jason.
I had a longer post, but it got deleted by your system because I left off my email address. 🙁
February 14, 2010 at 2:07 am
I recently finished a round of interviews, my first as a hiring manager, and I found that while many resumes were very descriptive about writing code, very few were descriptive about interacting with a development process.
I’m somewhat less concerned about a developer who can write syntactically valid code than one who recognizes that writing code is not the entire job and shows an aptitude for adapting to languages or frameworks they might not have used much. I want a sense if someone’s thinking about just writing the bare minimum code to make a feature “work” when they provide an estimate, or if they’re thinking about verifying corner and edge case handling, exceptions and other sub-optimal interactions through unit and integration tests.
To gauge where someone’s at as a developer, we ask a question about a hypothetical feature. Except, the feature is one we have in the application, so we know how we’ve solved the issue and what some of the technical limitations and implications are. So, in resolving the problem, we get to see if someone can formulate the problem domain and identify scalability concerns — even recognizing that scalability is a potential issue.
February 15, 2010 at 6:44 am
I used to think “yes” to that, but I’ve come around to something closer to “no”. Obviously it helps to be able to remember a lot of details, but… As I get better at writing code that’s simple and reasonably self-describing, I find that I rely on my memory less and less. It’s just as fast, and usually more accurate, to just look in the code and re-learn those details at need.
I’m sure I remember far less of my code nowadays than I did five years ago, but I’m also sure I’m a far better developer now.
February 15, 2010 at 6:24 pm
I think it is an interesting quality and potentially very useful. Certainly worth looking for in a candidate, in particular the “where should this go” part.
One way of looking for it would be to give the candidate a outline of a large fictional system in some form (flowchart, whiteboard, database schema) and giving them 10 minutes alone with it to look it over.
When you come back, present them with the new feature you want implemented and see how they approach it, where they implement it, and how they justify the decision.
February 22, 2010 at 5:30 am
You might like this: http://www.aaronsw.com/weblog/hiring
All smart people I know have at least one thing in common: good memory. Some of them think they don’t have such good memory, but if you get to know them, you find that they’re just very selective about what they care to remember. If they’re passionate about something, it turns out the whole thing fits in their head, indefinitely.
That’s to say, I think your memory requirement perfectly maps to “Are they smart?”