Redirecting your energy

I've seen people spend a lot of time crafting notes for their teammates to document the right order of steps to accomplish a repetitive and cumbersome task.

This is great, but you know what's even better? Spending the time on automating the task, so nobody has to learn the proper order of steps, and there are no more mistakes.

Sometimes you need to redirect your energy towards the right solution. Instructions on how not to mess up are great, but it's always better if there's no way to mess up in the first place.

Want to do something cool for your team? Look around, found a process that depends on a set of instructions, and automate the whole thing.

Don't be the jerk

Putting extra effort is a good thing. Going above and beyond is also a good thing. I think you should try regularly.

I also think that you should select the timing carefully.

If you are the person who waited for an empty office during the winter holiday to start committing code and spam people's emails with tales of your heroic efforts, you won't achieve any recognition.

Part of being a great team player is to respect everyone's time.

Let's assume that you want to do the work anyway; here is how I'd go about it: I'd finish the thing, write (but not send) the corresponding emails, and wait until we are all back at the office. Then, and only then, I'd show off my work.

People appreciate those that work hard and go the extra mile. Just make sure you are helping and not just showing off.

Bad code shouldn't be an option

Some people like to present unit testing as something optional in addition to the code they produce. They usually talk about two options: they can either create good code or good code that comes with tests.

I like to think about it a little bit different: it's either bad code or good code.

You can't write good code if you can't prove it with a test suite. Code without tests is as good as bad code, and it shouldn't be an option for people to settle for bad code.

The more you think about unit testing as indispensable, the closer you get to the developer everyone aspires to be.

TDD is hard, but it's tough to beat well-tested code

I just spent a couple of weeks doing TDD with somebody at work. He knew about TDD and unit testing in general, but he wasn't necessarily convinced about the trade-offs of TDD, especially for somebody with no previous experience doing it.

It takes time to learn TDD well. The initial feeling is that you can go ten times faster if you didn't have to write those darn tests. I get those that stop doing TDD after trying for just a few days; it's hard to envision the long-term gains while you are feeling so much pain to make any meaningful progress.

If you are going through this, don't stop. TDD is hard, but not harder than the other million things that you already learned. TDD will set apart your work; you'll be the one doing what the other hundred aren't just because they didn't take the time to learn it correctly. You can do better by sticking with it and overcoming the challenging phase. Eventually, TDD becomes second nature, and you'll be ripping off the benefits of your hard work.

The fact is that it's tough to beat well-tested code. There'll always be a thousand justifications to avoid unit testing, but at the end of the road, the better code always wins.

When the estimates are too high

It will happen more often than not: after you finish estimating the work, you realize the estimates are higher than what everyone was expecting.

An estimate is an unbiased prediction of how long a project will take or cost, regardless of what is the specific target that you want to accomplish. You can't just reduce your estimates, so here are some suggestions to keep in mind whenever your estimates seem too high:

  • Don't reduce estimates that came directly from the developers. They tend to provide estimates that are too optimistic already, so further reducing them will not help your chances of success.

  • Don't cut the estimates down without discussing the consequences and a plan to mitigate them. You can negotiate (and reduce) commitments, but you can't negotiate estimates.

  • Try to use different estimation techniques to validate your previous results. If these estimates agree, trust them.

  • An excellent way to improve the accuracy of the estimates is using group reviews. Wideband Delphi is a structured group-estimation technique that produces very good results.

  • Look at the least important features, and negotiate them out of the scope. Find the ones with the most uncertainty and start a conversation about them. Keep notes of every assumption you make to reduce the estimate.

  • Always remember that if you torture the data long enough, it will confess to anything. Don't push it.

Right at the intersection

Great, capable individuals can definitively make a difference. I know a lot of them; sharp, hardworking people that could easily impress you with their knowledge after a 5-minute conversation with them.

Sadly, you need something else to build a team. It's not enough to be great at what you do; you also need to be good at working with others. I've seen time and time again talented developers that have no clue about being part of something bigger than themselves.

Just like a baseball team, it's not about packing as many stars as possible under the same roof, but about finding the right balance and chemistry that will lead to winning games.

With every new interview, I've found myself asking more questions to uncover that side of the candidates. I don't stop anymore as soon as I realize how great developer you are, but I try to dig deeper to make sure you'll be a good fit for the rest of the orchestra.

The secret is right at the intersection of a great developer and a great team player.

Things to consider before sending your next estimate

Before sending an estimate for your next project, take some time and consider the following questions:

  • How long will it take you to clarify all the requirements, document them, and prepare the backlog of the project?
  • How long will it take to prioritize and size that backlog?
  • If you need to put together an initial release plan, are you accounting for the time to do it?
  • Are there any third-party integrations that will require further review and you aren't planning on it yet?
  • Do you need to schedule any time to think about performance, scalability and the security of the project?
  • Are you planning enough time to deploy the product?
  • How much time do you need to transition the project to the client?
  • Do you need to do any user training before handing over the project?
  • Is there any data migration that you should include in your estimate?
  • Is there any sort of warranty period that should be planned and estimated?

I keep this list handy, and it's very helpful every time I have to think about a new project. You can expand it to include additional activities (I removed some from the list above because they are unique to my company) and make sure you don't forget to account for that time again.


If you do a quick Google search for how to get better at estimating software tasks, you'll find multiple people recommending the way they do it. Some of these recommendations are some variation of the following ideas:

  • Come up with your estimate and then multiply this number by 2 (or 3, or even 4!)
  • Come up with your estimate and increase the unit of time you used. For example, if you came up with 2 days, your final estimate should be 2 weeks. If you came up with 4 weeks, your final estimate should be 4 months, and so on.

The principle behind these techniques (and any of their variations) is to add padding to the estimate to cover for unknowns. Despite well intentioned, doing this doesn't really make you better at estimation. It doesn't make your estimates more accurate either, and there's probably an argument about whether this is even ethical.

Would your client understand and agree with the way you are deciding how long things will take? If you feel the need to hide from your customer the way you come up with estimates, then you probably have more work to do on this front.

3-point estimates

It's being a long time since I estimated something using a single value. Providing a range is usually a better practice, and forces a different thought process that's extremely valuable.

What I do is to think about three different values: the optimistic case, the most likely case, and a pessimistic case. I'll talk about PERT in the future, but for now, let's keep the idea as simple as possible.

In order to build that feature, it will approximately take 5 days if I'm lucky. Most likely will take me 7 days, but depending on this and that, it could take as long as 12 days.

Thinking about the optimistic and pessimistic scenarios in addition to your most likely case forces you to answer very important questions:

  • What happens if I end up not needing that difficult integration after all?
  • Am I considering the dependencies to finish this task?
  • What are the risks that could get in my way?
  • What happens if some of the assumptions that I'm making don't pan out as planned?
  • Am I sure that documentation will be clear enough to finish the work?

Considering the impact of different factors on your estimate is extremely valuable, and I've found that it rarely happens when you think about a single value. But even when you think about all of this, it is hard to represent the results within a single number. 3-point estimates will tell the story that you need your audience understanding: big gaps between estimates will immediately point out to risks, dependencies, and unknowns that we should clear up to reduce uncertainty.

From this point, you can use your 3 values in different ways:

  • Provide a range using the optimistic and pesimistic values (5 - 12 on the example above).
  • Provide a range using the most likely and pesimistic values (7 - 12 on the example above).
  • Get a little bit more fancy, and compute the expected duration using the formula explained here. (This would be my recommendation, but it is also more time-consuming, so I'll discuss more about it in a future post.)

At the end, even if you are forced to use a single value as your estimate, the exercise of coming up with 3 different cases will play a huge role in making your estimate as accurate as possible.

One hundred 1-hour tasks or one 100-hour task

Are these the same really? I know that mathematically they are, but do they represent an equivalent effort for your product?

Most of the time they don't.

On one hand, having multiple low-complexity tasks is good to keep a large team busy. You will usually find ways to parallelize the work by having different people work on different tasks at the same time. There's no reason you can't do this with only one big task, but the former is usually simpler.

Smaller estimates will also tend to be more accurate than bigger estimates, where there's a lot of hidden complexity that we can't understand until we get close enough to the work.

On the flip side, one hundred tasks are just too many opportunities to make a mistake, to harbor scope creep, to have too many balls in the air at the same time. More moving things represent more complexity.

Make sure you consider everything at play before you let math play tricks with your estimates.