Supporting Traits

I’ve set up my resume in a way that is different from most that I have seen. Sure, there’s a job history, mention of those degrees I achieved, and a list of specific technologies, languages and tools that accompanies the CV of every programmer. I tried to keep it all intentionally simple. Before all that, there is a section for Core Skills and Supporting Traits. I’m not 100% sure it’s a good idea, but I think these two categories are crucial. The former is for the key skills and strengths that differentiate you and your ability to contribute. This category is mostly self explanatory so I’m not going to discuss it further here. The latter, supporting traits, is about the aspects of your personality that contribute to your approach. Not the what but the how. These can be an echo of your values or principles, or perhaps It’s your ‘angle’ - how you engage with the work. This article is about some of my traits, how they contribute to what I do, and (in some cases) how they can be non-optimal.


I enjoy building things. From bookcases to fictional worlds to web sites. It’s all a mix of art and science with some practical end. There’s something deeply fulfilling about the act of creation. About transforming your time and energy into something that didn’t exist before. As you can imagine given this elevated language, it’s something that I aspire to put my best into. Taken together, all this has obvious upside - I like to build things and build them well. The downside is less obvious. It can tend toward perfectionism. Knowing where that ‘good enough’ line is can be a challenge at times. There is also the frustration that arises when the work is not done well - whether it’s due to a lack of skill, a lack of time in the schedule, misunderstandings about the problem space, or other factors.


Certain questions and their answers matter more than others. For me, one of those primary questions is ‘does it work?’ Whether it’s a habit, a tool, a strategy, or a relationship, is it working? Is it making things better? I get that defining ‘better’ can be tricky. Here we mean does the good significantly outweigh the bad across multiple dimensions (e.g, time, cost, moral implications, etc). If the answer is ‘no’, then stop wasting time and do something different. If the answer is ‘maybe’, the it needs some additional research and experimentation. Assuming you have the time and inclination for that, otherwise it’s a no. In some ways, this can balance out my trend towards perfectionism. The downside is, ‘does it work’ can be a ruthlessly applied question. And that is not always the best way to approach problems when people are involved.


Take pragmatism and mix in some social interaction and you might end up at candor. I believe in vocalizing. Perhaps not in an unfiltered, radical honesty style. There are too many systems in play in our heads to simply say every stupid or inappropriate thing that comes into our consciousness (this could just be me). Direct, honest and considered communication is what we should engage in. If I think your design is problematic or that your code needs additional work, I’m going to tell you that. I will endeavor to be civil about it but I’m not going to pull punches to spare your feelings. I expect the same treatment. Professionals and adults should be able to take criticism and have their thinking challenged. We’re here to do the work, not to be supportive and compromise, not if that leads to mediocre ideas and execution. We all get things wrong sometimes, that’s only a problem when we wrap our egos around our fallibility and refuse to learn and improve.


Learning is one of those activities that is good for its own sake. An intrinsic good made better by the positive side effect of it being applicable to real world problems. I like to ask questions and dig into ideas, theories, tools, methodologies, frameworks, disciplines and systems. This is usually time well spent, especially if it contributes to my ability to deliver. On the downside, it is often easy for the curious mind to get stuck in research mode. Read, experiment, troubleshoot, repeat. Do that enough and you might find that you’ve lost a good bit of time that should have been dedicated to forward progress.

Given the breadth of technology in the software engineering domain, there will never be a shortage of interesting things to learn. Add in an interest in other domains and you could spend lifetimes on nothing but being curious. I find the best way to manage this is to put together a plan for learning. Prioritize based on interest and applicability. Set aside time for this outside of the time you need to be creating and understand that you won’t and can’t learn everything.

Tactical Pessimism

Things go wrong. No matter how well you think you planned or prepared, reality will go sideways in a manner you don’t expect. Pessimism is a bad way to live your life, but you have to adopt it as a tactical necessity when doing your work. How could this project fail? What am I not seeing? How can this design be more resilient? What are the failure modes for this block of code and can we recover? If something happens to a member of the team, could everyone else pick up the slack? Your process, organization and project need to be tactically sound. Have clear channels of communication and decision making protocols. Keep things simple. Build in redundancies and fallbacks. Brainstorm as if Fortune hates you. Do not rely on unreliable things. Understand how your response to the unexpected can make things worse and avoid doing that. Hope is a sentiment, not a parameter that your team should depend on.

Strategic Realism

Just as pragmatism can balance craftsmanship, strategic realism is the counter for tactical pessimism. Yes, a lot of bad things are possible. But we have limited resources so it’s better to focus on those issues that have the highest combined downside and probability. Things won’t go as well as you expect (or hope if you are prone to that sort of thing) but, if you have planned and executed well, neither will they go as bad as possible (statistically speaking). When making plans, know that your estimates are optimistic and temper them accordingly. Once you’ve done that, temper them again because they are still likely to be wrong. Choose simple solutions that can evolve. Understand that what you deliver may fail. Be objective - can you pivot and recover? Or is that the sunk cost fallacy leading you to throw good money after bad?

Our skills, talents and time are traded for money in our professional lives. But we underestimate how our personalities define our work. Who we are informs our approach to problem solving, collaboration, setbacks, uncertainty, planning, emergencies and contribution. Perhaps in ways that are more important than the other bullets on our resumes. Yet another reason to follow the simplest and most important philosophical imperative - know thyself.

Websites use cookies, this one is no different. Learn more here.