One frequent tendency is for new programmers to look at a problem and the existing solution and quickly come up with a new and simpler approach. But it turns out that the elegant new approach (perhaps already discarded) only gets you 90% of the way there. So you can have the old approach, which is close to 100% correct, is implemented, is tested, is working, or you can have the new. The headstrong programmer goes off to try the new approach anyway (perhaps in their spare time). They gradually run into the messiness of the real world, and try to hack special cases to handle the remaining 10% into their elegant framework, and end up with something whose complexity approaches (or exceeds) the orginal. Except now you've got something that only one person understands, is perhaps buggy, is perhaps not fully tested, etc. It's not always bad - writing your own version can be a pleasure, it teaches you, it may be the only way to really get an appreciation for a problem, etc. I've seen this many times - sometimes I do it myself (usually consciously), sometimes I try to stop others from the attempt, sometimes I let it go, etc. The real world is messy! Code complexity often exists for a good reason. And other platitudes.
albert
· 1 month ago
That is spot on. As Joel wrote in his piece on avoiding rewrites, existing code is often complicated because it handles edge cases.
Carter Cole
· 1 month ago
im sad that this is true... i always want to build the new nice and shinny but im learning that others have already looked at the problem and worked out all the kinks...
Scott Wheeler
· 1 month ago
There are a lot of things that I found valuable in working on a large open source project, but really learning to read code is certainly in the top couple.
Though, thinking about it now, it's almost more like dissecting rather than reading: given a large pile of code (say, at least 10k lines) can the interviewee jump into it cold and pinpoint an issue in a reasonable amount of time?
I think being able to pull together the connection points in the architecture is as important as understanding any particular block of code.
albert
· 1 month ago
Great point - I have seen many cases of people digging in the wrong place (to stick with the archeology metaphor).
Carter Cole
· 1 month ago
its crazy some times... these guys had an access application using a SQL backed but they had locked the file as a mde so we couldn't see the code inside the access and they lost the source. they didn't even see that they were working on a great plains database for the first hour even tho i showed them the linked tables then they said they fixed it after running some index checks on SQL but it was still loosing records then i found that a local table that was being written over in the mde because they all were using the same shortcut if they had just kept a copy of the original we could have seen it from the beginning ah it was a blind dig lolz
albert
· 1 month ago
That does sound painful!
CarmenDelessio
· 1 month ago
This perspective can be particularly helpful when hiring and evaluating consultants. I've seen 2 types of consultants. One type is the expert who comes in, looks at what's there, and decides a complete rewrite is in order. The other becomes part of the team and tries to understand what's there. A complete rewrite may be the best course of action, but if the same consultant always recommends it ... beware.
albert
· 1 month ago
Completely agree. In fact, a complete rewrite is almost never the best course of action.
andy idsinga
· 1 month ago
I think reading, debugging and fixing existing code is a really valuable skill. Some of the best coders I've worked with are fearless about jumping into existing code, figuring it out and fixing it with a minimum of complaining. A reading code from an open source code during an interview is a good idea - or even have the candidate come in already prepared to discuss the code! I like to have candidates tell me about a time when they were maintaining code vs writing new code. Then I dig deeper and deeper to see how detailed they can get. The best candidates can stay on topic and talk longer than I care to continue asking more detailed questions.
albert
· 1 month ago
I like that approach of asking questions about a past project and have used it a lot. Interesting twist to do that for a project that involved adding to someone else's code.
andy idsinga
· 1 month ago
Another line of questions that should help detect a seasoned coder: When looking at and analyzing a code base, what do you look for and do to help you understand the code. A seasoned coder will typically include the words "the debug output function" or "log macro" etc in their answer. They'll also say something about inserting debug/log statements into a local build to help understand the run time execution.
albert
· 1 month ago
That might be a good question if you know exactly what to listen for, but I am nervous that it is too easy to fake it in when answering abstract questions compared to actually having to read a concrete piece of code.
andy idsinga
· 1 month ago
Yes - agreed - focusing on some code for the specific interview is a great way to avoid faking it. I suppose the interviewer could have a private list of "important aspects of the code" they are looking for the candidate to bring up during discussion.
All Comments
Though, thinking about it now, it's almost more like dissecting rather than reading: given a large pile of code (say, at least 10k lines) can the interviewee jump into it cold and pinpoint an issue in a reasonable amount of time?
I think being able to pull together the connection points in the architecture is as important as understanding any particular block of code.
A reading code from an open source code during an interview is a good idea - or even have the candidate come in already prepared to discuss the code!
I like to have candidates tell me about a time when they were maintaining code vs writing new code. Then I dig deeper and deeper to see how detailed they can get. The best candidates can stay on topic and talk longer than I care to continue asking more detailed questions.
When looking at and analyzing a code base, what do you look for and do to help you understand the code.
A seasoned coder will typically include the words "the debug output function" or "log macro" etc in their answer. They'll also say something about inserting debug/log statements into a local build to help understand the run time execution.