At face value, when we think of developer productivity we might think of effectiveness in time management, communication, and task completion.14 Although we are drawn to personal workflow or time management tools, and learning secrets to improving our productivity, ironically this quest for the holy grail can sometimes take us off course and be a detriment to our productivity. The problem is that accomplishing tasks or having a filled up schedule does not necessarily equate to productivity. Creating a formulaic working strategy, as was common in the last century, does not either.a,8,13 Productivity is less a quality that can be easily measured,b controlled, or improved directly with tools, but instead is a human element that manifests from developer happiness.
This Viewpoint is intended for remote software engineers who are facing new challenges to thinking about routine, responsibility, and goal setting. As a developer of scientific software, and one who has transitioned to working remotely before any stay at home orders,24 I have slowly learned to optimize my own productivity by focusing exclusively on well-being. In this Viewpoint, I summarize what I have learned.
- Work on Things You Care About. It goes without saying that a core ingredient to happiness, and thus productivity, is working on projects or software that you care about.31 In fact, this has been experimentally shown: happier workers are more productive, and lower happiness associated with adverse life events is a detriment to productivity.7,28 Thus, we might step back to say that before we discuss any best practice criteria, you should enjoy the practices of software engineering, or participation in a community, enough to warrant having it a part of your daily life. If you are not sure if you are in the right role, then assess it based on the small tasks that it encompasses. You can break your day down into small events or tasks, and take a mental note about whether or not you enjoyed each one. For example, a software engineer might realize they enjoy working publicly on open source on GitHub, and writing documentation, but are not so keen on reanswering the same questions on a private user forum. Figuring this out would help the software engineer to push for projects and responsibilities that are better catered to their interests. If you cannot identify any items, or if all the items identified are considered negative experiences, then it is time to look more critically at your role. There is no list of best practices that you could reasonably follow to make you happy if you are not in the right line of work to begin with. If this is true for you, you will have a difficult time being regularly productive.
- Define Goals for Yourself. As software engineers, it is sometimes the case that we don't have a career ladder.21 Many of us might not sit within established groups where we have a manager who is aware of supporting our personal and professional development and growth. This can be problematic because goal setting can generally have a positive effect on performance.35 Under these circumstances, and especially in the present moment when we are more disconnected from our teams, we have to take our personal and professional development into our own hands. This means thinking about the kind of work that you want to do, or more generally, the goals you want to accomplish in the short and long term. For example, if you program a lot, your goal might be to learn a new language that would be useful to know. If you are feeling disconnected, your goal might be to pursue interacting with a small set of new communities, or creating structure into your schedule for discussing projects or work with colleagues. If you are involved with research, your goal might be to submit or publish a paper. Shorter-term goals might be in the context of a week or month. You might want to solve a particular challenge, add a feature to your software, or write up an idea you have. Having these goals is important for your productivity because you can better understand how your work fits into the overall story of you, as a software engineer. If you share your goals with your colleagues or supervisor, they might learn they are important to you, and be interested to support you or otherwise keep an eye out for you.
- Define Productivity for Yourself. If we were in a role that explicitly produced some kind of output (for example, a farmer might grow corn) then we might easily measure and define productivityc as these units of output. However, in context of a rich role that involves not just writing code but also interacting with people and ideas, this simple representation does not work very well. While we could define productivity based on lines of code or developer outputs,26 this definition fails to capture individual differences. There is huge variance in software engineering work, and it would be a daunting task to quantify or qualify what productivity or happiness means globally. However, even though we lack definition, we still are cognizant of what a productive day feels like. Although there are arguably different kinds of happiness,5 we do not need to have a holistic definition to know if we feel good at the end of a day. A productive day is one that you finish and feel satisfaction that your work was meaningful. Thus, it follows that we might be able to define productivity for ourselves by assessing our daily tasks and deciding if they contribute to that feeling of satisfaction. A software engineer might create a physical list, and add items to it whenever something feels done or accomplished. These items can either be items of work that are mention-worthy, or softer goals like fostering a collaboration or growing a community. This list can be hugely useful for deriving a better understanding of yourself, and what makes you happy or productive. Although happiness and productivity are not exactly the same thing, they seem to be intimately related.17
It goes without saying that a core ingredient to happiness, and thus productivity, is working on projects or software that you care about.
- Establish Routine and Environment. Small details about your working environment, or lack of a routine, can hugely throw off your workday, and thus your productivity. You should generally pay attention to the lighting, noise level, and comfort of a work space. If you find yourself distracted by anything, you might consider changing your environment. Habitual repetition by way of thinking about your environment or making explicit choices can lead to the establishment of longer-term habits.25 The more that you are able to repeat a behavior in a specific environment, the more likely it is to become effortless.12 For example, if you immensely enjoy browsing the Internet for pleasure, you might teach yourself to look forward to this activity after dinner, and choose to browse at a different location with a different device to not associate either with work. If you are the kind of person who enjoys the routine of working in a coffee shop, you might try to emulate this experience at home by creating several different working spots, and taking a walk in the middle of the day to mimic moving between them. In the case of a maladaptive habit you want to get rid of, you might consider changing your environment.37 For example, if you typically work alone and you do not like it, you might consider trying an environment with more regular interactions with another person. If you do not feel productive, you might consider testing a different working location, morning ritual, or lunch or exercise routine. An important aspect of this routine is creating a clear separation between times when you are working, and times when you are not. This is especially challenging and important for working at home, because any routine of going to and from work is gone, and home becomes two in the same. Finally, a routine that includes more than work, meaning activities that are for your personal well-being (exercise, time with family, relaxation), are essential to consider. The remarkable features of a healthy routine and environment are that they work so well that you do not notice them.
- Take Responsibility for Your Work. If you are in a role that provides user-support, work on a team, or otherwise have a list of tasks set out for you, there is a tendency to be passive. While you might check off items from a to-do list on a daily basis, this does not necessarily indicate that you have taken ownership or responsibility for your work. Having this ownership can be a driving factor for caring more about your work, and thus your productivity.30 It is a challenging but important skill to learn how to independently recognize and address challenges in your community or space. For example, a challenge might be anything from a small annoyance that your group faces on a regular basis, to a significant computational problem. The more capable you are of deciding something is important to do, creating a plan to do it, and executing that plan, the more you can establish independence, learn new skills, and feel you have ownership over your work. If you share your ideas or projects with your supervisor or team, they will also see these positive qualities in you, and this can help to establish trust, which is hugely important in a remote working environment. In fact, participation in organizational decisions can give a sense of psychological ownership that also improves general well-being.20 Taking ownership on both of these levels, in that it establishes trust, can help to solidify how your team thinks about and consequently treats you. Your supervisor should not require tracking software to keep abreast of your every move because they have confidence and trust in you.
- Take Responsibility for Human Connection. When newly remote, it is common to place the burden of connection on your team. If your team is not remote first,11 it is even more unlikely that there are established protocols and best practices for how to make you feel included and happy. Many of us learn this the hard way right at the offset of going remote. If we become disconnected from our immediate or even open source communities, it can feel terribly lonely and have direct impact on our well-being.9,34 In fact, social-isolation or exhaustion alone can trigger this same loneliness.32 In this situation, it is important to identify that there is a problem, namely lack of human connection, and figure out the kinds of human connection that are meaningful to you. You might first find comfort in the fact that feeling lonely is more common than you might think.36 You might then seek out human connection. Seeking human connection means attending virtual workshops, conference calls, or looking around for regular meetings that you could participate in. If you are looking for more one-on-one human interaction, you might see if anyone would be interested in having a virtual coffee a few times a month, or a virtual "happy hour" to involve others. The choice of group is up to you. While it is reasonable to consider your colleagues at work, what you are missing might be connection to friends or family, and so a regularly scheduled family meeting or even meeting online to play a game could be a regular event. In the context of work, you can also use the trick of sharing your work to pursue human connection. If you share progress on your projects on social media or Slack, it likely will open lines of communication with others interested in your work. Whatever your strategy, by changing your environment you can feel less lonely.38 As a remote worker you might live in isolation, but you do not need to work in it.
Although happiness and productivity are not exactly the same thing, they seem to be intimately related.
- Practice Empathetic Review. Software engineering requires a lot of technical communication. Whether you are having discussion in a chatwindow, on video, or a code review, you are undoubtedly going to encounter a lot of different kinds of people, all with different expectations and incentive structures. Empathy is essential. Communication can lead to good productivity,2,27 and having good productivity can further make you a better, less adversarial communicator.19 For example, if you encounter a maintainer of a repository seeming curt or mean, you might consider the responsibility on their shoulders to maintain the software, the number of other issues or pull requests they need to review, and that they are working in free time. The maintainer is likely to be in a stressful role. You might also consider cultural differences in communication—it could be that a succinct response is more common in their community or culture. When you take these factors into account, a response that you might have reacted with that is defensive, confrontational, or otherwise aggressive, might be adjusted to have kindness, and further, be productive by asking how you might help. Arguably, the quality of communication on the level of an organization comes down to the quality of the individuals' communication within it. Better communication leads to positive outcomes that range from addressing an issue to solving a problem, or simply feeling involved with decision making.15 No interaction is too small to practice good communication. Practicing empathetic development means introducing yourself, describing the issue or change clearly, and making it easy for the other party to reproduce. By setting an example, you will not only influence the others involved in the work at hand, but also set an example for the immediate community and larger community of software engineers.
- Have Self-Compassion. You can do your best to define personal goals, establish routine, and do meaningful work that feels productive, but this does not always mean that you finish the day and feel that you were successful. This is where self-compassiond and mindfulness4 are important, as they have been shown to have positive impact on mental health and well-being.3 Self-compassion can broadly be defined as being mindful and forgiving to yourself.16 Having self-compassion means looking back on the experience of a day, and not egging yourself for everything that was not perfect. It is just a given that every day will not feel productive. You might try new routines that do not work for you. Instead of thinking negatively, you might consider that establishing your routine, or figuring out a hard problem, is a work in progress, and there is no real state of failure because you wake up and try again. I have found that it helps to try to imagine myself as another person. If someone else approached me with the same experiences and negative thoughts, how would I comfort them? It is very likely that I would react with compassion, and that is the same compassion that I must find for myself. If the source of criticism comes from an external source, although you cannot control other people, you can choose to respond thoughtfully, with kindness, and try to find humor in the situation. However, obviously if someone is in violation of some code of conduct, you should report it, and not absorb it quietly. Thus, self-compassion also means knowing when to stand up for yourself and say something. This advice is especially pertinent for women and other minorities in the work force who might experience subtle inequality or microaggressions.e
As a remote worker you might live in isolation, but you do not need to work in it.
- Learn to Say Yes, No, and Not Anymore. As a software engineer, engaging with projects can be akin to going to a candy store. Each one offers a rich set of problems to work on, people to work with, and new languages or technologies to learn. You might be someone who very easily says "yes" to contributing to a project, or generally providing help.10 While this is a really great way to grow as a developer and person, there is also a time to say no: when you do not have the bandwidth, do not share the vision of the project, or otherwise have a gut feeling telling you to do so.13 It is also okay to say "yes" but then scope your contribution to an amount that you have time for. Finally, what if you originally say "yes" and then change your mind? This is okay too. To maximize your productivity, maintaining awareness about what is on your plate, and when it is time to ramp up or taper down engagement is essential for focusing on the projects that are most valuable and important to you or your community.18
- Choose Correct Communication Channels. When working remotely, there are many ways to communicate with others. In that people have different working environments and schedules, ideally the communication is asynchronous, meaning that you use messaging services like Slack, or issue boards on version control services like GitHub.f However, you should be careful to choose the method based on the needs of the communication.g Discussion that should be open and linked to code would be better on GitHub issues or Gitterh than Slack. A discussion that moves into a document might first do really well using a collaborative document tool like Google Docs, but after some hardening you might want to move it into version control. Sometimes a quick call is more efficient than trying to write out a verbose email.1 The important detail is that, whether you choose a video call, an email, or a Slack message, your choice of channel is appropriate for the needs of the problem that needs to be discussed, the degree to which the communication should be transparent and open, and your own level of comfort.23,29 If you are less comfortable with video or voice chat, you might section off specific time slots or days for it to make it a predictable part of your routine.
I have summarized 10 suggested best practices to optimize remote developer happiness, and thus remote developer productivity:
- Work on things that you care about;
- Define goals for yourself;
- Define productivity for yourself;
- Establish routine and environment;
- Take responsibility for your work;
- Take responsibility for human connection;
- Practice empathetic review;
- Have self-compassion;
- Learn to say yes, no, and not anymore; and
- Choose correct communication channels
I can personally attest that by discovering and subsequently following these guidelines over half a decade, I have felt more productive, more guided in my work, and can more easily take on additional responsibility without detriment to well-being. You might have noticed that most of these points come down to identifying a locus of control. The software engineer who feels in control of his or her work and has mental tricks for handling uncertainty and stress is more prepared to deal with said uncertainty, and over time is more productive and happy. Even in the case where happiness is related to disposition,22 by way of being mindful of these mental strategies we can change the way that we think, and arguably change our disposition.6 It should also be noted that although these points of discussion are especially relevant for remote software engineering, they can easily be extended beyond this domain of work. These points offer a refreshing idea that success and productivity does not happen to us, but is something that we choose to create.
4. Coo, C. and Salanova, M. Mindfulness can make you happy-and-productive: A mindfulness controlled trial and its effects on happiness, work engagement and performance. J. Happiness Stud. 19, 6 (Aug. 2018), 1691–1711.
5. Cropanzano, R. and Wright, T.A. When a "happy" worker is really a "productive" worker: A review and further refinement of the happy productive worker thesis. Consulting Psychology Journal: Practice and Research 53, 3 (2001), 182–199.
9. Erdil, O. and Gülen Ertosun, O. The relationship between social climate and loneliness in the workplace and effects on employee well-being. Procedia—Social and Behavioral Sciences 24 (Jan. 2011), 505–525.
11. Gant, W. Remote-First: A Guide for Organizations—Simple Programmer. (2019); https://bit.ly/3vzWCjr.
14. Hakes, T. How to Measure Developer Productivity. (2019); https://bit.ly/3qWH5q8
22. Ledford, G.E. Comment: Happiness and productivity revisited. Journal of Organizational Behavior 20, 1 (1999), 25–30; https://bit.ly/3vDtNCS
26. Oliveira, E. et al. How have software engineering researchers been measuring software productivity?—A systematic mapping study. In Proceedings of the 19th International Conference on Enterprise Information Systems (Porto, Portugal). SCITEPRESS—Science and Technology Publications, (2017), 76–87.
34. Sochat, V. The Sadness of the Open Source Developer. (2017); https://bit.ly/3vvklRX
a. The Scrum Guide. Scrum.org (2020): https://bit.ly/3ePRiT6
b. The myth of developer productivity; https://bit.ly/3m3uvF7
c. Definition of productivity—see https://bit.ly/38M7HEc
d. The Five Myths of Self-Compassion; https://bit.ly/3bVDepm
e. Almost two thirds of women face everyday sexism and racism at work; https://bit.ly/3eOB64l
g. Journal of Knowledge Management Practice. (Oct. 2001); https://bit.ly/30UB56O
h. Gitter; https://gitter.im/
The author thanks Ruth Marinshaw and colleagues in the Stanford Research Computing Center, her new team at LLNL, along with the many open source communities that she cares deeply about, for their humor and support during these times.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2021 ACM, Inc.