I’ve been programming for over a decade. During that time I went through several pretty difficult scenarios in my programming assignments. I want to share some thoughts in this post.
There are situations when we are not quite sure how to implement a particular feature. For example:
- Adding/modifying code in an old code-base
- Adding/modifying code in an unknown (potentially in-house made) framework
- Configuring software to suit our needs
- etc.
In all the above situation we may underestimate the effort needed to successfully implement a feature before the deadline. We, as professionals, want to provide pretty accurate (and potentially small) time estimate. Unfortunately, software is currently so complex that we should expect the unexpected. Otherwise, we need to know how to recover from exhausting an sprint.
Here are some tips on how I learned to tackle such cases.
Always have a plan (and backup plan as well)
Have a plan and stick to it - this seems obvious, but sometimes we are so confident that we skip planning. We jump straight into programming (this is what we love!!!). Unfortunately, if we meet difficulties, our estimates go to hell…
You may ask what difficulties? Let’s name a few: 1) different database, 2) system components updates, 3) unmaintained printer drivers, 4) expired SSL certificates and many others.
That is why we need a backup plan. A backup plan can consist of an alternative solution or a recovery procedure :) Both of them require some extra time, but should result in a working solution (even without implementing the feature this time).
Share your progress often, precise and honest
Usually, the work result is not kept in isolation. Other teams/organization units/departments are probably waiting for us to deliver on time (or better earlier :) ). Sharing progress also shows our professionalism, mental experience and transparency.
Because of that, we should communicate the progress as often as possible. This includes both good and bad news.
- Sharing good news - nothing is better than good news. Your confidence and trust in the organization grow - keep up going. And deliver :)
- Sharing bad news - usually that means missing a deadline or a serious issue. Remember to be honest. Don’t try to hide the real reason - people can feel when you are lying. Just explain what is the problem and - what is essential - provide a set of potential solutions. The decision has to be taken fast.
Don’t be afraid of asking for support
Don’t try to reinvent the wheel - ask for support. Don’t be afraid of losing your professionalism because you don’t know something. You are not alpha & omega.
Teamwork works best when communication is effective. In supportive organizations, every employee is entitled to ask for support if he/she meets unexpected issues. For a .NET developer, this could be configuring Nginx server or Linux firewall.
First thing before involving another person should be asking yourself if this is a single question or a number of questions related to the same topic. If it’s the second option, then probably reading documentation is the most appropriate thing to do before bothering others in the first place.
On the other side, you should not ask about everything. If you end up asking about everything then you are in a wrong place…
How to ask?
This is the most annoying thing when people ask me about something. They have problems with describing what is their problem. Advice: Synthesize a precise question. Provide context (some sample code or some description). Try to include the big picture in your question. There is not much more annoying than when I answer a question and then there are 5 variants that finally lead to a totally different approach… a waste of time…
What to do when there is nobody to ask?
Sometimes we end up in a situation when nobody knows the answer. In that case, google is your friend. Seach on product forums, blog posts, StackOverflow questions. Sometimes event browsing the source code could give you some hints. Just spend some time and investigate. I know it’s not easy…
Always conduct a retrospective
So finally you have delivered the feature! Congratulations - don’t hesitate and celebrate for a while :)
I encourage developers to write “Lessons learned” documents after a stressful period is over. Such documents have two-fold value.
- Primary value - while writing the document we revisit the case once again. Doing so refreshes our memory. This technique helps us to check what worked in long run perspective. Which actions we should mitigate and which we should practice often.
- Secondary value - they serve as a historical example of how did we solve a particular problem in the past. Maybe there was a tremendous blog-post that helped us. Maybe we have found a great book describing recipe and we used those. It’s a case description and action taken to finish it.
This is how you learn.
Final words
As you can see from the post, recovery is not something you can do after the problem occurs. You have to be prepared up-front.
Taking a few days off after exhausting development will not help you in the long run. Next time you will have to be prepared in a more structured way. That’s why I encourage you to, at least, try the recovery framework proposed above.