In the Spring of 2008, I decided to become a brownfield development specialist. Greenfield development is when you're starting a project from scratch and get to design everything with only minimal constraints. Brownfield development is the opposite of that: it's when a project is n months into development and most of the constraints have been cast in stone. My guess is that if you were to ask every developer you know whether they'd prefer to work on a greenfield project or a brownfield project that they'd all say greenfield. Heck, I'd bet that a quarter of them would laugh so hard that Red Bull shot out of their nose just at being asked the question. Therein lies one of the secrets of becoming a Big Swinging Developer:
You can make money being good at things that other people hate to do. A lot of money.
When people hate to do something, they don't do it very much. Since they don't do much of it, they never get particularly good at it. This makes it harder for them to do it and the cycle starts all over again. Some common values of "it" for development include: writing tests, documentation, and creating installers. You can safely add brownfield development to the list since a job description of "Support the big ball of mess that runs our business while adding features and fixing bugs" doesn't usually have folks banging down your door. Throw in the fact that you'll have no relevant documentation and few, if any, tests to guide your way and you can picture weeks of pestering your co-workers with questions just to get to the point where you can fix a simple defect.
But what if brownfield was easy for you? What if, rather than pestering your co-workers with basic questions, you could understand what the code was doing and then ask why it was doing things that way rather than asking what it actually does? That's what my secret weapon, Visustin, gives you. You paste in your source code and it'll generate a flowchart for you:
It supports 31 languages including the popular .NET, open source, and SQL variants. I spent last week throwing hundreds of lines of Python into the tool and tracing through an incredibly complex financial trading system to learn how portfolio valuation is calculated. I was able to correctly describe the process to my team lead, including a couple gotchas buried in the code even though I don't know Python. Since I know how the system works, though, I can find the path the code will take and identify where problems are likely to occur while coming up to speed on the language at night.
If you're a developer, I'd highly recommend Visustin. It's great for code reviews, documentation, and for diving into existing systems. Developer or not, look around your industry and find the important things that no one wants to do because there's a real opportunity there. You can become better (or more tolerant) than anyone else simply by identifying the key aspects to the unpleasantness and solving that problem first.
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.
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.
Every developer knows that unit tests are a good idea. Most developers know that using version control is a good idea. Some developers know that a "one-click" build is a good idea.
As you walk the aisles of the programming section at a bookstore, or browse the online equivalent you’ll see knowledge galore. How-to, what-to, why-to out the wazoo. With all this knowledge so readily available, why aren’t there more good or great developers?
The Big Swinging Developer is rarely judged by knowledge alone. As always, you have to be at least "good", which involves knowing a thing or two, but it’s your beliefs that will set you apart from everyone else. I happen to believe in isolating changes/problems, repeatable builds, and testing. Because of these beliefs, I’ve learned a lot of techniques to help me practice them.
I’ve been working on a web app this Memorial Day weekend. I’m a development team of one. No one is watching me, checking up on me, or even working with me. I have a one-click NAnt build that deploys to a Virtual Machine and have been branching my releases in my hosted Subversion repository.
You practice your beliefs because you can’t imagine doing things any other way and that defines you as a developer more than any single technology or language ever can. So, what do you believe?