My friend, Dave, and I have been talking about this, well mostly him, but I think it is an excellent question and has really got me pondering it lately.
Basically the question is this "Should you (ab)use tools/plugins for visual studio or use only what VS offers." More or less thats the question.
The thought behind this is that as a developer, when you use the tools and plugins from a third party, more times than not you are reliant on it and when it comes time to do the same or similar tasks, lets say in an interview, you are helpless without the tools. Example, CodeRush and Refactor Pro!. The shortcuts and auto-generated code that this tool provides are amazing, but if you use it religiously, you may not remember how to write basic code by hand.
So that's what brings me to the question, should we, as developers, continue to use the tools religiously and not learn/practice what is available from a standard VS install or does it not matter.
Does my question make sense? (sorry, if its confusing)
views:
498answers:
13If the tool makes you more productive, why cripple yourself by continuing to do things the hard way?
If you take the argument to the extreme, one could say that the .NET Framework is just a tool... why not do all your programming directly to the Win32 APIs instead of getting too comfortable with the amenities provided by .NET?
I'm totally open minded to all tools available - particularly well built timesaving ones. Ignoring the tools that are out there through some adherence to a dogma seems a bit pointless to me.
Visual Assist is invaluable in my opinion. Without it, it kinda feels like without one hand.
You should use whatever tools to get your job done efficiently and with minimum effort required. Compare: if you need to find a symbol with phrase you would use 'find' in VS while VisualAssist has dedicated quick-access list. Or VA can open a file for you from whole solution that you know part of the name - no need to browse whole solution.
So yes, use them as much as you can.
I think you are muddling the difference between a tool and library. For example if your application relies on a third party math packages then you will be face long terms problems if that vendor ceases to exist. The most important of which is the lack of upgrades when the next version of the framework, compiler, IDE, etc comes out.
However something like Refactor! is a tool that improves your productivity. It doesn't produce anything that is dependent on it's presence. In my book there is no reason not to use it.
Of course nothing fits into neat little boxes so there are a lot of add-ins that straddle these definitions in this case you will have to use your best judgment.
If the tool makes you more productive, by all means use it.
You will spend very little time during your career interviewing compared to the time you will spend developing, so there is no point in optimizing for that case. As long as you maintain a working knowledge of the API calls - not relying on intellisense too much, you should be able to do well in a programming interview.
I consider that part of any job you want to well is testing and selecting the best tools to carry out the job.
For .NET development most people are tied to Visual Studio, but the range of third-party tools available is quite good. For instance, I find that the Resharper add-in greatly enhances my development experience and helps me produce better code quicker.
For me these benefits far outweigh concerns about becoming dependent on the tools.
Use the tools. I believe the ultimate goal of a developer is to generate working code as quickly and efficiently as possible. Why not use tools that help you be more productive? If you were a carpenter, would you refuse to use power tools because you weren't sure what brand of power tools might be available on your next job?
Actually, a much better argument can be made for not using VS at all, for basically the same reason: most programmers today are far to defendant on Intellisense to progrm without it.
Should we go back to doing all our coding in Notepad?
Well, haha good point ahockley, but thats not exactly where I was trying to go with it.
I agree with you about using tools to make yourself more productive. I personally use many tools. However, where i meant to go with this is the effect of relying on the tools to do the job and not actually (possibly) understanding what is going on behind the scenes or learning to do the same task by hand for certain situations, such as an interview.
Let me put it to you this way, if I was an interviewer (and this is a lame example) and you wanted to write out a class with X methods and Y of them are static and the class has Z properties. Now, lets say you have used CodeRush for so long that you dont remember how to write a property or make a method static by hand, and since the only thing available to you during the interview is the fresh install of VS, you can't do it and you fail the interview, dont get the job, lose your house, your wife leaves you, the children change their last name, and you are sent to Mars....ok a little extreme, maybe, but I hope you get my drift.
Tools are great when they make you more productive by eliminating (or at least simplifying) the hard to do stuff (things like alphabetically sorting your methods, determining what using directives are not needed, refactoring, etc.).
When the tool becomes the primary method for doing "mundane" things like writing the structure for a property, making a method static, etc. then you end up becoming less productive in general and really become encumbered by your toolset (and limited to environments that support that toolset). I've known several people who were heavy CodeRush users (making heavy use of the keyboard shortcuts). They were extremely productive and could write code a lot faster, but only when sitting at their own machine. As soon as they needed to use a different machine they were lost without the shortcuts.
I think the difference is how you use the tools. Most productivity tools do not affect your understanding of the code. They merely help you get from point A to point B faster. The tools I tend to caution are code generators. Use code generators/designers only if you really understand what the output code is doing. If you use these kinds of tools as a crutch without understanding the functionality behind them, then no, you aren't going to ace that interview (nor be able to effectively fix/debug problems).
I would have to agree with what most everyone has been saying; tools make you more productive.
You can take that win32 example much further of course. We could go back to writing code in binary on punch cards. But most technology is built on top of other technology, that's just the way advancement comes about.
Sure intellisense lets you forget the exact names of methods, but it let's you use your memory for more important things like abstract concepts and design patterns. I've just run into too many 'certified' developers that didn't know what passing by reference was. How did they get those certifications, by memorizing tons of function names. So what, I still have to explain to a bunch of them that when you modify values on an object, all of the references to that object can see the changes. I'm not saying a good memory isn't valuable, just that there are more important abilities to have.
As far as interviews go, if not having my tools during an interview turned into a make or break issue, I'm probably applying to the wrong job in the first place. Maybe the job is a language lawyer sort of position. Maybe it is above my experience level. Maybe they want someone that already knows more Java or PHP than I do because I'm mostly a .NET developer. But for most software development positions, the worst questions you can ask candidates are of the "what function do you use to capitalize strings in C#," variety.
You can always look up how to create a class method again. You will probably have to relearn that skill several times for different languages if you stay a programmer for any length of time anyway. Knowing what makes a class method different from an instance method is much more important when I interview candidates.
Look at any other "engineering"-type discipline. I can't say software engineering because there P.Eng's out there who would beg to differ. I digress, that is a whole other discussion.
All disciplines use tools to augment tasks. Maybe not completely replace tasks, but to generate the basic template you can fill in. In programming, there are universal truths. You need to recognize these, and apply the correct tool, knowledge, or template to solve the problem.
There are repetitive tasks and there are thinking tasks. If you can automate repetitive tasks which are more error prone (due to their boring nature), then use of a tool is a good thing (reduces or eliminates mistakes). If your thinking tasks require a tool to generate, then perhaps you need to rethink what you are doing.
OK, so how does this relate to visual studio? VS provides the basic set of tools. VS is analogously to a basic cook book. It gives you the rudimentary tools to solve most programming tasks (independent of time). However, there are tools created by people to speed up those tasks, or in some cases, a better cook book.
The reason many of us use these tools (CodeRush, Refactor Pro, Resharper) is because we understand what we are doing, or we want to learn, and autonomous nature of these tools provides us a mechanism to correct our mistakes on-the-fly. E.g. To type out thirty property setter is honestly a waste of time and is very error prone.
I'm not sure if that answers your question or makes any sense at all.
HTH
p.s. Intellisense was first implemented as a discovery tool...