Developer Experience Influenced by Open Source Culture

Transcript

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Kyle Carberry. Kyle is the co-founder and CTO of Coder. And well Kyle, I'll let you tell us the rest. Welcome. Thanks for taking the time to talk to us.

Introductions [01:07]

Kyle Carberry: Thank you so much for having me, Shane. Like Shane said, I am the CTO and co-founder of Coder. I'm primarily a programmer though, that's mostly what I do, which is apt for the name of the company. But yes, we've been doing Coder now for I guess six years. And prior to that I mostly toured around on the internet and that's kind of where I met my co-founders.

Shane Hastie: So tell us a little bit about the Coder story.

Kyle Carberry: We won't go extremely deep here. I started with programming, kind of tinkering with computers as a kid. I pirated an extreme amount of software. Post that era I played a lot of Call of Duty and that's where I was copying and pasting other people's code to have modded lobbies in Call of Duty. Post that era I got into Minecraft servers and we ran servers for a bunch of people and a bunch of my friends had Minecraft servers and that's where I met my co-founders.

So then we tinkered around and made a lot of random tools on the internet in that time. And that was for maybe five years, four years. And we eventually stumbled upon the idea of Coder, and I say stumbled upon the idea because we really, really loved software and we really wanted to start a company.

The primary problem that we had at the time was when we were running these Minecraft servers, we would constantly be uploading our JARs to these servers to run against. And it didn't make a lot of sense to us why we were building one place and running in another.

Coder's gone through a lot of iteration post that point, but that's kind of the absolute inception.

Shane Hastie: The reason we're talking is developer experience. There's a lot of, I don't want to say hype, there's a lot of awareness of the importance of developer experience today, probably more so than there has been for quite a long time. Why is that happening and what does a good developer experience give us?

Why the focus on developer experience [02:55]

Kyle Carberry: So we'll start with the why is it happening. I do think the launch stuff like Copilot is accelerating an extreme amount. It gave us surprising insight. And what I mean by that is GitHub Copilot specifically, like auto-complete with code. And I think it gave us a remarkable amount of insight into how much writing code is kind of nonsense language or almost entirely auto-completable where it's not really logic, it's almost like your brain's on autopilot when you're writing it.

I think for that reason, that really gave people a lot more insight into, for one, how much people can get done and then for two, how much better it actually makes our lives. And for me, I use Copilot every day and it's an amazing tool and it would be a lot harder for me to program without it.

The second part of really how it's changing our lives from my perspective is kind of eliminating a lot of the lazy work I'll call it, of software development, which is quite a profound time to live it. Me writing an application, I have more of the abstract idea of what I want to write and the rest I can fill in.

Removing the lazy-work part of coding [03:58]

The cool thing is you're kind of almost interfacing with this stuff in natural language now and you kind of have to know how to code a lot less. And so it's changing our lives. I think it's making a lot more people, programmers, and I think it's making a lot of junior programmers, senior programmers, and I think it's really cut out that time of someone going from absolutely learning how to program to being an expert at programming. I think that's maybe the biggest jump that we're seeing.

And that's kind of developer experience in a whole, from my perspective, not necessarily just Copilot. That's probably just the most gleaming example.

Shane Hastie: So what other aspects of what makes a good developer experience?

What makes a good developer experience? [04:36]

Kyle Carberry: I think everything that's not writing code is kind of garbage and it's kind of something that we could pile up and be like meetings everything else. The ideal situation I think for most organizations that are paying people to code is having people write code. And I think the majority of people at companies that go to write code really want to just write code.

And so the garbage as we'll call it, is maybe setting up your development environment or having to write some horrible config file that Copilot could automatically write for you or setting up your laptop for the first time when you start a job or something to that effect. I think anything that's a non-coding time that really disrupts flow is what's terrible. It's kind of like you're building a table and you have to run to Home Depot because you forgot a bunch of parts like five times. You start getting upset that you even started building a table. So a terrible analogy, but you know what I mean.

Shane Hastie: Where does this friction come from?

Kyle Carberry: I think the friction builds up over time. There's nothing like the feeling of starting a new project. And what really happens is, and I don't think it's any individual's fault necessarily, but complexity arises whether it's from some immediate need in the business, which is super reasonable and you take on debt for a very, very well understood reason, or someone's newer to writing code and they may not have predicted the pitfalls of something that would happen. And so I think complexity accrues over time and once you have a lot of complexity, it's really hard to undo.

Shane Hastie: A lot of our audience will be in that space of complexity. It's hard to undo, but what are some concrete steps you can take?

Kyle Carberry: That's a good question. I can only speak from experience. So a lot of the customers that we talked to, I'm going to be extremely biased, so I'm going to try to not make this a plug for Coder. Some people obviously reduce the complexity of their environment with something like Coder. That's maybe like a step.

I would say something we do inside of Coder to speak more of the cultural engineering practices that we have is really, really opinionated code, like exceptionally opinionated, kind of like a religion of sorts. And if someone writes terrible code, it just doesn't get it because it just doesn't kind of pass the bylaws. Or maybe it'll get in once or twice, but it won't like the third or the fourth time.

And I think how to set that culture really, really comes from the top. And so I think it's very difficult to enforce backwards, but I really think your senior most people have to be very, very intentional in the way that they write code and how they merge code in those practices. I would say that's probably what I've seen work the best for us, is just being exceptionally diligent in terms of culture and having a really strong reward cycle on when people do the really good pieces of code.

Shane Hastie: So let's dig into that. What does opinionated code really mean?

Writing opinionated code [07:18]

Kyle Carberry: I think for us, opinionated code, I'll give you an example of some of the principles that I personally embody. I believe a lot in a lot of verbose code. So writing server instead of SRV everywhere, I think the mental complexity and adding one step to decoding things is generally bad. I don't think it's always bad. I think inconsistency is bad. And so having server some places and SRV some places is a mental catastrophe. So you think they might be two separate things. You're not sure if they're the same.

And then I would say we have a really, really strong culture of, I was going to say testing code, but that's kind of like status quo. I would say that maybe more so comes from being really idiomatic in how we abstract. And so we try to just keep stuff very, very basic. We understand our software is not going to be used by millions of engineers at the same time because we're self-hosted. We understand and it's like, yes, 10, 20, 30,000 developers at most. And so we architect our stuff very much like that. It's all really simple. We have one container. We don't have a million microservices. We keep it really, really basic. So I would say those are some of our opinions that at least we have in our code base.

Shane Hastie: So that's opinionated code. What are the other things that you do to build a culture where well developer experience is great and that people can remove that friction?

Elements of great development culture [08:42]

Kyle Carberry: I would say we really, really work to remove roadblocks inside of Coder. And I know every organization does, but the roadblocks are sometimes really hard to remove.

So one way I think that you can do that, I think open sourcing stuff for example is a fantastic way to do that. If all the code is open, there's a lot less to be concerned about. Whether it's IP protection or your computer gets hacked and the source code's leaked, I don't really have to care about that stuff as much. That's a really big barrier for most organizations to just say that, "Oh yes, just open source," it doesn't make a lot of sense for most. But a lot of the companies that we talk to and that find something like Coder beneficial or any alternative solution that is remote development is really being able to remove a lot of things that remove the developer from flow that we were talking about.

One example of that is a lot of companies will have a VDI in front of a developer. So that means your desktop is in one place and you're in an absolute another place in the world. And that is a bad developer experience. I feel like I can almost say across the board, nobody is happy about having a VDI and using a computer in some other place. They might be happy about some benefits they get from that or the security team might be exceptionally happy about it. But when you press a key and it shows up 300 milliseconds later, it's really hard to get in flow.

So I would say those types of things culturally are what really, really impede typically from what I've seen. And those are the people who generally benefit a lot from kind of the vast unlock of developer experience.

And typically it's very bureaucratic I would say. You get a lot of pushback from security people and there's a lot of hands involved. It makes a lot of sense. But I think over the coming years we're going to see a pretty big unwind as people understand that a lot of the ROI set of businesses is from the creation of stuff that developers make.

Shane Hastie: Thinking about culture and employment, finding people that fit the culture, how do you do that?

Finding people who align with the culture [10:33]

Kyle Carberry: So for us, I feel like we have kind of a hack in the fact that we are open source. And so a lot of the times and a lot of the people we've hired are actually people who have found Coder, fallen in love with it, love our code base and really want to work at the company. And I think that's an excellent way to display it because something I always tell people, not everyone's supposed to work at Coder, even some of the most talented people in the world might not want to work at Coder, whether it's cultural or the company, they just don't like me. I don't know what it is. But the important thing is to attract the people that are both really talented and also fit you culturally. And I think an exceptional way to do that is to put your cards on the table and just show people what you got.

And I think it's beneficial across the board kind of for your whole company. Whether it's customers that see how we write code and our practices that we have in engineering or prospective employees. And I'm sure a lot of people opt out even when someone's like, "Maybe I would work at Coder," and then they go to our GitHub and maybe they don't like what they see and they're like, "I don't want to work there." And that's great. It's beneficial for both parties.

So I would say open source is probably the biggest tactic that we have. That's kind of the main. As I'm sure you can tell Shane, it's a big philosophy I have of keeping things out in the open.

Shane Hastie: So what if I'm in an organization that is struggling with the very idea of putting our IP out in an open environment?

The benefits of adopting an open source approach [11:53]

Kyle Carberry: So the question, say you want to attract dev talent that maybe cares a lot about developer experience and they're really productive engineers, yet open source is almost not an option. So in that instance, I would say a lot of things are open source that aren't directly code. Netflix comes to mind as they have an exceptional engineering org from my perspective, and they do a lot of blog posts and they do have a lot of open source that's very popular, but I primarily know them from their engineering blog posts that are quite exceptional.

And so I think that's another example of open sourcing something that's not necessarily code. It's kind of more open sourcing your engineering culture, which is to say, here's the way that we think and we're looking for people who also think in this manner. And so I would say if someone's really particular about their IP, let's say you have some crazy high-frequency trading bot. If anyone else knows about it, you're done for. Well, I'm sure there's some other components of that that you've learned a lot from, whether it's like an engineering culture or from coding it or something to the effect that you could use to find like-minded people.

So I would say just writing generally, putting your thoughts out in the open is a fantastic way to collect other people who have the thoughts similar to you.

Shane Hastie: I want to dig into the, but I can just tell an AI bot to write me an article.

Kyle Carberry: So you can, but I think exceptional writing is really, really hard. I don't think the AIs are there yet. They're getting there for sure. I think maybe in a year or two you can create a Kyle bot that'll probably produce better writings than Kyle himself. But for right now, I do think that original writing and original thought is still quite profound.

Shane Hastie: So you've had a journey from a tinkerer to a founder to growing an organization. Quite a few of our listeners are going to be in a position where they're starting to move or thinking about moving from the individual contributor role into maybe a team lead or some other leadership role, or they're already in that team lead role and they're looking to progress their career advancement. What advice would you give them from your experience?

The journey from tinkerer to founder [14:04]

Kyle Carberry: I think the people that I've seen become the most prominent leaders in the company are very rarely promoted to become the leaders first. I think typically they're seen as a leader and then they become one formally. So they follow this informal journey where the team obviously respects them to some exceptional degree and then they end up transferring into some leadership role. And actually typically not intentionally, in my experience with the best leaders. Typically, it's kind of like the business needs this, and if you're willing to step up to the plate, we would absolutely love to have you. And a lot of the time it's been met with resistance where people are, "I really like coding," or something to the effect. And I think that's where the best leaders are generally born.

I found it very infrequently the ability to hire a leader to start something is really hard. It's really hard to gauge someone's leadership abilities. And so if I had to give advice to anyone who is aiming to kind of obtain a leadership position, I would say just start doing some of the things, not acting like you're someone's boss, but being a leader is not being someone's boss. It's being able to lead someone somewhere. And leading someone somewhere is not deciding whether they're hired, fired or their salary. It's taking them on a journey.

Shane Hastie: What's that journey look like?

Kyle Carberry: I think it's being able to carve out an explicit path that someone can walk on with you and be really happy with the result they'd end on, and you as the person who guided them on such path. It's a very abstract definition, but I would say that's the best leaders that I've found give some direction and they're happy standing on that ground. And it's the leader's job to make sure that it's aligned with the business's interests so that the people walking on the path don't end up going to nowhere.

Shane Hastie: What is that overlap with technical leadership and business interest?

Kyle Carberry: Good question. They frequently don't align. I have examples in my head of people who are exceptionally talented technically, but don't really care as much about the business side. But I actually think most people that are exceptionally talented have a little bit of either. Maybe you're 80% business, 20% technical, but I do think there's a divide there that I'm 80% technical, but I spend 20% of my time thinking about the business and what's best for that.

For me at this point, they've merged into being one and the same. I very infrequently work on technology problems that aren't directly relational to improving my life or the company or something to that effect.

And so I would say if you want to move into a leadership position, you can't be 100% focused on technology. I shouldn't say you can't. I think it'll be much more difficult if you're focused 100% on technology. I think as an employee of a business, you always have the duty and responsibility to be looking out for the business. And even if you're a person at a tech company who is mostly in a business role, I think you really have to understand the technology to be successful in the business role as well. Just in parts though, never 100% either way I would say.

Shane Hastie: So you're a tech leader in a company whose target audience is technologists. What if the audience isn't the technologists? What if I'm in a bank?

Understand the business drivers [17:09]

Kyle Carberry: Let's say I worked in a bank right now and someone hired me to be in charge of money management, the app for it, or something to that effect. I think my first task would be going to the app store and downloading the money management app on my phone and starting to manage some money. And it would probably not be diving into the code base. Or even more distant from technology if I worked at a clothing company and I was working on the shop online for a clothing company, I would go order some of the clothes.

I think it's critically important that you understand what you're selling and who you're selling to be successful in your role regardless of what role you're in in a business. I think it would always be my number one priority to understand who's gaining the value and how are they, and I would try to become as close to the buyer as I possibly could be, even if I'm not them exactly.

Shane Hastie: Tell me more.

Kyle Carberry: Well, I think it's really difficult. I think you kind of give someone an insurmountable task when you ask them to work on something that they can't understand and they don't see the end product of. And so if someone told me to make an app for something or work on an app and they're like, "But you can't install the app and you can't use it," I would try my best to switch my team or switch my job. Because for one, I think it's hard to get fulfillment from that. But for two, I think it's really hard. You're playing life with hard mode on if you can't see the product, what you're making.

Shane Hastie: So build the empathy, stand in the shoes of your customer, whomever that customer might be.

Kyle Carberry: I would say so, yes.

Shane Hastie: Over time, I'm going to make the assertion you've probably done a lot of experiments in teamwork and culture. What are some of the things that have worked and maybe some that haven't worked?

Experiments in teamwork and culture [18:48]

Kyle Carberry: I classify a set of people in my life as problem predictors. And I would say predicting problems has very infrequently turned out well for me. And this holds especially true in engineering cultures.

What I mean by that and the specific mistakes we made is trying to force people, not force in a terrible way, but more so remote people to say being like, "You're a manager," or trying to really find things for people to do and for people to be productive on. And you're really trying to predict problems. And I've done this before in my life. I'm much more of an emergent order type of person where you see a problem. Typically, the fire's a lot smaller than people think it will be. And then you just put it out. And maybe you hire someone if the fire keeps reappearing and you keep stomping that fire out.

But I would say that's probably the biggest problem that I've repeatedly made it and I had to learn five different times in horrendous ways each time is to not try to predict problems but rather let them emerge. And the vast majority of the time people vastly overestimate how bad a problem emerging will be, it's typically like, "Whatever, maybe I spend 10 minutes a day on this horrible problem." But then we'll hire someone in three weeks and cumulatively I will have spent two and a half hours on it. So it's like, yes, who cares?

Shane Hastie: What does teamwork look like at Coder?

Kyle Carberry: So now we try to promote is very much so working on an open source project. The proposal process and everyone merging code and opening code, I would say is quite similar to just going to a random repository like Kubernetes or Git, maybe less Git because they don't use GitHub for issue tracking, but just opening an issue and opening a pull request.

As for the kind of camaraderie and how people self-reward each other in a culture, we have a reward system that we essentially use. The channel, it's called #thanks. You can give someone a taco. And a taco is essentially redeemable for $5. And anyone can give five tacos a day to whoever they want to. And so you could give a big taco bomb, you can give five tacos all at once to someone if they really helped you out, or you could give one taco to five people.

And I would say this has been a really exceptional hack in our culture, just more broadly in the company. It's very visible to everyone, how people appreciate each other, what people are thankful for that someone else helps someone for. If someone gives tacos for some nonsensical reason, I'll mentally note it and it keeps a really good pulse on the culture, kind of like from a leadership perspective and also just for individuals. It's amazing to do something awesome. Or just this morning someone hopped on a customer call. A bunch of us did actually, and I gave them all tacos and I was like, "That was amazing that everyone hopped on." And it's just a nice little reward cycle. Plus, you get two or three tacos a day, you get your lunch paid for, that's also sick.

So I would say enforcing a non-leadership led engineering culture is critically important that everyone's able to obtain a lot of dopamine from themselves and not need a pat on the back from the manager. They should get expectations maybe from their manager, but as per the reward cycle and you want everyone high-fiving and everyone really happy with the work that everyone else is doing.

Shane Hastie: Kyle, a whole lot of interesting ideas in here. If people want to continue the conversation, where do they find you?

Kyle Carberry: A couple of ways. One at kylecarbs on GitHub. So you can always open an issue if you use Coder. You can also tweet at me @kylecarbs, or if you want to, you can just shoot me an email.

Shane Hastie: Kyle, thanks very much for taking the time to talk to us today.

Kyle Carberry: Thanks for having me, Shane.