Your guide to Developer Experience Week at GitHub InFocus

This year we hosted our first all-virtual GitHub Universe—and you tuned in to join us from 174 regions around the world! We knew there was even more to cover, so we’re trying something new: GitHub InFocus, a global virtual series just for software teams. Each week will feature a new topic—developer experience, DevOps, or security—and three new global hosts to guide you along the way. We checked in with virtual hosts Martin Woodward, Bassem Asseh, and Faten Healy for a quick Q&A on next week’s topic: developer experience.

If you attended Universe, you might see some familiar faces at InFocus. Martin, you hosted the Enterprise track at Universe. What’s different about what teams and developers can expect to see at InFocus?

Martin: One of my favorite things is that at InFocus we’ll be hearing directly from other teams in companies large and small about how they’re implementing many of the things you heard about at Universe. You’ll get to learn from them about what’s worked and what they would do differently, and ask questions about their experiences. I think of InFocus as the hallway track of the conference you go to—where you’re able to meet other attendees between sessions and share advice—and often that’s the place I learn the most.

Many software teams and organizations are familiar with industry terms like DevOps, but ‘developer velocity’ and ‘developer experience’ are a bit newer. For folks just getting acquainted, what does ‘developer experience’ mean? Why is it important for organizations?

Martin: Developer experience can mean different things depending on the context. It can describe the way developers outside your organization interact with external tools like your API keys, or the experience developers inside your organization have building your software. In business and with DevOps, teams are getting better and better at focusing on the customers and delivering value to them. But I still talk with lots of companies who are putting friction in their development processes rather than focusing on the developer experience inside their organization and how they can improve it to speed the flow of value to customers. When was the last time you asked your engineering teams about what slows them down and stops them from shipping awesome software? At InFocus, we’ll be exploring how to reduce that internal friction rather than external tools.

Next week, we’ll be talking to folks at Comcast and more organizations for specific examples of how to build a good developer experience. Just to set the stage: What does a good developer experience look like? What are some quick examples of best practices that folks can expect to learn this week?

Bassem: Organizations and communities have a pretty simple goal in this digital world we live in: Get better software shipped faster. But while this goal may be simple, many organizations and communities aren’t able to reach it. What’s missing? A good developer experience. Developers (and the people they work with) need to be as comfortable as possible doing what they do best—writing code—so they can leverage the best of themselves. In practice, this can look like using an integrated environment that maximizes automation so developers can focus only on the most complex tasks. Next week, you’ll see some examples of what can happen when the majority of manual or less-interesting tasks are offloaded and automation takes care of the rest.

As Martin shared, ‘developer experience’ can be a new concept depending on your organization. How can teams learn more before they attend?

Bassem: I’d recommend taking a look at what your team and developers miss doing most in their day-to-day tasks. For example, this can highlight the fact that they’re spending more time on peripheral tasks rather than on what they do best—again, writing code. Something else you might notice is security. Like Martin said, ask your team questions. If you’re a developer, ask yourself things like, “What am I doing in order to take care of software security in the code I’m writing?”

You can also explore some of the discussions from GitHub Universe, including our COO Erica Brescia’s keynote on velocity and developer experience and how teams at The Home Depot used developer experience to modernize their engineering culture.

InFocus topics and sessions might vary by region. Which talk from Developer Experience Week are you looking forward to most?

Faten: If you’re tuning in from Asia-Pacific, we’re focusing on this week’s keynote: Driving Innovation by building better developer experience. And I’m super excited about this session since we’ll be going deeper on what Erica covered at Universe, including all the new things that GitHub is building to help teams accelerate software delivery and provide great experiences for developers. We’ll be talking about auto-merge pull requests, updates to GitHub Actions, and, of course, dark mode. We’ll also be sharing more about GitHub Enterprise Server 3.0, which includes GitHub Actions and Packages, code scanning, and secret scanning.

Last but not least: if folks could only take away one thing from Developer Experience Week, what should it be?

Faten: Developer experience might be one concept, but it actually depends on four important areas. To improve your developer experience and accelerate software delivery, it’s important to provide developers with the right tools and resources across them all.

• Collaboration: Developers benefit from working in a collaborative community built around code.
• Automation: Workflow automation helps developers stay in flow (ex: leveraging tools like GitHub Actions).
• Security: Securing your code also means making sure your supply chain is secure, so the dependencies developers pull in from other projects aren’t a vulnerability.
• Reliability: Your platform should be scalable, resilient and available, so it’s there whenever your developers want or need to access it.

Want to learn more? Tune in to InFocus starting on February 23 at 11am PT / 2pm ET or check out the full list of sessions.

Written by

Grace Madlinger

@gmadlinger