Part 8 and part 9 were two of the toughest parts of being a Big Swinging Developer. It just so happens that part 10 is the easiest. So easy in fact that you can start immediately with no additional training, reading, or practice. If you’re just joining The Big Swinging Developer Test, start with part 1 to learn about the parallels to The Joel Test: 12 Steps to Better Code.
The Joel Test: 10. Do you have testers?
The Big Swinging Developer Test: 10. Do you treat testers as partners?
I like to think of a "development unit" as a subject matter expert (SME), a developer, and a tester. Put these functions together and you can crank out quality software. One of the benefits of creating products for yourself is that you are the SME. If you are doing medium-to-large scale development, however, chances are you’ll have one or more SMEs that you work with and they may be labeled SME, Program Manager, Product Manager, Knowledge Worker, or whatever term is fashionable at the time. If you’re doing contract work, you’ll almost certainly have an SME since you’re being brought in to build someone else’s vision. As for testers, while developers should always test as much as they can, if you’re doing anything other than "side project" work, you’re going to have a tester or test team to work with.
Over the past few years I’ve observed a strange and unfortunate phenomenon: Developers tend to partner with the SMEs, but they treat testers as second-class citizens. To me this is like saying, "It’s important to know what we’re trying to do, but not important for it to work well". You and your SME are responsible for delivering a product that meets the customer’s needs. You and your tester are responsible for delivering a product that works well. Every defect found by a tester is one that the customer won’t have to endure. How is that not valuable? A defect found and fixed should be celebrated just like a feature designed and implemented.
Okay, let’s leave the Idealismville for a minute and get down to some good old fashioned self-interest. If you partner with your tester, if you guys are "in it together", you’ll see fewer of those bullshit bugs that annoy us all to no end. You know, the ones that make you ask, "Why are you wasting your time on this instead of testing the real stuff?" Some devs may point to the bullshit bug behavior as the reason that they don’t respect their testers. Um, yeah, does, "He started it!" sound like something that should leave the mouth of a six figure developer?
The good news is that you can have it all: quality software, quality defect reports, money, and (until more developers start acting their wage) fame! All you have to do is treat your tester like a partner. Trust me, I’ve seen it both ways and you’ll be much more valuable and happy if you take the partner route.
Part 8 of The Big Swinging Developer Test introduced the one item that you couldn’t change: the working environment. Part 9 shows you the easiest thing to change, but it’s probably the most controversial entry in the list.
The Joel Test: 9. Do you use the best tools that money can buy?
The Big Swinging Developer Test: 9. If you’re not given the tools you need/want, do you buy them yourself?
If there was one "secret" that I considered holding back, it was this one. Other than my willingness to get up at ungodly hours of the morning, this technique has done more to increase my salary than anything else. I actually stumbled across this more than a decade ago, shortly before I went to Microsoft — who can, quite literally, buy you anything that’s for sale. I was working on several projects and I wanted to be able to work anywhere. This was before the age of cheap fast notebooks and my employer provided me with a desktop, but wouldn’t buy me a laptop. Crappy notebooks were pricey and decent notebooks were wicked expensive. Mine ended up costing about $5,000, which was a non-trivial percentage of my income at the time. That machine allowed me to do more than $100,000 of *extra* billable work before I retired it a few years later.
Ever since then I’ve been more than willing to buy books, hardware, software, stock images, and countless other tools. Development is a craft and while tools alone won’t make you a great craftsman, the right tool in the right hands is insanely valuable. There are other benefits to buying your own stuff: You don’t have to get approval, you don’t have to wade through the corporate purchasing process, you own the thing and can take it with you, and you’re more likely to use it since you bought it. Think of these purchases as an investment in yourself and watch what happens to your salary when you’re able to excel in an environment where others seem stymied. Remember: Any problem that can be solved by writing a check isn’t really a problem, it’s an expense.
I honestly wish that Part 8 didn’t exist. Question 8 of The Joel Test: 12 Steps to Better Code sits there pretending to be on par with the other questions, but it turns out to be in a league all its own. Here’s a quick recap of the subjects of questions 1 through 7 in the Joel Test and their Big Swinging Developer counterparts:
So what makes question 8 so different from all of these? It’s the one thing in the test that you can’t change.
The Joel Test:
8. Do programmers have quiet working conditions?
The Big Swinging Developer Test:
8. Can you get things done regardless of the working conditions?
At Microsoft I had an office that I shared with a designer. It was great. We were quiet except for the times when we both didn’t want to be. At BindView and Symantec I had a private office. It was even better. When I wanted quiet, I just closed (and possibly locked) my office door. At DuClaw I could work in any of our 4 bars, the brewery, or be at home. The bars, while certainly not quiet, were fun places to work and I could always go home when I needed quiet. My current gig, in stark contrast, is the single worst physical environment for programmers that I’ve ever worked in. It’s an "open floor plan" which fosters a "collaborative environment" whether you want it or not. I know plenty of programmers who would simply never work in this kind of office because they know how ineffective everyone becomes with all of the noise and the lack of barriers to interruption.
Being a Big Swinging Developer, however, is all about doing what others won’t or can’t and part 8 is the essence of this spirit. Reread the question, though. It’s not about tolerance or biting your tongue or just getting through. The question is "can you get things done regardless?", which is about adaptability and discipline. I’ve found that the open floor plan affects me less at 6am and on weekends, so when I need to crank things out, that’s when I work. I’ve also found that headphones, while not as effective as a door, are a key piece of survival gear when things get busy around me.
As I said in the beginning, I wish part 8 didn’t exist because programmers really are more effective when quiet is a choice. It’s also a shame that this is something that you just have to accept, like Houston weather or colonoscopies. Just remember: businesses choose open floor plans because they are much, much less expensive — and taxed differently — than real offices. Make sure that you can be effective regardless (and that they pass some of those savings on to you) and you’ll be a Big Swinging Developer that can work anywhere.
There’s a difference between "having a lot to do" and "being busy".
I almost always have a lot to do. I have a long list of tasks and projects that I’m interested in doing and I can productively work on that list at the drop of a hat. By the same token, I can usually stop what I’m doing and do something else if the need arises. There are certainly some tasks that require uninterrupted time, but those are easily accomplished in the "off-hours" of early or late. Most of the people that I enjoy working with structure their work similarly: they’re never "busy", but they are constantly making progress.
The people I least enjoy working with are the "busy" ones. These are the folks who feel buried by their tasks and often when asked to do something (and almost always when asked why something didn’t get done), their response is "I’m very busy". The worst part is that everyone seems to take being busy as a universal and unquestionable excuse instead of immediately responding, "Well how did you let yourself get into this predicament?". My friend, and never-busy-colleague, Jimmy C once pointed out that being busy is a choice just like being drunk is a choice. He likes to say, "Replace the word ‘busy’ with ‘drunk’ and see how much weight it carries".
"Sorry, I can’t help you out, I’m too drunk" or "He’s a very drunk person" or "I didn’t get to it yet, I’m too drunk".
Really takes the teeth out of the statement doesn’t it?
I’ve spent too much time over too many pints* trying to figure out why the busy people are the way they are. Poor time management? Unrealistic estimates? A need to feel more important than they are? Guilt over their bill rate? I finally realized that answering the question wasn’t productive, so I stopped thinking about it since I have a lot to do.
So stay productive and don’t get too busy too often.