Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking the IDE for the 2020s

movingfulcrum.com

Post reply on HN
Print view View original

11–20 of 64 posts

Re: Rethinking the IDE for the 2020s

#11

Post by brundolf »

aidos wrote: post #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 c…

It depends on how you define "typical". I'd bet it's a narrow minority of companies, but most of those companies are very large, so then what percentage of all engineers are working at companies like that? Maybe not a majority, but a significant number

Re: Rethinking the IDE for the 2020s

#12

Post by The_rationalist »

benjiweber wrote: post #7

Liveshare 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.

Intellij supports this natively with Code with Me. I also use it on their jupyter notebook competitor (datalore), it's a great fit.

Re: Rethinking the IDE for the 2020s

#15

Post by aidos »

closeparen wrote: post #8
aidos wrote: post #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 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.

And what qualifies as a micro service in your environment? Can you give a few examples? How many people work on each micro service? Etc etc. Would love to hear more details so I can build a better mental picture.

Re: Rethinking the IDE for the 2020s

#17

Post by thirdlamp »

aidos wrote: post #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 c…

While we're not in the hundreds (and I don't know our loc), what I've seen happen is that on top of having a large number of services you end up with "meta-repos" that contain infrastructure-as-code or you end up having a repo from which you build the company wide Jenkins image with its configuration and so on.

Re: Rethinking the IDE for the 2020s

#18

Post by akiselev »

aidos wrote: post #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 c…

It's pretty common. There's the extreme end like Uber (>3000 microservices) and countless cargo culting startups (I see a few dozen microservices for a team of half a dozen or fewer engineers in the wild frequently, which is big enough to desire cross-repo refactoring) but the 800 pound gorillas like Microsoft, Amazon, Apple, Facebook, etc. are at that scale by necessity. I doubt however that anyone is doing any sort of refactoring that touches a significant fraction of those and if they do, it's an organized manual team effort.

Microservices didn't become popular because the code could naturally be refactored that way, but because they enforced an interface boundary that worked better for mid to large sized organizations with multiple teams of engineers and levels of management where the communication overhead is much higher.

Re: Rethinking the IDE for the 2020s

#19

Post by dcre »

Cross-repo refactoring (even worse: renaming) seems like an at best worthless and at worst quite costly thing to optimize your toolchain around. Having stable interfaces between systems is very important. The whole point of having separate systems is so you don't have to change one when you change the other. If that's not the case, you're better off with a monorepo.
Post reply on HN