After reading How to Deal with Me (or any INTJ) the first thing that occurred to me was that a lot of the best software engineers I know show at least some of these characteristics. INTJ is one of the personality archetypes identified by the Meyers-Briggs test. While I don’t think of the MB as predictive of someone’s behavior, I do think of it as valuable insight into people’s system of values.

Chief among these values for an INTJ is the notion that a person has a personal model or view of the world, and they test their model against other people’s ideas. If those other ideas are deemed to be inferior, those ideas are (more or less mercilessly) discarded. While this may seem simplistic or even childish, this is the essence of becoming a better and better software engineer, in my opinion.

It is my opinion that everyone learns software engineering on their own, by dedicating themselves to understanding how it works. Yes, we can take classes, read books, talk with friends and we can certainly learn aspects of it that way. But, sooner or later we have to sit down on our own and figure things out. Chances are we’ve been doing that for as long as we can remember. But, the kind of thinking and skills that result in designing and implementing very large systems is difficult to gain by any means. Practice, making mistakes, seeing the ramifications of our own decisions and introspection are the kind of meta-cognition required to become a better and better software engineer. It takes a lot of time and patient dedication to figure out enough to actually accomplish something useful.

Why does it matter? I suggest to you that this aspect of INTJ is what allows someone to accumulate the vast store of knowledge and creative judgement required to be a successful software engineer. It is the ability to filter out inferior information and accept superior information that enables someone to gain that knowledge over time. It is the ratcheting up of the quality and breadth of knowledge that allows us to gain ground on understanding complex systems and ideas. Accepting inferior information (incorrect, misleading, etc.) is like slipping backwards to us. Of course, everyone probably learns this way to some degree, but I claim that in software engineering at least, this is important to success to such a great degree that people who do not exhibit this behavior are not only at a disadvantage, they are hardly to be found within the ranks of software engineers.

So, why do we care? We don’t at all, unless, we happen to need to communicate with software engineers.

What follows is my opinion on some of the natural communication patterns and thinking used by software engineers. I have tried to look inside myself to expose what I am like and why I am the way I am. It is all just my opinion and my assessment based on my experience. I won’t bother to add “in my opinion” to each and every assertion below. Instead, please just know that this is truly how I feel and I might not be alone in those feelings. But also please know that I do not speak for anyone else, and if this doesn’t jive with how you see things, that is probably as it should be, because you aren’t me. At the same time, some of this might resonate for you, in which case I hope it is helpful.


Everything is open to debate:
Software engineers have a deep desire to do the right thing and be perceived as someone who does the right thing. As such, any poor decision or action in a software project is a liability. Software engineers also know that some kinds of mistakes live forever in a project and cannot be corrected in any cost-effective way. We know that such mistakes can doom a project to failure. And, we know that if the project fails, we will feel harm. It may not be any more than the emotional harm of knowing we failed. But, we don’t like to fail and we sometimes go to extraordinary lengths to avoid failure. Unethical managers sometimes use this innate desire not to fail against an engineer by tricking them into agreeing to an unreasonable project and holding the engineer accountable for its completion. Engineers hate failing. We can be manipulated by this so we learn to be wary of managers who do no clearly and unambiguously communicate expectations and project requirements. As a result of our nature and our fears, we believe that everything is open to debate so that we can minimize the chances of failure. What is more, we feel we are obliged to debate anything we don’t understand or with which we do not agree. We are not ashamed of not knowing. We believe that admitting we do not know is a required first step in acquiring knowledge about anything. So, we are sometimes eager to admit what we do not know so that the learning can begin. We think of debate as the collaborative comparing and contrasting of multiple ideas with both members of the debate benefitting from the result and the only casualty of the debate being the ideas with no merit. So, the debate is for us a critical part of working with others to find the truth. We can’t imagine not debating ideas, especially important ideas. To avoid debate is to step off the path of even caring about the truth or what is real or what matters or anything else important. To us, refusal to debate is equivalent to mindless domination, and it is an indicator that someone’s arguments are so incredibly weak that they would be easy to overcome if they are even mentioned. In other words, someone who isn’t willing to debate is behaving like a controlling moron who is dangerous to the project and should be ostracized. It is unfortunate if that person is our manager. To us, everything is open to debate and we cannot even understand how it could be any other way.

How to talk to an engineer: be open to debate. If there isn’t time, make time. But, record decisions made to prevent talking in circles. Focus on priorities. “Lets debate this closer to the time when we need to make a decision” is a much better response than “Lets not debate this.”

How to be a better engineer: There is a time for some debates that isn’t now. Learn to tell the difference between a debate that must be held and one that simply can be held. Take a breath and try to hear the questions being asked of you.



Our culture is a meritocracy:
Please, please, please don’t try to indoctrinate us with your corporate culture. We feel infected, not improved by it. Please don’t get me wrong, we like your high sounding ideals and your commitment to open communication. We’d just love for you to begin actually living up to them. Engineers have a culture and it isn’t even appropriate for the same culture to exist in the rest of the company. No, I’m not an elitist nor to I believe that engineering is more important to a company’s success than any of its other departments. What I am saying is that when you have group of INTJ-like people they will self-organize their own culture and any attempt to influence it otherwise shows no understanding whatsoever of what we are like. The very last kind of information we’d be willing to accept from someone outside our culture is what our culture should be. We value what we value. We respect what we respect. Our current values are built the same way our knowledge is built: one layer at a time, debate after debate, trial after trial, result after result. By the time you meet us, we aren’t just set in our ways, we are our ways. Your attempt to inculcate a different culture in us will be met with the same contempt reserved for people in power who have no understanding whatsoever about what they control. Our culture is a meritocracy. Truth and knowledge are the primary values and we strive to know more and be better engineers. We value ourselves and each other by what we know and can accomplish. We are not irreverent: we simply judge ideas based on merit. If that means we must challenge the status quo or go against the inevitable group-think of organizations, so be it. In fact, we might even enjoy it. Some engineers develop a dangerous taste for being outspoken. We are ready to be outspoken if needed, buoyed by our belief that we are right. Engineers get a thrill from learning something new, and the more hidden or controversial or widely held was the misconception, the more joy we feel by exposing it and rectifying it. If your culture is also a meritocracy, we are probably happy to participate in it. If, in your culture, your position determines the value of what you say, we probably don’t respect you or your culture very much. However, we’ve probably already learned to hide this from you. Therefore, your attempts to infuse us with your non-meritocracy culture are going to be humored, at best.

How to talk to an engineer: Embrace engineering culture as-is. Recognize and reward merit. Do not allow low-productivity workers to spoil the motivation of highly productive workers by treating them all the same.

How to be a better engineer: Corporations have a culture too, and like it or not you work in it. Try to share that culture with people outside of engineering.


I am Spock’s Brain:
Science officer Spock from Star Trek, The Original Series, is in my opinion, a common archetype personality for software engineers. Well, perhaps a bit less broadly, I think they have these behaviors or intentions in common:
In control of their emotions
Flawlessly logical, even under duress
Ready with information and estimates for any situation
Reliable, honest and faithful to a fault
Willing to follow someone we respect
Deriving personal strength from the laws of the physical universe
Ready to dive into problems of any complexity or scope
Ignoring or burying uncomfortable emotions

It isn’t that we think we are Spock. We think Spock was created in our image, well, maybe except for the ears. Those pointy ears and his other less obvious physical differences were the thin veil that allowed us to believe he was different and unique. One would be less surprised by his character if every INTJ person had pointy ears to make them easy to identify. Instead, we identified with Spock when we watched the show, (or Data, or Seven of Nine, or any of the other intellectually-oriented characters) and we marveled at how popular they were. The same behaviors did not make us popular when we exhibited them as children. In fact, we probably learned early to be smart with smart people and to mirror the intelligence of anyone else. We love the fact that we are smart, but we also know that it can be a liability, so we are careful when and how we show that we are smart. If we are fortunate enough to find ourselves with a group of people who are all the same way, we flower and reveal the depth of our knowledge and wisdom. We thrive in such groups and we may even exhibit wholly different personality traits, such as confidence, compassion and humility. Those traits reveal who we are so if we aren’t willing to be smart around you, we probably aren’t willing to show you those things either. That is a pity, because it is only because of our own fears that we withhold who we are from you; however, we were all children once and we still remember how we were treated when we naively flowered at school and were punished by our “peers”. If you’d like this to be different, please talk to your kids about bullying. Until then, I’m afraid the only social structure that allows us be our best is a safe meritocracy based on knowledge and skill. If we don’t feel safe, we are disabled. No, we are not Spock, and he is not us. But, we so admire the way the character was accepted by the crew and valued for being exactly who he was that it is the quintessential example of what we seek more than anything else: to be loved for what we know, because we value ourselves based on on what we know. If you value us for something else, or fail to value us for that, we may not notice that you value us at all. Of course we are more than the sum of our knowledge, but many of us either don’t care about that or don’t believe it.

How to talk to an engineer: allow us our small illusions. Overlook when we cry or get frustrated and realize that we hold an ideal for our behavior that we cannot sustain or even reach. We are probably not as emotionally mature as you are, but we have feelings whether we show them or not. Try to understand that the the path we have chosen and followed may have left us in a place where we do not trust people who are not like ourselves. You can overcome this by accepting us as we are, or better yet, valuing us for what we are.


How to be a better engineer: You may have to relinquish the idea of getting emotional satisfaction from your job and seek it elsewhere, or get a job that fits better for you, so you can focus on your craft.



We have a right to ask questions:
This is so fundamental to who we are and so central to how we experience the physical universe that it would be easy for us to neglect to even mention it. But, we believe we always have the right to ask questions. We don’t think there is any topic that cannot be questioned nor any good reason to limit questions if they are pertinent. If you shut off our ability to ask questions we view it as a slap in our communicating faces. It is very much like arbitrarily ending a surgery mid-way through and closing regardless of the progress made thus far. We don’t expect the patient to survive, nor our patience with you if you are unwilling to finish a conversation by engaging in questions. Even when we understand very, very well, we are still likely to ask question because it improves our meta-cognition. Something that is true and correct is true and correct from each perspective (we believe) so the more ways in which we consider a truth, the better chance we have of absorbing its essential nature so that in the future we may recognize that truth if it appears enshrouded in different details.

How to talk to an engineer: let us ask questions.

How to be a better engineer: Ask the right questions. This is the smallest set of concise questions that enable you to make progress. More is a luxury.



We Differentiate:
We like to think we can make quick decisions, although in practice we often do not. We like to believe we are aware of many secret indicators about how things work that give us an advantage. Well, perhaps knowing when to create an abstraction and when to code something in-line won’t save us from a saber-toothed tiger’s attack, but we nonetheless feel that our ability to quickly acquire and use information is a survival skill. Lessons we learned growing up probably reinforced within us the belief that an ability to make a quick, correct choice is valuable. The problem is, making a correct choice quickly is, well, harder than making the wrong choice quickly. We know it. We know that to be able to make a correct choice quickly is an especially difficult problem of prioritizing all the information we can consider so that only the most important, pertinent parts are in our minds. We practice by distinguishing similar things. We practice by building a complete prediction of what you are about to say as you are saying it. We can sometimes reach the end of what we predict you will say before you can finish saying it. We’re looking for the difference between our internal model of you and the real you. We practice our differentiation skills with games and by testing ourselves against practically anything that could involve a choice. In our careers we use that skill perhaps hundreds of times each day, as we choose which thread of execution to follow, which variables to examine or as we make choices about the design or implementation of a project. What we do as software engineers is a combination of creativity and choices. What the computer does is automate our choices. We know we cannot make good choices unless we can tell the difference between the alternatives, so we practice differentiation a lot. Doesn’t everybody? If yes, we aren’t surprised. If no, it is just another reason we know we are weird in the eyes of others. When we differentiate enough we believe we understand the pieces we’ve identified, but we only really understand them to a point. If we are wise we try to recognize the limits of our knowledge and where it becomes lore or assumption. We’re comfortable with that dividing line running right through the middle of something we understand, because we know that to believe there isn’t such a dividing line in everything we know is to claim complete knowledge of a thing, and we don’t believe complete knowledge is possible outside of mathematics. We want to know the difference between what we know and everything else. This could take a while…

How to talk to an engineer: Let us use the decision-making processes we have refined over time. Feel free to inject the reality of priorities to focus the conversation, but a good choice is brewed, not hatched.


How to be a better engineer: Accept priorities from those who set them. Let them make choices of what the system should accomplish and you focus on how to accomplish those things.


We Integrate:
While some people never get beyond telling the difference between things, it is only the beginning for us. We need to understand those differences so that we can integrate the parts we value into a cohesive, whole understanding of a project. We believe that whole would be worse or even impossible if we don’t compose it from the right pieces -- the pieces we carefully differentiated and identified. We contemplate what we don’t yet understand and try to reduce its size, complexity and to get it out into the open where we can see it and think about it. We integrate systems from smaller pieces. We use inductive reasoning to understand the behavior of the system at different scales, manners of use and for different input. Most of the software systems we make have too many possible variations of input to test all of them. Yet, we can envision tests that are as effective as testing every possible combination of input (or so we believe). We integrate systems by building them from smaller systems. Layer upon layer, system upon system: the entire internet is one gigantic integrated system created by all of us as we use it. Some of us have a more direct role in its creation because we develop or maintain the web sites and services that comprise it, or the infrastructure that supports them, etc. We see each thing as composed of smaller things until we reach the atomic level for a programmer: the ability of a computer processor to test for equality to zero. Beyond that we leave the realm of software engineering and enter the physical realm of hardware engineering where few software engineers dare to tread. We see no conflict or confusion in liberally mixing differentiation and integration, moment by moment, even though they are opposite processes. To us it is as natural as breathing in and out. So long as each step increases our understanding or adds useful and needed code or resources to the project, we know we are inexorably moving toward our goal of completing the system. We have faith in this process.

How to talk to an engineer: Let us create the way we do best, even if it seems like we are jumping all over the place as we do it. Don’t expect the way we work to make sense to you unless you also write software. Focus on essential requirements, functional specifications and milestones.


How to be a better engineer: Focus on essential requirements and functional specifications so you are sure you know what to make, then work transparently so there are no surprises about project status or issues.


We are the warriors who fight chaos:
We probably don’t talk about it in these terms, but we think of ourselves as people who transform chaos into order. We’re uncomfortable with ambiguity and ignorance. We want it to go away. We like to think the systems we create are perfect, but we know they aren’t. As a result, when our system does something we don’t expect we are disappointed or alarmed. Sure, that means we try to find and fix bugs before you do, but from a broader perspective it shows that we value the order implied by a system that behaves the way it should regardless of the input. So long as the system handles inadequate or inappropriate input gracefully, we consider that to be appropriate. We believe that if our system is perfect, there is no input that could be supplied that would manifest inappropriate behavior. In other words, if there were a hypothetical spirit of Chaos it would be frustrated by our system, finding no way to affect the system or even exist within it. We are no strangers to chaos, because it takes time to root chaos out of a system being created. Make no mistake, we respect how dangerous chaos can be. A large enough data set produced with errors many be irreparable. A large enough system with intrinsic design flaws may require a whole new implementation. There is no fix in some cases besides the complete replacement of the system. When we seem to be unreasonably aggressive in fighting an idea you propose it may be because we see you arguing for what would seem to us to be a back door for chaos. We fear chaos because it wastes our time. Sometimes we work on projects of such scope that more than a tiny amount of chaos can make the project difficult or even impossible to complete in a meaningful timeframe. So we fight chaos at every turn with a nearly zero-tolerance ethic. We believe that meaningful choices reduce chaos so any choice that increases chaos is anathema. We run into problems when there are competing but incompatible approaches that solve the same problems and which each keep chaos at bay; it is here we submit to our weaknesses, such as preferring approaches we already know without considering the full merits of the other approach. But, this is why we debate with each other. We need only find someone to represent the other approach and we believe that through debate the better approach for this situation will emerge. We engage each other transparently to learn together which is the better approach. Chaos fears transparency.

How to talk to an engineer: Help us fight Chaos. Get us the answers and resources we need in time for them to make a difference. Don’t make your own ignorance our problem. Ask us what we need to succeed and then provide it if it is reasonable.

How to be a better engineer: Don’t rush decisions. Deferring a decision can be very, very valuable in a project. Know the difference between something you must know now, and something that can wait because you could work on something else useful instead.



We are children:
Sure, we’re all grown up now with careers and maybe wives, children and plenty of responsibility. But, when we’re happily doing our jobs, we’re connecting again with the child within us. We love to make things. We probably always have. We feel joy when we create things. We feel joy when other people appreciate what we created. Perhaps we make much, much bigger things now. But our joy in their creation is about the same as when we were children building smaller things. We try to draw joy from each small milestone and each feature that works. But, the sad reality is that as projects get larger and larger these feelings may occur less and less frequently. We’re supposed to be adult about this, I suppose. But, we feed upon that joy and it sustains us through the less pleasant parts of the project. Is it any wonder that sometimes we just want to do something small so we can get a sense of accomplishment? Yet, if we build larger and larger projects we perhaps feel surprised when we don’t feel as happy when we do them. There is always something wrong. There is always work that needs to be done. Any goal we reach is immediately replaced by new goals. If we are not careful, the logical conclusion of working on larger and larger projects is misery caused by inadequate joy experiences. No, you cannot give us a treat to make us feel better about this. The joy we receive through accomplishment cannot be sublimated. As a manager I try to use smaller milestones to increase the number of successful accomplishments that are recognized by the organization. It also happens to be easier to manager smaller projects and they have lower risk and higher reliability. Agile programming techniques also involve making projects smaller and easier to manage. But, Agile programming is about efficiency. I am actually writing about feeling satisfied in a software project. The receipt of appreciation and feelings of accomplishment are what balances an organization’s mismanagement, autocracy, and other inadequacies in the eyes of an engineer. When the value proposition dips too far toward dissatisfaction, those organizational inadequacies get promoted into the reason an engineer leaves. That was never it. They just made that their excuse to leave. The essence of it was probably that they didn’t feel appreciated or could not feel joy. Engineers need an environment where they can let go of their adult selves and be creative again. When we were kids there was no cost to making mistakes while creating. Now there is. We know it. But, to be our most creative and effective we have to suspend our fear of making a mistake and the adult, critical voice that comes with it. We need to recapture our sense of childhood to be fully free to create, and we do it every day if we possibly can, because we need some joy every day to sustain us as we battle Chaos. Micro-managemnt brings us back into our adult mind and we are less effective. We work best when we feel like we have enough time to wonder about what we are doing.

How to talk to an engineer: be nice, give praise when good work is done, and withhold praise when you are not satisfied, but don’t shout at us or embarrass us in front of others. We probably can’t deal with it very well, but even if we can, we may be hurt for a while and that can reduce our productivity more than a little as we devote valuable time to understanding our emotions instead of writing code.

How to be a better engineer: Don’t let go of your inner child, ever. Don’t let anyone threaten or harm that inner child. It is that inner child that whispers all of your very best, most creative ideas in your ear. Your inner child speaks with a small voice: you must have a peaceful place in your heart to even hear it.



We are afraid of you:
This probably applies differently to different engineers… but what I mean is that unless you are a software engineer who understands what we do in a project, we fear you if you have power over us. We are afraid of what you might do based on your lack of understanding. We face physical and mathematical realities ever day. We respect them and have learned many creative ways to work with them and to use them to our advantage. But, you don’t know anything about it and to you these realities don’t exist or exist only in a hazy, half-understood way. We can do nothing about these realities. You, on the other hand, seem unaffected by them, and that scares us. To us these things are obvious. One of the ways we recognize each other is by making subtle jokes about these realities to see if someone understands. To ignore them outside the context of a joke is somewhere between jarring and a conversation with a psychopath. Usually more on the jarring side, but don’t underestimate how threatened and frightened we can become when we are under the control of someone who has strayed outside of what we think of as a project’s reality. How we react to these feelings of course varies, but whether we feel them should not be in doubt. You can often tell when an engineer is horrified: they look exasperated or shocked and they disappear into an inward stare. That is a good time to stop and ask what is on their mind. Be prepared for them to utter some unthinkable choice or analogy, because once reality isn’t important, all things are equivalent to all other things, and we feel free to select the most heinous example we can think of to show you just how horrified we are.

How to talk to an engineer: if you see us suddenly look horrified, don’t take it personally. We aren’t actually horrified by you, only the consequences of what you are saying. Just pause and ask us what we think about it. The longer you go on after making an assertion that breaks our reality, the worse the situation will get. Defuse it early by letting us ask a question that clarifies the situation and brings us back to a space where things make sense again to us.

How to be a better engineer: Whenever you notice yourself feeling afraid of someone, remember that they may not even realize they have stepped off the path of reality. Ask a question and give them the benefit of the doubt. Nobody says psychopathic things knowingly unless they really are a psychopath. So, don’t make that your first assumption about their nature. Instead, help them understand what is real, as gently as possible.