Quincy Larson: Yeah, so I would still encourage people to start with web. And the reason why is about half of all developer jobs are web-focused… You hear about mobile app development, and really that is just a mobile app skin on top of a bunch of APIs that are running on the web, and stuff like that. You hear about a lot of machine learning, and things like that. And it’s true that machine learning is distinct from web development. I could talk about the big changes we’re making to the curriculum… But I would say that the skills that you learn, like data structures, algorithms - everything you learn while you’re learning to be a full stack web developer, virtually all of that is transferable. Almost everybody’s going to need to create some sort of website, or some sort of mobile app, or some sort of integration with an existing platform through an API, that serves whatever it is that they’re creating… Whether they’re creating data science insights. Most data scientists have to deal with data visualization. They have to figure out how to get what’s in their Jupyter Notebook or wherever it is they’re crunching the numbers, they need to figure out how to get that in a place where people who are making decisions based on those data can consume them, and understand them.

So web does touch pretty much everything, and that’s why I recommend starting with that. A lot of people would say “Start with systems engineering. Software systems engineering.” And learning how C works, because everything is built on top of C, and doing the classic computer science degree program work of building your own compiler, building your own operating system, building maybe your own search engine, maybe building your own LLM… Doing all those things. And then a lot of people would say you should just focus on machine learning, because that’s the future. Everybody’s going to be telling the machine in English what to do. And I’ve written a lot about this in my book, and I do believe that in the future programming will consist of talking in natural language, highly structured natural language, to a computer, the way that people on Star Trek talk to the computer and the computer builds things on the holodeck, and those things like that. But that still requires knowledge of the different layers of abstraction below. And in order to effectively get things done with technology, to some extent you do want to understand how that technology works. And I think a lot of people do have a decent understanding of how RAM works, how motherboards work, how hard drives work, how buses work… A lot of the actual computer engineering stuff that software is operating on top of. And we can certainly get a much more higher resolution understanding of that by looking at the underlying operating system kernel, and things like that.

I will tell you what the freeCodeCamp curriculum is doing… But in general, I do recommend – if you’re not sure where to start, start in web. And then work out from there. And don’t feel like “Oh, websites are – nobody uses websites anymore.” That’s just the tip of the iceberg of what web development is. Gaming… Any sort of field where you’re essentially writing software, there’s going to be some component that travels over the internet. And so a lot of those principles. So without belaboring that point any further, I will tell you where the freeCodeCamp curriculum is heading.

Spencer Kimball: Well, a lot of what I’ve been talking about I’d say is understood by still a small audience. That’s something to always keep in mind, that crossing the chasm thing. I think that the large pool of developers out there - and there’s ten million of them in the world - the majority of those have probably never even heard of Cockroach. That’s also interesting. I imagine people that listen to your podcast are closer on to that innovator side of the bell curve.

The thing that I think might be extremely interesting, that isn’t necessarily obvious from what I’ve already talked about, is just what we think the 2020s holds in store for even a developer at a startup, or a developer at one of the Fortune 500 companies, and Fortune 10 companies even… And that’s really not just a database that’s serverless, but an entire stack above that database. If you really wanna build an application the way that Facebook or Uber or Netflix builds them, so that wherever you do get customers around the world, you can give them what feels like a local experience, it’s more than just a database. The database is clearly a foundational layer in the stack, but you need to have an execution layer as well above it. You’re certainly gonna need additional systems that are also global; you’re gonna need global DNS and global load balancing, and so forth.

[01:04:15.11] So really what’s on the horizon for us is “How do we partner with the clouds, with other technology companies that are complementary to what Cockroach Labs is doing, in order to define the next generation of stack?” You remember the LAMP stack, which really drove a lot of the innovation in the aughts and beyond; the big question for us, and I think what’s extremely exciting, is the emergence of a stack that allows a startup or a Fortune 500 company to build the way that Google builds and operates services and applications.

I think that’s where a lot of our thinking, and I’m sure a lot of the thinking of all of our contemporary peer companies is going to be directed in the next five years. And part of that I think is 5G, interestingly enough. It’s pretty unusual that there is a significant improvement in latency in communication networks. It’s much more common that you have significant improvements in bandwidth. Latency improvements happen somewhat infrequently, and they usually herald quite a bit of innovation. So I think the widespread adoption of 5G in the next five years is going to mean that applications, especially on a smartphone, can feel substantially different than they do today.

I think everyone’s pretty used to hitting a button on a smartphone, and maybe a second and a half later something changes. That is a pretty bad user experience, but it’s just one we’re all used to. Ultimately, you want that to be the 100-milisecond rule, as popularized by Google Gmail, and now more recently Superhuman, which is another email application. And 100 milliseconds is the threshold for a human noticing something as taking time or being instantaneous. Less than 100 milliseconds is instantaneous.

So if you can actually adhere to that latency end-to-end, in other words you hit a button on your smartphone and you get a response all the way up to the backbone, into the – across the backbone, to wherever the data center is, through the application logic, into the backend database, and then all the way back out, that roundtrip time, less than a hundred milliseconds, you can give people real-time experiences. And obviously, for gaming, interactive media of all sorts, self-driving, AR, VR - these are obvious use cases, where this kind of latency guarantee is transformational, maybe even necessary…

Spencer Kimball: [59:58] Well, a lot of what I’ve been talking about I’d say is understood by still a small audience. That’s something to always keep in mind, that crossing the chasm thing. I think that the large pool of developers out there - and there’s ten million of them in the world - the majority of those have probably never even heard of Cockroach. That’s also interesting. I imagine people that listen to your podcast are closer on to that innovator side of the bell curve.

The thing that I think might be extremely interesting, that isn’t necessarily obvious from what I’ve already talked about, is just what we think the 2020s holds in store for even a developer at a startup, or a developer at one of the Fortune 500 companies, and Fortune 10 companies even… And that’s really not just a database that’s serverless, but an entire stack above that database. If you really wanna build an application the way that Facebook or Uber or Netflix builds them, so that wherever you do get customers around the world, you can give them what feels like a local experience, it’s more than just a database. The database is clearly a foundational layer in the stack, but you need to have an execution layer as well above it. You’re certainly gonna need additional systems that are also global; you’re gonna need global DNS and global load balancing, and so forth.

So really what’s on the horizon for us is “How do we partner with the clouds, with other technology companies that are complementary to what Cockroach Labs is doing, in order to define the next generation of stack?” You remember the LAMP stack, which really drove a lot of the innovation in the aughts and beyond; the big question for us, and I think what’s extremely exciting, is the emergence of a stack that allows a startup or a Fortune 500 company to build the way that Google builds and operates services and applications.

I think that’s where a lot of our thinking, and I’m sure a lot of the thinking of all of our contemporary peer companies is going to be directed in the next five years. And part of that I think is 5G, interestingly enough. It’s pretty unusual that there is a significant improvement in latency in communication networks. It’s much more common that you have significant improvements in bandwidth. Latency improvements happen somewhat infrequently, and they usually herald quite a bit of innovation. So I think the widespread adoption of 5G in the next five years is going to mean that applications, especially on a smartphone, can feel substantially different than they do today.

I think everyone’s pretty used to hitting a button on a smartphone, and maybe a second and a half later something changes. That is a pretty bad user experience, but it’s just one we’re all used to. Ultimately, you want that to be the 100-milisecond rule, as popularized by Google Gmail, and now more recently Superhuman, which is another email application. And 100 milliseconds is the threshold for a human noticing something as taking time or being instantaneous. Less than 100 milliseconds is instantaneous.

So if you can actually adhere to that latency end-to-end, in other words you hit a button on your smartphone and you get a response all the way up to the backbone, into the – across the backbone, to wherever the data center is, through the application logic, into the backend database, and then all the way back out, that roundtrip time, less than a hundred milliseconds, you can give people real-time experiences. And obviously, for gaming, interactive media of all sorts, self-driving, AR, VR - these are obvious use cases, where this kind of latency guarantee is transformational, maybe even necessary…

Daniel Stenberg: Well, of course, there have been some obstacles and points in time when I kind of ripped out a lot of junk and redone things internally, but I would say that I’ve never considered to change language. And of course, that’s me being old and grumpy and coding C… But I also think that a big explanation for curl’s success is that it’s massively portable. It builds and runs on just everything. That also helps everyone to use it on anything. And I don’t mean just Linux and Windows and Mac or whatever, but every imaginable [unintelligible 00:25:21.29] gaming systems, or embedded systems - everything. I kind of like that, and that’s also why I’ve never considered to change the programming language.

And when it comes to things like architectural decisions and how I made things work internally - we’ve actually been able to change that to a pretty large degree internally over the years, without any significant rewrites, just ordinary development and just changing things over time.

Johnny Boursiquot: Well, we’re not gonna drag Duarte through our interesting package management history in the Go community. It’s safe to say that the module system that we have now - it’s not everyone’s favorite, but just like gofmt, everybody pretty much loves it at this point, only because of the standardized nature of it. Well, maybe “love” is a strong word, but it’s good enough, it’s good enough. And it gives you sort of a reproducibility and a lot of other benefits.

But to your question, having a github.com base domain name with your GitHub handle - and it’s not just GitHub. It’s GitLab, it’s BitBucket, whatever your code repository tool of choice is… Basically, it makes it easy for the go get command to know exactly “Where do I go and grab this particular package?”, to pull it down and store it in a local module cache. That way I don’t have to keep pulling it down every time I do a build, basically.

[00:34:03.04] And when you are looking at code, literally you just copy and paste this package path into your browser, and to the repo you go. So it makes it easy – there’s so many benefits to having the path. It provides namespacing, there’s not going to be any conflicts, as to naming conflicts… Maybe you have two packages named foo; if one’s under a particular github.com/username/foo, that’s gonna be very different. Just by looking at it you know it’s going to be unique, because there’s no two packages that are gonna have to have the same naming, and you don’t have to jump through hoops to do any funky aliasing or anything like that to know which one you’re dealing with.

So there’s a lot of benefits to doing it that way, and one of the things I try to teach developers is from the get go, when you first install Go, if the install doesn’t create it for you, you should create it yourself - there’s gonna be a Go directory that gets created under your root username account. So if you’re on a Linux machine or something like that, under your home there’s gonna be a Go folder that gets created. And this is where I typically tell folks “Look, when you download any packages that you do a go get, there’s going to be a PKG folder that gets created under this go directory for you”, and this is where all the module cache lives. This is where anything that you download that you don’t vendor - and we can talk about vendoring if you’d like - is going to go into that particular module cache.

And then from there, you can create an SRC directory where you put your code. So I create an SRC directory, I have a github.com subdirectory, followed by my jboursiquot GitHub handle… So I have this the hierarchy that allows me to basically say okay, anytime I’m looking for code, or anytime I need to check out code, or fork a repository, whatever it is, I need to bring it locally, I just go into my go src github.com slash whatever username slash project name. So it simplifies everything; I know exactly where to go look for the particular source code for a project that I’m working with directly, and I know exactly where to go in a module cache to find the module code I’m looking for. And even when I vendor my dependencies in a particular project, in my vendor directory, there’s a hierarchy in there; there’s a github.com, followed by user name, followed by whatever project that I’m relying on as a dependency. So it just keeps that consistency across the board. And I can even use multiple versions of the same dependency, because the module system follows a semantic versioning mechanism.

So I know it might feel a little odd, it might feel weird at first, but trust me, we in the community have been burned… Not burned, but we’ve gone through some hardships, and we understand the value of what we have now. It’s not perfect - obviously; nothing is - but it works well enough that it creates that predictability and that reproducibility for our builds.

Abi Noda: Yeah. We’re definitely not a consulting company. We don’t come in like McKinsey and do an assessment, so that I can give you some decks to the C-suite… I mean, there could be a world – I mean, McKinsey does do that. They actually do exactly that, for developer productivity. But we don’t do that. We do provide a tool that people can use.

First of all, I should say that this whole – this DevEx team, platform team is kind of like the new DevOps and microservices. I mean, it’s an industry trend outside of our company and what we’re doing. I mean, thankfully, we’re benefiting; I’m speaking as an entrepreneur here, but… You know, there’s a real trend right now, with the rise of platform teams… Team Topologies, that book - really influential. DevEx just becoming this thing… But I mean, when we started the company, Adam - this is at the beginning of 2021 - we call it DX, for developer experience. I wasn’t sure if developer experience was – you know, it wasn’t really a term back then. But we used it at GitHub… We’ve used that, but I was like – so I was like “I hope this becomes a thing. I hope developer experience becomes a real thing.” And it has. Not because of us, just because of industry wins.

But what we see most mature - when I say mature, I mean most tech organizations with 150+ engineers have a team that is – I mean, they might be called… Who knows what they’re called. The naming is interesting. There’s a lot of variance there. But there is a team that’s working on something internal-focused. It might just be like “We’re just trying to fix our builds, because builds are way too slow.” That’s really common for a lot of these companies.

Alex Russell: Yeah, I’m reminded that engineering disciplines that kind of survive maintain their social license to operate by not naming their operators on a regular basis, right? [laughs] And you get there lots of different ways; you get there through labeling, maybe, you get there through training, lots of training… Most serious engineering disciplines involve a great deal of training. And I think it’s fair to say that we’ve made the front end so complex now that anyone who can hack it writing JavaScript in a kind of complex frontend today can easily train to learn CSS and HTML, and the basics. So I think that we have a skills gap, not a capability gap at some level.

[46:04] But then, as you were sort of focusing back on the product side, we have a gap in appreciation for evidence. So I hear an overwhelming sort of assertion that the developer experience is now significantly better than it was before. And I just keep waiting for someone to prove it… Because the teams that I work with have astonishing build times, sometimes. I’ve seen teams with 40-50 minute builds, 2-hour builds, for a website. For a website. Right? And that’s on modern hardware, that’s not on the hardware that we were building several thousand or a million page websites out of in 2006 or 2008, right? That’s on SSDs. Disk got 1000 times faster in terms of latency. That’s astonishing.

Shawn Wang: Oh, Jesus… That’s a very general question. Wow. So I tend to think of it in terms of radiating circles out from the product. I’m gonna stretch it to four, not three. So the first thing I always think about is products design. API design. Sweating the things like naming, and sweating the things like “Okay, is this product ready for release?” Some of the most impactful things that we did as developer relations at Netlify was to say no to launches. Like, “This thing is not ready, guys. Hey, we’ve gotta call this off.” And it’s unglamorous work, you are nobody’s friend, but you’ve gotta do it. It saves the company in the long rung.

Stuff like that, getting really involved in API design and product design to make sure that everything else down the road goes much smoother. So then you radiate out from core product into something that’s maybe like first-party media channels. That’s where a lot of developer relations comes in, which is very much like how do you evangelize the products, whether it’s from positioning, from doing a lot of talks, doing a lot of learning materials and docs as well.

By the way, no amount of developer advocates can overcome bad docs. You do wanna sort of get that in that first circle, as well. The second circle of this externalist community. The really engaged users that help people go up the ramp… Because there’s only so much of introductory material and workshops and blog posts and talks that you can do… And once they get past that initial stage, there’s often a big lack of content. So you wanna really think about that end-to-end developer experience, you have to provide a community where they can ask and answer questions… But even more than that, start to really build a reputation.

[43:53] They come to this community for answers about that general field. Sometimes I really like this area to be about category creation. A lot of companies’ forums are just glorified support channels, and that’s not really inspiring to hang out in. But if that’s the place where you talk about news and talk about “Hey, there’s this interesting paper that came out. Let’s talk about it”, then it becomes a real community.

For me, the litmus test of whether or not it’s a community versus a support forum is “Do you expect your relationship with this company to outlast your current employer?” The other metric is like “Is it many-to-many, or is it employees-to-people?” Once you have a kind of self-sustaining many-to-many connection, I think that’s a really good community, and that enhances the experience, because people can really connect and get help and get things going and collaborate.

And then finally, I think for me the last group - which I haven’t really solved yet. So this is just me thinking out loud, okay? It’s third-party content. It’s the third-party ecosystem that’s building on top of you, that has nothing to do with you. They just think it’s a good idea for them to associate themselves with you, because you made it such an appealing place to be in.

So you might want to lump that in with community, but this is more about like people actually building careers, writing their books and blog posts, and doing trainings, and workshops, or whatever, with none of your involvement. But it builds that huge third-party ecosystem that we really go after in sort of a late-stage technological adoption. That’s what people say when they are like “Oh yeah, yeah, you choose this technology because not only the core technology is good, not only is the company around it good, but the third-party ecosystem is vibrant around it.” That’s kind of what you’re looking for there.

Mark Erikson: The thing is, the docs showed a pattern of organizing your different types of code into different files, and then organizing those files into folders by type. So you have a reducers folder, an actions folder, a constants folder etc.

A guy named Erik Rasmussen actually came up with a pattern for putting all the logic for a given feature into one file, which he named the Ducks pattern. A small segment of the Redux community adopted it, but we didn’t officially suggest it. And I always had a couple concerns about it, particularly about how it kind of suggests that only one reducer can never handle an action of a given type, when really the intent was any reducer can respond to any action.

So given that these are specific pain points that people talked about, how does Redux Toolkit try to address them? The docs say that I created Redux Toolkit really to solve three different problems. It’s too hard to set up a store, you have to add a bunch of extra packages to do anything useful, like Redux Thunks, and Reselect and whatnot… And it requires too much boilerplate code.

Item one, Redux Toolkit has a function called configureStore, that is a one-line call. You provide either the reducer function you’ve already built yourself, or the slice reducers for the different features, and it will assemble them itself. It automatically sets up the Redux DevTools’ browser extension setup that is needed, and it automatically adds the Redux Thunk middleware, and in development mode a couple of dev check middleware that will throw errors if you do things like accidentally mutate any state in the store… So protecting against by far the most common mistake that people make when using Redux.

From there, there’s a couple of utilities like createAction, which generates action creators based on a given type string… And createReducer, which allows you to define reducers using an object look-up table syntax rather than a switch statement, because for some reason a lot of people really hate switch statements.

And createReducer also uses this Immer library inside to let you write what looks like mutating syntax in your reducers, but it’s actually turned into safe, correct, immutable updates internally. So from there, we have an API called createSlice, and we’ve traditionally used the word “slice” to refer to the reducer for a single part of your Redux state. For example, if I have a blogging app with state.users, state.posts and state.comments, the users reducer and the users actions represent a slice of your state.

[31:55] So createSlice builds on createAction and createReducer. You give it a set of reducer functions in an object, and you give them meaningful names. Giving the classic to-do app example, todoAdded, todoToggled, changeFilter, stuff like that… And it automatically generates the action creators and the action types internally, based on the names of the reducer functions that you provided. And this actually gets to that grepability factor that you were asking about earlier.

One of the advantages of having all those action types as const variables in the codebase was that you could look at the Redux DevTools and see “Okay, I dispatched the Add_todo” action type, and now I can Ctrl+Shift+F, search the whole codebase textually for uses of that action type.

Well, we’re actually now recommending that people use a naming pattern where the string is lower camel cased, and you define it as domain-eventname. For example, maybe the domain is todos/todoadded, rather than upper screaming snake case AddToDo.

Johnny Boursiquot: I say worry about it a little bit, just the right amount, and whatever that is for you; that’s gonna be a sweet spot that you have to find. For example, my sweet spot is I define – now I’m working on a project and I have some sort of a binary as a work product. So the first thing I do is I open up the project, and then I go and create a cmd folder, followed by the name of the project; that way when I do my builds I get the right name for the executable… And I create the main.go. My main.go - my objective is to keep it as thin and light as possible.

So at that point I’m like “Okay, from this main.go, what am I gonna call in? What [unintelligible 00:09:20.18] the rest of the application which is basically providing the package naming structure. What am I gonna be pulling in? What do I need to actually start doing work from this main.go?” And obviously, in main.go, this is where I’m sort of reading options, arguments being passed in, if I have to do initialization or configuration reading from the environment, wherever they’re coming from - I’m doing all that in there, and basically trying very hard to keep any sort of business logic out of that main.go. Then from there, once I’ve got a starting point there, then I basically come out, if you will, of that main.go, and install the rest of the package.

In the past, I used to follow an approach whereby I’d create a pkg folder at the root level of the project, and then start to create things in there as well. I’ve sort of gotten away from that model. Basically, I try to keep Go files at the top level now… But I’ve gone back and forth, and it’s not a wrong way to do it; it’s just a slightly different way to do it - you package up all your go files in their own directory. This is usually useful if what you’re building has a bunch of different assets in there. Maybe you need to produce some HTML, and CSS, and JavaScript. I don’t like all that stuff being right next to my Go code, so I might create a pkg folder for that. But other than those slightly nuanced things, basically I start with that main.go for the executable, and I work my way up from there.

Rhys Arkins: Yeah, sure. One quite interesting thing is that the tool behaves basically the same as the app. The app is actually a thin wrapper around the tool; there is no fork going on or a different behavior. So you could basically uninstall the app and go back to self-hosting. All the pull requests you have open and things like that will still be valid and updated, and so on. So pretty much everything I’ve described covers both the tool or the app.

The way it works is at the base it runs on a schedule, and I normally recommend to people one hour, but some enterprises run every ten minutes… And it scans this repository for package files that it understands, like package.json, Dockerfile, Meteor, package.js files, Google’s Bazel builder as well… And just recently we added NVM, RC and travis.yml files, because people wanted to be able to upgrade their Node versions in sync, and they can actually – Node versions can be found in many different places.

So it scans for all the files, it extracts the dependencies that it finds, it applies a cascading config to it, which gives you a lot of power, but also complexity. And then, based upon how you’ve configured it, it looks up updates and determines what you should be made aware of. It builds a list of “Okay, this is what we need to do.” It checks what’s already there, and if anything needs updating or creating, then it does it. And it actually does this by keeping all the state in the repository, so the tool itself you could say is stateless, in that it doesn’t need any state file which could be corrupted, or out of date. It actually uses GitHub’s Git repository and the list of branches that have been created or pull requests that have been closed, and it basically uses that as its state.

The naming of branches and the naming of the pull requests becomes quite important, because they kind of become like look-up keys. So yeah, it just runs… One difference in the web app is that it’s been web-hooked, so it listens to GitHub webhooks for every repository it’s installed on, and if that webhook event looks meaningful, such as the person has updated a package.json file, or they’ve updated their renovate.json file, then it runs again on demand to update it. Then it’s quite nice, because if people edit their dependencies, all their pull requests get updated if necessary. If they change their config, then again, everything gets updated if necessary.

[27:46] Then it also has a listener for npmJS, so it basically gets updates or notifications using a kind of subscribe notify approach of CouchDB. So it gets updates whenever any new package is updated. We do keep a little bit of state, but it’s in a way unimportant state. It looks for any repositories that had that dependency the last time they ran, and if so again, it puts them in the queue. That means that if a package you depend upon on npmJS gets an update, then you can expect to see a pull request within minutes. This gets particularly helpful when you have multiple repositories that belong to the one organization or the one project.

An example is in GraphQL - there’s a lot of GraphQL repositories using Renovate, and the Graphcool guys, and that’ll often do an update in one upstream repository, and then that flows down to a downstream one where it needs to get merged, and that might flow down to another one. Thanks to the webhooks, it means that that can be done in minutes. It’s almost like an alternative to the monorepo, because at least you’re not having to update it manually, and it happens within minutes. That’s a little value-add onto the app that you can’t really do in a stateless command line tool; it would need to be alive and listening and you have to make sure it doesn’t crash and all that kind of stuff that I take of with the app.

Gerhard Lazu: And unless that expert is willing and open-minded to change his perception and to learn with you, it’s for nothing, all that expertise. You can’t transplant ideas, you can’t take guilds or squads or whatever you wanna call them and make them work in your company as they are. That doesn’t happen, and that’s not how it works. And whoever tells you that’s how it works, I would take it with a grain of salt, or two, or three.

David Kaplan: It’s a good question, and I definitely think most engineering leaders struggle with this. You get to a point with people who are very good individual contributors, and how far can somebody go in their career without ever expanding out. I think there’s a lot of nuance, to be honest, because there’s so many skills involved, so it really depends on a case-by-case basis.

Here’s part of my belief - you don’t need to lead some big initiative. There are some skills that people don’t enjoy or don’t ever want, whether it’s presenting, and leading meetings, and things like that. But you don’t need to be that type of leader to produce original value. That is what I expect. So you can do that independently, or you can do that as part of a group. You can be the one engaging in synthesizing the solution.

Part of our career rubric focuses on product focus. This is also part of our identity, we say that we create good product engineers. What we mean by that - and this also goes back to Marty, so I’m stealing from Marty Cagan… He says “If you want innovative products, then you need your designers and your engineers to be involved with synthesizing the solution.” That’s on the product side - don’t have the product manager come to the engineer with the solution, have him come with the problem that the customer wants solved. Then they can find the right way to solve it.

I think the same thing goes in these guilds. Maybe the leader is not even the one – I have some guilds where honestly the leader is not the thought leader, and that’s totally okay. Some of the people that are actually the staff on the guild are the ones coming up with the solution ideas. It’s a different skillset. But I do expect that. Only executing somebody else’s vision I don’t think you’re going to go super-far in your engineering career.

Kim Crayton: Every industry starts with associations. Why don’t we have associations? Why don’t we have guilds? Why don’t we have something that people – just like this conversation we’re having; you said we need to start with the conversations; we’re not having the conversations, and we’re not having the conversations in volumes enough and scaling enough for people to understand this.

I tell people all the time, I understand why the Google Manifesto guy was upset, I totally get it. He was being required to do stuff that he absolutely did not sign up for and did not want to do, and this is why his case was thrown out with the employment people, because what you did was not violate that, what you did was violate the company policies, which is when you sign that contract, what you said on using your company’s equipment caused a problem for your company. That’s why you got fired, not for what you said; it’s how you said it and how you did that.

Why do we force people who have absolutely no desire to understand unconscious bias, to force them? It’s not changing anything. We need to have these honest conversations. I need to hear him, or people like this. What about this do you not think is good for the bottom line? This is why I said I don’t even talk about this from “This is the right thing to do” - no, this is about business.