One thing that gives me delight to no end is making tools that help people around me. I guess that's why I'm a software developer. Or, I guess, that's why I enjoy being a software developer.
I've worked on a few types of code generators to date, the idea of course being to save time when people have to do repetitious or monotonous tasks. Another big idea I've had was inspired by David Heinemeier Hansson's talk at Carson Workshops where he talked of the notion of convention over configuration (linked here in the context of spring, but a general enough design pattern). I thought: why not start with a bunch of conventions and, if need be, customize when necessary?
I've recieved two responses over the utilities I've written that seem to point to different philosophies regarding software development and how I win with some people and struggle with others.
The first was a developer who was excited when I showed him a utility for generating property stubs - a lot faster than using Visual Studio's class designer or code snippets. I could see that it was the idea that got him going, not necessarily the implementation because his following question was if he could have the source. This is no problem on my end - I always just ask for bugs people find and features they'd want so that I can put them in an updated version. Half of the fun is finding out what people want and then giving it to them -
The other response was from another developer who was a little bit more hostile to the notion of a utility that didn't come from a larger party (a company like Microsoft) and wasn't particularly interested in even seeing how the tool worked (let alone what improvements they'd want to make to it). In this particular scenario I prompted the person by asking if they were more interested in hand coding what needed to be done to which I got a quick but very sure nod.
I think the step further that makes these two responses interesting and sidesteps the question of whether what I've made is really all that good is that I know these two developers well enough to know that the first is a younger guy who is interested in open source - who prefers tools like Firefox and Thunderbird, and who has night projects - things he does on his own because he enjoys writing software. He reads technical articles and blogs. He is a familiar and enthusiastic user of RSS and syndication tools. The second developer is a "business" guy - less of a dreamer but very much a hard worker. When Microsoft (or big company X) releases a tool he uses it, and uses it as prescribed. He rarely has "time" to browse the web for leisure or interest. He also, and I think this is interesting, is the kind of person who keeps his Windows desktop as the default.
I think you can take these different archetypes and distribute them quite well - with varying levels of commitment, interest, and aptitude. The open source/mac/web world is full of people who are curious - who look at a problem or solution and think about how it applies to them. Moving beyond the open source "zealot" I see a lot of programmers like this - many in a non Microsoft sphere but quite a few avid Microsoft tool users. At the beginning of last year I thought of somehow trying to take ideas from the open source world and port them to the Microsoft sphere but it's been a delight to find so many people who use Microsoft tools who are still very passionate about technology, and the large contexts of problems and solutions.
On the other end of the sphere there are a considerable number of people who approach development without novelty, without interest in the process and more in a blue collar "just get it done" sense. Because the elegance and style are not important, it's best to go with tools that are proven by the majority - personal extensions and/or hacks are a waste of time because it counts against "getting the job done." People like this seem to have the ability to focus much more on the business or the task. That's why tool customization, hacks, and web reading (articles, blog posts, etc...) are beside the point. The point is the task. Create a XYZ. Write a method that stores ABC. Display MNO.
Of course with this divide I run the risk of upsetting people - especially the second developer (it's doubtful this blog post would ever be read, and even more doubtful that the person would guess themselves) but before I reap any backlash I want to say this: both the first and second developer are pretty effective at what they do because the nature of our work is constained by the type of software we write: big business apps that essentially boil down to CRUD (CREATE / RETRIEVE / UPDATE / DELETE). I think this sort of divide would show up a lot more if we were writing a web application framework, next generation web app, or a game.
It's not my goal to make anyone upset although even Microsoft's got the idea of different personas for developers - the question it leaves is where I can find that kind of nourishment from the first developer, even when an idea is too rough or unpolished to be useful. For people who work with Microsoft tools, without a doubt I think there's a great community in the blogosphere but even more so at conferences - a place where a guy like me can stop a Scott Hanselman and inquire as to this or that. But beyond the conference I think it has to do with (and this is very general) "open" tools and "vendor driven" tools. The open tools seem to have a community that collaborates and grows them - people who by nature are interested in making the process of software better and more enjoyable. People who have the audacity to think that a solution for them might actually help other people who are willing to give it a shot.