|
Indeed. My attitude is that people should use tools that work for them but without compromising on code quality, productivity, or impacting other team members with their tool choices. The latter is a big caveat when working on Kotlin/Java code bases because standards are high regarding things like code formatting, style, etc. People will notice when you skip some of the things Intellij does. The few cases I've seen of people not using the right tools for the job, they thought they were doing a great job. And then I did a code review and showed them how bad it was because clearly they were blissfully unaware of warnings, had never run a static code analyzer, were clearly not refactoring their code base, and were generally doing a lot of things that were bordering on "probably wrong; definitely not optimal". IDEs provide several big buckets of essential functionality: - Code criticism: warnings, static analysis, deprecations, dead code, etc. You can use external tools to stay on top of this as well. But having mistakes pointed out to you as you are making them saves a lot of time. Also, since these are preventable problems, there is zero excuse for having any of them. So, whatever you use, make sure you stay on top of this. If this is tedious, consider using better tools or fixing the ones you have. - Intelligence and situational awareness: Syntax coloring, code navigation & documentation, find uses of, etc. When stuff doesn't work, this is a real time saver. Bottom line here is that there are things that you need to know how to find out about your code. If you can script things together using grep and other command line tools; great. As long as you are productive. But you have no excuse for ignorance. - Automatic program transformations: This goes way beyond refactoring (which is also useful of course and for which renames are merely the simplest example) and also includes things like using quick fixes for common problems, automatically applying replacements for deprecated functions, adding all the missing branches to a when statement, managing lists of imports, converting between different syntax alternatives for the same thing (e.g. convert between when and if, invert an if, ...), etc. For languages like Kotlin and Java, there are hundreds of these and they are super useful. I use them all the time. Use them or don't use them. But you should not allow your tool choices to impact your code quality. So, if it needs refactoring, do it. Do it manually if you must. But you don't get to skip it. Edit your imports like a caveman if you must, but make sure you do it properly (no wildcards, sorted correctly, remove unused imports, etc.). - Tool integration: Build tools, debuggers, de-compilers, code formatters/linters, etc. Nice to have that at your finger tips. If you do this via the command line, be my guest. But make sure you know how to use your tools and that you do use the tools that are available to you. On projects I manage, I'll judge people on their code quality, not on how they produce their code. But I'm a harsh judge when it comes to that. Do it whatever way pleases you but do it right. And with some editors, that just means performing a lot of manual labor. |