In this special year-end wrap-up podcast Thomas Betts, Wes Reisz, Shane Hastie, Srini Penchikala, and Daniel Bryant discuss what they have seen in 2022 and muse on what they hope to see in 2023. Topics explored included: the benefits of architecture decision records (ADRs), the role of Staff Plus engineers, treating platforms as a product, the importance of sustainability and green IT, and the need to be deliberate with culture design.
Key Takeaways
- The architect is a technical leader. A vitally important part of the architect’s role is communicating decisions effectively. Architecture decision records (ADRs) are not a new concept, but increasingly we are seeing companies adopt them and make them standard practice.
- As an industry, we’re increasingly recognizing the value of senior individual contributor (IC) roles, which are being labeled as "Staff Plus". Individuals in these roles have deep technical expertise but are also often "T-shaped" with a wide range of skills.
- We believe Charity Majors successfully argued within her QCon San Francisco talk, "The Engineer/Manager Pendulum", that individuals can move between IC and management roles within their software development careers.
- Creating effective software development and delivery platforms, using DevOps and platform engineering practices, can help reduce developer cognitive load and increase positive business outcomes (in regard to DORA metrics). Matthew Skelton’s and Manuel Pais’ book, "Team Topologies", is the gold standard here.
- Treat your application and data platforms as products; design, staff, and resource them appropriately. Quoting Kelsey Hightower, "don’t look for 10x engineers, look for engineers who can make 10 other people more effective." The role of the platform engineer may be key in gaining this 10x productivity.
- Data is no longer something you simply store somewhere; it is the second most important asset for your business (after your people). There is much innovation occurring in the AI/ML space in relation to modeling, transformation, and processing data.
- ChatGPT will not make developers (or InfoQ editors!) obsolete yet, and this technology can currently provide the role of a good (rubber duck) pair programmer or architect’s assistant. There are inherent biases built into any of the underlying models; recognize this and act accordingly.
- Everybody can contribute to implementing sustainable solutions within software development and IT. According to leaders in this space who have spoken at QCon, including Astrid Atkinson, Adrian Cockcroft, Lisa McNally, and Marco Valtas, you can no longer just pass the buck and say, "that's not my problem."
- We need to invest increasingly in deliberate culture design. Hybrid hell is real; stories abound of people commuting to their office to sit on video calls all day just because of an arbitrary “back to the office” mandate. If you are going to bring people together, think about the benefits and costs for the organization, for the environment, and for the people.
Subscribe on:
Transcript
Introductions [00:24]
Daniel Bryant: Hello and welcome to The InfoQ Podcast. It's that time of year where we do our end of year review and wrap up, looking back at what's happened this year and also looking forward to what's exciting in terms of topics and trends and technologies, people and processes that we are all interested in. I'm joined by my co-hosts today, Wes Reisz, Thomas Betts, Shane Hastie, and Srini Penchikala. I'll let them all do a quick round of introductions, and then we'll get straight into it.
Thomas Betts: I'm Thomas Betts. I'm, in addition to a co-host of the podcast, lead editor for architecture and design at InfoQ. My day job is application architect at Blackbaud, the leading software provider for social good. The trend that I'm looking forward to talking about today is the evolving role of the architect, how we're documenting decisions and no longer just documenting designs. Srini?
Srini Penchikala: Thanks, Thomas. I am Srini Penchikala. In my day job, I work as a software architect with a focus on data and AIML technologies. At InfoQ, I am the lead editor for data engineering and the AIML community. In terms of trends, I'm looking forward to how AIML is kind of eating the software and the software world, as they say it. We'll discuss more details later in the podcast. Next, Wesley?
Wes Reisz: My name is Wes Reisz. I am a technical principal for Thoughtworks in my day job, and then I chair QCon San Francisco and the most recently just finished QCon+. I guess the thing that I want to talk about, I'm not taking a side here, but there's been some things you've seen on Twitter. DevOps is dead. Long live platform engineering. Again, not taking a side there, but I definitely would like to talk about platform engineering, things like teams apologies and effective engineering organizations today. Then, I think that goes over to Shane.
Shane Hastie: It does. I'm Shane Hastie. I'm the lead editor for culture and methods, host of The Engineering Culture Podcast. My day job, I am the global delivery lead for SoftEd, and I want to talk about getting back in person, about avoiding hybrid hell. And, how do we maintain team cultures as so much is changing around us?
Daniel Bryant: Fantastic, thank you very much, Shane. Yes, myself, Daniel Bryant. I lead the DevRel team at Ambassador Labs, a Kubernetes tooling company. Also, I'm the news manager at InfoQ as well, a long career in software development and architecture, which I'm super excited to dive into more today. I'm interested in a similar topic to you, Wes, about internal developer platforms. I see them as the jumping off point to a lot of the other things around platforms in general, so super keen to explore that.
How is the role of the architect shifting? [02:50]
Daniel Bryant : But, as we all know, one of our key personas at InfoQ is the architecture persona, the role of the architect. And, how do we all think the role of the architect is shifting now and how it might shift perhaps next year as well?
Thomas Betts: Well, I'll take that to start. We've had some form of this on the InfoQ trends report for A&D for, I don't know, as long as I've been reading it. The architect is technical leader. Architect is team lead. No one is quite sure what the architecture should be, but we're watching the innovators coming up with new ways of defining what is the architect role, and how do you serve your teams around you? One of the things that's been coming up repeatedly throughout the year was how it's all about communicating decisions. Some of this came out because of the pandemic and hybrid workflows that people are having to communicate more asynchronously. They're having to write things down and finding that it's not just enough to show a picture. Here's the diagram of the architecture I want. People are asking, why was that designed in the first place?
So, documenting why the decisions comes out in the form of ADR, architecture decision records. These have been around for a while, but I've seen them finally get to a point where companies are adopting them and making them standard practice. But, at my company, people will have conversations about new features and say, "Hey, do we need an ADR for that?" And, architect goes off, spends some time figuring out what to do, and writing it down. Then, people can discuss, why did you make that decision? You see the pros and the cons, and then it's more of a collaborative process.
Wes Reisz: Hey, Thomas, before you keep going on that, ADR tends to ... People have a different mental model for what an ADR actually is. What is an ADR in your organization?
Thomas Betts: So, the way we use it is it always starts with a question. I'm trying to solve this problem. Here's a specific scenario. How could I go about doing this? Because, we know the answer to any question is it depends. It's helpful to walk through what does it depend on? So, I like creating a new ADR template. There's MADR and there's other tools you can use that say, "Hey, here's markdown for ADRs and command line tool." Create a new one, give it a name, and it flushes out a template.
Then, you fill it in and say, "Okay, what is the decision you're trying to make? What are the possible options you're considering? What are the pros and cons of each?" Then, what's the decision? All of that gets checked into a centralized Git repo. Other people who aren't architects can review them. People who aren't architects in their day job can write them. So, you can give it to a team and say, "Hey, here's the thing that you can start thinking about, and you can start understanding the role of architecture and being an architect. Think through the decisions." And, people start learning that decision making skill.
Wes Reisz: It's that context, right? It's so you can establish that shared context of why in the world did you pick that message bus? Why didn't you do this? This is the things that were behind it. Yes, absolutely.
Thomas Betts: It's a collaborative process, and I think that's what this goes to, is that architects use these first, get the pattern established, figure out what works within our company. Each company, you adapt it to be what you need it to be, but for the big cross-cutting concerns, those get put in a shared repo. Then, inside one project, inside one microservice, we might have, hey, here's how we're going to do stuff. The team can then discuss it, but then that just gets saved in the documentation as part of the repo. New developer comes on the team. They can say, "Well, why are you doing it this way?" Well, yes, we had different options. We chose this, and now that why is written down.
It's also living documentation. You can change your mind, and you don't have to say, "Well, here's the diagram that is out of date the day that you finished drawing it." Then, no one goes back and takes the time to find the original source file to update the PDF. They're like, "Well, I know what's changed." If the mental model is just in your head, then it never gets updated. This puts it in a simple text format. People can update it, and then if they want to make a diagram next to it, Mermaid diagrams fit in really nicely. You can do a Mermaid diagram. So, you can do do simple sketches inside the ADR and show, here's what I'm thinking of. So, seeing how you combine those tools is nice.
How do we maintain this type of living documentation and the culture that supports it? [06:27]
Shane Hastie: Thomas, I'd love to see how do we maintain this type of living documentation and the culture that supports it? Because, oh so often, we've tried to bring in documentation. Every microservice must have a comment explaining it, and the comment is, "This is a microservice."
Thomas Betts: I think when you're talking about ... What are things we've used? Wes mentioned service bus. If we're going to use whatever service bus technology or how we're going to send messages across the wire, how are we going to serialize it? Things like that, if it's a big ... Here's the company-wide decision. Sometimes, people just show up, and it's the story of the monkeys that won't climb up the ladder because the first monkeys got hit with the fire hose. People don't remember why. Well, having it written down, and then two years later, you're like, "This seems like it doesn't make sense anymore."
We don't have two years worth of history, but being able to point to six months ago, what did I decide? I had that personally. A decision I made in January seemed right based on the information I had at the time. By May, new information was available, and new business priorities were available. And, we could reevaluate. Oh, option two was a sensible thing to do in January, but come May when we've got a different direction and that's not the priority, reevaluate the it depends, and a different option comes out and says, "Oh, we should go a different direction." We say, "This ADR supersedes the previous ADR, and this is the way we're going."
Wes Reisz: There's three things that he said. Just to tease out one, he said the word lightweight. This is very light. It's not a novel. It's not a huge book. It is a very lightweight ... What was the decision? What's the context? What does it mean? It's very, very lightweight, just a few consequences. Then, the second thing he mentioned was Git, which means it's versioned. So, if you change it, you just give it another version, and it can keep evolving. If it's in a wiki, cool, but that doesn't really show you the full version that changed. So, getting it into Git is really key for the versioning. Then, also the third thing is still Git. It's right there with the code. So, when you check out, when you clone that repo, you're looking at it. You can look at the 10 ADRs, maybe the 20 ADRs that maybe went into why some of these things happened. That's what's so powerful, I think, about ADR sums.
Thomas Betts: The fact that it's a read me file in a Git repo brings the barrier to entry down to the average engineer developer, not, oh, that's the ivory tower architect. We're trying to get away from the architects are over there. They make decisions. They tell us what to do. This is now embedded with your project, and you see it with your code. The team feels empowered to do it. Then, if you see them as examples, the next time when you're having a big feature discussion, and somebody is sitting there and having half an hour discussion, or a standup is taken up with ... I don't know what to do here.
Tell them to go offline. Fill out an ADR just to walk through the process. Maybe it'll help them think through it. That doesn't take an architect, but it sometimes takes that architecture mindset of it depends. Think through your pros and cons and your trade offs, and write it down. It's like rubber duck debugging. Having to explain yourself makes you understand the problem better. You're going to come up with a better solution than you just say, "Oh, we're going to go with option A, because I know it best."
What impact is the increased visibility of “staff plus” roles having on the industry? [09:27]
Daniel Bryant: One thing I just had as well, Thomas, is that you did a fantastic interview. I think it was with Andrew Harmel-Law a while back. That is well worth referencing, right? Because, he addressed Shane's question there. He talked a lot about how you get folks involved, who should be involved, and how you incentivize to do that kind of stuff, right? That was a fantastic podcast and fantastic article.
I think that's a nice segue, Thomas, as well to the next thing I was going to look at was Staff Plus in terms of the role of each individual. You mentioned there, not just the ivory tower architect. I think many of us here started our careers when the ivory tower architect was very much a real thing. What do folks think now in terms of options for senior IC roles, getting folks in to contribute to things like architecture?
Wes Reisz: One thing that's interesting is that we're recognizing it, right? Before, it wasn't so long ago in my own mind. It was like you got to a certain point. Okay, what am I going to do now? I've got to this point where I am that big A architect you mentioned. Now, I guess I've got to be a manager. I guess I've got to get into a director role. Now, with Staff Plus, it's starting to say, "What is the roadmap beyond that staff level?" So, I think that right there, just being able to have companies intentionally looking at it is a huge point for me.
Srini Penchikala: Just to add to that, right? Architecture is getting the right focus as a discipline and a software craftsmanship, rather than just diagrams and the artifacts. That's where the architects are becoming more valuable to the enterprise, because what they can do, how they can contribute to the teams, rather than just creating some PowerPoint slides and throwing it over the wall. I think most of them are hands-on, and they are involved as throughout the life cycle of the software development. Also, like Thomas mentioned, it's an iterative and incremental versioning of the architecture. So, it's going to evolve through the software product development lifecycle.
Thomas Betts: Yes, one of the things I like about the different levels of engineering once you get past, because I think you're right, Wes. It used to be you were a junior engineer. You were an engineer, senior engineer, and then, well, the next thing up has to be architect, because that's the only title we came up with. It was a title, whether you were doing the role or not. Well, that guy's been around longer. The other option was management. By having the Staff Plus and having actual levels of engineering, it tends to be that more T-shaped role of you have to think about cross-cutting concerns.
You have to think about more than just the one little project you're working on. You're seeing companies recognize you need to move up and say, "Okay, how do you solve this problem for two teams that works well?" That gets to ideas like platform engineering that I know you wanted to talk about later. Somebody has to think about the cross-cutting concerns, the big projects, and the big picture of how does this solve multiple problems? How do I come up with new ideas? That goes up that ladder of not just three levels of engineering, and then you're out.
Wes Reisz: Yes, that T-shaped engineer always has resonated with me, too. Be broad across many things, but deep in a particular area. Yes.
Shane Hastie: Charity Majors gave an amazing talk at QCon SF where she was talking about actually consciously, deliberately bouncing in and out of that senior Staff Plus/Architect role and into management and then bouncing back and forwards and doing this a few times and seeing that as a great way to, one, spread and to move beyond T-shaped to pi-shaped, or broken comb is the other thing where people can build many deep competencies in different spaces and moving back and forth on that and managing your career like a product and very, very deliberately making some choices there. So, I would certainly point people to that QCon San Francisco talk by Charity Majors. It was great.
Thomas Betts: She called it a pendulum, because you can swing back and forth, and it's not a one way road that you went over to management. You can't come back. Sometimes you go over, and I like how here, you build software. Here, you build people and teams. You're responsible for the people you are managing and their careers and supporting them. That is a different role. It's not a promotion. It is a different job. Just like it's not a demotion to go back to engineering, it's a shift in what do you want to do and having that flexibility.
Wes Reisz: Yes, and normalizing the conversation about it, too. I think that's a really interesting thing. What I loved about Charity's talk that you mentioned, Shane, was that it was normalizing the conversation. It's okay. How many people have you talked to, have we all talked to who went into a management position and was like, "I just wanted to go back to being an IC," and then maybe even went back the other way? That talk, I think it was really cool just for us to all get together and nod and go, "This is normal. This is okay. It's not a dirty secret."
Is it possible to move back and forth from individual contributor (IC) and management roles within the same company? [13:49]
Daniel Bryant: One thing I'd ask, do you think it's possible to do that within a company? Or, do you maybe have to change companies if you want to go between team lead to senior IC?
Shane Hastie: I'm going to respond there with the answer, it depends. If your company is mature enough to understand, and if you can have that conversation, so maybe if you're the first one moving there and you can influence the organization, because it's so much better for the organization if we don't lose people all the time. The cost of replacing a senior person is so huge in terms of the knowledge that walks out the door when they leave because we're not giving them what they want out of their careers. We see this, and I'm segueing a little bit into the culture stuff and the organization cultures.
One of the trends that we are seeing is this huge great resignation, 30% of people changing jobs, and 70%, according to some studies, are actively dissatisfied with their current position. Well, the cost of the organization of losing those people, phenomenal. What do we need to do at a leadership level to create the opportunities for people to move as their interests shift without losing the people? So, this requires a whole lot of different thinking at the executive leadership level, which now we touch on the other trend that I think is happening is business agility, the recognition of the Agile ways of thinking coming into organizations at higher levels and at different levels. Definitely, I think in that space globally, we're at the early adopter.
Srini Penchikala: Shane, to add to your thoughts, what I'm kind of seeing in some of the organizations is the senior IC or Staff Plus, these positions are being created more as evolved opportunities, rather than appointed opportunities. So, it's not like the senior leadership is saying that, "Okay, we are going to make you a senior Staff Plus engineer." It's the other way around. So, these team members are able to contribute not only technologically, but also organizationally. They're able to manage their own people, the stakeholders, speaking of people management. Architects and dev leads, we have our own people to manage, the stakeholders. So, they're able to do really these kind of things so very effectively, and really over the next level, to contribute 2X or 3X compared to other ICs. That's where some of these people are getting promotions and making those promotions happen.
The role of the (mythical) 10x engineer; aim for one engineer to make 10 others better [16:17]
Shane Hastie: Yes, there was a great quote, and to my chagrin, I cannot remember who said it. But, it was in one of my podcasts and was talking about a 10X engineer is not an individual who is 10 times faster than anyone else. It is somebody who makes other people more effective, that this person makes 10 people better. That's what a 10X engineer is.
Daniel Bryant: I think that's actually maybe a nice segue, Shane, as well. Because, I've heard the same thing. It was Kelsey Hightower.
Shane Hastie: It was Kelsey Hightower. Thank you.
What do you all think about platforms, platform engineering, and the goal of reducing developer cognitive load? [16:46]
Daniel Bryant: Perfect, because I was chatting to him as well, and he was saying, "Don't look for 10X developers. Look for someone who can create platforms, for example, that make other engineers 10 times as effective." There's many different takes on it, right? But, Wes, I think that's a perfect segue into what you're looking at there, because Kelsey was like, "Hey, the platform really is a massive lever. If you get it right, you can enable all the stream aligned teams as team topologists call them. You can enable folks actually delivering value." I think that was a great segue, Shane. The floor to you, Wes, what do you think about what's going on in this space?
Wes Reisz: I think you already introduced it perfectly right there. It's that we started this conversation a while back with DevOps. If you've been on Twitter, if you've been on any of the social medias these days, you've seen some kind of conversation about DevOps is dead. Long live platform engineering teams. I think what that's trying to say is that, look, we had dev. We had ops. We brought together DevOps. But, in that process, we took cognitive load. Again, this goes out to that team topology reference you just made. So, just a shout out real quick to Manuel Pais and Matthew Skelton, that book, Team Topologies, has been at the forefront of just about every conversation I've had in the last six months. So, well done to those two, and it's just if you haven't read it yet, why not? Go read it. But, we took dev. We took ops, and we brought them together into this space called DevOps.
We did amazing things, but in the process, we took cognitive load on our teams, and we went really high. It got really, really high. Burnout is an issue, right? Trying to keep your mental model together of all the things that a team has to deal with today from Kubernetes to Istio to the sidecars to your ingress, and then you've got to write code, is getting quite a bit. So, the idea with platform teams is how do you pull that lever that you mentioned and start to reduce that cognitive load? How do you reduce the friction, so you're ... to use team topology vocabulary, your stream aligned teams can deliver on the features, the business capabilities that they need to do? So, platform teams with some of the stuff, again, I think that you want to talk about with internal developer platforms and things along those lines, platform teams are providing the self-service capabilities, reducing friction. They're doing all these types of things. So, keep going, Daniel. I know this is an area close and dear to your heart, as well.
Daniel Bryant: Yes, for sure, Wes. What I'm seeing as well is something emerges. There's a distinction between internal developer platforms and internal developer portals as well, because we've got to mention Backstage, right? Spotify's Backstage is seemingly everywhere at the moment. Every person I chat to, they're sneaking Backstage in their stack. Backstage is an amazing project. It's a CNCF open source project. There's many other similar ones, if folks are looking as well. But, what some people are looking at Backstage as is a silver bullet. And, we all know, I think we mention silver bullets every year on the podcast, right? There are no silver bullets. Much like it depends, we always say there are no silver bullets. What folks are saying is, do you think, as you mentioned, Wes, about self-service first? That is the key thing. Lower cognitive load enabled developers to deliver value.
A portal, something like backstage ,may be part of that, but the actual platform itself is a bit deeper than that. How do I provision infrastructure? How do I push my code down a CI/CD pipeline? How do I verify the qualities? All these things like security shift left. All these things we talk about are so important, and that platform must offer you the ability to bake in all those sensible things. That's stuff that you've talked about, Thomas, in terms of all that architecture, all the -ilities, right? The platform should help us as developers bake that in and definitely verify it before it ends up in the hands of users. So, I think next year, we're going to see a lot more focus on internal development platforms. I think within the CNCF, the Cloud Native Computing Foundation, there's a bunch of companies, a bunch of projects popping up. That's usually a good sign that some standardization might happen in that space, I think.
Wes Reisz: The idea is not new. Netflix talked about the paved road for a while. They were kind of saying, "Look, let's get on this paved road. If you get off it, you've got the freedom and responsibility, the freedom to do it, but the responsibility to take care of it." But, I think what was so powerful, again team topologies, was that it put a name. It put a conversation. It started raising the conversation about this in a way that the platform team specifically's job is to remove the friction, to improve the velocity of those streamlined teams.
Data mesh and platforms as product [20:53]
Thomas Betts: One of the topics we didn't actually have on the list was data mesh. I think one of the things that companies struggle with in implementing a data mesh is that they have to create a platform that allows them to take charge of the principles and actually live out and say, "Okay, here's the dream of having these individual data products." There's a governance layer that you have to have to make sure that everybody plays by the same rules, so you then get to the idea of having that standardized mesh that everyone can then put data in and get the data out that they need, as opposed to having the bottlenecks.
It's just like the monolith was a bottleneck, because one team had to control everything, or there was one repo everybody had to contribute to. And, it's always a pain. We spread that out. Well, you can't just spread it out. You need to build the platform to help you spread it out so you can then get those benefits. That's just one example of where we're seeing the next level of doing anything with this is going to require some investment in building the platform and coming up with the people who just want to build the platform to then enable the rest of the company to say, "We can now go to the next level."
Daniel Bryant: I like it. There's one thing, just riffing back to our staff engineers. I'm seeing a lot more focus with and platforms as products. Actually having a product manager on a platform is a really interesting trend I'm seeing now. I think it's quite an interesting role, because you have to be empathic. You have to be able to engage with the developers who are the customers, the users. You have to be a good stakeholder management, because often the senior folks are like, "Why am I paying for this platform? What value is it adding?" No, it's an enabler. You're investing in solid foundations, be it for platforms in terms of applications or platforms in terms of data. So, I think product management is something we all sort of do. Often, I think in this call, we all do on the side case, but as in I think it's going to be more and more important in the platform space.
Thomas Betts: Yes, I like that. It has to get past the old idea that IT is just a cost center, and people don't see it as a benefit. They just make sure the email works. No, software is what's enabling your business to be more productive. All of these things, you can leverage the ROI on it and say, "This is a good investment. We need to continue investing in it. This is what it takes to invest in it." You have to have the right people, the right roles. You have to think about it the right way.
What are the interesting trends in the AI, ML, and data engineering space? [22:48]
Daniel Bryant: Yes, 100%. I think you mentioned the data mesh there. It's probably a good segue into your area, Srini, right? You are our resident data expert here. Have you been seeing much of data mesh this year? I know you've been looking at the trends report, and anything interesting in that space that you'd like to comment on?
Srini Penchikala: Yes, definitely. I think data mesh is one of the several trends that are happening in the area. Just like Thomas mentioned, data, similar to architecture and security, is kind of going through the shift to left approach. Data is no longer something you store somewhere, and that's all it is. It is becoming a first class citizen in terms of modeling the transformation and the processing. The whole end-to-end automated data pipelines are definitely getting more attention, because you cannot have the data in silos or a duplication of the data and the quality of the data, all those problems. So, Yes, definitely database is one of the solutions for that, Daniel, as well as the other trends like streaming first architectures where the data is coming in terms of data streams. How do we process that?
There also the talk of streaming warehouses now. How do we capture and analyze the data coming in terms of streams? Not only we have data warehouse, now we have streaming warehouse. Those are some of the trends happening there. Also, definitely I know if you want to look at all the major developments in this area, they're definitely data related trends, data management, data engineering. Also, the whole machine learning and artificial intelligence is the second area. The infrastructure for all of this to make it happen, platforms and everything, that's a third area that is currently definitely going through a lot of transformation and a lot of innovations, also.
Thomas Betts: I'm going to echo what Srini was saying. When we were talking about the architecture and design trends report, which I think was back in February or April, we spent a lot of time talking about data and architecture and how architectural decisions are being driven. Like you said, it's not just where do we store the data? Or, do I use SQL or no SQL? It is I have to think about data upfront as part of my entire system. So, how do I make sure we have observability, not just of the system, but of the data to make sure that the data is flowing through properly? Are we going to use AI models? Can we get our data into a way that we can feed it into a machine learning model so we can get some of those benefits? All that has to be considered. So, that's where architecture has to start thinking a little differently, not just here's the product. Here's the object model, but what's the data? And, creating data separately as focus on the data and architect for the data, it's a different way of thinking.
Srini Penchikala: Yes, it's almost like data is a product, right, Thomas? Give it enough emphasis for that, right?
Daniel Bryant: I think more and more, we are seeing that role as a product, Srini, be it data architecture, many things. I think that role of treating things as a product, design thinking, systems thinking, to Wes's point. A lot of that is DevOps based as well, that systems thinking, that design thinking. But, it's newish to us, many of us I think in software engineering. We just want to write code, is the thing I hear sometimes. But, now you've got to be a bit more thinking of the end-to-end experience, right?
Srini Penchikala: Yes, because data, as they say, is the second most important asset of any company after the people. So, Yes, we definitely need to give it as much attention. Data is definitely going through the similar evolution that code and architecture have gone through in the past. There is a continuous CI/CD type of approach for data as well in terms of receiving the data, ingesting it, processing it, on how do you version the data, and all that good stuff. So, definitely data side is seeing a lot of innovations. Machine learning, as you guys know, probably there's no other technologies that has gone through the same level of innovation as machine learning and AI, right? We can talk more about this if you have time later. We have the GitHub's Copilot, which was announced probably a year ago, I think.
It has been talked about as a tool to improve developers' productivity. I have heard from some developers that Copilot has made them 100% more productive, so almost 2X, right? They say they don't write any basic functions anymore. They don't need to remember how they're written. They just ask Copilot, and Copilot creates, generates all code for them. They don't even use Stack Overflow anymore, because Copilot is next to Stack Overflow. With all that happening right now, we also are seeing the new technologies like ChatGPT that's getting probably too much attention in a way and how that can change not only developers' lives, but everybody else's lives.
Will ChatGPT make the InfoQ editor team obsolete? [26:39]
Daniel Bryant: Do you think us InfoQ editors are going to be out of our jobs, Srini, with ChatGPT?
Srini Penchikala: Yes, it looks like we won't have jobs, because ChatGPT can write articles, maybe even host podcasts. The third I just want to mention briefly is the infrastructure. We talked about platforms. This is where the Kubernetes and the hybrid clouds and the cloud agnostic computing can really help in our machine learning. Also, we want to make these solutions as a service, so machine learning as a service so the developers. AI developers don't have to remember what kind of image they need to manage or where to deploy, where to host, and how to scale up. The platform will take care of all those, right?
Thomas Betts: And, that's where I would like to see in the next year or two coming, is how the barrier to entry for doing all these things with AI and ML has to go down. What is the platform that enables all my teams to start using it without having to become experts in it? Because, I feel like there's just too much to learn for people to say, "I'm going to just use ML. It's Monday. I'm going to use it on Tuesday." I can spin up a new microservice in five seconds, but I can't create a new machine learning model. I don't know how to do that. If we can get a platform that can take care of that, going back to our earlier discussion of the importance of platform teams, then we can start doing 10X scale on what our internal AI models can do.
What about the legality, ethics, and sustainability challenges associated with the use of AI (and computing in general)? [27:48]
Daniel Bryant: Yes. Has anyone got any thoughts about the legality of some of these models? I've heard there's some interesting challenges. I think there's a court case now with Copilot. Just today, I saw, I think it's a new subscription model coming out for Copilot where you can just train it on your data. To your point, Thomas, you have data sovereignty, and that doesn't leak out anywhere. But, Yes, anyone got any opinions on the legality?
Shane Hastie: I want to tackle broader than legality, the whole ethical aspects of how do we make sure that the products we build are good? And, we'll touch on green there, and we can touch on social good. Thomas, you're in that social good space. How do we encourage others? Lots of questions, not a lot of answers.
Thomas Betts: We all know that there are inherent biases built into any of the models. The data that it's sampled and read off of is what it has built in. You have to assume that. We've had plenty of discussions on the podcast and on InfoQ about understanding that. I think what we're seeing, because ChatGPT took off, and mere mortals can now interact with an AI. That's, I think, what we saw since it came out. People thought, oh, that's those nerds over there in the corner. All of a sudden, everyone is trying it out. They're like, "Oh, I just asked it to come up with a script for a Seinfeld episode, and it did." Does that mean it was a good episode? No, but it did something.
People are talking about can it be used to have kids finish their homework? If it's good enough to fool their professors, who's going to know? There's a lot of ethical questions, like you said, not a whole lot of answers. I think we're just starting to see this becoming so mainstream that the accessibility of it is so easy. People are going to start using it, and like anything on the internet, it's going to be used for good, and it's going to be used for bad. I hope that we see more good cases come out of it, but I don't think there's an easy way to just ensure that it's a good solution.
Wes Reisz: I think there's another interesting point there that you bring up with green there, Shane. It's a new -ility. We're seeing green being discussed as a brand new -ility. What is the cost of running some of these models? What is the cost of running Kubernetes? I think sustainability and the green question, we've seen it both at QCon London. We've seen it at QCon San Francisco. We've seen people like Adrian Cockcroft who went into this space who helped define the term microservices, now taking his whole career towards sustainability. So, I think that's a really interesting question. I'm curious what everybody else thinks about it. I know, Thomas, you did a podcast on it, didn't you?
Thomas Betts: Yes, I talked to Marco Valtas who also spoke at QCon on the green software principles. Yes, there's a definite link we can put in the show back to that podcast talking about the principles of green software development. I think if I can recall off the top of my head, it's everybody's problem, and everybody can contribute to it, and everybody can do something. You can't just pass the buck and say, "That's not my problem." Everybody who writes software is involved in saying, "Can we make this a green solution?" The talks at QCon were very good, because they covered ... Here's what you need to do, and here's what the big picture is, and set the whole context. Who was the keynote speaker?
Wes Reisz: Astrid Atkinson, and then the talk you were looking at was The Zen of Green Software with Lisa McNally and Marco Valtas.
Thomas Betts: Right, Astrid talked about how we have this issue with climate change, and we know the impact of carbon. You can either just go along and hope that somebody fixes it, or you can be part of the people who fix it. I think she's shifted her entire career, founded a company focused on one aspect of the grid and how to make it ... I'm going to take my knowledge of distributed computing and apply it to the distribution grid. She commented that distribution is an overloaded term in that context for sending electricity over wires, but managing it like a complex system. But, you don't have to do the whole thing.
If I have to go into a field where that's my focus, everyone can take their software and look at it and say, "Where am I running this? Is it using green energy, or is it running in one of the data centers that's all coal-powered energy?" So, maybe we can move it somewhere. If it doesn't have an impact on our system, or run my jobs off peak. I've got a smart meter in my house, so if I run my dishwasher during the day, it costs me more than if I run it overnight. Little decisions that I can make as a human, I can put that into my software, so my software says, "You know what? I'm going to run on a more green schedule, because no one notices the impact, and I still get the same results."
Daniel Bryant: On that note, Thomas, then you mentioned Adrian Cockcroft already. He was a big advocate of us all as customers saying to our cloud providers, because many of us consume from the cloud, asking, exactly your point, Thomas, "What's the impact in terms of CO2 of running this workload? What's your green options? Can I pay a bit extra?" Adrian, I think, was on point and on the money in terms of we have to drive that change. We have to ask it as leaders. What is the impact? The cloud folks are very sensible. They'll listen to the general trend, but they've got to get that feedback from customers.
ThoughtWorks Cloud Carbon Footprint [32:16]
Thomas Betts: And, Wes, I know Thoughtworks has done some sort of report that you can plug in some of your variables, and it'll kind of estimate what's your green impact.
Wes Reisz: Yes, Tom, there's a tool that Thoughtworks puts out called ... Again, I work for Thoughtworks, so not in this particular space. I'm a consultant working with organizational transformation, DevOps, Kubernetes, things like that. That's what I do. However, Thoughtworks does have a tool called Cloud Carbon Footprint. What it does is it helps you estimate your carbon footprint with some of the cloud providers. You can go out to GitHub. It's an open source tool. Download it. Actually use it to be able to see what that is. Again, that podcast that you did with Marco, I believe, dove into that a bit too, right?
Thomas Betts: Yes, and you may not get an exact answer, but every model is wrong. Some are useful. It's helpful to start looking at it, and then you can figure out, do I need to refine this at all? Or, does it give us the general ballpark of how many tons of CO2 is our software creating? And, can we do something about that?
Wes Reisz: Adrian Cockcroft, he did a DevSusOps talk, and he talked about that the IT sector contributes 3% of global CO2 emissions, which is on par with the aviation industry. Think about the growth of the data centers just over the last three, four years. What will that look like in another four years, in another four years? So, we have to start talking about this. We have to start thinking about it, because our systems are hungry. They're continuing to consume more and more power.
Thomas Betts: Adrian had a couple other good points. It's always nice to have the other point of view and saying, "Yes, there are some big software concerns, and yes, there's a lot that we can do." Also, look at your organization. The software might not be the biggest contributing factor to your company's CO2 footprint. I think he cited at Starbucks, their biggest one is dairy. If they got everybody to switch to non-dairy milk, that would reduce their carbon footprint more than shutting off all their servers. So, you can make a big impact, but is it the right impact? And, is it the right place for you to focus? So, that's why those tools that can say, "Give me the estimate of how much we're doing," oh, well, we're running all these servers, and no one is using them. We should shut them down. There are some easy wins, but the long-term operations is where you have to look and say, "Okay, what is this going to project, if we have super scale, and we have to have 100 times the load. Are we able to handle that in a green fashion?"
What will the future of work look like? Are we all heading back to the office? [34:24]
Daniel Bryant: Looking at the end to end there, Thomas, something I was just thinking about is a lot of us used to commute, right? Pre-pandemic, the commute itself, and then obviously, we all fly all over the world to conferences as well, so we've got to be careful what we say here. But, I'm kind of curious what everyone thinks in terms of the move to hybrid now. A lot more of us are working at home, cutting back emissions. So, there is that aspect of it, but it does bring in some other challenges in terms of we're on Zoom a lot more, I'm guessing. I'd love to hear focused thoughts on what the future of hybrid will look like. Will we be flying around the world for conferences? Will we be traveling to the office every day? I'd love to get folks' thoughts on that.
Shane Hastie: Hybrid hell is real. The stories and the reality of people commuting into the office, because there's a mandate, they've now got to be there two days a week or three days a week, it's not coordinated well. So, you come into the office, and then you spend seven hours on Zoom calls. We've got to start being deliberate about why we bring people together. There is huge value in coming together in person. We see this in the conferences. Being together at QCon SF was, for me, one of the highlights of this past year. It was just wonderful to be in the same place with the people sharing all of those ideas. So, there is a real value in that.
There's also amazing value and great value in the QCon+ events and the ability to ... Of course, this is what InfoQ does, is make those sessions available so we can watch them asynchronously, as well. But, then how do we help our teams, help the people in the organizations get the balance right? So, if you are going to bring people together, think about the cost for the organization, for the environment, for the people. When you're doing so, make sure that the benefit outweighs that cost. So, if I'm coming in, and Yes, maybe it is one day a week, but it's the same day for everybody on my team and all the stakeholders I need to work with, that's incredibly powerful. Because, now we can have those collaborative conversations in person and leverage the humanity of it.
But, don't bring us in to sit on Zoom calls. Have a deliberate reason. Also, let go of how we measure. It's not about hours in front of a screen. It's about outcomes. The other thing, if we think of the impact from a green and climate perspective, the organizations and in some places, countries, governments that are shifting to four day work weeks. What's happening there? And, the studies are amazing. In every organization that has shifted to the four day work week, productivity has stayed the same or gone up. People are more focused, because now we've only got four days. We get the work done. That makes more leisure time, and we're not chewing carbon in the leisure time. We're actually taking the leisure.
Thomas Betts: Is the move to four day work week becoming more palatable because people don't have a commute? If I don't have to work, you're basically taking 40 hours, making four 10 hour days. But, if I don't have to drive an hour each way, my eight hour workday, I've got those two hours back. Now, am I willing to do those two hours if I'm at home? Is that why four day work weeks are becoming more common?
Shane Hastie: I don't know, because the studies are largely saying, "No, this is a 32 hour, four days at eight hours, not four days at 10 hours."
Thomas Betts: Oh, I like that even better.
Wes Reisz: I like what you said about outcome, Shane. That right there really resonated. I think as I was watching here with the screen, I know everybody else can't see it, but everybody was nodding when you said that. It's not about screen time. It's about the outcome. It's about what we're trying to achieve, and I think when you're focused on the outcome, sometimes you can get more done with less time.
Srini Penchikala: To add to Shane's comments and your comments, Wes, I can agree with you guys, because the in-person mandate cannot be come to office Tuesday, Wednesday, and Thursday kind of thing. It has to be context based. It has to be product lifecycle based. If we are doing product in PI, for example sprint planning, sprint planning needs everybody preferably in person so that they can collaborate for one or two days. Then, if the development phase starts, when the development starts, not everybody has to be in the office. So, it has to be more context driven, rather than calendar driven, right?
Daniel Bryant: I think on that note, Srini, as well, I've seen a lot of companies and my team included getting together at least say quarterly in departments and once a year all together. Definitely, the retrospectives and the brainstorming, you cannot do, in my experience, at least my experience, you can't do as effectively via Zoom. You get the stutters, the cutouts, or whatever. People just can't read each other quite as well when you're not in the same room. I think for us, the quarterly planning really works well. We rotate folks in to do cross-collaboration with the teams. But, then Yes, that yearly get everyone together, and it's going to be tricky with the current macro economy, the climate of can you justify getting everyone in the same place?
To Shane's point, is it good for the climate, flying everyone to one place? But, I don't know, a lot of teams I've worked on, regardless of size, we're probably talking up to 100. Once you get past 100, it's not logistically possible. But, a lot of startups, I think the value of getting folks together once a year and just building those bonds, because with a startup, it does tend to be quite dynamic, right? It is really valuable, I think, to get folks into the same physical space. In addition to the commutes into the office, I think that the quarterly and yearly are really valuable.
Don’t underestimate the bonds that are built in-person [39:40]
Wes Reisz: I was going to echo the bond part there. It can't be underestimated. We're doing amazing things in this hybrid world, trying to build bonds online, but three dimensions is important. Getting it right, bringing people together, being able to connect as human beings really allows you to be more comfortable, more safe in your environment. It allows you to be present better. So, that bond, I think, is super important.
Thomas Betts: Another call back to the whole track of remote work was fantastic. It was probably the surprise. I didn't plan to go to every session, and I kept sitting in that room. Just to call one out. Jesse McGinnis from Spotify talked about how you need to be intentional in whatever you do. Whether it's remote first or hybrid or remote only or whatever your model is, embrace it, and say, "Here's what we're going to do," and make those decisions. Say, "What's the right venue?" I think, Srini, you said, "The context is really critical." If you're having your daily stand up, does it even need to be a Zoom call? Can we get that done on Slack? Or, is it four days, we can do it on Slack, and one day, we actually meet just to see each other.
If it's just to communicate the status, that's fine. Use the in-person for not just coming to the office to be around people, but to actually take advantage of the stuff you can only do when you have that three-dimensional connection. So, if it is quarterly, don't spend it all in planning meetings. Do some actual team building events. Go out and volunteer together, something like that, so you actually meet the people as people, not just a three by five section of your Zoom screen.
Srini Penchikala: Just to add to that, Thomas, I really like your idea. You just mentioned the volunteering, right? Any of these community outreach efforts, if they happen in person, it's going to help with the bonding, what Wes mentioned, the productivity in the future, the safety, and the gratification. So, it's going to make it 10X valuable in the long term.
Daniel Bryant: One thing I would say, drawing some of these things together, is all the great talks I've heard you mention QCon SF and QCon+ have been covered on InfoQ. Shameless plug, Shane, I know you wrote a bunch of ones. Shout out to Steve Yan. Srini, I know you've done some as well with QCon things. Yes, there's a bunch of great content, because that one you mentioned, Thomas, I read the notes on InfoQ. I had to immediately tweet it, because the information about being intentional was just amazing, right?
Thomas Betts: There was a fantastic panel discussion. In some ways, it's the things that, oh, you hear them out loud, and they sound so obvious. Yet, companies don't always do that. You're like, "Well, why are they successful?" It's not that hard. You just have to think about it a little bit. It's not a drastic shift. When we said, "Everyone has to go home, because the pandemic," all the companies who said, "Well, everyone has to be in the office, or they're not going to be productive., they're just going to slack off at home." Then, going back to outcomes are what matter, oh, we still got our job done. Can we get our job done in four days instead of five? Focus on that, rather than I need you in the office so I can see you so that I know what you're doing. I need you in the office with other people, because I want you to bond as a team. That's what you're looking for.
The role of virtual reality and (pair programming) chatbots [42:25]
Shane Hastie: I want to call out to one of my podcast episodes this year. I interviewed a software development team, and they were all using VR environments for their collaborative work. The podcast was actually released as a video as well, because we've got the 3D video image up there. I was not in the VR immersive space with them, but the six of them were around the table. They're a the development team completely distributed, and they're using Oculus. They mentioned the specific software for doing peer programming, for doing debugging sessions. It was really interesting to see, and it's a sample size of one, but it was fascinating stuff to see. I wonder where that's going to go in the future.
Thomas Betts: I'd like to segue from there into the ... What if it's not a virtual reality hologram, but it's actually an AI that's my pair programming. Because, that was how I tested out ChatGPT. I used it instead of my little rubber duck to say, "Hey, how do I solve this problem? Here's my scenario." And, I had to explain it to a point that it could give an answer, and then it gave me the code. I'm like, "Oh, well, that looks similar to my code. Oh." And, you could ask it, "What did you do wrong? What would you improve? Or, here's what it is." Same thing that the pair programming in person was. Let's talk over the code. Let's not talk at each other. How do I have that relationship? Let me explain my problem to you, whether you're a person or an AI, as long as I get the response back. I'm wondering if the VR, that's just the seventh person in the room is the bot speaks out for you.
Hopes and wishes for 2023 [43:56]
Shane Hastie: I will do a little bit of a hint here. I'm track host for the what's next for hybrid and remote in QCon London. One of the talks is going to be talking about mmersive VR. Okay, well, we're coming to the end of our time together, so let's talk about what we as a group want to see. What would our hopes and wishes be?
More deliberate culture design [44:16]
Shane Hastie: I'll kick off with to see more of that deliberate culture design in organizations and to see some of the experiments, the four day work week, more and more organizations bringing that on, outcome focused, the humanistic workplaces. That's what I hope to see in 2023. I also hope to see all of you physically in person. It'll be great. Thomas, can I throw the ball to you? What do you want for next year?
The (AI-powered) architect’s assistant [45:53]
Thomas Betts: Sure. So, I went and reviewed last year when we did this podcast, and I said I was looking forward to in-person events, and that happened. So, I feel like one wish from last year got accomplished. So, now I'm going to go to what's going to happen next year, and we'll come back in 12 months. I think we're right at the inflection point with artificial intelligence becoming so mainstream that I can think of ... I have this role of an architect. Can I have an architect with an assistant that's not just me, and I don't have to reach out to a friend on Slack? I can just ask my chat bot for helpful information, and it can respond accordingly and help me think through and give me the ability to do my job 10X better than if I'm just sitting there, struggling trying to think of what's the next line to write.
I don't think it's going to replace my InfoQ writing, but it can augment it. I think that same type of thing, it can help augment all of our roles, and how is that going to affect everybody, not just engineers and architects? Our UX designers are using it now to figure out how do we design new things. So, I think we're going to see something come about in AI in the next 12 months that we didn't expect to see, that it just becomes very mainstream, and we all start using it. since it's sort of data, ML, AI, I'm going to hand it off to Srini next.
Harnessing AI/ML effectively and ethically for the individual, community, and nation [46:00]
Srini Penchikala: Yes, thanks, Thomas. I was going to say that. So, Yes, I agree with you. ChatGPT and whatever is the next AI solution, they can definitely do a better job at helping the consumers. But, I don't think they will replace humans completely anytime soon. I was kind of joking that they would, but seriously, no, there's always some gap between machines and programs and humans. To wrap this up, Yes, I'm kind of looking forward to how data and AI/ML technologies, how can they help with all aspects of our lives at the individual level, as well as community level, as well as national and government level? So, how can they help at all the different levels, not only in our offices, at our work, in our personal lives, and also in other areas like healthcare, the governance, and everything else?
At the same time, these solutions need to be ethical to individuals with our own bias, and they need to be ethical to communities. We'd have some communities being incorrectly suppressed, right? Also, they need to be ethical to the environment, which is where the green computing comes into the picture. I can see a lot of these, pretty much all the topics we talked about today, whether it's on the human side or on the technology side. They're all coming together to make our lives better overall.
Also, I want to mention a couple of things, Daniel, I guess shameless plugs, right? We have a e-magazine on data pipelines that we published recently. It's a great resource, excellent articles on that, what's happening in the data engineering side. Then, we also published back in August, the AIML trends report for 2022. It talks about the Transformers, ChatGPT, and other models. So, a lot of things that we didn't have time in this podcast, I definitely encourage our listeners to check it out. Finally, as Shane mentioned, QCon London 2023 is going to have two tracks. One is on data engineering innovations, and the other one is on AIML trends, again excellent opportunity to learn what's happening in these areas. Again, thank you all for the opportunity. So, it's great to see you guys, and until next time. Wes is next. Go ahead, Wes.
Technical problems are often people problems; act accordingly [47:51]
Wes Reisz: Oh, Yes. That was a great summary, Srini. Thomas, you talked about last year, about returning to in-person event. I think I mention this every year, but Daniel, remember 2019, 2020 going, "You know what? I think we need to travel less next year. That's going to be my goal." That kind of rose up to bite us, but we've been pretty accurate for our year end, what's coming up. I don't know, for me, I guess it's where I started. What I want to see is more a focus on reducing cognitive load. I really like where we're evolving with platform conversations. We talked about it just a minute ago, but off of the podcast.
But, the more technical I get, the more deep I get into technical issues, the more I find out it's about people, it's about organizations, it's about communication. The technical stuff kind of comes along, is not the hard part, I guess. So, for me, it's just continuing the platform conversation next year, building stronger teams, and being able to do more with less, and reduce cognitive load so that people are able to develop software and be happy and healthy doing it. I'm going to turn it over to you, Daniel. I know you've got some things to jump into here.
Low code, no node, and AI augmentation; bringing it all together [48:55]
Daniel Bryant: Yes, Yes, just hearing everyone talk here. One thing I was going to lean into, something we didn't talkabout today is the low-code, no-code trend that's going on. I think actually AI is somewhat ... and the ML has somewhat pushed that to the side. Because, I was doing a lot of work with Doug Hudgeon and some awesome folks in InfoQ where I was learning a bunch from him and the teams around how this is going to enable citizen developers. Many of us have had the dream for business process modeling and all that kind of stuff from when I started my career 20 years ago or so. But, I think the low-code, no-code stuff and with the rise of Zapier, and there's many other platforms out there, is going to allow folks, not just technologists, but folks to assemble a lot more workflows and business logic.
Then, I think as we're all concluding is that AI is probably going to augment that. I think technology is going to be more adoptable by more people. The interesting thing we're all saying is if we are struggling with some of the ethics and the legality and a bunch of other things, imagine we push it onto folks that don't have a CS background or haven't been studying it quite so long. I think it opens the door to, I think as you hinted at Thomas, a lot of good stuff, but also maybe a lot of bad stuff as well. So, I'm thinking, as you alluded to, Thomas, I'm a big fan of Simon Wardley's stuff. He talks about a punctuated equilibrium in terms of suddenly, you get this massive step change.
I think we're kind of seeing that with ML. We're kind of seeing that with low-code, no-code. We're kind of seeing, as Shane has alluded to, the way the world is communicating and collaborating is changing too, the virtual and VR aspect to it as well. I just wonder if next year, we could be doing this podcast and going, "Wow, what a year?" Do you know what I mean? We're wrapping all the things. We've been doing that now, but I think with the world opening back up, I wonder if next year could be a real game changer in that space.
Outro: Thanks to the listeners, and best wishes for the New Year [50:35]
I think that's a perfect point to wrap up the podcast there. Thank you all so much for joining me. Thank you, Shane, Thomas, Srini, Wes. It's always great to be in the same virtual room as you all. I always learn so much, and I enjoy hearing your insights and takes on all the different areas of interest that we have. I'll also say a big thanks to you, the listener, and also readers, watchers at InfoQ and QCon. It's always great to meet many of you at in-person conferences and also see your comments online at InfoQ.com, as well. Do be sure to pop on the website. Check out all the latest events we've got for you, InfoQ Live, QCon London soon, and other QCons. I'll say, "Happy holidays," and see you all in the new year.
References mentioned:
- The Architecture Advice Process with Andrew Harmel-Law
- ThoughtWorks’ Cloud Carbon Footprint
- The InfoQ eMag: Modern Data Architectures, Pipelines, & Streams
- QCon London 2023
- QCon San Francisco 2022 InfoQ summaries
- Business and Technical Agility with Team Topologies
- The Engineer/Manager Pendulum: Charity Majors at QCon SF
- Podcast with Kelsey Hightower - Engineering with Empathy
- Cloud Native Computing Foundation
- Principles of Green Software Engineering with Marco Valtas
- VR Environments for Collaborative Software Development
- Business Systems Integration is about to Get a Whole Lot Easier
- Building High-Trust and High-Performing Teams at Shopify in a Remote World: Jesse McGinnis at QCon SF