When learning programming you learn about arrays, maps and objects, but when you work in the real world, with more events to process than you can keep in memory you have to learn about queues. They show up in networks, batch processing, OS management and pretty much any problem you can think of.
We will explain queues and then give you use cases for a queue in your workflow.
Queues are a natural data structure that keeps tasks or information to be processed neatly organized. You add to an array or linked list on one end and, depending on the type, will take from the same or the other end. The most common ones are:
- Last In, First Out (LIFO)
- First In, Last Out (FIFO)
A good way to understand these is with real examples in the world around you. A FIFO queue is like a line in your favorite coffee shop, where you come in and wait for each person ahead of you to order their coffee, and eventually it is your turn to get a good cup of joe. A LIFO is like one of those amazing fruit towers in your local grocery store, where the one first set on the display sits at the bottom, and you put all the others on top and when time comes to take one you will take the one from the top, unless you like chaos and picking up all the fruit.
This sounds like a lot of the moments of working as a team. Waiting for PRs to be approved, putting and pulling things in your backlog, deploying to production, creating feature branches for gitflow or GitHubFlow, waiting for a message response, ordering food for the all-hands…
We took a step back from the usual and noticed that we can model these problems as queues and make it faster. Your team will love thinking of their tasks as a queue, with some constraints. When reviewing PRs, for example, you usually review top to bottom, which makes a LIFO queue, and might make you lose some context, even when using AI for code review.
This is probably suboptimal for teams that want to deploy faster. We hope that’s you.
A FIFO queue will be better, as the traditional git system builds upon the previous changes, and usually your teammates will pull before developing. To avoid this we recommend asking your teammates to start reviewing at the end of the list, and tag the issues tackled so you have a cross reference. GitHub allows you to close issues from PR descriptions or comments. Also, without being pushy, ask other developers to review your code at their earliest convenience, remember that breaking someone’s flow is a big no-no. To help you there’s the GitHub Slack bot that will post which PRs are awaiting review and tag people requested in the channel you select.
Finally, moving across environments to production, will be a LIFO queue, but should be a FIFO, as breaking changes should be quickly found and solved, but will move usually as a single block of changes. Be careful and opt for automating error finding to speed up your production releases.
When putting things in your backlog in Jira, Linear or Asana you might suffer the stack pressing problem, in which things added at the start of the queue will never get popped. Older problems seem less important, you get paginated responses, and most ticketing systems add at the top, so you and your team will have to make an effort to keep pruning the backlog. Again, a FIFO queue will be better, or try another view, maybe timeframe the problems.
You’re probably putting together beautiful strategies on how to tackle everyday problems, and will think of implementing systems to keep your team neatly organized, but remember, they are people. Changing people’s customs takes forever, and improving systems is not always possible. You’re better off adding to the ways people do and slowly pushing towards better systems. Remember that for huge PRs people will approve with “LGTM” and nothing more. If your code diff shows more than a few dozen lines, people will skip really reviewing it!
Before this becomes salesy, we will teach you more about queues in the next blog. We’ll talk a little about other types and how to use them in systems design. We still recommend asking GPT or your favorite assistant to get a deeper understanding.
At Watermelon we built an AI assistant that can take from anywhere in the queue and bring context in, a huge help in the PR reviewing process, as well as adding tags to PRs, so you can pull from the whole stack and feel more confident when looking at code and lastly, we comment on possible errors, reducing mental capacity required to read over the long changes. Try it now.