This blog is dedicated to those fellow developers who look down at documenting.
It is perhaps a platitude that developers are mere binary thinkers. The only thing that they care to think about is whether the flag is set or not. Does my program compiles successfully or it doesn’t? Is the production system up or crashed? Are the clients satisfied with the code change or they’re not? It’s all just Black & White in their world.
Now, don’t get me wrong. I’m a developer too, and have been so for the past 5 years. Somehow my fellow developers feel that it’s all bull to document & to follow quality process. They don’t consider it to be what they call as ‘Real Work’. It’s all a waste of time & effort for them. They whine & crib endlessly about the volume of documentation to be done & process to be followed. Simply working mindlessly, figuring out logic based on the functionality alone doesn’t define ‘Real Work’.
This isn’t even the worst part. They freaking smirk & look down at people who do these stuff. They think documenting & following process don’t require any talent. Well, I agree. Yes, I do. Documentation isn’t rocket science. Then why in the bloody hell can’t you do it when a High Schooler can do a better job in it than you.
Developers are so lazy bummed that they make the company hire technical writers to do this job. Now, this is where I come in. This is why I too feel the pain when people smirk at Tech writers. Yes, apart from being a developer, I’m now a technical writer for yet another company’s development team. Hah... I know I'm sucha Kick Ass! B-)
When you develop all you gotta do is figure out the logic, put the right syntax & make sure it works under all cases. But when we do documentation, however, none of these same binary flags being set successfully are present. Instead, measuring the success tend to be more subjective, & require your judgment, rather than simpler logical conditions. We have to make sure that these documents contain sufficient information, so that when you aren’t around, another fellow developer can understand the case & clean up your mess!
Now, let me spell it out for you. Say, you are assigned with a production problem. I know that you will figure out the code that causes the bug. The more likely changes are the coding was done by someone who is now happily married and vacationing at Hawaii. Well, let’s face it. Even after finding the cause of the bug, without proper documents you are still in the middle of the freaking desert! Hah, this doesn’t end here. It gets better and better as your oh-so-totally-not-busy onsite manager would’ve have already sniffed known that you have landed yourself in knee deep of crap that he keeps ignoring your calls. In my experience, I can bet 1000 bucks that these mishaps find their way to you mostly during the holiday season. Beat that!
So, now that I have rested my case on why documents are more important, I personally think that documents prepared by the developer themselves are richer in content & insight than those prepared by the tech writers (Doesn’t apply for tech writers who are developers too. *Wink* *Wink*). For a developer to do no documents is trouble free. For a developer to fill out a Word template for every single deliverable called out by a process is also easy, in the sense that it doesn’t require much judgment.
But to come up with just enough documentation, though… that is hard! This is one reason why CMMI-based process effort frequently goes astray. I wish my quality facilitator reads this blog. It would be awesome. I bet he/she will be super impressed with me that she will let me go without any findings in the next audit. A girl can wish, you know... ;)
P.S: And HELL NO, you don’t look this Delllllllicious when you smirk. Humph.
When you develop all you gotta do is figure out the logic, put the right syntax & make sure it works under all cases. But when we do documentation, however, none of these same binary flags being set successfully are present. Instead, measuring the success tend to be more subjective, & require your judgment, rather than simpler logical conditions. We have to make sure that these documents contain sufficient information, so that when you aren’t around, another fellow developer can understand the case & clean up your mess!
Now, let me spell it out for you. Say, you are assigned with a production problem. I know that you will figure out the code that causes the bug. The more likely changes are the coding was done by someone who is now happily married and vacationing at Hawaii. Well, let’s face it. Even after finding the cause of the bug, without proper documents you are still in the middle of the freaking desert! Hah, this doesn’t end here. It gets better and better as your oh-so-totally-
So, now that I have rested my case on why documents are more important, I personally think that documents prepared by the developer themselves are richer in content & insight than those prepared by the tech writers (Doesn’t apply for tech writers who are developers too. *Wink* *Wink*). For a developer to do no documents is trouble free. For a developer to fill out a Word template for every single deliverable called out by a process is also easy, in the sense that it doesn’t require much judgment.
But to come up with just enough documentation, though… that is hard! This is one reason why CMMI-based process effort frequently goes astray. I wish my quality facilitator reads this blog. It would be awesome. I bet he/she will be super impressed with me that she will let me go without any findings in the next audit. A girl can wish, you know... ;)
P.S: And HELL NO, you don’t look this Delllllllicious when you smirk. Humph.
Wow...sissy ur blog luks amazing