What does it mean for a Linux distribution to be “fresh”?

I recently had a discussion with Luboš Kocman of openSUSE about how distros can monitor their “freshness”. In other words: how close is a distro to upstream? From our perspectives, it’s helpful to know which packages are significantly behind their upstreams. These packages represent areas that might need attention, whether that be a gentle nudge to the maintainer or recruiting additional volunteers from the community.

The challenge is that freshness can mean different things. The Repology project monitors a large number of distributions and upstreams to report on the status. But simply comparing the upstream version number to the packaged version number ignores a lot of very important context.

Updating to the latest upstream version as soon as it comes out is the most obvious definition of “fresh”, but it’s not always the best. Rolling releases (and their users) probably want that. In Fedora, policy is to not do “major updates” within a release. Many other release-oriented distributions have a similar policy, with varying degrees of “major”. Enterprise distributions add another wrinkle: they’ll backport security fixes (and sometimes key features), so the difference in version number doesn’t necessarily tell you what’s missing.

Of course, the upstream’s version number doesn’t necessarily tell you much. Semantic versioning is great, but not everyone uses it. And not everyone that uses it uses it well. If a distribution has version 1.4 and upstream released 1.5, is that a lack of freshness or an intentional decision to avoid mid-release compatibility changes?

I don’t have a good answer. This is a hard problem to solve. Something like Repology may be the best we can do with reasonable effort. But I’d love to have a more accurate view of how fresh Fedora packages are within the bounds of policy.

How to document your job

I was recently talking to a coworker who is in the middle of a large project to document her job. The goal is two-fold: to give teammates the ability to cover for her when she’s out of the office and to improve the onboarding experience for new team members. She has her manager’s support, but it’s a large project. She finds it difficult to make progress, in part because she doesn’t particularly like writing. As a result, the deadline keeps slipping further out.

I won’t claim to be the best documentarian, but I try to always leave my successor with better documentation than my predecessor left me. I’d like to think I’ve succeeded in that. In some cases, the bar was pretty low because there was no documentation at all. At any rate, this post is a collection of things I’ve learned over the years. This is an opinionated post and does not necessarily represent the One True Way to Document Your Job™.

Writing

  • Separate the why and the how. You have two separate audiences: someone filling in for a day or two and someone taking over the role. The information they need is very different. A person covering short-term probably doesn’t need or want to know the whole history of a process. They just want to know the steps they need to take. On the other hand, your replacement will benefit from a greater level of explanation. They’ll want to know why the steps are they way they are. In particular, knowing what didn’t work well in the past is a good reference to help them avoid re-learning that lesson later.
  • Start at a high level. If you cover the broad stuff first, that gives your reader something to work with, even if they need to ask you or someone else to help fill in the details. On the other hand, a detailed list for process A does nothing to help with process B. Starting at a high level also allows you to…
  • Write small chunks. You don’t need to write everything in a day. Starting with higher level concepts allows you to break the role into a few key areas. From there, you can break it down further and further.
  • Limit the work in progress. Similarly, you don’t need to write everything at the same time. if you work one one or two concepts at a time, you can get those sufficiently done and move on to the next. Yes, it’s a bummer if the one of the incomplete concepts is what your coworker needs to cover a sick day, but some fully-complete documentation is generally better than a lot of woefully incomplete documentation.
  • Avoid duplication. The more places the same information is recorded, the more likely it will become out of date. If documentation for something already exists, link to the authoritative source. You can provide some basic context around the link, but minimize the amount of copy/paste you do.
  • Write as you learn. If you’re just getting started, try to write as much as you can as you learn it. That way, you don’t end up assuming knowledge that your reader won’t have. If you’re learning from someone else, this also gives you the opportunity to let them verify it.

Verifying

The first time you write documentation, it will almost always be incomplete. You’ll want to get feedback to help improve it. This turns out to be another benefit of small chunks with limited work in progress. It’s almost like Agile was on to something here!

  • Trade places with a coworker. If you can (this requires management support for sure), swapping jobs with a coworker for a few hours gives you the opportunity to see how the documentation performs in real life. Doing it while you’re still around means that the documentation has been tested before you have a sick day or vacation. If there are problems, you can answer them without being inconvenienced.
  • Get feedback quicky. Even if you don’t swap roles, at least let someone look at it as soon as you’re done writing. This way everything is fresh in your mind as the questions come up.

The mechanics

You may have noticed that I cleverly avoided discussing the technical aspects. Do you write a wiki page? A word processor document? A standalone note taking app (like CherryTree)? Rendered HTML on a docs site? I leave this as an exercise for the reader. They all have benefits and drawbacks, so whatever works best for your team is the right answer. If people can’t find or update the documentation, then why did you bother writing it?

A survey of the kanban tools I use

In a previous post about distinguishing between tasks and projects, I made a brief mention of the different kanban tools I use with a promise to go into further depth. Here is the depth. This post is more about the tools I use and the context in which I use them as opposed to the specific design of the boards themselves.

Trello

Trello is the gold standard when it comes to kanban. It’s free to use (although I’ve paid for a business subscription in the past), has a useful mobile app, and focuses on being good at being a kanban board. Trello was the first kanban board I used and it became my default. I use it to track article ideas for this blog, plan meals, and track online orders.

I wouldn’t mind switching to another tool, just to have one less place to track work, but there are a few things that keep me around. The mobile app is the biggest. Trello’s mobile app works really well. It doesn’t have the full feature set of the web app, but it’s enough to be productive. I’m also a big fan of the calendar view. This helps me plan time-based work like blog posts and dinners. Combined with labels, the calendar view makes it really easy to see if I’m being too repetitive. I also like that Trello makes a visual distinction between complete and incomplete when displaying dates. Relatedly, the package tracking plugin is really nice, too. Plug in a tracking number and the estimated delivery date displays on the card as if it were a due date. The last feature that I love is the automation. I only use it on my writing board, but it comes in handy. I have a rule that when I set a due date on a card, it gets moved from “Ideas” to “Planned”. There’s another one that will mark a card as done when I move it to the “Scheduled” column.

Trello also has a good blog if you’re into that sort of thing.

Todoist

I switched to Todoist when I couldn’t put off migrating away from Wunderlist any longer. As the name implies, it’s primarily a todo list manager (and a darn good one at that), but it recently added support for kanban boards. To try it out, I converted my “laundry” category to a board. It works okay for that purpose.

The mobile app is great for the todo side, but the boards are a little buggy (although the same is true for the web app). Cards don’t always want to move to the column you’re trying to drag them to. But my biggest gripe is that there’s currently no way to cleanly handle recurring tasks. For example, my laundry board is broken out by load (e.g. whites, pants, towels), with tasks scheduled to recur every two weeks. When I mark a task done, I’d like the new incarnation to start in the “dirty” column. Ideally, moving a task to the “folded” column would automatically mark it done.

I’ve found myself using the board feature less and less with my laundry. The issues above combined with the fact that the state is readily apparent means it doesn’t have a lot of value. I like Todoist overall, so I wish I had more reason to use the board feature.

Taiga

I actually use two different Taiga instances: Fedora’s and the public instance. In the Fedora instance, I have a board where I track all of my work as Fedora Program Manager, as well as using it collaboratively with other teams. On the public instance, I’m currently only using it to track progress on my book.

Taiga is designed to be a full-featured project management tool, which gives it a leg up in some ways. User stories on the kanban board can have child tasks with their own state, which is helpful when i need to decompose work. It also has a module for epics, which is useful for aggregating larger work. As an example, I have a card for each chapter on my book board. When my editor gives me things to fix, I add those as tasks. Each of the milestones that the publisher has in their process is an epic.

There are two missing features that keep from moving to Taiga as my main kanban tool. The first is the lack of a calendar view. This would be particularly for the Fedora Magazine editorial board. The second is a sub-optimal (read: basically unusable) mobile experience. I don’t manipulate my boards on my phone a ton, but I do enough that it would be hellish. There are some third-party apps, but they can’t connect via Fedora’s authentication system, so they don’t help me.

I’d also like the ability to mark specific user stories as private, although I concede that doesn’t make a ton of sense in the context of what it’s intended for.

GitHub, GitLab, and Pagure

I combined these three because they’re basically the same to me: nice additions to issue tracking tools. I wouldn’t use either of them primarily as a kanban tool, but it comes in handy as a layer on the primary purpose. GitHub allows you to add both issues and non-issue cards to a board, which has resulted in a very confused me on several occasions. Pagure does not appear to have this problem. I’ve used GitLab’s board feature a little bit, but I don’t feel I’m familiar enough to comment on it.

Setting boundaries when working in communities

Kat Cosgrove recently had a tweet that hit home:

I haven’t taken any meaningful time off of work in the last 14 months because it feels kinda pointless. I’m just going to be sitting at home thinking about work so I might as well be doing work. Invariably, what I fear is happening while I’m not at work is much worse than what is actually happening. Yay, anxiety!

But also, there’s some guilt when you’re paid to work in a community where a lot of people are volunteering. I don’t feel like I can say “hey, it’s after my work hours” because many in my community only participate outside of their work hours. Add to that the global nature of open source communities and that means that there’s always something to devote my time to.

I think it would be easier to come in as an outsider who is just doing the job for a paycheck. But working in a community where you previously volunteered makes the urge to be around all the time so much stronger. It can be really hard to set boundaries because it feels like you’re devaluing the donated time of others.

It’s a blessing and a curse. I happen to think I’m pretty good at my job (and the fact that I’m anything other than a failure should tell you something) and I know that’s because it’s more than a paycheck to me. But that’s also what makes it so hard to draw boundaries.

My manager (who is very good at reminding me to take care of myself) recently compared it to working for a startup. Everyone pitches in wherever they can, even when it’s not on the job description. That’s incredibly true in open source projects, except there’s no exit. It’s not like you’re working hard now so you’ll get a stupid-large pile of cash when a big company acquires you or you have an IPO. If the project is successful it…keeps being a startup forever.

For now, I’m holding up pretty well. I’m balancing working too much with non-work interests (even if a lot of them look like work to the outside observer). But I wonder how long that can hold. And I wonder how others in a similar position make it work over the long term.

Balancing incoming tasks in volunteer projects

Open source (and other volunteer-driven) communities are often made up of a “team of equals.” Each member of the group is equally empowered to act on incoming tasks. But balancing the load is not easy. One of two things happens: everyone is busy with other work and assumes someone else will handle it, or a small number of people immediately jump on every task that comes in. Both of these present challenges for the long-term health of the team.

Bystander effect

The first situation is known as the “bystander effect.” Because every member of the team bears an equal responsibility, each member of the team assumes that someone else will take an incoming task. The sociological research is apparently mixed, but I’ve observed this enough to know that it’s at least possible in some teams. You’ve likely heard the saying “if everyone is responsible then no one is.”

The Bystander effect has two outcomes. The first is that the team drops the task. No one acts on it. If the task happens to be an introduction from a new member or the submission of content, this demoralizes the newcomer. If the team drops enough tasks, the new tasks stop coming.

The other possibility is that someone eventually notices that no one else is taking the task, so they take it. In my experience, it’s generally the same person who does this every time. Eventually, they begin to resent the other members of the team. They may burn out and leave.

Oxygen theft

Sometimes one or two team members jump on new tasks before anyone else does. Like the delayed version in the bystander effect scenario, this can lead to burn out. But worse, it can drive away team members who want to take tasks. If they’re constantly missing work because they weren’t able to immediately jump on it, they’ll go find other places to contribute. I call this “oxygen theft” because it’s like sucking all of the oxygen out of the room: it puts out the flames.

I have been an oxygen thief myself. Shortly after I started as the Fedora Program Manager, I became an editor on the Fedora Community Blog. I was publishing regular posts and I happen to be a decent editor, so it made sense to give me that privilege. But because Fedora was my day job, I was often the first to notice new submissions. Over time, I eventually became the only editor working on posts. By accident, the editorial team became a team of one. That’s on my list to fix in the near future.

Solving the problem

Letting either the bystander effect or oxygen theft cases go for too long harms the team. But with volunteers, it’s hard to balance the work. Team members may not have consistent availability. For example, if one of the team members dayjob schedule varies from week. They probably don’t have evenly distributed availability, either. Someone who is paid to be on a project will likely have a lot more time available than someone volunteering.

One way to solve the problem is to take turns being in charge of the incoming tasks for a period of time. This addresses “if everyone is responsible then no one is” by making a single person responsible. But by making it a rotating duty, you can spread the load.

After learning my lesson with the Fedora Community Blog, I was hesitant to be too aggressive with taking tasks as an editor of the Fedora Magazine. But the Magazine team was definitely suffering from the bystander effect.

To fix this, I proposed having an Editor of the Week. Each week, one person volunteers to be responsible for making sure new article pitches got timely responses and the comments were moderated. Any of the editors are free to help with those tasks, but the Editor of the Week is the one accountable for them.

It’s not a perfect system. The Editor of the Week role is taken on a volunteer basis, so some editors serve more frequently than others. Still, it seems to work well for us overall. Pitches get feedback more quickly than in the past, and we’re not putting all of the work on one person’s plate.

[If you are intrigued by this half-baked post, you’ll enjoy my book on program management for open source projects, coming from The Pragmatic Bookshelf in 2022.]

Distinguishing between tasks and projects

I was talking to a colleague recently about leading a volunteer group at work. One of the issues she mentioned was that the group sometimes has a hard time separating tasks and projects. If you look around, you’ll find plenty of blog posts (mostly from software companies trying to sell you their tool). Many of them share a similar adherence to the Project Management Institute’s definition of a project. While that can be useful, it’s more formal than necessary.

In my mind, the distinguishing factor is the number of states.Tasks have two states: “not done” and “done”.Projects have multiple states.

For example, I treat doing the dishes as a task. There’s not really an in-between state. Okay, there could be. Scrubbing, rinsing, and drying could all be distinct states. In practice, a dish moves between the three so quickly that it’s of no benefit to track the state. Doing the dishes is a single act in terms of my time. I’m not going to start and then pause midway through (barring my kids doing something that requires immediate attention).

Laundry, on the other hand, I treat as a project. It has distinct states of sorting, washing, drying, and folding. Unlike the dishes example, they don’t happen all at once. I’ll load the washer and then I have to wait until I can put the clothes in the dryer.

To use work examples, writing an email is a task. Yes, there’s a state of “writing” and I may not compose it all at once, but it’s essentially a single thing. Writing a release announcement is a project. First I write it, then it gets reviewed, then it gets scheduled.

This brings up another point about the states. Tasks change state in one direction, but projects can move between states. Once they’re done, they’re done. After I send an email, it’s done. New tasks may come as a follow-up, but those are new tasks. The release announcement may go back and forth between “writing” and “review” several times before it’s done.

The astute reader will notice that the states sound a lot like tasks. You can look at the laundry project as a collection of four tasks: sort the laundry, load the washing machine, load the dryer, fold the laundry. That’s a valid approach. For me, it makes more sense to think about it in states instead of a collection of steps.

Part of this is probably due to the tools I use. For tasks, I use a todo list application (Todoist, specifically) to track and plan. For projects, I use a Kanban board (Trello, generally, but Taiga for a few things. And Todoist’s new board feature for my laundry. More on all of this in a future post). For particularly complex projects, I’ll add sub-projects or tasks to track them more granularly.

Sidebar: why PMI’s definition is too formal

The Project Management Institute defines a project as “It’s a temporary endeavor undertaken to create a unique product, service or result.” While this is not unreasonable in the context of my conversation, the page goes on to add a lot of extra baggage. In common usage, a project is something that takes multiple steps to accomplish. The structure, process, and documentation of a Project™ are entirely unnecessary for how most people use the word.

File a bug, but where?

It’s easy to tell someone to file a bug. Knowing where to file it isn’t quite as simple. In a large project like Fedora, there is no One Tracker to Rule Them All.

Red Hat Bugzilla comes the closest. That’s where most software bugs should be filed. Except for Fedora CoreOS which would rather you use their GitHub tracker. And a few other components, which would very much prefer issues be filed upstream.

But for non-software issues, Bugzilla may or may not be the place. Components still exist for documentation and websites, although those are mostly handled via Pagure repos now. (I should really remove those components.) And some teams discuss software features in their Pagure repo for collaboration and then might open a Bugzilla bug if other tools need one.

Of course, knowing which platform is only the start. You also have to know which component (in Bugzilla) or repo (in Pagure) is right. This isn’t always clear when you’re familiar with the inner workings of the project and is entirely opaque to outsiders. A casual user is not going to know (or care) which URLs happen to be owned by the websites team versus the docs team versus who knows what other team.

And that, dear reader, is one of the key features of a centralized tracker like Bugzilla: mis-filed bugs can be trivially passed to the right team. With independent repos, you force users to know your project’s org chart

Of course, Bugzilla can be pretty heavy and is generally more complicated than you need. There’s no right answer. There’s just how you’re willing to balance the tradeoffs.

In general, I think putting software issues (bugs, features, etc) in Bugzilla and process issues in a team’s Pagure repo is the right approach. But ultimately, teams decide for themselves how they will work.

[If you are intrigued by this half-baked post, you’ll enjoy my book on program management for open source projects, coming from The Pragmatic Bookshelf in 2022.]

Projects shouldn’t write their own tools

Over the weekend, the PHP project learned that its git server had been compromised. Attackers inserted malicious code into the repo. This is very bad. As a result, the project moved development to GitHub.

It’s easy to say that open source projects should run their own infrastructure. It’s harder to do that successfully. The challenges compound when you add in writing the infrastructure applications.

I understand the appeal. It’s zero-price (to write; you still need the hardware to run it). Bespoke software meets your needs exactly. And it can be a fun diversion from the main thing you’re working on: who doesn’t like going to chase a shiny for a little bit?

Of course, there’s always the matter of “the thing you wanted didn’t exist when you started the project.” PHP’s first release predates the launch of GitHub by 13 years. It’s 10 years older than git, even.

Of course, this means that at some point PHP moved from some other version control system to Git. That also means they could have moved from their homegrown platform to GitHub. I understand why they’d want to avoid the pain of making that switch, but sometimes it’s worthwhile.

Writing secure and reliable infrastructure is hard. For most projects, the effort and risk of writing their own tooling isn’t worth the benefit. If the core mission of your project isn’t the production of infrastructure applications, don’t write it.

Sidebar: Self-hosting

The question of whether or not to write your infrastructure applications is different from the question of whether or not to self-host. While the former has a pretty easy answer of “no”, the latter is mixed. Self-hosting still costs time and resources, but it allows for customization and integration that might be difficult with software-as-a-service. It also avoids being at the whims of a third party who may or may not share your project’s values. But in general, projects should do the minimum that they can reasonably justify. Sometimes that means running your own instances of an infrastructure application. Very rarely does it mean writing a bespoke infrastructure application.

Applying the Potter Stewart rule to release blockers

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description, and perhaps I could never succeed in intelligibly doing so. But I know it when I see it.

Justice Potter Stewart in Jacobellis v. Ohio

Potter Stewart was talking bout hard-core pornography when he wrote “I know it when I see it”, but the principle also applies to release blockers. These are bugs that are so bad that you can’t release your software until they are fixed.Most bugs do not fall into this category. It would be nice to fix them, of course, but they’re not world-stopping.

Making a predictable process

For the most part, you want your release blockers to be defined by specific criteria. It’s even better if automated testing can use the criteria, but that’s not always possible. The point is that you want the process to be predictable.

A predictable blocker process provides value and clarity throughout the process. Developers know what the rules are so they can take care to fix (or avoid!) potential blockers early. Testers know what tests to prioritize. Users know that, while the software might do something annoying, it won’t turn the hard drive into a pile of melted metal, for example. And everyone knows that the release won’t be delayed indefinitely.

Having a predictable blocker process means not only developing the criteria, but sticking to the criteria. If a bug doesn’t violate a criterion, you can’t call it a blocker. Of course, it’s impossible to come up with every possible reason why you might want to block a release, so sometimes you have to add a new criterion.

Breaking the predictable process

This came up in last week’s Go/No-Go meeting for Fedora Linux 34 Beta. We were considering a bug that caused a delay of up to two minutes before gnome-initial-setup started. I argued that this should be a blocker because of the negative reputational impact, despite the fact that it does not break any specific release criterion. I didn’t want first time users (or worse: reviewers) to turn away from Fedora Linux because of this bug.

QA wizard Adam Williamson argued against calling it a blocker without developing a specific criterion it violates. To do otherwise, he said, makes a mockery of the process. I understand his position, but I disagree. While there are a variety of reasons to have release blockers, I see the preservation of reputation as the most important. In other words, the point of the process is to prevent the release of software so bad that it drives away current and potential users.

Admittedly, that is an entirely subjective opinion. I expect disagreement on it. But if you accept my premise and acknowledge that you can’t pre-write criteria to catch every possible, then it follows that squishy “I know it when I see it” rules are sometimes okay.

Can’t you just make that a criterion?

The best blocking criteria are objective. This aids automated testing and (mostly) avoids arguments about interpretation. But that’s not always possible. Even saying “feature X works” is open to argument over what constitutes “working”.

The challenge lies in how to incorporate “this bug is bad even though there’s no specific rule” without making the process unpredictable. In this case, Adam’s position makes a lot of sense. It’s much easier to write rules to address specific issues and apply them retroactively. Of course, doing that in a go/no-go meeting is perhaps straining the word “predictable” a bit, too.

So what happened?

In the case of this specific bug, we had an escape hatch. The release was likely to be declared no-go for other reasons, so we didn’t need to come to a decision either way. With a candidate fix available, we could just pull that in as a freeze exception and write a new criterion for the next time.

Because of this, I decided not to push my argument. I declined to propose a criterion in-meeting because I wanted to take some time to think about what the right approach is. I also wanted to spend some time thinking about the blocker process holistically. This gives me a blog post to publish (hi!) and some content for a project I’ll be announcing in the near future. In the meantime, I’ve proposed a change to the criteria.

Working from home: my advice

There are as many articles about working from home as there are people who work from home. But I’ve been asked by a few people about my experiences, so looking back on the last nearly seven years, here’s what stands out.

Let’s keep a few things in mind first. Not everyone has the privilege of being able to work from home. In the midst of a pandemic, I feel for them. Also, working from home for a few weeks as an emergency is different from doing it all the time. Routine work from home you plan ahead for. It probably doesn’t involve having your partner and children around all the time while you also worry about a global pandemic and economic collapse. Just do the best you can and understand that your best now probably looks a lot different than your best a few months ago.

Your environment

Ideally, you’ll want a separate room that’s walled off from the rest of the house. This gives you the ability to focus and sets boundaries for you and others. If that’s not possible, get yourself the most secluded space you can. Make sure you have enough space for your laptop and any additional equipment you might need. Make sure there are power outlets available. I also ensure there’s space for mug of coffee or a cup of water, depending on the time of day.

When it comes to noise, you might not get much choice. If you like having chaos in the background, that’s great. With a partner, pets, or kids at home, you’ll probably get that. Noise canceling headphones are a good thing to have, but keep in mind that “noise canceling” means “the hum of your HVAC” not “the shriek of your toddler”. I personally tend to listen to podcasts. I’m generally not paying active attention, but the background talking helps. If I’m reading intently or writing, then I’ll shut it off.

Also consider what’s behind you. You’ll probably be on video calls a lot. Does the background send the message you want? Most people will understand a messy room, but if it bothers you, now’s the time to address it. Be particularly careful if someone can walk into frame unexpectedly. Years ago, I’m pretty sure I saw someone walk out of the shower in the background of a call with a coworker. That was awkward. You may consider having some kind of visual indicator: a flag or a light or something. Anything that will make it clear to those around you that you’re “on air” can help them avoid being in the meeting unexpectedly. But also consider that everyone else is going through this and a cute animal or kid can help everyone relax for a minute.

If you can help it, don’t work from a bed or couch. They’re too comfortable and I’ve found it’s really hard to maintain focus. The only time I’ve worked from bed is when I’ve felt particularly unwell but couldn’t bring myself to not work. (That is a personal failing, not an admirable trait.)

Try to find somewhere with sunlight, too. Especially in winter, having some sunshine really helps my mood. Consider where it will come in, though. You probably don’t want it directly in your face as you look at the screen, nor directly over your shoulder.

Your communication

Get ready to embrace your employer’s video platform of choice. I work in an open source community where a lot of daily communication happens through text-based chat. But video calls add an important human dimension. The in-person conversations you used to have? They happen on a webcam now!

If you have multiple monitors, put the thing you’re looking at on the one with the webcam. That might be the chat application, but it also could be a shared document that you’re looking at. But I can say from experience that it’s really disorienting to be looking at someone in profile the whole time.

On a similar note, try to find a good angle for your webcam. It’s best if it can catch you straight on. Up-nose shots are no fun and looking-down-on-your-forehead shots seem weird.

If your bandwidth isn’t up a video call, disable the video. It’s better to have the audio than nothing. If you’re not normally working from home, you might not have paid for the bandwidth you need, especially if others in the house are streaming movies or something. Also keep in mind that some providers throttle the upload bandwidth, which means that you might be receiving the call clearly, but your video or audio might be on the strugglebus. A business-class connection will generally not have that limitation, so it may be worth checking with your provider on that.

One thing you won’t get working remotely is the random water cooler chatter. That can be really helpful for team bonding. In previous jobs, I’ve done things like pair people up with randomly-selected coworkers and say “schedule a 15 minute call in the next two weeks to talk about anything you want.” I have a script that will draw names out of the hat for you. If you have a chat tool like Slack, IRC, etc, have a channel devoted to chit-chat. People can pop in and shoot the breeze without worrying about bothering someone who is in the zone.

Your self

Dress for success. Or at least for work. In cold weather, I put on jeans. In the summer, I wear shorts. What I don’t wear is pajama pants. I’ve found that I just can’t motivate myself to get work done on days I stay in my pajama pants. Not everyone has that problem, so if you find it works for you, great!

You might also want to shower. Or not. I won’t say how often I shower, but I can assure you it’s not daily. A lot depends on how I feel. If I feel like I need a shower, I take one. Sometimes that’s in the morning, but it’s usually at night or occasionally midday. You may find that you need to do your whole morning routine in order to feel motivated for work. That’s fine, but don’t expect that everyone else will.

Try to get some exercise if you can. I’m really bad at this myself, especially when I’m busy or the weather is bad. But when the weather is nice, a 20 minute walk around the neighborhood is a good chance to get away and think for a few minutes. A standing desk or treadmill desk can help too, or even some hand weights that you use during a call.

You know what’s great? Naps! It’s hard to do this at an office, but one of the things I really like about working from home is that I can go lie down for 20 minutes. “But, Ben!” you say “isn’t that like stealing from the company?!” I look at it this way: I could spend 20 minutes taking a nap, or two hours sitting at my desk but just sort of mindlessly staring at my screen. Which one seems better?

At some point, you’ll want to eat. I see a lot of advice that says “don’t eat at your desk”, but I do that almost every day. I did that when I worked in an office, too. For me, it was a way to shorten the work day a bit. For you, do what works best for you. Experiment a little bit. For me, I also know that I should not keep food within arms reach because I will eat it. All of it. Having a little bit of physical separation from food goes a long way.

Perhaps the most important thing is to give yourself some slack. Being a human is hard, and being a human in the time of pandemic is harder. You have a lot on your mind, and it’s okay if you’re not always at your best. Especially if you’re working from home in a suboptimal situation.

Your boundaries

You should have them. Working from home can really blur the line between work and home. It’s okay to step away for a few minutes to load laundry or run the vacuum. It’s not okay to keep working until 11pm because suddenly your living room is now your office. This is where having a separate office space helps. If you can make it happen.

Communication boundaries with coworkers are important, too. Don’t send an IM if it could be an email or a message in a broader channel. In a previous job we set up an escalation process for help requests in Slack:

  1. Ask in a product- or customer-specific channel with no tagging names, @here, or @channel
  2. If sufficient (use your judgment, based on the urgency) time goes by and you haven’t gotten an answer, repeat the message with @here to alert folks who are available
  3. If that still doesn’t get a response, send an IM to the person you think could help

Your routine

Like I said above, some people find they need to go through the whole routine in order to get motivated for work. That might mean doing makeup and hair and getting dressed in your “grown up” clothes. I’ve even heard of some people who drive their car around the block once just to have that mental routine of a morning commute.

I, on the other hand, do none of that. The closest thing to routine I have is making coffee before I sit down at my desk. For me, I love that I can be out of bed and at work five minutes later. I am not at all a morning person. What I do miss is having a commute home. Especially if you have kids, it can be hard to go straight from work stress to kid stress with no break in between. I don’t really miss the act of commuting, just the time to switch gears. For me, I found that was a good time to do 10 minutes of meditation. It helped me calm down after work and it gave me just enough of a break to be less frazzled with the kids.

Your distractions

I love working from home, but it’s not all great. Being able to step away for 5 minutes to get house work done is a great mental relief. But it’s also possible to get carried away, especially if you’re trying to avoid a hard problem at work. Unloading the dishwasher is fine. But don’t let it snowball into then cleaning out the fridge and scrubbing the stove top and and and.

If you have roommates, spouses, children, etc, they need to know when you’re working and that you should be left alone except in emergency. Find a way to signal that, like wearing your headphones when you walk through the house.

You can do this

Whether you’re making work-from-home a permanent thing, or you’re just work-from-home-during-a-pandemic-oh-god-what-is-happening-in-this-world, I hope some of the advice here helps. If you only take away 12 words, let them be: set boundaries, do what works for you, and go easy on yourself.