The Good, the Bad and the Ugly

Sometimes you write really good code (or posts), sometimes you write bad code (again posts) and sometimes you write really, really ugly code (yup, posts too).

The Good is amazing, you sit back in your chair and think – “I am a genius”.  Remember that clip from Golden Eye where the Russian Hacker makes it all work?  That’s how you feel.

The Bad is still a pretty decent feeling, because you still feel good (not great though) because you accomplished something – “It’s not pretty but it does work… but it needs a little polish… later”.

The Ugly is where you have presented your code and it works, it does the job, people are happy with it.  But deep down you know it’s not your best work.  And it’s not because you didn’t try – perhaps it was a really hard problem that took awhile to wrap your head around, perhaps you are so overloaded that getting it done is an accomplishment or perhaps you simply weren’t able to invest as much time as you needed to into it.

Whatever the reason, it’s ugly, you’d like to change it, but you can’t, it’s gone out the door, people are using it, you’re in the corner cringing – “how could they be using it” and would prefer if no one brings it up again.
But here’s what it is – you shipped, you delivered, you put something out there that you weren’t sure about but you were willing to take a risk to get there. 

Was anyone else was willing to take that risk?

Was anyone else was willing to put that out there?

Did anyone else take on the hard problem?

All Nos – because you did.

So embrace the ugly, be proud of it, and instead of cringing in the corner, stand on a table and proclaim – “Damn right I wrote that, want some more”?

Leave it till the morning

There is a little, unpublicized feature on your phone called Do Not Disturb where you can block emails coming into you during specific intervals or ad-hoc.

I never knew about it until my daughter started to use it because her phone would keep dinging all night long.

Now I use it between 10pm and 6am.

This doesn’t mean I don’t get the message, I do and sometimes, by force of a horrible habit, I check it before I go to bed.

And this is where things can go terribly wrong…

I might have already had a stressful day and before it’s even started, tomorrow just became worse.  I might have done a ton of work to finish a project, only now to realize that the project is being cancelled.  We might have lost a customer after working so hard on that RFP.

The list goes on and on.

Although we are all first to say – “Not a problem this doesn’t bother me, I’m good to go, let’s handle it” – it does something to our bodies and our sleep. We keep working when we should be resting – even though phsyically we are resting – the mind is still racing.

Or even worse, that time when we receive the email at 12am, when we are already at the very end of the day (or start of a new one) we choose to respond.

Responding to an email between those hours when you should be sleeping/resting is a recipe for disaster – you’re off-kilter, you haven’t thought it through, it’s a quick send, etc.  When you read it the next morning you’ll think it came from someone else. You were rude, short, abrasive, etc, etc. Now the apologies come for having sent the email and the damage you done, the follow-up explanations (what I meant to say was or let me rephrase it) or even the meetings to discuss the email, etc, etc.

Or it doesn’t have to happen at all, you could merely wait till the morning to respond to that email and all will still be fine, but with less collateral around the email itself.

Put your phone in Do Not Disturb, rest (sleep or whatever) and leave it till the morning – it will still be there when you get up.

The Inverse Answer

Generally, when speaking or presenting, we ask the audience to ask questions. As a presenter, you WANT and even NEED them to ask questions.

It’s a bit of validation into what you have probably just invested an insurmountable amount of time and energy in, in making this presentation, to get some feedback and generate discussion.

If you don’t want your question/answer period to end at 1 question to do the following;

  1. Think about the question before speaking.
  2. Establish the common ground from which both you and the questioner can start from – what industry? do you use the same technologies? etc?
  3. Build on that common ground connection by recommending your answer to solving the problem.
  4. Apply it to a scenario this person might be fixing.
  5. Follow-up with the person asking the question whether you really answered the question (hey it happens) and follow-up with them later if you didn’t.

All or none of the above can work really, but there is only one thing you need to make sure you do not do when answering a question.

Deliver your presentation all over again, because that is not what they were asking you to do.

The Grinder

It’s not a place, it’s a point.

A point in the project when there is so much to do, that all you can do is grind on the work that has to be done.

It doesn’t matter what the work is, how complex it is, what needs to be done, etc.

All that matters is that you’re at that point and you need to Grind.

The Grinder doesn’t care about design patterns, frameworks, best practices or methodologies; it only cares about getting it done.

Some people excel at Grinding, some don’t – it can be stressful and non-forgiving.

There is only one way out of the Grinder – to code, code, code – until the pile is no more.

Every project hits the Grinder at some point.  The key is to make sure you’re not always in it.

Treat Right vs Treat Well

Huge difference.

When we treat someone well, there is a barometer, a comparison that is evoked to how they are being treated and an immediate justification for how they are being treated.

“They are being treated well… for someone who does this.”

“We treat them well compared to this other company.”

On the other hand, when you treat someone right, the story changes completely, there is no comparison, no follow-up, the statement itself stands on its own.

“We treat our team right.”

The right does not need to be expanded on because it’s ingrained in your company culture and who you are, it merely becomes an extension of you and your company.

One is open for debate, the other is unequivocal.

The question now is which would you prefer to be treated as?