"I like to code, I like new technology, I have a weird fear of documentation and I do everything in my power to avoid the politics of management"
The first few projects I was on were awesome. I was learning so much! Over time, I become more aware of the various properties a project had, and learned to place a project on a spectrum of good/bad:
"I get to use the latest technology? I love that, so let's nudge the needle to the "good" side, please! Oh, but I have a complex, 30 page requirements document I have to follow? I hate documents, so we'd better put the needle back where it came from..."
Most developers I have talked to do this, and it's normal. Nothing wrong with it, just the way it is. I do the exact same thing myself.
...Except, I'm trying to become a consultant. I'm somewhat dissatisfied with the projects that I'm getting, but if I want to complete my transition to consultant, I must learn to work on any project, in any environment.
Let's examine the process a bit. When evaluating a project, I collect information about it. Each piece of information becomes a property used to describe that project ("VB6 app", "agile", "highly contentious"), and then pass those properties through a filter where I determine how to feel about them ("boring", "easy", "honorable"). I weigh the values I get and assign a blended score that I assign ("good", "bad).
When the client asks "what's it going to be like to add some extra functionality?", I bring all those feelings and opinions to the table. Sometimes, who does the work tends to determine the solution, since I might try to minimize the amount of time I have to spend with VB6.
The Real Issue
So what's at issue here? The issue is that I'm making this about me when it's really not. I'm not paid to hold opinions based on personal beliefs and desires. In fact, I'm paid not to. Objectivity is why a company brings in consultants. By holding personal beliefs about a project, you are, by definition, violating that objectivity.
What if we instead, when evaluating a project, stopped right before we passed the properties through our filter. Isn't the project in a much more "real" form? Aren't the properties more objective?
What if we listened to those properties? What if we inferred knowledge about the client from the project? What if the fact that the project is in VB6 means something about the organization? What if we made that a statement about the people themselves?
What if we passed those properties through a filter, but not one of our own making? What if we painted every property as "valuable", or "necessary"? What does that say about the organization now? What does it say about the people?
If we can modify our evaluation process, playing with the filters we put a project through, it really becomes something new...
I feel this has gotten a little too rhetorical, so I will state some opinions on this matter, ignoring the irony therein:
- A project isn't good or bad. A project is.
- A project exists because it results in a net increase in value. If it did not, it would not exist.
- A project has the attributes it does because those attributes are the ones that serve the organization best.
- A project is a mirror of the organization and the people that make it up
Bringing It Home
So how does this relate back to my satisfaction? Quite simply, it's important to not judge the project or the organization, but instead realize that you are in the position you are because you are an observer to the problem. If you want to truly help an organization, you must be able to see past your own thoughts and see the problem you are trying to solve as it exists in reality, which includes how it fits within the organization. Once you do this, you are better equipped to provide help. Helping the client in a more real way is, so far, the best way I have found to bring satisfaction to my life. Help them, help yourself.