Improve your Developer Experience and create a culture of success

What is DX, and why is it important?

Imagine you’re a plumber, and a customer has asked you to fix their water softener. You drive to their house in the morning, and your customer greets you at their door. They quickly show you the exterior entrance to the basement—a big Bilco door wide enough for your hand truck. The basement is a clean, dry, and well-lit space, with power outlets available right next to the brine tank you’ll be working on.

After lunch, you drive to your next appointment—a farmhouse down an unmarked lane in an area with no cell service. A post-it note on the locked door says, “EQUIPMENT IN PIT – BEWARE OF DOG.” You spend the rest of the afternoon hauling filter material, bucket by bucket, up and out of an unlit brick vault in the backyard, all the while listening for growling and keeping an eye out for the snakes that like to curl up under the equipment.

In both cases, the job is exactly the same—to dump and rebed a water softener. The price might even be the same for both jobs. But the morning and the afternoon are vastly different. The difference between those two visits is “developer experience.”

Think Company alumni and senior developer Jessica DiPonziano summed it up this way: “Developer experience is simply how easy or difficult it is for a developer to perform the essential tasks needed to implement a change or add a new feature.”

Just like the clean, dry basement, it’s easy to do your best work when the developer experience is good. Think Company engineer Cameron Messinides puts it this way: “My favorite developer experiences make it easy to put the user and their experience first.”

Good Developer Experience starts with tools

What kind of computer does your organization issue to developers? Do they have an external monitor? Can they have more than one external monitor if that’s what they like to use? Do your developers have a quiet place to work?

Good developer experience isn’t just about tools, but good tools and a good working environment are the foundation for everything else.

Do your developers have to log in to a VPN every fifteen minutes to refresh their credentials? If so, it’s going to be really hard to address a tricky question.

Having good tools—and no barriers to focus and attention—helps developers get into a place of sustained productivity. Jess adds: “When you get in “the zone,” you’re just developing, and four hours go by, and you didn’t put your head through a wall. You didn’t have to deal with something that’s difficult but shouldn’t be. You’re solving puzzles, and that’s the fun part.”

This applies not only to the hardware tools your developers are using and their connection to your network, but also to the frameworks your organization has selected for your project.

For instance, Cameron loves Playwright, a testing tool that allows developers to verify that what they’re writing actually works as intended: “My favorite thing about Playwright is it makes it easy to test your sites like a user. You can use Playwright to perform actions, like typing in a form field or clicking on a link, and it doesn’t just simulate the events: it takes control of the browser and acts on your page like a user would. Not only do you get confidence that your features will work for your users, but you don’t have to rewrite tests when implementation details change: if the UI is the same and the expectations are the same, you don’t have to touch the tests.”

More than tools, Developer Experience is about process

Great tools will lead to great developer experience for one developer working by themselves. In a team environment, it’s the interfaces between people that are crucial.

If it’s unclear whether the designer will like your work—either because you don’t have the “source of truth” handy or because you don’t even know who the designer is—then you’re risking rework.

Here at Think Company, we work to streamline process by making documentation available to the people that need it most, in the space where they’re already working—whether it’s the Figma files they’re already referring to or the Jira or Rally tickets they’re consulting. 

That clarity not only helps to avoid rework, but also speeds collaboration.

Most of all, good Developer Experience is about strategy and culture

The story about the dry basement and the scary backyard hole is slightly more complicated. That’s actually a true story about John’s father-in-law—and, despite the pit and the dog, the farmhouse was his favorite visit. It was his favorite visit because the elderly woman who lived in that house was lovely, and her water was very hard. The equipment installed made a huge difference to her, and she was really appreciative. So even though it was higher effort, the fact that the work was meaningful and appreciated outweighed all the other considerations, even the excitable dog.

More than tools, more than process, a clear vision of what is being built, why it’s being built, and a shared sense of ownership is the most important part of developer experience.

Cameron underscores this: “A developer culture that expects and encourages devs to think of the user (by raising and fixing accessibility issues, testing and improving performance, and more) is great DX.”

Jess: “If, as developers, we know the overarching strategy and the goal, then we can understand what the goal is, and we best decide what we’re doing to fit that strategy and those goals. If we already feel like we understand what’s going on, then rapid changes are pivots we can help with, not confusing swirl we have to react to.”

Jess emphasizes that “when the code is DRY, and it’s code to the point where you can start to remember what does what via a simple name. You start getting discoverability and memory. Things get faster, and that faster compounds.”

That strategy is also the hardest part of developer experience because it’s an effect, not a cause. It’s an effect of having clear leadership visions, empowered product owners that know what they want to accomplish (and what they don’t need to accomplish), and a focus from top to bottom on the end user—on the needs of the person that will be using the product in the end.

Even if the tools are rough, even if the process has some hiccups, if the developers trust their teams and feel like they’re able to collaborate, the rest can be solved together.

Are you rethinking your development team strategy—structure, tooling, and process? We can help! Chat with our development experts today.