This song is dedicated to the Fed balance shi– I mean sheet.

I read a rather enticing post from some other blog entitled 5 Best Things About Being a Developer. This post was enticing in that it was so shill, I could think to do no other thing in response to its content, than write: 5 Most Ridiculous Things About Being a Software Developer.  Apparently, the author had a few of his 5 Best Things happen the day he wrote it  up — how quaint.  These items I’ve scribed below are however, the things that happen to us software developers every day and are not quite as inspirational.

1. Writing Code That Works The First Time Maintaining Code That No One Wants to Exist

You know that script/program/library/object/method that you and your boss both hate.  It rears its ugly head time and again; it ruins perfectly good days.  No matter how many times you try to explain the need to scrap the code involved, no one’s interested.  Its either too time-consuming, too costly, or my favorite line of all time: “It opens us up to too much risk.”   That line should be followed by the Office Space-famed “Riiiight” every time its used.  Imagine how insane it would be if we took that perspective on any other facet of innovation: “Automobiles!?  Oh, no.  We’re sticking with horses.  That opens us up to too much risk!” From a standpoint of business and innovation, and considering this logically (heaven forbid), isn’t it much more risky to have technology running your operation where change is too terrifying a proposition?

I guess what most people don’t realize is risk is success — taking risks is what teaches you things — or as the Zen aphorism goes: The obstacle is the path.

2. Finishing a Project Never Feeling a Project is Finished

Oh, its done alright — just about, anyway — just that last 10%.  Its in the “Shoelace Phase” as I like to call it. The whole shoe is there but that leaves that last part of tying the bow.  Then, quite suddenly, someone not even involved with the shoe realizes something is missing among the myriad not-physically documented requirements, and you, Shoemaker, are back to the beginning.

Most software projects fail in just such a way, as they fail to collect accurate requirements which determine the necessary state of a release candidate.  Worse, if such a final state can be determined, the expectations of that state are rarely appropriately managed, resulting in end-user’s who feel surprised or unsatisfied with the final product; more relevant, a developer who is surprised or unsatisfied with the final product.

3.  Optimization / Re-Factoring / Reducing the # of Lines of Code Bloating / Re-Inventing the Wheel / Needlessly Increasing the Complexity of the Lines of Code

“We need something to get a file from A to B.”  You offer to use a transfer protocol and an existing transfer client.  But, no.  Thats rarely reasonable or robust enough. The route everyone loves is: E-Mail!  So, you bloat your own e-mail client that is a transfer protocol client by the time your done.  Lovely work, I suppose you could mark that under #5  — “Learning Something New and Useful.”

Of course, the only excuse for those kinds of software development sensibilities is a hefty amount of time spent smoking crack.

“Thats going to take re-factoring, perhaps re-design… ” Very common words of the software developer.  How about at least one common response? “Nothing takes a re-design, come on! Just build your more advanced (in other words, your system with a more accurately recorded set of requirements) on top of the old system (the system with nearly no recorded set of requirements that only exists in motion).”  In laymans terms:  Build me a train that runs on eggshell tracks while its on its way to its first stop — I’ll be in the back adding cars, so hurry up.

4. Seeing Marketing For a Product You Work On

As many times as this happens, I can not resist informing whoever is nearby that the entire product came about because a few people scribbled some things down on a napkin and handed them to me on a Monday morning (and told me to “be creative”).  Nor can I ignore the urge to explain precisely how much money they are making off each individual sale and how little they took into account the potential customer. The few times I’ll keep my mouth shut in these types of instances, are when the product is in fact so piss-poor there is no reasonable way to explain my involvement while at the same time absolving myself of having been a part of such worthless engineering.

Any one who sits there cheering proudly is the kind of fan-boy who does that no matter the nature of the product.  For developers, critique is king.

5. Learning Something New & Useful Ignoring Best Practices For Irrational Reasons

Remember all those wonderful things you learned in your first few projects?  Good, cherish them.  The rest of the time you’re going to be told there is little time to make use of them; no time to develop test cases; no time to actually write down requirements; no time to discuss certain aspects of certain features with the actual users; no time to explore that experimental way of filling this need, only the same-ole’ broken ways they’ve learned to accept so far.

Remember the insane look you got when you suggested making a web form to replace executing business processes through specially constructed, shared E-Mail messages? Remember how they told you The Web was just a fad?

Below, the cover of The New Yorker this month, showing a candid shot of our President in the oval office, “chilling” with one of his better friends — capturing the President, a man at work.

Funniest do-it-yourself (de-)motivation poster ever.