4 ms·

I think you need to define what is a complicated code base here. Visual Studio works fine for millions of lines but I am sure the difference in experience can

• shadowgovt 3y ago
  Visual Studio crashes on the code base I maintain. It's a monorepo using bazel to manage it, and between the sheer number of includes compilation units take, the hundred thousand plus compilation units themselves, and some decisions made early on that are hostile to VS code tooling because the original developers didn't use VS code (such as hiding template implementations in .inl files that are included in the corresponding .hh file), VS code is functionally unusable for us. In general, the company moves forward because most of the same people who established the code base are still working here and they just already know all the quirks and can Intuit argument types, often because they wrote all the classes in question.
  • fsloth 3y ago
    Ouch, my condolences.
  • ftrobro 3y ago
    Visual Studio != VS Code. I've always found Visual Studio to be great at C++ so I'm interested in knowing which of the two you meant?
    • shadowgovt 3y ago
      VSCode, to be clear. The fact that Microsoft released two products in the same domain with almost the same name consistently trips me up. No, we don't spend money on code editors around here; I meant VSCode.
      • TillE 3y ago
        Visual Studio Community is free to any company whose annual revenue is under $1 million USD. It's fully functional, unlike the ancient Express versions.
      • fsloth 3y ago
        "No, we don't spend money on code editors around here; I meant VSCode." Not spending money in tools sounds like a very strange economics for software development. If interviewing does not scare you I warmly suggest finding a new employer.
  • CyberDildonics 3y ago
    Visual Studio is not visual studio code. Also if you have a hundred thousand compilation units, it might be time for some shared libraries instead of one monolithic program.
    • shadowgovt 3y ago
      Oh I completely agree, but I am a mere senior software engineer and I have not yet figured out how to chisel past the corporate cruft of the three folks in charge of the codebase who believe monorepos are right because Google is doing it, therefore it must be the best way to do things. Nevermind that I have some experience with how Google did it, and it turns out there's a lot of ills you can solve with a 25,000+-strong engineering force that you can't in a smaller org. VSCode at Google never worked for me either, but punching a novel symbol into company-wide syntax-intelligent internal code search and glancing at the first response, which was likely to be the right one because it was a Google search engine so had well-tuned signals for "things humans care about," always did. They're not interested in how Google does it, merely that they do it so you can't get fired for making an architectural decision that worked for Google. Nor are they really interested in solving the tooling issue because it works for them; they just grep-and-pray. They're very fast at it because it's all they know so they've gotten quite good at it (when they have to do it at all; often they just know the types because they wrote the classes. ;) ).