Code reviews might feel like bumper-to-bumper traffic on your morning commute. You’re stuck. You just need to get through it in order to get to your destination.


Code reviews can sap the joy out of your day. Steal focus. Make it hard to concentrate, even if (in reality) you 

As a result, you could have a tendency to try and rush through a list of pull requests. Or put them off until they threaten to get in the way of moving a feature forward. But with both approaches you’re missing an opportunity to strengthen the culture of your team.


For Derek Prior, a staff engineering manager at GitHub, code reviews are how you build the right culture at your company.


“Code review is the discipline of discussing your code with your peers that drives a higher standard of coding,” 

Those discussions around code give you insight into your team, encourage knowledge sharing, and drive innovation. You’re not stuck in code reviews. They’re the path to getting unstuck.


Code reviews can be a grind. They can bring out our worst habits. But, they can also help you understand the needs of your team and forge deeper connections.


By building a good code review culture, you will make a better culture for your team. Here’s how to do it.


Before you can change the code review process, you have to understand where it is breaking down. There’s always a bottleneck with code reviews. And if you’re a founder or senior engineer, it may very well be you.


Developers with the most experience are the ones on your team most likely to be asked to check out code. It’s a lot of work. And a lot of weight. A backlog of reviews might even be blocking progress in other areas like shipping a new feature.


Maybe you’ve already recognized the problem. So, you started to train someone. But training takes time and trust. Meanwhile, your backlog of pull requests is growing.


Change begins with acknowledging that someone on your team is carrying too much of the burden. Remember, a senior engineer is often not the only one who can review a piece of code.


Your team wants more ownership. And you’re probably ready to clear your plate. So, how do you lighten your load and give them the opportunity?


2. Assess your team’s attitude and comfort with code reviews.

When you notice that all of your code reviews are being done by the same person or a short list of people, Uma Chingunde, VP of Engineering at 

“Is everyone feeling confident to do code reviews?”


Even the most functional teams struggle with how to comment in code reviews. In the early stages of remaking your code review process, encourage teammates to remember there’s a human behind the code.


Gergely Orosz, the developer behind the blog and newsletter The Pragmatic Engineer, believes empathy plays a big role in 

Start by acknowledging that members of your team might still be learning your guidelines or parts of the code. Then, he recommends focusing on “explaining alternative approaches,” and submitting reviews that are “very positive in tone, celebrating the first few changes to the codebase that the author is suggesting.”


There are lots of reasons why members on your team aren’t taking on code reviews. You won’t know why unless you ask. Here’s how Chingunde suggests digging into what’s happening.


“If someone on the team doesn’t review, then have a chat,” said Chingunde. “You can say, ‘I notice you don’t review.’ It’s possible they don’t feel confident or they don’t get the value.”


Your teammate’s answer will let you know if you need to look at how you’re communicating, sharing knowledge, or assigning code reviews. Spoiler alert: It’s all of the above.


3. Good communication begins with clear, concise pull requests.

Ambiguity is a quick way to side track code reviews. The best outcomes – whether it’s code reviews or 

 – come from asking distinct, meaningful questions.


blog post about code review best practices

, has developed a practical method for streamlining the code review process.


“"Only submit complete, self-reviewed (by diff), and self-tested CRs,” notes the Palantir team. “In order to save reviewers’ time, test the submitted changes (i.e., run the test suite) and make sure they pass all builds as well as all tests and code quality checks, both locally and on the CI servers, before assigning reviewers."


Take the time to catch the things that are obvious. You’ll make it easier for the reviewer to get at what’s important and you’ll benefit from insight into challenges you can’t solve on your own.


For Prior, the pull request is the opening of a conversation. The request author provides context – he suggests two paragraphs (focusing on what you’ve learned) for each change – to help the reviewer understand why a given code choice was made. That explanation is also relevant to future discussions because it becomes part of the commit.


The reviewer of the code, in turn, should “ask questions rather than making demands.” By framing potential changes as questions, you’ll encourage discussion that makes space for multiple perspectives and the chance to share knowledge about why a given idea could be the best way forward.


4. Track how long it takes for code reviews to be completed.

As you begin to incorporate more of your team into the code review process, things could naturally slow down.


So, what should you do if code reviews are taking too long? Chingunde thinks this is a great time for another check in with your engineers.


“If people take too long to do reviews, is it because they’re too busy doing their own thing? Or is it because they find it hard to review the code?”


It’s typically some combination of other responsibilities and unclear expectations that may lead to a slower pace of code reviews. In order to overcome that inertia, you will have to intentionally build time into your team’s schedule and reassess how you assign code reviews.


5. Optimize your schedule by using pause points for code reviews.

Code reviews don’t have to be a drag on productivity. By building in time around natural pause points, you can 

 and the cost of context switching. Take the 30 minutes before lunch or after the morning stand-up to review code.


Regular time set aside for reviews minimizes begins to build a habit. You might even use whatever comes next – an espresso or walk around the block – as a reward for completing a code review while you’re establishing that habit.


This strategy is a way to effectively use the time when you’re transitioning away from meetings or coming out of deep work. If it’s following a stand up meeting, the code review could even begin with a short dialogue with the author of a pull request to help give you additional context or emphasis beyond what’s been typed.


6. Assign code reviews to establish expectations for your team.

Your team might be operating under the assumption that code reviews aren’t their responsibility. Asking for someone to contribute isn’t enough to break that assumption. You have to assign code reviews to each member of your team to make it clear this is a shared responsibility.


There are a number of ways to structure assignments. Here are two ideas that could work for your team: Pair engineers together on tasks so you don’t need separate reviews or assign reviews via a rotation system.


Pairs are a useful construct because they facilitate dialogue. And you don’t need to explicitly assign someone to a review. You write each piece of logic as a pair – one person “driving” (typing) – as the other person reads and discusses their code. There will inevitably be more ideas shared and different approaches.


You’re introducing a partner to speed up the pace of play. While pairing, you automatically have a built-in code review as you write the code together. That knowledge – that someone will back you up – also alleviates the stress of feeling like you have to handle everything.


. Creating an automatic assignment rotation helps both the author of a pull request and the assignee. Make sure there’s a clear way for team members to tell everyone, whether in Slack or somewhere else, that they’ve claimed a code review.


An automated system reduces decision fatigue for your engineers. It eliminates the feeling that code review may be a burden and the cost of trying to remember who you last tapped for a review assignment. Perhaps, most importantly, it supports a culture of code reviewing by making it clear that everyone will take a turn.


You can always add in an option to override the automatic assignment if you need someone on your team with specific skills to review your code.


Building a sustainable code review culture encourages productive debates and unexpected insights. Team ownership of code strengthens relationships by defusing conflicts and preventing burnout.


Your team might get by without a well-defined code review process. But establishing clear practices and expectations around code review can help your team better share the load and move forward more smoothly and efficiently.

How to build a good code review culture

Johnathan Bender

Engage your whole team to build the culture you want

Code review culture

Every once in a while, it’s just you and a screen. The rapid click of keys. The beat in your  headphones. The joy of interrupted work.


This is “flow.” You might not call it that. You might not even know exactly how you access it. But you’ve been to the peak of the mountain. Now, how do you get back?


You start by learning the story of flow – an idea popularized by Mihaly Csikszentmihaly, a Hungarian American psychologist obsessed with discovering the “

” [Hint: it starts with ‘f’ and ends with ‘w.’] Then, you look at how flow factors into 

Ever wonder what happens to your brain when you’re in flow? Or why it might help you do your job as an engineer? Us too. And what we found is fascinating.


The final step in optimizing flow is tracking your tasks and work habits. Then, you can start building systems to stay in a 

What do you say? You ready to get going with the flow?


Flow is a state of being. It’s the time when you’re working at a high level with clear focus. You’re stimulated and invigorated. You are completely absorbed in what you’re doing.


, a psychologist who spent more than 50 years traveling the globe to try to understand what powered creativity.


He found there were moments where people felt like their work or hobby was effortless and outside of time. A state of being where they felt in control because their skills were well matched to the challenge they hoped to best.


Csikszentmihalyi coined the term “flow,” and expanded the idea in his 1990 book “

Flow: The Psychology of Optimal Experience.

These are the four key conditions for flow:


The task needs to be the right amount of hard. 

You’ll get bored with a simple task before you’re done. And the frustration surrounding an unreasonable task or one not relevant to your skill set is a clear barrier to finding your flow.

 Both the short term happiness you get from making a quick code change that solves a bug and the larger satisfaction from finishing a project.


 Eliminate distractions. Silence alerts. Close your tabs. Build an environment where the majority of your stimuli is coming from the task in front of you.


Get clarity about why you’re taking on a challenge. Clear goals stave off doubt. Keep your brain from wandering during a task. Put simply: we all need a purpose for doing something.


Beyond defining the conditions for flow, Csikszentmihalyi also made one point clearly and repeatedly: 

Attention is like energy in that without it no work can be done, and in doing work it is dissipated. And it is an energy under our control, to do with as we please; hence, attention is our most important tool in the task of improving the quality of experience. – Mihaly Csikszentmihalyi


Flow is critical for engineers because it is a path to getting your work done efficiently, but more importantly, it is a path to enjoying the process.


You can slog through work not fully focused. It will feel like a grind and move slowly. Or, you can structure your work day to spend more time in flow. You’ll feel more rewarded because you’ll be dedicating your time to the work that matters.


Flow accounts for the idea that engineers are individuals with preferences about how and when they work. By facilitating flow, Beyang Liu, CTO and co-founder of 

, suggests that developers can have more agency over their jobs and design systems that let them move faster because they’re delighted by the tasks in front of them.


 in a post about productivity, flow is “when you have ‘paged in’ all the necessary context and can actually have fun. It’s when you’re 

The story of flow extends beyond productivity. It can also make you more adaptable to change, which is particularly important in a startup where pivots can happen regularly.


Richard Huskey, an associate communications professor at the University of California-Davis, has spent years studying the neuroscience underlying flow. He noted that recent studies have shown flow can 

In an effort to learn more about what is going on in our brains during flow, Huskey recently tested a theory that flow was derived from our brain’s ability to be flexible. So, the professor developed a point-and-click video game, Asteroid Impact [get the 

He had people play the game. Collect gems. Avoid asteroids. He adjusted the difficulty. He then scanned their brains while they were playing to see what happens when we’re in flow. The results astonished him.


“There is no “flow” region in the brain,” 

 Karen Michele Nikos-Rose, the associate director of news and media relations for UC Davis. “Instead, flow results from networked interactions between multiple brain regions.”


In the midst of flow, your brain network is continually adapting to the task at hand. Your brain is working harder; but essentially smarter via more direct pathways. So, as Huskey noted, flow is ““simultaneously perceived as high-control and effortless, even when the task difficulty is high.”


This is why you need to be challenged – and have the skills to meet that challenge – to achieve a flow state.


Here’s why you may be really feeling the flow.

Flow isn’t only using your neural networks, it’s also influencing how you emotionally respond to the task at hand. During flow, the good vibes roll and your inner critic is muted.


Nearly two decades ago, researchers at Bonn University 

 runners in flow had higher levels of endorphins. Since then, studies have shown those in the flow state to have elevated levels of four other neurochemicals: anandamide, dopamine, norepinephrine, and serotonin.


Author Steven Kotler, who has written repeatedly about how humans achieve peak performance, 

 these “pleasure-inducing, performance-enhancing” neurochemicals are important because they increase “everything from muscle reaction times to attention, pattern recognition and lateral thinking—the three horsemen of rapid-fire problem-solving.”


Flow is not only about potential happiness; it also may help stave off self doubt. 

 pointed to research from Charles Limb, a neuroscientist at John Hopkins University, for additional insight into why we might be able to stay in a flow state.


Limb studied the brains of jazz musicians during an improvised jam session and found that the dorsolateral prefrontal cortex (the area of the brain in charge of working memory, executive function, and self regulation), turned off. In other words, that little voice saying something couldn’t be done was silenced in the middle of a flow state.


Free from our inner critics, Kotler suggested that “creativity becomes more free-flowing, risking tasking becomes less frightening, and the combination lets us flow at a far faster clip. “

How much time should you spend in a flow state?

Flow cultivates a positive state of mind. 

 that flow is a buffer to experiencing burnout. And, correspondingly, that a lack of flow, can make it harder to stop feeling like the work will never get done.


Aiming for constant flow is an unrealistic goal. There are too many distractions. Too many interruptions. Tasks that will be too difficult or hard. But, being intentional to spend just a little more time in flow during the work day can yield big results.


 shows that knowledge workers are five times more productive when they’re in a flow state. If you can spend 

, you’ll achieve as much as you would in a 50-hour work week of average productivity.


, suggests looking at your current routine.


“So little time is spent in a flow state because operating at maximum mental capacity is energy-draining,” 

 Roomer. “That’s why it’s critical to do your flow state work when your mental energy levels are at their peak.”


Try to assess when you have lots of energy for work – perhaps at the start of the day or after a workout – and when your energy tends to wane – post-lunch or after back-to-back meetings. Then, adjust your schedule based on what you learn.


Build in clear blocks of time for specific types of work. You might try the 

 (breaking your day up into 30-minute bites known as a “pomodoro,”) and designated meeting times each week. Time blocking cuts down on the cost of  switching and helps you slip into the flow state more easily.


You might want to start tracking your flow.

Tracking flow probably feels a bit like trying to hold water in your hand. The harder you squeeze, the more it seems to slip away.


Tracking flow is really about paying attention. It’s about understanding when you are productive. And when you are lagging. And then examining the work you were doing in both instances.


Keep a journal or make notes in your schedule about when you were in flow. Try and jot down exactly what you were doing and for how long. Don’t ignore your emotional state, whether you find the work taxing or enjoyable. At the end of a week and then a month, look back at your notes and take action to make your schedule work better for you.


Build support systems for your team to encourage and sustain flow.

Once you start to recognize flow and assess the frequency or duration, you can find your flow faster.


While Csikszentmihalyi believed we all could achieve a flow state, we don’t arrive there in exactly the same way.


People he termed “autotelic,” were task-oriented. They could find meaning in the constraints of a job and might be open or seeking new experiences.

Sound like you? Since you can likely navigate internal distractions that compete for your attention, you should focus on limiting 

. Set expectations with your team about your availability. 

 for dedicated coding time. Schedule meetings around your peak energy hours.


If your tasks don’t get you out of bed in the morning, don’t worry there’s still a path for you to find your flow.

Exotelic folks  – motivated by the end goal or what happens as a result of an action – need help managing internal distractions. This is where you may need to work to change the job or task itself to mirror what happens in a game.


Add more stimuli. Offer added attention, feedback, or praise. Tweak the difficulty or add in feedback (stimuli) once you’re engaged with a project, just as Huskey adjusted the difficulty of a video game, to try and keep a player engaged.


We all may arrive at flow in a different way; but we all can benefit from understanding more about the process of flow. Take the time to understand what you need to get into the flow and discover exactly what you’re capable of when you’re performing at your best.


A deep dive into flow

Get in flow to do your best work and enjoy the process.

You've launched or released a major new feature. But there's still all of the code that’s hard to work with because it needs rearchitecting.


"Tech debt is unique to start-ups in that if you're worrying more about tech debt than the growth of the business, it probably means you’ve made it… to a certain degree." said Sonia Yang, CTO and co-founder of 

, which helps brands with resale services.


Congrats. You've got tech debt. You probably also have a list of bugs and tests (which your engineers have told you about once…or a dozen times) on your to-do list.


Now, there's another feature to be shipped. A customer base with a slight uptick in churn. So, how do you know when to shift gears from product to proactive maintenance?

 (Slack-native technical onboarding and training to enable your software engineering team at scale), and 

 (issue tracking tool for high performance teams) to understand more about how they’re approaching tech debt, tests, and bugs as a startup. And we came away with 4 clear lessons on accessibility, decision-making, prioritization, and story-telling.


Keep reading to discover why maintenance tasks and tech debt don’t have to sidetrack your product roadmap.


1.  Level up your code quality to help usher in new teammates.

When you think about tech debt, you probably (and understandably) focus on all of the things you haven’t done. But if you want to develop a sustainable system for high code quality, you need to think about the engineers who haven’t yet joined your team.


"We realized that if we want to grow, we have to make it easy for people to enter the culture," said Treet CTO and co-founder 

Much like when you clean up your house because guests are coming over, Treet found the right moment to solve lingering bugs was in the weeks before onboarding a new pair of engineers. Yang scheduled a sprint session with her team centered on a checklist of issues that was discussed, edited, and then assigned.


While the pause to clean up code was effective – Yang estimated they tackled 70% of their issues during the time dedicated to fixing code – it was what happened afterwards that could yield significant benefits.


The company put in place monitoring to measure the effectiveness of the work. They’re also re-examining how they document changes.


Treet and other startups could look to Linear for a blueprint on how to advance projects while fixing bugs. Linear CEO and co-founder Karri Saarinen has developed a culture that encourages engineers to fix problems when they’re noticed; but also know they’ve got a backstop.


"We have one engineer in “goalie,” rotation, which is basically the person to help support and fix bugs and issues that get reported," said Saarinen.

Treet is weighing a rotation or dedicated percentage of bandwidth to ensure there’s always someone chipping away at the tasks that need to get done.

"One sprint session will never clean our entire plate off," said Yang. "Now, it’s top of mind when we’re building something to think about how sensible it will be for another engineer to come after."

2. Find the right decision making framework to balance maintenance and features.

Small teams are nimble by design. Decisions need to be made quickly to account for user feedback and product pivots.

Yet, how do you hold on to flexibility – to defuse potential tension between the need for maintenance and the desire for better performance – as your team is growing?

For Jayme Rabenberg, Director of Product for Edify, the answer is simple. You need to adopt a clear decision making framework to decide when and how you’ll tackle testing, code quality, and tech debt.

"You have to start with a framework because you can't develop one in the heat of the moment," said Rabenberg.


Since decisions may be difficult, it’s imperative the decision-making process be simplified. Rabenberg is partial to 

, a time management system developed by former President Dwight D. Eisenhower. Here, potential problems are addressed, delegated or deleted according to their urgency (x-axis) and importance (y-axis). If something is both urgent and important, it takes priority.

At Edify, there’s a decision maker for each project. The rest of the team then slots in as advisors, offering context (what customers want or what results might follow) to allow the decider to understand the urgency 

Tech debt and tests are unlikely to be deemed urgent; but they can take priority when long-standing issues are slowing or stopping new feature development. Conversely, functional bugs and performance issues often seem urgent, yet may only be important to solve if they’re detracting from the user experience.

A decision-making framework provides the consistency you need to weigh different courses of action and determine how resources will be allocated. It also creates transparency. The voices of team members are heard. Decisions are then holistic accounting for the needs of different departments and feedback from users.


What about the small fixes, what Rabenberg terms "microdecisions," the ones that might fall through the cracks?

Rabenberg empowers her team to make their own choices to efficiently solve discrete problems. For those decisions deemed too small for the formal process, Edify has outlined design standards and establishable, measurable outcomes to help offer guidance that still allows for autonomy.


3. Consider costs and benefits to know when to tackle tech debt.

Once you acknowledge that you can’t – and might not even want – to address all of your tech debt, the work isn’t done. You still have to decide when to prioritize maintenance.


At Treet, Yang honed in on the errors that interrupt an engineer's ability to 

"If an error is happening multiple times a day, and that error needs a manual fix each time, that’s time away from doing core work," said Yang.


Treet often prioritizes bugs that need to be solved immediately because the cost of that debt – the lost time and focus of an engineer – is too great. Another way to assess the value of a maintenance task is to consider the ultimate benefit to your end users or team.


At Stashpad, we're hyper-focused on performance. Developers can't get value from our product unless it's fast.


"Performance standards are  part of the acceptance criteria of all new features and we prioritize tech debt when it’s starting to get in our way and slow us down," said Stashpad CEO and co-founder Cara Borenstein.

By keeping our core feature set small, we make it possible to keep our standards for performance high. This provides common ground and a shared language for our product and engineering teams, ensuring decisions are based on how they ultimately affect performance - even if that means fewer features are shipped.

"Narrowing scope is empowering," said Borenstein, "The less surface area we are trying to cover, the better job we can do at the one thing we’re trying to do well. The best products are very simple and work very well."


4. Don't forget to tell the story of each decision.

Once you’ve actually made a decision to prioritize tech debt, bugs, or new feature development, it’s important everyone on your team understands why the decision was made.


"I had to learn to articulate why I made decisions," said Rabenberg. "I don’t think that's particularly innate even to those of us that are good at making decisions."


Acknowledge that individual emotions are part of the process, even if the decisions are based on a clear set of metrics or the demands of the market. By holding space for people to share what they're feeling, it eliminates the possibility a pivot may leave one of your team feeling left behind. It also can help you gain clarity on what you need to prioritize next.


"As a leader, I think my job is to facilitate an environment that feels safe," Rabenberg said. "How we show up as humans and interact as humans is the thing that makes us successful."


Remember, you're not only taking care of the emotional needs of your team, you're also aligning team members, customers, and your leadership. The story of a decision is part of the story of your company as each decision is a step in a new direction.


"When we're clear on the why, it's much easier to prioritize and find the right path forward," said Borenstein.

When to Prioritize Code Quality at a Startup

We asked startups to share how they prioritize tech debt, tests, and performance in their product roadmaps.  

When to prioritize code quality at a startup

We're building Stashpad to help developers stay in flow so they can do their best work and enjoy it.

We're software developers. In 2019, our first idea was to build a better wiki for engineering teams. We talked to hundreds of developers who described their workflows and the challenges they experienced. But we couldn't help but notice that something else was always up on their screen. It was the humble scratchpad - an untitled text file, sticky note, message to self, or similar.

The scratchpad is key to how developers get work done.

It's where we jot things down to process information. It's where we go when we have an idea of how to solve a problem. It's where we go to stash something away to come back to later. It's where we go to start drafting a document or considered reply to a teammate.

The scratchpad is where we go to begin our work.

And yet, for most of us, our scratchpad consists of a jumble of sticky notes, random text files, scraps of paper, and messages to yourself.

The result is that we're constantly operating out of a state of chaos. And we don't have to.

Stashpad is a new scratchpad for developers. It's fast to use and actually stays organized so you can do your best work and enjoy it.

Stashpad has all the features that developers expect of any tool - like code syntax highlighting and markdown support. It's also specifically designed to reduce friction in common workflows - like seamlessly jotting something down on an unrelated topic.

You'll find many little details in Stashpad that are intended to make life as a developer just a little bit better.

Bytebase is now Stashpad. We're in Open Beta!

Today, we're excited to announce our name change from Bytebase to Stashpad. In our new name, we wanted to better communicate what the tool is and what it enables you to do: Stashpad is a new kind of developer scratchpad that makes it easy to stash your thoughts and notes without breaking your flow.

We're also excited to release the Stashpad Desktop app in Open Beta. Any developer can go to stashpad.com and instantly download the Stashpad Desktop app for MacOS, Windows, or Linux.

And we're just getting started. Stay tuned for a Stashpad mobile app, integrations with other key tools in the dev toolset, and full extensibility so you can build exactly what you need to power your workflows.

Introducing Stashpad

Cara Borenstein

Stashpad is a new scratchpad for developers. 

In the office, it’s pretty obvious when your colleague is in 

. You look over and see that she’s deep in some code. She’s in the zone, with her eyes glued to the screen. If your question isn’t urgent, you save it for later. If it’s urgent, you interrupt and get all hands on deck.

When you’re in the office, it’s also obvious when your colleague is on a break. She’ll be away from her desk. If you have a non-urgent question, you save it for later. If it’s urgent, you send a page and go looking.

With Work From Home, you don’t have this same type of visibility. It takes a little more effort to recreate it, but it can be worthwhile and provide benefits beyond teammate visibility.

The last few weeks, we’ve been experimenting with using a set of 4 emojis to denote our current status at work: Deep Work, Deep Break, Out of Office (OOO), In a meeting.

Each of us sets a Slack Status as we transition throughout the day.

1. Select your photo/avatar in the top right to view settings.

2. Click on your Status to start editing.

Blog | From the Stashpad team and community

How to build a good code review culture

A deep dive into flow

When to Prioritize Code Quality at a Startup

Introducing Stashpad

Setting slack status for remote work

Maximize creativity with planned group brainstorming sessions

Find Meaning In The Gritty Work

How we minimize deep work interruptions at Stashpad

Why the pomodoro method is more useful than you might think

Embrace the reality of zoom meetings and make them work for you

You probably don't need a knowledge garden

5 strategies for self-care when working from home

How to maximize deep work when working remotely

Status dumps for software engineers

Start stashing today