Skip to main content

Command Palette

Search for a command to run...

Never Give Up on a Work Colleague

Updated
2 min readView as Markdown
Never Give Up on a Work Colleague
P
I am a full-stack developer specializing in React, Next.js, TypeScript, C#, .NET and Sitecore. I love working on back-end as well as front-end, writing documentation, finding solutions to problems, and writing technical blog posts to help others. I've been Sitecore certified and Coveo for Sitecore certified twice.

I once worked closely with a team lead on a .NET project. We were working together to find out why a function we were implementing wasn’t working. This function was fetching hundreds of thousands of records from a SQL database to determine if any were missing. After deploying it to the remote server, we ran the function and noticed it was running out of memory, but it wasn’t when running it locally. The team lead insisted that it was a defect with the code and we had to write it differently, but I disagreed with them since it worked fine locally. I insisted there was a problem with how the remote server was handling the request.

The team lead responded with “Well, good luck”, and I didn’t hear from them again about this task. This person was clearly done helping me and essentially their message meant, “good luck, you’re on your own, I am not helping you anymore”. This is precisely how you set a bad example as a leader.

I have no objection to working on issues and solving problems by myself. I do it a lot in my day-to-day work. However, before this series of events, I never had a technical leader give up on a problem they were trying to help me solve. The messaging has always been “sorry, I’m busy right now, I’ll help you later”, or “I don’t know how to fix this problem”, not “you’re on your own, good luck, don’t message me again”. The team lead, not agreeing with my viewpoint of the problem, declined to help me any further.

Ultimately, the out of memory issue was due to how the remote server’s software handled child processes that were spun up from our function. When running the function on the server, these processes took a long time to complete, which caused the memory issue. The real solution for this may have been to write a single function that handled all of the processing logic without assigning workloads to child functions, which, funnily enough, was what I had at the beginning, before the team lead made me rewrite it.

The lesson here is to never give up on a colleague in need. Everyone gets busy with their own work, but to flat out give up on someone you were helping is setting a bad example. I myself have been guilty of this from time to time. I also think developers in leadership positions should swallow their pride and simply work together to solve the problem at hand, or at least move the yard stick a little. What do you think? Let me know in the comments.

12 views