Categories
development leadership lifehacks

Be passionate about something that isn’t your job

There’s a recurring trope from the tech Ponzi schemers that you need to hustle in your youth. Work weekends. Work unpaid. Climb the ladder. It’s what they did, so it’s the only way.

It’s not.

Be passionate about your job. Be passionate about solving your customer’s problems. And be passionate about understanding and representing all your users.

But also be passionate about something else. Something that inspires you to leave the office. Something that satisfies a dream. Don’t narrow down your life to just your job.

Go surfing. Play in a band. Crochet. Spend time with your family and friends. Reset your ideas of what’s normal in working life, because the Ponzi scheme relies on you giving everything to your job, and convincing the next generation to do that too. Because the alternative is to look up and look around.

If you feel you need to work for free at the weekends, volunteer at a homeless shelter, not for a corporation.

Use your weekends for hobbies, for relaxation, for catching up with people in other industries and finding out that these opinions only exist in echo chambers.

Join the conversation on Twitter

Work your brain. Get new ideas. Reset your mind.

Watch TV.

Read books. Walk in the wilderness. Get out of the glare of the screens, and the superstars.

And don’t forget to wear sunscreen.

For more, listen to this podcast on making the most of your leisure time

Advertisement
Categories
lifehacks

Productivity sieve

There’s a lot of information out there. And more generated every day than you could process in your lifetime. So you need to filter out the important nuggets and discard the rest. The most important thing is what you ignore, because you’ll be ignoring most of it.

Many productivity frameworks deal with this problem the same way. Take
the firehose of emails, RSS feeds, Twitter recommendations, that book at the meetup, … and collect them in one place (or, if you really must, 2 – one physical, one digital).

Only add things that look interesting, and be intentional about it. Not every email or every tweet, just the ones you’ve marked (IFTTT or Zapier are a great help here). That’s your first filter.

Then, at a scheduled time, on a regular schedule (weekly or fortnightly) decide what you’re doing with everything in the one place. That’s your second filter.

Then, for the things you’ve decided are important, review them, rewrite them, record them. Your words are the next filter.

And don’t be afraid to rewrite, to delete. I use git for my notes so I know I can keep things clean and look at the history if I need to.

Or, to put it another way:

Put everything in your Universal inbox (Trello, Evernote, Notion, …) – one place for “this looks interesting”, from web, photos, videos, etc. but only what you’ve chosen to put in. Don’t let another person or an algorithm choose for you.

Automate the copying, not the decision to copy.

Each week, for everything in your inbox, make a decision.

๐Ÿ‘‰ Either “this is useful” – archive and tag
๐Ÿ‘‰ Or “this is actionable” – add to task list
๐Ÿ‘‰ Or “why did I bother with this” – bin it

Split tasks into “now and next” and “coming up”

๐Ÿ‘‰ “now and next” is stuff planned until your next horizon (tomorrow, next week, next sprint),
๐Ÿ‘‰ “coming up” is the rest of the stuff important from your latest planning session (this week, this month).
๐Ÿ‘‰ Everything else is unimportant right now, and either is in the ideas archive waiting to be promoted when the project is attached to resurfaces, or is dated to surface at the right time (e.g. annual subscription)

Don’t carry excess weight.

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.