About the Author

My first DX experience happened long before my software career.

In one of my earliest jobs - when I was still a designer at a small advertising company - I ran into chaos around printing and production tracking. Mistakes, lost orders, mismatches - most of it came from the lack of a proper system.

I built a simple system to track printed materials and their statuses. As a result, the number of issues dropped sharply, and the process became predictable.

Back then I wasn't writing code and didn't even know the term DX. But I was already improving the system I worked in, so both I and our clients would spend less time and fewer nerves.

Later I worked as a developer-analyst at a small company.

When I joined, the previous analyst left me an Excel file that took a full hour to save. That's how I learned SQL - because I couldn't tolerate it - and cut the calculations from an hour down to 20-30 seconds.

I started gradually automating processes - step by step.

In the end, my entire workload shrank from a month to 3-4 working days.

Back then I wasn't improving colleagues' lives - I was improving my own work. Because if a system is inconvenient for you every day, you either fix it or burn out.

And since the company simply didn't have enough work for me for a full month, they first offered me to work from home - and later laid me off.

But I never regretted it - it was invaluable experience that opened new perspectives for me. Even then, I realized how much I enjoy this kind of work, especially when you manage to improve processes so dramatically.

The real shift happened later, at Yandex.

I spent 7 years there as an engineer, building internal tools, libraries, and infrastructure solutions. That's where the focus gradually shifted from "it's more convenient for me" to "it's more convenient for the whole team".

I started improving, systematically:

• onboarding for new engineers,
• internal UI libraries used across multiple teams,
• developer tooling adopted by hundreds of engineers,
• team workflows and automation.

DX stopped being a "side effect" of my work and became an important part of it. I kept noticing how small improvements in tools or processes could save hours for dozens of people - and how much more valuable that was than it might seem at first.

I've been at Microsoft for more than 3 years. I joined as a frontend engineer on the Skype team, working on product features. But from day one, I kept collecting things that bothered me from a DX standpoint: onboarding wasn't great, local builds weren't stable, and many processes could be improved.

Nothing seemed critical - you could still ship. That's how most teams operate: people get used to friction because there are rarely dedicated resources to improve it.

And about a year later (at the end of 2023), I stumbled upon an article about Developer Experience. I read it - and something clicked in my head.

It was a moment of absolute clarity. For 10+ years I had been doing exactly this - I just didn't know it had a name. All those years, projects, and system improvements had a label.

Right away, in the internal review process (Connect), I wrote it explicitly: I wanted to add DX as an additional goal for the next cycle. It was my personal initiative, not a formal role - because the role simply didn't exist on the team.

Leadership supported it: in early 2024 they offered me a chance to work on DX full-time. Importantly, it wasn't just a new task - it was a new direction that Skype didn't have before.

From April to December 2024, I was the only person working on DX full-time (and often evenings and weekends - because I genuinely enjoyed it).

Note: I'm not advocating for overtime - this was my choice because I was genuinely excited about the work.

I audited the current state, identified bottlenecks, and tackled them one by one. One early win: mobile Fast Refresh went from 60+ seconds down to 2-5 seconds - a 12-30x speedup that engineers kept referencing as a turning point. I rewrote the 700+ line onboarding guide, built environment health-check tooling, and reduced friction across day-to-day workflows. In practice, I was building a DX culture in the team from scratch.

I had big plans for 2025 and beyond. But, as you may know, Microsoft decided to shut down Skype...

Today, in my new team, I initiated and described a DX Champion role that takes only a small portion of my time. I hope to return to full-time DX work in the future.

DX-Ray started with a realization: I want to grow in DX and help the field expand

I started taking notes and collecting thoughts, links, and observations about DX - at first just for myself. That led me to launch a Telegram channel, expand to LinkedIn, write in-depth articles, and even experiment with video content on YouTube. Then the desire to make it all more structured and open.

DX-Ray is:

• an attempt to clearly explain what DX is and why it matters,
• a collection of practices, tools, and ideas,
• a space for discussion, not top-down broadcasting.

DX is evolving fast, and I'm learning alongside others who care about it. I want to grow in this field together with people who find it interesting too.

I want to gradually evolve and improve this project - adding new materials, tools, and ideas. And I'd be happy if you join me on this journey.

I care deeply about communities - not just content. Back in 2017, I created several professional spaces for people to ask questions, exchange ideas, and help each other without ego:

• A GameDev analytics community - 1000+ members
• A legal GameDev community - 4500+ members
• An internal analytics community at Yandex - ~800 members when I left

I am still moderating them (except the internal Yandex one) today. To me, that is part of Developer Experience too: knowing you are not alone when things break. I've seen many times how communities helped people find the right contacts, the right information, or at least a direction to explore.

DX-Ray will follow the same spirit - human-centered, open, and useful.

I am open to collaborations that help the DevEx field grow in real teams and real systems, for example:

• reviewing articles, books, and ideas,
• discussing real DX problems in teams,
• joint projects and experiments,
• interviews, podcasts, and just talking.

Long-term, I want to help grow DevEx as a global discipline, with a special focus on the U.S. ecosystem. I care about durable, real-world impact - tools, practices, and communities that outlast hype.

If you are working on something in this space and think we could do more together than separately, I would love to talk.

• artem-mukhin.com
• LinkedIn
• Telegram channel (RU)
• YouTube (RU)