Embrace Tools

This blog post is a reply to Mark Seemann's warning: Beware of Productivity Tools. I suppose I fall in the category of those that "feel passionate about ReSharper" and I simply couldn't resist the temptation to share my passion.

My background is Java and in that environment there are plenty of IDEs a developer can choose from. Given that, you're encouraged to try them all and to select the tool that best does the job. Talking about an IDE (not Notepad), one of the smartest IDEs out there is IntelliJ IDEA by JetBrains. The guys at JetBrains have never left a Java developer breath, I think. With their constant improvements, there was always something to read about and learn. Simply amazed by their innovation and still waiting for some of the goodies to come to Visual Studio, like Auto-Save and Local History.

I switched to .NET only recently (1-2 years ago) but I still remember the initial frustration with Visual Studio. It was like using the good old Delphi IDE, where although you could do a lot of stuff pretty easy, there was some plumbing and manual coding of parts that can so easily be automated. At least from my experience with IntelliJ IDEA. Luckily, after a while I gave a try at ReSharper and found that the intelligence in the IDE can be found even within Visual Studio.

From my point of view, there aren't 100 best ways to program a piece of functionality. If you really look inside every different solution, one would always be better suited for the problem at hand. This is why Perl felt strange to me. I still remember how the teacher was excited that you can say the same thing in 4-5 ways. This isn't programming for me. This isn't optimized. It's more of poetry and language, and in this sense is more related to literature than to mathematics and physics. I don't say it's bad to want options and diversity, I just say I don't think this is the target of programming or engineering.

In this sense, when you write code, it's best to have tools that help you correct errors and prevent bugs. At first, Resharper is actually making you spend more time on your code. Because it tells you that this and that is not good. It asks you to refactor parts of the code, because there is a problem. It's productivity in the sense of quality, not quantity.

My guess is that this is the reason why Visual Studio 2012 got so many "productivity" features. It's just becoming outdated as an environment if they don't put them in.

Onto the final thoughts, learning Resharper as a productivity tool will first give you a better understanding of some of the inner-workings of the language. At some point, you always stumble upon a strange construct where Resharper will instruct you to do something. It's like a Senior Software Developer looking over your shoulder and giving you a hint. Because that's what it actually is. The guys at JetBrain, or even a normal Resharper user, finding a pattern and suggesting a good intention that can help out developers. If you haven't been to JetBrains bug tracking system, you wouldn't know. Complaining about Resharper is like complaining about the laws, or the cops. It's a system that by definition is there for good. Instead of waiting for the compiler to bomb out, you can get a warning instantly.

I like the ending phrase though. Good developers are not defined simply by the tool they use.

Now my post is not as polished as Mark's but I hope my point will be understood.


Popular posts from this blog

Sitecore Social Connected 1.3.0 Add Account issue (fixed)

Крачка назад във вечния танц