One thing I find surprising is that even among engineers, many people don’t look too deep into the details. It should be noted however, that I’m not talking about “you wrote this code so you should know how to fix it problems”, most if not all developers can fix problems that are self-contained within their code. I speak of the case where the problem lies in someone else’s logic / code / 3rd party integration and you must penetrate that to solve the problem at hand. I believe this segways into a more broad definition of the people who tend to become developers in general, so bear with me. What comes to mind is the debate between “big picture” engineers versus detail-oriented engineers.

First, solely big picture engineers. I say solely as it’s an important distinction. Regardless, this case arises when you know the goal and a rough idea of how to get there, but don’t care about the details enough to systematically arrive at the solution again in the future if you had to. Personality types that tend to exhibit this would tend to be the non-analyst programming types on the myer’s-briggs scale (INFJ, INFP, ENFJ, ENFP, ISTJ, ISFJ, ESTJ, ESFJ). I would also claim that this would be a distinction between those who love programming versus career programmers, but more information could be needed in that regard.

Second, solely detail-oriented engineers. These guys are your bastion of “we know this is going to work, but we need several weeks-months of research to be sure”. For those programming types out there, depth-first search comes to mind. The inability to move forward unless all points of contention are resolved systemically via thought or careful analysis. Personality types that fall into this tend to be the analysts, INTJ, INTP, ENTJ, ENTP. I can only speak for myself, being an INTJ, but I’m pretty sure this comes about by wanting to understand all the details of the technology stack, a love of programming versus career programmers.

Lastly, those engineers who exhibit both traits. Someone lacking a big-picture perspective will lose out on the why while someone lacking a details perspective loses out on the how. Reconciling this dilemma and learning to employ both strategies when needed is, in my opinion, one of the greatest realizations an engineer can make. The key point though, is never to favor one over the other unless the business situation demands it, someone working on mission-critical software should definitely take the time to research while someone performing maintenance should try and keep in mind the cascade effect of changing a single line of code.

The question then becomes, how does one shift along the axis? Sadly that is something I don’t have the answer to, I’ve met quite a few developers and I’ve never seen anyone make a shift from any of the three points to any other of the points. People tend to be pretty rigid in their thinking after all, “if it’s not broken, why fix it?”. The dilemma continues…