The Role of Experts
My day job (when I'm not out fighting crime at night, of course) is as a Java software consultant, working at a variety of businesses in a variety of shapes and sizes. I've been fortunate in that most of them have used Eclipse as their development environment of choice. One of the things I have noticed over time is that there are basically four types of Eclipse users: those who use it because they have no choice (and lament the entire process), those who use it to develop but don't take advantage of it (it's just a glorified text editor, after all), those who get by fairly well (they know some of the keystrokes, they can run build scripts, and they are fairly proficient), and then last those who are enthusiastic Eclipse users. They are always exploring what else Eclipse can do for them. The last set of users are the ones who can truly take advantage of Eclipse, and more importantly, guide the direction the company takes with its adoption of Eclipse functionality.
Company policy plays an important role in the adoption of technologies. I think that Eclipse is often an easy choice for companies that don't want to spend a significant amount of money on tools for developers up-front; Eclipse looks really good on the bottom line. What companies need to be aware of, however, is that a tool as complex as a modern Java IDE really needs more than just a ZIP file out on a server somewhere that developers can download and install. Developers can get weeks of training for using a web server, but rarely get the training necessary to truly utilize their IDE.
A recent client I've been working at has an internal requirement that all open-source technologies used should have a 'guru', or an expert that can be a point of contact for other developers during the development process, and can also help dissect problems in the use of the open-source library (looking for bug entries, working through quirks, finding work-arounds, etc). It's certainly a legitimate policy for managing the consumption of open-source software in the company. What is most interesting, however, is that they don't require an expert to be on staff for Eclipse; only for open-source software that is actually released in their products.
So, why would a company want an expert for an IDE?
Well, first, let's talk about the relationship between the expert and the other types of developers. Perhaps the most critical relationship will be the one between the expert and the Eclipse nay-sayer. An expert can go a long distance towards converting this type of developer into becoming yet-another-Eclipse-fan. All too often, disliking a tool comes from not understanding it. The best way to convince someone that Eclipse is a great tool isn't to argue merits, but to show them Eclipse's strengths through real-world use. In the same vein, the developer who hardly uses the tool's abilities at all is probably avoiding it for the same reasons; they are probably afraid that Eclipse will impede them or get in their way, rather than assist them to do their job. Once again, knowledge and awareness is key. The third set of developers, the semi-casual users, is unique. These are developers who already have some form of enthusiasm for the strengths that Eclipse offers them, they're already using some of its features (and may be addicted to using them), so they generally will be more open to learning new and nifty tricks. They are just as likely as the expert to help evangelize the tool to others.
Importantly, an expert can create IDE familiarity and comfort across the entire development team, but that's not all. The Eclipse open-source community provides a lot more than just a Java IDE. Eclipse's community is quickly changing; new tools and technologies are becoming available through Eclipse every day, and many of them can be very valuable to companies. It requires someone with a keen eye to keep up with the Eclipse community, and truly know what the outlying technologies truly have to offer.
So, if you consider yourself an expert, what can you do? Let's say your company doesn't have the time or money to contribute to IDE development; does that mean that you can't help promote the 'appropriate' use of Eclipse to help maximize the productivity of the team? Quite the contrary. Write articles. E-mail links to articles. When working with other developers, show them your favorite keystrokes. Help set-up your Eclipse projects when you start new development. Talk with your management about some of the Eclipse technologies they're not yet using. All this effort can help small companies and large corporations alike, and it has the added benefit of making you the go-to-guy (or girl) for a key technology for your team.
EclipseCon is Coming...
On another note, EclipseCon is coming up ever-so-quickly. This will be the last EclipseZone newsletter to be published until EclipseCon hits (March 20th to March 23rd), so let me point everyone now out to check out the EclipseCon Site. While the most excitement will be for those of you who are actually going, there is bound to be plenty of material rushing into sites all across the internet for those of us not going. I for one will be consuming it up greedily. Thanks for tuning in!
Until Next Time,
R.J. Lorimer
rj@javalobby.org
|
Tired of dealing with Java code fires?
EZ News Corner
