Ask HN: Can you be a good programmer if you are not details oriented?

Yes, you can become a good programmer if you're not detail-oriented. Not without becoming detail-oriented in the process of becoming a good programmer, however.

An entire system can go down because a single bit which should have the value 0 has the value 1, or vice-versa.

However, everyone has problems with details to some extent. Otherwise, we wouldn't have software defects. A reasonable software development process does not rely on hiring perfect people who take care of every detail and never make a mistake. (By saying which I don't intend to blur the distinction between missing a detail, or getting a details wrong.)

Alan Perlis once wrote the following epigram, #32 out of many:

"Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis."

That's the important thing: getting all the cases right and not missing any.

Yes, experience should bring improvement in all areas. Not uniform improvement, but improvement to some degree. Expect that over time you will gain significantly in some areas.

Another point is that teams are ideally made of people with complimentary skills and mindsets. Try to be the best "you" instead of trying to be as good a "Jim" as your coworker Jim. Bring something to the table that Jim isn't so good at. Even if Jim is awesome, there's probably something that you can do better. Even if it's a "soft" skill like ferreting out hidden requirements or something.

Despite what many people think, programmers spend far more time reading code than writing code. Figure out ways of reading code that work for you, using tools as needed. For example syntax colouring was a great reading productivity improvement. If you write your code in a consistent way then it will also be easier to read, although that doesn't help much reading other people's code. (This is why source formatting is a big deal to some.)

Ultimately you will develop a sense of "code smell". A quick glance at some code will give you an impression of it likely being right or having problems. (For example lots of variables and control flow is more likely to have bugs. Seeing lots of zeroes and ones points to off by one issues.)

Everyone has different ides of what "detail oriented" means, and everyone's experience taints any advice they give on the matter.

For example I've been programming for 20 years, and with my favored languages I don't see "details" of the code at all; I mainly think in indentation shape and huge code block pattern recognition, with the internals of the patterns abstracted away and irrelevant. "Oh, this is just a request handler that reads a file."

By sheer weight of experience I'd classify myself as a pretty "good" programmer, but I don't consider my programming style to be "details oriented" at all.

Summarily I would suggest that a programmer worrying about being "details oriented" is a lot like a fresh lawyer agonizing about the fit of their suit. Stop worrying about it.

My take is that you must learn to pay attention to details to be good at anything. As many others have pointed out, and from my own experience, this is a skill that grows with practice. What level of abstraction you focus on is a separate issue -- details exist at every level. In other words, to design a sound high-level architecture, you must pay attention to details in the architecture.