How can I improve my attention and make fewer mistakes?

Question

Throughout my life, I have always had some issues with what I, my peers and my teachers referred to colloquially as "paying attention". By this I mean a very specific ability to not make mistakes. Some very good examples are:

• A mathematically competent adult getting a calculus question wrong because of a simple arithmetic mistake, such as 5+3=15.
• A well-prepared student getting a multiple choice question wrong because it was asking "which of the above are not true", but he mistakenly selected the ones that are true.
• A skilled roboticist damaging an expensive circuit because he accidentally wired the components incorrectly.
• Mixing up two terms which refer to different things, despite understanding very well the concept that either term refers to.
• Typos and simple grammar errors.

Note that I do not mean attention in the sense of being able to concentrate on and pay attention to a topic. I am specifically talking about the ability to not make mistakes (where mistakes are simple errors, which you know are wrong but do not notice at the time - not errors you committed because you lacked understanding of a key concept or because you didn't know any better).

While this "attention" obviously influences ability to do well on tests, it also affects my day-to-day work in 2 key ways:

1. When performing an involved experiment, things such as mixing up samples, accidentally skipping a step of the procedure, forgetting to clearly label the samples and so on may ruin the whole experiment - either because the experiment no longer works when that simple mistake is made, or because the mistake has made the results uninterpretable.
2. When working with a tool that does not provide much automated error checking, I can end up producing data or programs that are incorrect due to some mistakes I made. It may take me a very long time to detect these bugs - and until I do, all conclusions I draw from my results are unreliable (and I am not aware of this!). Even after I discover the bug, the work done up to that point is still wasted.

So, my question: Is "attention" in this sense (ability to make few mistakes) a skill, or innate? Is there any way for me to improve this skill? Can it be trained, or is it an invariant quality of a person that they can only accept and accommodate?

---

Note that, for the "making mistakes when doing something complicated" problem, there exist the solutions of

• "break it down into simpler chunks which you are less likely to make mistakes with"
• "restructure your complicated activity such that mistakes are rendered obvious".

I'm not very interested in these sorts of solutions, because restructuring the task is not always possible, feasible and efficient. Some things simply cannot be made any less complicated than they are.

Also, while I welcome discussions of the physiology of this problem, it is very unlikely that my problem is ADD or a similar disorder. As the saying goes, to err is human - but some humans err more than others, and I am interested in understanding why (and more precisely, what strategies are available to make oneself err less).

Answer 1

I was unfortunate enough to grow up in an academic upbringing (almost from pre-school up until university) that is a) purely competitive and b) relies solely on multiple-choice exams.

We were drilled for years to try and avoid such small mistakes, since they prove to be extremely costly when millions of people take the same test.

My only advice to you is to make a habit of checking your work, with a clear set of mind. I know it's not always possible (usually due to lack of time) but it's a very important skill to keep in mind that such mistakes do happen from time to time, and having some time at the end of a test/experiment entirely dedicated to checking your work is "money".

To my knowledge there is no fail-safe way to avoid such mistakes. Humans aren't really designed (from an evolutionary point of view) to stay focused for extended periods of time, especially when implicit calculations occur. Which brings me to a "corollary" advice; make a habit of writing out all your thoughts/calculations explicitly. The benefit with that is that it allows you to immediately spot irregularities in your work when you go back and check your work later prior to the point-of-no-return (i.e. you hand in your exam, or turn on the electricity switch or whatever).

Answer 2

My experience comes from theoretical physics and I do not know how well that can apply to you but I will anyway post my experience.

When dealing with calculations, one should evolve certain intuition for what can be right. For example, if you are calculating temperature of a gas in a problem from thermodynamics and you get a value of -20 kelvin, you must have done something wrong. Most of the time, it will be more difficult to know if one did an error in the calculation but one can still check if a given calculation scales with given parameters in an expected way or not. Such an approach is usually much faster than going through the whole calculation step by step (you just need to look at the result). On the other hand, it requires a good understanding of the problem you are solving (so that you know what you should expect) and some practice. Moreover, it can be used to find incorrect trends only; if you overlook a prefactor of two or three, you won't find it in this way.

This approach also works with any numerical problems. By varying parameters of the calculation, you can check if you get the expected behaviour. The time requirements there might be worse, though; If you have a complicated calculation, running it several times with different parameters can be very time consuming.

Answer 3

I agree with the earlier answer, but I disagree with the questioner's non-acceptance of "restructuring problems".

There are two main classes of checks I employ: plausibility checks mentioned above (which give you a high-level sanity check of what you could hope to expect) and self-imposing structural constraints which limit your ability to make undetected mistakes.

You talk about tools with error checking. In programming, there are many ways of organising code in such a way that will make it difficult to fit together parts which should not go together. It is similar to putting in a special plug that will go only into the correct corresponding socket, and thus will avoid a short-circuit.

In programming, apart from using strongly typed languages, for internal software, I am so paranoid that I litter my code with "assert" statements for any nontrivial assumption I make. This catches many bugs in the making. There are many tricks of that kind. When organising activities, developing a check list and following it, ideally with some kind of physical "cursor", can avoid mistakes. Generally, externalising your activity status can help, such as marking all terms you have operated on in a calculation.

For highly critical processes, I usually create a parallel checking line, such as an independent line of computation or estimate. I'll give a more detailed concrete example of such a parallel check:

I once had to use a formula from literature to estimate a quantity known from literature, but using my own experimental data. I didn't trust it, and did the recomputation from scratch, which took me two weeks of intense work. It paid off, though, as my computation resulted in a factor 2 discrepancy from the original publication. Then I plugged in my experimental data and everything fit beautifully with what was known till then. Had I tried the experimental data first, I probably would have wasted weeks on trying to uncover where the wrong factor 2 would have come from.

Note that I intentionally did the theoretical computation first, without knowing that my experimental data would have given the factor 2 wrong value with the literature formula. This, to avoid temptation to fine tune the factor post hoc. However, in all likelihood, I would probably not have done that, either, and rather would have dropped the whole line of investigation as inconclusive.

This checking procedure was very time-consuming, but the payoff was that it prevented sloppy work and erroneously dropping the hard-won experimental results as useless. I detest debugging after the fact, and generally find it easier to submit to a rigorous discipline to build up my results systematically. I specifically mention this strategy of mine, because the popular "debugging after every substep" (aka "test-driven design") may violate the questioner's constraints about how problems can be structured.