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.
I know a lot of developers and most of them are "binary" people: They tend to see things as right or wrong, good or bad, elegant or kludgey.
In addition to (or perhaps due to) being binary, they have an opinion on just about everything: .NET vs. Java, emacs vs. vi, MacOS vs. Ubuntu.
Having these opinions and practicing a geek form of the Socratic method serves us very well in the technical portion of our lives. The best programmers I know have both the depth and breadth of knowledge required to support their position against all other arguments. The best developers I know are the ones who know when to be quiet.
One of the secrets to being a Big Swinging Developer is to know when to be null. The realization that you don’t have to be right or wrong is not only liberating, it’s a great boost to your career. The key here is balance. On one extreme you have the folks who jump into every discussion within earshot. At some point they usually get labeled, "likes to hear himself talk". The other extreme is people who literally say nothing. They stop getting included in important discussions because they offer no value. So how do you strike the balance? Start asking yourself if what you’re considering saying will be valuable to anyone other than yourself. Is it actionable? Is it something that needs to be said? Is it relevant? Is it inspirational? The definition of "valuable" will change depending on the context of the discussion, the important thing is to think before you speak.
"Make something people need and you’ll make a living. Make something people want, you’ll make a fortune."
There are lots of developers out there with "job security". You know the type: they’re the ones that know all the system trivia. They’re the keepers of the system’s oral history and when something extraordinary needs to be done with the system, they’re who gets tapped. These developers usually find themselves in this position due to lack of documentation, bad design, planning failures, or some combination of these and a dozen other things. In some situations, they become a "required" component to keep the system running. This may seem like great position at first, but try taking a vacation or getting promoted when you are a required component: at best it’s not fun, at worst it’s impossible. Heck, even getting sick is more miserable if you have to keep things running while trying to recuperate.
While it may seem more risky, you’ll be better off if you’re desired, rather than required. Pretend that every development iteration is your last. At the same time, pretend that you are your own replacement and it’s your first day. What information would you want? Would you know how to find it? Does the body of documentation relay not only what the system does, but what you were thinking when you designed/built it? Does it build easily? Does it have good test coverage? How about a decent installer?
Having all of these things in place makes it a lot easier to transition to new/better opportunities. But that’s just the medium-term benefit. The short term benefit is that by keeping things in order, it will force you to work better and be both a better developer and a better employee. In the long term, your reputation will be well served by being known as the Big Swinging Developer who "does things right" and "leaves things in order".
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.