I just read a post on Coding Balance by Jeff Atwood over at Coding Horror.
Jeff was reading a collection of interviews from some big names in programming.
Here's one paragraph that Jeff pulls out that I also love:
Interviewer: When you write code, does it come out balanced the first time, or does it need a lot of changes?
Interviewee: I do a lot of changing. I like to make an analogy between writing code and sculpting a clay figure. You start with a lump of clay and then you scrape away, add more clay, then scrape away again. And every now and then you decide that a leg doesn't look right, so you tear it off and put a new one on. There's a lot of interaction.
Brilliant. Not because of the artistic description of coding (compares it to sculpting), but because it alludes to what we now call refactoring, even before it was called that.
Jeff goes on to say something even more powerful about internal code styling:
How you place your squigglies won't affect users in the slightest. But attention to internal code layout details implies that you're equally attentive to the external details.
There it is: Attention to internal code layout details implies that you're equally attentive to the external details.
See, attention to detail, I find, isn't something you turn on and off. Good attention over here, poor attention over there. It's more like a personality trait. There are some people who generally place emphasis on the details, and others who simply rush right by them. But either way, people are usually consistent in their bias.
The difference between these people is that those that sweat the small stuff will be much more successful than those that rush or gloss over things. The details are what make or break a product. Anyone can get the "rough parameters" right, but a really great product shows you that the designer thought of exactly the right details to maximize your enjoyment of it. And because attention to detail is more of a consistent trait than a conscious effort only in certain areas, these designers also tend to produce higher quality work - because they likely took as much care on the inside as they did on the outside. Not only that, but they likely served the next poor sap who has to take over the innards of the product because he/she also probably took the care to make sure the code was well designed, documented, consistent and clean.
This is a little known benefit of coding styles or guidelines developed by senior members of devshops (you know, those rules about where you put your squigglies). Many say it's for "consistency" or "clarity". Sure, to some degree, it helps but it's not the killer application of coding styles. The biggest benefit of mandated coding styles is that it teaches the newbies that we sweat the details! It says that you are not allowed just to rush quickly through your coding and slap it together so you can move on to the next neato feature. Sure it takes a little longer to make your code adhere to the coding standard, but this attention to detail on the inside leads to better developers later on - developers that sweat the details.
Comments