Craftsmanship Task - Lessons (Part1)

A quick blog post about things I have learned whilst working on my (as yet unfinished) wiki.

I am a really bad blogger!

No really. I am so bad at finding time to write stuff up, hence this is quite a long post. I should have written each of these up at the time, but I end up coding, not blogging in the time I have. I must do more of both…

Testing is hard

This is not to say it’s not worth it…but I do find it hard. I’ve found, often writing the tests is harder than writing the code, however, not testing makes thinks 100% harder in another way, in that you can’t tell if something is really working.

I’ve found Pair Programming Bot really good for making me behave!

TDD

Testing the right things is not easy. I’ve found I’m often testing for the sake of it, and not really resolving very much with my tests.

I’ve also found that no matter how much testing I do, it doesn’t circumvent having an idea of direction before you start.

You can code yourself into a hole TDD just as easily as not!

Big chunks of time are massively more productive than the same amount of time in smaller chunks

I have a family and a long commute, so time is the thing I am most short of. This causes the most problems in that I find it hard to get into whatever I am doing in the time I have available. When I get a few hours, I can get so much more done than 20 minutes here and there. Not because you can’t do anything in 20 minutes, but I tend to find I’ve lost context or a grasp on where I was going if I have to walk away from code before it’s a good time to stop.

Failing publicly is hard

I am trying to teach my son that the first step to learning how to do something, is to fail at it…

The reality is that whilst this is true, even as an adult, I find it frustrating and embarrassing, so I know how hard it must be for him.

It can’t always be the best

In the same vein, my son is a perfectionist. He hates to have even the smallest thing wrong. I have over the years got better at not falling into that trap, but when learning something completely new, it’s hard to know where it is acceptable to have something ‘wrong’ and fix it later.

Breaking down code in the right way

I’ve learned quite a bit about how to organise my code in this task. I am not happy with it yet (by a long chalk) but I am learning. It can’t always be perfect!

Pairing & review

All the eden guys have been really helpful about critiquing my code with me and pairing with me to improve my code. I’d totally recommend that you get someone to look over your work (or whatever nature) as often as possible and better still pair with you. You will learn a lot quicker.

We pair on UI/UX work, which is my speciality. This probably sounds odd, but two sets of eyes and ideas has proven to always be better than one so far.

Part 2 to follow.

At some point in the (hopefully) not to distant future, I’ll follow this up with another post about this task and what I’ve learned.