This is a behind-the-scenes sort of improvement which has been happening since the late 2010s while real applications have seemingly gotten worse.<p>What’s actually happening is that there are a lot of bloated, buggy, badly-designed programs today because they simply wouldn’t have existed prior to the improvements in developer tooling. In some cases because the software has a much broader scope made possible by the tooling (distributed “webscale” sites with massive data throughput and configurability). Alternatively (or additionally), sometimes the developer(s) are mistakenly using a tool (e.g. Kubernetes) that is way too webscale/generalized for their purpose and/or itself wouldn’t have existed prior to improvements in development tooling.<p>Good software still exists today. It’s just gold lying around in a forest of junk, whereas it used to be more like less-shiny gold lying around in a barren plain.
> With luck, the options for doing so without paying a monthly tithe to dozens of vendors will improve over the next decade!<p>This is why I've started digging deep into setting up a homelab environment, with the goal to be implementing local source control, automation pipelines, AI inference models, and hosting.<p>I feel it's important to keep skills fresh rather than paying others to do.<p>It is important to focus on what you're good at, but it's also important to know what is really going on at the infrastructure layer.<p>BTW. on premise compute for homelab environments is incredibly cheap right now! (Looking at you 'second hand Dell Optiplex' gear)
Visual Studio 5-10 years ago with C#/.NET Intellisense was a great experience and high performance. I have yet to replicate that in the bloated Electron IDEs these days, there are still constant issues with autocompletion and navigation being slow or not working randomly for some reason even on my $3000 desktop PC from last year, I haven't found debugging (properly with breakpoints and variable tracking) to be viable compared to "printf debugging" since my Visual Studio days, and the UX of VSCode has not caught up to Visual Studio for bigger projects, file navigation is particularly awful and between the floating toolbars that disappear on a whim and ridiculously narrow scrollbars you'd think they're making it difficult on purpose.<p>It's an improvement from a certain baseline, but Visual Studio set a higher bar for me personally.
> Both have evolved gradual type systems that might make it easier to hold a large program in an individual’s head productively.<p>This… is not the primary benefit of type systems. (Not sure I’d agree that this is even an actual benefit - my mental model of a system is unaffected by the presence of types)<p>In my view, the primary benefit of type systems is that it makes changing code significantly easier, much in the same way that test cases do. They give you confidence that a code change doesn’t cause a regression. Refactoring a code base without types is nightmare fuel. This is not hype.
Have IDEs gotten faster, or have processors gotten faster to the point that it's now feasible to use a heavy IDE without wanting to tear your hair out? I personally think it's the latter.<p>This isn't really an assessment on the utility of IDEs. I think they're a net positive for the people that get benefit from them.
> Notably, I have not used Kubernetes but the anecdotal data does not lead me to think I’m missing out on much.<p>My experience as a single developer on a new project is that the usability of K8s has improved dramatically in the last decade.<p>I use Vultr VKS; setting up a small cluster takes a few minutes, it’s super cheap, and now I have a deployment environment with automatic redundancy, zero downtime upgrades, and much more.<p>It’s not perfect, but I absolutely love it, and it’s made my life so much easier. I do hate yaml with a passion, and there’s a lot of boilerplate, but IDEs and templates make it bearable, and in any case it’s a small price to pay for all the automation I get.
> AI assistants/copilots can wear the hat of “better autocomplete” today and may wear the “help me understand this code” or “help me write a good PR/commit message” hat later. I’m skeptical about the wisdom of handing off the latter to a program, but we’ll see how it goes.<p>The vast majority of PR/commit messages I see (approaching 100%) are basically a JIRA ticket number and the name of the ticket, and that message is used over and over again for multiple commits under that same ticket. I'm not sure Copilot could do any worse.
> Notably, deploying software doesn’t seem to have improved much at all for the individual developer. Heroku, in its prime, is still the golden standard.<p>I feel this. There are a lot of PaaS options, but very little portability between them.
> The options free of lock-in for such a service are limited-to-nascent2.<p>Everything is a lock-in of some kind or to a degree, even k8s or EC2s can be depending on the complexity, of which there exists heaps in k8s. It's a different kind of lock-in, the self inflicted variety.
I don't understand the hate regarding K8s.<p>What's wrong with developing software knowing it will be hosted on a k8s cluster?<p>You can install a local k8s cluster will plenty of tools helping you with secrets management, observability, ingress, scaling, storage.<p>Why the hate?