今日推薦開源項目：《人類時間 HumanizeDuration.js》
今日推薦英文原文：《The Software Engineer』s Guide to Avoid Work-From-Home Burnout》
今日推薦開源項目：《人類時間 HumanizeDuration.js》傳送門：項目鏈接
推薦理由：在代碼里，絕大部分時候時間都以毫秒的形式存在，但是一旦時間需要顯示給用戶，就需要把毫秒轉換為時分秒這樣簡單易懂的單位。這個項目可以幫你實現這一點，同時還額外提供了改變輸出使用的語言與對輸出格式做細微調整的功能，比當場手寫實現一個要方便的多。
今日推薦英文原文：《The Software Engineer』s Guide to Avoid Work-From-Home Burnout》作者：Ekrem Aktaş
原文鏈接：https://medium.com/better-programming/the-software-engineers-guide-to-avoid-work-from-home-burnout-b5d887601641
推薦理由：一些能改善在家中工作產生的不便的建議
The Software Engineer』s Guide to Avoid Work-From-Home Burnout
Strategies to improve your productivity and happiness at home
Software engineering is one of the most suitable professions for working from home (WFH). But even though software engineers seem to enjoy working from home, there are signs that it may decrease productivity. For example, a case study reports that WFH might hurt developer productivity on large projects. Another analysis performed by Microsoft on its employees working from home found a new 「night shift」 forming up — often to catch up with work, leading to burnouts.There are many aspects of WFH that can decrease your productivity and cause burnouts, but I want to focus on two of them.
The first is avoiding distractions and keeping yourself focused on the task. Focusing and being in the zone is the ultimate recipe for productivity. But focusing on the work in your room is not trivial when large tech companies are racing to get your attention with every notification popping up on your phone or your kids demanding your attention.
The second problem is communication. Many companies met with remote work for the first time in the COVID-19 pandemic and didn』t have a remote-first work culture. Most of them are still operating WFH with the 「office」 mindset, which depends on synchronous communication. But the companies with a remote-first culture, such as GitLab and Basecamp, embrace asynchronous communication instead. Unfortunately, most software engineers now need to adapt to WFH with 「office」 culture until their companies embrace asynchronous communication.
As a software engineer, those issues can decrease your productivity. Here is a list of suggestions to tackle them.
Take Zoom Meetings Outside
Virtual meetings decrease your productivity for two reasons: Keeping yourself focused during virtual meetings is tough, and many things can distract you.Do you 「zoom out」 while having meetings on Zoom? You』re not alone. Focusing on a virtual meeting requires more effort than a regular meeting. Staring at the screen and camera simultaneously for hours to show that you』re paying attention is exhausting. It even has a name: Zoom fatigue.
Did you ever notice the person who works secretly during Zoom meetings? You can easily see that from their face, which often looks dull and steady. No, don』t blame the victim here. It』s easy to fall into the trap of multitasking — many people do it while checking out the notifications on their phones as they speak to friends.
Did you have a 「no laptop during meetings」 rule back at the office? Some companies have it to ensure that people aren』t distracted with their work during meetings. But that』s what we do during virtual calls. We join meetings with laptops. Unfortunately, we join them without even leaving the table. Walking over to a meeting room in the office helped us switch context from whatever we were working on to the meeting』s agenda. That』s no longer the case with virtual meetings, and we have a hard time switching context without standing up from the chair.
Have you ever tried having a physical conversation with a person looking at your belly instead of your eyes? Go ahead and try it. That』s what we do every day on Zoom.
All the difficulties above have two common parts: video and distractions. And here is a controversial solution: Join a Zoom meeting from your phone with video disabled, and go outside.
When you join a Zoom meeting without video, your meeting turns into a phone call. Phone calls feel more natural than video conferencing to us because we』ve practiced them since we were kids. Now you can focus on the meeting without looking at the same region of your screen for an hour.
Taking a stroll outside the house with Zoom meetings has many benefits.
First, you get rid of all distractions that your workstation can cause. You don』t have to look at a screen. There are no unread emails or Slack messages. Your phone is in your pocket (hopefully). It is you and your headphones. You can focus on what you hear in the meeting.
Second, walking is a real life hack. That』s not because it』s healthy but because it helps you think better, increase your working memory, and boost your creativity. You increase your productivity and cognitive abilities by walking because your heart pumps more blood than sitting. Your brain takes advantage of the extra blood flow. You become smarter by walking. Why not take advantage of this with meetings that need mental power?
And lastly, you feel better when you take a walk outside, helping you cope with the WFH burnout.
Have a Zoom Meeting Running in the Background With Your Teammates
Focusing on work is easier when you work with others. That』s why pair programming works — it helps both the driver and the navigator stay in the zone, and makes them less vulnerable to distractions.You can apply a similar technique by having an always-on Zoom meeting with your teammates, but with everyone muted. This helps to simulate an 「office」 environment. Everyone can focus on their tasks, like in the office. Anyone with a question can unmute and start a conversation at any time.
Limit Hours in Meetings
A benefit of remote work is that we don』t need meeting rooms anymore, but that』s also a curse. Previously, meetings were limited by the physical availability of meeting rooms. We used to postpone meetings when there were no available rooms.When a resource is scarce, you care more about how you use it. There wouldn』t be useless or optional meetings, just because finding a room was hard.
With WFH, you are always working from the 「meeting room」 because the physical constraints no longer apply. Teams can have meetings at any time, anywhere. A study performed by Microsoft reports that 「too many meetings」 is the number one challenge software engineers encounter during WFH.
Limit the time you spend on meetings daily. Schedule the available time slots left in your calendar once you』ve reached your meeting limit for the day. This way, meeting organizers will have an incentive to choose another day where you』re available for meetings.
Another approach is to declare meeting-free days. Microsoft reports that 73% of participants said 「No-meeting Friday」 improved their wellbeing and 77% reported it gave them more focus time. Of course, this is not something you can decide for yourself, but you can start a conversation in your company.
Work on the Most Important Task First, and Make Sure You』re Not Interrupted
Back in the days when I was working in the office, I used to start my day by 「catching up,」 checking my inbox and pending Slack messages first. I could easily spend an hour with it. Now I realize that it was a total mistake.According to research, we are self-distracters: We check our email and IM every six minutes, thus hijacking our focus. It is more hazardous when you check pending notifications at the beginning of your workday because you lose control of your day from the beginning. You often respond to the pending messages immediately and may spend hours on tasks that you did not plan for your most productive time slot.
Instead, treat the first two hours of your working day as focus hours. Dedicate this time slot to work on the most important and challenging task that requires focus and cognitive power. This is a sacred time slot: no notifications or distractions are allowed. Things you can do during the focus hours:
- Silence all IM and email notifications
- Write code for challenging stories
- Perform non-trivial code reviews
- Write technical decision documents, such as ADRs
- Debug a rather complicated bug
- Brainstorm about a problem you want to solve
- Arrange or attend meetings
- Read unread messages on Slack, JIRA, or Zendesk
- Work on trivial stories
- Any repetitive or monotonous work/task
- Check social media/news
You may ask, 「shouldn』t I respond to a Slack message when one of my team members sends a direct message asking for help?」 Indeed you should. But it is best if you make sure that you don』t get that message by starting your workday earlier than your teammates. For example, I dedicate the time between 7:30 a.m. and 9:30 a.m. to focused work.
Plan Your Day the Day Ahead, and Schedule Time Slots on Your Calendar
Take a short break after the focus time and plan the rest of your working day. Briefly check emails and Slack messages from the previous day to create a plan. Prioritize your work backlog and focus on what matters the most. Schedule a time slot for each activity on your calendar, which will help you manage time and prevent last-minute meetings. Don』t forget to plan for breaks during the day; otherwise, you may fall into the trap of working the whole day without a break.A plan of your day could look like this: 11:00–12:00: Code for story #1 13:00–13:30: Triage ticket #2 13:30–14:00: Break 14:00–15:30: Pair with a teammate on a story 15:30–16:00: Review pull request #3 Don』t worry if your day doesn』t go as planned. Just take note of what happened instead. Deviations from your original plan are excellent opportunities to learn retroactively what your actual workday looks like. They often indicate the things holding you back from being more productive. Maybe it』s time to fix that CI pipeline, which fails intermittently and causes you to lose time.
Plan Short and Well-Defined Stories
Coding alone is very natural to software engineers, until they don』t know the requirements or encounter a problem.Imagine that you are working on a task and have a question about the scope or feature. Walking by a teammate is quite natural and comfortable, thanks to open floor plans when working at the office. But that changes with WFH because collaboration and communication are more challenging when working from home. The communication is asynchronous, meaning you might get blocked until you get a response.
Ensure that each story you』re going to pick up has a clear definition of 「done」 and of scope. It should also include the technical implementation approach and details, leaving less room for unclarity. Writing small ADRs whenever applicable is a great way to achieve this. Otherwise, include it in the description. This way, a software developer can complete a story without getting blocked and requiring less external help. The impact of having explicit stories is more observable, especially with junior engineers.
Share the Knowledge
WFH productivity changes depending on the size and the age of the project. While small or newer projects benefit from increased WFH productivity, the benefits shrink with large or old projects.The reason is that large and old projects contain more information to be processed by everyone in a team, therefore requiring more communication. The scope is enormous, and there is often no single person who holds all of the information in their head. We rely on multiple people』s knowledge about specific parts of the project to complete our work. We ask questions of the people who are most likely to know the answer. Limited communication caused by WFH might be causing the productivity decrease for large projects.
To cope with this problem, share the information regularly. Schedule knowledge-sharing meetings to inform team members about the project. Record your meetings so that people can watch them on demand later on.
Another way of sharing knowledge lies in your commit messages. Software developers often browse the repo history to figure out how the code evolved and why a particular code exists. More explanatory and informative commit messages can help any future developer understand your perspective and reasons for a specific commit.
I hope these strategies can help you to become more productive at home and resilient to WFH burnout. Thanks for reading!
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
