I think it's useful to point out that, much like with any other written language, there are two collaborative processes at play here--reading for understanding,

I think it's useful to point out that, much like with any other written language, there are two collaborative processes at play here--reading for understanding, and proofreading/editing. As someone who has a lot of 'detail' trouble (I miss a lot of detail in day-to-day life), but who is also a writer, editor and programmer--there's most-certainly a lot of room for improvement. I'll talk about writing for a bit before I bring this back to programming. Many writers have a miserable time proofreading their own work--and it's this way because they already have a strong mental model of what they wrote. When our brain already has a strong model, it can hide a lot of detail from us. It's really just trying to help free our attention for _new_ detail, but in cases like this it causes problems. I suspect you're having trouble finding these minor issues in your own code, and I also suspect you'd find them more readily in code you aren't familiar with (if you're proficient at reading code you didn't write--itself a muscle that must be developed.) My perception is that the biggest component of developing the ability to proofread my own writing was learning to edit other people's writing in a very exacting manner. Other people write differently than you do; when you edit them in an exacting manner, you're strengthening processes for applying arbitrary rules, deciding which arbitrary rules are worth enforcing, and building your own sense of style. When you just do this to yourself, it can take longer for you to develop strong opinions, because you aren't forced to encounter all of the mistakes and tics other writers make. Getting pissed off at all of the annoying shit other writers do will provide both the eye and motivation to attack your own writing with a scalpel. Learning to admire perfect pacing, metaphors, structure and word-choice will slowly prepare you to realize when you fall short. From there, it can help to apply what you've learned to older writing that you're less familiar with; the gap you need to read yourself clearly will shrink. In programming, I think the most succinct analog to this process is refactoring other people's code (note: I didn't say rewrite. Avoid that temptation.) Likewise, it's also really useful to refactor your own code once it has become unfamiliar; you'll both realize how you've grown, and identify some of your own annoying tendencies. When you invest time in activities like this, you're building strong models of where things should be, and how they should be done. You'll cope with common problems, and develop a sense of how code can be written to make those mistakes harder to make in the first place, and easier to spot when you do. I realize I haven't said a word about finding stray semicolons or an errant bracket, yet, but my point is: there are classes of mistake that are much easier to find when you're reading like an editor than when you're reading like a programmer.