Prioritization

I have run into some situations recently where it wasn't entirely clear to people how they should be spending their time working on code. So I am writing up a policy to inform everyone of the expectations I have regarding the prioritization of their work tasks.

Summary

• Priority of tasks is usually subject to the discretion of the developer, but bug fixes and tasks requested by me or Grigore take priority over other work.
• For tasks with an explicit priority, the task should be worked on until you can't work on it any more, and only then move to a lower priority task.
• Working on numerous changes simultaneously is a drain on efficiency compared to working on tasks one at a time until they are complete or at meaningful milestones.

How to decide priority

As a developer, you inevitably are working on your own research in addition to whatever responsibilities you have for the group. As such, you have a certain amount of discretion with respect to how you choose to spend your time.

However, some changes are significant to the overall trajectory of the group and need to be considered more important. For example, a change which fixes a bug that is blocking the development of another team member is higher priority than your own research, as are changes associated with major milestones the K framework is trying to reach, or which are explicitly requested by me or Grigore.

In these cases, you should consider your tasks to have the following tiers of priority:

1. Bug fixes
2. Changes requested by group leadership
3. Changes required for major group milestones
4. Other changes / your own research

How to work with tasks having explicit priority

In order to understand why tasks with higher priority should be worked to completion before moving to smaller tasks, it's important to understand some basic information about scheduling in real-time systems. Consider a process with two threads completing unique tasks. They have clear outputs when finished but have no appreciable side effects while running. This is similar to the effect of a code change that ends with a merge.

In the first case, we schedule both tasks to alternate CPU resources until they're both done. Tasks 1 and 2 both take 15 units of time, and they switch off following each unit of time in the pattern 1212... etc. In this case Task 1 completes after 29 units of time and Task 2 completes after 30 units of time.

In the second case, we prioritize one task over the other: the tasks take the same amount of time, but we work on Task 1 until completion and only then move to Task 2. In this case, Task 2 still completes after 30 units of time, but Task 1 completes 14 units of time earlier at time 15. This is a significant improvement in efficiency, especially when we consider that in the real process of code development, code review takes time, and thus we are able to get started on code reviewing task 1 earlier and not waste that time by clumping the review process together into narrow bands of time. We also gain efficiency because other developers can use the outputs of your milestones at the earliest possible time instead of having to wait for further milestones in addition to the ones they are waiting on.

This leads us to the main point of how you should work on tasks with explicit priority:

Always work on the task that has highest priority until you can't work on it any more, before beginning a lower priority task.

In practice this means a couple things:

• If you are working on a change that takes a couple weeks and a quick bugfix is requested by another team member in order to unblock them, you should put off the longer change until the bugfix is ready for code review, and you should promptly work on code review requests for the bugfix as they arrive.
• If you are working on a change with multiple pieces, you should complete one as much as possible (i.e. submit it for code review, resolve code review comments, etc.) as much as possible before beginning another piece of the change.
• If I review a piece of code that is higher priority than what you are working on now, and request changes, you should find a stopping place quickly for what you are doing in order to be able to prioritize the code review for the higher priority task over continuing to work on a change you have already started.

If you have any questions or are uncertain what you should be working on, I would rather you come to me or Grigore instead of continuing to work on something that may not be what is best for the group. Similarly, if you feel we are misprioritizing work, we need to have that discussion rather than simply having you go off and do things other than what we agreed on. It's important that we can trust developers to work in a way that the group agrees on even if they personally disagree, so long as they were given their chance to justify their own beliefs.