diff options
Diffstat (limited to '')
| -rw-r--r-- | posts/remote-work.njk | 165 |
1 files changed, 165 insertions, 0 deletions
diff --git a/posts/remote-work.njk b/posts/remote-work.njk new file mode 100644 index 0000000..4a80bd6 --- /dev/null +++ b/posts/remote-work.njk @@ -0,0 +1,165 @@ +--- +layout: post.njk +title: A Busy Bee's Guide to Remote Work +tags: post +--- + +<p> +One of my goals in life is to create an online cookbook. I want to record and share the unique personal stories behind recipes from different cultures around the world, and this is why I have been traveling for the past three years. To be able to do this, I needed to make remote work work. +</p> + +<p> +To finance my travels, I work four days a week as a programmer for Baemingo, a Swedish start-up, where I build restaurant POS systems. My previous position was also remote. I have needed to make remote work work, to prove to my employer that I can be trusted and to prove that you can get just as much work done working from a cafe in Bengaluru as you can in an office in Stockholm. +</p> + +<p> +In order to make remote work… well work, rethinking my workflows was essential. The results of which I will present here. +</p> + +<p> +One of the key benefits with remote work is that to do it effectively you must master the art of documentation. While documenting seems to not be a benefit but a drudge, I think it is a benefit, both for you and the organization. Your ability to quickly chat with your colleagues and ask for help is limited when working in different time zones. People will not always be available to respond while you are working. Those in favor of in-office work see it as a reason why remote organizations cannot work. I actually think it allows for a different style of work with its own set of advantages. <a href="https://about.gitlab.com/company/team/">Gitlab manages to have thousands of employees all over the world in a fully remote setting</a>, the Linux kernel development is a fully remote. How do they do it? In order to cope with longer response times and less back and forth, proactive documentation and async communication has to become the norm. Not being available always is a blessing in disguise: it reduces stress levels, gives you time to focus and plan your day to your accordance. In the book <i>Deep Work</i>, Cal Newport claims it takes up to 15 minutes to refocus from a single distraction. So less distractions = more work done, at least in theory. +</p> + +<p> +When remote work is done correctly, the documentation you get from async communication reduces the redundancy in requests, making people more autonomous and less distracted. Different forms of communication allow for more thoughtful discussions and longer lasting understanding of the domain. The documentation you leave will linger on, even when you are no longer at the company, which is not the case in informal office discussions. Companies benefit greatly from this continuity, reducing losses in expertise created by churn. +</p> + +<p> +An organization that manages to embrace a culture of remote work will see this benefit, all the while unlocking a greater pool of talent by lifting geographical limits. At the same time, providing greater flexibility and giving better work life balance for workers. It can be a win-win for both employer and employee. However, it requires new ways of thinking both for the employer and the employee. In this article I will explore the latter. +</p> + +<p> +My overarching idea to being a good remote worker is that you should 1. Write a lot 2. Identify the platform(s) your communication needs 3. Centralize all your communication. +</p> + +<p> +Let’s dive into each point. +</p> + +<h3>Write a lot</h3> + +<p> +To keep track of all I am up to, I use a technique called <i><a href="https://nesslabs.com/interstitial-journaling">interstitial journaling</a></i>. It is straight forward, you have one page for each day, make a new line for each item, note the time and add your current thought or action. At the top of the page, write the location you are at. +</p> + +<p> +The journal allows me to reduce my stress levels while juggling work, side projects and personal life. Trying to keep everything in my head is a recipe for disaster. When having 1-on-1s with my manager, my journal allows me to pull up a lot of material to report on, as I can say exactly what I’ve been up to, what has held me back and we can have productive discussions on how to continue. When you work remotely, there is no one who looks over your shoulder and sees you are working. That means that it is up to you to communicate clearly about what you have been up to and so my aim is to give transparency and peace of mind to my manager. All the material I provide has been greatly appreciated at my job, with people telling me repeatedly about the trust it instills in them and how they feel inspired to do the same. +</p> + +<p> +A lot of what I write down in the journal gets converted to documentation. Documenting while doing my work is much easier than trying to write it later on as we do a lot more than we think we do, our brain naturally filters out much of it. +</p> + +<p> +To create my journal, I use Emacs + org and org-journal. Having my journal integrated with my coding environment makes adding new entries very quick. Org works well with Logseq, so I make use of that for sync and also to be able to take notes wherever I am. Ideas usually pop up at random and it is great to write them out of my head so I can focus on what I am currently doing. +</p> + +<p> +The journal entry for one day ends up looking like this: +</p> +<pre> +2023-08-19 +City: Bangalore +Country: India +- 09:30 People are not testing their code properly. + This needs to improve. tag:retro +- 10:45 Completed feature X. tag:achievement +- 12:45 Maybe write article about remote working? + Feels like it could be interesting to people. +- LATER Write an article about working remote +</pre> + +<p> +I make sure to track and write down the following items, as they are what I find myself regularly coming back to: +</p> +<ul> +<li>My mood</li> +<li>Learnings</li> +<li>Setbacks</li> +<li>Decisions</li> +<li>Reflections</li> +<li>Achievements</li> +<li>To-dos</li> +<li>Processes/how-tos</li> +<li>(Since I travel full time) My location</li> +</ul> + +<p> +Tracking these things naturally makes me write more, a habit I am trying to build. Journaling gives me material, habit and a continuous practice for written communication. It allows my managers to get a better understanding and trust into what I do. More documentation means that we reduce the need for synchronous communication, as people can read what has been written instead. +</p> + +<h3>Identify the platform(s) your communication needs</h3> +<p> +Getting into the habit of writing and documenting was the first step to improve my remote workflow. The next step is sharing the information through the right medium. Certain platforms allow you to better search, process and archive different types of information. Slack is tempting to use for all communication but is not necessarily the best. Slack shines for synchronous communication, I.E. quick messages like “Are you joining the meeting?”, “How are you feeling today” etc. However, Slack has terrible search functionality and threads do not work for discussing various topics, as you often end up discussing multiple topics in a single thread making harder to understand what is being discussed and causes confussion. +</p> + +<p> +At work we use Jira, Github, Slack, Notion and GSuite. It is not necessarily the platforms I would have picked myself for managing a remote organization, however as an employee, I try to make the best of the tools that are available to me. This is how I break up my communication in each platform. +</p> + +<h4>Discuss and manage projects on Jira</h4> +<p> +Jira’s interface ties discussions to features. Each ticket can have its own discussion and state, meaning it’s easier to understand the status, scope and all discussions pertaining it at a glance in one place. This also means that if someone takes over that feature later or wants to look back at what has been done, everything is nicely archived and packaged. +</p> + +<p> +If people are tagged in discussions, they also, unlike on Slack, receive emails which they can respond directly to. +</p> + +<h4>Discuss PRs on Github</h4> +<p> +In Github you can comment on specific lines of code, which means that you can more easily +focus on different parts of the code and have multiple topic active. I usually document my PR in git commits, where each commit explains the change of that specific commit. +</p> +<h4> Discuss proposals on Notion</h4> +<p> +Discussing proposals on Slack means that archiving and understanding why decisions were made become harder. Usually, proposals serve as great foundation for documentation later on. Slack's limited thread capability means also that you often have multiple topics going on in a single thread, making it very hard to respond to each issue at once. If you keep your discussions in Notion or Google Docs, you can easily comment on specific points and suggest edits. You can afterward refer back to those discussions back in a JIRA ticket with a single link. +</p> + +<h4> Documentation on Notion</h4> +<p> +Notion makes it easy to comment, search, edit and give feedback. Much better than telling people the same things over and over again. +</p> + +<h4> Schedule time with Google Calendar</h4> +<p> +I often run into people scheduling meetings using Slack instead of Google Calendar. Using Slack increases the risk of confusing time zones and causes a lot of back and forth as you try to schedule a time. Google Calendar supports setting working hours, suggesting new meeting times, accepting/rejecting invites and seeing other people’s calendar. It is much faster to look at someone’s calendar, have time zones automatically converted to your local timezone and suggest a time. +</p> + +<p> +By using the correct medium when communicating, we improve the efficiency of the communication, reducing the need for back and forth, confusion and the risk of vital information being lost. +</p> +<h3> Centralize Communication</h3> +<p> +With all these different platforms being used, it will quickly get difficult to keep track of everything and be on top of all requests. Centralizing notifications into one space becomes critical. +</p> + +<p> +Email is still the best option to centralize notifications as every single platform has integration with it (except Slack’s super limited email capabilities (grrr), I would never use it if it was up to me). Github notifications, Jira notifications and Notion notifications all support email. Some of these platforms also allow you to respond directly via email, making it so you do not even need to load their slow web-page. Many email clients also support responding offline, which is a nice feature if internet is spotty. Email allows you to keep track of what is going on in different channels and keep yourself updated in one place. +</p> + +<p> +I currently use <a href="https://www.djcbsoftware.nl/code/mu/mu4e/index.html">Mu4e</a>, but if you're not a regressive terminal hermit like me, you can use <a href="https://www.thunderbird.net/en-US/">Thunderbird</a> or Apple Mail to handle your email, they are great clients. +</p> + +<p> +I make heavy use of labels, and fashion my inbox into a sort of to-do list. Once I have responded or completed the task within the email, I label the mail and then archive it. This is a lot easier to manage then Slack’s various platform integrations, that tend to force everyone into the same setup. Mail has a lot more capabilities to manage your own setup, use your own tools etc. It might be old, but it is still around for a reason. +</p> + +<p> +Once you have managed to centralize all the communication, you will feel a lot more like you are on top of things. +</p> + +<h2>Conclusion</h2> +<p> +So this is how I make remote work for me. I make sure that I build positive habits, document and learn the social tools that are available to me. +</p> + +<p> +As a programmer, I have invested a lot of time into learning the tools that I use for coding. However, it is only when I started working remotely that started learning about the tools that I use to communicate. Oftentimes we only scratch the surface of what collaboration tools like Github, email, Slack, Jira, Trello etc. are capable of, yet much of our work is social. Given that we communicate so much, is it not better then to learn these tools properly? To learn to communicate effectively? Just as we invest time learning excel, word or code editors, so should we invest time in learning the tools we use to communicate. Remote work made this investment essential for me, and in investing this time I unlocked these tools' real powers, allowing me to build a lifestyle that was never before possible while at the same time allowing me to contribute even more than I did as an on-site worker. +</p> + +<h2> A side note for programmers</h2> +<p> +In many ways, I think about communication mediums like data structures. While it is tempting to use hashmaps and arrays for every problem, they are not necessarily the best representation of the data we are working with. Instead, I can use sets, trees, enums, relational structures to more easily solve my problem. The same logic applies to how we communicate. Synchronous is basically the array of communication, easy and works for most forms and so we try to apply it to way too many forms of communication. Different platforms make certain types of communications easier or harder, so I try to think about which one makes the most sense for the message. How will I query it in the future? +</p>
\ No newline at end of file |