Unknown Pain/Gain ratios

It is really funny. The best thing I like about my job is that I have to follow no process. But then the worst thing is that nobody else follows it either :-)

I love to not to have to look up pages of coding guidelines, just to figure out where the semicolon should be placed, when all the code reviewers do is point out the mistake in the variable naming convention, column width and indentation. But then without a coding guideline, I can barely understand what other folks have written.

I hate to have to update the High Level Design everytime a data structure changes or I modify the order in which they are initialized. But when I get into a new project, that is the first document that I need, and I hate the fact that the Design is so out of date and code, and only code will tell me what to do.

I hate to create a new branch in source control for every bug fix that I make. But when the build breaks, the first thing I want to find out is the list of files that were modified as a part of this check-in. This is the only way I can find out what the problem could be with the code.

I hate to run all the tests after I have put in my fix, but everytime I hit a problem in someone else's code, the only thought I have is "Did he even run the basic Sanity tests before checking in?". It would have saved me so much time that I spent debugging something that could have been caught by a simple test.

Now to make a decision on whether to follow the process or not, what you need is a PAIN:GAIN ratio. A manager will always say the it is <1>1. I am still alive with and without the process and I have had project which have bombed equally with or without process. So I don't know what to think.