Every developer knows that unit tests are a good idea. Most developers know that using version control is a good idea. Some developers know that a "one-click" build is a good idea.
As you walk the aisles of the programming section at a bookstore, or browse the online equivalent you’ll see knowledge galore. How-to, what-to, why-to out the wazoo. With all this knowledge so readily available, why aren’t there more good or great developers?
The Big Swinging Developer is rarely judged by knowledge alone. As always, you have to be at least "good", which involves knowing a thing or two, but it’s your beliefs that will set you apart from everyone else. I happen to believe in isolating changes/problems, repeatable builds, and testing. Because of these beliefs, I’ve learned a lot of techniques to help me practice them.
I’ve been working on a web app this Memorial Day weekend. I’m a development team of one. No one is watching me, checking up on me, or even working with me. I have a one-click NAnt build that deploys to a Virtual Machine and have been branching my releases in my hosted Subversion repository.
You practice your beliefs because you can’t imagine doing things any other way and that defines you as a developer more than any single technology or language ever can. So, what do you believe?
Like other craftsmen, the Big Swinging Developer has an above average toolbox. When a problem rears it’s ugly head, the right program, utility, or plug-in is just a download away. Like a master craftsmen, Big Swinging Developers also realize that tools are there to perform a function and that there’s more than one way to complete a task. When you’ve reached this level of mastery, you stop complaining that your client uses ClearCase for version control even though you prefer Subversion. You’ll gladly work with Oracle, SQL Server, or MySQL . . . after all, databases are just a tool that let you work with data. You’re a fan of Infragistics, but they’re a Syncfusion shop? In the words of Tim Gunn, "Make it work".
This is not to say that you shouldn’t have preferences. And you should certainly put in your two cents when they’re in the process of making technology decisions. After the decisions have been made, however, it’s time to get down to business. Remember: It’s a poor craftsman who blames his tools.
One of the most important skills for a Big Swinging Developer to learn is how to focus. This is more than a matter of shutting the world out while slinging code. If it were that simple, then anyone with headphones could be a BSD.
To us, "focus" means pursuing the goal of shipping great software in addition to addressing all the other "distractions" that may pop up. Someone asking for help may seem like a focus-breaking request, but if helping that person makes the system better then it’s in keeping with the goal. Researching a new technology may be a huge breakthrough, or a huge waste of time.
I found myself in this position earlier today. I signed up to look at a new way of doing something in our system. After 30 minutes it became clear that the change (pretty much regardless of what it was) was going to be more time and effort than we could afford. This wasn’t the answer I wanted — I wanted a breakthrough. The problem was that even a breakthrough wouldn’t be worth implementing. This put me into a serious funk, but the alternative was to spin my wheels looking for (and probably finding) options that all had one thing in common: they wouldn’t be implemented and, therefore, they wouldn’t make the system any better.
It’s hard to stop short of solving a problem. It’s often easier to search and search and search until you’re told to stop, because then you can feel like the reason you didn’t solve the problem is because someone told you to stop. It’s easy to blame your predecessors, your vendors, or even your colleagues for getting the system into a state that you can’t "fix" within the given amount of time. But none of these makes the system better, so it’s your job to focus relentlessly by doing the right thing and getting back to the problems that have solutions.