Don't help others (immediately)

Published on July 1, 2021
Contents

I know my coworkers and teammates are reading this, and probably my boss as well. But let’s risk it.

If you only read the title and few first sentences to came to conclusions, here you go: as a senior developer, when asked for help, don’t rush to answer.

But if you don’t want to be an 🅰️-hole unjustifiably: continue reading. Maybe there is a method in this madness.

The Context

You are a software developer with noticeable experience. Senior, Lead, Principal, Rockstar, whatever they decided to call you in your current startup, company, or corporation (whatever they decided to call themselves). On top of that, you also have good knowledge about your project. You may be in it from the beginning, or just for the last three months, but you know what’s what. You are an experienced developer, after all.

You, of course, do not work alone. You work in a team. And this team, sooner or later, will have a junior or mid developer. After all, they should learn from the best, right?

Jokes aside, no matter if you are the smartest guy (or girl) in a room or not (hopefully not, that’s better for you), you will receive questions and requests for help. Most of us still work remotely in those beautiful COVID times, and many of us will still work remotely when things go back to normal to a new normal. That leads us to numerous Slack (or MS Teams, you poor soul) notification sounds and bubbles.

The Why

Now I will try to persuade you to ignore those bubbles.

The First Why – It’s Good For Them

I was working on some particularly interesting new feature. I was deep in the code. I didn’t want to be distracted. You saw this relevant not XKCD a hundred times, right?

Why you shouldn't interrupt a programmer

So, I just ignored a question about “how to do X in Y” from a teammate. Yes, sorry. I’m a “developer” first, “senior” later, and sometimes coding absorbs me completely.

After an hour (ok, hour and a half), I committed my changes and looked at Slack. I spent the next 2 minutes writing an elaborated response on how to do X in Y. If you look at this post and my other articles, you will know that I can’t write short. This also applies to emails and Slack messages. Sorry to everyone that work’s with me.

Anyway, I hit enter only to get “yeah, I already figured it out, thanks” in response.

Ok, that’s amazing. I knew I was not talking to some stupid, but just someone with less experience. Instead of spending time on Reddit something else waiting for my help, he pursued trying to figure it out by himself. With success.

Could I save him an hour? Yes. Would it be better if I do so? No.

Now read carefully because I’m (finally) getting to the point.

Programming is about solving problems. We learn the most when we solve problems on our own, going through them step by step. When we get the solution right away, we lose a lot.

It’s not like, “I learned to program the hard way, so must you” – quite the opposite. I will do much to share my knowledge. Just sometimes, it’s not the best thing to do. Really, there are psychological papers on that (google “generation effect”).

What else? I did the same with few other people in the following weeks, more or less consciously. With similar results – 4 out of 5 times, they already solved the problem (correctly!) when I responded. I work with wonderful people, I know.

Of course, I always try to answer in 1-1.5 hours max.

And to be clear – it’s not like those people asked trivial “let me google it for you” questions. Those were legitimate questions asked to unblock the work. But you know, most blockers are in your mind…

The Second Why – It’s Good For You

This is far more prosaic and well known. At least in theory.

While it may be hard to deal with that exact situation in real life, why do we allow such distractions online? Email, Slack, Teams, … Maybe it’s not other people begging for our immediate attention, but rather those apps to prove themself worthy? (Insert Philosophy Dinosaur meme here.)

No matter how urgent or trivial the message is, it breaks our concentration just as much. And in effect, it slows us down. So do a favor yourself and whoever pays you, and separate your focus and not-focus time.

This is not only to deliver more story points in the sprint. It’s is also for your mental health. Seeing you still didn’t complete this simple feature, although you “worked on it” for the whole day, can be frustrating and make you question your abilities. Maybe rightly, but not necessarily the engineering abilities are the one faulty here.

The Third Why – It’s Good For The Company

Was that hour my colleague spent having to find the answer on his own a wasted hour for which my company or the client paid? No. It was not wasted. That person will continue to work on that project and in the same technology. An hour spent now that resulted in extending knowledge will save much more time in the future. My company understands that, our client understands that, would be great if everyone everywhere would understand that.

Encouraging people to look for the answers by themselves builds a problem-solving culture instead of the ask-immediately culture. The latter is especially dangerous if you have (or you are) that one god-like person in your team that knows everything on the given project or technology. Why even bother googling, if you can just ask? Well, because otherwise, you build a Jenga tower stacked on a single block. Looks good, but everything will fail when you take it out.

I don’t like generic images in tech articles, so here you have a Reddit post illustrating the problem.

I know some people will ask too soon, others will ask too late. For now, this is a solution for the first kind. I will let you know when I find the solution for the second.

The Limit

Helping others is essential. That’s why we work in teams, to build something together. So don’t go offline for the whole day. Check Slack regularly, respond, and help if needed. Regularly, not constantly.

The Exceptions

Before you happily disable Slack notifications, let me worry you. There are situations when this is not the best strategy.

Primarily with interns and juniors. When they are new to the project and have low (or none) experience, having a problem can mean they are completely stuck. An hour or ten will not make a difference for them, and they may need just a link to the right documentation page to unblock. For some time, you need to pay more attention and spend time to fill them in on everything. That’s the “buddy” role, right?

Secondly, no one will welcome your productive coding session during the critical production release or something of similar magnitude. But you know it, don’t you?

The Conclusion

Check your OS. It probably has this little “do not disturb” button. Enable it for one hour, make your favorite tee, and write some code. Then handle all accumulated messages and enable it again. And code.

Every time I see "do not disturb" I think about this (source)

Even if that sounds easy to do, you may feel some guilt at the beginning. Overcome it. And well, nothing prevents you from sending a word to the team before, right?

I know that this text can be misinterpreted in a hundred ways. I hope it won’t, despite the slightly clickbaitly title.

And finally – I did not discover anything new. I bet thousands of effective developers are already doing what I described above. But somehow, no one let me know about it? Or I just missed all the blog posts and decided to write my own.

Category: Other