←back to thread

Cognitive load is what matters

(github.com)
1455 points nromiun | 6 comments | 30 Aug 25 12:58 UTC | HN request time: 0s | source | bottom
Show context
noen ◴[30 Aug 25 14:41 UTC] 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 #
darkstarsys ◴[30 Aug 25 15:45 UTC] No.45075605[source]▶
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.
replies(7): >>45075629 #>>45075972 #>>45076121 #>>45076580 #>>45076720 #>>45077118 #>>45077276 #
makeitdouble ◴[30 Aug 25 16:57 UTC] No.45076121[source]▶
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 ?

replies(1): >>45076164 #
gherkinnn ◴[30 Aug 25 17:02 UTC] No.45076164[source]▶
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.
replies(1): >>45076288 #
makeitdouble ◴[30 Aug 25 17:13 UTC] No.45076288[source]▶
Wouldn't refactoring the if soup into an algorithmically elegant solution what the Einstein does ?
replies(4): >>45076394 #>>45076432 #>>45077259 #>>45077737 #
1. pessimizer ◴[30 Aug 25 17:24 UTC] No.45076394[source]▶
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.)
replies(2): >>45076632 #>>45077834 #
2. n4r9 ◴[30 Aug 25 17:51 UTC] No.45076632[source]▶
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.
replies(1): >>45076672 #
3. pessimizer ◴[30 Aug 25 17:55 UTC] No.45076672[source]▶
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.)
replies(1): >>45090964 #
4. packetlost ◴[30 Aug 25 20:42 UTC] No.45077834[source]▶
Your definition of elegant is definitely different from mine lol
replies(1): >>45078034 #
5. Izkata ◴[30 Aug 25 21:09 UTC] No.45078034[source]▶
Yeah, I'd define elegant as something like "unexpectedly simple and easy to understand", relative to the simple approach to the problem at hand.
6. n4r9 ◴[01 Sep 25 09:12 UTC] No.45090964{3}[source]▶
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.