Help Guide For Engineers

This article is suitable junior or senior engineers; even if you are not, feel free to read and forward to your team

Helping others

Every team has a fall-back engineer. Someone who is assigned to fix the road blocks. I was just promoted to a senior engineering role and I became the fall-back guy. I enjoyed the role for the most part, but hated when situations did not call for a fall-back.

Take for an example, on a usual monday morning, my manager came to my desk. He asked me to go and help someone who was stuck. I went to help the person, only to realise there was nothing wrong. For some reason, that person thought the program wasn’t working, may be the tens of versions of the program confused the person. I was upset.

Similar stories continued for a few years. Again in a few years, things changed a bit. Instead of my manager connecting me with the team members, now they directly came to me. On a usual day, I would get several engineers reaching out for one or another problem. At the same time, my responsibilities on other front were growing. I was living a nightmare.

The problem? Not just others but I played my role in it. Let me explain how -

I was used to working alone when it came to problems. That’s the only way I could think. So when anyone came to me for a problem, I took details of their code repo and asked them to wait till they hear from me. I would go into my shell and resolve the issue. Send updated code to the dev and that would be the end of our interaction.

I created a hole for myself. These devs started thinking, I have some trick up my sleeve and depended on me.

I failed to educate them how to think about solving a problem, how to approach and research on it. There isn’t any magic, it’s just about breaking down the problem. Most of them were just starting into career with a couple of years, and needed guidance instead of spoon feeding.

I didn’t have patience. I also thought teaching them was not my job but the leads. I wasn’t a lead yet.

I learnt the hard way. I realised that helping the junior team members get better, will only help me do more challenging and interesting work.

New approach

Step 1: Instead of asking for code repo, I started asking about things they have tried,

Step 2: Shared a few pointers to try some approaches

Step 3: If that did not work, I sat down with them for a few minutes (10-15 mins) to see if something could be done quick. It was either me on the laptop walking through the steps I am taking and why I am taking. This was also an opportunity to teach things you would otherwise don’t. Like why a browser sends an OPTIONS request.

Step 4: If we can’t reach a solution in 15 minutes, I ask for code repo. I go back to my desk, do what I do. If I manage to solve the problem, I walk the team member through steps I had taken in minute details possible.

Asking for help

Early in my career, in my first job, I walked to my reporting lead, to ask a question. The person was furious, asked me to do research first and come back. I was just a few weeks in the job, I was offended. My ego was triggered, I started self-learning things, spent hours going through code, after all I didn’t want someone to bash at me. Google was my friend and the existing code written by others was my book.

I wasn’t solving any problems though, at least as fast as I should have. My lead will come, talk for a few minutes. But that interaction was a catalyst. It will lead me to a direction, taking me a step near the solution. Our conversations matured, I was able to resolve problems in days instead of weeks.

My second job, I joined a star project. Untill now, I assumed that my job was technical, and I need not learn the business side. I went up to the new lead, to ask a business question I need answer for. He asked several ‘Do you know x?’ sort of questions in response. I had no answer to them.

He asked me to learn those topics first before wasting his time. I was again offended, I went back with a mission to find the answers myself. I also had access to customers, so that helped a lot. Next few months, I studied financial accounting so I could talk to the customers.

Things the school of hard knocks taught me

• Walk together when helping someone or share the map if can’t
• You can’t put a boundary around your learning
• Programmer needs an ego when asking questions
• and Patience when answering others