⭐️ We all want a good DevEx. Here's how to do it right:

Imagine spending more time coding and less time starting, configuring, testing, debugging, deploying...

That's the dream, right?

Developer Experience (DevEx) is about making it a reality.

Goals

• Maximize time spent on the fun part—coding!
• Minimize the dreaded manual setup and configuration
• Make end-to-end testing easy

Impact

• Increase team velocity by ditching non-value-add activities
• Improve code quality with super-easy debugging and testing
• Onboard new devs quickly with automated essential tasks

By the way, there's an entertaining book about the hurdles of onboarding. I can't remember if it's The Phoenix Project or The Unicorn Project, but either way, both are worth reading! 📚

Measures

• Time to First E2E Result: How fast can you set up and run the system from scratch?
• Time to First Commit: How quickly can you make and verify a change locally?

I heard a friend once literally cry because testing and debugging locally took forever with Docker. Maybe one of you would have a better suggestion for him. Time to first commit is an essential measure to keep up.

Roles

• Dev Lead: Set the dev environment and expectations
• DevEx Champion: Seek iterative improvements in the dev environment
• Team Members: Hold each other accountable and spot deviations
• New Team Members: Identify undocumented processes during onboarding with fresh eyes

Strategies

• Assign hotkeys for essential tasks (because who doesn't love shortcuts?)
• The F5 Contract: End-to-end solutions
• Make tasks cross-platform (unite dev tribes)
• Create an epic onboarding guide
• Standardize essential tasks across solution components (keep it consistent)
• Implement observability for smoother debugging and performance

Number of Repositories:

According to the Microsoft Engineering Playbook, fewer repos = fewer headaches.

But I don't know. It can also be that fewer repos = greater entanglement = more headaches.

What's your take on this?

Minimize Remote Dependencies

Also according to Microsoft, we better use emulators and dependency injection to mock remote dependencies (keep it local, keep it simple). We should abstract remote dependencies behind interfaces (interface is king).

Maybe... only maybe... what's missing is a reliable way of connecting to remote dependencies. 🧡 Check Webcrumbs for instance

Observability

Enhance performance by quickly spotting and resolving issues (like having a crystal ball for your code)

Why it matters to us?

At Webcrumbs, we're developers building an open source for developers. We want to make developers' lives easier. So we're constantly thinking about Developer Experience.

You can give your perspective and ask us what you'd like to make your life easier and funnier. We're all ears: