Categories
development

Embrace bored

Be bored.

No news in Facebook news feed
No news in Facebook news feed

Be at peace with your thoughts, and let them consume you. Put down your phone, disconnect from social networks.

Don’t seek stimulation just for the sake of it 

Think about your problems. But don’t dwell on them.

Boredom makes you brilliant. 

Boredom makes you more creative 

Procrastinate. It’s good for you. 

Not working will help you work.

Grab a coffee. 

Smoke a pipe or three.  

In Praise of Boredom – Maria Konnikova

If you’re stuck, get away and think.

Give yourself time. 🕒 It’s a precious gift.

Categories
lifehacks

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.
Categories
development leadership quickfix ux wtf

De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”

“NEW COMPUTER SYSTEM!”

Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.

Categories
development leadership

Measuring the wrong thing

Process improvement requires measurements. How do you know what to improve if you can’t see where things aren’t working, and how do you know you’ve made the right change without seeing those numbers going in the right direction?

But measuring doesn’t mean you’re measuring the right thing, and measuring the wrong thing can lead to the wrong outcomes, and can be very harmful (see Liz Keogh’s talk on perverse incentives )

The key to the success of any metric is that it is owned by the team so they have complete control over the changes needed to affect it, so they feel ownership, and that improving the metric has a useful business outcome.

Metrics that I’ve found useful in the past include:

Number of bugs introduced by a release.

This is a tricky one to work with because it can easily be a perverse incentive, and the feedback cycle can be slow, especially with the usual 6-12 month release cadence. However, on one waterfall project I took over there was a strong negative perception of the quality of the code, and big count was a useful proxy as the customer had access to JIRA so the big list was already visible. Reducing this number was a combined effort where testers and developers had to approve requirements, developers and testers invested in automated testing at all levels, and testers joined the developer daily stand-up in order to catch bugs before they were released “have you checked that page in Welsh?“, “We found problems on that page last time because IE was too slow“.

Number of releases per month.

On an agile project we noticed that releases were getting held up because testing was slow and produced a lot of rework, which were then tested against more features that had been pulled from the backlog, increasing testing time. Each release also took half a day, so we had to schedule them carefully.

So we set a goal of focusing on releases for a month and measuring how many we did. There were other measures within that, such as monitoring work in progress on the testers, time taken to do a release, and cycle time from start of development to live release, but they all drove the big number, visible to the whole company, of more quality releases.

Questions answered per day.

This can be a very useful metric for research projects, especially when following a fail fast approach, when you want to prove something can’t be done before you invest in doing it. In order to do that, you need lots of questions with quick answers, to accelerate learning. Any answer, positive or negative, is progress. It means we have learned something.

“I cheerily assured him that we had learned something.
For we had learned for a certainty that the thing couldn’t be done
that way, and that we would have to try some other way.” – Thomas Edison

Age of Pull Requests

Successful agile projects rely on peer review, either via pairing, or a formal review process such as git PRs (and I won’t discuss that in this post). However, when we started working with these on one project, we discovered that we were building up a large debt of Work In Progress because the team wasn’t incentivised to review each other’s code, so one of the developers set up a nag bot for any PR older than 4 days. It lasted 2 weeks before it was no longer needed.

What about you?

What metrics have you used to incentivise the team? What problem were you trying to solve, and did the metric work?

Categories
development leadership lifehacks programming

The manager and maker schedule

All technical leads should write code. If you’re not writing code, you’re a manager. And that’s fine. But stop pretending you’re technical. Many Technical Leads or other senior technical staff have a preferred time split between the admin and technical parts of their job, but I don’t always see that in practice.

Some technical leads double down on the technical part and ignore the leadership part. Those are the people who need mentored. It’s the hardest shift when becoming the leader, to accept that your most valuable time is no longer the conversation you have with the compiler, it’s the conversations you have with and on behalf of your team.

You need the time to have those conversations, to keep the team delivering, and delivering the right thing. But you also need up to date technical knowledge to give you the right context for those conversations.

Managing time can be one of the trickiest skills for a new technical lead to learn. The process I use is simple, but it requires discipline.

If you want a split of 60% coding to 40% admin, then schedule it in advance. Pick 2 admin days and 3 development days. Or if you’re most creative in the mornings, schedule 3 hours at the end of each day. Into the admin days put your 1-2-1 meetings and other line management, and your cross-functional meetings, and the team planning and retrospective meetings. Lay out time for emails and backlog pruning and catching up on your reading list. And then block the remainder off for development, deferring to your task board for detail. And make those events as public as you can so your team and others know when they can schedule your time.

Maybe those times are dictated by others and you end up with regular meetings scheduled in your Zone time.If you can’t move it, work the schedule around it. Turn those into your admin days. The most important thing is to define a split, and stick to it.

Categories
development lifehacks

Give yourself time to think

I’ve spoken before about how a quick time out to grab a coffee can help you get to the bottom of a problem, but sometimes you need longer. You need time to switch off and think. 

I feel guilty about just sitting and thinking, despite trying mindfulness techniques, so for me, my best thinking comes when my body is busy but my mind is free. Sometimes in the shower (and apologies to my wife for those days when I take an extra 10 minutes to think through something), sometimes swimming, sometimes mowing the lawn.

Take time to get bored. Boredom is not boring. Boredom gives you ideas.

Read these…

Action is good, thinking then acting is better. Make time to think.

Categories
development

Naughtonomy

wp-1450118461565.jpg
Wherever the wind takes you

If you want a strong team of developers, give them autonomy. But what if they don’t want to take it? The ones in, or from, the big corporations who just won’t take the initiative? The ones who just want to be told what to do?

I’ve said before that those are the waterfall people. The cogs in the machine.

Have you been a developer who didn’t want to take responsibility for yourself or your work? Who doesn’t have pride in your work, and just wants the money? Do you want the opposite of autonomy?

It might not be your fault. If you live in a blame culture, you want to leave as small a footprint as possible. Head down, do as you’re told. Don’t attempt that risky refactoring or upgrade. After all, if you do it, and it breaks, it’s your bonus that gets lost, and your neck on the line for big failures. If you don’t touch it, and it breaks, maybe the previous touchee will get passed the grenade, or maybe it will just get blamed on a faceless, incomplete “process”.

Maybe your manager doesn’t want you making decisions. You’re not important enough. You don’t have the power to make them. Developer ideas don’t matter, listen to the manager, or the architect.

Or maybe you want to be motivated, to get autonomy and change things.

Show your boss this. Or get a new job.

Categories
lifehacks

Reducing waste by delegation

Sometimes the best way to get something done is not to do it. Use your time wisely. Lean on someone else. Drop the ball. Focus on what’s important.

Don’t write your own ORM, NHibernate and Entity Framework are probably faster, more secure and less buggy than anything you could write.

Don’t manage your own servers. Let Microsoft, or Amazon, or Google, or a myriad of other providers do it for you. Let someone else monitor the patch list, recover from failures and continually roll out new hardware.

You own your dependencies, but sometimes that’s better than owning a half-baked, home-brewed alternative.

Categories
development leadership lifehacks programming

Reducing waste by timeboxing

Sometimes we have a task to do, but distractions get in the way. We know we can’t multitask, and we want to be available, especially if you are in a leadership role.

But sometimes you just need to get something done.

Don’t be afraid to block out 30 minutes or half a day to focus. Put it in your calendar so everyone can see, and go somewhere private where you won’t get interrupted unless it’s an emergency. Work outside the office if you have to.

And limit your time. If you know you only have an hour (or 2 pomodoros) to finish something, you will be focused on it for that time. But pomodoros are good to remind you to take a break, re-energise and get back in the flow (but not Flowstate – I like the idea of an app that keeps you focused Mission Impossible style, but a lot of the writing I do needs a lot of thinking too).

Be clear about what you’re doing so that your team feels they have the space to do it when they need to.

Categories
development leadership lifehacks

Agile : The importance of heartbeat

wp-1448927964326.jpg

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.