Dino Cajic explaining that Software Developers should learn to say no

Software Developers solve problems. Due to this fact, they love to help. This is exaggerated with Senior Developers. Ask a Senior Software Developer for an explanation and you’ll get a proper response. There are outliers, however, from my own personal observations, most developers truly like to help, even if it ends up costing them.

This is a great characteristic to have most of the time. There are situations when it starts to affect them, both professionally and personally.

Solving Problems for Junior Developers

Everyone goes through the Junior Developer stage. You don’t know how to tackle problems. You need experience and you’ll get there; however, when you’re a Junior Developer it may seem like you’ll never grasp it. So, you ask for help from a Senior Developer.

Knowing that the explanation will take longer than solving the problem, Senior Developers will talk through the reasoning and solve the task with the Junior Developer. It may make everyone feel great, but it doesn’t help anyone.

Junior Developers do not get the experience that they need. They need to be able to struggle through the problems. This struggle is what rewires the neurons. Only when the Jr. Developer is fully stuck should the Sr. Developer assist. It’s okay to give them hints but not okay to solve their tasks for them.

The Jr. Dev will feel grateful and the Sr. Dev will feel happy about it, for now. Reward the behavior too many times and it’ll become a pattern, unconsciously. It will also frustrate the Sr. Developer after the 20th time. Senior Developers will be asked “why they haven’t completed their tasks” by management. They may need to work later in order to catch up on their work. Resentment will build up and it’s nobody’s fault but their own.

To prevent that situation from occurring, learn to say no. It doesn’t have to be harsh. A polite nudge in the right direction will suffice. You can wrap it up by saying something like “this should guide you in the right direction but I have some other tasks that I need to take care of now. Reach out later today or tomorrow if you’re still stuck.”

Staying Late to Solve Company Problems

Software Developers have a much better understanding of the software development lifecycle than others within the company. These individuals will see a simple change that they need and ask the software developer for an ETA. The software developer makes the first mistake and says, “that shouldn’t take more than a couple of minutes to fix.”

What the other employee heard was, “I will get off the call with you and will start working on this. I should be done in a few minutes.” How many times have you had the employee reach out to you a few hours later asking for an update?

Even if you’re not working in 2 week sprints, you have a backlog of issues that need to be resolved. Other employees are also waiting for their tickets to be marked as complete. There’s still testing that needs to occur on the staging environment. Nobody wants you to push your code because it may break something on production, so let’s wait until 9:00pm Friday. Developers don’t have a life after all.

Working late is the other one that will start to drive Senior Developers completely insane. If it’s an absolute necessity, hold off emailing until the next day. I’ve had individuals send emails at 9:00pm and ask me the next day at 7:00am if the team has started working on the task. Developers are robots that need no sleep. What else do they need to do besides write code?

Give Realistic Timelines

Expectations need to be set. If you need to reiterate how many items you have in the backlog, do it. I’ve pulled up the backlog and have prioritized their task with them on the call. Clear expectations should be set with everyone. As long as there’s a timeline, most individuals tend to accept that as fact. No need to lose sleep just because you want to make everyone happy.

An experienced project manager normally handles this, but sometimes you don’t have a project manager to communicate this with the staff. Having a timeline that can be shared with the company is pretty critical for your sanity. I’ve pushed back projects for 5–6 months. Watching facial expressions change when I give them a response like that makes my day. I allow them to ask why that’s going to take so long. I pull up the project timeline and tell them this is where their project is going due to priority, “but I’ll be more than happy to discuss shifting these priorities if you believe yours is of a higher one.”

Give and take is what you’ll need to really master. You can’t please everyone because if you do, your work-life balance will suffer. Moral of the story, Software Developers Should Say No whenever it impedes their work.

Leave a Reply