Dating back to my days as a consultant in the waning hours of the dotcom era, there were two truths I came to view as fundamental:
1) Once you get to a certain point in your development as a programmer, the actual functioning of software ceases to be a mystery. The only mystery that remains is what to do next. You can pretty much build anything you can imagine, but how do you choose *what* to build next?
2) You can only do so much as an individual developer. To create something really meaningful, you need to work with a team. The whole is *truly* greater than the some of its parts.
These two beliefs fuel my interest in the software development process – tools, methodologies, processes and practices – particularly those that deal with development teams and collaboration. I’m always on the lookout for ideas that will help me choose my next project, and help me go about building it through collaboration and teamwork with my colleagues.
To that end, when I heard about the Software Best Practices Conference, I was intrigued. The title is actually a bit misleading… it’s more of a roadshow, with different speakers scheduled to be at different cities on different days.
I went ahead and registered for the Pittsburgh conference, which takes place tomorrow. I’m going to try to summarize some of the more interesting ideas here throughout the day.
If the conference lives up to my imagination, I may see about attending some of the dates in other cities… several of the upcoming conference dates are in cities within a reasonable driving distance.
I am currently living the two items you pointed out in this article.
1. While I am by no means an "expert" developer, I have gotten to where I can figure out a software solution for a client problem pretty quickly. But for most of the work I do it is following the same kinds of development tasks, and truly "new" development is few and far between.
2. I’m a one-man band here at my job: UI, graphics, database, processes, QA & testing, application design. I’m a jack-of-all-trades, master of none, so to have colleagues with specific strengths would be nice, but its a true luxury. And in true Socratic fashion, I know exactly what I DON’T do well, and would benefit from a team environment.
During my current HR development plan evaluation, a big theme was to develop real processes for my job, and to improve my management skills. Something like this (though seemingly intimidating for a non-management guy like myself) might be helpful to those ends. Thanks for sharing it!