PREROLL: Collaboration between different disciplines in your organization can be difficult, and finding clarity and alignment on the right problem to solve and the right solution design is even more so. We approach improvement from our own (limited) perspective. We can't take into account the whole story. How is that effective? Ha! Paul Rayner's EventStorming Facilitation Virtual Workshop is a multi-day online event. It promotes collaboration between different disciplines in order to solve business problems in the most effective way. This virtual workshop with Paul consists of 4 sessions on Sep 28 through Oct 1st, 2020 from 9am to Noon in central time (CDT) each day. To register and get 20% off your ticket, visit virtualgenious.com/events, use the code VGGTC. In this highly hands-on and interactive virtual workshop, you'll learn advanced EventStorming facilitation skills from large scale business discovery to collaborative solution design at the team level. Also, Paul is great. That's my personal opinion. Once again, to get 20% off your ticket, visit virtualgenious.com/events and use the code VGGTC. John Sawers: Welcome to Greater Than Code episode 201. I'm John Sawers, and I'm here with Jacob Stoebel. Jacob Stoebel: Thank you. It's my pleasure to welcome our guest this week "Nils Norman Haukås" was born and raised in rural Tysvær, Norway. These days he's living and working in rainy Bergen, where he deletes and writes code for the digital design agency NetLife Design. In his coding work, Nils makes use of his academic background which includes user experience design, human-computer interaction, and business development. These days he works comfortably from backend to frontend, doing everything from server provisioning to optimizing SQL queries, to architecting applications, to general web development and animating with CSS. Beyond just making stuff work, he thinks a lot about software in relation to society. Our lives are mediated by software, we live immersed in it. We've become the fish swimming in software, barely noticing the water around us. Nils believes software developers need to consider the ethical implications of the software that we write and make use of. When he's not pondering on software, Nils can be found playing capoeira, reading poetry, playing computer games, or dancing salsa. Coding is a lot of fun, but there's a lot to a life worth living and doing. I would agree. Welcome to our show. Nils: Thank you very much. I'm very honored to be here. Jacob Stoebel: We will start the way we always do, which is asking you, what is your super power and how did you acquire it? Nils: So I had to give this lots of thoughts. So I eventually ended up landing on my superpower is storytelling and how I acquired it is, I think, it's like somebody makes a comment and then you look back on your life, then you're thinking like, wait a minute, that's totally something that could be a superpower for me. So and the way I kind of discovered this was when I, I was talking about how I love to tell stories and so, and my mom commented, "Well, you've always been very, very fond of storytelling." And so she talked about this scene from or something that happened in third grade in school, where she talked to the teacher of the class. And she had just mentioned, like "Nils loves telling stories." So apparently I had stood up on the chair and just told the story to the class by myself. So I'm just thinking about that. Okay. So maybe that's something that was dormant there and now I'm trying to tap more into it. John Sawers: You're working on developing that skill a bit more consciously. Is that what you're saying? Nils: Yes. So I find that if you like doing an activity, I think you can get very good at it if you try to reget get really good at it. And maybe I think it was last year, I spent some of the, like we have this budget at my workplace, we can spend it on training. And then I- even though I was quite comfortable about speaking publicly, I actually tried to invest into a course trying to like, okay. So I feel like I can do this pretty decently, but how can I get even better at this? So the trick was practice apparently that's what the [laughs] the workshop who I paid money. She, she told me, "You know what? Practicing and actually recording yourself and watching the recording, even though it can feel a bit excruciating to watch yourself for presenting." [laughs]. John Sawers: I've been there with that whole watching yourself on video thing. It's hard, but also so instructive. John Sawers: Yes, definitely. And also once you start thinking about how to present, then you can start thinking maybe you see somebody else presenting and then you notice, "Oh, wow! That was a great opening. Or that was a great ending, or I really like the way how this person was made the statement, and then just let it chill in the room almost. And then everybody is just, wow, this is an important statement. Jacob Stoebel: And you said your work sponsored this? Nils: Yes, actually. So in Netlife, we have this training budget, we have so and so much money which we can spend on whatever type of training, so you just have to clear it with your team leader, so it can be, it can be books. It can be going to a conference or attending a workshop. It's very easy to forget [laughs] forget to make use of it. So almost because in the day to day you get very busy, of course with the actual work. Jacob Stoebel: I was asking, because I would guess that that's pretty rare where there would be such unrestricted view of how training can be, but, you know what I mean? Like, there'll be like a bit there's this, it seems like there's this very wide ID, wide perspective on what could be considered acceptable training. And I would certainly agree, but I'm wondering, like how can other people make the case to their employers that, you know, something as seemingly unrelated as storytelling would be a worthwhile training in their job in software? Nils: Actually, I would say that storytelling or public speaking, I think that's extremely nice tool to have in your pocket when you're a designer or a developer or a content strategist. Because when I- As an IT consultant, I really need to convince the client that I really believe in these types of like, we should do this and not this. And also when I'm working with other programmers even my colleagues, they need convincing. So I need to always try to tell a very compelling story about how I think the software should be structured. So it's not that hard to make the case for public speaking, at least I think. In Netlife, we emphasize a lot about the importance of being able to share knowledge. So, and then being trained in public speaking, that's excellent to be able to share knowledge and also to be able to stand on maybe in front of a board room at the customer. Maybe we used up all the money because we thought this was very important to spend a lot of time on getting this feature just right and now we have to explain ourselves. And then being able to hold a good presentation is excellent. So usually we don't end up in those types of situations, but that could happen. John Sawers: Yeah. I was thinking if you, if you couch, even if, even if the training was specifically about like crafting stories or storytelling, I mean, you could very easily say that this is, you know, this is building a toolbox for public speaking, you know, nd communication that would like, I, as a manager, would say like, "Oh yeah, great. Go for it." But that's [laughs] that sounds awesome. So like, if folks are interested in that kind of thing, there's a way to make it seem relevant to the relevant boses. [laughs]. Nils: Yeah. And also young public speaking, I could say that, a developer taking a brief course in design, or maybe a designer taking a brief course in coding or a content strategist, learning a little bit of code, it makes you ask so much better questions. So, it's like you're actually saving money, you could say, by taking those types of courses. [laughs]. John Sawers: Yeah. You really, you, I mean, I guess technically is broadening the skillset, but it sort of deepens your core skillset by giving you like, that extra context of what the other people are doing and what they need out of you and vice versa. Nils: Yes, definitely. John Sawers: So in your bio, I noticed that you, I love that you talked about the fact that you delete code and write code and that you put the delete first. Cause I think that's like, for- personally, it's one of my pleasures is ripping out features, especially old ones that don't work very well. So can you tell me a little bit about why you chose to do that? Nils: Oh, I'm so happy that you notice that because as an IT consultant, we have to introduce ourselves to new clients all the time. And this is something I like to just say, because it kind of wakes people up in the room, like, "Yeah, my name is Nils and I delete code." And then people are like, "Whoa, what's going on"? And then I really like to clear out old cruft, so then suddenly the code base is just so much easier to reason about, especially in old code basis where you have a lot of code laying around, you can almost feel a bit scared to touch anything it's like, you're deep in some code mine or something, and you're looking at these type of structures and you're wondering like, are these load bearing or what? Can we remove this and make something new? And sometimes like, I remember this one occasion where I was- there was this some react code and it was doing this MapReduce filter and really juggling lots of erase. And, and I'm like, "What is really going on here?" Well, actually it was just trying to take a list of items and for some of the items gripping them. It was doing something very trivial. And I cleaned it up, and then I just actually took the commit before the cleanup, and just screenshotted it and shared it with my colleagues and ask them, "Hey people, what do you think is happening here?" And everybody was like, "Yeah, I don't have no idea." And then I posted my refactoring and it was like, okay, it was actually doing extremely little. [laughs] We can only carry so much complexity in our head. So when we are writing a feature, it's very easy to forget to do the cleanup right after completing the feature. So it's the common saying to make it work, and then you make it fast and then you make it right. I'm not quite sure who said it first, but yeah, that's something I really think about a lot. I want to try to code. Jacob Stoebel: And definitly felt sometimes when I'm looking at code and I get a sense that maybe I could, I could refactor it or remove something, but then I look at the get blame and see who wrote it. And I'm like, "Oh, I really respect that person a lot." And then I find myself second guessing if I really should be changing that, because in my mind, I'm thinking about, "Oh, well, that's what caused a conflict with that person. Or will they think that I'm, that I think that they're not good at their job." And I find that there's all these, there's all this drama that's sort of going on under the surface that I can understand why I think code goes uncleaned a lot, because I think there's a lot of tension around that. Nils: The tension part is, that's something to unpack because when I talk about the code with my colleagues, I really try to use the word WE a lot, like, it's our code, we should do this. And it's like, this code base is really tough, we should try to figure out a way to make it better, so that it doesn't go down to the level where like you did this and I'm doing this and you should do that, who wrote this. So then suddenly we're like ping ponging, blame around instead of saying like, you know, if we all pitch in, we can make this so much smoother to work in. [laughs]. John Sawers: Yeah, a couple of years ago, I had an experience around that where I had written a feature in like it was, it was part of our testing things, so it was allow us to sort of mock out in points. And I'd sort of done it all on my own and sort of just said, "Okay, this is how we're doing these things now." And then like three months later, another developer came along and was like, in like tore out a lot of it because it didn't actually work the way he needed it to work. And at one point he was like, "Hey, you want to talk about this?" And I was still in that like, Oh my God, I'm really angry. Like this has only been live for three months and it's already been thrown away, Ha, you know? And so I didn't say anything to him because I knew I was probably not going to be nice about it. And then once I calmed down, I realized that was a bad feature in the first place, cause I hadn't gotten input from anybody else when I built it. And if I had, I would have known that there were these other requirements that this person needed and built something completely different. And so of course it's being torn out because it doesn't actually, it only fits one narrow use case. And so like again, it's sort of like the whole life-cycle of like that feeling very proprietary about the code you write, and then also worrying about how other people are gonna react. But then if you sort of go up a level to the team and say, "Well, does the team need this code? Is it serving the app? Is it serving, you know, the customers?" Then, then you can be like "Well, no. Actually it's not. So let's fix it." Nils: Yeah. It's really something to grow into a field as you become more and more experienced as a program around. I'm thinking about the writers, I mean authors, when they send their drafts to editors. Those drafts, they get tear it apart and then no author just writes a draft and then that's a book. So then to see like a piece of a chapter or a lot large chunk of code being ripped out. Okay. So it should be okay. [Laughs]. John Sawers: And in fact, like those writers that get to the point where the editors are too afraid to really tear them apart, like they end up writing worst books. Nils: Yeah. Jacob Stoebel: Did you find out about your code being ripped out before the pull request was merged? John Sawers: So I was reviewing the pull request. Jacob Stoebel: Aha. Yeah. So I feel like that that happens, I think speaks really well to your team, because somehow there was a mechanism for like the person who might have strong feelings about it, got to at least know about it [laughs] before, you know what I mean? [chuckles]. John Sawers: Yeah. If it had just sort of showed up like a month later, like, "Oh this, yeah we don't do this anymore." And I'd be like, "What the heck happened?" That would have been even worse because the surprise factor just makes it, like it multiplies whatever reaction you're going to have there. Jacob Stoebel: Yeah. I think- I've been thinking a lot recently about how like, the systems that teams have for getting feedback, because there are some circumstances where a specific person really ought to review this pull request, but then how is the author going to necessarily know who those people should be? And like, that would be a really complex question, but it sounds like it was, it went well [laughs] in that scenario at least. John Sawers: Yeah. That's one of those sort of implicit knowledge things on a team. And if it's been around long enough, everyone just sort of knows these things, but if you've got a newish team or like 80% new, like new, then it's a lot harder. Cause that stuff isn't ever communicated, like it's not even written down anywhere. It's just, you just know that Bob wrote that whole section. And so like maybe get his input when you're changing [laughs] Like, [laughs]. Nils: Yeah. And and on this note, I'm thinking that the NetLife, we've had this talk about how we don't want individuals to be, to know everything about one code base to be like, the code base owner, because it's very easy for managers to think, "Yeah, this one person is really fast and nimble in that code base, so we just put that person on there forever." And then and then that person is stuck in the project and maybe the code base becomes spread around weirder, because everybody has their own type of style, how they like to code. And so that's something, we try to have a very open dialogue with our team leaders who are trying to like it's, sometimes it can be a bit Tetris trying to put designers and developers on projects and moving them and so on. But on top of that, we need to think about switching the people working on code basis. And then that forces you to like, I need to leave my implicit knowledge inside the code base somewhere, so that I can be somewhere else learning something else. John Sawers: There are so many downsides to being tied to a single project like that. Like, for like, you were saying, you sort of stagnated as a developer, like you're the only one who can fix it. I mean, sure you get things done fast, but that's because it's all your code, but it's also like a risk, right? If you like leave to another company, if you win the lottery, like you're, like then, everyone is sort of scrambling, what the heck is even going on in here? So yeah, we try an explicitly swap people around and cross train and do that as well because just, I mean, even a week-long vacation can cause havoc if like only one person really knows how the thing works. [laughs]. Nils: Yeah. MIDROLL: This podcast is brought to you by An Event Apart. For over 15 years, An Event Apart conferences have been the best way to level up your skills, be inspired by world-class experts, and learn what’s next in web design. An Event Apart is proud to introduce Online Together: Fall Summit, a three-day web design conference coming to a device near you, October 26th through 28th. The Fall Summit features 18 in-depth sessions, each followed by a live, moderated Q&A session with the speaker, plus unique one-on-one conversations with some special guests. You’ll learn about advanced CSS from Miriam Suzanne and Una Kravets, design systems and patterns from Mina Markham and Jason Grigsby, design engineering from Adekunle Oduye, inclusive design from Sara Soueidan and David Dylan Thomas, and much more. Attending An Event Apart boosts your brain, inspires your creativity, and increases your value to your teammates, employers, clients, and most of all yourself. And you can boost it even further. Purchase a Three-Day Pass and receive six months of on-demand access to their first three Online Together events. That’s six full days of jam-packed content for the price of three. Greater Than Code listeners can get $100 off any multi-day pass with promo code AEAGTC. Once again, that promo code is AEAGTC. So grab your spot and join An Event Apart’s Online Together: Fall Summit, October 26th through 28th. See the full three-day schedule and register today at AnEventApart.com. Nils: In February, I think, I asked a question to my team, which was, "Is it ethical to use technologies from companies that pay little or no texas? And implicit in the backgrounds, it's kind of like looming behind us. We are using react, which supports Facebook. We are using other technologies that support Amazon and also Google. So we internally at NetLife, we wound up at this kind of philosophical debate or discussion about whether or not it's right to use those type of technologies when the- if the companies contribute negative to society. And then some of my colleagues were like, "Well, I mean, they are large. What can you do? Let's just use react and chug out features." And then actually a colleague of mine, he was saying like, "Well, ethically or philosophically, well, we could look at maybe utilitarianism here perhaps to try to evaluate it then", but eventually with- the discussion just fizzled off and didn't quite go anywhere. But that lingered in my mind somehow this question, and I started seeing this conference call for proposals, and then I started making some pitches based on this idea. And then I pitched to NDC also with a talk called Real Rebels Pay Their Taxes, where I try to unpack this question. And I try to pull in references to ethics, to value, economical value theory. And I also try to pull in some references just to talking about tax, and all of this I do to build an argument. Well, I would argue that it's not ethical to use these technologies from these companies who do this rampant type of tax optimizations. And then this whole argument like, okay, can we somehow accept that these companies, these like big five: the Google, Amazon Facebook, Microsoft, can we accept that these contribute? They are so highly evaluated and they pay so little tax. They out-compete smaller tax paying businesses on a global scale, and they create these low income jobs maybe, especially Amazon. And then they extract value from that. That's happening in the real world while we are get cloning projects and where achieving planets scale, serverless functions. And we're really like buying into all of this hype. I'm saying that we programmers, we are not immune to fashion, so we are very enamored by everything that's new and cool. And we maybe we've lost this, we are not appreciating code that has been functioning for 20 years as much as we should be appreciating it. John Sawers: I find that the tax angle an interesting one that I haven't seen before in discussions of software ethics, like there's really obvious things like no tech for ice and the DHS and Palentier, and like the sort of obvious evils of like not supporting those sort of organizations. But then this is sort of another level up of like organizations that maybe aren't actively evil, but you, if you consider like the impact to society of not paying the taxes that they probably should be, then like that's still a negative that there's still that ethical angle to it. Nils: I referenced the economist Mariana Mazzucato a lot in my talk. And I actually, in 2018, I somehow stumbled into a keynote speech of her. And I watched her speaking live about values and economical inequality in society. And I'm sitting there as a programmer and I'm just like, "Oh my God, all this value theory hundreds of years of economical theory. And she's like arguing really well how we need to rekindle the idea that value is actually something to be debated." So then when Amazon is a very highly evaluated company, we should just not accept that at face value. Why is Jeff Bezos highly evaluated? Why is he highly evaluated and not some teacher or not some nurse instead? Where does this come from actually? So and so just, I was sitting there 2018, just like, "Oh my God, what's going on here?" And then I kind of maybe forgot about this, I'm not sure, but I was always in the back of my mind. And then in 2019, I was able to catch the last JSConf EU in Berlin. And I saw one of the last talks there was a talk by C J Silverio, who had been the previously the CTO of NPM. And she just, she had a talk called "The economics of open source". It's a long talk where she talks about this kind of journey of the NPM ecosystem. And she talks about how a lot of the, maybe the largest I mean, not the largest, but the most prominent contributors to the NPM ecosystem, they are not rich today. They are not living on some yacht somewhere. But NPM, the CEO of NPM or the owners of NPM, they are rich, but not- why aren't these programmers who contributed so much to the ecosystem rich? So then I just watched that, and she during that talk, NPM had been struggling a lot. They had a lot of kind of trouble. A lot of people were quitting NPM and also they haven't been acquired by Microsoft. So at that point, things were really hanging in the air and was a lot of unsaid, a lot of unspoken things it felt. So she had the talk and she announced the decentralized package management system called Entropic. There was just standing ovations from the audience because everybody was really like feeling like, "Oh my God, we were just sitting around there, and suddenly we have this venture capitalist funding just coming in, sailing in and owning the ecosystem. And how did that happen? What can we do?" And then she introduced this solution of creating a decentralized package management system. So that happened there. And of course later in history, Microsoft acquired NPM They kind of solved, kind of the ticking time bomb of what happens to NPM when it runs out of venture capitalists, venture capital funding. So that happened in 2019, and then just this whole narrative of value and money, and then just kind of, we're kind of hanging around in my mind. And then come 2020, then what's up with these large companies benefiting so much from open source and not contributing back. John Sawers: Yeah. I think there's an interesting parallel there that we've seen, like in the broader economy with COVID-19, at least in the US, there's been, you know, this designation of certain workers as a central workers, that that should be out there working and need to be protected. And except that all of those workers are paid incredibly poorly, right? All of the essential workers are stock people, and like counters and baristas, and like just keeping the food chain and the gas flowing and all those things and yet, they're the ones making the crap pay. And only some of them were getting like minor bumps for that. And it's the same issue there were like the stuff we can't live without is so poorly valued. Nils: Definitely. And also in our way, somebody coined the phrase called a [yam contour ADL 00:29:01??], Which is the home office nobility, the people who are privileged to be able to have a job where they can stay at home in order what they need. The argument I have in my talk is quite complex because okay, what now? What can we do about the centralization of power into large tech corporations? Well, one thing we can do is to start one thing, an alternative, if we can recognize that this is an issue, then we can start thinking about some alternatives. In my talk towards the end, I started talking about maybe we need the better licensing somehow. And then after my talk, I learned about the ethical source working group, and I learned about ethical licensing and so on. So I'm saying that, it's not ethical to use the technology from these large tech corporations. For example, if I go to my manager, and I'm saying, "You know what? Amazon web services or Google web services or Asher, that's a super neat service. Let's just put all our client services on those types of systems. We can spend a lot of time and effort to learn the technology, learn the platform and put our code there." I'm helping put thing the- if the client is paying for this type of hosting, I'm actually taking the money from the client and investing it in companies that pay very little tax. So then in an ideal situation, if these companies were paying their fair share of Texas, if they were not the multinational company able to do tax optimization, if it was just a national company, then much more of those taxes would just go back into the economy. So then you wouldn't have a lot of money piling up somewhere. There's a reason that we have a lot of developer evangelists because developers, we make a lot of purchasing options. We have a lot of say about where to host the code, what type of technologies to use, and how to move where. So if I'm arguing to my manager, like, "You know what? This new platform, we should put all our code there." It's quite hard for a manager or somebody else to say, "I don't know. I don't believe in that technology." So then, so we have a lot of purchasing power not only within our company, but also with any companies that we are helping. And thinking about how money flows around into society, it's harder and harder to look at large open source projects and not think about how money and power is accumulating with companies owning those technologies. Another example is that, we have large open source projects such as Gatsby.js, Next. js, and also Nuxt.js, all of those technologies are funded by venture capital. So to receive venture capital funding, it's kind of like, I was going to say like dancing with the devil, or kind of like accepting to have a fire lit underneath you, like, okay, we have invested so and so many millions into your open source project, you need to start acquiring. A lot of people start requiring talent and the just burn off money as much as you can just to grow as large as possible. So we're seeing that Gatsby.js has been doing this. And I'm sorry if I'm feel like I'm hounding, I get to be here, but it's just a good example, and then Gatsby.js trying to grow and grow and grow. And there's this incentive system or getting venture funding, venture capital, VC funding creates weird incentives in an open source project. It's not so much about, well, you need to optimize a lot of things, but also you start optimizing your release schedule. So suddenly you're like, you always need to like release new features every now and so often, so that you can kind of stay in the mind, share of your service and programmers out there. It's like, okay, Oh my God, they launched yet another feature and another feature. And now they're doing this and taking over the world because we programmers. We have come kind of- we've become blind to all the code around us that just work. Like, I'm sure there are a lot of very basic open source projects around us that just are mission critical, but they don't have a large marketing department, and they are not pushing out a lot of features because it's just rock solid, stable. And then on the other side, you have a lot of open source projects that are, they're moving so fast and they're, kind of like changing paradigms. So then suddenly you're like, especially with frameworks, if I'm building with a framework and then the framework do major version updates, then actually, I'm chasing the framework and I'm forced to unlearn old syntax and I have to learn new syntax. So the case in point here would be that, I have an old code base based on the Next. js 7. And then with Next. js 8 & 9, now they're moving more and more to the serverless paradigm. And they are gearing this framework to work really well with their verse sell platform. But that's not where my client is. My client is running self-hosted infrastructure. So even though we built all this code on top of Next. js, I'm thinking like, well, I shouldn't upgrade. I shouldn't buy into the direction that this framework is headed. And it's kind of a tough call to make, because we have this notion that staying up-to-date and current is the safest bet. Like, we should always update to get security updates and so on and so forth. So, it's kind of hard when the framework is trying to make money [laughs] underneath you. For instance, I would say that with Gatsby.js, again, sorry that I'm not critiquing it so hard. It's just that, a lot of people have been concerned that it's- they have issues with the build times, and now they launched a cloud offering where they have very good build times, but then this creates a kind of weird incentive that we should never make the framework faster because then the programmers are no longer incentivized to use our platform. Implicit in this argument is that VC funded technology will always try to disempower you in some way. So it's a strong argument, of course, but I would say that we're seeing this with software as a service infrastructures where you get some code that's open source, but then you interface with the backend that's close source. So then they have a platform and you can't get away from that platform, even though what you're holding in your code base is open source, you're forced to talk to some closed source backend. And then suddenly like, yeah, you lose power, but it's hard to see this because you're bombarded with very, very strong marketing. You get a developer evangelists really professing how great these technologies are. And you see them maybe some links surfacing at the top of hacker news. And then you're thinking like, okay, I'm seeing this technology a lot, so it must be great. Well, it's debatable because in the background, for instance, I've been working with the Norwegian methodological institutes for a bit, a fun fact, they're here in Bergen and they were actually the birthplace of modern weather forecasting. So a lot of budding what the forecasters say try to have a stay working at the in Bergen to be closed to where it started, it all started. So but yeah, I was working at the Norwegian metrological Institute and I was working on a 20 year old service. And as some of these people on my team, they were the people who originally built the service. And this service is extreme wave letter forecasting service, written in Pearl, I think. And it's extremely mission critical because this service combines wave and the wind data, and then generates a report. And based on that report, the people on the oil rigs out in the North sea, they can make a decision on whether or not they should move a thousand people onto the shore because there's a storm brewing. So, and it has everything to do with the angle of the waves, how the waves are hitting the oil rig, and how is this combining with the wind coming in and and so on. So then, so this is like 20 year old cold written in Pearl, and now they're finally replacing it. And it's like, you will hardly find some developer relations people talking about this type of stuff, because they are talking about all the new stuff, the cool stuff that's coming in. But then you have all this other stuff, which we are not talking about, just this kind of like boring, just works type of technology. So that's kind of lacking in the conversation about doing this. [laughs] Okay. So we have a lot of these fancy technologies put forth by lots of companies that are VC funded or otherwise not contributing their fair share to society then. So okay. So what other types of technologies can we or where do we go from here? One way, I would say like, maybe we could look at the brush, some dust stuff, the web components for instance, just a web component. It's not as smooth to work with as a react components. It's not the as polished, but web components could be not the framework, but just something you use in your code, suddenly you're not working with some framework, that's struggling to figure out how to make money. Instead, you're just working with code that's built into your browser. And then if you can move away from the framework, thinking and start thinking only in libraries, then it's easier to not be trapped by some framework. I believe a lot of framework authors, they're very idealistic, releasing stuff, putting an IT license on it, throwing it out into the world and trying to make it work. But at some point, it's going to get tough, especially if your project becomes successful. There are so many stories about open source authors who become burnt out because of their success, because it's like, you're trying to tell people that, "Hey, I'm doing this on my free time. I can't really respond to this issue." Or maybe somebody shows up at your doorstep with a lot of code, but it's code that's going to take your code-base in the wrong direction you feel. And then that's super tough because somebody else has done a lot of work on their spare time. And then you are sitting there on your spare time trying to say, "I'm sorry, but I can't really take responsibility for this type of code. It's not going in the direction I'm trying to go." And then at some point, you're like, "Oh my God, what am I spending all my free time working on?" And in the meantime, all these large corporations are making so much money from this type of open source. So I'm seeing this kind of conversations here and there where people are like burning out or trying to like, "Oh my God, what should I do?" And then a lot of open source projects then resort to getting venture capitalist funding. That's not a success, I would say. It's not a success either because then suddenly, you know, you need to start hiring people and you need to scale up, and then you're definitely not going to remain the type of project you were before you got that funding. Yeah. [Laughs]. John Sawers: I'm always suspicious the moment venture capital gets involved, whether it's in a SAS product that maybe was bootstrapped for a while, and then they get around to funding. Or like you said, in an open-source project that suddenly gets backing. Like, there's always a God! How, like what, like the incentives all get switched around and then you're no longer part of the equation as a customer, as a user. And so like, it can work out all right. But it doesn't [laughs] like it often doesn't. Nils: Yeah. And and also as a consultant, my job is to advise clients on what type of actions they should take, what type of strategies they should do with their code base. And when I'm seeing a framework, getting funding and starting to skyrocketing into some direction, then I'm kind of become hesitant to advise clients that they should invest in those types of technologies. Because then it's kind of like, yeah, you bet on this technology and it's kind of boom or bust either it becomes hugely famous or it gets maybe pick the part then sold to somebody else, maybe. I feel like almost like a carpenter when I'm talking to a client, "Yeah, you should invest in these materials because these materials are going to be great." So then in a consultant life, then I would talk to a client saying, "Yeah, you should invest in these frameworks because these are tried and true, or I really believe in the community around these technologies." John Sawers: Yeah. It seems like that there, there are a lot of pitfalls in all of the open source funding models, right? There's the like, do it yourself model, which leads to burnout. There's the venture capital model, which obviously we talked about0 there's the company sponsorship model, which can work. And I'm not super familiar with this situation, but I know there's a whole thing going on with Kubernetes. And like the fact that Google is so in control of that project, so it's like, there's all those issues there. And then like, I'm not sure what, like there's donations, which are like spotty as best as far as I know, like sometimes you get money, sometimes you don't and it probably doesn't pay for your actual labor. [laughs]. Nils: Yeah, I just, on that note, I just want to say that there's another aspect here, which I haven't talked about yet, which is how large businesses can, when they have developers working full time on their open source. They are kind of competing any projects out there because like, if I'm trying to create a competitor to Kubernetes on my free time, like I would lose because I can work a couple of hours every other night, or evening. But then you have these, you have a full team of developers just chugging along in like 40 hours a week, just trying to make Kubernetes even better. And I also make a point about this in my talk saying that, and why are we really trying to make Kubernetes a thing? Is it to just save us from learning Linux system administration? And I'm talking a lot about this type of alternative cost, because all the time we are investing in making Kubernetes a thing, is time that we're not putting into making Linux system administration better. I feel this is truly disempowering to have generations of developers growing up thinking like, "Yeah, Kubernetes is the cool thing." Yeah. It definitely I'm reading. I'm seeing it everywhere. So it must be great. Even though, maybe in the background, you have some virtual machines running, DBN with automated security updates, some Cron jobs, notifying people by email just, I mean, shout out to email [laughs] stuff that just works in the background not cool, just done. So yeah, I'm being tough on Kubernetes. I feel that we are inventing frameworks and texts for each other to save each other from learning what we should be learning, which is just fundamentals about Linux system administration or server system administration basically. Jacob Stoebel: And there's a critical mass that you can achieve by bootstrapping in an open source project, because when Kubernetes, a project like Kubernetes becomes popular enough, suddenly it's, maybe it's easier to find people who have experiences in Kubernetes compared to, you know, vanilla Linux admin, or, you know, a react developer as opposed to, you know, someone who knows everything about jQuery. And there's a lot of jQuery code out there still. And additionally, when you get big enough, you can extract free labor from others because they need react to work. And there's some problem that doesn't fit their particular use case. So they can either fork it, but no one wants to do that or they can fix it for free. Nils: You're on the right on the money there. [Laughs]. Jacob Stoebel: Yeah. Nils: Yeah, I noticed this, I was watching- I was reading about this material design react library, where this is just some people outside of Google who are- they've created a lot of react components based on Google's material design. And I'm seeing like how they are, they are working, they are getting some sponsorship on their documentation pages, and they're getting funding, but I'm reading the change log or the blog. And I'm seeing like, yeah, Google suddenly changed their material design something, so now we are just throwing ourselves around and the rewriting a lot of components to fit with the Google's change the material design something. And I'm just seeing that, and I'm thinking, "Oh man, that's so much work happening," because Google decided to change something suddenly. And it's very beneficial for Google, of course, that there are projects outside Google really trying to align themselves with what Google is trying to do. When we think about all this labor that, all this free labor we are putting into creating code that works well with Kubernetes or code that works well with react. When a new framework shows up, it's useless kind of, then we need to transplant all the good ideas we've learned from this ecosystem into the new ecosystem. And it's just so much work again, free labor that people are putting up with basically. So, but what if we, instead of building with Kubernetes we build with even more stable abstractions, such as building with DBN in mind, just, okay. What's what's up inside the DBN? What does DBN show up with? Can we somehow extend the system D to do even better things for us? And I know that a lot of Linux, new Linux folks, some are very up in arms about the system D and how system D has spread inside the Linux ecosystem. Just to say two words on what the system D actually is. Well, it's, I guess it's the hypervisor, the program that is responsible for starting and stopping services, so making sure that all the services are aligned and so on. And then instead, instead of using putting system D to greater effect or expanding on that, we are inventing, Kubernetes somehow trying to hide the Linux servers from us underneath there somewhere. But as the programmers saying goes, abstractions leak. So you thought you could just learn Kubernetes and get away with it, but guess what? Now you need to learn Kubernetes and learn DBN, learn Linux system administration. So what have you actually learned? Just to have another example here is, some years back I used hibernates with Java. So hibernate is a Java library that abstracts away the raw SQL queries from you. So instead of writing SQL to save data, you are calling these Java objects and putting objects into objects and figuring out how to do inheritance and so on, just to at some point, wind up with tabular data in a database. And then I was just, for some reason, I don't know, maybe I heard it on a podcast, but somebody was just, actually, I saw a talk by somebody who was an expert in Postgres, the Postgres database. And he was just showing, "Hey, what's new with the SQL syntax and Postgres?" So he was just saying that, Well, a lot of people when I tried to learn SQL, they tried to learn SQL standard from 1992. We have progressed so much more from there. So then it just showed some of the modern SQL syntax. And I'm just, "Wow! Oh my God! Why am I trying to debug this ORM that is writing SQL format and not stepping down a bit and learning SQL?" So now that I spent the time learning SQL, and this type of knowledge is it's like, it's timeless, it's [chuckles] almost as timeless as possible in the program or ecosystem. Like if you learn HTML and CSS, or if you learn SQL, that's the type of knowledge that's going to be extremely valuable for a long type of time. And it's like, we don't like to repeat ourselves. And we don't like to kind of just, I don't know, spend too much effort on something that doesn't give you value back. So just learning the basics, HTML, CSS, JavaScript to learning basic SQL, learning Linux system administration. It's like, you won't find developer relations people talking highly about this kind of stuff, but I feel that this is the true, like you want to get rich [laughs], learn stuff because you are going to be useful wherever you are. John Sawers: So there's one idea in here that I sort of want to unpack a little bit because it's sort of like, I'm still trying to get my head around it a little bit. And it's around the idea of using a product, we're using a tool framework project, whatever, from like, from a company or from some sort of organization that has moneyed interest for free as a form of support. Like, it's obvious when you're giving money to say, get hub that you're giving money to get hub and whatever getting up wants to do with the money that they have more power now, because they have more money, but it's a different kind of transaction when you're just using a project. And I'm curious if you could talk a little bit about how that impacts like, the company and how you're using it and how you see that connecting to the ethical implications of what sort of support for a company that is. Nils: Yes, definitely a very good question. So then we need to center our thinking around alternative costs. If I spend a lot of time learning Kubernetes, that is time I'm not learning something else. So even though I got Kubernetes for free, I download it for free on my computer. I can create a lot of cool services for free with that type of software, but, and also I can convince my colleagues and my clients to use Kubernetes, but then I'm using a lot of time on that, which I could be, which could be spent doing something else previous, like talked about these type of timeless knowledge, yeah, the HTML, CSS, JavaScript, and then the system administration. What if we tap into that instead of tapping into technology from these type of corporations, because this has a weird type of gravitational pull, because let's say one year or two years into the future where yeah, all the old school system administrators, we fired them. We only have 20 somethings who only know about Kubernetes, so now they're checking codes and the, yeah, we can't really self-host anything, but no problem, because we just put everything on Google cloud, because Google cloud is the largest vendor, or we can put it on Asher or Amazon. Even though you got all of this for free, you got all the documentation for free. It's like it is high way of power centralization, and we don't need to do that, we can take a different route. So what if we spend effort into making self-hosting super sweet instead? Or maybe we spent more time not creating frameworks, but more documenting patterns and writing small libraries that can be useful wherever they are. It's super convenient when you're inside the framework, that's kind of like boxing you in and throwing you down some happy path. Nils: Yes, it's easy, but this is the right thing. [laughs] Considering how much centralization you're getting and the, you want freedom, essentially. The freedom to maybe change libraries if you want to. Maybe you also want the freedom to not see your framework, your code goes super complex. So if you're only right, if you're writing your codes around libraries, then it's easier to change your codes and choose your way basically. And also another argument is that it stifle. I would say it stifles innovation, because we're spending so much time trying to make this type of technology work instead of trying to create smaller more atomic libraries and making them work well. And if we would create more libraries, then there would be easier to maintain. Also, it would be easier to reason about and carry on into the future. John Sawers: Well, unfortunately, we're coming to the end of our time here. So it's probably like, this is definitely a good opening conversation. There's definitely a lot more places we could go with this, but I think it's probably time to move into reflections here, which is just, you know, from this conversation, what sort of things are we taking away? What thoughts are we continuing to chew on? I'm happy to get started with that. I think for me, the idea of treating like tax avoidance as a social negative, which like, when you think about it, of course, that's obviously a social negative. Taxas are social good. But like, it tends not to be one of those things that's obviously categorized as a social negative in sort of in the context of evil things that corporations do [laughs] but it's on that list. And, and thinking of that as part of a way of evaluating a company and its ethical standing, is I think important. And it's definitely something I'm going to keep in mind, like thinking about this going into the future. And also like thinking about how companies that are involved in open source, like, what are their motivations there? Like, what are they getting out of it? Why are they putting money into it? Because, obviously, if they're putting money into it, they feel like they're getting more value out of it than they're putting into it. So there's some, there's some motivation there, and questioning that, or at least trying to understand what that is, I think, puts me in a better position to think about how to use their tools. Jacob Stoebel: I guess, I would consider myself a mid-level software developer. I've been doing this for six years now. And I think I've gotten to the point where I've been thinking more about how I've been finding myself a little bit bored with, you know, learning the next hot thing. And I've been sort of struggling with that. And I think talking with you all has made me sort of realize why that might be is, you know, I've gotten to the point where I've figured out the pattern [laughs] and like, if there's something new and hot that I need to know, I can learn the details, but I sort of, you know, figured out like the basics of how software is put together. And now I'm thinking more about like, Hmm, it's probably time for me to start figuring out, what are the sort of like the foundational technologies that I maybe have been dodging a little bit and how can I fill in the holes there? That was really good for me. Nils: Yeah. For me, well this talk, we've been talking about that's kind of the culmination of a lot of reflections, but also in this talk with you then yeah, I've kind of reflected on, it's a hard argument to make. It's kind of tough because it's almost, for me, it's to take away from this talk is that, I can do a smart practice [laughs] into introducing the problem and arguing the problem. And I'm thinking that I hope that maybe other people can build on the arguments, so the question I put forth in my talk and then create even better arguments, or maybe try to create the counter argument, so then you can have counter counter arguments, and then we can arrive at some quite refined way of looking at software. So it's reflecting here and I'm thinking that software development is still incredibly young field, I think. Psychologists maybe 200 years and they consider themselves a young field. So what is development even then? [laughs]. We're still figuring this out. Towards the end here, I thought about longevity. Can I write something today that will last 10 years? Can I write something today that my clients will think, "Oh my goodness, this is something we should take care of and safeguard or cultivate for 10 or 15 years, instead of trying to change it every three years, because then are you really getting anywhere."? [laughs]. John Sawers: You know, one other reflection that just sort of popped into the back of my head near the end of our conversation there is, thinking about like, say you're fully like bought into Kubernetes and you've built a whole system and you're like, okay, great. We've got choice. We can run this on Google or Amazon or we've got three choices of giant corporations that we can give lots of money to, which all have basically the same ethics profile to run this, like that, like those are your choices. Like, especially if you don't have the CIS admin experience to build out your own like virtualization platform where you're like, you know, it's so interesting. Like, it feels like there's choice, but when you look at the, like the ethical profile of the companies involved, there really isn't, it's like Google slightly better because they're carbon neutral and Microsoft kind of does some cool stuff and Amazon sort of hurt evil all to the bottom. And like, you know, there isn't really a choice if you really think about it. And that's also an interesting thing to sort of ponder from that perspective. Nils: Just on that note, maybe you don't have CIS admin experience in your company anymore because some years ago you decided like, "Yeah, we don't need to hire anybody with CIS admin skills anymore." Then you're a fully important to Kubernetes [laughs]. Yes. John Sawers: Nils, it's been great talking to you today. Thanks so much for being on our show. Jacob Stoebel: Yeah. Nils: Thank you very much for having me. END-ROLL: Businesses all over the world right now are trying to reinvent how they connect with the world. Whether a business is delivering packages, treating patients, or running a global customer support center, their customers need them to invent new ways to stay connected. Twilio is the platform that Fortune 500 companies and startups alike trust to build seamless communications experiences with phone calls, text messages, video calls, and more. Really, the only limit becomes your developer’s imaginations. It’s time to build. Visit twilio.com to learn more.