Rethinking the IDE for the 2020s
movingfulcrum.com
Rethinking the IDE for the 2020s
1–10 of 64 posts
Re: Rethinking the IDE for the 2020s
#2“A typical organization in the 2020s has:
Hundreds of microservices”
Can people with expertise in this situation speak about how typical it is? I guess if you have all those services then you need your IDE to help - but surely this isn’t super common? If it is, what sort of size of micro service are we talking here? I’ve worked in orgs with 3M line codebases, and I’d struggle to find a hundred ways to partition the code naturally.
Re: Rethinking the IDE for the 2020s
#3“A typical organization in the 2020s has: Hundreds of microservices” Can people with expertise in this situation speak about how typical it is? I guess if you have all those services then you need your IDE to help - but surely this isn’t super common? If it is, what sort of size of micro service are we talking here? I’ve worked in orgs with 3M line codebases, and I’d struggle to find a hundred ways to partition the c…
I would say this is somewhat accurate at my company (thousands of engineers). It depends on what you quality as a microservice.
Re: Rethinking the IDE for the 2020s
#4Basic summary: "a modern IDE should be optimised for my particular use-case". The author then proceeds to describe a very atypical use-case.
One example: "The IDE should ask for the Github org eg, github.com/astradot and it should create a single project that contains all the repo as modules. It should then manage lazy-loading/lazy-checkout or whatever is needed to give me a seamless experience browsing the code of my entire org."
Like (I strongly suspect) a majority of developers, I work in a large monorepo. There are 400+ other repositories in the same GitHub org. 99% of them are small projects I'll never touch. I wouldn't want my IDE to go anywhere near them.
Re: Rethinking the IDE for the 2020s
#5For most devs the most user facing issue of intellij is it's time to first syntax highlight and is one of the few points where vscode is better.
Upvote the issue if you wanna bump up the priority https://youtrack.jetbrains.com/issue/KT-45087
Re: Rethinking the IDE for the 2020s
#6[deleted]
Re: Rethinking the IDE for the 2020s
#7Liveshare is pretty useful for pair programming. Not about invading privacy but making it easy to work together. Given how easy it is to collaborate on docs with google docs it's kind of sad that remote collaborative coding tools are still in their infancy.
Re: Rethinking the IDE for the 2020s
#8“A typical organization in the 2020s has: Hundreds of microservices” Can people with expertise in this situation speak about how typical it is? I guess if you have all those services then you need your IDE to help - but surely this isn’t super common? If it is, what sort of size of micro service are we talking here? I’ve worked in orgs with 3M line codebases, and I’d struggle to find a hundred ways to partition the c…
I work in a large microservices environment. It’s very important that IDEs don’t make it easy to reach inside other services. The whole point is to create cognitive barriers at the public APIs. The pain of coordinating changes across services is a feature: it is telling you that your architecture is wrong.
Re: Rethinking the IDE for the 2020s
#9Basic summary: "a modern IDE should be optimised for my particular use-case". The author then proceeds to describe a very atypical use-case. One example: "The IDE should ask for the Github org eg, github.com/astradot and it should create a single project that contains all the repo as modules. It should then manage lazy-loading/lazy-checkout or whatever is needed to give me a seamless experience browsing the code of m…
That's the fundamental problem with tools like IDEs. They have to optimize for just a handful of use cases or the UX for all of them gets worse than just learning the individual tools. Jetbrains is pretty awesome but still not quite good enough to convince me it's worth adopting.
Re: Rethinking the IDE for the 2020s
#10I switched from IntelliJ to Emacs about a year ago, and honestly these things seem relatively trivial in that environment, because I can write small ELisp functions that automate things like this without much effort or ceremony. For example it's quite easy to automate checking out repos, applying AST refactorings using LSP Mode, and then committing and sending PRs using VC/Magit. Or configuring projects and "Run Buttons" for entire groups of packages.
Granted there is effort in learning ELisp in the first place, but now that I'm comfortable with it, I find myself able to adapt to these changes quite easily while many other developers have to wait on big feature releases from their IDEs, use hard-to-automated GUIs, or heavyweight IDE APIs to develop "plugins" to modify behavior.