The curse of being a Senior Engineer, how to deal with timelines, frustrations, etc

As a senior developer, have you ever been so frustrated that you feel like quitting or taking a long, long vacation or doing something else? Have you felt like you are lost and have no clue what’s going on? Everyone must have gone through these frustrations at least once or twice in their career. Frustrations are typical in our profession but learning to deal with them is very important; these are some of my learnings and practices to deal with them and get back to normal.

Deadline is coming!
  • Not getting enough time to implement your changes?
  • Getting frustrated with late-night coding?
  • Giving wrong timelines & ending up becoming sleep deprived?
I used to be one of these developers before I started implementing some good practices into my daily routine.

I used to feel the same way; I always wondered how people manage so many multiple things; I still wonder about this but on a different level.

Looking at the Figma designs & seeing only 2 pages need to be implemented, I used to take it lightly. I can finish this coding in 1 week & 1 week for testing, so we can release this in 2-3 weeks max. And I was very confident and never even assumed I might get stuck. So once I started coding, I got stuck and got frustrated, but since I had given less estimation, I pushed myself to do overtime & late night work.

Task estimations suck :P

I thought that if I didn't code on a particular day, I would feel like I hadn’t done any work on that day, so I implemented this policy that ignored whatever time gets wasted. Still, there won't be anyone to distract me during the night, so I can peacefully work. So before I slept, I made sure some small chunk of my feature was done.

This strategy really helped me get my work done. I was able to manage, but soon I started feeling more pressured & my work was unorganized & I started showing frustration to my family, friends & loved ones.

This also awfully affected my health. Then I realized this was wrong; doing the documentation work (which I still don’t like :p) or part of a meeting is also part of the work.

Pushing yourself more & more will only affect you. So I decided to make some changes to how I used to work. Thanks to my manager Gokul for always being supportive, encouraging & giving me so many tips & pushing me to achieve some of these. These changes actually helped me plan things better and helped me manage my personal & professional stuff more remarkably.

Split the task into multiple subtasks

I started splitting my task. Previously the pages which looked just 2 now became 10-15 smaller screens or tasks. For every small task, I send the PR now. So, what used to be 1000+ codes is now split into 50-100 lines PR.

Tasks breakdown leading to small PRs

This really helped me to fasten the review process. I stopped feeling that pressure where my feature will get delayed for release because my PR is not approved. By the time I finished implementing my feature, all of my previous PRs would have already been approved. Therefore, I am now left with 1 to 2 last small tasks that I can easily manage before the release.The more & more I started doing this, I could give exact estimations for my tasks, including the time which might be spent in meetings, critical bug fixes, etc.

Another advantage of splitting these bigger screens into smaller ones is that it helped me give timelines and made me figure out the most complicated part of that feature & how I should go about it. During the documentation stage, I could figure out a rough solution.This process led to a confident boast that I could finish all of my smaller tasks & send the PRs within the given time.

Prioritize the tasks

Once I started dividing these tasks, I now had a clear vision of what was on my plate; this list of tasks includes the feature tasks and the bug reports, other critical tasks that are high priority, etc.


Plan your day

I started planning my day with the help of a task list by allocating specific tasks for the day; I started with the high priority bugs & other critical features as my top priority for the day. I gave time to each of them. Sometimes just one bug report will occupy my whole day, but that’s okay because now I know how I spent my day.

Post updates at regular intervals

I keep posting my updates & progress in the slack channels. It gives a clear picture to my managers & other stakeholders, and it also avoids the daily operational sync-ups. This is a bonus because I saved 20-30 minutes by simply posting the daily updates in 2 minutes.

Regular Updates on Slack
Regular Updates on Slack

Inform about delays

If I am occupied with some non-roadmap items, my roadmap initiatives will be delayed. I will keep an update on this as soon as I start feeling that something might slip & not go as planned. I give an update to my manager stating the reasons for the delay. This will avoid considerable confusion in the end on why this got delayed.

After I start working on the initiatives, I keep updating the corresponding timelines in case there is too much delay & also communicate this to the stakeholders. Keeping everyone on the same page is very important; updates & notes make the job easier.

Taking Meeting Notes & highlighting the critical decisions with reasons

I used to just put up a meeting notes about what we decided and never mentioned why we came to that conclusion. This started to affect us whenever we got into conflict after the release, or some customers complained about our decision. No one would have remembered why we came to certain conclusions by this time. So I started noting down the reasons for particular decisions, especially those involving multiple discussions to reach an agreement. This will be very helpful if we end up in a situation where we have to question our decisions.

Minutes of meeting

Keep buffer time for every initiative.

To help me further, I keep buffer time for the whole initiative, not irrespective of tasks. Suppose I feel the initiative is vast & it involves changing a critical part of the code. In that case, I usually keep 1 week of buffer for the entire initiative at the beginning itself & I give the timelines also by including this buffer time. There are plenty of things that can go wrong but giving a little extra breathing space helps get through difficulties.

Learning to manage between professional life and social life is very difficult. You will feel like you have lost, and there is no way to come back, but you can come back strong with the help of small behavioural changes. These are some of the things that helped me become a sane developer, manage my day-to-day things, and be productive at my work. I no longer feel overwhelmed with my tasks or dilemmas about deadlines. I have excellent clarity on what’s going on in my initiatives. It also helped me to avoid late-night coding.

PS: This is my personal experience; reach out to me with your thoughts, learning and practices or any disagreements etc.,

Kavya H L

I am a Member of Technical Staff, while not coding I would love to experiment with my cooking and improve on recipes. Love to binge watch F.R.I.E.N.D.S

More of our stories from

The curse of being a Senior Engineer, how to deal with timelines, frustrations, etc

Being a good developer is 50% skill and 50% emotional support; here's my secret to balancing both at the right amount!

How did I build cropping of receipts in the mobile app?

Follow Yash's journey of what it takes to reduce manual work for our customers when receipts come in all shapes and sizes!

How did we increase Data Extraction accuracy by a whopping ~50%?

Wanna know the secret of data extraction, the complex machine learning models we use, the experiments we did? Read on...

The not so secret sauce of my work

From chaos to clarity, follow Chethan's not so secret sauce to excelling at work!

From Zero to Hero: The Policy Tests Journey!

The story of policy tests at Fyle

How Fyle changed my life from a naive intern to a confident Engineering Lead

A blogpost that documents Shwetabh's journey at Fyle.

Vikas Prasad @ Fyle

This document is a user guide to Vikas at work.

Gokul K's README

This document is a user guide to Gokul at work.

How we used AMP Emails to get feedback on AMP Emails!

This blog discusses the how's & why's behind us building a feedback & monitoring system for AMP Emails using AMP Emails


All Topics