Have you been in a situation where you need to fix a bug and you just do not know where to start or have you already moved the ticket to the IMPLEMENTATION column a few days ago but still have no clue what to console.log? Well, I am 100% positive to say that I have. Today I opened an MR for the bug that took me one month and a half to fix which by the way is a workaround approach because I could not resolve the fundamental cause.
This piece is not really about that bug I’m dealing with. Here I’d like to talk about the things I learned from the back and forth of git branches, environments, and discussions with other engineers.
Transparent communication is the key.
Especially in terms of the time estimation. Don’t forget that you are not alone in this. Oftentimes, you are expected to call others for help. You are not working as an individual. You are working as a member of the team. Being transparent about the progress and time estimation is one of the keys to facilitating development. Usually, telling your PM that it will take more time than what you estimated, in the beginning, is not a great feeling. Still, being professional means that you make your work always visible, facilitate a project with transparent status, be able to provide alternatives, or create room for mitigation.
Organize the context, document your trials, and explain the pain points.
When you collaborate with other stakeholders, what is important is that you are not coming to the check-in meetings or pair programming sessions with empty hands, saying ‘Hey this is not working, do you have any idea?’. While debugging, I had to go through several pair programmings with my team lead, dev ops, two FE engineers. From the moment you are assigned to the ticket, it is your responsibility to learn about every detail of the issue and dig into it so that you can explain the context and the pain point that you want to solve with your teammates.
Organizing your understanding of the background of the project and the context of the issue is an important skill in software engineering in general, but when you are debugging or collaborating with others, it is especially highlighted. When I am in the creative flow of experimenting with different approaches, oftentimes I tend to forget the approaches that have already failed and repeat them nonetheless. I call this ‘Oops I did it again moment’. It goes like this: ‘Maybe this is the angle I should try.’ → ‘Right, this does not work because of A, B, and C’ → ‘What about this one?’ → ‘Of course, it does not work because of A, B, and C.’ → ‘Okay.. then what if I …’ → ‘Oops I did it again.’
I guess the process itself is nothing bad. Actually, it helps me understand and refine the issue and that is exactly how I get to the point of ‘Aha!’. However, when you press pause on things you’ve been doing and have to get back to them later, you would not want to repeat the same trail of thoughts, simply because it is redundant. Especially when you have to hand the task over to another engineer, documentation of your previous trials and findings will be absolutely powerful.
It is okay to come back later.
It is undoubtedly better to be able to come up with some kind of an alternative approach than to let it on hold(without anyone knowing!) when you are stuck for days without breakthroughs. It can be crappy codes, pass the task to a senior engineer, split the task smaller and start from there, or try to mitigate design or feature requirements with stakeholders and ask for input. (Your strategy may differ on your team’s priorities or workflow.)
It is not that you lack responsibilities or you are not competent. It is the opposite. You are taking ownership. Having ownership starts trying to understand priorities. It is about sharing the process with transparency, asking support when necessary with clear questions, and supporting others to solve the issue more efficiently with well-documented trials and errors. Debugging is hard. Sometimes responsibility is heavier than you’d want it to be. Well, what can I do about it? Not much, really. I just try today and get back to it tomorrow.
