Clockwise : suggestions for managing your time

• Plan ahead (with contingency)
  • Whatever works for you – personal JIRA, Trello, stacked sticky notes, dead tree notebook
• Stay focussed
  • Specify windows to check your email (e.g. first thing in AM and after lunch) and ignore emails until that window
  • Rather than letting new tasks distract you, write them down, then continue on your current task – and have a time to review and prioritize those tasks during the day.
  • Avoid context switching – humans are very bad at multitasking and your brain is highly prone to disk-thrashing, especially if you think you’re good at multitasking. See this TIME article for a summary of the research.
  • Some people work best with time-boxing : concentrate on a single task for a fixed period of time. Read about the Pomodoro technique.
• Say No if you need to – or you’ll disappoint
  • If someone asks you to do something, get a deadline for it to help you decide if you have time
• Track as you go
  • 6 minutes are a good building block of time to decimalise your day, especially if you’re filling out timesheets.
  • If you’re working on more than 1 project, you’re going to forget very quickly what you’ve done by the end of the week
• Review your time – find ways to optimise
  • Personal retrospectives. Are you spending your time on what you should be spending it on?
• Learn when to delegate, both to management and within your team.

Demotivated by refactoring

Technical debt causes drag. It slows down new features and lengthens the half life of a project (Erik Bernhardsson talks about projects with a code half-life measured in years, but Sandi Metz talks about projects with a half life of 6 weeks on her Chainline mailing list – go sign up now). We all know the benefit of doing it and development teams fight to get time to do it.

But it’s not the most exciting work. Dealing with debt can easily demotivate a team fired up by new challenges and new features, even when they see the benefit. Yak shaving doesn’t get innovators out of bed.

Sometimes the motivation comes from seeing the next step, 2 days refactoring so that this new feature can be delivered faster. Sometimes it’s a negative motivation, fix this and you’ll never have to worry about it again.

But for teams driven by delivering business value, taking time away from that to naval gaze at the code stacks up the guilt, and can tire the team out faster than a crunch, because there’s no adrenaline to go around. That’s because often the goal of refactoring isn’t enabling functionality, it’s unlocking efficiency, and that’s a less tangible goal. Why go through the pain when other tasks show more short term benefit for less work?

For one, the team has to be motivated by medium and long term goals rather than just short term. Not just what can be done this sprint, but what code do we want to work with next year? For another, refactoring in general should be small enough that the next business value task is on the horizon, and directly linked to the success of the current task. Or maybe there’s a personal reward. The team appreciates the work and so is happy to cover your support shift. They all agree that you get off pager duty for the length of the task plus a week.

When yak shaving is a drag, how do you keep motivated?

Cognitive load: Default to success

​Process impedes progress. It’s the hurdles, and the red tape, that stop you from doing what you want to do. It’s why you can’t have administration rights on your machine, it’s why you can’t commit directly to master. It’s why developers don’t get logins to production. It limits your agility. 

Sometimes that’s a good thing. So long as it’s a straightforward, time efficient workaround. You don’t commit directly to master, but every green, code reviewed pull request does. You don’t get a login to production, but the deployment server does, and you can quickly get access to production data on your machine when required to recreate a bug. And your live servers are protected. 

Make it easy to do the right thing. Process is part of it, and so is tooling. Don’t make me think about the right way to do it, direct me, without getting in my way. Make the process implicit, but open for investigation and improvement. 

We believe in people over process, but when machines can automate the process, the people are free to think about the business problem.

Agile : The importance of heartbeat

Scrum is built on the weekly/bi-weekly cycle. It provides a structure, a routine. It minimises surprises. You know that the planning session is on a Friday, for the work that starts on Monday, so you can get things on order on Wednesday.

It lets you see what’s coming.

It’s not about process, it’s about expectation. The more you can plan, the less you have to think about. You know when it’s coming and you can line things up in advance.

Have a heartbeat. Know what happens on a Monday, even if you don’t know yet what you’ll achieve.

Google Inbox and Inbox Zero

With a broken phone and Inbox by Google I went from 5000 unread messages to Inbox Zero in a week with some email bankruptcy and clearing out some tasks.

It’s not about being anal and keeping things neat, it’s about recognising that you’re never going to reply to that email from 2 years ago, but it’s hiding that email you should respond to.

Be ruthless. Archive, delete in bulk. That sale 3 years ago is over, you’re never going to fix that NHibernate bug, and someone else is looking at it, it’s too late to sign the petition to bless the rain down in Africa.

And as I found when my phone broke, and I got thrown back to a version of Gmail without bundles, stop hiding things behind labels. If you’re not going to read it, unsubscribe or filter it into the bin. Lose the haystack, keep the needles.

Rail Ticket UX

You may have noticed that Rail Tickets in the UK look a lot different, and it annoyed be, because I don’t trust that the change will make things easier for me, and I’ve yet to find the study to prove otherwise.

When I challenged it on Twitter, there was a split between the lovers and the haters of the new design, and also a brilliant example of how not to sell the design by the Scotrailgb parody account, in a tweet that has since been deleted, using language I have heard others use to justify their way.

This is industry wide and was tested on two month old babies who had no problem, sure you’re not just simple?

Use language wisely. You don’t sell change by insulting your users, customers, developers, colleagues or managers.

https://twitter.com/craignicol/status/631847304358690816?s=09

https://twitter.com/jay_tyler/status/631767276887404544?s=09

https://twitter.com/craignicol/status/631756264759013376

What do you think about the new design, and the alternatives?

Developer cognitive load

Anything a developer does that doesn’t add business value is wasted cognitive load. That’s why we use abstractions.

I know my developers are smart enough to handle memory management if they needed to, but developers just as smart in the past were less productive and introduced buffer overflow bugs because they had to think about that as well as the business problem they were trying to solve.

I want my team to fix one novel problem a day, rather than 10 papercuts that have already been fixed and get in the way of business logic.

When I see a developer make a mistake, I always need to ask myself if that mistake is a papercut that other developers will suffer from, and if there’s a way to fix it before the next developer encounters it. Code that makes my team more productive is always useful code.