How ZenHub’s Browser Extension Simplifies a Developer’s Workflow

Editor’s Note: This guest post is by Anna Zhao, Frontend Developer at Dapper Labs.

Three years ago, I decided to make the career transition from a CEO’s Executive Assistant (EA) to a Software Developer. I was already working in the tech industry, and watching the Engineering team work had piqued my interest.

As an EA, my days consisted of chasing various people and projects, juggling all the different pieces to ensure things were on track. Managing multiple calendars, email inboxes, and project management tools meant that organization was key. The tools I worked with could make or break my efficiency – the best tools gave me exactly what I needed right at my fingertips, while the worst ones were cumbersome and time-consuming, often becoming more of a hindrance than anything.

When I started working as a developer, I found myself on the other half of the equation. Suddenly, I had to find a way to manage my work in a way so that others – project managers, product owners, the other developers on my team – could see what I was up to, and vice versa. Sure, coding itself was brand new to me, but I also had to get used to being asked things like, “How long will this take you?”, “Is anything blocking you?”, or “What should be worked on first?”. I quickly noticed that the time it took to organize and plan tasks was substantial, even for a small and cohesive team. It was time that could be spent shipping code!

With trial and error, I began to find the right tools that would help me optimize my efficiency. The ZenHub extension has made the biggest difference to both my individual productivity and team workflow. Below, I’m going to share some of the ways ZenHub has made my career transition smoother, as well as how I use it to enhance my work day-to-day.

Challenge #1: Getting in the zone, and staying there

When I worked as an EA, I always worked on countless things at once; waiting on updates from various projects while I checked off smaller tasks on my to-do list. My days were filled with meetings, so I squeezed in minor tasks in between. It wouldn’t be unusual for me to start the day with a to-do list of twenty items, and have them all completed by the time I finished for the day. The nature of my work made it easier for me to transition between different tasks and work on multiple things at once.

When I became a developer, I suddenly understood why Engineering teams were always complaining about meetings. Instead of various smaller tasks, I was often working on building one big feature, untangling a complicated refactor, or chasing a nasty bug. It was much harder to work in scattered spurts; it often took a substantial amount of time for me to fully wrap my mind around what I was working on. It was suddenly a lot more important that I work undisrupted, or I’d lose my train of thought. The switching costs of being interrupted in my work were a lot higher, and I needed to adapt my tools to work with that.

I love that ZenHub lives right inside of GitHub, letting me work with minimal disruption. The best tools are the ones I barely notice I’m using! When I’m about to begin building a new feature or fixing a new bug, I start inside GitHub. This is where I can see Issues assigned to me and their requirements. While I’m there, I can take a glance at ZenHub’s Board, which allows me to instantly get an overview of our current Sprint. Using the Dependencies feature, I can see if what I’m about to work on is blocked by other tasks (or if there’s a different Issue I could work on first to unblock someone else!). The highest priority Issues are pinned to the top of Pipelines, so I can be assured I’m always focusing on the most important work first.

When I’m ready to grab an Issue, I can easily update the Pipeline of the Issue, so my team knows what is in progress. Alternatively, I might notice that our team already has a lot of work waiting for a PR review or QA. In this case, it’d be better for me to unblock my team first before starting a new task. I never need to leave GitHub and log into a separate tool. It all lives right where my code does, so seeing all this information is second-nature.

Using ZenHub feels natural and minimally disruptive because I’m always inside of GitHub anyway. I don’t have to consciously make the decision to use ZenHub; it lives where I already work. This makes it much more likely I’ll remember to keep information up to date.

Challenge #2: Maintaining a single source of truth

Whether you’re a developer yourself, or you work around developers, you’ve probably heard the following two axioms: writing code that doesn’t repeat itself (or “DRY” code), and maintaining a single source of truth. The heart of these two is the same – when possible, you want to write your code in a way that every instance of the same thing points back to one place. There are various reasons to do this, but the key benefits can be summarized in two points: DRY code is easier to write and easier to read.

Let me expand on this. It’s pretty obvious that writing something once is easier than writing it twice. But it isn’t just the first time you implement something. It’s also each time you update or refactor something too. Instead of hunting down each instance to replace them all, you have confidence that changing things in one place will update your entire application.

How do these principles apply to project management? As an EA, I constantly heard “I’ve already started (or even completed!) that task, but I forgot to update the ticket!”. The status of work was scattered everywhere – in weekly reports, in the comments of tickets, or in long email threads. There wasn’t one place I could rely on to be the single source of truth.

ZenHub prevents this by tying everything back to your code (and GitHub Issues). When a PR is opened, the Pipeline of a connected Issue is automatically updated. (The Pipeline it moves to can be customized to best fit your team’s workflow!) When Issues are closed, this change automatically propagates throughout ZenHub. The Board will move the Issue into the Closed Pipeline. Reports will update, recalculating predicted end dates based on your latest progress. Dependencies will refresh, removing the “Blocked” status on dependent Issues. None of this needs to be done manually, removing opportunities for information to fall out of sync.

Because ZenHub utilizes GitHub’s native Issue data, I don’t need to use the extension directly to reap the benefits. Sometimes, I’ll grab my phone to quickly review a PR or respond to an Issue comment. In these instances, I’m using GitHub without ZenHub. However, this doesn’t mean I’ll need to go back and manually update ZenHub to keep things synchronized. Updating the comments, labels, or open/closed status of an Issue automatically reflects the change in the ZenHub board. This is yet another way ZenHub reduces the margin of error when it comes to keeping information consistent and correct.

Challenge #3: So many tools, so little time

When I first learned to code, mastering my text editor was a whole process in itself. I quickly discovered the world of developer tools extended well beyond that. My team uses Zeplin for design mocks and Storybook for developing UI components, as well as a variety of logging, monitoring, and CI-CD tools. It’s a lot to keep track of! Learning to use these tools effectively has been critical in improving my overall efficiency as a developer.

When a team chooses to adopt a new tool, there’s an inevitable learning curve as everyone familiarizes themselves and learns how to best fit it into an existing workflow. ZenHub minimizes these onboarding pains by being built right on top of GitHub. It’s more than just being able to work without downloading a separate tool. ZenHub fits intuitively into GitHub’s existing UI, providing a cohesive and instinctual experience.

In the same way, I can add Labels to an Issue in GitHub, I can add Dependencies or a High Priority pin. GitHub’s Milestones serve as a natural representation of Sprints, with ZenHub’s Burndown Charts built around it. However, ZenHub further extends this with Epics and Releases as well. Epics provide Issue hierarchy – when creating new Issues, only a few clicks nests them into a parent Issue. Releases use your Issues in predictive, long-term planning. Adding an Issue to an Epic or Release is as easy as adding it to a Milestone, but these additional features allow Issues to be grouped in more nuanced ways.

ZenHub is organized in such a way that you see what you need in a given context. For example, the Issue page of an Epic shows all nested Issues and their Pipelines right underneath the Issue description, with links to each Issue. In one glance, I can see what’s completed in my Epic and which pieces of work are in progress. An extensive reporting suite allows project managers to see progress and predictions in various visualizations. However, as a developer, I get the most value out of the Board. ZenHub smartly tucks Reports away in a separate tab, allowing me to commit code and review PRs without any additional visual clutter. Pipelines that aren’t relevant to me can be collapsed.I easily see the information I need, no more, and no less. This keeps the experience snappy and quick.

In conclusion, ZenHub changes the way our team works, allowing us to ship more value, faster. We benefit from it at every point in our workflow – whether it’s Sprint Planning with the Board, or mapping long-term plans with Roadmaps. It provides clarity and transparency, without high overhead costs. At this point, I couldn’t imagine working without it.

Editor’s Note: This guest post is by Anna Zhao, Frontend Developer at Dapper Labs.

The ZenHub extension is available for Google Chrome and Mozilla Firefox. The ZenHub web app is also available for Safari and mobile.

Ready to get started? Sign up for a free 14-day trial.

To read more about how a software team can benefit from adopting ZenHub, check out this other blog post here.