The Final Hack

If you were to measure the amount of hacks shipping in the latest release of your product by the date they were created. You would probably see a hockey-stick style graph.

Up until that moment, you’ve done everything right, laid the foundation, put in the effort, plowed through your grunt work – making gains all day every day.

But now the end is in sight and everyone is getting excited or worried about what is going to happen next.

Excited because they are finally going to be done.

Worried because will it work and will customers like it.

It’s the perfect storm of hacks.

“That’ll take too long we’re almost done, do it as dirty as possible.”

“The customer now wants these five things, how can we give them three and call it five.”

“We’ll patch again tomorrow.”

It’s tempting to be seduced by the hacks as you push to get it done.

But in the end, it’s the decision that yields debt for years, confusion and a messy release.

Your final release shouldn’t crawl past the finish line encumbered by hacks and patches, it should leap over the ribbon ready to save the world.

When presented with a list of hacks there are only two options – push out the release, push out the work.

Both are unpopular calls that no one wants to make.

But that’s why we have you to lead the way.


Commenting Everything

Ask a developer to what extent they comment their code and you’ll learn something very quickly about how they approach their work and their team.

Very little comments – whoever comes next can fend for themselves, just as I did.

Substantive comments – this was very confusing, I don’t want the next person to have to go through all of that again.

Commenting your code serves no purpose today, for you.

But for the next person behind you, it can substantially reduce their time, effort and overall level of frustration in working on a similar problem.

Who knows, maybe that next person is a future version of you that will appreciate what past you did for them.

The False Learning Trap

I hear this a lot – “I’ll learn it when I’m given a project that I can learn it on”.

Translation – “I’m not going to invest my own time in figuring this out until you tell me I can invest my own time in doing this for you… and pay me for it.”

Perhaps not what you were thinking at the time you said that, but you can’t argue with the logic.

Would that really inspire confidence at an interview or team meeting if uttered as honestly as the above?


Don’t fall into the False Learning Trap where someone else needs to support and fund your learning initiatives.

It’s not their job – it’s yours.

It’s not their goal – it’s yours.

It’s not to their benefit – it’s to yours.

Instead start saying – “I’m going to figure out some time to learn this so I can start going for the projects that will help me to continue to grow and improve on this skill”.

Now you’re developing the learning base to start making something happen.

Code More, Test Less

As Developers, there is an all-too familiar trap where we start to become really good at what we do.

We start to become really, really good programmers.

And with that, we start to code less, because we want to put more effort into design to making sure our code is perfect and beautiful and adapting and pristine and self-healing and and and…

So we do more design, then we code, then we write tests, lots of tests to validate all these assumptions.  In the end we start focusing more on design and testing then constant coding and pressing F5.

What we should be doing, what we need to be doing, more of is coding and testing, coding and testing, pressing F5 every 15 minutes to validate what we’ve done before sloughing forward with our next task.

Unit Tests are great for giving you that post check-in happiness glow of everything coming up green (and should not be discounted at all) but as developers we need to have that constant ebb and flow of success and failure in our face.  It’s through those attempts and scenarios that our code gets that much stronger, hardened and bulletproof.

Code, Fail, Code, Fail, Code, Fail, Code, It works, Check it in, Code, Fail, Code, Fail, Code Fail.

New Experiment – The Daily Coder

I’ve been trying to get my coding blog going bit by bit but I’ve struggled with it a bit – – perhaps it’s due to to not enough focus, perhaps it’s due to not having enough time, whatever the case, I’m starting a new project with this blog at it’s core.

For the month of June, I will be committing to doing an hour of code a day and blogging about it.

The rules are;

  • One hour of day of code per day.
  • Cannot be part of a professional project – must be my own project.
  • Learning doesn’t count, i.e., watching a PluralSight video, it must be actual coding.
  • Must write about it each day.

I don’t code every day or rather push it off more than anything else because that part of me worries that it’s going to be too hard to get back into and what I create won’t be anything of worthwhile value.

So let’s see what I can do – the experiment starts tomorrow.