obviousity's posterous

obviousity's posterous

Casse No-i  //  The unfiltered ramblings of a 20-something designer/dev with a bad case of the people-watchies... a girl who just needs to get it off her chest once in a while.

Filed under

accountability

See all posts on posterous with this tag »
 
Apr 20 / 10:16pm

Blueprints and the Truth of What's "Obvious"

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.

Filed under  //  accountability   advice   blinking kittens   don't be stupid   obviousity  
 
Sep 29 / 7:10pm

The Importance of Documentation - Don't Be Stupid Tuesday #1

I wasted almost five hours of my life this morning because of the (what I consider to be) poor choices of the person in my position before me.

Five hours of playing IT-for-free when I could have been doing my "real" job building a billable web project.

Five hours of learning about something that, although related to my day-to-day, doesn't serve me as much more than a tertiary bullet point on the laundry list of my career goals.

Five hours that skewed the day so badly it was hard to accomplish anything relevant in the afternoon.

Five hours of pain I wouldn't wish on my worst enemy.  Not even that person-before-me who ultimately made today possible.

And while I'd like to discuss all the events that led to today's debacle - I'm focusing my first Don't Be Stupid Tuesday post on what I think is the most important point of the lot because I think it's the easiest to accomplish.  And, that's the importance of appropriately documenting your project for future reference and maintentance, whether its for you or whoever comes along to take care of it next.

This isn't the same-forever-only-2-people-know Coke Secret Formula. This is a live build that real, normal people need to use in every day situations. It needs to be adaptable, fixable, and understandable.

I shouldn't even have to say this, but the number of issues I hit with things I didn't build - issues that would have been moot with the right notation - issues that are normal concerns of someone in my position, managing the care of 100+ sites, and building new constantly ...I don't know how to stress the importance of taking that little extra time to DOCUMENT YOUR SHIT.

Comment your code. Provide a README or similar notation.  Tell someone else where you keep your list of passwords. I'm not saying publish it to your Facebook - be smart about it. And whatever it is, consider the person that may be fixing it later: a PHP file may need some commentary to suit another developer, but a mail server may need some direction in layman's terms in case the IT is out of the office. 

Point is, whatever you've put together, you're not going to be there forever to take care of it. And even if you are, who's to say there won't be a day some catastrophe hits and you're not there to troubleshoot, or maybe 3 years go by and you plumb forget what you did in the first place. It happens.

I mentioned earlier that this was the easiest to avoid of all the causes of today's mess-i-wouldn't-wish-on-anyone, and I stand by that statement. Stop leaning on excuses, and start breaking the bad habits.

I'm not just asking for my own sake as the "person that fills your shoes next."  Do it for your development as a professional. As someone who cares about being a Senior This, a Lead That, or simply a hard worker who is seen as a competent, accountable whatever you are.  I know when you stop and think about it, you'd hate to be in my shoes: wasting time, keystrokes, and sanity on things that could, and more importantly SHOULD, be much less stressful.

I'm even willing to bet you've already been there once or twice before.

Filed under  //  accountability   advice   document   professional development   stupidtuesday   tips