←back to thread

1457 points nromiun | 3 comments | | HN request time: 0.73s | source
Show context
noen ◴[] No.45075068[source]
This article reminds me of my early days at Microsoft. I spent 8 years in the Developer Division (DevDiv).

Microsoft had three personas for software engineers that were eventually retired for a much more complex persona framework called people in context (the irony in relation to this article isn’t lost on me).

But those original personas still stick with me and have been incredibly valuable in my career to understand and work effectively with other engineers.

Mort - the pragmatic engineer who cares most about the business outcome. If a “pile of if statements” gets the job done quickly and meets the requirements - Mort became a pejorative term at Microsoft unfortunately. VB developers were often Morts, Access developers were often Morts.

Elvis - the rockstar engineer who cares most about doing something new and exciting. Being the first to use the latest framework or technology. Getting visibility and accolades for innovation. The code might be a little unstable - but move fast and break things right? Elvis also cares a lot about the perceived brilliance of their code - 4 layers of abstraction? That must take a genius to understand and Elvis understands it because they wrote it, now everyone will know they are a genius. For many engineers at Microsoft (especially early in career) the assumption was (and still is largely) that Elvis gets promoted because Elvis gets visibility and is always innovating.

Einstein - the engineer who cares about the algorithm. Einstein wants to write the most performant, the most elegant, the most technically correct code possible. Einstein cares more if they are writing “pythonic” code than if the output actually solves the business problem. Einstein will refactor 200 lines of code to add a single new conditional to keep the codebase consistent. Einsteins love love love functional languages.

None of these personas represent a real engineer - every engineer is a mix, and a human with complex motivations and perspectives - but I can usually pin one of these 3 as the primary within a few days of PRs and a single design review.

replies(20): >>45075408 #>>45075546 #>>45075605 #>>45075650 #>>45075660 #>>45075767 #>>45075790 #>>45075860 #>>45075867 #>>45075993 #>>45076014 #>>45076041 #>>45076341 #>>45076370 #>>45076392 #>>45077077 #>>45077131 #>>45077552 #>>45079976 #>>45081167 #
1. jama211 ◴[] No.45077552[source]
I think this is somewhat dangerous, it can lead you to categorise people unfairly and permanently. Also, in my experience this has a critical flaw - the managers love morts in my experience, not Elvises. They don’t care about the technical details, so “fastest and fits the business outcome the most” is ideal.

Also the actual solution is proper team leadership/management. If you have morts, make sure that code quality requirements are a PART of the requirements their code must pass, and they’ll instead deliver decent work slightly slower. Got an elvis? Give more boundaries. Got Einsteins? Redefine the subtasks so they can’t refactor everything and give deadlines both in terms of time but also pragmatism.

Either way, I don’t love this approach, as it removes the complexity from the human condition, complexity which is most important to keep in mind.

replies(1): >>45078791 #
2. zmmmmm ◴[] No.45078791[source]
I agree with you and one of the most important ways is that it bakes in an assumption that people cant grow, learn and change.

Life is all about learning, adapting and changing. Great leaders see the potential growth in people and are up for having hard conversations about how they can improve.

Even if people do have these personality traits as life long attributes, that doesn't define them or prevent them from learning aspects of the others over time.

replies(1): >>45082476 #
3. jama211 ◴[] No.45082476[source]
Well said!