Big Swinging Developer

The 3 Types of Value

Early in my career I learned that there are 3 types of value to an employer:

• Increase revenue (grow the top line)
• Decrease expenses (grow the bottom line)
• Reduce risk

In an ideal world your employer would understand and value all three equally and you'd be free to pick and choose what you work on in order to be most valuable.  Even if your employer could choose to be that balanced, the market wouldn't let them.  Instead, you have to read the tea leaves (or the corporate memos) to figure out what's what.  If you align what you're working on with what's most desired, you're in for a Big Swinging Payday.

Alright, that's the general rule.  Let's get a little more specific for the folks out there who write software for a living.  There's a development analog for each of the 3 types of value listed above.  In matching order they are:

• Increase capabilities
• Decrease effort
• Improve process

You increase your capabilities (and those of your group) by learning new technologies and tools.  This increases the range of what you're capable of delivering.  There are times when providing what couldn't be done before is incredibly valuable: typically at the start of a project or during project turnaround.  At the beginning there's a much better chance that new capabilities can be incorporated into the project.  This also happens when the project hits a, "We've got to change because what we've been doing isn't working" point.  Another way to look at it is that if things are moving along, don't risk getting in the way with offering something new.

You decrease effort by bringing efficiencies to the group that either didn't exist, or were poorly exploited.  The simplest way to do this is to automate the living daylights out of everything you can.  Automated builds, testing, documentation, etc. will help developers focus on the things that only they can do: write code to solve problems.  This doesn't mean that developers will end up working less, it means that given the same amount of time/effort they will produce more.  This is easiest to do at the start of a project (before things get messy), but is actually more valuable in the middle once bad habits and thrashing have begun.

Improving the development process is almost always valuable, but becomes particularly important between the middle and the end of a project.  This is due to the fact that from the middle to the end is the time when the project needs to be set up for maintenance mode.  If you wait until the end to do that then you won't have nearly enough time to get everyone used to the process.  In addition, from the middle to the end is when people will be rolling off the project and the level of talent should be constantly increasing until right before the end.  This is not to say that process isn't important until the middle.  Chances are that when a project starts there will be a period of process development that lasts the first quarter of the overall time.  Then people settle into a groove and crank things out for a while until they hit the halfway point, when it becomes time to plan for the end of the project.  By improving the process, you make development more predictable which lets those around (and above) you plan better and control the end-of-project glide path.

Notice that I'm talking about relative value at specific points the the project's lifetime.  All of these things are valuable and you'd be well off learning how to bring any of them into your organization.  If you want to really capitalize on them, though, take a look around and align what you're doing with what's most needed.

Why Should We Have Centralized Architecture?

I recently had a chance to discuss the role of centralized architecture with a colleague.  When I say "centralized architecture", I'm talking about a group usually found in large companies that is responsible for technology standards across the organization.  In talking with developers over the past several years, I've seen the full spectrum of opinions on central architecture groups: At one end you have the developers who are appreciative of the architects hammering things out so that the organization has a common direction.  In the middle you have the folks that have heard such a group exists, but isn't exactly sure what they do.  At the other end are the developers who see the group actively impeding their progress.

Given the wide range of opinions and reactions to the architecture function, I started thinking about what I would want such a group to do.  I finally boiled it down to this:

The role of central architecture should be to balance the desires of the organization with the desires of the developers.

There are plenty of places where the desires of the organization and the developers are aligned.  The org wants some software, the developers want to write it.  But from there, things get a little tricky.  The org prefers to standardize on certain products in order to reduce cost and simplify maintenance.  Developers want to use whatever they want to use.  Developers focus on their system, or part of the system.  The org sees their system as part of a larger system and wants to make sure it can talk to everything else when need be.  The list goes on and on, but an architecture group can resolve these differences by providing the structure with which technology gets built.  Not only that, they can help developers work outside of the general structure when it makes sense to do so and provide tools that make staying inside the structure desirable.

Building Software Is Easy

Thanks to the modern Integrated Development Environment (IDE), building software is easy.  I'm not talking about writing software, that will continue to be challenging for a while yet, I'm talking about the actual compile step.  Let's use Visual Studio as an example: Not only can you compile your code, but with the use of pre-build and post-build steps you can put all the work needed to build your software right there in your project file.  What could be more convenient?  In fact, it's so convenient that many developers never even question whether it's a good idea or not.

Building software well is hard.  A comment last week from Christopher Painter at DeploymentEngineering.com reminded me that I've wanted to write this post for awhile. It never ceases to amaze me that developers will go on and on about "loose coupling", "high cohesion", and "inversion of control" and then turn around to violate all those principles by coding deployment instructions into their project files.  We talk about loose coupling in development because it gives us flexibility and makes maintenance easier down the road.  Aren't those good principles in a build?  High cohesion is a nice attribute that essentially means "things that are alike are together".  Hmm, I'll take a shot of that in my build.  Don't even get me started on Inversion of Control.  The fact that a developer would accept the added complexity of an IoC container and then balk at the idea of using a separate NAnt script or MSBuild file for their build stuns me.

Here's a radical thought: Your build is software too.  Your build should adhere to the same principles that your software does.  Your build needs to be maintainable.  Your build should be self-documenting.  Your build should provide good feedback to the user.  Your build should be easy to run. 

So take a look at your build today and see if it represents your development principles.  Practicing what you preach (and doing so consistently) is the hallmark of a Big Swinging Developer.

The Skill I Wish All Developers Had

One of my team members recently said that he was looking forward to the day when everything runs in the cloud so he no longer has to do sysadmin work.  He said this at a time when he was configuring some VMs to create a test environment for our large enterprise application.  I didn't think much of it at the time, mostly because this guy is a really good sysadmin and the configuration was a little bit of a time sink but didn't really get in our way.

I started thinking about his comments more when a member of someone else's team ran into a driver problem.  He went from "it's not working right" to "I may have to reformat the box" in less than a half a cup of coffee.  This led me to thinking about some of the other teams and how they worked for more than 2 years using only a shared environment because no one felt comfortable enough with setting up individual environments.  To be fair, our environment isn't exactly trivial.  We have a mix of IIS web services, Tibco EMS, Oracle, and Active Directory.  At the same time, there's nothing really exotic in there.  These are not only standard technologies, but every one of them can be downloaded as a trial version online.

Driving home last night I realized that I wish every developer had basic to mid-level sysadmin experience.  The ability to not only set up environments from scratch, but to troubleshoot (in a logical way . . . one that doesn't start with, "Well, gotta set it on fire first.") and fix problems.  This skill also helps in a corporate environment since you'll either have to work within the network bounds, work around the network limitations, or both.  That ability only comes from understanding how things really work.

Being a Big Swinging Developer is all about being valuable in whatever environment you're placed.  If you have some sysadmin tools in your toolbox, you never have to be the one sidelined by what turns out to be a speed bump rather than a true block.

Leadership on the Line

As technical professionals, developers are often accused of ignoring human issues and focusing too much on the technical aspects of a solution.  Hugh MacLeod said it best:

I'm 1/4 of the way through the book Leadership on the Line: Staying Alive Through the Dangers of Leading and something I read back on page 27 is haunting me:

Habits, values, and attitudes, even dysfunctional ones, are part of one's identity.  To change the way people see and do things is to challenge how they define themselves.

Being a Big Swinging Developer is all about changing the way that people see and do things and that second sentence up there explains a lot of the resistance you'll face. It's not enough to show people what they can do, you need to show them who they can be.  For example, I know lots of programmers who love agile development techniques and have trouble getting others to follow suit.  This can lead to a lot of frustration as the Agiles think that the Non-Agiles "just don't get it."  I don't think that that's the case.  I think the folks who resist agile techniques do so because they don't want to be agile developers.  Really, it may be as simple as that.  Not everyone wants to code quickly and safely, or be able to change their mind, or do the things that agile techniques enable.  If you look at it that way then you start to realize that someone who codes slowly and (at least in their mind) carefully will view writing unit tests as extra work that lowers their productivity.  They may see putting prototypes in front of users before all the requirements are known as opening themselves up for (gasp) more work down the road.

If the view of people defining their identity by their habits, values, and attitudes is correct then the happier they are with their identity, the harder it will be to change how they see and do things.  This may explain why the multi-decade veterans stick to their ways while the freshly minted grad will try out whatever you throw at him.  It's not that the new guy understands better, it's that his identity isn't as firmly cemented which means changing what he does results in less of a change of who he thinks he is.

The next time you have an idea for process or organizational change, make sure that it either fits with who the organization is or who they want to be.  If it's going to be a significant departure then spend extra time painting the picture of who they can be if your change is adopted.  If you can't sell the idea of the new identity, chances are you won't be able to sell the technical aspects of the change.  If, however, you can make people want to be who your change enables them to be then you'll find yourself surrounded by support instead of resistance.

The Big Swinging Developer Test - Part 12

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!

The Big Swinging Developer Test - Part 11

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.

How To Survive (Or Thrive In) A Downturn

I have a confession: I love turmoil.

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.

The Big Swinging Developer Test - Part 10

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.

The Big Swinging Developer Test - Part 9

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.