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.

Two Hours of Code – the Sequel

I had the opportunity to go back to a school and talk some more about code.

This time the focus was on IoT and Cloud – amazing to see the growth and development of the kids in the classroom.

The full experience is on my LinkedIn article here and the full Slideshare presentation is here.

Creative Software Development

My favourite part of software development has always been the creative opportunities that it presents…

  • Coming up with new ideas to complex problems.
  • Trying something out simply to see if works.
  • Building something that no one thinks really works and watching it work.
  • Dreaming of an idea and then putting it into practice.

I love it, I love every aspect of it, it’s amazing and wonderful and beautiful all at the same time with an artistic wonder that I think is sometimes forgotten.

I think it’s the only industry on the planet that offers so much freedom to its community and at the same time provides so much opportunity for growth.  There will always be the long, hard nights debugging problems – but the part that always gets be going to the end of that long, hard night is figuring out a creative solution to the problem and going to bed elated at what I created.