We often talk about time management, communication, and task completion, when we think of developer productivity. 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. Accomplishing tasks or filling up ones’s schedule does not necessarily equate to productivity. Productivity is less a quality that can be easily measured, controlled, or improved directly with tools, but instead is a human element that manifests from developer happiness. As a developer who has transitioned to working remotely, almost under a decade before, I have slowly learnt to optimize my own productivity by focusing on my well-being as an individual inside an organization.
Let me summarize, them in simplest of terms I can break down to.
What to do?
- Work on Things You Care About.
Work on projects or software that you care about. 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. 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. 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. 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. 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.
While we could define productivity based on lines of code or developer outputs, 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, 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. Although happiness and productivity are not exactly the same thing, they seem to be intimately related.
How to do?
- 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. The more that you are able to repeat a behavior in a specific environment, the more likely it is to become effortless. 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 Human Connection.
When newly remote, it is common to place the burden of connection on your team. If your team is not remote first, 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. 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/work on 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. As a remote worker you might live in isolation, but you do not need to work in it.
- Practice Empathetic Review.
Software engineering requires a lot of technical communication. Whether you are having discussion in a chat window, 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, and having good productivity can further make you a better, less adversarial communicator. 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. 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.
- Learn to Say Yes, No, and Not Anymore.
You might be someone who very easily says “yes” to contributing to a project, or generally providing help. 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. 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.
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.