Artem Mukhin is an expert in Developer Experience (DX), a concept that helps developers eliminate routine tasks and work more productively. Artem has been engaged in this throughout his entire career – long before he even heard the term “DX.” He has created successful tools for his colleagues at Yandex and Microsoft, saving teams weeks of work and making the development process far more comfortable and efficient. Artem shared his approaches and his vision of the future of DX.
Artem, tell us how your path in development began. What initially drew you to building interfaces and internal tools?
Actually, my path into development was quite winding. I studied economics – more precisely, I initially enrolled as a programming student, but there was very little programming at my university, so I switched to “Finance and Credit.” After finishing my fourth year, I went to work as a designer at an advertising firm, making banners and flyers. I did that for some time but realized that creative professions weren’t for me. I have more of an analytical mindset, so I decided to try my hand at analytics.
I joined a company that specialized in marketing research. Before me, they had an analyst who was fine with clicking “save” in Excel and waiting an hour while the file processed – he would just go smoke during that time. I decided to learn SQL and move the data into a database. The process was reduced to a minute. But even that wasn’t enough, because PowerPoint presentations still had to be assembled manually. I started learning VBA, the programming language built into Microsoft Office, and automated the entire process. Tasks that previously took a month I could complete in four days. I spent the rest of my time learning and taking courses. In the end, they simply didn’t have enough work to fully keep me busy – so I was let go.
After that, I joined Yandex in a group of media planners and analysts, again working on automation. Previously, media plans were created manually in Excel, taking half a day. After automation, it took just a few minutes. I began studying databases and building interfaces. Eventually, I turned one of the Excel tools into a full-fledged web application.
It was designed for clients planning ad campaigns, helping them calculate how many impressions they’d get for a specific budget. The new tool delivered results in one minute, compared to at least a full day previously. We significantly sped up the process and reduced the team’s workload by about 30%. That interface was later opened up to external users – still using the same UI that I had originally designed.
Later, I moved to a new division that built internal tools, including for analysts. I sought out this team myself and asked to join. At first, they refused, saying I lacked experience. But I returned a year later, and they took me in. In just two and a half months, I launched two projects from scratch: gathering requirements, designing, and working through the UX.
My design background helped me a lot. Combined with programming skills and logical thinking, it naturally led me to DX.
Throughout my career, I’ve always aimed to simplify life for myself and my colleagues. I’ve always preferred optimizing and automating processes over tedious, repetitive work. I can’t stand inefficiency: if a task takes 30 minutes but can be done in one, I’ll do everything I can to make that happen.
So you started with interfaces for analysts and media planners, then moved on to internal tools for developers. How does the approach to DX differ across these groups of users?
Managers, analysts, and media planners often perform tasks “head-on.” Since their technical level is lower, it’s easier to identify the improvements they need. Developers also have people who automate and optimize, but there are fewer of them, and not enough resources are usually allocated to this.
For me, the similarities are more striking: everyone gets used to working “the way things are.” Media planners or analysts have their tools, but they won’t change anything unless some developer happens to come along and improve their lives.
Meanwhile, most developers are used to the fact that it’s hard to secure resources for optimization tasks. As a result, something might take two hours instead of ten minutes, but everyone just lives with it. I want to highlight these cases and show that many “normal” pain points can actually be eliminated.
Tell us how you started working on DX at Skype – as I recall, you originally joined for other tasks?
Yes, I joined as a frontend developer. My first team was responsible for the payment interface. But right from day one, certain things annoyed me – for example, onboarding difficulties, which are crucial. Either everything is automated, and you integrate quickly into work, or you waste two weeks setting up your environment.
While working on frontend tasks, I kept noting down everything that was slow or inconvenient. I ended up with a list several pages long – 20 to 30 items. I first showed it to my manager, then to the head of development, discussing it with many people. Eventually, they offered me a full-time focus on Developer Experience. Initially, I didn’t really expect this to become a full-time role, but I had hoped.
DX projects often live “between” teams. How do you manage to find support for your initiatives and build trust with managers and developers?
I’ve always paved the way myself. If my initiatives don’t get resources, I use my free time. If something personally bothers me – something slow or inconvenient – I don’t waste time asking for allocated hours to fix it. I just build an MVP and show it: “Guys, here’s a working solution that fixes the problem. Let’s adopt it.”
I also pay attention to chat messages to learn about colleagues’ issues, gather feedback from managers, and ask questions myself. I’ve always enjoyed such tasks – they help me grow. If I had to do the same thing for years, I would have died of boredom long ago.
What aspects of DX are most often underestimated by developers or tech leads at the start of a project? Are there architectural or infrastructure choices you try to lay down from the beginning?
Hardly anyone thinks about DX at the start. Early on, everything seems fine: the technology is fresh, the libraries are new. The real problems appear in projects that live for years. Technical debt builds up, and what was once ignored eventually has to be cleaned up.
At the start, my advice is: don’t reinvent the wheel – use standard approaches. Eventually, you’ll leave, and new developers will have to untangle your custom library. That really slows things down.
It’s also important to keep projects up to date: regularly update libraries. If you postpone this for too long, you’ll run into compatibility issues between old and new versions. You update one library, and suddenly you’ve pulled on a whole knot of dependencies that are no longer maintained. That turns into a massive problem.
What do you see as the future of DX – and what is missing today?
What bothers me is that Developer Experience is about developers, but it’s often driven by managers, SEOs, or CTOs. They write articles and create frameworks. As a result, DX improvements are usually handed from the top down. My case is more of an exception. I’d like to see more bottom-up examples.
I want to show by example that DX works. You can take it to leadership and prove that these improvements benefit the company. There are fewer managers than developers, and even fewer actively promoting DX. It’s important for managers and developers to meet each other halfway.
DX won’t become as popular as UX or DevOps until developers themselves get involved in spreading it. Once more people start sharing real results, that’s when mass adoption will begin.
I want to be on the developers’ side. That’s why I make explainer videos with memes – because while reports and frameworks are useful, very few people will actually watch and share them. For popularization, we need a different approach.
For example, at Microsoft we’re currently discussing the role of a DX Champion. A champion is a dedicated expert in DX that the whole team can turn to with questions. We’re discussing what responsibilities and KPIs such a role should include.
What would happen if a large number of developers started focusing on DX? What would developers themselves gain?
DX is about improving developers’ lives. It cuts out the unpleasant, repetitive tasks everyone has grown used to. The more developers see that DX delivers real results – speeding up work, saving the company money – the faster it will spread.
Developers would be less tired. Instead of context switching every 15 minutes and waiting 10 minutes for systems to respond, they’d be able to calmly complete a two-hour task in half an hour. Constant switching and repetitive tasks are exhausting.
Also, automation accelerates personal growth. Developers free up time for more complex tasks and learning new things. Sure, you can manually build an Excel table – but you can also automate it with a formula and spend the next day learning a more advanced tool. Motivation comes from interesting challenges, not monotonous ones.
