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!
In the last post I proposed that the key to going from being a good programmer to a highly paid developer was a change in behavior. In future posts I’ll get into the nitty-gritty detail of what to do, when to do it, and how to know what to do. Before we get into the tactics, however, there are still a few strategy points to cover. None is more important than this one, though:
You are now in the sales business
Most programmers view sales and marketing with suspicion at best and, more commonly, disdain. Forget the people you’ve met form these departments for a moment and focus on the departments goals. The best description of marketing that I’ve read came from Seth Godin who said, "The job of marketing is to get people to know, like, and trust you." The job of sales is, quite simply, to close the deal. There are lots of books about sales such as The Little Red Book of Selling and it will help your career to read at least one, I’ve read several and they all have one thing in common: The Ask. This is probably the most important aspect of sales ever taught and in its simplest form it says:
You are unlikely to get something unless you ask for it
If you remember nothing else from this blog, please remember the line above. There is, of course, more to the sales process than just asking for the sale. The reason The Ask is so important is that without it, none of those other things matter. The future posts that talk about specific tactics are all geared toward getting a response of "Yes" to The Ask, but without asking for something, there’s nothing to say "Yes" to.
Are you shy about asking for things? You’re not alone, but by the time we get deep into the tactics section you’ll feel more confident about it and you’ll realize why The Powers That Be will actually appreciate you asking (Hint: It helps them figure out what you need. In other words you’ll be doing the hardest part of their job for them.)
Don’t miss a single post! Use the link on the left to subscribe by RSS or email.
This blog is dedicated to the career programmer – folks who make their living from turning nebulous requirements into working systems on a daily basis. If Joel Spolsky is right, and 80% of the software in the world is written for internal use, then chances are good that if you’re a programmer, you’re working in a corporate development group. The majority of programmers in corporate development fall into the "good" category so, once again, chances are that if you’re a programmer then you’re a good programmer in a corporate development group.
Chances are also good that if you’re a programmer then you are underpaid.
Actually, underpaid indicates that you’re not getting paid what you’re worth so technically you’re not underpaid – you’re simply not making as much as you can. The result is the same, though: less money is reaching you than could/should be. How do I know this? I’ve been a professional developer for more than a decade and in that time I’ve become a good programmer. Not superb, not fantastic, not even great. Just good. Solidly, smack-dab-in-the-middle-of-the-curve, no-better-no-worse good.
Despite being a merely good programmer, I’ve become a highly paid developer.
This wasn’t just a matter of luck, circumstance, or even "knowing the right people". I became a highly paid developer the same way you can: By changing my behavior. Being a Big Swinging Developer is all about behavior, not technical skills. You definitely have to be at least good and if you’re not then I recommend working on your development skills before putting ANY of the techniques on this blog into practice. Long story short, you must be able to walk the walk above all else. Being a highly paid developer is all about actually being more valuable than other programmers, but that means that you need to deliver that value reliably.
Are you underwhelmed by the generality of the "change of behavior = more money" revelation? Don’t worry, I’ll get much more specific in upcoming posts and show you how to see your job in a very different light. Use the link on the left to subscribe via RSS or email so you don’t miss anything!
Do you know how to solve a Rubik’s Cube? If not, click the link in the previous sentence and take a quick look. 
