I definitely can agree that with larger codebases I need to restart my IDE from time to time. I guess, for me, I became accustomed to that and started tolerating it. That is because I still get tons of value from complex automated refactorings because I use TDD and I need to refactor in small atomic steps every few minutes.
The famous quote “Have you tried to restart it?” works well here.
What I did notice is that when you have a simple editor, or library, tool, or framework, whenever such blasphemy happens, we, as developers, go to GitHub (or another tracker) and report an issue. We also help with all the details for the developer, and engagedly help them fix the problem.
I see myself (and others) do that much less with a paid tool for some reason even though the support (that we’re paying for) is exactly for this purpose.
Usually when I have a problem with a bigger tool the issue tracker points to a several years old issue that's either marked as solved or wontfix. In addition, some are hard to describe or recreate, and it feels strange to complain about a project not being optimized enough.
Though I must admit I'm often too lazy to report issues, so I can't really answer your question well :-P
I think it's a mindset when we engage with Big Companies vs. individual developers. Smaller open source projects like simple text editors feel like individual devs we'd like to help, because we know the struggle if being a dev getting their project bug free. Large IDEs that we pay for feel more like anonymous companies that don't deserve our help. I've seen a change of my mindset toward some of the Jetbrains IDEs: I've met a few of the people behind CLion, and I'm much more inclined to file bugs and provide repro steps for that IDE, but not for others.
The people behind it are small teams of developers. If they don’t have the feedback loop closed—there is no way that the bugs will be fixed. And also, in this complex world, it’s not possible to write bug-free applications from the get-go without the feedback loop.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I definitely can agree that with larger codebases I need to restart my IDE from time to time. I guess, for me, I became accustomed to that and started tolerating it. That is because I still get tons of value from complex automated refactorings because I use TDD and I need to refactor in small atomic steps every few minutes.
The famous quote “Have you tried to restart it?” works well here.
What I did notice is that when you have a simple editor, or library, tool, or framework, whenever such blasphemy happens, we, as developers, go to GitHub (or another tracker) and report an issue. We also help with all the details for the developer, and engagedly help them fix the problem.
I see myself (and others) do that much less with a paid tool for some reason even though the support (that we’re paying for) is exactly for this purpose.
Why do you think is that?
Usually when I have a problem with a bigger tool the issue tracker points to a several years old issue that's either marked as solved or wontfix. In addition, some are hard to describe or recreate, and it feels strange to complain about a project not being optimized enough.
Though I must admit I'm often too lazy to report issues, so I can't really answer your question well :-P
I think it's a mindset when we engage with Big Companies vs. individual developers. Smaller open source projects like simple text editors feel like individual devs we'd like to help, because we know the struggle if being a dev getting their project bug free. Large IDEs that we pay for feel more like anonymous companies that don't deserve our help. I've seen a change of my mindset toward some of the Jetbrains IDEs: I've met a few of the people behind CLion, and I'm much more inclined to file bugs and provide repro steps for that IDE, but not for others.
Yes. This!
The people behind it are small teams of developers. If they don’t have the feedback loop closed—there is no way that the bugs will be fixed. And also, in this complex world, it’s not possible to write bug-free applications from the get-go without the feedback loop.