Sometimes, it's better to not do your work
November 20, 2019
It’s 11 o’clock and I am finally doing my own work…
I typically say this line to my colleague almost every day. I used to mean it (albeit satirically), as it could be draining coming into the office and instantly being dragged off to assist others. Now though, after saying that line a lot of times. I realised (after it was pointed out) that the impact I make while helping my team is probably higher than what I would achieve plugging away at my own work.
These are some of the things I get up to instead of focusing on my own work:
- Answering slack questions (Open Source project)
- Answering any other sort of questions
- Debugging code with colleagues
- Discussions about features (not necessarily ones close to me)
- Reviewing blog posts
While I am sure there are more to list, my mind has gone completely blank now I am trying to write some down. If you were to put your own list together, I imagine a number of those would make the cut. It’s also highly likely there are things you do that I haven’t put here.
So, why am I even writing this? Partially for myself, to note down my stream of consciousness as I think about this subject. Primarily, for you, to feel more validated and correct in your decisions to assist your colleagues or anyone else you choose to support.
As I mentioned at the beginning of this post, you can have a more significant impact by assisting someone instead of focusing solely on your own work. Obviously, this is not a rule, and there will be times where you can have a large impact by going solo. But, in my opinion, those times are far fewer.
To see what impact can be made, let me expand on areas I tend to help others with:
- Answering slack questions (Open Source project) - Very often, some questions are asked that I can answer with the snap of my fingers. But, that short time spent can be magnitudes smaller than what the asker might need to spend to figure it out themselves. They might have already spent hours trying to find the missing piece. Pointing them in the correct direction could unlock them to continue working productively. This is not just good for them. When participating in an Open Source project, it is also good for the project itself. As there is now one more person who is closer to successfully building a product on top of the project.
- Answering any other sort of questions - Similar to the point above, but focusing on more internal questions from my own colleagues. The impact is the same, but the questions might be more precise. I might know the answer, and I am saving a lot of time by giving it to them or suggesting some things to look at.
- Debugging code with colleagues - Being a living rubber duck, I can provide slightly more feedback than an actual rubber duck. Allowing colleagues to talk through a problem can break down the mental roadblock in their way. At the same time, it is an excellent opportunity to provide suggestions and general knowledge about the code that is being looked at. In doing so, knowledge is moved out of a single person and can continue to be shared. The colleague that received some help might now be able to help someone else further down the line. Heck, they’ll probably tell me what I told them after I have forgotten it.
- Discussions about features (not necessarily ones close to me) - Again, this one is quite similar to the point above (debugging). I remember sitting with one colleague, for a few hours, with them talking at me. Every now and then I would ask a question. They might be stupid questions. I mean, I really was out of my depth and barely understood what we were discussing. But apparently, I am a really good rubber duck. Once we finished, they thanked me and claimed it was extremely helpful. So, somehow, it seemed that I made an impact without really grasping what we were talking about. Nice, I guess…
- Reviewing blog posts - This is the one that is probably the least common from the list as it depends on your role or company. It involves reviewing the content and grammar of a post, along with suggesting other improvements. I find it quite a challenging task, but it is really satisfying seeing readers enjoy the writer’s post. The impact here is firstly the refined post that comes out. Secondly, by providing suggestions and indications on small mistakes that are often made, the original writer can produce better and better content. Allowing them to take the step from already creating good content, to potentially great and stimulating pieces.
Now, I realise I have spent the whole time talking about what I do…Unfortunately, it is the easiest way for me to get it down in writing. To correct this, I want you to rethink what you just read in the points above and switch all the “I”s with “you”s (or read it in first person from your perspective).
These points are things that you do.
These are areas that you impact others.
These are ways you are effectively spending your time to lift other people up.
What seems like small amounts of your time can allow others to move past the problem they are facing. More importantly, this time could have a significant impact on their output, outlook and ideas moving forward. You should realise how valuable your time is, and how sharing that time can spread out your reach far and wide.
To close this off, let me reuse the quote I opened with:
It’s 11 o’clock and I am finally doing my own work…
Go ahead and say it. But, don’t say it in annoyance. Say it as a statement highlighting the impact you make on others.
Java friendly Kotlin - static functionsMarch 18, 2020
In this post, we will look at writing static functions in Kotlin that treat Java callers as first-class citizens. Recap There are three ways…
Defined by failure - How failure fueled my improvementFebruary 27, 2020
I am going to go with a more personal blog post today. This is something that I have wanted to write for several years now. Better late than…
Calling Java Functional Interfaces from KotlinFebruary 10, 2020
Basics Below is a Functional Interface defined in Java: Note, that an interface does not need to be annotated with to be treated as one. In…
Serializable Java LambdasJanuary 24, 2020
Recently I was presented with the following error when serializing a lambda with Kryo: If you do not recognise the syntax, don’t worry, it…
Responder flow validation (part 3 - overriding)January 06, 2020
To finish off my trilogy of blog posts on including validation inside your responder flows, I present to you the final topic. How to…