I'm not big on resolutions, but every now and then I realize that something has to change.
In December of 2006 I started having the "something has to change" feeling. My career was going pretty well, but I always felt bogged down. I started thinking about what was in my way and I came to the conclusion that I was wasting time fighting with co-workers. It wasn't always head-on "2 developers enter, 1 developer leaves" Thunderdome style fighting, but it was fighting nonetheless.
I made a resolution to be more positive.
After telling one of my close colleagues about my resolution he replied, "Dude, you can be as optimistic as you want, this place isn't going to change."
I explained to him that I wasn't going to be more optimistic, that optimism is something you feel and it's VERY difficult to change how you feel. Instead, I was going to be more positive. Regardless of how I felt, I was going to look for the most positive action I could take and pursue it even if it went against my emotions at the time.
It was hard.
It was worth it.
The first month or two were difficult. The most positive action I could think of most of the time was to be quiet. To simply not say any of the cynical, cutting, or downright mean things I was thinking (regardless of how funny they were). A wonderful thing happened: Things stopped getting worse. When an argument or flame war broke out, I no longer made it worse. Things not getting worse is a huge step to them getting better.
My colleague was right: that place didn't change, but I did. In my next gig (where I am now), I practiced staying calm and taking positive action. I can assure you that after 2 years it is not only easier, but it is worth it. I would never have been able to advance to where I am now without my resolution in late 2006.
Being a Big Swinging Developer is about how you act regardless of how you feel. You are paid for your results and I can promise that you will get further faster if you start by being more positive. Give it a try and your workdays will be happier and more productive.
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.
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.
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:
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.
and something I read back on page 27 is haunting me: