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.
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.
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?
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
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 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.
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.
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?
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.
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.
Letting people figure out the answers on their own all the time rather builds a competitive, toxic, individualistic culture in the company. A team is not a bunch of people working in isolation, it’s a unit where ppl have each other’s backs all the time.
There is a difference between “it’s your problem, figure it yourself” and “ok, you didn’t found an answer on your own for an hour, let me help you”. Thankfully, I did not suggest anything like the first one 😉
Great article! I really like this approach. So, when you know that coworkers and teammates are reading that – would be an idea to wrtite a article about what they think?
I mostly agree. I too think the process of figuring things out is valuable, you learn a lot more from 100 failures and finally a success than you would from getting the answer handed to you. That’s mostly how I learned things, and I tend to expect the same from others.
And I also appreciate the point about being interrupted mid-flow.
That being said, if your co-workers are the sort of people who spend an hour/day trying to figure something out before finally asking, you aren’t doing them any favours by making them wait for no reason (again assuming it’s not interrupting your flow). I generally dislike asking others for help, but I will when I either have exhausted my ability to figure it out, or when it makes sense to do so (it’s not something within my domain and they will know it off the top of their head). In that case I wouldn’t appreciate someone intentionally waiting an hour to get back to me simply to give me more time it figure it out myself – if I could have I already would have.
Thank you, I appreciate your comment. And yes, I agree. There is no “one size fits all” solution. It requires knowing your colleagues to know if they ask first, or ask if they run out of ideas themselves.
What may have not been clear in the post, I do not let others wait for the response “just because”. If I’m not in the flow and I’m doing something that does not require uninterrupted focus, I’ll respond right away 🙂