This is for John–

1.  Thinking on Your Feet

Few people might call analysis an art, but it is — ask any developer. When you have to come up with a way to fix a train when its moving along the tracks (patch a broken, already released product) , you learn fast how to think on your feet.

Another way to put it: when you develop software, over time, you begin to restructure your thoughts so that almost any inquiry can fit inside a formalized optimization problem.  It goes something like “What is the ideal way to handle this?” After answering that question in the multitude of ways its presented developing software, the programmer literally has learned optimized internal methodologies. This in turn further improves how they handle future analysis.  And before long like rolling lava, this optimized way of thinking covers all things and creates a new mental landscape. Smarter… Faster… Stronger…

Except maybe as an acrobat on the high-wire, few other jobs will provide such powerful training with thinking on your feet.

2.  Mastering Discovery

Developers need a lot of other software tools for making software.  And they are without a doubt the very definition of power user when it comes to how most of those tools were designed to be used.  So its often that a developer will discover a bug in the very tools used.  What so great about that?

These instances teach you discovery! They teach you how to remain skeptical and studious, so that one day from learned proper analysis, you are astute enough to see such problems coming down the pike and perhaps inspired to deal with things differently in your own creations– all gratifying..

Sometimes though, there is just no more instant a form of gratification than being first.  First in line.. first to make it home– first to find a problem.  Mastering discovery means just that, being first when it comes to finding (and if possible solving) problems.  But, it also means being a developer sometimes comes with all the gratification and arrogance of approaching your SAT proctor and saying suggestively, “Excuse me, sir.  I think you’ve gotten this question wrong.”

3. Being In-Demand

Lets face it, we’re surrounded by technology.  And one of the best things about being a developer — being a technologist — is simply the fact that right now, every one needs you!  Mostly due to the truths surrounding #4 on this list.

4. Making it Look Easy When its Not

One of the best things about being a software developer, is that we’re usually able to make it look incredibly easy given what the heck we’re actually doing.  We type some jumble into some window on our screen and suddenly, we can all socially network on the web;  communicate and search based on geographic location; blog about our day; become closer to one another and the information that binds us to one another.

To draw a metaphor other developers might need concrete, nails, hammers, sheet rock, a giant truck to carry it all and the laborers. Not us; a desk if you got one otherwise our lap will do and these days the obvious Internet connection, is pretty much all we need.

The reality is though, our job — software development — is intensely challenging, making the success all the more sweet albeit not so easy to share.

5. Making Friends/Solving Problems

Then there are times you can share it.

One of the most true statements about sociality with people is that shared trials and tribulations can bring people together more smoothly and easily than most other sets of circumstances.  The effort to share survival is an ultimate and immediate trust-builder.

When you and your co-worker manage to save the company $100,000 outage, keep some cracker from making it all the way into some critical system, find a faster way to complete some business process, or even just provide a friend a URL that makes their personal lives easier somehow, you’re making friends,  solving problems.  You’re contributing to something that is truly the masterwork of every developer: a unified framework for solving problems, creating a better perhaps less hectic life for everyone.

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?

For years people have learned from hacking — its the most ancient human art. But, it seems the US has slid so far from its foundation, that now the sheer construction and presentation of information can within itself be considered in some way criminal.

A judge acting as thought-cop told 3 MIT students they were not to discuss their latest hack. Since the halt order, the availability of the information in the presentation has fluctuated. Decius makes mention of the evolving legal manifestation on Memestreams.

I believe information like this ought to be free, and so: a complete form of the content of the halted Defcon presentation is right here (in PDF format). Enjoy.

For million of years, mankind lived just like the animals.  Then something happened, that unleashed the power of our imagination — we learned to talk…

–

It doesn’t have to be like this, all we need to do, is make sure, we keep talking.