My company has banned the use of Jetbrains IDEs internally

Original Article ↗ Hacker News Discussion ↗

Job market, “just quit” advice, and privilege

  • Some argue that if a company makes sweeping tool decisions you strongly oppose, you should leave and find an employer aligned with your preferences.
  • Others counter that this assumes financial and market privilege; many cannot safely quit given the harsh 2024 job market and long, exhausting job searches (hundreds of applications).
  • Suggested middle ground: look for a new job before resigning, or only quit on principle if you have substantial savings or another offer lined up.

Reasons for banning JetBrains and geopolitics

  • The ban is reportedly justified by JetBrains’ “Russian ties”; some see this as a valid risk-avoidance move (esp. for sensitive customers worried about Russian state pressure).
  • Others criticize such blanket boycotts as overreach or politically inconsistent, and question whether targeting a dev tool vendor meaningfully affects state policy.
  • Several commenters stress that it’s legitimate to boycott companies for ethical or political reasons, but that standards will inevitably be uneven.

JetBrains’ Russian origins and current status

  • JetBrains is widely remembered as founded by Russians and historically having substantial R&D in Russia.
  • Linked JetBrains blog post (2022) is cited: they shut Russian offices, stopped R&D in Russia, filed liquidation for the Russian entity, relocated many staff, blocked Russian customers, and cut cooperation with Russia.
  • Perception diverges:
    • Some in Russia see JetBrains as fully severed and effectively “pro‑Western,” even cancelling licenses seen from Russian IPs.
    • Others outside Russia still view it as “Russian” or allegedly tied to people close to Putin; evidence for these deeper ties in the thread is anecdotal and unclear.

IDE/editor choices: JetBrains vs VSCode vs Emacs/Vim/Neovim

  • Many note that JetBrains IDEs are feature‑rich out of the box, especially for Java and complex refactoring; moving back to VSCode can feel like a downgrade unless heavily extended.
  • VSCode is praised as a strong, flexible default, easy to standardize across teams and configure via shared JSON; some see it as “the one tool to rule them all,” others distrust it as a Microsoft, telemetry‑heavy product.
  • Large subthread debates Emacs/Vim/Neovim:
    • Proponents emphasize longevity, deep configurability, keyboard‑driven workflows, LSP-based language support, powerful Git integration (e.g., Magit-like tools), and avoiding dependence on proprietary IDEs.
    • Critics emphasize steep learning curves, esoteric configuration (especially Emacs Lisp), time sink of maintaining configs, and difficulty using them as a team‑wide standard compared to VSCode.
    • Some claim they “grew out” of needing heavyweight IDEs; others insist that debuggers, refactoring tools, and rich cross‑domain integrations (e.g., SQL inside Java) make modern IDEs clearly more productive.

Productivity, UX, and career strategy

  • There’s disagreement on whether mastering a programmable editor once (Emacs/Vim) yields long‑term productivity gains vs. simply learning new mainstream IDEs every few years.
  • Several stress that a developer should be comfortable learning new tools; others argue editing muscle memory is precious and switching editors frequently is wasteful.
  • Some report JetBrains tools feeling increasingly bloated or buggy, especially after staff relocations; others still consider them best‑in‑class for certain languages. Quality trend is disputed.