4 ms·
You must pay attention to the details if you will ever become a good programmer (not necessarily the same as being detail-oriented). This may mean different th
by paxunix 12y ago
You must pay attention to the details if you will ever become a good programmer (not necessarily the same as being detail-oriented). This may mean different things depending on context: designing a system? The implementation details aren't very relevant yet. Building the system? Those details become very important.
I've been programming for over 20 years and I've come to think the two most important factors contributing to a "good" programmer are communication skill and attention to detail (both of which can be learned, though some seem innately good at both at the outset).
For example: let's say you are reviewing someone's code. You notice they've missed some null checks, haven't properly handled exceptions or ignore some failure cases, aren't doing object comparisons properly, etc. They insist the code works fine (if you're putting up untested code for review, you should be beaten), but those little things now consume the reviewer's valuable time and head-space when they should have been sorted out before the review was ever posted. As the reviewer, you get caught up in an endless stream of niggling little details and nitpicking, rather than focussing on the logic and design and structure of the code. Meanwhile, the programmer feels very productive ("hey, I've just churned out a whole new module") and moved on to the next task, essentially relying on everyone else to finish his job.
Missing some things like this now and then doesn't make one a bad programmer, but consistently neglecting/forgetting them implies a lack of attention to detail and makes me wonder what else they're missing that I'm just not seeing (slog through several hundred lines in a code review and you will inevitably start missing things (http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/ http://www.ibm.com/developerworks/rational/library/11-proven... )). It also creates a lot of busy-work churn for the whole team that has to deal with that code. They may seem to be very productive, but they're actually dragging down the overall productivity of the team because everyone else has to point out the little things that were missed, as well as most likely re-review the code once all the small-detail changes have been made.
EDIT: fixed link