As the name implies, The Joel Test: 12 Steps to Better Code has 12 parts to it. That makes this the last parallel Big Swinging Developer Test question. Just joining the test? You can start from here and marathon it like an HBO series on Tivo.
The Joel Test: 12. Do you do hallway usability testing?
The Big Swinging Developer Test: 12. If you see a usability problem, do you treat it as a defect?
Check out the Wikipedia definition of usability. At the time of this writing the first sentence says, "…the ease with which people can employ a particular tool or other human-made object to achieve a particular goal." There’s a lot of other text that follows, but I think that the first sentence really nails what you should be measuring when you think about usability.
If we accept that definition of usability, then a usability problem is one that makes it hard for someone to use your software to accomplish a goal. Notice that this has nothing to do with fulfilling a functional specification or a passing a suite of automated tests. That’s what commodity developers do. If you see your job as writing code to fulfill a requirement or close a defect then you can easily (and cheaply) be replaced. If you see your job as building software to help other people kick ass then you’re well on your way to being a Big Swinging Developer.
If you’ve read at least a few posts on this blog, you’ve seen that it’s almost all about behavior . . . the behaviors that have helped me become a valuable developer. This seems like a good time to ask about what you’ve learned during your career. Even if you’re not a "blog comment type of person", take a moment to share some of your experience and wisdom in the comments below. Thanks!
If you’ve been reading this series, you know that The Joel Test: 12
Steps to Better Code is all about having an environment that leads to
better software. The Big Swinging Developer Test is a parallel that is
all about being a more valuable developer, but this late in the game
you’ve probably also noticed another pattern. A lot of the Big
Swinging Developer Test is about how to effectively help an
organization improve their Joel Test score and/or how to maximize the
effectiveness of their Joel Test items.
The Joel Test: 11. Do new candidates write code during their interview?
The Big Swinging Developer Test: 11. If you had to interview someone in 15 minutes, could you conduct a solid interview?
Even
if you never interview a single candidate, this will still boost your
value. As a Big Swinging Developer, the ability to conduct a solid
interview hinges upon 3 things:
Knowing what the organization wants/needs.
Knowing what you’re looking for in a co-worker.
The ability to determine if someone fulfills these two.
It’s
not easy to know what your organization wants or needs. It requires
research, thought, and an open mind. An open mind is required because
what the org wants may be different from what you want. If this were a
blog about startups, you’d see some very different advice from me
because at a startup the org needs what you need . . . otherwise you’re
in the wrong place. As a contractor, consultant, or simply a highly
paid employee somewhere you’ll find that meeting the company’s needs is
the winning strategy. Now before you start thinking that I’m
advocating organizational stasis, let me be clear: Sometimes the
organization needs a shakeup. Sometimes you’ll need a rabble-rouser, a
rebel, or a renegade. But that has to be based on what the org needs,
not what you want. If you find yourself in a place that is
change-resistant beyond what you were brought in to do, then factor
that in to your decisions. If what the org needs is unpalatable to
you, then it’s probably time to move on.
It’s easy to know what
you’re looking for in a co-worker, but it’s usually hard to articulate it.
We all have people that we’re drawn to, but it takes a fair amount of
reflection and introspection to know why and to be able to look for it
in others. I look for co-workers who are funny, excitable, articulate,
and curious (among other traits). I also know why I’m looking for
these things and how they’ll help us work together. I avoid people who
try to mask their lack of knowledge on something, have poor
communication skills, or overplay their hand. Give some thought to what you like and dislike in a colleague instead of simply being drawn to people who are like you or are just easy to get along with.
The idea of
candidates writing code in an interview (the original Joel Test
question) is great. So is a small, clear refactoring question that has
multiple correct answers. Ask candidates about previous projects,
especially what went wrong. Give them a chance to be the things that
you’re looking for and a chance to be the things that you’re trying to
avoid. If you deliberately walk them into (or near) the opportunity to earn positive or negative points then you’ll have a much easier time making your evaluation based on what’s important to you. Remember: It’s your job in an interview to create the conditions where the candidate can show if they’re a fit or not.
Even if you never use any of this to interview someone,
knowing what your organization needs, knowing yourself and how you like
to work, and knowing how to identify compatriots will make you
incredibly valuable. Put in the time for the research and reflection and you’ll be on your way to becoming a Big Swinging Developer.
One of the hardest things you can do is to get an organization to change. In periods of turmoil, change is inevitable and the hardest part of your career — getting those around and above you into a "we must change" mindset — is done for you. Those periods where everything is up in the air, or on fire, or crumbling around you are the ripest opportunities that you’ll ever see. But before you can thrive, you have to survive.
I recently talked to a friend who is about to downsize his team. The team is made up of some contributors and some cogs. As you might imagine, the cogs will be the ones to go. Not only that, but some of the cogs will probably be surprised since their work is fine and they work a lot. They are mistaking being a high quality cog with being a contributor.
So how do you know if you’re a contributor or a cog?
It’s actually pretty easy to know if you’re a contributor. If things are truly different (in a positive way) because you’re there, you’re contributing. If someone else who is as qualified and works as much had been doing your job for the last several months and put the project/team/department in the same place they are now, then you’re the definition of a workplace cog: an interchangeable part.
It’s pretty clear that we’re in a period of market turmoil right now. I can’t imagine any place that is going to be acting the same over the next 6 months as they were over the past 6. If you’ve spent time differentiating yourself, then you’ll be fine at either your current organization or a new one that’s looking to make a change. If you’ve just been plodding along, then you’ve put yourself in a precarious position to be replaced or removed. Get yourself out of that position ASAP and never be in it again.
What about thriving instead of merely surviving?
This is where it gets fun, if you have the stomach for it. While others are adopting a defensive posture, keeping their head down and trying not to get canned, this is a time to shine. Can you and a couple of other high-quality people replace a team twice your size? If so, you have an excellent value play. Can you, all by yourself, create a new revenue stream? Can you do it while fulfilling your existing duties? This would be a perfect time to offer your employer a near-zero-risk opportunity to bring in more money.
No doubt that things have gone pear shaped and it’s going to affect everyone. It’s up to you whether the effect is positive or negative. Things are in motion so now is the time to steer.
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.