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.
Have you ever been told that you’re a "real asset to the team"? If you have, it probably felt good at the time. Congratulations for making your mark and getting noticed, but I’m about to ruin the complement.
An asset is someone who gets things done. An asset is a reliable, sometimes brilliant, source of work product. Assets are often specialists and their value is easy to quantify — it’s the inverse of the cost of not having them. If you’re a database tuning guru, your value is roughly equal to the cost of having an un-tuned database. If you’re a security whiz, your value is roughly equal to the cost of having an insecure app. This is often how Big Swinging Developers get their start: they specialize and learn how to sell themselves by presenting the cost of not having them on board.
I see a few problems with this, such as:
Your employer may not see the same cost of the problem as you do
The problem may be mitigated in a way you don’t expect, which lowers your value
New technologies may make your specialization obsolete or devalue it significantly
This is not to say that having specialized knowledge is a bad thing, it’s just that banking solely on that specialized knowledge is the way to become a Specialized Niche Programmer.
To become a Big Swinging Developer, don’t be an asset – be a force multiplier.
Which do you think is worth more to a customer: "I can tune the heck out of your database" or "I can help your project get done on time"? How about "I can write great multi-threaded code" vs "I’ll make the entire team more productive"? Once again, it’s not that database tuning or mastery of the black art of threading aren’t valuable – they are. In fact, you need at least one or two such skills to get your foot in the door. The point is that once you’re in the door, and once you’re humming along on the tasks that you’ve been assigned based on these skills, that’s when the truly valuable work can begin.
Not sure how to be a force multiplier? Subscribe via RSS or email and you’ll learn how.
