Are you in Software Development for just a few Sprints or a Marathon?

9 min readMay 13, 2019

Solving problems until 3 in the morning happened a lot at the beginning of my career. I would start working on a programming assignment and without even noticing it I would go down the rabbit hole of solving yet another problem that emerged while figuring out something completely else, and of course I would completely lose track of time.

Time estimation is hard. There’s no doubt about it. It takes a great deal of experience to figure out how long things will take, but I do have a few words of advice on how to think about time estimation. The attitude of most fresh devs is “I’ll have it done by tomorrow (and if not, I’ll spend the whole night working on it)”. This is horrible attitude! Why? It results in huge stress for the developer, and is not sustainable in the long run.

Let’s start with understanding what is the goal of accurate time estimation and why it’s important. The implications of getting the correct estimate are way beyond just delivering on time. Delivering features on time has a huge ripple effect and an underlying meaning that should not be disregarded as it defines other people’s perception and creates a reputation for the developer.

If you, as a developer can deliver on time, that means:

you are responsible,
you can be trusted by your coworkers/ management,
you have the experience necessary to estimate time properly, and
ultimately people will respect you for it.

It is not an easy task to master at the beginning, but it should be something you strive for. Because if you do deliver on time, you will be perceived as a professional and will be in spot for all the goodies that professionals get (like great job opportunities, flexibility, good salary). It might also increase the number of compliments you get for the work you do, so you’ll end up feeling more valued at work, and let me tell you, from my own experience, when I deliver on time, and get praised for it, it feels GREAT.

Now let’s consider a developer that’s been programming for a while but consistently does not deliver on time. The way that particular developer is perceived is the following:

they’re sluggish,
they cannot be trusted, and
they don’t care about the company/project they work for.

With that kind of a reputation it’s almost impossible to move up in a software career or have exciting opportunities to pick from. The scary thing is that if you do everything as it needs to be done, but you fail at that one thing — time estimation — your reputation will suffer. And that will affect how you feel at work.

For example: Let’s say you are working on a feature, and it takes you about two days to complete it. Consider the effects if you have estimated to work on that feature only one day vs. three days. How the recipients of your work feel about the quality of your work, your work ethic in both scenarios even though the work done is EXACTLY. THE. SAME. in both scenarios?

Your trustworthiness as a developer will be impacted. Even though you wrote the same code, the recipients of your work will perceive the quality of your work differently if you haven’t meet the deadline.

Now, if you are just getting started, don’t panic. You will not get it right from the beginning. Have patience, it will take some time to get the hang of it. Also the more you work on a certain codebase the easier it will become for you to figure things out — just like when navigating through a terrain you are familiar with.

The thing to remember too is, when you are asked to estimate a particular task, you don’t need to provide an answer right away. Many developers try to come up with the number on the spot, and they end up locking themselves in an unreasonable or perhaps even unreachable timeframe. But the truth is, professionals take time to think. So, next time, when someone is pressuring you into giving them an estimate, tell them, you need some time to look into the code and think about it. It’s way more professional to ask for that time to research than to guess a number and then deliver low quality, past delivery time, or having overworked oneself — it serves nobody, not you and definitely not your company.

So here’s what you need to take into account whenever you’re preparing for a feature time estimation. There are 6 additional things to the actual feature implementation that most dev’s forget (7 things all together) to take into account when estimating features and we’ll address them one by one in just a moment:

Research
Meetings
Dependencies
Implementation of the feature
Writing tests
Peer review and improvements after the review
Other obligations

Let’s dive in into all 7 elements.

#1: Research

Before you get into the good stuff — implementing the feature — you need to figure out how to do it. Most new features contain requirements that you might not know how to meet right away. The feature will require that you learn something new. First you need to understand what it is that you’re doing, and only after having that understanding, execute.

You might need to learn a new skill, new framework, or new library in order to accomplish your task. Or you might need to study the codebase before you implement your new feature. Research if a) there might be similar solutions already existing in code that you should probably mimic (stay in the same convention) in order to keep the codebase consistent; or b) to figure out where to “plug the feature in” and what effect it might have on other parts of the code. Either way, you need to save some time for doing that prep work prior to the actual implementation.

#2: Meetings

You’ll be attending meetings with your client/team/product manager/technical lead to figure out what you’re implementing (translating user needs into actual feature requirements), and you’ll most likely need a couple of meetings to fill in the blanks that will arise while you are developing the feature. And you might have other meetings to attend to, while developing, even though they might have nothing to do with the current feature (social chair meeting, a 1-on-1 with your manager, conducting an interview, and so on… ). But it is important to keep in mind, that those meetings take your time away from developing and therefore affect the deadline of delivering that particular feature you need to implement. Meetings aren’t all bad though. They are a great place for seeking direction, asking for feedback and more clarification.

#3: Dependencies

As a Developer you’ll mostly experience two types of dependencies: Cross-Team or Cross-Department. A Cross-Team dependency is if you are working on a mobile app, but you need to wait for the backend team to deliver a piece of code and place an API before you can continue. This might severely inhibit your ability to deliver your feature by not having an API available that you must call in order to get the data to display it on a screen for the end user. A Cross-Department dependency occurs when you’re waiting for a designer to finish icons that are being designed for the app that you need to deploy to the App Store or Google Store. Those dependencies might affect your timelines, and you need to be aware of them.

#4: Feature implementation

The actual cool part! However, time estimation for this part is mostly guesswork in the beginning. Why? Well, if you’ve never implemented a feature similar to the one you’re estimating, it’s tough to predict timelines with certainty; also if you’re new to the codebase, it’s a bit harder. That’s why proper time estimation comes with experience — the more you implement, the more you work with a particular project, the easier it will get. Though it will very often contain a certain amount of guesswork.

#5: Writing tests

Another task of incredible importance, as it affects the maintainability of your code, is writing tests. There are different kinds of tests you’ll write in your programming career: Unit Tests, Integration tests, UI Tests, Functional Tests, Stress Tests, Performance Tests, etc.

Testing is very important, since the earlier you can catch a bug, the less is the cost of fixing it.

#6: Peer review

Implementing the feature is the main activity, however once you implement it, it does not mean that the feature is done. You need to have a different set of eyes look into it to increase maintainability. Having two pairs of eyes look into the code ensures that the code is understandable by at least two people, hence increasing the probability that whoever else comes to work in that piece of code, will have an easier way into that codebase.

#7: Other obligations

Perhaps you’re giving a talk, going to a conference, or you’re mentoring someone… That also requires time. If you are developing features for one codebase, but have obligations to maintain another project, it will split your time. Or perhaps you are bug fixing on earlier branches of that same project. This time, just like meeting time, is unrelated to feature development and will take your time and attention away from implementing the feature that you have been assigned to.

Another important obligation to keep in mind is… having a life outside of work and separate from programming. Other than maintaining code, you gotta maintain yourself! Many of us start out feeling so excited that we work all the time, and even if we don’t work on the feature-related code, we do some extra home projects that are related to programming. This is not to say that it’s a bad attitude to have, however, if you don’t plan for downtime and getaways from coding you’ll very likely burn out.

Did you get into coding to burn yourself out in 2–3 years? Or is it career that you would like to last for years to come and just have fun and enjoy the process? You have made an investment, of time and perhaps money, to become a developer. If you keep working after hours and on the weekends, without any rejuvenation time away from the computer, you’ll burn yourself out.

Don’t burn out.

This were the 7 things to take into account when estimating features.

Bonus tip: Talking doesn’t hurt!

Discuss your thoughts with your peers that work on the same codebase. Perhaps they know exactly where the functionality you’re building upon resides in the code. They might offer you some really great insights, so always try to ask and discuss your thoughts on how to go about estimating that particular piece of code.

Talking doesn’t hurt and might help you avoid hours of searching for the answer on the internet. However, do your research before asking. You want to avoid a situation where you distract others to the point they’re not able to do their job, because all they do is answer your questions.

TL;DR

Writing new code is just part of the work that needs to be taken into account when estimating time necessary for implementing new features. Other obligations, meetings, research, waiting for dependencies and code review are also time consuming parts of that process. That’s why it’s important to add safety buffers when estimating features. Buffers will help in delivering on time when unexpected problems occur, and will help keep your reputation intact. Without having enough time allocated we’d be burning the midnight oil… and ourselves.

It’s easy to lose track of time, while chasing answers and solving problems in code. But it’s very important to stop, take a breath, and see the bigger picture. Developers’ career is a Marathon, not a Sprint, and other than maintaining your code, you need to maintain yourself if you want to be in it for the long run.

Work with me!

If you feel stuck in your career, let’s hop on a call and see how a tough-love career coach like me, could help an awesome developer like you: www.themindfuldev.com/get-in-touch .