How to pay more attention to detail as a developer?

Question

Are there any resources for paying more attention to detail as a software developer? (Especially edge cases, or small mistakes in code, details in the problem description, ramifications for certain changes to a large system)

Some thoughts so far:
- Books of some sort?
- Exercise of some sort (e.g. just solving math problems [a professor during undergrad mentioned math teaches attention to detail..although another said assembly language programming teaches detail too...])?
- Some type of method for decomposing problems/thinking to force attention to every detail?
- Some way of noting down details so as not to forget them later

Example of what I mean:

Someone said a good question to ask a prospective developer how many 7's between 0 and 100. I did it quickly and thought of 10, forgetting about 70-76 and 78-79. Basically it's just a lack of attention to detail....

Another example is during a white board coding interview, there was an easy problem and while the initial version was correct, as we kept making it more efficient I kept making more and more small mistakes. Once pointed out it was easy for me to fix them, but it was embarrassing to have them pointed out by the interviewer instead of me finding the issues on my own and fixing them.

Another example is just compiling code. Initially I would write code, go over it once before compiling and catch many errors. Now I miss many more errors and the compiler (or interpreter) finds many more errors than it used to.

Also I noticed that when I first came out of undergrad it was much easier to hang onto tons of detail where as now even the detail that I initially knew I seem to forget more as time goes on. Which is why in addition to paying attention to detail for new problems I could also use resources for keeping track of detail from older problems without having to rely on memory.

Answer 1

1. Slow down. Think before you speak. Practice checking your work, even when it's all in your head. Everybody makes mistakes, especially in a stressful situation like an interview, but you'll make fewer of them if you give yourself time to think. Most people, including interviewers, appreciate a thoughtful answer more than a speedy one.

2. If an interviewer asks you a question with an obvious answer, pause for a moment and consider whether that's the only answer. The 7's question could be answered a number of ways:

   • 20: That's the number of times the digit '7' occurs between 0 and 100.
   • 1: Only one of the numbers between 0 and 100 is 7.
   • 14: If you divide the numbers between 0 and 100 into groups of 7, you get 14 plus a few extra.
   • Infinitely many: I'll let you figure out why.

3. There are plenty of books out there to help you improve your memory but when it comes to code, it's better to spend time writing code that's as clear as possible than to try to memorize all the details. If your code is easy to understand, you don't have to remember all the details. Take that a step further: If you have to remember details about the code in order to understand it, the code should be rewritten until that's no longer necessary.

Answer 2

Learn how to unit test and write testable code.

If you write good unit tests, you will ensure all edge cases are covered. At the very least, writing unit test will force you to think about the code you are writing and help with getting the detail right.

When you have good coverage by unit tests, mistakes made when changing the code (say for performance) will be caught.

The art of unit testing is a good book to get to learn what unit testing is all about.

---

As a side note - it is more important to be correct than fast. If you need to think things for an hour and only then start coding, you are doing well. Simply taking the time to think things through will already help with lots of the edge cases and general class and method design.

Answer 3

It sounds to me like you are letting yourself get distracted and, as Caleb suggests, want to go too fast.

What has helped me from forgetting details is not to hop-skip-and-jump from one part of a bigger problem to another part of it. Finish one part at a time. Write "todo comments" in your code when you think of something that needs to be done elsewhere and isn't related directly to what you are doing now.

I now tend to write "todo's" even for the part I am working on at any time. It helps ensure that I remember to implement whatever crossed my mind and to keep the intrusion on my thought process of that little detail to an absolute minimum.

Answer 4

Just take your time and remember: its not the AMOUNT of code, its the quality of it. keeping that always in the back of your mind will force you to think beforebjust typing code at 100the words per minute.

Answer 5

Like most fields that are detailed in nature it takes practice to get good at the details. Structured practice using a concept called Code Katas can help because it is done away from your main job so it allows for practicing doing detailed thinking away from the pressure of having to finish something fast. And most of the sites that give example Katas to do also emphasize test-driven and/or behavior-driven development.

The seminal "Bowling Game Kata" is a good one to start with.

Here are some references to get started:

• CodeKata by Dave Thomas
• Software Craftmanship - Katas

Answer 6

Attention to details requires:

1. systematic way of browsing through the details
2. some efficient way to regognize which piece is important and which is less important
3. ability to quickly change the details which requires modification

It's always good to remember the fundamental limits of what humans have:

1. people can only remember 7 things in their short-term memory - your details need to flow through these 7 things or you cannot handle large volumes of details
2. Learning how to use your short-term memory for details takes very long time, like 10-20 years and only happens through constant practise
3. Large volumes of details are harmful in the long term, so sufficient holiday time is required where details are not available (given internet's availability of large amounts of details, this is sometimes forgotten)

Answer 7

You're not going to get it right the first time. Go into Creative mode do solve problems. Step away from your code and return as more of a reviewer or editor. Here you'll find more mistakes. There may be more errors found in a code review. It's not that you get sloppy thinking someone else will catch mistakes, it's just going to happen.

Your asking yourself to the the writer and the editor simultaneously. That's impossible to do effectively in both areas.