The Return of Fancy Tools

I find it hard to think I'd give PyCharm up for my daily Python and Typescript.

(apart from that: a filesystem is nothing else than a database, and text files are pretty much the most open data format imaginable, it's not like we arrived there by accident).

Take for example the admin UI. When adding "Application Links" to link Jira and Confluence with each other, Jira has a nice tabbed interface allowing you to configure it easily, whereas in Confluence, you have to scroll down a long sidebar with dozens of options until you chance upon the required link. Had similar experiences configuring various other options at the filesystem level.

Jira configuration was more coherent, fault tolerant and failed gracefully. Confluence configuration on the other hand was messy in comparison.

But generally IDEs are almost a necessity for any complex Java codebase. That's markedly different in other languages. I sometimes work on the chromium codebase (C++ mostly) which I use either VSCode or a simple text editor for. When dealing with smaller scripts, whether in Python, Perl or Bash or whatever, I usually stick to whichever simple editor I happen to have accessible. The same is true for some small C codebases I maintain on an irregular basis.

Generally I consider it a rule of thumb that the more refactoring a codebase requires to be kept in a maintainable state, the more you profit from an IDE. And the necessity for complex refactoring grows with the size of the codebase and the number of developers working on it (especially if a lot of them happen to be rather new to the craft).

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.