Listen.

An architect doesn't ASSUME there will be a door on the building; She draws it in the blueprint.

Why?

Two reasons:

NUMBER ONE:  Drawing on the blueprint gives her control of the vision.

Not only does she say "I need a door." But, by drawing it into the spec - she says "I need a door, and I want it here - and I want it to look like this"

And so then maybe the client says, "Nice door, but I was thinking we could change it this way" - and it's ok because she can change that spec before they build.  Or maybe the client says, "Actually, I don't really want a door. I want a secret tunnel from the back yard. You know, like the pyramids...?"

Any way it goes, the point is she took control and lead the discussion.

NUMBER TWO:"Obvious" is subjective.

Builders don't build what isn't on the blueprint, and they don't ASSUME to build it anyway because "it's obvious."

It also makes the architect look like a real winner (READ: idiot!) to the client when she "assumes a door is obvious" and leaves it off the spec.

...
 

So, what the hell do doors and blueprints have to do with web development?

only EVERYTHING

An architect wouldn't assume a door because it's "obvious," so why would you make assumptions in a project scope?

Seriously.

We take for granted the simple things in our little web world.  The things that are obvious to us. User login functions, site maps, Twitter buttons - What. Ever.

...If you think "it's obvious" - you're wrong.

...If you assume "well yeah, of course" - write it down anyway

...If you're not quite sure - ask the question. CONTROL THE DISCUSSION.

The Moral of all this? Never. Assume. Anything.

Using "obvious" as a crutch leads to mistakes, ugly builds, and heartache down the line. Leaving "obvious" out of the spec is one of two things: Careless or stupid.

In the end you either lose control of the vision, or you look like an ass for forgetting. Or both.

I really wanted to give you something good today. Some blow-your-mind-from-left-field piece of prose that knocked you straight out of your socks into next week.

But, alas, it's  Tuesday night and I haven't managed to give you a thing. I apologize for that. Apparently last week's challenge wasn't enough, and so this week I had the pleasure of playing IT & super-site-saver since early Sunday morning. No, I'm not complaining.  It's all in a day's work as a senior developing small firm project managing dev-seo-marketing-web-wizard.  And I do love what I do.

I am also still human.

So after three days of restless fighting with some damn-nasty-catastrophic failure; in between swearing, finger-crossing, fighting with backups, sifting through raw data, and digging into the magic top hat on my desk... Three days later this Swiss Army dev has been reduced to a mere pile of blinking, drooling, barely keystroking, mush. 

This time last week, after I had wasted almost six hours of my life diligently enriched my skillset cramming my brain with code I may never need again - I at least had the motivation afterward to put my conclusions and story morals into words.  I formed (at least what I think was) a semi-coherent piece for you from that camel-back-breaking straw of an experience.  But, no.  No, that is not the case right now.

Right now, today, in my post traumatic stupor, I am pulling some glowing morals and wisdom from the embers - but nothing is quite lucid.

I'm pretty sure I want to tell you about how it's ok to ask for help.  Not just in the obvious "hey I can't lift this piano myself" sense, either. But the kind of help where you offer your clients everything without having to do it all yourself.

That's the most important help you can get when you know how to get it right.

Now I don't mean hiring cheap, faceless, unaccountable labor from who-knows-where. Well, do what you will, but that's not what we're talking about here. I mean building strong, symbiotic relationships and making the right choices that allow you to profit while strengthening your pool of resources and offering your clients the full service they're asking for.  I *also* mean knowing where that balance is and further knowing what "full service" means for you.

I mean using all that's available in today's almost over-connected world to your best advantage.

I mean running lean like a small firm should, but being mean like a big firm can. 

Not bad mean. Tough mean. Flexible. Capable. Indisposable mean.

It is fortunate that over the past year I have worked to establish policies and procedures with this team while continuing to move forward with new builds and projects.  To show where it's ok to get that sort of "help" and still build our business internally.  I work every day to help us achieve that balance, and the end result was an issue whose damage was minimized to a fraction of the catastrophe it *could have* been.  Yes, there were a few heart stopping moments. Yes, it is unfortunate that similar practices weren't there in the first place.  But, it's something we'll recover and move forward from. And, it is what it is. And what it is is something I've seen before many, many times.

And that's fine because it's also something that can be fixed. 

(!!WARNING SELFISH ASIDE!! It's also fine for me because helping teams become lean, strong, indisposable mean is one of the things I do best.)

As my brain finally begins to reboot here, I'm finding inspiration to talk more about those things you can do to be mean like that. I'd like to follow up with more details, insights, and recommendations: I just don't have it in me to do it now. So let me leave you with this:

Success, especially these days, isn't determined by size nor is it fostered by greed.  Sure it goes against a lot of stodgy old conventional wisdom, but it is possible be everything to your clients without having to do it all yourself.  It's not just acceptable to ask for help - it is in the greatest interest of your sanity, your strength, and your livelihood to embrace that notion.  To reach out in pursuit of perfecting that balance.

As I hope you will see, the benefits are endless.

3.27 minutes ago, I finally resolved an issue that could have been avoided with the proper documentation.

3.27 minutes ago, I felt torn between having lost 4 hours of my life and being "grateful for the experience."

3.27 minutes ago plus the four hours prior, I was painfully reminded, as I am all too often, of the importance of thinking outside the moment you're standing in - especially as a programmer or anyone who creates something to be used, tweaked, and interpreted by future custodians.

3.26 minutes ago, Don't Be Stupid Tuesday was born.

Starting this afternoon, and every Tuesday to come to uncertainty, I will post for your pleasure (and hopefully your empathy) my musings on the small things in life you can focus on to make yourself a little less "stupid."

That is, I want to share some antecdotal -let's call them "recommendations"- on how one might go about functioning well in a world that has OTHER PEOPLE IN IT (besides just you!) A commentary on how to better yourself as a functioning member of society, if you will.  Most of these tips will spawn from my specific adventures as a php-developer-slash-swiss-army-web-everything, but I hope that even if you don't speak the same flavor of programese as me (or, if you don't speak it at all), you can still take something away from the whole mess of it.

I hope you'll share comments or recommendations on future posts I can plug into this category.

Subscribe to this blog or simply look for my #stupidtuesday posts on Twitter to join in the fun.

And please, don't hesitate to share some #stupidtuesday of your own!