I don't think good tools are necessarily easy to approach. Some of the best tools I know have quite a steep learning curve. A good tool is one that gives you power. It makes difficult and complicated tasks easy and simple. It may come with the cost of getting good with using the tool, but once you master it, you don't know how you lived without it.

Consider “affordances”: a chair may be used for sitting, or as a weapon, or as kindling etc. Likewise, a good tool is made to be approachable for the beginner, and open-endedly extensible for the expert. They’re the same material, but the hand movements of beginner and expert are very different. Analogously, consider how Simpsons episodes have 2 affordances: to be funny for children and for adults, each for their own reasons.

A good tool picks an audience and builds everything with them in mind. You can make a tool aimed at beginners of some discipline with the understanding it may not satisfy power users, but that doesn't make it a bad one, just bad for that audience. Same in the other direction, tools aimed at optimizing power users ability to do their task may seem completely impossible to a beginner, and that's totally okay.

Audiences change over time. Projects need something less ephemeral to aim for.

There's a lot of truth to this. I feel like I'm willing to really dig in and learn a tool if I can sense that the power of wielding that tool will be commensurate with the difficulty learning it.

A good tool is one that works, and works predictably. If it can just stay reasonably dependable, I'll come up with ways to use it to its limits.

"Good tools aim to simplify complexity, not complexify simplicity."

Some people don't realise that this is a goal, or that it's even possible.

At Microsoft, this was the philosophy behind the .NET Framework standard library. It is simple, beautiful, and abstracts away reams of complex boilerplate that was necessary with C++ programming.

Now?

I'm using Azure, and... oh... my god. Every internal piece of wiring is exposed, raw, to the end-user. Wear insulating gloves.

You need to know their internal project code names! The undocumented ones are typically the most important.

You need to pass secrets between two agents running on the same VM through your workstation during deployment!

Need to pass an identity around? It's broken up into individual fields, one of which can only have a single valid value. But you have to provide it using a programmatic lookup.

Want Accelerated Networking? There's a convenient Boolean flag for it. Great. Except that it'll break deployments if the VM size you've selected doesn't support it. How do you know if a VM size supports it? Bahaha... you don't. Build a switch statement with 300 entries yourself. That's what the Indian subcontractors writing the rest of Azure's code do! It's good enough for them, so it should be good enough for you. (I wish I was kidding, but I have seen the code and it is literally this.)

Ultra Disks? Switch statement.

Availability Zones? Switch statement.

You get the idea...

I have spoken with several Azure team leads, and they just blink at me slowly with an utter lack of comprehension when I explain that this is just not good enough. That in Visual Studio, I can tab-complete a type and it will compile. That 100% certainty is not comparable to 90% certainty in Azure, where a boolean true value might need to be the string "true" value because fuck you.

As long time developer on the Windows ecosystem I really don't get what happened.

I fully agree with the experience, add on top of that CLI tools for what used to be VS wizards, code instead of GUI designers, killing C++/CX replaced by C++/WinRT, which after 4 years still doesn't have VS tooling support, 5 competing GUI frameworks on Windows,....

Culture reboot at Microsoft went a bit too far in the wrong direction.

> Every internal piece of wiring is exposed, raw, to the end-user. Wear insulating gloves.

I'm stealing this one. Hope you don't mind.

Imitation is the sincerest form of flattery.

> That's what the Indian subcontractors writing the rest of Azure's code do!

Important to note that the subcontract would be paid 1/10th of what his counterpart in Silicon Valley would be getting.

I like what Douglas Engelbart said about good tools (paraphrasing): if you use a tool the same way on the 1st day you acquired it and a year later - it's not a good tool.

Which I feel a lot of modern software struggles to provide. Sure I can onboard quickly and do _something_ but if I'm spending hundreds of hours I want to get better at it and improve my returns.