Really well written article, thank you!

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.

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.

> - 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.

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.

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).

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

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. :)

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 ?

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.

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

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.

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"

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 appreciate both for different reasons.

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.

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.)

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.

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.

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?

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.

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

Amanda try to be like.

> 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

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.

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

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.)

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.

> 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.

> 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.

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.

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!

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.

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?

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.

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...

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.

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.

Well said!

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/

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)?

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

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

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.

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.

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!"

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

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

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

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

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.

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.

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?

Animal Farm, but with a twist

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

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.

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

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

I had a lot of fun in DevDiv!

> 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.

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

Stereotyping people is good.

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've seen those kinds of tests described as astrology for business guys. Sounds about right.

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

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

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

By not putting reductionist labels on them.

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.

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.

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.

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.

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.

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.

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

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

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.

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

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

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

Amanda=Cleric

Microsoft rarely did or does anything first. They are typically second or third to the post and VC is no different.

Most people don’t know or realize that Git is where it is because of Microsoft. About 1/2 of the TFS core team spun out to a foundation where they spent several years doing things like making submodules actually work, writing git-lfs, and generally making git scale.

You can look for yourself at the libgit2 repo back in the 2012-2015 timeframe. Nearly the whole thing was rewritten by Microsoft employees as the earliest stages of moving the company off source depot.

It was a really cool time that I’m still amazed to have been a small part of.

Huh? I've always seen numbers larger than that

Xreal claims

> To mitigate this, the industry usually maintains the VID at over 1 meter; for instance, Apple's Vision Pro employs a distance of 1.1m, Meta Quest 3 sits at 1.25m, and Hololens boasts 2m.

https://us.shop.xreal.com/blogs/buying-guide/prescription-le...

Though strangely they don't give a number their for their own devices.

The article claims the focal plane on the xreal glasses is 10 feet (roughly 3m).

Why? I mean, can't you dial it in and out if you weren't folding the path and really needed that feature?

Can you point to something to learn more about this?

The article says his one is 10 feet (3m).

A team in my org worked with Jet for 2+ years to help y’all scale.

It was interesting seeing the biweekly status updates, they basically all started with “This is how Jet.com broke Azure core services this week”.

As much as it sucks, this was a deliberate strategy all the way from Satya - every employee knew Azure was a joke, but the only want to actually fix shit was to get internet scale customers to break it daily and weekly.

My experience working on Google Cloud Platform is similar. Even when the solution is relatively technically simple, there are many organizational impediments and politics because the solution likely involves multiple fiefdoms.

The only thing that seems to get the fiefdoms to work on an issue is if a big enough customer calls enough of an attention to the issue so that no leader/fiefdom wants to be blamed in such a "high profile" issue that everyone got their work in gear for. This leads to organizational dysfunction since now everyone understands that there's no point in trying to fix anything until there is enough attention on it, and that is mainly achieved when a big customer complains.

I've even had projects that took months of engineering work that would resolve many user complaints about a lack of really basic functionality, and different elements of leadership would block the launch. I can only guess that some fiefdom did not like change and would not state their objection publicly, so I only got stonewalled, and I never got an explanation to throw away months of work. I am as certain as I can be that if a big customer complained loudly enough about the problem that such basic functionality was missing, the organization would demand that the fix be launched.

> but the only want to actually fix shit was to get internet scale customers to break it daily and weekly.

I don't get it. There's lots of distributed systems theory that could provide a more robust, analytical approach to a scalable architecture. If a system is regularly breaking like this, it sounds like it should be a "back to the drawing board" moment.

Back to the drawing board risks delaying your products with several years. Their strategy was probably the right one.

It sounds like their product has been considered crap for years, so they've had the time.

“We’ve had years to fix it, all the experience and knowledge we’d need, but we’ve tried basically none of it and we’re at a loss as to why our product is still garbage! It’s truly a mystery” - Azure leadership I assume.

It has been on life support for a long time AFAIK. I designed Visual Studio Online (the first launch of AzDO) - and every engineer, PM, and executive I worked with is either in leadership at GitHub or retired.

It feels clear from an outside perspective that all the work on AzDO Pipelines has shifted to focus on GitHub Actions and Actions is now like 3 or 4 versions ahead. Especially because the public Issue trackers for some of AzDO Pipelines "Roadmap" are still up (on GitHub, naturally) and haven't been updated since ~2020.

I wish Microsoft would just announce AzDO's time of death and save companies increasingly crazy AzDO blinders and/or weird mixes of GitHub and AzDO as GitHub-only is clearly the present/future.

Yeah feels like they should be able to converge actions and pipelines.

Keeping some separation between AzDo itself and GH also requires some balancing. But so far I’m pretty sure I could never sell our enterprise on a shift to GH. Simply not enough jira-esque features in GH with complex workflows, time reporting etc so I can’t see them doing the bigger GH/AzDo merger.

This month's rollout of sub-issues and issue types would be most of what my organization thinks it needs to shift to GH Issues, I believe, barring however long it would take to rewrite some sync up automation with ServiceNow based on those issue types. Of course it will take another 6 months to a year before those kinds of features make it to GitHub Enterprise, so it is still not happening any time soon. (Though that gets back to my "weird" mixes. I don't entirely know why my company is using AzDO SaaS for Issue Tracking but decided GHE over "normal" cloud GH for Repos. But that's not the weirdest mix I've seen.)

I definitely get the backwards compatibility thing and "don't break someone's automation", but at the same time, Microsoft could at least mark AzDO's official Roadmap as "Maintenance Only" and send the message that feels obvious as a user that GitHub is getting far more attention than AzDO can, but is hard to convince management and infosec that a move to GitHub is not just "the future" but "the present" (and also maybe "the past", now, given AzDO seems to have been frozen ~2020).

Thin client - no big deal. $30-300 per month per device? LOL. Dead on arrival.

That 30-300 dollars is just the range of virtual machines you are connecting to-- I can't imagine it is very surprising that a personal VM starts at around 30 dollars per month and GPU-enabled machines would be substantially more expensive. A quick spot check suggests this pricing is in line with the same type of offerings available in AWS (~$30-$1000) https://aws.amazon.com/workspaces-family/workspaces/pricing/.

The cost of 30 to 300 is the cost of the cloud pc, with or without this device. The device just provides a secure way to access it.

For context

For 30 you get 2 vCPU, 4 GB RAM,64 GB Storage. For 300 you get 16 vCPU,64 GB RAM, 1 TB Storage.

https://www.microsoft.com/en/windows-365/enterprise/all-pric...

Similar story here. 20+ years experience in leading dev, pm, and UX teams. Launched multiple 0-1 market leading products, worked with dozens of Fortune 500s.

Applied to more than a hundred positions - one phone screen and one interview.

Then I just went to my large network and within a week I have multiple opportunities - companies creating positions so they can hire me.

Spoke to a number of colleagues in recruiting and who are hiring for their teams - the number of ghost jobs, and frozen but posted positions is staggering. Something is fundamentally broken in the hiring world today.

If this is a true story, then it means there’s no point in applying at all. You should just go full LinkedIn, and networking, preferably when you still have a job.

I’m not gonna do that so I’ll just keep my job until layoff, and then panic, automate my applications and belatedly start connecting.

I think that's more or less true. Outside of school (one of which was way back in spray and pray physical letter days), my few jobs have always been through personal connections. Any online applications pretty much resulted in nada.

This is the way. Submitting an application is useless. We've reverted back to networking for jobs. You have to connect with actual humans, as nobody is going to wade through 5k resumes and pick yours out no matter how good it is...

He didn’t keep the lights on while waiting for new development to take off. He actively lost 40+ billion dollars on horrible acquisitions, and actively stifled internal innovation to ensure existing product lines weren’t threatened.

On the sales side he streamlined Microsoft into a single monolithic sales motion that killed dozens of products before they started because the target customer/market didn’t fit the EA model.

This included Azure that took nearly a decade after his departure to unwind so the sales force could actually sell consumption based products and services.

I honestly can’t think of anything substantially positive he achieved in his tenure other than promoting Satya and Scott G and a handful of others.

All of the contemporary media reports don’t know about the laundry list of near sighted, anti competitive, anti innovation shit he put on the company.

> I honestly can’t think of anything substantially positive he achieved in his tenure other than promoting Satya and Scott G and a handful of others.

Ok, but apart from fostering a great generation of new executives, investing in currently extremely profitable products and business lines, streamlining our sales operations and getting us out of these life threatening antitrust cases, what did Steve Ballmer ever do for us?

This is so true.

I adopted mediawiki to run a knowledge base for my organization at Microsoft ( https://microsoft.github.io/code-with-engineering-playbook/I... ).

As I was exploring self-host options that would scale to our org size, it turned out there was already an internal team running a company wide multi-tenant mediawiki PLATFORM.

So I hit them up and a week later we had a custom instance and were off to the races.

Almost all the work that team did was making mediawiki hyper efficient with caching and cache gen, along with a lot of plumbing to have shared infra (AD auth, semitrusted code repos, etc) thst still allowed all of us “customers” to implement whatever whacky extensions and templates we needed.

I still hope that one day Microsoft will acknowledge that they use Mediawiki internally (and to great effect) and open-source the whole stack, or at least offer it as a hosted platform.

I tried setting up a production instance af my next employer - and we ended up using confluence , it was like going back to the dark ages. But I couldn’t make any reasonable financial argument against it - it would have taken a a huge lift to get a vanilla MW instance integrated into the enterprise IT environment.

Microsoft did open source a bunch of their mediawiki extensions. https://github.com/microsoft/mediawiki-extensions

Last i heard though they were moving off it.

Nice!! Made my day. Not sure how they can move off of it, partly because there’s no alternative that has a fraction of the capability

The rumour i heard is they were making their own custom thing.

There was some rumours that they were unhappy about mediawiki's response to patches they submitted (they made a bunch around accessibility). However i looked through their patches at one point when this rumour started flying around and it looked like most were merged. Those that weren't generally had code review comments with questions or pointing out mistakes which were never replied to. I sort of suspect the patch thing was some sort of internal excuse because the team involved wanted to make their own thing.

Regardless, im really happy they decided to open source their extensions and it was nice to see that they put in effort to upstream core patches.

Yeah the team running the platform internally was amazing to work with and did incredible work with just a handful of resources.

The efficiency for scale of mediawiki is hard to beat.