Last week I wrote my cultural evaluation of the past six month, where I have been working remotely from India.
Although that post was divided into many interesting topics about India and how different it is to my home country of Denmark, I felt that it also needed some content about my evaluation of working remote. I basically wanted to write a blog to answer the question: Is Working Remotely Beneficial?
Initially, I am going to assume that you, as the reader, share the same opinion as the rest of the internet. The opinion that working remotely is simply an excuse to get out of the office and not do the same amount of work. (e.g. try and google “remote worker meme” to get the internet’s opinion)
In this post, I am going to analyze my own experience and data from my period as a remote worker, in the hope to actually put some real content into the discussion.
I will start by discussing the main reason, why I believe working remote can increase productivity, in the “Responsibilities of Working Remote“-section. Afterwards, I will highlight some of the “Sources of Knowledge” that I found useful in my position. And finally, I will get down to the cold hard facts, in the “Productivity Results“-section.
Maybe you will be able to learn something? Maybe you want to reconsider your current position and situation? …or maybe you want to start picking holes in my post? Either way let’s make it a discussion.
I quickly learned that the responsibilities of a remote worker are far higher than being in the office. You are solely responsible for your own productivity and results. Unlike in the office, you don’t have the opportunity to sit face-to-face with people and observe their progress, but on the other hand, you’re also don’t have all the interruptions of an office environment.
I made sure to document my productivity through the six months to learn whether or not I would benefit from working outside the office.
I even went to the extent to create a virtual scrum retrospective to hear my colleague’s opinion about my work.
Not shockingly many of them feared that my productivity had been lowered due to lack of communication. However, none of them actually had any scenarios or evidence to back up this idea. It was only based on their assumptions.
Luckily, I had my evidence.
I am proud to say that I have throughout the past six months more than doubled the amount of code that I have committed (more on this later). I have also been able to make some dramatic improvements to the quality of the code as the responsibilities of writing the best possible code had fallen unto me with an entirely different level of responsibility.
In the office, we will often use each other to discuss and “negotiate” the suitable level of code quality. However, when I was alone, I ended up having to read and learn all core concepts of clean code and design patterns. I could not rely on someone else to help me out since I was working 4,5 hours earlier than anyone else.
This is not to say that communication was bad, but rather that I would feel stuck in those morning hours. That is if I was not able to answer those questions myself.
I thank this remote position for “putting the gun to my head” and giving me the motivation and purpose to accelerate my learning.
While talking about accelerated learning, I want to highlight some of the most influential sources of knowledge that I used while in India to improve my productivity as a developer.
In this post, I’m only going to mention my three favorites, but as a side note, the “putting the gun to my head” responsibilities of working remote, actually triggered a great habit of reading educational books.
A habit that I’m sure will be evident from my blog posts’ future content.
Joost Visser (@jstvssr), CPO at SIG (Software Improvement Group), wrote this book to explain how SIG conducts statistical analysis‘ of code sources and how to improve on the measure parameters.
As a start let me say that statistical analysis of code is in my opinion the equivalent of “judging a book my its cover”. Although the analysis does not look into how the code work, it might however still show some valuable points of improvement.
For one, I think that it’s section about unit (methods in Java) complexity is very interesting when acknowledging that your code should have a unit test for each branch (||, &&, if-else-statement, switch etc.) within the unit.
…code should have a unit test for each branch within the unit.
Does your code always comply to this standard.? Likely not. Should it? Maybe? Either way, I think that it is an important question to ask.
PS. I hope to dive into this topic more in a future blog post about unit tests, so look out for that.
After many recommendations and a ton of references to this book in my code reviews, I finally got the last boost of motivation needed to read “Clean Code“.
I will not dive too much into the content of the book, as I have already extensively covered it in a previous post. If you would like to know more, I would encourage you to go check that out.
However, I can say that this book is without a doubt the best source of knowledge that have improved my code-writing skills. Had I not read this book while in India, I would not have been able to get results that I have achieved.
Head First’s book on Design Patterns have also been a great influence for me. The way they explain the patterns in a practical manner, with “relatable” problems, makes it quick and easy to understand an otherwise pretty difficult topic.
Design patterns are in my opinion not really a code-writing skill, but more of a code-communication skill. A skill that allows me to quickly give other developers an idea of my intended development strategy and also allowing them to later on get in the fastlane to understand the code structure, when they have to change or fix issues in the same area of code.
As some might know, I became so fascinated by this topic that I started to make short explanation blogs and videos for design patterns.
…back to the reason why I believe this book was so helpful for my situation. When working while no one else is online, it was crucial for me to know what to do and what other developers intended with their code structure.
Therefore, it was super useful being able to instantly know what the intend was, only by looking at the class’ name (e.g. XyzFactory or AbcStrategy).
Finally, we have reached the point of truth. Can I prove that it is more beneficial for me to be working remote? To answer this, I have separated the results into two categories: Lines of Code-, and Issues-Tracking.
All the data shown below have been spread over the number of hours that I worked, which means that it is basically just a ratio and not the actual data.
This statistic is without a doubt, the one which I am most surprised and proud of. I already had a strong feeling that I was actually modifying more code than before, but I had no idea that it was to this extend.
On any parameter, in this statistic I can say that I contributed with at least four times as much code as before. How come? Responsibility and no interruptions!
When you have been made responsible for learning how to improve your own code (e.g. reading technical books), you suddenly start taking matters into your own hands.
Additionally, I also feel that working remotely removes a lot of disruptions. You do not spend all your time going to meetings and being asked questions. Instead you receive messages online, which you can prioritize and schedule when you want to tackle.
Issue tracking relates to how many issues I have been involved in. Every time I have been assigned to a specific issue, I will automatically be set as a watcher for the issue, even after it has been closed.
Unsurprisingly, based on what we saw in the previous graph, I have been involved in more issues while working remote.
Additionally, we can see that I have also created a larger number of bugs while remote, if we acknowledge that I didn’t participate in any regression testing.
So, what is the major take away from this post and the results of my remote working experience?
Working remotely can be beneficial for everybody.
However, it is based on the idea that the employee will grow with the task and obtain a higher level of responsibility of their work process and effect on the product or service. I believe that many employees will be willing to pay this price, based on the benefits of freedom and time saved on commuting to an office.
I was lucky to be given this opportunity at the right time and with the necessary mindset, in order to gain this level of responsibility.
It may be a scary thought for some people, but I would encourage both employees and employers to start thinking about the advantages of working remote, instead of sharing the “default” opinion of the internet.
My name is Daniel H. Jacobsen and I’m a dedicated and highly motivated software developer with a masters engineering degree within the field of ICT.
I have through many years of constantly learning and adapting to new challenges, gained a well-rounded understanding of what it takes to stay up to date with new technologies, tools and utilities.
The purpose of this blog is to share both my learnings and knowledge with other likeminded developers as well as illustrating how these topics can be taught in a different and alternative manner.
If you like the idea of that, I would encourage you to sign up for the newsletter.