I just this week vibe-coded a personal knowledge management app that reads all my org-mode and logseq files and answers questions, and can update them, with WebSpeech voice input. Now it's my todo manager, grocery list, "what do I need to do today?", "when did I get the leaves done the last few years?" and so on, even on mobile (bye bye Android-Emacs). It's just a basic chatbot with a few tools and access to my files, 100% customized for my personal needs, and it's great.
Cool! It would benefit from better physics though, maybe supersampling the position in time especially when moving fast. Each ball can't push to its edge fully, for instance.
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.
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.
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.
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.
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).
Amanda is just the light side of Mort, Elvis or Einstein, since keeping things simple and reviewable can mean staying business-oriented, using the right technology or using an existing tool with deep knowledge.
We would all like our coworkers to never make bad decisions. :)
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 ?
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.
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.
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.
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 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.
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 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.)
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.
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?
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.
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.)
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.
I prefer Claude Code (the `claude` cmd line version, with Sonnet 4) because it's more like an actual pair-programming session. It uses my claude acct rather than costing extra per token. It also hooks into all my MCP tools (shell (restricted), filesystem, ripgrep, test runners, etc. etc.) which makes it pretty amazing.
After turning off its annoying auto-commit-for-everything behavior, aider does work OK but it's harder to really get it to understand what I want during planning. Its new `--watch-files` thing is pretty darn cool though.
Update: I refactored it to remove d3 and use solidjs for fully reactive SVG generation. I'm happy with how that came out. Panning and zooming are smoother now on all platforms.
Be a craft programmer. Create or join a small lifestyle tech company that understands the beauty of software, the importance of keeping your tools sharp and your technique polished. Avoid the giant soul-sucking companies where you're just a cog in a giant machine.
Ah, good old Ted Nelson. His "Computer Lib/Dream Machines" captivated and inspired me as a counterculture kid in the '70s, and played a big part in me becoming a graphics nerd today. (https://en.wikipedia.org/wiki/Computer_Lib/Dream_Machines)
No argument here, and I've been using emacs since around 1983. It's a hobby and a way of life. But like any way of life, it's for those who like that sort of thing.
