What do you really get from IDE-driven development?

All in all, I don't see the link between using an IDE or not and the quality of the outcome. But I do see the link between using an IDE and development speed, where refactoring is just so much faster and less error prone if you have a decent IDE.

I haven't tried copilot yet, so can't say much about it.

In the 90s IDEs were all the rage, from Turbo Pascal to Visual Basic - the pinnacle of usability IMO.

> This happens in just about anything you can imagine, but let’s consider IDEs. You start using an IDE and it makes one particular thing particularly easy, and it makes it so easy that you don’t go looking for something even easier. You can’t spend all of your time wondering if there’s a slightly better way of doing things.

This argument resonates fairly well with me. I generally view IDEs as low commitment, a rapid learning curve to completion, with very hard caps on what you are going to find. You'll understand what the tool gives you, and then you'll be done. There's some trading/collecting hooks to keep you feeling like you can improve, to collect all the best plugins to improve the base system, but you're still a consumer, hunting for solutions, and you never really gain intimacy, understanding, or general prowess, evaluating your gains from a position of general ignorance as to what you're really buying/using. Being an end-user is being stuck at some minimum, having milked the curve you're at, until someone else comes disrupts your world for you. You make no real gains on your own, develop no only superficial mastery, mastering of the pane-of-glass atop the environment you dwell in.

It's really really hard to make a stronger better pitch for the school of lifelong learning & struggle. Often IDEs are a great way to understand what is possible, what tools to expect, but once you have a baseline, getting back into the command line, the terminal, the console & re-learning the hard way how to re-enact many of the things your IDE does for you is really hard. The learning curve is super slow, it takes ages to get out of the bottom reaches & start to feel ok. But you're gaining mastery not just of the programming job, but of the operating system, of the shell, of the real genuine honest environment of computing. Your ability to understand & see what is happening is so much higher, has such a more real connection than the pane-of-glass interface. Your ability to evaluate & direct yourself grows & amplifies over time, only if you invest in yourself & think of yourself as someone seeking a truthful engagement.

In general, I feel like the world has a lot of "what is the use case"/"what is the business value" thinking, and there's kind of an aggressive anti-exploratory value system that hates geekiness, that hates learning, that despises the enrichment of humankind, that rejects possibility. To insist on fast immediate obvious worth is to miss the big picture, is toxic to healthy ecosystems & diversity's neandering, exploring many many many tentacles. I want to see a world culture that believes in honest, genuine interactions, not fancy indecypherable veneers of things. Papert's Constructivism/Constructionism is a spiritual boon, one essential to what humanity became, and we should cherish, protect, & grow this light. https://en.wikipedia.org/wiki/Constructionism_(learning_theo...

If these things somehow prevent you from writing code that is as good as it would be without these integrations then what on earth were you doing? Apart from the “copilot” like things (which almost no one uses and which is orthogonal to the concept of IDEs, any editor can have that) what is “IDE-driven development”? Taking the first autocomplete suggestion after typing a dot in Java? instead of what? Reading docs? It’s not like the IDE having autocompletion for valid method names is forcing your hand to blindly take the first one or the wrong one? This reads a bit like that rant against syntax highlighting making developers bad.

This goes for IDEs, programming languages, frameworks, etc. Think of a language like PHP, which made it so easy to code that countless shitty websites were made, ridden with spaghetti code and security issues. But, I was amongst probably tens of thousands of script kiddies who cut our teeth on PHP and eventually learned how to "properly" build web products. My first startup's MVP was a giant functions.php file and a bunch of templates, FTP'd onto a VPS. Probably wouldn't have gotten into it if instead I had needed to learn something like C++ or Java.

Yes, making something easier to do decreases the quality on average. But even skilled professionals can benefit from better accessibility. And it's hard to quantify the full benefit to those who wouldn't have been able to do the work without the lower barrier.

Personally, yes, I know if I blindly use Github Copilot I'll prob write some shitty code. But it just makes everything easier/faster to do. So I use it and put in a tiny bit of extra effort to make sure I'm not abusing it. And it's game-changing. I'm also sure tools like Copilot will improve at a pace that is much faster than people expect. It will recognize deprecated calls, misused calls, errors, security holes, etc.