Johnny Boursiquot: My unpopular opinion – and I have a nasty habit of thinking my opinions unpopular, but they ended up being popular… Except that one time I actually did have an unpopular opinion. But anyways, my unpopular opinion is that - I think with the advent of these generative AI tools that can understand language and generate language and everything else, while it is easy to leverage these tools… And I speak from somebody who pays for GitHub Copilot, and I use it, and I like it… While these tools may make the act of building and writing code easier and faster, the responsibility still lies with you, the developer.

I think we’re entering an age where you are going to learn not really how to write code, but how to proofread code. Because if you can have machines, like a model generate code for you, then the only thing you’re doing is verifying that it’s doing the right thing. And right now, I find that about 50% of the things I’m generating from something like a GitHub Copilot, I have to tweak, because it’s not quite what I want… But that’s still 50% of typing that I don’t have to do, right? So it does help me and it has given me a boost of productivity, no doubt, and I’m glad to pay for it… But a responsibility of understanding what it is that it’s generating… And to me, it’s like back in the day where I would look at a website and I was learning how a website worked; I’d do View Source… Corollary here being that you can get the equivalent of View Source - you can get source code from the cloud, from something in the cloud… But it was still up to me to understand what HTML tags were, what does the p tag do, what does the image tag do, if I add this attribute to this type, what does it do? Like, you still have to understand – you’ve got a leg up, but you still have to understand what it is that you’re getting.

So just because you’re gonna get tools doesn’t mean the responsibility of said code, either the productivity, whether it’s the benefit or the chaos that ensues from you using that code, and shipping it into production, and all that stuff - you are still responsible for that code, right? And I would probably be harsher on you as a developer who commits generated code and doesn’t really verify it, proofreads it, and fix it… I’d be much harder on you, knowing that’s what you did if you actually wrote the code yourself, right? If you wrote the code yourself, I know, “Okay, it’s human error. Maybe we need better practices for code review and everything else.” But if you’re just blindly generating code and getting it in there and shipping it, then I’m gonna be much harsher on you.

Ian Miell: Sure, yeah. So I was aware that when we called this “Follow the money”, that it would sound like I was saying “Hey, you should get all the money you can as an engineer.” And that’s very much not what I’m saying… Especially when I mentioned that I worked for banks, it really sounds like I was money-grabbing. So I wanna make that clear from the outset - what I’m talking about with “Follow the money” is that… So as I mentioned, I worked in a very narrow domain, and the economic model of it was really simple; so simple it was invisible to me. So customer wanted thing, customer had platform, customer paid licenses. Customer wanted thing, customer had time and materials, and customer paid for ongoing support and maintenance. That was the model.

I didn’t think about this too much as a significant thing, but then we tried to convert to being a product company, and failed. There were also reasons we could argue about, about why that failed… But I took that experience, I had my ideas about we used the wrong technologies, or we had the wrong culture, or whatever. I took that experience and then I went to Barclays. And I’ve found that there it was far less about the technology and far more about the organizational. So I became less interested in technology, because there were better and worse technologies for any given situation… But really, what causes success or failure in these organizations is the structure of the organization, and so on.

There was a common meme when we talk about DevOps and we talk about software engineering development, that when you’re young, you think about tools. “Should I use Go, or should I use Java, or should I use Ruby…?” And people really focus on that. Then the wise old person says “No, no, no. It’s not about that. It’s about team organization, and agility, and so on.” So you get to thinking about these things. And then the slightly older person says “No, it’s about culture.” And then I’d find the conversation just stops. Like, people just say it’s culture, and you go “Okay, it’s culture. Now what? How do I change a culture?” And this got me thinking – you know, I was one of those humanities students. I came to software when I was 25, when I wanted a different kind of career. And as a humanities student, I studied modern history; I obviously read about Marxian ideas, and one of the Marxist ideas was the material base, the kind of structure of material exchange in capitalism, and so on, ultimately determines the superstructure, which is culture. This is kind of where my mind’s been going recently, because I’ve been involved in various projects where we’re looking at why things are struggling to happen, and we uncovered that the business thinks of things in a completely different way than the engineers.

[28:04] The engineers think of a platform as this continuously engineered product, and it needs constant investment, and this investment is repaid over time, and the more you build it and the more you automate, the more you get as investment over time.

But some organizations are still in this very transactional “I pay for something and then I have a thing”, and then that’s it. So getting them to think in this kind of continuous investment way and selling something that isn’t just “Oh, we had ten engineers working for a month, and therefore it costs X”, we have this thing that is of value to you, and this is of this much value, and we have to invest in it to maintain it. This kind of way of thinking comes ultimately from the way companies run their accounts, is my hypothesis. And in order to really debug an organization and why it’s struggling to move to cloud-native, or DevOps, or whatever, you ultimately end up back with accounts.

I saw this in banks, to some extent, because we were building a platform that was consumed by the rest of the business, so it was like a product, but there was actually no way for us to be paid internally for that. So we had - I don’t know how many teams - many, many teams using this platform, but the ones who were using it more than others weren’t necessarily paying more. It was very opaque; we couldn’t actually get to the bottom of how the money was moving around. And actually, the whole business was structured around yearly review cycles, yearly accounting cycles. You couldn’t say like “Oh, we have a new version of this product and we need to invest in previous cycle.” It’s like, “Well, that wasn’t in the original budget for the year.” So you can’t be agile when you have to think in yearly cycles. You just think “What are we gonna do this year? We need to get the budget for this year.” It doesn’t work where every three months the number of people on our platform is doubling, but we had no more budget to support that, so we had to borrow, beg and steal money from other bits.

These are all questions that make me think “Oh, you know what’s at the bottom of this? It’s how money moves around in an organization, and why money moves around in an organization.” If you can sort that out, or at least get that aligned with the way you want to work, then suddenly things can move much faster. Organizations that are built from the ground up as microservices typically have a different cost structure. They allocate money to teams, and they’re responsible for products.

I spoke to my CFO where I work at Container Solutions and he said “Yeah, there’s this whole thing called agile accounting.” And he was a big fan of it. He turned me on to a couple of books on the subject… It tries to overthrow this yearly cycle in favor of continuous accounting… Because that’s familiar to us, right? Continuous accounting, continuous software.

So there must be a Conway’s Law type thing here, which says that the organizational structure determines the tools and technologies you use, but what determines the organization structure? Well, one way to look at it is the financial structure. How does money move around? So you get this thing of like – you’re always getting back to money. So this is why I say “Follow the money”, because if everything is working fine, you’re getting the resources you need to do your job properly, and then it’s invisible; you don’t care. But when things are going wrong, it’s like “Well, I’m debugging…” We did the Five Whys exercise with our customer recently. It was like “Well, why can’t you allocate someone full-time to this platform?” And they said “Well, we can’t do that because they get pulled away.” “Why do they get pulled away?” “Well, because we have other projects.” “Why do you have other projects?” And we kind of went around in circles, and then eventually we got to “Oh, because your time and materials company, and you think of things in terms of built, finished, done, and not in terms of “Oh, this needs to be continuously maintained.” So the senior management are saying “The platform is finished. Why are we still talking about it?” It’s like, “No, that’s the wrong way to think about it.” It’s in the accounts is the thing and now it’s depreciating. We finished it. It’s built.”

[32:06] Once we go back to that, someone else pointed out - someone very experienced pointed out and called it. Accounts are very used to the idea of investment. If you buy a warehouse, they understand that you buy the warehouse and you have to maintain the warehouse. Amazon don’t just buy a warehouse and then think it’s done. They buy a warehouse, big expense, and then they say “Right, there’s gonna be some ongoing expense here, as we need cleaners, we need janitors, we need security etc. Or we need to rebuild a part of it, because the products we store in them have changed.”

This is all not new to accountants, they understand it… But we don’t talk to them. As engineers, we’re scared of – maybe I speak for myself, but it’s a bit like when people talk to us, they suddenly get these jargon words, and we’re like “We have no idea what you’re talking about.” It’s like for us when we get to accountants. They start talking about tax deductions, and things we’re not that interested in necessarily… And it’s very technical. But if you get someone who wants to work with you, it can be completely eye-opening.

I remember learning about the difference between cap-ex and op-ex, and I was like – suddenly, it makes sense to me why the cloud has taken off, because it’s treated differently from a tax point of view and a spending point of view. Suddenly, cloud makes a lot more sense.

So I haven’t formed this into a coherent theory yet. There’s still some thoughts sort of flying around in my head, but it’s something that I’m super interested in exploring more.

Gerhard Lazu: Yeah. One thing that we talked about previously, and I thought was a really important point, was around what makes a good developer. [unintelligible 01:12:26.29] go further, what makes a good engineer, a good software engineer. And it is not the documentation, even though that plays a very important role. It is not the code that they write, even though that has to be present. It is not how they present and how they talk. But again, that has to be present. How they share ideas, how they show into the world, and do whatever they have to do… Those are well-rounded individuals. And that well-roundedness, I can see how it translates to what is the cloud, what is the on-prem… Whatever the next thing is, you need to be well-rounded in all these things. And you should be using all of them. Because if you don’t use it, you lose it, right? Very simple, very true. It will never change.

So you should be using the cloud, but you should be using the cloud the way the cloud was meant to be used. And Justin, you made a very good point, at Disney, how you were using the cloud; possibly the best example of using the cloud correctly, right? Span out, stand up all these instances, and then tear them down. That’s how it’s supposed to be used, right? It’s capacity on demand, massive capacity. You would not want to buy that. But when you need it, it’s there, and it’s a great commodity. It is a hundred times more expensive, because that’s what this commodity costs you. Where else can you turn up and say “Hey, spin up a hundred beef instances?” That wouldn’t take months, it would take maybe years to source all of those things. And by the way - no, no, I don’t want that AMD CPU. I want that Intel CPU. Oh, ARM? I think I’m going to have some ARM. And by the way, I’m going to have, I don’t know, 10,000 ARM CPUs. Where can you get that? It’s the convenience of that.

[01:14:09.20] Now, if you know what you need, as a business that is successful, as a startup that’s successful - well, for the things that you know that you definitely need, and that’s like your baseline operating budget in terms of infrastructure, have that in a place that makes sense. Have that cheap. Have that - cheap, I say cost-efficient. Do what makes sense. Hybrid cloud.

What about WASM? What about the WASI runtimes? How do they change how we see containers and how we work with containers? Is that coming? Well, I can tell you that React did not work for Dagger Cloud. React, the DOM, to generate all the things that we had to generate, was just breaking down. The tech was not up to scratch. So what did we do? We looked at WASM v3. That’s the v3 cloud. We went through three rewrites to get it to a point where it’s as performant as it should be.

And there’s so many dragons there. Don’t think that this is like the holy place where you pick it up and everything is awesome. Oh, no. The cycle starts again. But that’s it. That’s the beauty of it. Start those cycles, keep going through them, keep learning, keep iterating… Eventually, you will be able to consider yourself well-rounded. And others will look at you and will say “Wow, I wish he responded to my pull requests. I wish he left some comments, and did some reviews, because I like his reviews. I wish he blogged more. Or I wish she went and gave some talks, because she’s an excellent presenter.” So look for well-rounded, not for 10x.

Adam Stacoviak: To quote from your Howie guide, under “distribute the findings” it says, “Your work shouldn’t be completed to be filed. It should be completed so it can be read and shared across the business even after the learning review has taken place and the corrective actions have been taken”, which is interesting, because it’s by design meant to be shared. And when you write something, you always take the reader in mind. And so the reader really is the CEO to QA, to support, to sales potentially even. I mean, it’s an organizational learning opportunity.

Brittany Dionigi: Yeah, we don’t have a lot of experts in this space right now, which is the main blocker. My number one recommendation for organizations would be go seek out engineers who have taught before, have taught at coding bootcamps or do open source education efforts and training courses, and embed them into your organization, embed them into your engineering teams to start learning how they teach, and what works well and what doesn’t, in courses that they’ve done and lessons or materials that they’ve provided online.

There’s a lot of education-based strategies, classroom-based strategies that you might learn if you had gone to college to be an educator, to be a public school teacher or any other sort of professor, that are pretty unknown to people in the engineering field, because we’ve never had to learn those types of things.

[28:13] So I think the first step for organizations is a) just being able to identify and leverage any potential learning opportunity that you can create for folks. And those happen at the organization level, they happen at the team level, and they can happen in these more one-on-one intimate levels as well.

Organizationally, I think – at Articulate, we’ve done a couple of things. We’ve recently partnered with jeli.io. They do incident analysis work. I’m not sure if either of you have worked with them or heard of them in the past… Super-talented people over there, and they helped us facilitate a lot of incident review calls, which are open to all of engineering for anyone to attend. And those types of opportunities are really great for creating a lot of consistency and predictability in a learning environment where you’re going to review an incident – and not only what happened and how did we fix it, but how did the people who were involved know what to do? Let’s suss out their instincts and how they got this to resolution. What can we learn from this? What can we learn that was interesting about the systems that were involved and the tools that were involved? And those types of opportunities don’t require a ton of in-depth –

Carol Lee: Yeah. I mean, like you said, awareness is really key. I always say, you literally can’t do something about a problem if you don’t even know the problem exists. That’s just a fact. I think it’s really interesting… I had a lot of folks who would say things like “Oh yeah, I always avoid code reviews.” And I was like “Well, do you feel anxious about code reviews?” And they were like “You know what? I think I do.” You just kind of avoid the thing, and you’re like “Hm. It turns out I am anxious.” it’s like “Great, now we know why you avoid them, so now we know what to do, which is try to reduce that anxiety.” And I think that’s a really key piece. Same thing with those biased thoughts, like “I don’t know why I feel so terrible about myself before a code review”, and it’s like “Well, you’re literally telling yourself that you’re terrible, and people hate you, so there we go.” It’s like “Oh, right. I am telling myself that.” So kind of knowledge is power here.

Like you said, reducing physiological arousal helps with things, challenging those thoughts, asking yourself “Hey, is this actually true?”

The exposure piece is super-interesting. So part of it actually refers back to what Jerod was saying earlier, where you do the thing a lot of times, and you kind of get used to it. For some people, they’re able to say “I did this a lot of times, and I still feel anxious, but I feel like I can manage it.” Or “I’m okay with the anxiety now. I’m chill with it.” And then you being chill with it reduces your anxiety. It’s very paradoxical.

[00:32:19.01] But there’s also this way in which you – like I was saying earlier, you kind of avoid thinking about the code review, and you’re just focused on getting it over with. Maybe you open the thing up and you’re like [unintelligible 00:32:31.28] and then you close it out. You’re like “It’s done. Thank God.” And so exposure here really involves “Okay, let’s practice that awareness during the entire code review.”

So folks after the workshop get a toolkit to do during their next code review, and it asks you “Okay, what is your anxiety like now? What can you do to manage it now? Okay, keep working on your code review. What is your anxiety now? What can we do to manage that now?” And so it kind of gives you practice on saying “Hey, actually, my anxiety isn’t in control of me. It’s not this thing that I have to run away from, and therefore run away from code reviews. I can approach a code review and learn” - and this is a new learning kind of theory; you can learn that you can actually handle it.

So the more that you kind of actively engage with the code review, the more that you walk away learning “Hey, you know what? That wasn’t so bad. I actually managed to reduce my anxiety, I managed to do the thing, the world didn’t end…” Cool. Right?

There’s also kind of a method here where proactively engaging also means that you’re also expressing how you feel about your code. A lot of times - and people kind of do this and they shoot themselves in the foot, where they’re really anxious about their code. And maybe they’re super-confused; they don’t feel comfortable with it. And they just kind of quietly put it out into the world, and they’re like “It’s done…!” And when you do that, people are like “Okay, this person feels confident. Let me just give them the review.” It also – I mean, it’s really hard to remember… And I say this even as a psychologist. When you’re working on a computer, interacting with somebody’s work, it’s sometimes really hard to remember that there’s a person with feelings on the other side of it. You’re like “Here’s the code. I’m going to review it.” But that code belongs to somebody, and that person has feelings, and maybe anxiety. So you can ask for a code review in a way that elicits some humanity. You can say things like “I’m just really not sure about this section. I’m kind of feeling anxious here.” And oftentimes when folks read things like “I’m uncomfortable here”, or “I’m feeling anxious”, that cues them to be like “Oh, this person doesn’t feel good. I should be gentle with them.” In contrast, when you just kind of put it out there, people are just kind of like “Nah, you should change this.” And then you read that feedback and you’re like “This person doesn’t like me.” So you can actually elicit kinder code reviews by actually sharing that you’re anxious. So I think that’s just kind of an interesting way that exposure can work there, too.

Hilary Mason: [43:47] As of today, I don’t think you can put the raw output in front of people at all, unless you’re constraining the domain in which it’s able to produce text. So I do think you could use it today for things like translating from language to code; I built a thing that writes really shitty SQL queries, and that seems pretty safe, maybe… But for things that are generating, deliberating inciting the model to hallucinate fictional worlds - it’s not safe now.

So constraining the problem space such that we’re able to manage, say, descriptions of characters and descriptions of items in a way that we can then run another layer of machine learning classification, and even in many cases human review and human feedback to ensure that what is coming out of the system beats some notion of content standards.

We also have other issues around getting what you expect. GPT-3 and other models let you dial down or up the randomness of the output, but when you dial it down, it actually ends up being quite boring, and when you dial it up, it’s completely random and you can’t direct it where you want it to go, because it doesn’t have taste. We have taste, but as far as the math knows, you’re just sort of randomly exploring a space, and any particular set of tokens is just as likely as the next one… So we need to build systems that learn and reflect that taste. I believe, at least from our approach right now, those are systems built on top of fine-tuned GPT-2 systems, in this case.

I also wanna be very clear, because we’re recording this here in August… We’re at the beginning of this work, so I can’t speak to it as if I have solved this problem. I don’t want anyone to point to this discussion and say “Oh, they did it, so it’s great.” It should be easy. It’s not easy. And I think there’s almost as much work involved in what we have ahead as there is in getting to this point in the first place.

Matar Haller: Right. There’s not an infinite number of those people, and also, we want to be very aware of their well being. We care a lot about the well being of the people that we work with. ActiveFence invests a lot in that. And so specifically for these analysts I want to make sure that I prioritize what it is that they need to review. I don’t always need – I don’t need them to review everything, right? Usually, what I would go for is I want to review the gray zone, right?

So we have implemented active learning, which is basically to prioritize what it is that we want to train on. And so that also prioritizes what it is that we want to review and to label… Because I’m always going for the gray zone, right? The things that we’re not quite sure of, that we don’t really know - that’s where it goes to the expert, right? It goes back to Chris’s question, “How do you know?” Sometimes you do know, but it’s tough. And those are the things that I want to label, because those things that are tough are what is going to feed in, and to give my descriminator the maximum power that it needs.

Robin Morero: Code reviews are really popular with a lot of people, and it quickly becomes a heated discussion. But the issue I have there is why do you do the code reviews? In terms of learning and sharing - that’s excellent. Perfect. That’s a tool you want to use, right? But do you want to enforce a tool to always be used, or do you want to use that tool when you need it? And that’s the question we have been struggling with.

Joel Grus: [24:25] That’s one angle. Another angle is that by doing code reviews you learn a lot, both in terms of having a second set of eyes on your code, that can tell you “Here’s another way you could have done this”, or by reviewing someone else’s code and saying “Wow, I never would have thought to do it that way, but that’s a cool way to do it.” So doing code reviews is a great way to keep learning and building skills and getting better at what you do. And hopefully, if someone’s a data scientist, that’s something that they’re interested in.

Mikeal Rogers: Well, I think also to Daniel’s point, a lot of the intrinsic motivation is learning something new. And when people are early contributors and they’re doing early reviews, on the outside that might seem like really menial work, but they actually are learning something by doing that. By teaching it to other people and reviewing other people’s code, it is a learning experience for them, to a point; eventually it does become just kind of a monotonous thing. The Node project relies on just bringing in a lot of new people all the time, so there’s always a new batch of people that are learning in that way, with these easier reviews that we have to get done. And the people that are really deeply technically invested in particular areas don’t have to do that work. They can focus on just the really technical reviews.

Nick Nisi: Alright, let’s take a break here… But before we do, I just wanna bring us back around to the book, Learning TypeScript, and just mention that I did get to preview it before it came out, and it’s a fantastic book, that breaks things down really well. Josh, just from having met you before and heard you speak several times, I read it in your voice as I was going through it. It was in your calm voice, explaining to me these different concepts… And the way that you broke things down I thought was really beneficial as someone who’s been doing TypeScript for a long time; it seems like a really good way to introduce a JavaScript developer to it… So I just wanted to congratulate you on that, and for shipping it this week; that’s wonderful.

We’re gonna take a break now, but when we come back, we will dig into more about Josh has been working on.

Jon Calhoun: If you don’t mind me plugging this, if anybody knows Go and is willing to give code reviews - there are a lot of people who are just learning Go and they’ll submit solutions on the GitHub page… This is all open source (their solutions), and I try to give code reviews as much as I can, but sometimes I’ll get really busy, overwhelmed, or sometimes is just nice to get another perspective in there. So if you ever do want to go give a code review to somebody who’s new to the language, I’m more than happy to have other people help, and I’ll gladly send you some stickers or do whatever else to sort of say thank you for that.

Adam Stacoviak: And now you’re in code reviewing, you’re learning.

Annie Sexton: I’m actually curious to see, as we progress, as we see more early-career developers use things like Copilot, whether that’s for a net good or a net bad. I feel kind of mixed on this, because I know that when I’m in a codebase in a language that I’m not as savvy as JavaScript, such as like a Go project, or Python - I don’t know those languages as well, so having something like Copilot helped me out with a lot of the syntax is really helpful. And I do find that I’m learning, and eventually I don’t need Copilot to suggest things… And so I think it can be a good learning tool, but I also don’t know - you know, we’re reviewing applicants, and I can sometimes see when I think this has just been generated. First of all, it doesn’t work. That’s one thing.

Jerod Santo: We’ve reached July: CrowdStrike strikes. cdn.pollyfill.js too. ZIRP phenomena are becoming apparent.

Coolest code goes to Posting: an HTTP client, not unlike Postman and Insomnia. As a TUI application, it can be used over SSH and enables efficient keyboard-centric workflows. Your requests are stored locally in simple YAML files, meaning they’re easy to read and version control.

Best prose: Programming advice for my younger self

If you’ve been following News for awhile, you know I have a penchant for blog posts about hard-earned learnings/advice we can all benefit from. You know, stuff like, “If you’re shooting yourself in the foot constantly, fix the gun.” Good one, Marcus!

Marcus Buffett finally thinks he’s a decent programmer, so he rounded up a bunch of his learnings and wrote them down with the idea of “what would have gotten me to this point faster?”

And my favorite episode of the month: Code review anxiety

I’m a big fan of Carol Lee, PhD, and a big fan of this conversation where she shared with us her research on code review anxiety. We get into all the nooks and crannies of this topic — common code review myths, strategies for coping, the need for awareness and self-reflection, the value of exposure and practice to build confidence, the importance of team dynamics, respect, empathy, and connection, and more.

Later in the year, she embarrassed everyone (except me) on our #define game show…

Ben Cohen: It’s all over Twitter, yeah. So yes, at the time, I think actually that change was proposed by Chris Latner at the time… Or maybe he was the review manager, I can’t remember. Yeah, we removed the pre and post increment operator, I think because the idea is they’re a bit of an attractive nuisance. I think if it was just a pre increment or a post increment operator, that might make sense. But having two - that should not be the thing that people encounter as they’re first learning a language, is like “Oh, what’s the difference between pre and post?” There’s all sorts of myths on the internet about how one is more efficient than the other, and things like that.

So yeah, in the early days of Swift there was a lot of rapid motion with the language. That was actually one of the things that was a bit of a challenge for the very early adopters from the Swift 1.0 days, is the language did go through a fair amount of churn. Since I think Swift 4 we actually adopted a policy where there are no more breaking language changes, except with a major version upgrade. And so basically, when we introduce a new major language version - and the next one is actually going to be Swift 6; there was actually a post to the Swift forums just a couple of weeks ago about what it means to migrate to Swift 6, and what the goal is there. When we introduce Swift 6, that’s going to be the version of Swift that introduces data race safety by default.

So we talked about Swift being a memory safe language. The one exception to that is if you have two threads, and you’ve created those two threads, and they share state between themselves. If you mutate a global object from both threads at the same time, that introduces a data race that can introduce memory-unsafe behavior.

As of today, you can opt into a strict mode that will prevent you from introducing those data races into your code. So if you have the latest version of Swift, if you download like the latest toolchain from Swift.org to try out the upcoming version, you can opt into that data race safety checker, and they’ll give you a bunch of warnings saying “Hey, this is a class. You’re escaping it by sending it from this task into this task. That could introduce a data race.” And it’ll tell you, and you can go in and there are various language techniques that allow you to do something about that; unsharing the reference, making a copy, things like that.

[47:57] Swift 6 will turn those warnings into errors, and that means that if you’re starting a new project from scratch, you can be certain that your code is guaranteed data-race free, because the compiler just won’t let you accidentally write a data race. Obviously, like all of these things, there’ll always be unsafe opt outs, where you say “Oh, I’ve got to deal with this legacy API, so I need to be able to tell the compiler. I know, I know, but let me pass this value.”

But obviously, people have existing codebases where they’ve got to ship their app, they’ve got to do an update, they’ve got the latest version of the language, they want to use the latest version of Xcode that comes with the latest version of Swift, but they haven’t got time to go through and address all of those warnings in order to switch to that newer secure mode. And so whenever we introduce a new major version, we always make it an opt-in choice.

So when you compile your code, you say “Compile with the version of the language 5.0”, or “Compile with the version of the language 6.0.” And if you tell the compiler “Compile with the version of the language 6.0”, it will stop you from making these data race issues into your production code. But if you compile with version 5.0, it won’t stop you; you can just get away with them just being warnings, and then you can tackle them at your leisure. And that’s been much better for the community, because it means that they can move forward; we don’t end up getting into the classic Python 2 to Python 3 situation where people are holding back… And you can also do that migration at the module by module level. So you can break up your code and say “Okay, this bit of code I’ve audited, it’s good. I can go to Swift 6 mode. This bit of code - maybe I’m going to do that next month, but in the meantime I need to ship my app and adopt it. Stick with Swift 5 for now and then adopt Swift 6 maybe after I do that.”

Kirsten Lum: Yeah. And so that education point - it’s very hard; I used to say this quite a bit when I would review resumes… There is a primacy to delivering results. Anything else when you’re reviewing someone’s resume, a lot of times that’s the output of kind of all of the inputs in the resume, what results have been driven. That can tell you a lot about how well do they manage projects, how well do they work in a team. All of those things kind of ladder up to delivering results. And so when you think about earning trust within a small organization, thinking about delivering results as being the output of earning trust, doing your work well, training your models well, having good relationships with the people along the pipeline - that’s what will really point you there. And once an organization sees those results, it’s actually very tough – you’ll have more work on your plate than you’ll know what to do it. That’s what I’ve found.

Paula Kennedy: We pour a lot of our learnings from the last seven years into our tiny three-person company… So we are regularly having objective and key result meetings to review, and we have regular board meetings to plan what’s the next three months, what’s the next three years. The interesting thing is that, you know, plans change; the plan is the plan, that’s why the plan changes, as we like to say…

Wanny Morellato: [39:48] We give the same feedback. Even for us, when we run our own infrastructure - like, we are an open source friendly company; we have a lot of open source software that we use. And like you said, the upgrades are very critical, so we do like every quarterly check to make sure if there’s versions that we need to upgrade for these specific ones… And there are breaking changes, right? So we start with the change logs; there are teams that still have these kinds of [unintelligible 00:40:10.06] we were doing an upgrade two weeks back, to 1.2.6, and then we found there are teams that had very legacy versions, like alpha one of [unintelligible 00:40:19.08] So we do that check. We do that check to make sure what are the APIs that the teams leverage, which is pretty old and deprecated, and then we tend to work with them. So then we go to them and say “Hey, we’ve found out this is problem”, we try to work with them. For me, we just send PRs to them and say “Hey, we’ve found this one. It’s very stable now [unintelligible 00:40:43.06] you might have missed it”, so we are helping you there, get it up.

And then there are cases where we have to upgrade some critical ones, and that’s the most tricky ones. That’s where we kind of trust as the dev environment, we do like end to end tests to make sure – like, in some cases it’s a breaking one, and you have to migrate off. So that requires an old and a new one, so you have to have dual versions of those entities… Let the application shift over to the new ones… Like, for example the external secret operator. There was the old version and the new version, so there were breaking changes that they have to make in the application [unintelligible 00:41:17.07] So we work with them, we do help them how to zero downtime migrate with them. That’s another way we deal with them.

I think the operator was the main thing… And the other one, like you said, because Kube, you have to do it like every three months or four months. Now, there are certain things that we go and help them in the service reviews, like help them to configure [unintelligible 00:41:38.18] budget. So when we recycle the nodes, the data plane nodes on the Kube side, we guarantee you we’re not going to cause any sort of issues… Because these are like customer-serving services, so anything that we cause here is going to have a cascade effect to our customers. So we try to educate them, we try to evangelize them the benefits, and we try to use our learnings and self-apply, which is something we also do with customers also… Because in the end, these abstractions are the same. Customers also have the same thing. So we dogfood certain things when we do kong upgrade ourselves and say “Hey, we’ve found this one.” Now, sure, there are customers who are doing the exact thing, and we give early feedbacks and stuff like that them to those.

Angelica Hill: No, it was awesome. And I would say you did much better than I did; last year when I was asked to help organize – as Kaylyn and Johnny and Kris all now, I’m someone who likes to be planned. I like to be over-prepared. I come with a lot of notes and a lot of preparation. Some may say a little bit too much preparation… So last year, I came into the planning being like “Right, what’s the roadmap? What’s the timeline? When are our deliverables? When are our milestones for getting GopherCon done?” And the wonderful other organizers are very good at getting very organized amongst chaos, is the best way that I could put it. And I was not fully prepared for that. This year I think I was more ready for that…

But to answer your question directly, Kris, I think GopherCon all started with getting ready for “How do we want to do this this year? What do we want to do differently from last year when we were in Chicago?”, taking kind of cool learnings, etc. and then trying to start getting people to submit papers, etc. To me, it felt more streamlined than previous years, but that might just be because I only started organizing last year, and before that I was part of the CFP process, which is like a lot of reviewing papers, a lot of reading through things… But also, I just think that Heather specifically, who helped organize it, is just very good at saying “This is what we’re focusing on right now. Don’t care about anything else. This is the to-do thing for right now.” But I’d be more interested to hear your experience, Kaylyn, honestly, coming in.

Angelica Hill: And I would +100 that. Bring it back to basics. Check your grammar, check your spelling, make sure that it reads well… Because your proposal is gonna be the first interaction your reviewers have with your style of writing and your structure… And if I see a proposal that is beautifully written, structured well, they’ve clearly put a lot of thought into their word choice, their grammar is on point - I’m gonna have a lot of faith that that talk is gonna be crisp, polished, beautiful. Slides… No punctuation errors, no spelling errors… A lot of thought is going to go into that talk.

[48:03] If I see a really interesting topic, a really great proposal, but there are spelling issues, punctuation is all over the shop, the structure’s not great - that’s gonna lead me to believe, whether it’s true or not… When you’re giving your talk, the image that I get in my brain is a little bit of like someone who has all those great ideas, but it’s just like babbling on in a not very structured way, leaving that audience very confused. And honestly, as someone who tends to do that, I am often the bumbling ball of excitement that just babbles about everything… People don’t get all that much when I give talks where it’s just me getting excited about something and babbling on. Yes, they’ll be like “Oh, great! That made me feel happy! I felt the excitement, but I didn’t learn much.”

You wanna make sure people come away from both your proposal as a reviewer and your talk as a viewer excited, empowered; they can see you excited about your topic, but you also want them to take away tangible learnings, and therefore you have to go back to those basics - structure, punctuation, grammar, using the right words.

William Nichols: It’s a little bit of history. So I worked with Watts for a number of years. It’s a part of what got me to go to the SEI. And I took the personal software process – it was really part of teaching developers how to plan and manage their work, so they could work on an industrial project and know how to talk to their management, negotiate schedules, bring the projects in on time… And the two key things we taught were estimation and quality.

The main things in quality were applying design techniques, then showing them how to do disciplined reviews of designs and code, so that you’d find your defects before a test. And what we tried to do was show them “Hey, you can actually write a program and you can get this to compile the first time, without getting compile warnings.” Now, in the days before IDEs, that was a big thing.

Nathan Sobo: [00:12:00.16] Yeah, yeah. We’re playing with setting thresholds. You can commit a threshold that would potentially fail the build. We’re being pretty conservative with those right now, because failing builds are annoying, and I think we’re still kind of traversing the learning curve on all of this, quite honestly. But what we have is this new – yeah a new experience where you can define tools, either pull them in via MCP… We’ve got a set of core tools that the agent can use. And it’s an environment that’s more optimized for just like having the standard conversation with an agent, where it’s able to reach out and do things.

And so getting that UI in place, getting it nice, the checkpointing for which the CRDT stuff has been dope to have, the review experience for which the multi buffers that we’ve invested in are really great… Like, seeing everywhere that the agent did the editing. And kind of the overall chrome around the experience - we’ve got that in place, and then used it to start collecting data. Having collected the data, that is driving into “Alright, how do we make sure that we can prompt this thing and define the tool prompts and define the system prompt in such a way that things are going to be effective?” Make sure our tools are really unit-tested. I mean, all of that is like traditional software engineering to a T, other than this – other than the golden retriever.

John Long: Yeah, I mean, I would describe it, if you haven’t done it, as very much like working with someone who is fast at generating drafts. ChatGPT writes better marketing content than, dare I say it, most marketing people I know, that are kind of doing that in their day job.

So if you’re not using it kind of as your drafting system – and I think there are certainly times where you want to slow down and just write out what you’re doing. But think about your positioning, and get all of those things figured - those kinds of documents on the marketing side, you need to spend time writing that. Write about your angle, all that kind of thing. But then once you have that, why not create a custom GPT and let it write your drafts for you? You can give instructions about the style that you want it to compose in…

And for me, I’m one of those people that can come to the blank page and I don’t know what to do, kind of thing. And it’s not that I can’t get there, it’s just it takes me like 40 minutes to write my first rough draft. So ChatGPT will shortcut that for me, so that in five minutes I have my draft, I can go back and forth with it a little bit, and then I jump in there and edit it myself, because you know, it can’t quite get what I want it to do.

So there’s a lot of sort of back and forth, and I have some of these chats where – you know, it depends on what I was doing. I think the documentation one, the most epic thing that I did was to do a full walkthrough as kind of the documentation. So it was a full walkthrough of the product, and that was a ton of back and forth with ChatGPT. First, I had it write the outline for what I wanted to do, and then I took the outline, major point by major point, and asked it to write the content, I would review it, I’d say, “No, that’s too long. Make it shorter.” I would tell it when it got things wrong… Because it’s really good at reading in between the lines, but sometimes it will say things that aren’t true about your product, too. So you have to hold it accountable. But I don’t think that’s any different from working with a writer on things.

[00:08:40.01] So it’s really interesting… My perspective on the GPT is they’re here to stay, whether we like it or not. But learning how to work with them, whatever your role is - if you write marketing content in your day job, if you’re a developer that needs to write marketing content, what whatever it is, they can definitely increase your throughput. That would be the way that I’d describe it. And you can do things in days now with GPTs that used to take weeks to pull off when it comes to writing.