Software Engineering Typologies

Introduction

After nearly 20 years in Software Engineering working in 6 industries, several countries and having had the chance to work or interact with hundreds of engineers, time has come for me to switch tracks.

Before moving on, I thought I’d capture few things I’ve discovered and learned over time (in the lines of things-I-wish-I-knew-20-years-ago). This one touches on Software Engineers and their different typologies. (If you expect the classical engineer type classifications of backend vs frontend, mobile vs data engineering, etc. — you landed on the wrong post, as this is more about personalities and traits rather than grouping by skills or job families)

When reflecting on myself or assessing other engineers over time, I’ve learned to value few dimensions or traits that I found useful to consider:

• Getting Things Done — it sounds like a boolean property but it really is a whole spectrum of traits coming together to plot one’s ability on a scale influenced heavily by the current context. This one stuck with me ever since I first came across stackoverflow’s Joel Spolsky blog and later book “Smart and Gets Things Done”
• Ability to learn and unlearn — in our line of work undoubtedly one of the key tenets, yet I am stressing the duality and the importance of both sides of the coin.
• Pragmatism vs Perfectionism — it is not a fixed trait and the best of us are those able to swiftly navigate the scale as the circumstances require.

I’ll open a bigger bracket on this — as I saw at times these extremes clashing. In our fast paced world, VUCA if you will, my personal rule of thumb gives more credit to the side that says: “the best is the enemy of the good” or the supporters of Pareto’s principle “roughly 80% of the effects come from 20% of the causes”.

However, let’s not kid ourselves, if you need to crunch through some exhaustive application integrations or convoluted yet decreted must-have business logic components — 20% won’t get you through to the other side.

So now, why do you even need perfectionism — because the more pragmatic you get, the more compromises you make and that impacts quality among other things. Perfectionists in the software world, are passionate or obsessed with quality (inner or external). There is a line of theories advocating for “building quality in” and KPIs measuring First Time Right which have something to it.

There are certainly others worth noticing, of a more generic nature such as: communication skills, time management, being a team player, etc, yet I’ll save the rumble and move on to my incomplete, fully-biased, very personal list of:

Typologies

The Good

1. Backlog burner (ISTP)- these are the guys and girls you want most of in your team, in most cases. The proverbial introverts, the geeky kinds — the ones that don’t care about the politics and try hard to attend all meetings (though fail at times), yet take pleasure in getting things done. They are by definition pragmatic and will move mountains if they have to.
2. Enthusiast (ENFP)- keeping themselves and those around them engaged and motivated is a superpower in itself. Staying always positive, exuberant on every test pass and production push while supportive and always seeing the full half of the glass when things go south. Growth mindset at its best.
3. Catalyst - Performance amplifier for teams (ESTP)- you surely had or are one of those loving to build reusable components or scripts or something that everyone loves, adopts and uses. There is a whole job family for this as well (Platform Engineering), but I am here talking about those working in teams, doing it on the side with no mandate, yet having typically huge impact on everyone’s productivity and happiness.
4. Scout (ISTP)-looking ahead for technologies and techniques - I mentioned learning as a key trait, so this is the hat that every engineer must wear from time to time. Yet, I must acknowledge and praise those that make it a mission to stay informed, be assertive and don’t take everything that shines as gold. They are very deliberate and careful on adopting new technologies or techniques, will run it through their pet project or create a PoC before even bringing it up and come up with Cons next to all the Pros.
5. Swiss Army Knife (ESTJ)- threading the realm of superheroes - these are all those shifting gears, technologies and stacks within seconds with a feather-like ease. They are camouflaged under a regular engineering title, yet they can do anything coming their way - automation, testing, scripting, frontend, backend, you name it. Now, why don’t we just all train to be one, why does the world need anything else? In my experience, you want to make sure they always have something challenging to crack at or else they’ll stall or leave and off are the superpowers.
6. Cameleon (ESTJ) —the last of our heroes and the most versatile. Someone that can wear different hats at different times, be obsessive about quality if he’s tinkering with medical applications but stand a whole stack of services from dusk till dawn to back a crazy idea with a prototype. Also someone that can burn backlogs in countless sprints till the spark ignites and goes off building the perfect missing platform library that now everyone loves and praises.

The list is longer, but didn’t make it to the best of, things like: The Genius, The Refactorer or The Debugger. I also saved some types of connected types that are worth a separate post.

The Bad

I’ll save some ink and keep the dark side of software engineering shorter:

1. Complainer (INTP)- No matter what, no matter when, he’s got a complaint. Tendentially it’s about people, but it might as well be the weather, the stupid CI server or the intranet (these days the VPN as well).
2. Tech Magnet (INFP)- Remember the Scout? Well, that’s kind of the same just that it goes off researching technologies and gets attracted of every single new shiny library, tool or framework. It tendentially just stays theoretical till it tries to force fit it everywhere, till the next one comes.
3. The Hammer (ISTJ) -when everything looks like a nail. Conservative and resistant to change, always having the proof of why a well established technology even out of support is the best options. They are in the long tail of the Laggards on the Innovation Adoption Cycle.
4. Overthinker (ISTJ) - This is a dangerous slippery slope as anyone can go down this one. Someone said: “Simplicity is the ultimate sophistication”- and software engineering is at times, the ground where this is hardest get right. That’s why we have the KISS principle called out now and again in the software literature. Overcomplicating solutions or adding even more complexity to already complex systems is many times easier - that’s why we all need to solemnly pledge to fight the urge.

I’ll intentionally keep the bad list smaller as a testimony of belief in the greater good in the larger engineering community.

There is no Ugly

Conclusion

Over the years I found myself wearing one or the other hat, sometimes good sometimes less, as far as I could reflect or read from the feedback I got. There is no one best trait to favour or one type to aim for. There are few to avoid though.

If you are an aspiring or fresh engineer, be aware of the traits and the types, maybe pick a favorite and work your way towards it.

For those and all the rest, create your own list, be honest and self-reflective, strive to improve but also give feedback to those around you and help them brush up as well.

But most importantly: Keep on learning and keep on building!

I mentioned Joel Spolsky’s blog, the creator of stackoverflow and Trello.

The four letter acronyms (ISTP) are a shot at mapping the typologies to the Myers-Briggs types.

I have also came across and enjoyed Neil’s list — most certainly a more complete catalogue.

Photo by Annie Spratt on Unsplash