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

Tools

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.

Make the to-do tiny, say… flossing one tooth. It’s tiny enough if it’s easy and fast to do.
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.
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?

We planned our projects out at the beginning, choosing to work on a specific set of tasks or to-dos each week.

If there are eight steps in our pre-planning process and that takes two weeks, we spend the first two weeks on pre-planning. That’s our focus — we set a boundary around those two weeks.

No revisions
No changing the scope of work
No adding last minute to-dos
No unrelated tasks

It took more discipline than we expected. But here’s what we found.

Developers did a better job. Each developer had a set amount of tasks for the week. There wasn’t a never-ending list of things to do, so our team stayed fresh. We had more time, so we wrote better code and caught more bugs, doing more work in less time.
They found problems faster. When you’re overwhelmed with a list of to-dos, your focus changes. You tend to become focused on knocking out as many to-dos as you can when you should be focused on fixing the problems properly. It’s amazing what you catch when you have the time to look.
Clients were more stable. We told clients upfront that we wouldn’t change our to-dos or options from week to week unless they were absolutely vital. This conditioned clients to think carefully about the changes they wanted. Last minute requests along the lines of “I need this new feature by tomorrow” dried up overnight.
Scope creep was easy to avoid. With to-dos scheduled or frozen in place, we were able to minimize scope creep, only making adjustments for the necessities.

The benefits were huge.

But these strategies worked well for us because we had control. We were a small agency and we had the autonomy we needed to test this out.

But what if you don’t?

You’re Finished If You Don’t Have Control

Right?

That’s the expectation. If you’re working at a job and you don’t have control over your situation you’re just going to have to suck it up.

But it’s not true.

If you’re working at a place where people are willing to listen, talk to your co-workers.

Make your case and ask for feedback. But, what if it’s not safe? You’ll need some more options.

Limiting to-dos

It’s the same as before. But instead of limiting to-dos on the project, you place limits on the to-dos you’ll work on for a particular time period.

Pick a timeframe. If you’re micromanaged on a regular basis you’ll need a shorter timeframe. If you have more autonomy you have a longer timeframe to work with e.g. a week to a month. Limit the to-dos that are pushed into your timeframe. If one gets forced into your week for example, you defer an existing to-do.
Choose your to-dos. You’ll want to choose the right mix of to-dos. High value to-dos push the project forward, make your boss happy, but take more time. Mid to low value to-dos give you quick wins and lots of momentum but aren’t as appealing.
Deal with resistance. A controlling boss may want to dictate what you work on and when. Rope them in on it, getting them to share responsibility for the project’s success. Do it right and you get an overbearing boss to back off.

Using reminders to ignore to-dos

Research shows we work best when we focus our attention on one thing at a time. Which means multi-tasking is kind of the worst. But it’s exactly what to-dos entice us to do.

Focus your attention on all the things you’ll have to work on later.

So you create helpful reminders. Here’s the problem. Most of us take this opportunity to load ourselves up. We take all of the to-dos and we hang them around our necks creating a rabble of reminders.

Don’t do it.

Instead, create one reminder at a time. If you’re about to start working on A, create a reminder for B. If you’re starting B, create a reminder for C.

Create one reminder for the very next thing on your list.

This takes discipline, but your sanity will thank you.

When you’re done, head back to your to-do list and cross it off. Create a reminder, then keep going.

Why bother?

Because fear, stress and anxiety kills your performance. Aggressively limiting your to-do list keeps your stress levels to a minimum.

Want to do your best work? This isn’t optional.

Your boss will push for control. Your co-workers will push for control. Some of your co-workers will look out for the team, but let’s be honest, most won’t. Most of your co-workers will look for opportunities to reduce their workload, even if that means increasing yours.

Protect your emotional and psychological health and your best days are ahead of you.

Ignore it and suffer.

To-Do Lists Only Hurt If You Allow Them To

That’s easy to say — if you’re in control. When you have autonomy, control or influence it’s easy to discount someone else’s problems.

But that’s not reality for most developers.

Developers are stressed out, overworked, abused. It’s a common problem.

Which immediately creates fear. That fear usually manifests itself like this:

“When you are given more work to do, you bend over and say ‘Thank you sir, may I have another’.

Or else you will be replaced … in a New York minute.”

If you’re an unremarkable developer this is true. And why wouldn’t it be?

But if you’re great at what you do — helpful, supportive, an all-star — losing you will hurt. All-stars have the ability to set boundaries and limits on their work. You’re too valuable to lose.

You can’t work without to-dos…

… And you shouldn’t have to. But becoming a slave to your to-do list isn’t the answer. Your to-do list should work for you, for the team, not against you as it does for many developers.

To-Dos Don’t Have to Be Stressful

To-do lists make coding a stressful and exhausting ordeal for developers. Most developers are overworked. Working harder, drowning in to-dos.

This doesn’t have to be you.

Your personal and professional life can be a wonderful, stress free experience. You don’t have to be crushed under the weight of a massive list.

You’re in control.

Take back your to-do list. Fight for your time, fight for your emotional and psychological freedom. Give yourself the tools you need and you’ll find your best days are ahead of you.

No crushing workload required.