DevXPod

Growing developer experience: from 10 to 100 developers with Anton Drukh

• Chris & Pauline • Season 2 • Episode 1

Share episode

Welcome back to Season 2 of DevX Pod!

We're your hosts (Christian Weichel and Pauline Narvas) for this season. 👋

In today's episode, we're joined by Anton Drukh, Tech Executive Mentor and former  VP Engineering and GM Israel at Snyk where we talk about how to grow developer experience as organisations naturally go through changes. 


The hosts  â–»

Our guest  â–»

Things mentioned â–»

Let's chat some more! â–»

Anton:

I remember a few ah-ha moments so to speak when it dawned on me that a rugged experience that could have been construed as this is what development is about the learning curve needs to be very tough because you need to earn it was actually replaced with developers are people they have attention span problems They have the needs to focus the combination of caring for the success of the team And also caring for the success of the product was actually very enlightening in how it allowed me to connect the two things into the concept of developer experience

Chris:

Welcome You're listening to the DevX podcast The show where product and engineering leaders share their thoughts and insights on developer experience I'm Christian Weichel joined by my cohost Pauline Narvas

Pauline:

Hi Anton Thank you so much for joining us for today's DevX podcast episode We're really excited to have you

Anton:

Thank you very much It's a pleasure to be here

Pauline:

Yeah we're super excited to learn more about your story and a bit about your journey into developer experience So just to kick us off then could you tell us a bit about yourself for those who aren't familiar with you or your work

Anton:

Of course my name is Anton and for the past year I've been a self-employed as a tech executive man there was a recent tweet asking people to describe their job in the poor way And I had a nice take on it They said that what I do is basically tell people about what I did wrong so that they can do things wrong in their own way but around engineering leadership specifically and the majority of the experience I bring into this mentorship role I have actually gotten from I joined Synk in the beginning of 2016 as the first employee in our Tel Aviv office in the role of VP engineering And I had the most amazing incredible professional experience growing and scaling with the company to about 650 people out of whom 125 plus were on the engineering side by the time that I departed into this new chapter of mine

Chris:

Anton and I we've been having conversations around engineering leadership for almost the past year at this point And the advice and the conversations that we've had have been absolutely invaluable in growing Gitpod and Helped us do fewer things wrong and be a sounding board correct The things where we were going off path it's been absolutely great

Anton:

Thank you very much Chris It's like if you replace code with people then you replace the process of code review with plans review and then just speaking out what you plan on doing and hearing what other people think about it is very insightful

Chris:

on the note of code reviews diving right into things This is DevX pod right We're all about developing experience How would you define developer experience

Anton:

It's a very good question and I'm thinking about it from the perspective of time as an engineer you take pride in your craft and you want to use the right tools and not just to enjoy the end result but also the process of what you're building But it was actually the role at Snyk where everything converged as I was evolving my expectation of what processes and tools do I think would be right for our team But at the same time looking at it from the outside by basically saying Synk's a dev tooling company we are building tools and solutions for developers And we want them to be easily adopted And I remember if you ah-ha moments so to speak when it dawned on me that what used to be the sort of like command line interface you need to remember the flags of everything You type a rugged experience that could have been construed as this is what development is about You need to know the thing and the learning curve needs to be very tough because you need to earn it was actually replaced with developers are people they have attention span problems They have the needs to focus They have the needs to be efficient with how they use their time We will not be taking away their professional pride If We tied it up some pixels on the screen right Like let's make the tools easy to use And especially in this consumery approach of we want millions of people to be able to connect to what we're offering and say Hey this solves a problem for me You really need to think about the experience that you are providing And it happens to be developer experience because your audience is developers So the combination of caring for the success of the team And also caring for the success of the product was actually very enlightening in how it allowed me to connect the two things into the concept of developer experience

Pauline:

that's amazing because I think in other episodes I've said this before but I'm learning a lot about developer experience and all the different things that go on in this space And I think one of the things that when you think of dev X you think of tools you think of the technology and sometimes you forget about that people aspect So I really appreciate that you brought that up and also recognize that we're all human and complex and there's a lot more to a developer experience than just the tech that they use

Chris:

You're at that interesting sweet spot where on one hand Synk as had the target audience that is developers and you have developers yourself where you need to build the tools and you built the tools for something that is very close to who you are yourself And so very quickly people get into this chart where they go where developers we understand ourselves we can build for our own experience Have you found this to be working out Are developers good at building developer tools

Anton:

That's an interesting question I think that it can be a double-edged sword because you don't want to go all in on this You're just one person You are a team of just a handful of individuals Don't Expect your understanding of reality to apply everywhere there is a lot of humility that you learn by trying out your ideas and putting them out there and see how people react But if that's one edge of the scale which is overdoing it you also must not go to the other edge which is under doing And I remember talking about it a lot with candidates we were interviewing telling them about what we expect what success looks like on our team And I was constantly emphasizing the product mindset that we as engineers need to apply and to not to outsource product decision-making to the product managers who have a very specific and important role in this To eventually not to tie our hands behind our back and say I just write code tell me what problem I need to solve And they'll figure out a solution for it This would be the under doing of developer oriented product building And the sweet spot in the middle is holding the stick by both ends Thinking about the end user and finding ways to relate to the problem being solved being opinionated about the problem being solved asking questions about why is this the right problem Being able to say I can convince others of the importance of my work So this is a good starting point but at the same time not overdoing it and not going all the way this is how I would like to consume this API endpoint or the CLI flag So I'm just going to build it this way because my opinion is the only opinion that matters

Chris:

Yeah it's a great point It's the product mindset in developers where it's easier to have a starting point because you understand where people are coming from your their persona yourself and at the same time being humble enough to understand that Your opinion is just one opinion There are other and many other ways of doing this and then putting things to the test and really embracing the fact when things don't work out as you had originally designed them because you understand that there are other ways of doing things product mindset and developers is just so important

Anton:

Maybe this is also a sort of a paraphrasing of the transition I made because prior to Synk I was an engineering leader mostly at the B2B companies where you work with companies that say what they want and we'll pay you money for this specific set of features and shifting to this more of a consumer in mind You need to call the shots and do you need to stand behind the decisions the product decisions that you make and no single user will tell you whether you did right or wrong so it's like herding the audience together

Chris:

Yeah This is an interesting challenge to try and gain signal especially from developers as an audience while we are often on the opinionated end of things And then trying to reign in and giving weight to individual opinions but also seeing patterns emerge and builds for those patterns rather than who speaks the loudest

Anton:

what you just said is a very good definition of a product mindset for engineers I think it was amazing for our team to seize the opportunity and define ourselves as a dev tooling company to grow this business But I really believe that you don't have to see yourself as a dev tooling company in order to do so stepping into the shoes of your users whoever they may be is a very eye-opening and humbling experience for an engineer

Chris:

Focusing view more inwards into the organization itself You started out with what was essentially 10 engineers if I'm not mistaken how did the experience of those engineers look like in those days

Anton:

So I often recount the major milestones in the growth of our organization at Synk when I talk to my clients today and try to draw specific examples from my experience to what they're going through And the mark of 10 engineers on the team is a really important one We grew from just basically me and the handful of people to the number of 10 engineers and had to make a very important decision that had to do with our organizational structure Now I want to dive into all this how to structure your teams and what is the role of engineering manager Which can I think accommodate several podcasts episodes but they will say that in order to guarantee the success of people stepping into part of the role that I used to hold as the only engineering manager of up to 10 people the need to think in patterns becomes important You suddenly need to be more explicit about all these gut feelings that were driving your decision-making and help people see the why behind what you were doing let them implement their own method of reaching the right goals but to be more explicit about the goals of what a successful team looks like And one very important aspect is How easy it is for the team to do the right thing It sounds very simple We all want to do the right things and we want them to be easy to do But if you look at the pain points and the friction your team is now experiencing whether it's flaky tests difficulty to deploy things to production not knowing what the impact of a change would be difficulty troubleshooting customer issues Difficulties handling with technical debt and code that is not fit for purpose today You can usually trace it the origin of the problem to a point in time where the right thing to do was not easy enough to be done And something went sideways developer experience is a good title for me To put emphasis on are we as a team investing enough in making the right things for us be easy and it takes two distinct decisions The definition of right is very subjective What is right for one team may just as well be very wrong for another So coming together as a team and spending time deciding what is right for us how should we deliver code how should we maintain quality How should we manage expectations about what is it that we're asked to do so that once we deliver it people are happy and they don't say what does this have to do with what we agreed on that would be more of a fundamental decision not to be changed every week on what is right And then the execution mode is all about identifying The parts where the right thing to do wasn't easy and saying okay what can we change tomorrow next week next sprint to make it easier Let's invest in this The ease of doing the right things is important to us and that's a wider umbrella for what I would call a developer experience that the team creates for itself

Pauline:

Yeah absolutely And that was yeah that was really insightful When I was listening to you I was imagining all of the teams that I've been in before joining get pods and how I started in small teams and then it grew into bigger ones and we started to lose touch in terms of the importance of developer experience so it was really interesting just listening to your point of view I have a follow-up question which is around when did you first notice that you needed to evolve your developer experience and at what size was the team at that

Anton:

So after this initial split of 10 engineers into two teams we adopted a model We called it the amoeba model I hope I'm pronouncing the word correctly where you have this very basic like biological organism that splits itself as it grows And by the time we were at 20 we were already four teams where every team became two teams which is a very good scaling practice What changed along the way was basically a long set of very small decisions we have made that made sense at the time And we tried to do Make sure that they fit for as long as we can like stretching last season's clothes even though your body's is growing And I have a few colorful examples that that come to mind about some choices that we've made while splitting into product oriented teams with very distinct output outcomes and product roadmap The code ownership was very tightly knit We did not want to build fences and to assign like this code can only be changed by this team So everyone would basically have impact across the entire code We decided to structure our services We had the microservices architecture So we decided to set that event in a multi report poly-repo I heard two terms for this which is the opposite of a monorepo set up which made this duplication either Okay Hey let's just create another service It will be stand alone It's CI processes are self-contained It's our ability to deploy small changes to it is self-contained and what works great for three repos for three services doesn't work as great for 30 And here's my first example So there was a very experienced team member on the team who was grappling with a difficult task I don't remember whether it was a feature or a bug but it doesn't really matter And it took that person several days to figure it out the change required Adjustments in three different microservices So that person created over necessary changes tested them everything checks out And then they come to me and say Hey I want to share a learning from this experience it was quite messy for me to align all these three microservices locally online So I could run them and test them and develop them And I think it would be easier for all of us to deal with such challenges in the future If we use Docker compose the abilities to spin up all of our microservices on our Mac so that Everything that needs to be changed is already within reach And this is an amazing iniative too because the person thinks on behalf of the team this is a great example of developer experience They care about how easy would it be to do the right thing Okay But here's the thing I was very glad to have this conversation with them in a one-to-one setting because I had a very strong opinion against this suggestion Of course it made something very easy But once this thumb something the right thing And my counter statement to the suggestion was but why would it be right for us to make it easier to create changes across three different microservices At the same time if I'm thinking about the deployment process our system doesn't allow us to coordinate the deployment of more than one service at a time So if you're pushing three different changes to the system at the same time there will be a period of time where the system will be unstable Some instances of service a will expect something from service B but it won't still be there This is not how we want to roll out changes I would rather agree that the right thing is to be able to make very contained distinct changes to the system One micro service at the time Respecting backwards compatibility and all of that And let's make that thing easier The bottom line of my argument is that we should absolutely not use Docker compose because it will make it easier for people to run themselves into difficult corners by creating changes that will be difficult to deploy safely So here's an example of the combination of yes there are many things that can be easier but only few of them are Right So let's make sure that we focused on the right thing Another example I can provide has to do with what I call sometimes the unneeded innovation When you're after this shiny new thing and do you want to adopt it and do you want to get your hands dirty with it and you hold the hammer in your head and you're desperate for nails there have to be nails around you because you now have a hammer and you want to use it so my antidote to this sometimes misguided intent is to be very critical about what is it that we choose to build as opposed to the needs to focus to know that you have only a handful of problems that you can deeply own and that owning a problem takes time and effort and mental energy very often it is much simpler and more cost efficient to the business to basically let someone else do it for you Another example would be an elk stack You would want it to use for your logs to be centralized and searchable And then you face the challenge of do you want to run it yourself or do you want to buy this as a managed service Now if you have elastic search competence and the expertise on the team as part of what is critical to your product by all means run a small setup of an elk just for your logging needs But if that won't help your product move forward then do not step on this slippery slope where within two months you find yourself with two people doing nothing but making sure that your homegrown elk cluster is fit for purpose And you ask yourself how did we end up here So the bottom line of that is to prefer buying instead of building

Chris:

It strikes me that as teams grow the focus of what developer experience means shifts it shifts from the individual to the team It shifts from how do I make my life easier to how do I make it easier for the team as a whole to do the right thing And it shifts from Hey I'm just that one person I can go and build this real quick Also as developers every so often we tend to under estimate how long something is going to take and consequently undervalue our own time And this just multiplies as the team grows because all of a sudden it's not just one person who is roped into doing something but an entire team And so being very careful about what do we want to achieve being deliberate about how do we achieve this Do we build this Do we need to make that right thing the easy thing or can we buy that in Can we get someone else to do that for us so that we can go back and focus on what we actually want to build And yet don't need to forego the convenience that such a thing

Anton:

Absolutely And you mentioned sizes of teams I think one one key learning from scaling an organization beyond the a hundred people is that what may seem as this continuous gradual growth and new person comes on board and another you go from two to 20 to 60 Is actually slightly more distinct than it may seem and that would equate it to the analogy I use if you are familiar with physics is that in an atom the electrons that rotate around the center of the atom move between energy levels they don't just have any possible orbit to there are several orbits several specific distances from the core of the atom And thinking about organizations they think something similar applies At Synk we opted into smaller team sizes So a team would be an engineering manager product manager and something between three and four maybe five engineers And when the team was hiring it's fifth or maybe sixth Engineer they would at the same time have a plan to split themselves up as a team into two smaller teams that can continue growing We never wanted to have teams that could slow themselves down by being too large but the organization grows and you need to put teams together and give them a greater purpose in those So delegate their purpose and provide them with the right sense of autonomy so a group of teams had led by a director of engineering would be between two and maybe four teams Okay So 10, 15 to 25 people And as we grew I was constantly thinking about the processes the ceremonies that we observed The sort of this unspoken need for consensus to make technical decisions How wide should I go There was a time when one team wanted to introduce a new tool into the CI process we were using semantic release and sometimes we would miss the commit message So a release would not happen and we thought it would So the team wanted to introduce a tool that would prevent those kinds of oversights And they brought it out upon an engineering weekly meeting with 50 more people saying Hey here's what we felt about Does everyone think it's a good idea and an awkward silence instills Because I just want out to 55 people does my opinion really matter Okay it's difficult to speak up in such a setting but the team proposing this are looking for support They don't want Innovate for the sake of innovation and run ahead leaving the entire organization behind them What we ended up settling on was small team sizes of five people or five people or less to make these cohesive day-to-day decisions of how do we capture value How do we deliver value What is the right cost efficient approach should if this feature would take a week to develop but with deliver this much Is it worth our time a group of about 20 to 25 people would be able to have wider discussions incident reviews learning from problems that have occurred making longer term technical decisions choosing their own tools whether it's Choice of CGI How do we deploy let's deviate from this multi repo set up that we had a group would be autonomous enough to make such a decision for itself And my personal experience in this was what is commonly known after a very interesting article on this topic is that it was constantly giving out the decisions I used to be very involved in and saying Hey let me take care of you let's not have a managed elk a self hosted DLK let's choose managed instead Let's not go for Docker compose it will make the wrong thing easy for us suddenly it was very important for me not to make these decisions but to actually say let's stop I can help you maybe Talk me through what you think is right And how do you want to make the right things easier And I'll share my opinions but I it is not my place to tell you what is right And to impose it on you as a director of engineering responsible for the success of their group or an engineering manager responsible for the success of their team

Chris:

When the organization grows and you go through these different energy levels these different stages of growth And at every step you have to pull yourself back and go Hey this is not my decision to make anymore I will delegate this I will help you make that decision You know I'm not just going to leave you in the woods and all by yourself but I'm going to help you One of the questions becomes where does that decision land Is this the responsibility of an individual team or is this spread across multiple teams within some organizational unit for development experience specifically did you end up with teams that were dedicated to greasing the wheels to making the lives of developers and other teams easier Or was this distributed across all teams where they would need to go and figure out what works for them Because it might not work for someone

Anton:

So as I'm in the beginning of this conversation I introduced myself as a person who tells others what they've done wrong across the across the years And this is one such example My professional background is basically in operations and I really enjoyed the ability to support the entire team as it grew by keeping my hands dirty but never Standing between the team and its ability to deliver user value And of course it started to basically flatten out at I don't know about 20 or 30 people where the foundations I have created were still helpful but I did not have time to invest more in them And the team began feeling limited by what was offered in the beginning And it was at that point in time where I set out to basically build a new team in our engineering organization we called it the platform team our choice of terminology was that DevOps is not a role DevOps is a culture way of doing things on a wider engineering team So what I sometimes hear referred to as DevOps engineers we decided to use the SRE title And I remember interviewing candidates for that role And they would say well we have very self-sufficient product engineering teams that have a lot of ops competence and they run their own on call rotation but we need someone to come in and show us better ways of doing things And people would say oh wait you're not like looking at Put me into the dumpster fire of a very painful on-call rotation that the engineers want to hand off to someone else everyone has their own scars and my scar speaking of which was that despite all this great intent it was quite difficult for me to set out to this team and set it up for success I hired very talented individuals that that was offering and what we were offering as a team but they made it quite difficult for them to succeed by not infusing the platform team with enough knowledge of the day to day or of the product engineers but by bringing in professionals with proven experience and things that we did not use before and basically telling them Look around you see what people are dealing with and help the right things for them be easier and that led to a disconnect because what I was too hopeful in in how the need of the product engineers as users of this platform team would connect would be Would it be owned by the platform team And what actually happened was something that we invested a lot of effort into making sure that it would never happen on the product engineering teams where the team would basically we veer off away from what its users actually wanted And you become more obsessed with what is it that you're building And the solution you decided on rather than so what does the problem look like now when with the solution in play did the problem take a hit right Was it is it smaller now for those facing the problem on a daily basis and that was a disconnect my way of solving this was to hire a very experienced director of engineering in this specific domain And I remember conversations that again struck me like lightning because that person came on board and said so every other director of engineers Has a counterpart director of product What about the platform group And they said wow this is exactly what was making missing and I made the mistake of assuming that product management is only needed to represent external users within the company but product management is important to make sure The things that you build are solving the right problems whether those problems are very close to you physically or belong to the users of your company's building

Chris:

I just found myself nodding to a point where my neck hurts We were just now undergoing a various similar transformation where a platform team that had so many things on their plate So many things that for one they could focus on specific areas and would not be able to cover others that also needed attention So we just saw an overload of that team It became a bit of a kitchen sink everything that that the product team stoned one two cannot do ends up in this platform team And so now we're refocusing Into a sort of developer productivity developer experience team And one thing that we're realizing is the PM role that we had until now we treated as a all our teams have an EMP so we got to have someone in that role but we didn't really see the need that you need actual proper product management in that and this development experience or whatever we're going to call that team we'll grow that PM role to for that reasonable Otherwise you very quickly end up with also separated incentives as a platform team as a development productivity team You're not necessarily feeling that pain It's only by someone telling you And so your incentive it's much easier to walk in a direction of I got this hammer Let's look for nails rather than really solving the pain You're not feeling it yourself after all

Anton:

Indeed very much so

Chris:

You already hinted that one of the biggest changes you made was introducing that senior engineering director and product management towards the platform Can you speak a bit more about what levels with regards to development experience and the day-to-day life of developers you found that really made a difference that had an outsized impact on the value created by the teams

Anton:

there are two things in play that are worth looking at objectively and trying to quantify One is how easy is it for the team to come up with an idea that will be valuable for its users that would advance it along its product roadmap and then start pushing out bits of this idea out to users the best metric there would be in the shape of cycle time We didn't automate it as much And today there are plenty of tools that would make it much much easier to basically measure this important metric But I remember myself skimming through I had this separate browser window full of tabs And each tab was basically with the pull requests page on a very busy repository And several times a week I would just refresh those tabs and look at the amount of pull requests open for every repo And not scientifically try to gauge how many of them are fresh and how many of them are still right Like the last pages And yes we had pages of of pull requests And I would not show people I would say Hey folks like we had very clear ownership Every repository had a team owning it It wasn't the only team making changes to that code base but it was the team approving all the pull requests and shepherding this this repo towards its its future And I would say folks I think the pull requests here are getting a bit a dusty And it's not like we decided to focus on the median or the 95th percentile of the like the age of of the poor request but that's something that was useful And another metric again from this first part of making it easy to make incremental changes to your product had to do with I would say Chunk size how many changes are being pushed to production with every deployment So we ran a relatively smooth CICT process with every service being capable of being deployed all the time with tens of deployments per day for different services in our system But sometimes you would notice that you had five consecutive deployments of two commits each and then suddenly a deployment comes through with 45 commits in it Those are not the same and you need to keep an eye on it and say okay what in our process made so many commits go to production at once how can we make the right thing which is smaller chunks more frequently How can we make it easier The other side has to do with the operational ownership And this is something that I advocate in favor of very strongly to make sure that teams follow the you build it you run it motto and say if we're the ones pushing it to production we're the ones confirming that it does what it said on the tin and it doesn't have side effects And if something goes wrong PagerDuty wakes us up and not someone else who is responsible for the operational aspects and owning it on the teams also allows to create objective measures of what operational excellence looks like it overlaps highly with the definitions of quality And what I like most about them is that if the team Owns these aspects then the team would choose to measure what the team has control over I would often talk to clients struggling with how they want to manage and improve quality And they say so what is quality for you what would go good quality look like And then it was they would say something like I would want if I had a button to push that would make the number of critical regressions go down to zero I will do that And this is okay Sounds nice No one wants critical regressions right But it begs two questions who decides that a certain bug is a regression and who decides of the criticality of this bug Because if you introduce this subjective measure into it you may be Leading yourself to a situation where people would use it as a buffer and say I know like I'm writing the best code that I think I can write And yes of course we are used code reviews And I learned that improve with the feedback that I get but critical regressions in production I don't know It's it's hard for me to say what exactly did I do that contributed to And improvement even in this metric that we have as a team So instead my learning from this and the metrics I advocate for are more around the definition of uptime of a service And it doesn't really matter if it's a synthetic way to measure uptime or something that is very user centric And another metric that we use to call success ratio where we basically identify the most atomic interactions A service would have usually API calls and say how many failed responses can we sustain for every thousand of requests And if the number is one then you're basically aiming for a success ratio of 99.9% And what's really helps it Coming back to developer experience is being very thoughtful with how you treat HTTP status codes in your Do not brush it under the rug by saying go it doesn't matter Like we we all saw that service that says HTTP 200 but the payload is ever true so don't do that and keep a high bar on what does HTTP 200 400 and 500 mean for all of your services and then the success metric success ratio metric Basically presents itself and allows the team to say okay we're in a good place We are qualities is good And we stand behind these numbers it's our code It's our service we know that the quality is good enough Someone else I think the PR topic and making changes go through code review And making that a good experience all around I E reducing waiting time enabling people to feel a sense of agency over what's happening in that process Probably once an episode on its own You mentioned a key thing here is when it comes to gauging the experience developers are having you really have the qualitative and the quantitative approach You can measure things like P 95 cycle time but that doesn't necessarily tell you If people feel like they can get the changes through or if they're walking into a wall of some sort every time they raise a PR And at the same time if you just an air quotes use questionnaires those have a very low sample rate You can only do them every so often So a combination of the two is something that you'll want to use to gauge what experience are my developers having within the team with their reviews with their ability to get training Yes I agree I think a combination of being very objective towards the artifacts of your work the uptime of your services the sizes of the batch sizes of what you put to push to production can provide a very constant stream of information Like over the past three days this is the average the median the P 95 vetch size that went out to product In our code base but by itself it will be very accurate and very difficult to reason about and will completely disregard what people are feeling about these numbers And you absolutely have to have some qualitative measure that addresses the team and they can point out two sources which I find very relevant One is a post by the Spotify engineering team dating back to 2014 called the squad health check model which offers a questionnaire you should run on your team or your squad every few weeks or months to measure very important qualitative aspects of team health And the other is a more recent a continuation for the Dora metrics that became popular a while back an article published by Dr Nicole Forsgren and others in March of 2021 called the engineering space metrics They are a great read and really complimented this view of measuring something very objective By saying there are people in the mix We need people to be happy because if we have 99.9% up time but the team is constantly rotating team members and people get burnt out by the difficulty of our on-call rotation Then that's a very expensive three nines of uptime Do you want to check

Pauline:

just listening to you reminded me of a team I was in it was also like a central platform team and it reminded me of this one time I raised a PR and it took Two to three months to get it out the door And I remember seeing all the conflicts every single week and having to fix it and then trying to tell my team Can someone look at this and can we get it out into production because it's just laying around And I fought I started to feel bad because I was like why is this not getting into production Why is it being ignored And it really does link to developer happiness And I could keep raising these PRS but if they're constantly ignored by the team and not prioritized it's yeah it doesn't feel great pages of PRs woah like gives me a little bit of anxiety Well Anton I feel like we can talk for hours about this There's so much Maybe we can have you on for another episode but honestly thank you so much for all of the information that you've shared on this podcast for those listening there's so many cool recommendations that you shared we will put them in the show notes for you to explore and read on and Anton where can people find you if they Want to get in touch with you directly

Anton:

The best place to find me is on Twitter My handle is ADR U K H I write a bit about things we spoke of and the occasional meme so yes please get in touch and thank you very much for having me It's been an absolute pleasure

Pauline:

Thank you so much Anton

Chris:

Much appreciated to have you on the show

Pauline:

Thank you for listening to this episode of DevXPod Want to continue the conversation about developer experience head over to our community discord server at gitpod.io/chat We have a dedicated channel there for us to talk all about DevX to make sure you don't miss the next episode follow us on your favorite podcast platform or subscribe to our newsletter DevX Digest

Chris:

you can also find out more about Gitpod on gitpod.io Start any workspace and tell us about your developer experience See you in the next episode

People on this episode

Head Shot

Christian Weichel

Host
Head Shot

Pauline Narvas

Co-host