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.
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.
Being a Big Swinging Developer is kind of like being a chef in a professional kitchen. There’s a lot of pressure, a lot of money on the line, and a lot of cursing. One of my favorite analogies from the cooking world is knife work and the difference between professionals and home cooks.
The key to not cutting yourself in the kitchen is to keep the knife from making unwanted contact with your body.
The home cook approaches this problem by eliminating the "contact" portion of the equation. They’ll cut slowly and deliberately in order to keep the knife away from their fingers. If you’ve ever watched a professional, however, you’ll notice that they put the blade against their knuckles and can cut very, very quickly while keeping all of their digits. Professionals remove the "unwanted" portion of the equation. Why does this matter? Because professionals cut all day long and the better their knife work is, the more they can accomplish.
A defect is incorrect code that gets released into the wild.
There are two parts to this equation as well: Don’t write incorrect code, or don’t release it into the wild. The beginning developer will take the first approach with the thought that writing great code is what it’s all about. The seasoned developer knows that releasing great code is what it’s all about and that mistakes happen. This is why unit tests, continuous integration, one step builds, etc. are so important: the more test shots you get, the more defects you’ll catch, and the better your released code will be. These tests and builds need to happen in isolation –on private branches, for example– rather than occurring in the wild. The ability to use your version control system well is like being a chef with strong knife skills: you’ll be able to experiment more, build more, test more, and simply do more than the developers who are too afraid of cutting themselves.
So learn your tools and use them with confidence. Move faster (and more safely) than everyone else and you’ll be a Big Swinging Developer in no time.
I talk a lot about the non-programming aspects of software development since I think that they have the most impact to a good programmer’s career. I try to remind readers that you have to be "at least good" as far as programming goes to become a Big Swinging Developer. This doesn’t mean that I think that developers shouldn’t be constantly building and honing their programming skills.
A post on ReadWriteWeb entitled Top 10 Concepts That Every Software Engineer Should Know reminded me why I focus on the non-programming aspects: Other folks already have the programming aspect covered pretty well. I really liked their list and their reasoning behind it. It’s definitely worth a read and even if you don’t agree with it completely, it’s likely to get you thinking about what you know and what you want to learn.