Three lessons to help you be a better developer

By Harvey Taylor

When was the last time you gave yourself the chance to step outside of your headspace and think about how you work on projects? Sometimes, you need to get out of your usual routine, move beyond your usual headspace and give yourself the chance to think about things differently.

That’s the opportunity that myself and four other Bluefruit team members found when we went to a Coding Retreat run by Agile on the Beach. Hosted at the Bedruthan Hotel and Spa, it was a low stress environment in beautiful coastal surroundings.

The retreat offered attendees, including those with even just a small amount of software development experience, the chance to learn and reflect away from their day-to-day. Jon Jagger and Kevlin Henney, experts in processes and coding, ran the two-day retreat.

I appreciated the learning that I got out of this, and I wanted to share three of my top lessons with you.

Lesson #1: Lookout for tunnel vision

During the retreat, we had sessions where we practised Agile development processes, often in teams of two. Practice included Test-Driven Development (TDD) and Pair Programming. So, we’d work through a mini-project and review what we’d done with everyone else at the retreat.

What are TDD and Pair Programming? Doing TDD means writing tests for our code before we got to coding. Pair Programming is where two people work on the same problem together. There are two roles: a Driver and a Navigator. The Driver is the person that is at the keyboard and the Navigator is the one telling them what to write—you switch these roles frequently as you code.

At the end of going through this whole condensed development process, we reviewed what we’d done. And that’s when my partner and I realised we’d made a mistake. We had been so focused on completing the project that we’d not reflected much at all on the test names we’d created during TDD.

We’d developed a sort of tunnel vision as we blasted through testing and ended up with test names that were not reflecting the nature of the tests or the language of the instructions we were basing them on. We’d lost sight of the wider context and how habitable we should have been making our tests. It meant that someone coming back to them in a theoretical future would find it difficult to run the tests and make sure newer code still passed them.

You can’t just think about the task in the now. You need to think about how it fits in its wider context.

Lesson #2: Give yourself time to step back and get out of your head

I didn’t realise that before I went to the retreat, I was carrying a lot of stress. It wasn’t that work was actively stressing me out, but I hadn’t been allowing myself to step back in my downtime. To just let go.

Being at the retreat helped me to see how wound up I’d gotten. The retreat gave me the chance to destress and not dwell on things more than I had to. You don’t need to go to a coding retreat to do this, but we all need to remember that we should give ourselves moments of calm.

Take breaks at work. Don’t bring work things home with you. You might have lots on at home and work, but if you don’t give yourself the chance to step back now and then, you could burn out and be unable to do anything. And if you’re struggling to do that—find someone you trust to talk to about it. We have an open-door policy at Bluefruit, so there’s always someone we can talk to.

Lesson #3: Communicate how you want to communicate

During one exercise, people went into teams of three, and while two were in the traditional Pair Programming roles the third person acted as an observer. I was that observer twice, and I noticed that the pairs that didn’t communicate as much, who relied on just words without looking at each other, tended to produce code that wasn’t as of high a quality as those who used more communication avenues such as body language and eye contact.

Using body language and eye contact to communicate isn’t possible for everyone, but I think for me, it highlighted the need for pairs to discuss communication preferences before code writing starts. If you highlight any potential incompatibilities or gaps before you start pairing, then you should be able to come to a good compromise on how to communicate. Puzzle out how you can both make the most of the experience.

Get out of your normal headspace

The retreat for me showed me the need just to make sure that I’m not in full developer or engineer mode all the time. It’s good to take a break from your routine and give yourself a chance to think differently for once.

Head to the Agile on the Beach website for news on their latest events including Agile on the Beach 2020.