Platforms, People and Process for Great Developer Experience

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I have a fascinating and fun experience. I'm sitting down with Daniel Bryant. Now, Daniel is the News Manager at InfoQ. He's been track host at innumerable QCon conferences, and is, and here is my bias, an all around great guy. Daniel, welcome. Thanks for taking the time to talk to us.

Daniel Bryant: Thank you very much, Shane. It's interesting to be on the other side and I very much appreciate that humbling introduction. Thank you.

Shane Hastie: I'm going to go with how I normally open up. So who's Daniel? Tell us your background, what brought you to where you are today?

Introductions [00:48]

Daniel Bryant: Yes, sure thing, Shane. So I think the thing I always say in the professional context is, there's a few things that underpin all the choices in my career. I've always loved technology. So my first computer, for the folks listening, Amstrad CPC 464, back in the day, eight bits, 64K of RAM. Always loved programming, but I always enjoyed teaching other people even more, so bridging the people and the tech.

I was never going to be the best programmer, though. It blew my mind when I discovered BBC BASIC and I discovered assembly, I could build games, but I enjoyed teaching my friends just as much as I did coding the things myself. So all throughout my career, I nearly became an academic. I really got into research. I did a PhD in AI, which I don't talk about too much these days, but with AI coming back probably should put that bit higher up on the resume. But it wasn't LLMs, it was diffusible logics I was studying.

I nearly became a professor, that teaching aspect I've always enjoyed. But along the way of doing my PhD, I discovered coding in Java professionally, and that was fantastic. Faster feedback loops than the theoretical work I was doing. And now my career took off from there, from software developer to architect, then I went to platform engineer and a few other things along the way. I just always enjoyed that bigger picture from software to architecture, architecture to platforms. And I always enjoyed bringing folks along on the journey, meeting them where they're at, understanding whether they're junior developers, whether they're business folks as we call some people, and knitting together the value of technology in people.

And it's been a lot of fun on that journey. And the journey's only halfway done I guess, right? Hopefully many more years to my career. But I see that theme running throughout the rest of the work I do, whether it's software development, or more product-focused like I am today, but I just love the people and love the technology.

Shane Hastie: What got you involved with InfoQ and QCon?

Getting involved with InfoQ & QCon [02:33]

Daniel Bryant: Don't know if I've told the origin story of those, actually. It was very much motivated by my love of sharing knowledge and learning as well. Because selfishly, I was looking at InfoQ and thinking, "Oh these folks sharing all this knowledge, they must have to learn it of course before they can share it." And having some sort of forcing function if you like, be it writing for InfoQ, be it doing presentations. I thought this would be great to make me learn many different things just out of pure interest and also as I expand my career. So I was reading InfoQ pretty much from when it was created.

I will shout out Ben Evans who's a longtime editor at InfoQ. Ben's one of my mentors back from the Java days, 15-plus years ago, I guess, it's been a while now. One day I was just chatting and I was saying, "I love InfoQ, love all the stories being talked about." SOA was the thing back then. SOA, a lot of Ruby I was reading about. And Ben was like, "Hey, I can introduce you to..." I think it was Floyd and a few other folks. So the founders of C4Media, which is the company behind InfoQ. And I'm like, "Yes, Ben, I'd love that." And the sweetener as well was I was just getting into the QCon conferences and I knew the connection between InfoQ and QCon at the time. Again, a lot of early service, I went architecture microservice stuff, this is what I was doing on my day job. And I saw at QCon and there was like Rebecca Parsons, there was Adrian Cockcroft, folks I'd love to speak to. And I thought if I can get in the door with InfoQ and with QCon, maybe it's an excuse, an icebreaker, to chat to these amazing people and learn from them.

And that's pretty much what happened, Shane. Let's say Ben introed me, I met Floyd and several other folks, Dio. And then Charles I think was becoming the editor-in-chief at the time, met yourself and a few other folks as well. I just realized that this is a really cool community of folks. That is one of the things, several points in my career I'll shout out other than Java community, the LJC, the InfoQ community, the CNCF community, the QCon community. There's been certain communities that have really leveled me up. Do you know what I mean? Just by being around amazing people saying, "I want to be like you, I want to learn from you."

And InfoQ is one of those early experiences of that. And yes, I've not looked back as in it's a fantastic excuse to learn lots of stuff and share stuff on podcasts, on articles, on many different formats and I've thoroughly enjoyed it.

Shane Hastie: So let's dig into your last track at QCon London. The platforms, people and process, delivering great developer experiences.

I want to go to the theme. What was the driver for this? What's the need?

Platforms, people and process for great developer experience [05:04]

Daniel Bryant: Yes, interesting. So it came actually I did the QCon San Francisco track, similar track last year. And Justin Cormack, who's the CTO at Docker, was the sponsor of that track. He reached out to me and said, "Hey Daniel, I'd love for you to connect up these folks and put together an interesting program." Because it's all about the speakers, I was just curating these things.

But one thing Justin said, Justin and I have known each other for many years, and again, love Docker, so I've been working in Docker, Kubernetes, all that space. And we both love the tech, but over coffee we were like, "You know what, we're all talking about the tech a lot." Really, we all know that is the "easy part" in air quotes. The hard parts are the people, the process, all these things that go with a successful product, a successful project.

Justin said to me, "Lean into the people side." So if you look at the QCon San Francisco track, that was some amazing folks on that track and basically the success of that track, I leveraged it into the QCon London track. You never are sure when you're putting together a QCon track, is the audience in the same place you're at? You've got to meet the audience where they are. Are they ready to hear some of these things? Do they like the story we're trying to tell? And they very much did.

A few key things popped out, key themes throughout all the talks in QCon SF was empathy, was big picture thinking, clear goal setting, and people were tweeting, people were on LinkedIn, sharing, "Yes, this is great stuff." We were like, "You know what? Let's bring it over to the European market." Because sometimes, the Bay Area is slightly ahead in some of these things. Just it is what it is. And being a proud Londoner so to speak, a proud UK person, I'm always keen to bring a bit of the Bay Area over into London and Europe and beyond as well. And it went down really well, Shane.

People in London, same kind of vibe, they totally understand the technology. They realized there's a lot of value in being intentional about cultivating a platform, building a platform. But many of them have tried, or are on the process of building a platform, and the sticking points are all around the people, the process, and these things. They're not so much around the tech. And that's why that track, I think, hits quite nicely in London and hopefully gave a lot of thinking points. Again, I'll shout out the amazing speakers. I do 5% of the work, if that, kind of thing, probably less than that. The amazing speakers are the people that really delivered all the value. And I was just sat there like Jessica, Gemma, Avrin, Anna, Andy, just did amazing work.

Shane Hastie: So what is different or special about developer experience for a platform versus just DevX in general?

What’s different about DevEx for a platform? [07:32]

Daniel Bryant: A great question, Shane. And I do see this one quite a bit. And in reality, I think it's all the same thing. Do you know what I mean? The bottom line is, wherever you work in the organization, you are trying to sustainably deliver business value for want of a better phrase. And definitely, I even forgot that when I was perhaps a developer, I was like, "What cool framework can I play with? What latest code can I do?" But then good managers, good mentors along my journey are always saying to me and focus on delivering that business value.

So developer experience for me is that how do I get these fantastic ideas and hypothesis experiments that we've got in our minds or discussing in the company level, how do I get that from delivering observable business value in production. And that gap between those two things, and I did a presentation back at GOTO Amsterdam many years ago on this, but that gap on the idea experiment hypothesis and that gap on running in an observable way in production is developer experience in my mind.

And it touches everything, right? It touches the coding, it touches the architecture, touches the platform, it touches CICD, all these good things, observability as well. But it's the way typically we see it as developers, how do they experience all those things? We talk a lot about shifting left, which is great. I love the principle. Thinking about security earlier, thinking about scalability, resilience, observability. But poor developers, I've been there, you get what we now call cognitive overload on trying to balance all these things. Yes, it's a great idea to think about all those things, but without the right tooling, without the right platforms and critically without the right leadership support, you are never going to do all those things as a developer early on. So my focus over the last few years has been creating tools in the cloud native space to help developers in particular work with all these important things for delivering that sustainable, observable business value via coding.

Shane Hastie: Let's dig into that cognitive overload because we've heard quite a lot recently and probably the last couple of years this has been bubbling up that the cognitive load on developers today is substantively higher and harder than when I was coding in a assembles and COBOL and C++ in the eighties, nineties, even into the mid two thousands and early two thousand teens. But it seems that there's been, and maybe it's a seem, so to me, am I right, has there been an explosion of complexity that we have to cope with?

Cognitive overload in the developer experience [10:10]

Daniel Bryant: I think there has Shane, because I can remember I bumped in some of the COBOL stuff and definitely assembler and things and C++ of my early days. I think the trends I'm definitely seeing is one, the audience, and that includes us, are more demanding now. We've been exposed to the iPhone world or the pick your  sort of favorite UX. When things work really well, we like it and we're like, why can't we have that experience in every bit of software?

So back when you and I were building these more basic, perhaps, banking apps or whatever, I remember the interface was super clunky and you had to suck it up because you're paying money for this UX or whatever, it's business people that are going to use it, tough luck if you like it or not. You go with that. Nowadays the audience, even B2B software, just the audience is more demanding and that includes not only UX but things like security and the threats have just blossomed. There's a whole cybercriminal market now that wasn't perhaps so big when again, I was doing this in the nineties, two thousands. And I would say the rise of distributed systems has definitely made things more complex.

Now the reason we've gone to that sort of distributed mindset, and again, my career started as the internet was really kicking off and it is just incredible. When I was coding on that Amstrad CPC 464 back in the day, it was a terminal in my parents' front room. There was no internet connectivity at all. And as I went to college, I saw the internet blossom and the possibilities, the benefits are innumerable, but there you are inherently dealing with distributed systems.

So again, both the good UX, good experiences, the rise of all the challenges around these things, and again, dealing with the rise of distributed computing, I think the combination of those two things just have bumped up the complexity to a higher order and we haven't really got the abstractions or the tooling to push some of that complexity down into the platform, if that makes sense. Because I think where perhaps with C++, you're dealing literally with memory handling. Java came along, got rid of a lot of that for example, and now we're seeing Rust and things like that. We're kind of rising the abstraction levels that helps me as a developer do my job without getting overloaded.

But with all these changing requirements and distributed systems, I don't think we've quite caught up with the level of abstractions and therefore a developer coming straight out of college these days has got to learn a myriad of things. Not only are they going to learn the actual programming language, they've got to learn architecture, the fallacies of distributed computing. There's just so much stuff you've got to learn now, which I think if you haven't been in the industry for a few years is a bit overwhelming.

Shane Hastie: This touches on something that I would like to dig into a bit. We've got the tooling now, we've got the AI tools coming in, Copilot, that's supposed to be helping us. I'm hearing massive increases in productivity in some reports and others where yes, I might get 10%.

How does somebody coming in new learn to be a good programmer today?

How do people new to the industry learn to be a good programmer today? [13:11]

Daniel Bryant: Yes, that's a fantastic question, You and I touched on this briefly at our end of year or beginning of year summary and as you asked us then about this, I was like, oh, that is a really good point. Because folks that have been in the industry, ourselves included, for a while, having an AI Copilot is like a pair programmer. We know perhaps how to work with a pair. It's different than when you're coding solo. And we also know if you're pairing with an intern, it's very different than pairing with someone of your abilities too. You treat the pair differently.

And I think we haven't quite figured that bit out yet in terms of the levels there. And if you are starting from a tablua rasa, like blank slate, knowing what questions to ask is really hard. I can instantly look at a problem and I'm thinking, oh, with my pair I say, "Oh, we need to think about the second order ramifications of this change we're going to make." But that's just because I've got this sort of inbuilt pattern matching and years of just seeing these things. Whereas when you're starting off, you don't have that gut feel, sixth sense, spidey sense, call it what you will.

And I'm with you, I genuinely think that's hard without doing some of the things and getting that experience and building that gut feeling, I'm not sure exactly yet if we've got the tooling to do that. I think AI could probably help accelerate some of those things, and maybe my mindset is just a bit stuck in the past. I will put my hands up and say that because I'm almost using my old mental models to this new world, but I wonder if we need to create some kind of training or some kind of support system that bootstraps people from that sort of one to a hundred or zero to a hundred where when they get to the a hundred, they're not necessarily the best programmer in the world for example but they know about fundamental tenets, coupling, cohesion, single responsibility principle, many other patterns that many of us have gone through and they've sort of been exposed to the ramifications of some of these patterns and so forth that they know what kind of questions to ask of their pair programmer.

But again, this is a plan. I'm totally conscious that I'm applying my old mental models again, I need to chat to some folks fresh out of college and actually see how they're learning because when I do, I mentor a few folks, and the way they use YouTube shorts and TikTok and things. I'm on those platforms and are playing around with them a little bit, but the way they learn is very different than me. I love a good book and I love getting hands-on with the tech. The book gives me the big picture, I love reading, and the hands-on helps me build a mental model.

But junior folks I mentor, "Don't give me the book, just give me the TikTok," or whatever. And I'm like, "But how are you going to get the big picture?" And I wonder as in we're just going to maybe have to update the way we do teach folks to build software.

Shane Hastie: That's a challenge for the educational institutions, isn't it?

Daniel Bryant: Yes, exactly. I agree.

Shane Hastie: What does an intentional culture look like?

Great culture emergent and requires intentional behaviors [15:57]

Daniel Bryant: Yes, this is great. Again, I've listened to many of your podcasts around this, Shane, and chatted to lots of interesting people at QCons over the years and I think really it is about setting goals and guardrails, primarily. The best cultures I've worked on, they're not the ones with those kind of cheesy things on the wall that says we value all these things, they're somewhat emergent than the cultural norms, but they're emergent from a very clear value of we want to aim for these things, these are our goals. We collectively believe these things to get to this point. And then the guardrails.

I definitely worked in some of the cultures where the cliche is culture is the worst behavior the leader tolerates. And I was definitely in a few of those situations where stuff would side and then no one really liked it and then the culture unraveled from there. So I think for me it's one of those things you have to be on it all the time. It's not like I write my values and stick them on the wall, done. We have to be day in, day out monitoring ourselves in terms of are we subscribing to our stated values, our stated culture? Do we need to adapt to the culture?

I definitely see, I've worked with folks over years who've worked in say, government organizations or big organizations like that where the culture doesn't change. And actually that's a bad thing. We all think, oh, it's a great culture, but it was great 10 years ago, 20 years ago, not so great with the challenges we've got now. So you sort of need to update these things but I do think, yes, goals, guardrails and that constant awareness of how is the culture interacting with new folks joining the team? Are we looking after everyone on the team from the junior folks, the senior folks? These kind of things.

Shane Hastie: Jumping around a little bit, where is platform engineering going?

What’s happening with platform engineering? [17:45]

Daniel Bryant: Yes, great question Shane. I get all the DMs all the time because I'm on LinkedIn talking about engineering quite a lot. People were like, it's just DevOps. And they're folks that have even been around longer, they're like, it's just infrastructure. And I get it as in I know friends have had four different job titles and basically done the same job over the last 10, 20 years. But I think with a lot of technology we come up with different words, we talk about different sort of approaches, but for me it's kind of like, I don't know, it's something like a pendulum swinging or you can see it like a spiral.

My take on it, we are getting better all the time if we're not exactly going in a sort of one straight line to better or success or whatever. So I think for me, platform engineering is a collection of many good things that have come out from building infrastructure, things like site reliability engineering, SRE the Google folks championed, and things like CICD, which I learned a lot from Dave Farley back in the day and Jez Humble, with their classic book. It's mashing all those things together with that cultural sprinkling that you and I talked about a few times today, recognizing hence the QCon track. It's not just about the tech, but if you want to allow developers to go fast, be safe and build systems at scale, you have to provide a framework for them to do that.

And framework, I'm deliberately keeping it a bit vague, but that is the culture, the tooling, the practices, all the things, if that makes sense, right? And for me, platform engineering is the label we're putting over that. And I think you and I have definitely seen even with DevOps, the danger once we do have a label, it's like vendors co-opt it and people just misunderstand it. It's just human nature. Certainly, I'm sure I've played my part in that too. There is a bit of a danger of platform engineering going through that kind of hype cycle as the Gartner folks might say, I've been just reading some Gartner reports about this. We are at the peak of inflated expectations according to Gartner, and then we drop down to the trough of disillusionment and I'm with that.

I think the Gartner folks are often on something of that and then you have to go through this trough before you come out the other side with productivity. But I like it, again, it's an interesting community of people coming around platform engineering. And that for me is the key thing. And most of us assume good intentions and we're not always making the right noises and always going in the right direction. But I think platform engineering is a way to how do I build these frameworks, foundations, platforms, portals, all the things mashed together to enable developers to have the best experience to go faster, think about being safe, security, all these good things and delivering systems at scale as well.

Shane Hastie: Now you mentioned you've been dabbling in product management. Tell us about that.

Dabbling in product management [20:15]

Daniel Bryant: Yes, so my career, Shane, I really enjoyed software delivery and architecture and platform building, but I fancy doing some product work. So I left the company I was working with, I'll shout out to the OpenCredo  folks. Fancied moving on from there about seven or so years ago and moved into building tools.

I worked with a company called Ambassador Labs. When I joined it, it was like seven folks in a Boston office but ultimately we created Telepresence and Emissary Ingress to open source projects that we donated to the CNCF. And now I've moved on from Ambassador Labs and working on Kratix now, which is an open source platform building tool. But along the way of building all these tools and working with the fantastic communities around there, I realized I had to learn some of the basics on product ownership, product management, project delivery, all these good things. Because the fantastic thing with open source is everyone can contribute and literally we found everyone does contribute.

When I worked on that Telepresence back a years ago now, we had people wanting to take the project in a different direction and just again, all great, great stuff. I looked at Marty Cagan's work, actually inspired, and a bunch of other books I'm sure your listeners will recognize. But those books really helped me understand how do I build a good product because if you listen to everyone's opinion, the product's going to be like the Swiss Army knife but negative sort of Swiss army knife, if that makes sense in the cloud native world.

And yes, I just love learning, Shane, as we've sort of mentioned a few times today. And for me learning these product management skills, I can see how they relate to all the things I've built in my previous careers. It's fascinating looking back sometimes as with age comes wisdom, hopefully, right? And when I look back and I remember thinking, oh, that's why that manager said that, that's why that mentor did that. That's why that CEO was saying we should go in this direction. They were trying to meet business goals, they were sort of obsessing about the customer or we know there's clearly some challenges with building a sustainable product, these kind of things. And as a sort more naive software engineer, I was just like, why are people doing these things?

And I get people on my team ask me that these days, "Why are you doing this?" And I'm like, "We're building a product, right? It is not perfect, but we've got to meet some user goals, get some revenue." These kind things opened my eyes. The Marty Cagan stuff in particular, there's many other folks I read their Substacks and listen to podcasts. I've shared Lenny's podcasts. I love the Lenny's stuff. Does fantastic work in the product space. For me it's just opening my eyes up in how I run communities, how I treat some of my career even. That product focus, it's actually a really powerful focus.

Shane Hastie: So what should a software engineer understand about product management?

What should a software engineer understand about product management? [22:47]

Daniel Bryant: I definitely think reading some of the Marty Cagan's work inspired if you like reading or listening to Lenny's podcast is a great way. It is just you can tell folks they're really passionate about what they do and that kind of seeps to many of us. If you're a software engineer, you're probably a systems thinker, you're probably very curious about building mental models and learning. So I think naturally those kind of resources that are out there you would just gravitate to. But I think learning the fundamentals of you are trying to deliver business value. As silly as perhaps that may sound to a bunch of listeners, I guarantee you there's folks out there, because I was certainly one of them at one point where I didn't fully make that connection between we are trying to deliver business value in solving a problem.

Sounds really obvious, but I worked on a few government projects, I worked on a few private projects I should say as well where it was not super clear as an engineer what problem we were really solving. We knew we had a spec and we were building the web apps and so forth. But when I actually look back, if I'd known the business problem I was trying to solve, I might've made different suggestions. I might've sort of pushed back or implemented the software a bit differently. I think it was a danger at some points and probably even now where people want to hide the complexity or segment the work. But I think the more context we have throughout the organization, the better things you will deliver. So I think as a software engineer, understanding you are solving business problems and understanding some of the constraints in your organization is really good.

There's many analogies with programming here, but just understanding in terms of you can build anything but you can't build everything. You have to prioritize, ruthlessly. I really enjoyed learning about prioritization within the product framework. And the last thing I'd say is running experiments. I think that's sort of more thing has come into vogue over the last few years, but back when I started creating software applications, they were months and years of delivery. I remember being handed a telephone directory of requirements for my team back in the government, UK government, my first gig, and I think that project took 18 months, two years and didn't get deployed while I was actually there. My internship finished, I moved on.

Whereas these days on startups we're pushing that code constantly to validate hypotheses like, hey, we think if we had this feature, this small little feature, our customers will get more value from that in this way. I can create an experiment, I push some code out there, I get the metrics back, I look at it, test my hypothesis, validation or not. So I think that's a really key thing, that experimental mindset, which again many of us have as software engineers, but with a slightly different focus towards customer value, business value is a really powerful thing to learn.

Shane Hastie: Advice for young players, people who are early in their career and who are inspired by looking at what you've been doing and your journey. What advice would you give the young Daniel today?

Advice for young players [25:38]

Daniel Bryant: I love these thought-provoking questions, Shane. I would say there's something, I mentor a lot of folks these days and one of the dangers I have and I see other folks have is wanting to do it all. And I've had a very lucky 20 year career so far in tech and I've had some amazing mentors and amazing opportunities along the way and I'm conscious that I've done all these things and people are like, I want to do all the things. You cannot do all the things.

Definitely picking the most important thing to you now, whether it's being a better software engineer, learning how to work with AI, understanding product. Do you want to become a startup founder? Do you want to be that CEO of big org? Being super clear on some of your goals and they're guaranteed to change, I could say that, but being clear on your current goals and then laser focusing perhaps an area that you are strong or want to get stronger in or an area where you know it's a weakness, but you have to have that, really investing in that.

I did a lot of mentoring last summer. I took a bit, very lucky, took a bit of time out, spent some time with the family and so forth. But as well I also mentored a bunch of folks on Zoom. I opened up my calendar and said, Hey, jump on. And a lot of those conversations were how, I imagine I've got no psychological training, but I imagine how the sort of psychologists go. A lot of it's like, so tell me why you think this is what you want to learn. Tell me what your next career step would be.

And the people would often rock up with very clear, I think I need to do this, this, this. And then we actually have a chat around what do you really want to do? What's the most important thing? And break it down and then build it back up with actionable steps. People walked away so much happier than when they rolled into the call, probably a classic case of cognitive overload, right? They were like, I need to read all these books, do all these things, learn all these things. And I'm like, trust me, you can get there but that's a 10-year journey. You need to break it down and have clear smaller goals along the way.

So the biggest bit of advice I gave last year I'd give now on the podcast is be super clear on where you want to get to, but break it down to smaller steps and recognize that work-life balance as well because you can almost run yourself ragged. There's so much amazing resource and content out there on the internet these days, but you can consume it 24/7. You shouldn't consume it 24/7, you should definitely balance up life in general. And I think being super clear on the goals will really help you prioritize what to read, what to learn, what to play around with.

Shane Hastie: Great conversation. We do this far too infrequently.

Daniel Bryant: Indeed. Thank you Shane.

Shane Hastie: I would typically at this point ask where would people find you but of course you're on InfoQ.

Daniel Bryant: That's it. Come and find me there. Yes, @danielbryantuk on most of the places. Shane. So like I'm on LinkedIn, GitHub, X, formerly Twitter, @danielbryantuk is where folks can find me, but InfoQ is the first place. Rock up, have a chat, find me there.

Shane Hastie: Wonderful. Daniel, thanks so much.

Daniel Bryant: Thanks a lot Shane.

Mentioned:

• QCon London
• MartyCagan – Inspired
• Lenny’s Podcast
• Daniel on InfoQ and LinkedIn