> Take the Jetbrains IDEs. I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way. For individual use, most of them are <$100/year.
After a particularly bad tooling week (js supply chain problems, plugin problems and more than the usual amount of DB changes) Our dev team made the unanimous call to move require all developers to use Jetbrains IDEs instead of the mix of VSCode, Emacs and whatever else... Our codebase is Python, Go and Javascript, and data is stored in Postgres, so we use Goland, PyCharm, WebStorm and Datagrip regularly. We also started using the awesome Micro editor when we need something that can be installed on a remote because it's key bindings are identical to JetBrains...
A few thoughts:
1. We all picked up 2-3 hours per week of time we were spending pounding plugins on Emacs and VSCode into shape. There was a lot more fiddling going on than we thought.
2. The debugger in JetBrains IDEs is top notch. Debuggers are underrated, and bad debuggers make using print and over-logging seem like the best option.
3. When we want to do something new, (containers, notebooks, etc...) it is almost always supported, and there are not 100 incomplete plugins to sort out (both Emacs and VSCode have this issue).
4. We're doing things the same way, which sometimes really pays off. For example, instead of a mix of PostMan, python scripts, restclient, and bashified curl for making api requests, we just use the client in the IDE... which means we can share them.
5. Datagrip and the database tools in the IDEs are incredibly useful.
Ok, so the payoff: By the end of the second week, we were over the learning curve, and the payoff came in the third week: a total of 16 hours of developer time not spent on twiddling with Emacs, vim, Sublime and VSCode. That time savings paid for the subscription for the year.
While I've never worked anywhere that enforced the IDE, I can see the appeal.
Problems like linting and formatting working differently for different developers because they're using different tools, not updating settings correctly because their IDE uses a different settings file. Junior developers struggling to find people to help them because everyone's using their own toolchain.
Everyone on the team agreed. If one person had said no, we would not have made the jump.
> I think having a blessed option and understanding of "use what you want but don't let it affect deliverables" is best.
That's kind of how it worked out for us. We didn't ban emacs or vs code, we just all agreed we'd go Jet Brains first and mostly... and for the more senior of us (me especially), go out of the comfort zone and learn the new tool.
After a particularly bad tooling week (js supply chain problems, plugin problems and more than the usual amount of DB changes) Our dev team made the unanimous call to move require all developers to use Jetbrains IDEs instead of the mix of VSCode, Emacs and whatever else... Our codebase is Python, Go and Javascript, and data is stored in Postgres, so we use Goland, PyCharm, WebStorm and Datagrip regularly. We also started using the awesome Micro editor when we need something that can be installed on a remote because it's key bindings are identical to JetBrains...
A few thoughts:
1. We all picked up 2-3 hours per week of time we were spending pounding plugins on Emacs and VSCode into shape. There was a lot more fiddling going on than we thought.
2. The debugger in JetBrains IDEs is top notch. Debuggers are underrated, and bad debuggers make using print and over-logging seem like the best option.
3. When we want to do something new, (containers, notebooks, etc...) it is almost always supported, and there are not 100 incomplete plugins to sort out (both Emacs and VSCode have this issue).
4. We're doing things the same way, which sometimes really pays off. For example, instead of a mix of PostMan, python scripts, restclient, and bashified curl for making api requests, we just use the client in the IDE... which means we can share them.
5. Datagrip and the database tools in the IDEs are incredibly useful.
Ok, so the payoff: By the end of the second week, we were over the learning curve, and the payoff came in the third week: a total of 16 hours of developer time not spent on twiddling with Emacs, vim, Sublime and VSCode. That time savings paid for the subscription for the year.
reply