Cognitive load is what matters

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.

Is Microsoft so Balkanized that they have a Developer Division, Developer Multiplication, Developer Addition, and Developer Subtraction (where you get transferred to before they fire you)?

I had a lot of fun in DevDiv!

Clearly they were missing Amanda, the engineer who's had to review others' terrible code (and her own) for 20 years, and has learned the hard way to keep it simple. She knows she's writing code mostly for people to read, not computers. Give me a small team of Amandas any day.

And as a manager/CTO, the way to do this is to give the devs time to think about what they're doing, and reward implementation clarity (though it's its own reward for Amandas).

Animal Farm, but with a twist

> three personas for software engineers

The kind of psycho-bullshit that we should stay away from, and wouldn't happen if we respected each other. Coming from Microsoft is not surprising though.

Yeah… it’s like picking three points in an n-dimensional matrix. It is sufficient for creating an illusion of being scientific about it.

The larger a corporation gets, the more npm packages you have to first install before accomplishing any meaningful work.

For my frame of reference, do you think the Myers-Briggs Type Indicator are psycho-bullshit, too? Because I had characterized personas as a very similar "of course it's a generalization" and OP even said themselves "every engineer is a mix" but if you're coming from stance that bucketing people is disrespectful, then your perspective on MBTI would help me digest your stance

I briefly flagged the preceding comment for "psycho-bullshit" before concluding that it was just a really forceful way to say the developer personas were pseudoscientific (of course they are, nobody is claiming otherwise) but I think it's worth calling out that MBTI is also pseudoscientific; it has no real validity, or even test-test reliability.

The best engineers are all three, and can turn up or down these tendencies depending on what's required for the project, business, or personal goals. These should not be fixed in proportion over time, as they are each useful in different circumstances.

I spent time at Microsoft as well, and one of the things I noticed was folks who spent time in different disciplines (e.g. dev, test, pgm) seemed to be especially great at tailoring these qualities to their needs. If you're working on optimizing a compiler, you probably need a bit more Einstein and Mort than Elvis. If you're working on a game engine you may need a different combination.

The quantities of each (or whether these are the correct archetypes) is certainly debatable, but understanding that you need all of them in different proportions over time is important, IMHO.

Perhaps best modeled as a waveform that starts before morning coffee. Each engineer has a vector of spectral magnitudes.

I've seen those kinds of tests described as astrology for business guys. Sounds about right.

Indeed. And besides that, all three are really bad parodies. Mort is the only one where the product actually works, because for him that’s an explicit goal. With the other two, a working product is mere coincidence.

Mort, Elvis, Einstein, Amanda does seem to fit well with my experience. While people are a mix, generally I think its fair that there is a primary focus/mode that fits on career goals.

- Mort wants to climb the business ladder.

- Elvis wants earned social status.

- Einstein wants legacy with unique contributions.

- Amanda just wants group cohesion and minimizing future unpredictability.

That’s super interesting. What was the ideal ratio, back then. Is it still the same now? Or I guess maybe it depends on the specific role and could be different in each. What exactly do you find valuable about thinking in these terms?

Mort is the pragmatist, Einstein is the perfectionist, and Elvis is... let's be honest, Elvis is basically cancer to a project. I guess maybe a small dose of Elvis can help motivate?

I see the ideal as a combination of Mort and Einstein that want to keep it simple enough that it can be delivered (less abstraction, distilled requirements) while ensuring the code is sufficiently correct (not necessarily "elegant" mind you) that maintenance and support won't be a total nightmare.

IMO, seek out Morts and give them long term ownership of the project so they get a little Einstein-y when they realize they need to support that "pile of if statements".

As an aside, I'm finding coding agents to be a bit too much Mort at times (YOLO), when I'd prefer they were more Einstein. I'd rather be the Mort myself to keep it on track.

This is a helpful framing, thank you.

Something was bugging me after an interview with a potential hire, and now I can articulate that they were too much Einstein and not enough Mort for the role.

Both are made up bollocks for idiots to label people. Just write fucking code, solve business problems and go home.

What difference do you see from a Mort ?

If there is no inherent complexity, a Mort will come up with the simplest solution. If it's a complex problem needing trade-offs the Mort will come up with the fastest and most business centric solution.

Or would you see that Amanda refactoring a whole system to keep it simple above all whatever the deadlines and stakes ?

MBTI is absolutely bullshit, it's like one level above horoscopes and astrology, but very similar type of BS. There's also the Gallup crap that many corps were doing to evaluate the strengths and weaknesses of each employee so they could fit them into neat buckets such as "Leader" vs "Follower", as if these aren't skills people develop over time but actual personality traits.

Mort is happy with an if soup. Amanda sees what the if soup ought to do and replaces it with a simple state machine and fixes two bugs along the way.

I would guess that lack of repeatability happens a lot with any self-reporting scheme, but I am sorry that I accidentally picked such a polarizing "people generalization" scheme to use as contrast. Maybe I should have used "introvert versus extrovert" or something

Anyway, their sibling comment told me what I wanted to know, so in that way I'm wasting more of my time contributing to this

Wouldn't refactoring the if soup into an algorithmically elegant solution what the Einstein does ?

Unfortunately for a fast growing industry (think AI, LLM), Mort + Elvis will be much more success then any combination with Einstein. The speed to adapt a new technology into a specific domain outweight your ability to scale for long term (think the oracle vs sybase in server)

Novels are fictional too. So long as they're not taken too literally, archetypes can be helpful mental prompts.

I lean towards Mort for most things, Einstein for the key things and freaking NEVER Elvis.

Reminds me of the three tribes of software programmers. https://josephg.com/blog/3-tribes/amp/

Mort == maker Elvis ==? hacker Einstein == poet

mort = paladin

elvis = thief

einstein = mage

> Elvis is basically cancer to a project. I guess maybe a small dose of Elvis can help motivate?

Sometimes teams are quite stuck in their ways because they don’t have the capacity or desire to explore anything new.

For example, an Elvis would probably introduce containers which would eliminate a class of dependency and runtime environment related issues, alongside allowing CI to become easier and simpler, even though previously using SCP and Jenkins and deploying things into Tomcat mostly worked. Suddenly even the front end components can be containers, as can be testing and development databases, everyone can easily have the correct version locally and so on.

An unchecked Elvis will eventually introduce Kubernetes in the small shop to possibly messy results, though.

Elegant is usually the opposite of maintainable. Reading elegant code is like reading a book of riddles (which is one of the reasons we enjoy it.)

The way to do this is to chew people out when they let their own sources get in the way of doing a good job

As I imagine it, Einstein would no be happy with fixing a couple bugs and making a state machine. Einstein would add a new unit test framework and implement a linear optimizer written with only lambdas to solve the problem and recommend replacing the web server with it as well. This is tongue in cheek but gets the idea across.

You clearly missed the entire message of the entire "three kinds of developers" sort of shit if you think that a fourth type that's perfect is what's missing from it.

Stereotyping people is good.

True, but we shouldn't understate how beneficial elegant solutions can be in the appropriate setting. Sometimes you read code that gives you a new and memorable way to think about a certain kind of problem.

I'll leave it to others to make the argument for why Jungian psychology (and by extension, MBTI) is/isn't bullshit.

But since nobody has mentioned the alternative yet, the framework used by anyone in any scientific capacity is the Big Five: https://en.wikipedia.org/wiki/Big_Five_personality_traits

The link between programming and conscientiousness seems fairly straightforward. To fully translate Mort/Elvis/Einstein into some kind of OCEAN vector would take a little more effort.

I agree we like it. I don't want to have to review it. I'd rather review code where the bugs stick out like blinking yellow lights, even if it runs 10% slower (or 1000% slower, if I'm only running it once.)

They were also missing Steve Jobs. Having had the displeasure to work with Microsoft tools and code for most of my career. Microsoft never in my experience just plain works. I had to fight Microsoft every step of the way to get things to "work". And when it does it invariably breaks in the next major software release.

> - Mort wants to climb the business ladder.

I think the personas have some validity but I don't agree with the primary focus/mode.

For example, I tend to be a mort because what gets me up in the morning is solving problems for the enterprise and seeing that system in action and providing benefit. Bigger and more complex problems are more fun to solve than simpler ones.

Microsoft is/was far more developer friendly than Apple

MFC may have been a steaming pile of doodoo, but at least the tools for developing on the OS were generally free and had decent documentation

Its kind of a common thing to say Myers-Briggs typing is useless because its pseudo-science. I dont think this is supported by the data in the way people think.

For one, many studies of identical twins raised in separate households show they have the same personality type at a much higher rate than chance.

Two, there are incredibly strong correlations in the data. In different surveys of 100k+ people, the highest earning type has twice the salary of the lowest type. This is basically impossible by chance.

The letters (like ENTJ) correlate highly to the variables of Big 5, the personality system used by scientists. Its just that it's bucketed into 16 categories vs being 5 sliding scales.

Scientific studies are looking for variables that can be tracked over time reliably, so Big 5 is a better measure for that.

But for personal or organizational use, the category approach is a feature, not a bug. It is much more help as a mental toolkit than just getting a personality score on each of the 5 categories.

Big 5 correlates to MBTI very closely in any case. With the exception of neuroticism.

Amanda=Cleric

Pretty sure this was not true for the longest time actually. Up to at least the mid 90s, both Apple and Microsoft had their own tools like Visual Basic/C/C++ and MPW on the Mac and none of those tools were free. You could get significant educational discounts or other deals but the tools cost real money.

Later, Xcode (or Project Builder) became pretty much free with the first release of MacOS X. You could buy a Mac and install all the tools to develop software. Very much in the spirit of NeXT. I am sure something similar happened for Microsoft around the same time.

And now of course all the tools both native from vendors + a large selection of additional third party tools are basiclly free for all major platforms.

(Disregarding things like 'app store fees' or 'developer accounts' which exists for both Apple and Microsoft but are not 100% required to build stuff.)

Your comment made me think Mort represents efficiency, Einstein represents quality, and Elvis represents risk. The ideal combination is difficult, and it changes over time. If anyone knew what the ideal combination was, companies would never fail. Risk can get something started, and lack of it can eventually kill software. In fact, I would argue the vast majority of software we’ve seen so far dies an eventual death due in part to its inability to take risk and change and adapt - it might be not enough Elvis in the long term. Too much risk can kill something before it takes off and can undermine the ability to ship and to ship quality. Generally speaking my gut instinct was to (perhaps like you) align with and defend Morts; the business objective is the only thing that matters and pays the bills, and there is certainly a class of Morts that doesn’t write spaghetti code, and cares about quality and tries new things, but prioritizes work toward the customer and not code wonkery. Anyway… this is too probably abstract to be very useful and I made it worse and more abstract, but it’s fun to hypothesize!

Personas are a great tool. IMO - By the time you arrived these had transformed into bad shorthand. (I say this having been in Devdiv through those years.)

Elvis is not a persona - it is an inside baseball argument to management. It suffered a form of Goodhart’s law … it is a useful tool so people phrase their arguments in that form to win a biz fight and then the tool degrades.

Alan Cooper, who created VB advocated personas. When used well they are great.

The most important insight is your own PoV may be flawed. The way a scientist provides value via software is different than how a firmware developer provides value.

https://www.amazon.com/Inmates-Are-Running-Asylum/dp/0672316...

Mort: Someone who lacks sense of life, looks dumbfounded, and has only a limited ability to learn and understand. (urban slang)

Elvis: A famous rock star

Enstein: A famous physicist

Amanda: ???

Mort, Elvis, Enstein are referencing things I've heard of before. What is Amanda referencing? is there some famous person named Amanda? Is it slang I'm unaware of?

If personas in this context resonate with you, I highly recommend - even if only remotely related - to read Rich Gold’s The Plenitude.

https://mitpress.mit.edu/9780262543798/the-plenitude/

Okay, it's psycho bullshit. How would you organize and sort people instead?

Everything is made up. How do you organize people into being able to solve problems?

Exactly the expectation value for "analysis of types of developers done by people who really don't care about people"

"so, there's 3 boxes. no more, no less. why? i have a gut feeling. axis? on a case by case basis. am i willing to put my money where my mouth is? heallnaw!"

The Amanda solution is the intuitively obvious to even the casual reader. The Einstein solution is quite succinct but takes years to understand all the nuance in the one liner. :-)

I appreciate both for different reasons.

> Amanda

Am I missing a reference? If not, may I suggest “Ada”?

https://en.wikipedia.org/wiki/Ada_Lovelace

Or even better, “Grace”. Seems to fit your description better.

https://en.wikipedia.org/wiki/Grace_Hopper

https://www.youtube.com/watch?v=gYqF6-h9Cvg

Amanda try to be like.

I vote for Amanda. Really, there is no substitute for seeing something easy to understand.

I have been most of my career working with C++. You all may know C++ can be as complex as you want and even more clever.

Unless I really need it, and this is very few times, I always ask myself: will this code be easy to understand for others? And I avoid the clever way.

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.

Precisely. Also people underestimate the power of mort code. The world runs on it, and besides, at the end of the day unless you are an executive or own significant stock in the company, making decisions about speed/outcome vs tech debt actually isn’t your job IMO. Give your opinions and advice but at the end of the day build what they ask you to in the manner they’re happy for you to build it - if they demand speed over quality that’s on them.

And you can improve everything with a system. A team of morts forced into a framework where testers/qa/code review find and make them fix the problems along the way before the product is shipped is an incredibly powerful thing to behold.

Mort is the only one who does their job from the perspective of the business owner.

Who’s the bard? I feel like I’m more of a bard

I thought the Microsoft developer persona thing was cute. I didn't think anybody was claiming it was science!

Amanda is clearly the most beloved of those four. ;)

Einstein would write a new state-machine library with SIMD optimization for the purpose, and refactor any logic into it that could possibly be contorted into a state machine.

I don't really like the axes Mort/Elvis/Einstein are on, they all seem like obviously pathological examples.

I think if I were to make three strawmen like this I would instead talk about them as maximizing utility, maintainability, and effectiveness. Utility because the "most business value" option doesn't always make the software more useful to people. (And I will tend to prioritize making the software better over making it better for the business.) Maintainability because the thing that solves the use case today might cause serious issues that makes the code not fit for purpose some time in the future. Effectiveness because the basket of if statements might be perfect in terms of solving the business problem as stated, but it might be dramatically slower or subtly incorrect relative to some other algorithm.

Mort is described as someone who prioritizes present business value with no regard to maintainability or usefulness.

Elvis is described as someone who prioritizes shiny things, he's totally a pejorative.

Einstein is described as someone who just wants fancy algorithms with no regard for maintainability or fitness to the task at hand. Unlike Elvis I think this one has some value, but I think it's a bit more interesting to talk about someone who is looking at the business value and putting in the extra effort to make the perfectly correct/performant/maintainable solution for the use case, rather than going with the easiest thing that works. It's still possible to overdo, but I think it makes the archetype more useful to steelman the perspective. Amanda sounds a bit more like this, but I think she might work better without the other three but with some better archetypes.

Your definition of elegant is definitely different from mine lol

Yeah, I'd define elegant as something like "unexpectedly simple and easy to understand", relative to the simple approach to the problem at hand.

I think implementing stuff correctly (Einstein) is sometimes more important than doing what you're told to do (Mort) - requirements don't always represent business interests.

> How do you organize people into being able to solve problems?

By not putting reductionist labels on them.

Sounds me like what you see in the Amanda type is "balance", landing as Mort mixed with an Einstein.

To quote OP: "None of these personas represent a real engineer - every engineer is a mix, and a human with complex motivations and perspectives"

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.

You can pick any set of axis you feel like and get similar results. “Do you like X? Wow you are an X person!”. So yeah, technically better than horoscopes, more like a “warm” reading where you tell a person what they told you earlier. But it’s entirely unclear why these axis are the right ones over a million other possible ones, if these are particularly stable categories in time and context, or if the harm of encouraging people to box themselves or others into specific stereotypes has any possible benefit to outweigh the obvious harms of simplifying stereotypes.

Mort might mean short-term efficiency, but those solutions are where technical debt and unmaintainable organically-grown complexity come from. That has its time and place, but it must be balanced to not doom anything but short-lived projects.

It's good questions. Here's why this axis is the right one in my opinion:

1) As I mentioned, it has a lot of statistically significant correlations, including to all the variables of the Big 5. Example: Surveys show that % of the overall population that is each type (like INFJ) is very consistent across time and populations.

2) Beyond that, youre right, there are a lot of personality systems with pros and cons. But Myers-Briggs has by far the must supporting materials, tools, ease of use, and so on. I think its the quickest to make useful to the average person.

3) I've found it really helpful as a lens for self analysis in my own life.

Can you share what was the new framework? At least some of the details, it sound interesting what was the new understand

The problem is that "work smart not hard" for software devs is counterintuitive because using your brain is the hard work. Einstein works too hard and creates code that's hard to reason about, Most doesn't work hard enough and creates code that's hard to reason about.

The originating example for an Amanda is someone who used her brain to recognize that the existing code was clumsily modeling a state machine and clarified the code by reframing it in terms of well-known vocabulary. It's technically an abstraction but because every dev is taught in advance how they work it's see-through and reduces cognitive load even when you must peel back the abstraction to make changes.

I kinda see the original proposition as similar to a RGB framework. The same way we mix RGB to have a whole spectrum of colors, I assume we can mix Mort, Einstein and Elvis to get whole spectrums of engineers profiles.

There will be people looking at pure Green and pure Blue and ask for an Emerald color to get RGBE instead, but that's not how the RGB framework works. And I can't get rid of the feeling that Amanda is that Emerald color people are clamoring for.

I also kinda get why Microsoft got rid of the system for something more abstract.

> An unchecked Elvis will eventually introduce Kubernetes in the small shop to possibly messy results, though.

Elvis and Einstein joined powers to create 14 new javascript package managers over a handful of years while Mort tore his hair out.

I'd love one of those old facebook quizzes like "take this quizz to figure out which friends character you are", but for figuring out whether you are a Mort, an Elvis or an Einstein

She is not familiar because she is referencing things that are rare. You haven't seen an "Amanda" because she is rare. Just like common sense.

It’s more important if your goal is an _actually good product_. Whether that’s the goal of the stakeholders is quite honestly up to them.

Well said!

The only place I’ve seen technical debt and organic complexity come from in real life is from over-engineering (Einsteins over-engineer the code, and Elvises bring in too many dependencies) and, more importantly, from changing requirements (customers & PMs & management). The changing requirements is the bigger culprit most of the time, and that doesn’t reflect directly on programmers or programmer personalities. I’ve never seen efficiency arguments make the code unwieldy. If anything, the problem is that real life Morts sometimes under-engineer, and it takes some of the other types to build up a bit. I’ve seen over-engineering far more often than under-engineering. Anyway, Mort only means short-term efficiency if you make assumptions. It didn’t in the top comment, and it doesn’t have to, you can just as easily assume efficiency is long term and includes efficiency of maintainable code and efficiency of business processes. If you care about the business outcome, why would you jump to the conclusion that it’s short term thinking?

Elvii often face a lot of criticism when Big New Ideas are overkill or they don’t work. They often get forgotten when the idea becomes standard issue and Mortified. The most pragmatic ideas today were Highly Risky and Unproved 10 years ago.

I don't see how that helps if the number of people you need to solve a problem exceeds the ability of a single human to know all of the people involved.

I guess it depends what mean by "elegant". For me, an elegant solution makes it obvious that certain classes of bugs will not be present.

For example, suppose you have an application that connects to 17 queues and processes a different type of request from each. You could do this in lots of lines as follows:

  var processors = new Processor[18];
  processors[0] = client.CreateProcessor("FooQueue") { Handler = GetHandler("FooRequest") };
  log.Write("Connected to Foo Queue");
  ...
  processors[17] = client.CreateProcessor("BarQueue") { Handler = GetHandler("BarRequest") };
  log.Write("Connected to Bar Queue");

Or you could do this:

  var queues = new List<string> { "Foo", ... , "Bar" };
  var processors = queues.Select(q => client.CreateProcessor(q + "Queue") { Handler = GetHandler(q  + "Request") };

The former - despite being "warts and all" - is more prone to bugs getting missed in development and review.