Don’t crash and burn! (part 2)
This is part 3 of a 3-part series on my first glance at the professional world. Part 1 and 2 of this series can be found here and here.
On my last blog post, I talked about I (failed to) tackled the big project that I was assigned. In this blog, I will talk about problems that I encountered on the project management side:
- How to not crash and burn ( a.k.a avoid burning out, and maintain productivity from beginning to end )
- Expectation management, and how to give accurate, realistic deadline.
When this project was assigned to me, I have 2 weeks to make it happens. The pressure is immense. It was my first pass in-depth at the application’s massive codebase. I spent a week to read through and understand how things work under the hood. That gives me one week to implement over 15 sections of the application. It’s safe to say that the pressure on me was huge. The week before that, I worked through the weekend for more than 12 hours a day. Still, I decided it’s a great idea to push through the final week. I ended up working over 100 hours on that final week. I pulled all-nighters multiple times, and I have been consistently working on a few hours of sleep every day for a week. I find it interesting that the more I work, the less productive I am. I also tend to make more mistakes and my codes are worse the later I work.
I kept on ignoring the signs of fatigue, and kept pushing. Obviously, I crashed. During one of my long working day, I performed a rebase on a couple of my feature branches. In order to save time, I picked the option for the rebase to recursively accept the remote branch’s version. The maneuver ended up overwriting all of the changes I have made to those branches. I was totally unaware of the disaster, and mindlessly did a hard push to my repo. I lost 3 branches on that day. A major chunks of my work just disappeared into thin air right when the deadline is near.
Lesson learnt: Pace yourself !!! Working long hours do no make you more productive, it just creates more problems to solve later on!!!
Obviously, with the loss of those 3 branches, there is no way I can make the deadline in time. Even though the mistake was made when I was really tired from working long hour, what caused the mistake happened way before the project even started. It happened when I agreed to the deadline. That brings me to the last lesson: how to manage the boss’s expectation, how to give accurate and realistic estimation, and when to say no.
When the project was assigned to me, I was given a deadline by my boss. At the time, I did not have any idea about the workload or the difficulty/complexity of the tasks at hand. Obviously, I accepted the deadline. As I mentioned in the previous blog post, I then went on to tackle the project without any kind of game plan. I just took what is in front of me, one at a time. The benefit of that approach is that it can quickly get you going, making progress. However, the cons trumps the pros in this case. I have no idea how easy or how difficult the next sections are. This approach gave me unrealistic estimation of the project. I happened to pick the easiest section to start with. Thus, I totally underestimated the time needed to do the project, and I did not say anything about the deadline.
Since I did not bother slowing down to plan ahead, I subconsciously forced myself into working long hours, which ended up delaying my progress further. Have I taken the time to fully understand the amount of workflow, and devised the plan, I would definitely tell my boss about the unrealistic deadline. I notice when I make the estimation of the project, I tend to be extremely optimistic. My estimation would be perfect if everything goes as planned. However, it’s rarely the case.
Lesson learnt: Plan ahead, map out the tasks at hand, give yourself some breathing room, and keep everyone in the loop
I would like to end this post with one sentence that I have realized from all of the costly lessons that I had.