I hear what you're saying, but we're supposed to be professionals and, at least in theory, we should not expect the IDE to be our co-workers' babysitter. From your anecdote, I get the impression that the vi guy was lacking proper judgment of his own skills rather than tools. Our language is standardized, so are building and deployment tools, and app containers. We have a variety of revision control clients. We have continuous integration. In this ecosystem of tools and standards, our job as professional software engineers is to not blindly conform, but to have the necessary skills, intuition, and foresight to make high level decisions about our own tasks and the team's work as a whole. Being good at vi does not a good developer make. Neither does intimate knowledge of every last algorithm. What does though is the combination of tools, research skills, and knowledge and ability to make informed decisions about how to use them.
Sadly, unjustified confidence about quality of own work is quite common in software and something we should all be cognizant of. Alexey ________________________________ From: Andreas Petersson <[email protected]> To: [email protected] Sent: Wed, November 24, 2010 2:34:44 PM Subject: Re: [The Java Posse] Re: But do people really refactor? Interesting discussion so far about vi/emacs vs IJ/Ecl/NB. There were lots of arguments concerning the PERSONAL productivity of a single programmer. For my part, i personally stick to IJ, i used that since 2001 (with a 1-year intermezzo in Eclipse) and has since not disappointed me. Previously i did not object if someone else used notepad/vi/emacs until I experienced working with them in a team: The problem i see is you have to look at the productivity not only of a single programmer but rather the combined productivity of a whole team. Some anecdotes supporting this: In one of my teams we had a single programmer insisting on using vi only. He was coding javascript with proclaimed 3 years of experience. After his checkins I opened IJ and saw 2 yellow and 3 red markings. Without knowing javascript i knew this was wrong and ideed those were errors, popping up in some corner-cases. Also some html tags were broken (like <div><span></div></span>) which would be trivial to detect and fix with a decent editor. In other situations a 10-person team coding Java everyone wrote auto-generated hashCode/equals methods, everyone was used to it. Except the "hardcore" guy wrote them by himself leading to bugs and furthermore he was dragging everyone down, because everyone had to re-check his manually written methods for errors, while they could rely on most auto-generated ones being correct. Also the practical method of keeping final immutable fields public rather than private with a getter becomes unhandy if you cannot rely on the fact that everyone in the team can trivially apply "encapsulate fields" as a refactoring. Convulated Naming conventions become obsolete if the IDE renders different types in different colors. (members, local variables, interface impl etc..). The same holds true for many other "modern" coding techniques which rely on good IDE support. my conclusion: In a team a single person not using top-notch tools can potentially harm the productivity of everyone. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
