This Development Tool Hurts Developers — Here’s How to Win Anyway

Does coding stress you out?

It's a stressful and exhausting ordeal for many developers. Many of them feel like they're not accomplishing much of anything at work. There's a long list of problems they have to fix, and never enough time to get everything done.

Solve one problem and two more take its place.

They're already overworked. So what do they do? They work harder. They add more work to their already full plate. They shift their attention to brute-force tactics, doing whatever it takes to get results.

You know how that ends. It doesn't work.

Their personal lives suffer as they're crushed under the weight of their massive workload.

The Problem Isn't Their Workload

It's their tools.

There's a specific tool that makes things psychologically unbearable for many developers. Something so simple, it's immediately discounted or ignored.

Almost immediately you hear the objections.

• "It's not that bad.”
• "I use it and I'm just fine.”
• "I use this tool every day. It's only a problem in the beginning.”

Some developers are downright fanatical about this tool.

• "I absolutely need this tool.”
• "No way I can function without this."
• "Projects aren't successful without it.”

By now you're probably on pins and needles. What tool hurts developers? What is he talking about?

I'm talking about...

To-do lists.

Your to-do list is either a standalone product or a feature in your project management tool of choice. It's something we use to manage our personal and professional lives and it's typically not optional...

Which is a problem.

To-do lists are helpful... at first. You're able to get an overall view of the work that needs to be done. You know what to do, and when to do it. It keeps everyone on track and on the same page.

Great, right?

The Not-So-Great Side of To-Do Lists

To-do lists come with a lot of downsides. What's worse, the damage from these downsides increases slowly over time. It creeps in slowly, subtly.

The damage is so subtle most developers miss it.

Damage? What damage?

• Perpetual guilt. You feel guilty because you're not getting everything done. You're delaying it or you're not getting it done fast enough. When you're finished, that completed to-do is a persistent reminder that you didn't do it right.
• Performance delusion. You check something off your to-do list and you can't help but feel good. It feels like you're accomplishing something, as if you're making progress — except when you're not.
• Psychological load. There's a depressing secret about to-do lists. They're never ending. Finish one list and another one takes its place. Over and over, day after day after day.
• Misplaced priorities. Are your priorities focused on the right to-dos or are you simply spinning your wheels, working on tasks that ultimately don't matter? How can you tell?
• Conditioned to fail. It's no secret you're overworked. The list of things you're expected to do never stops growing. What does this train developers to do? Ignore their to-do list.
• Disorganized and inefficient. App to-do lists come with limitations that hurt productivity. For example, the majority of to-do apps don't allow you to set group to-dos, where a group of people are working together on one task. Then, there's the fact that to-do lists don't distinguish between tasks you can finish in three minutes versus the task that takes three days.

And this isn't even everything.

In the beginning, new developers are typically apathetic or enthusiastic about to-dos. The developers who've been abused by them feel otherwise.

Often times they're stewing with frustration.

"It doesn't work, but my boss makes me use it." It's a discouraging part of work experienced developers tolerate.

Which Means These To-Dos Hurt Everyone Else

If you're a developer struggling with these issues, you're not as productive as you should be.

And it's not your fault.

Regardless of who's responsible, these mistakes hurt developers, the teams they work with, their bosses and even their clients.

Does this mean you shouldn't use to-do lists then? That, at best, they're a waste of your time and resources? Absolutely not. To-do lists can be a helpful tool.

If they're used properly.

But what does that mean? It means to-do lists should be used as a tool to support the team, to guide development and move the project towards the ultimate goal.

To-do lists serve the team, not the other way around.

These lists become hurtful when this gets switched around. Once teams start serving their to-dos, inefficiency and struggle are sure to follow.

Okay, so what should developers use instead?

What You Use Depends On the Freedom You Have

If you're a freelancer or part of a small agency you have the influence or control you need to try new things.

Here's a few strategies you can suggest or, at the very least try, to combat to-do abuse.

Tiny habits

I've noticed a common problem with developers; they create a to-do list with the same repetitive tasks, regardless of the project. These are tasks they know how to do and they're things they do repeatedly, like clockwork.

What if you created a habit instead?

BJ Fogg, director of the persuasive tech lab at Stanford, discovered a simple way to create habits.

Take baby steps. Teeny tiny, easy-to-follow baby steps that create new habits.

Let's say you wanted to create a new habit: flossing your teeth every day.

Most people make things complicated. They rely on brute force to create the habit. They spend time shopping for floss. They create flossing spreadsheets and checklists when a simple habit will do.

Dr. Fogg recommends the opposite.

1. Make the to-do tiny, say... flossing one tooth. It's tiny enough if it's easy and fast to do.
2. Find a spot in your existing routine where this new tiny habit could fit, after a solid habit e.g. eating lunch. For example, flossing by design, comes after eating.
3. Train it in. Focus on doing that habit, after your anchor habit every day. You'll need reminders at first, but soon you'll notice it becomes automatic.

I used a generic example here but that can apply to pretty much anything. Even better, there are specific things you do routinely as part of the development cycle.

• Pre-planning and planning tasks
• Implementation tasks
• Testing and analysis
• Debugging and performance improvement.

See what I mean? Every project has a routine, which means you can build habits around them.

Scheduling and limiting to-dos

"Oh you've finished your work early? Great! Here's another long list of things for you to do." Your brain knows the reward for your hard work is going to be... more hard work. So, why bother?

This has a demotivating effect on your team.

And the worst part? It encourages everyone to drag things out, to milk their time. It trains your team to spend more time accomplishing less.

Here's what we did instead.

We spent more time planning out our projects. In fact, 60 percent of our time was spent planning the project out. Thinking about how things would work, setting client expectations and gathering resources together.

In the beginning it felt crazy.

"Who spends this kind of time planning? Agile is better, we just need to get in there and build something. We need to iterate quickly."

We ignored our objections, deciding that we'd try scheduling and limiting our to-dos for a bit to see how it worked for us. Here's what we found.

• Revisions dropped by 96 percent (compared to the previous year).
• Bugs, edits, revisions — do-overs of any kind decreased by more than half.
• 80 percent of our projects launched on time and in budget.
• Our clients were much happier.

All because we scheduled and limited our to-dos.

But what does that mean?

Continue reading %This Development Tool Hurts Developers — Here’s How to Win Anyway%

by Andrew McDermott via SitePoint