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.
Do you know how to solve a Rubik’s Cube? If not, click the link in the previous sentence and take a quick look.
Ready?
Okay, now look at the picture of the cube on the right. Does it look as messed up as the project you’re working on? And yet both are solvable, and in remarkably similar ways.
Get To A Known Good State The first step is to go from utter chaos to something that looks more familiar. For the cube, some use a 2x2x2 corner, others use a cross. On projects, some developers fill in unit test gaps, others automate the build process.
Have A Logical Progression of States After you get to a known good state, there will be a next step. And a next. And probably several other states before reaching completion. The way in which the cube is scrambled has no effect on the order in which it will be solved, it simply affects the work that must be done to get to each state. Likewise, every project is troubled in it’s own special way — although there are certainly recurring anti-patterns — but you’ll still help move it through the same states.
Know The End State It’s easy to know when you’re done solving the Rubik’s Cube and that’s one of the reasons that solving it using different techniques from different starting points is still a repeatable process. Conversely, many projects fail because the people working on them don’t have a clear definition of what it means to be done.
So take a moment to step back from what appears to be a jumbled mess and decide what state it needs to be in next — regardless of what it takes to get there. Then the next state and the next, all the way up to a clear end state. Once you know how things should look along the way, it’s a lot more clear what you need to do to get there.
In the last post I revealed that the key to becoming a Big Swinging Developer was to realize that you’re now in the sales business (don’t worry, it’s a part time gig, you still get to code) and covered the importance of The Ask. Another aspect that’s covered in sales training is Overcoming Objections. In the world of the Big Swinging Developer, there are 3 main objections to overcome:
It’s too expensive
It’s too much work
It’s too risky
There are likely to be other objections that are specific to your situation that are often given the blanket label of "Office Politics". We’re going to ignore those for the time being — like a Physics teacher ignoring mass and friction to teach a more general concept.
The objections above are listed in the order in which you’ll need to overcome them. In a business setting, if something is too expensive, it’s simply not going to be approved. If something is too much work, that has a loose correlation to being too expensive because the person responsible for approving the work will do a rough calculation in the wages required and throw back the opportunity cost objection. Risk is the most nebulous objection on the list because it can mean anything from risk of losing money (see also "too expensive") to risk of looking foolish.
As with most posts in the Big Swinging Developer series, there is a key to the solution:
Whenever possible, take on the burden yourself
"It’s too risky" doesn’t hold water once you have a working solution or, in some cases, a prototype. "It’s too much work" isn’t a barrier once the work is done. That only leaves "It’s too expensive". This is where our final sales lesson comes in:
Sell money
Do you need a software component? Don’t ask for it because it’s really cool and easy to use. As for it because it will save 20 hours of development work and costs less than 20 hours at the average developer rate. This is a reversal of the previously mentioned opportunity cost argument. A faster build machine (or, even better, a farm) won’t necessarily be purchased to make your life easier. There’s a much better chance of getting the funding if you can show the benefit in monetary terms. Of course, before you ask you should drive the chances up even higher by using a trial version of the component or setting up a prototype of the build system on your own. By taking on the burden, you’ll remove the risk and the fear of it being too much work and it will put you in a great position to sell it as money.
It’s free, it’s almost no work, and you can cancel anytime: Use the link on the left to subscribe so you don’t miss a single post!
