Johnny Boursiquot: So when you talk about bias, Steve, you’re worried about… So if I say “Hey, write the code, Gen AI. I write the code that turns on the faucet when I put my hand under it. When you detect a hand, turn on the faucet.” You’re saying that if we have biased AI and a person with enough pigmentation puts their hand under… If the training data only includes people without pigments in their skin, the moment I as a person who is heavily pigmented puts my hand under that thing, if it doesn’t turn on, that’s bias. Right?

Jerod Santo: Another one that I haven’t quite – he hasn’t freemiumed me yet, but he’s close… It’s Ben Evans, whose newsletter I subscribe to for years, and he just recently added a premium tier, a paid membership to his newsletter. And what he does is he’s an analyst, so a lot of why you read him is, first of all, the links, but also his analysis of why this is interesting stuff. He’s a technology and analyst; he used to work for Andreessen Horowitz, so he’s like a startup guy. His paid tier is two things; the first thing is he releases it two days earlier, which for me, I’m like “I don’t care about that.” Again, maybe some people are like “I want in first.”

I think in his case, some of his tips are like “You can probably make some money knowing that before other people.” If his analysis is correct, you can maybe make some market moves, so maybe there’s some advantage there… So there’s that, and I think that’s a small thing, but it’s a thing. I know some people like early access. For me, I’m always like “I’ve got so much content… Whenever it comes out, it’s fine”, but that’s just me.

[35:46] And then the other thing he does is he actually writes an essay every week. So his free newsletter is all of the stuff he was doing in the past, two days later… And then his premium newsletter is all the stuff he was doing in the past, plus an essay that only paid members get, and it comes out two days before. So it’s similar in terms of yours would be like members-only screencasts, and his is a members-only essay. But now you have a new job, right? Your new job is write essays once a week, or make a screencast once a week… So these are things to experiment with, but it’s not like turning on a faucet. You’re giving yourself more work, and maybe that’s – if that’s something that you already wanna do, then it makes total sense.

Kris Brandow: I do feel that there’s sometimes electricity in that, because you know, you have those obnoxious handsfree faucets that have to have some amount of electricity for the sensor, or whatever. So it’s kind of like that, it’s just adding some LEDs instead of some sensors.

Jerod Santo: [01:04:09.04] Right. And the stakes are higher. Of course, with Auth the stakes are high, but now when it’s like plug an LLM into your life, every facet of your life, whether it’s your bank account, or your FourSquare account, or whatever your Square account - when there is a vulnerability, there’s just so much opportunity for bad actors that definitely we’ll see some trouble.

And it’s a brand new thing. I mean, I think Anthropic came out with it back in November, and of course, they had the task of getting other people besides Anthropic to actually adopt the protocol… Which - it was open and I think designed to be not an Anthropic thing from the start, which is a great way to get it going… But here we are in April and it seems like - will it be the protocol to rule them all in this next age of agentic things? Not sure, but right now it seems like it’s got a lot of momentum behind it, and it quite possibly might be. And so it’s going to be vulnerable until it gets robust. I mean, that’s what happens. You have to face the real world for a while, and find all the obvious things, and work out the kinks.

Beyang Liu: Yeah, so there’s two things here. One is the context awareness, building that in as a first-class citizen. I mentioned that we were first to market for that, and we actually have a way of delivering that really effectively into the enterprise. Sourcegraph has been self-hostable for many years now, because a lot of our early customers were very large enterprises. And so we’ve built all this DNA around delivering the best context for human developers in the form of code search and code navigation into all these different deployment environments… And we can essentially offer those same context fetchers as a kind of game-changing tool or capability for LLMs, as well; any sort of AI code generation or question asking.

[01:04:01.08] The other facet of this is just the security and compliance requirements that a lot of these larger enterprises have to comply with, or are constrained by. So in terms of being able to deliver something into a purely self-hostable environment, I think we’re basically the leader in being able to do this. Even Microsoft, or Copilot, with all their enterprise branding, there’s still components of their infrastructure that have to be tied to their Claude… And that essentially rules them out for a lot of, frankly, the largest software engineering organizations in the world. They’re ones that you haven’t heard of, but they’re literally powering half the economy, and they have very stringent security and data privacy constraints.

Adam Stacoviak: I think you hit the nail on the head with the word facet there. I think that’s what it is, is like perspectives and facets within an ecosystem. It doesn’t have to be “Oh, what is the latest feature that’s being scrutinized?”, which there’s some in the Go world… What’s the latest feature? What’s the latest release? How does that work? I think it’s more about the culture of being a developer that I think shows are more interesting around. I know that you’re steeped in this cloud-native go world where that is very much the way things are… However, I also want to know why you think the way you think, or how you react to a certain piece of news that affects every developer, to some degree, shape or form.

[22:09] I will say, however, I am totally unschooled on Founder Mode. I have purposely not – I’ve heard of it, I know it’s out there, I can assume what it means, but I have not read the essay. I have not even read Bryan Cantrill’s response to it, and other people kind of like jumping on the bandwagon of it and how great it is… I’ve only been on the peripheral to know it exists; I do not know the details of the essay, and I have not begun to listen to this episode either to hear y’all’s perspective. So just to put my card out there, I am non-steeped in Founder Mode.

Jake Shirley: Yeah, I was going to mention – I was going to say versioning. I mean, even just little things - like, we wanted to change how often we pump… Like, how often we resolve promises. It turns out people were using await null to defer to the next frame always. And so like, “Oh, well, we have to version that now, because if we pump those multiple times a frame now, all that stuff breaks.” But I’m not going to say versioning, because Raph already said that. I would say an interesting challenge we have now - and we’ve always had this, but I think we’re taking the API surface a lot more seriously these days… An interesting problem we have now is trying to create a cohesive developer experience, where scripting is just a facet of it.

So how do we combine these data definitions that people have used for a long time, and traditionally tried to stuff a bunch of logic into, which we don’t love, and how do we combine that with something that’s a little bit more sane for logic, like scripting? And then how do we – just all the different areas. How does that play with Minecraft commands? How does that play with all the other developer tools that these creators can use? And how do we make sure it’s kind of consistent from the developer experience, from the documentation? Does it affect the player at all? So all these different kind of bigger picture things that lets us zoom out a little bit from scripting, which Raph and I have worked very extensively on for the last couple of years… But now we have the opportunity to zoom out a little farther and say “Well, how do these play together all up?” And does it make any sense for these kind of overlapping features to exist? Should one be the authoritative source of how to write logic? Should one be the only way to write data? So stuff like that I think is really interesting.

Johnny Boursiquot: I think you’ve just described perfectly why we have DevRel, why we have developer relations. We love to give them grief, or people to – we like to get on our high horses and say “Oh, developer relations people - they’re not real programmers, they’re not whatever.” They serve – and that’s just ego speaking. A lot of us make people feel less than, so that we can feel better ourselves. And that’s a thing. That’s called being human. But when we sit down and think deeply about exactly what you’ve just said, there’s the need for that technical leader who’s just going to look at the raw data… But like you say, Kris, it’s not just about the raw data. If you just looked at raw data – I mean, you can look at raw data and you can justify anything good or bad by some lens; you can justify anything with data. But there’s another aspect to this. There’s the “Well, how do people feel when using this particular tool?” Take, for example, the Go tool chain. We’re getting more and more opt-in telemetry that the Go tool chain is going to now start sending. So every time we do a – whenever we use the Go tool chain in the command line, some telemetry is going to be captured and can be sent back to the Go team for analysis, to help really remove the – maybe we’ll say “Well, this thing sucks. Nobody ever uses it.” Well, we can actually go to the data and see “Okay, well, actually, no. It is used pretty heavily, and it’s part of tons of workflows.” So we have the raw data.

Now, one can say “Okay, well, we have the raw data, we know people are using it, but how does it feel to use it? How usable is the tool?” Do they use it in spite, or are they using it because it’s a great experience and things of that nature? And that’s something that a developer relations person, somebody who’s not just looking at the technical aspect of things, somebody who’s not looking at the raw data… Even though that role can also go and get more data to make their point, to validate their point. Basically, they are the ones that are in between, that are basically interfacing with the community, and gathering the sentiment around using a tool or the language, and the features. Are the features working, not working? How do they make people – do they bring people joy in using?
[00:27:51.20] I remember being back in my Ruby days, there was such an emphasis on the joy of writing Ruby. I see a little less of that in Go, and perhaps, who knows, maybe every community has their own quirkiness, if you want to call it that… In Go we’re less about the developer joy and more about the simplicity. Our vernacular doesn’t include things like “the joy of writing Go.” It’s more like the simplicity, and the straightforwardness. We favor certain things in this community.

But you need that person or that set of people that is going to be able to be in underground, with the people using the tool or the technology or the programming language, and then report that back to the Go team. Who’s looking at the raw data, but also didn’t need another facet to look at in order to make decisions. They can’t just be about the data.

So I think you’ve just nailed the whole problem on the head. We need somebody - and hopefully, again, I don’t know Austin and Cherry styles of leadership, but if they can provide that balance between the two, I’m sure there are other people on the Go team, hopefully, that can also step in to help provide that kind of a role. Not sure what we’d call it. Is it developer relations? I don’t know. Maybe it has a different name for it on the Go team, but we need somebody like that who’s going to provide it. I think the closest thing we have now… What’s his name? I think he’s the actual product manager for the Go team.

Adam Stacoviak: Maybe one more facet is how do maintainers get paid? How easy is it for them to extract the dollars from the donation, from GitHub Sponsors?

Christopher Hiller: Not just that, but the who’s extracting value, right? If I go and contribute to Node, I might get a salary, but businesses build huge businesses on Node, and make a lot of money. So that’s also another imbalance, right?

But the sum, when we talk about the sum to so much of the work… Another facet, of course - and this was alluded to earlier - was that the sum is mostly like white dudes, or Asian dudes… Not a whole lot of women… And I think that has tremendous impact on a) the culture itself of open source, but b) the software that is getting built. I’m wondering, Paloma, if you’d like to speak to that side.

Tiago Queiroz: Yeah, I think in the case of working with Elastic, it’s a very interesting case of debugging in production, because – well, we don’t have access to the users’ environments. So basically, we’re only relying on logs, and asking people “Hey, what have you done?” So that’s where you actually see two things - the power of actually having good logs, and also you see the other side, that logs can be too verbose as well. Like, you have some applications, and if you enable log debugging and it has a very high throughput, then sometimes you get like 100 megabytes of logs, and it’s like three seconds of execution, because it’s just too verbose for some stuff.

So yeah, I think definitely debugging in production has this facet of - sometimes you actually don’t have access to the environment, and more often than not you’re mostly relying on logs and metrics, and that’s all you have. So you’re basically, let’s say, looking to the past. Okay, something happened, I have things that point me to what happened in the past, not right now. That’s different from debugging locally, or even – usually, in staging you have more control of the environment.

Adam Stacoviak: …which kind of gives a different facet to it.

Ali Spittel: People aren’t tweeting about it 24/7, so it falls out of the front of your brain, I guess. But then they’re still doing stuff, they’re still building a tool that’s clearly going to help in some facet of the industry… And maybe it’s not going to be overnight that everybody’s moving from their Node Express apps to Deno, but it seems like for building really complex things, that need to be really performant, like deployment pipelines, maybe Deno’s a really great option.

Adam Stacoviak: Yeah. Well, that speaks to the maturity we talked about earlier though, right? Like when you said, how has open source matured over the years? I think that speaks to the maturity of it, because Brett’s perspective from what I recall in the post is his contribution to Python itself. Whereas your all contribution to Forem is different than his contribution to the same open source commons that we all lean upon. So it’s a facet, totally. But I think that speaks to the maturity, because a GitLab or a Forem, and the commercial aspect of it - you know, you still have the software and it’s still licensed permissively. You have AGPL V3 license. I could take that software today and go commercially use it. There’s probably some copyright conditions I have to adhere to, but for the most part, if I contribute to it, I can also take your software and do something commercial with it as well.

[50:22] So it kind of depends… I mean, licenses play a role in helping that line and being crossed too, because what makes open source open source is, one, I would suppose OSI’s blessing of the license… But then, two, its permissiveness, and its restrictions.

Angelica Hill: I certainly think that if you’re going to one guy in a basement, that should cross your mind as something to check in on. I think that’s a great question; I would like to say everyone thinks that through, but I don’t think they always do.

I think what you’re both touching on - I think Kris you’ve touched on this, in terms of relying on dependencies that might not be there in the long run, and Johnny, you’ve touched on this in terms of people, even if it’s a big company, changing things; maybe they fix a bug that you’re unaware of, that you were relying on, or they changed that ethos, or the way that they want you to use that product… And I think that’s another interesting area to explore, is around the fact that you’re giving up control when you’re relying on these external, bought solutions, in a way that perhaps you should really bring into the equation in a big way, because you are then relying on external people to make sure that your infrastructure is working the way you want to. You’re giving away a facet of your overall technology that you could control and you could have complete ownership of.

[20:12] So I think certainly in my mind - which goes to kind of evaluating what you eventually want it to do - certainly when I’m having conversations around “Should we be building this? Should we be buying it?”, is this something that it’s really important that we have full control over, full ownership of? Are we gonna wanna have the flexibility to tweak it, to change it, to innovate on it at a pace, 1) that is gonna be sustainable? We don’t wanna be pinging a ticket every two seconds to our external dependencies and following up on PRs, following up on “Hey, have you done this feature update which we’ve put in three years ago, that we really need?” Because then you eventually - personal experience - get to a point where you’re like “This was a great solution, but they’re just so slow. They just don’t get back to us, and we actually should just build this ourselves, even though it’s more time at the front.”

When we have full ownership, we’re gonna be able to iterate faster, we’re gonna be able to have more personalization, we’re gonna be able to just completely be in control. I see you smiling, Johnny…

Jerod Santo: Thank you. You thought I was shallow, but it turns out there’s one facet…

Johnny Boursiquot: I do have to acknowledge that all things being equal, if you are capable of sitting down for 30 minutes, an hour, or two, for really a decent chunk of time to consume content, that’s great; then it’s just a matter of – I don’t wanna call it willpower, but your motivation to sit down, like you’re saying, Kris, sitting in that pain, pushing through that pain, because on the other side there’s a payoff. But I do wanna acknowledge that for some it’s not easy. Perhaps it’s some sort of a reading disability, perhaps it’s ADHD, whatever the case might be; I don’t know enough about these challenges to speak to them.

I’m hoping there are solutions out there for those who struggle with these things, to be able to take advantage of what we’re prescribing here today, that deep consuming of documentation to achieve expertise… But that’s something I do want to acknowledge. If folks in the Go Time channel know of any resources and things like that that they wanna share, I’d love to be able to put that out there for those who could benefit.

I do want to switch gears slightly back towards the Go documentation, because we haven’t yet answered Eric Miller’s query… “How do I, coming from other languages (in his case it was Python), where the documentation is more narrative in nature…” - and that’s the kind of documentation you can sit down and read cover to cover… And I’m not saying it’s some sort of nice romance novel, and you’re gonna be happy with it at the end or whatever, but it is much more readable than our documentation, the GoDocs, which are more reference-like; not storytelling, not reading content… It doesn’t lend itself well to cover-to-cover reading. So what can we do in the Go community to make some aspect of Go documentation - I’m not saying “Let’s blow up GoDocs and reinvent it.” I think there’s an opportunity here for complementary documentation, that makes for a more readable facet to the body of documentation we have.

And yes, there’s tutorials, and blog posts, and things like that, but there’s different kinds of documentation, which I’ll touch on in a bit… But any ideas, any first impressions of how we within the Go community could make our content to our documentation more consumable?

Mireille Reece, PsyD: [20:16] Yeah. Well, motivation is to have comfort, but I have to say, there’s a myriad of things relative to that, because our experiences or biases or ways in which we’ve been conditioned relative to comfort or discomfort is also a facet of that. I mean, who has the same pain threshold or motivation? Well, everybody’s had different experiences, everybody’s got a different personality, genes and on and on, and so recognizing that discomfort is a part of that, but that discomfort, to some degree, is learned, assigned. If I believe–

Mireille Reece, PsyD: And tolerance is a facet of addiction; you need more to cultivate the same effects.

Mireille Reece, PsyD: Well, the DNA is what makes up who we are. So it is our genes. I don’t want to do too much of a deep dive into that, but genes are sort of like this building block for who we are. So when things go awry, it’s sort of like – you’ve heard of certain abnormalities like Trisomy 21, the 21st chromosome has this third aspect to it, which looks like what we reference as Down Syndrome.

So there are these genetic abnormalities, which are fixed, and you’re not going to undo. But we also aren’t just subjected to what we’re born with, because we know this in terms of, for example, alcoholism. People who have – we know that there’s a genetic facet or component to alcoholism. But just because you have it in your family line, i.e. a family building block, it doesn’t mean that then you will be an alcoholic.

In the same way with mental health - we can say “Hey, this is in my family lineage. There’s people in my life who have this”, but it does not then mean that you will in fact have that same issue. Does that make sense?

Jerod Santo: [20:18] Let me add a little amen to that. I think you’re hitting on some of the right strokes. And myself as a developer - I’ve definitely had an adverse reaction to certain forms of marketing in my life… And I think it comes down - one facet at least - to authenticity, which is something that I value very much, and I think many developers do. And there’s something about a personal brand that feels inauthentic, because it’s as if you’re doing something for this public face, versus something you would naturally do. And like you said, there’s this ickiness there. In the past we called it reputation – I mean, it really is about your reputation, right?

Chris Benson: That’s exactly right. That’s another thing worth calling out - in the last few months, the U.S. Space Force has been created out of what had been the Space Command in the United States Air Force. So we’re now at a point where it made sense to separate those out as their own concerns… So I think you’re gonna see autonomy in every facet of transportation, sooner than most people might expect.

Adam Stacoviak: If we had to facet my skillset, one of my biggest skillsets is sales, and just relationships and partnerships; I love that kind of stuff… And I’d mentioned Reese Brothers and doing telemarketing - well, I’d always like to help people. I think sales is really just trying to help people solve their problems. It’s not about getting Jerod to buy something he doesn’t wanna buy, with money he doesn’t have… It’s about he has a problem, I can help solve that problem - that’s sales to me.

It’s kind of a long story, but I’ll make it really short - I had a friend who was trying to be a DJ… And we were at a club, early in the day, kind of like seven o’clock… time it’s borning at the club. It’s not the time you wanna be a DJ. So we were there, I see him talking to this guy at the bar, I see him go back and do his thing… And I go over and introduce myself, because I’m like “If you’re a friend of my friend, you’re a friend of mine” kind of person. So I went over and I introduced myself and said “Hey, I saw you talking to my buddy Donald. My name is Adam etc.”

And long story short, this person’s name was Sean Hughes; another person that I would love to see again and thank… Because that day I was at the crossroads of like what I was doing, which was basically nothing. I had no real ambition at the time. I was like “Well, I’m really hating what I’m doing now, and I’m thinking about getting into car sales.” So car sales, right…? I love selling, people need cars… I can help you solve your problem by getting a great car, whatever. But car sales is generally not the most fun sales job. It’s got just a lot of eekiness to it, so to speak. It doesn’t have a great reputation for being a great job. You can make a lot of money, but it may not be the best job for you.

Long story short, I mean Sean, and he’s like “Don’t get into car sales. I’ve been into car sales, it’s terrible. Don’t do that. I’ll tell you what - come in on Monday (this is Friday) to my office. You sound like a great young man, you’ve got a great head on your shoulders… I’ve got something I’m working on at a company called Muzak. I’d love to interview you for this thing we have going on.” So that’s another huge moment in my life where I went from no direction to direction.

I go in on Monday, meet with Sean… It’s a great office, it’s a legit job, where you’ve gotta dress nice, and you’ve got a computer… I mean, I’m not talking to a POS (point of sales system), or… Which - there’s nothing wrong with that; it was just the next direction for me… Because at the time I was a server. I was waiting tables, doing that kind of stuff in Orlando. Making good money because there’s lots of hospitality around that area, but… This guy hired me into this position; it was an LAPD program, Leads, Appointments, Deals, Proposals. And that’s what it was all about. I was basically inside sales for account executives… And I learned the ropes of this business.

If you haven’t heard of Muzak, if you’ve been into, say Old Navy, or a Banana Republic, or any sort of like upscale retail environment, they put the sound systems in, they put the music in, and that’s where I learned how to do a soundtrack to evoke an emotion. I started getting into user experience, his whole aspect of design, and stuff like that… Muzak had a really good brand design…

Marcus Edwards: I certainly can. Actually, my link to quantum physics and quantum computing really is Dr. Ghose. I attended Wilfrid Laurier University in my undergrad, in a double major in computer science and physics. I originally joined that program just because of the interest in the fundamental problem of information science and computing, and wanting to get into the physics of it. In that exploration, quantum mechanics was the most interesting facet, and it sort of felt like that’s where people were asking the most fundamental and ground-breaking questions… So I started working with Dr. Ghose in my undergrad, doing a directed research study, and getting involved that way.

It was actually Dr. Ghose who encouraged me to continue on with it, and that’s why largely I’m at the Institute for Quantum Computing now, doing my grad studies. I guess I also am a bit of a technologist, so I’m currently a front-end team lead at DelphX Capital Markets Inc. where I’m doing full-stack software development. So having some of that more practical technology experience and bringing that together with the quantum physics is really exciting to me; that’s sort of where quantum machine learning comes into it… And we’ll go from there.

Emma Wedekind: It’s kind of twofold. That’s definitely one facet of that - it makes everyone’s life easier if your components that you’re incorporating are already accessible, responsive, whatnot. That takes a lot of pressure off the engineers to do the heavy lifting for every single component they need. But the second part is at the end of the day we’re not delivering a library, we’re delivering a consistent experience cross-platform, that’s accessible to everyone, and I think that’s the real benefit of having a design system in place - your users, regardless of who they are or their circumstances, all have a great experience across all of your platforms. And that’s the benefit that you really should be getting out of these design systems. I’m very fortunate to be in a position where I can enable that and facilitate that.

Gregory Kurtzer: I always ended up landing in Vim, and I did most of my development in Vim, so I feel the pain, and at the same token, I was always really happy to help people get out of it. From the perspective of an outsider, here’s the lead developer, the project lead, helping somebody with these extraordinarily basic questions, and I think that is absolutely necessary. And if it’s the fifth time or the tenth time or the hundredth time that that question gets asked, it’s obviously still an issue; you should still answer it. If you just did a Google search and just looked through their logs and the archives, you’d be able to find that, you know, I’m sorry; it’s a pompous response, and it’s not very welcoming.

So I would always be very supportive, very appreciative of everybody that came into the group, whether they’re developers, whether they’re users, and set the tone right away as that, and set it from the top down. I didn’t tolerate people that became the jerk mentality. And it’s nice to see that many more open source projects are adopting this behavior, but I feel as though it was a critical facet for what makes a good, strong community, and how do you develop that strong community and keep it on track.

I’m not sure if that completely answered the question, but that’s been my experience with open source communities, and leading them and running them.

Nick Nisi: That’s a really interesting facet, because it tells you that most people are not just writing raw JavaScript.

Paul Frazee: You know, a lot of what we do right now has mostly to do with “Let’s find out how much we can get out of the Dat protocol.” So it’s a lot of features structured around that. There’s a couple of things we’ve done that are outside of that, that are just things we like. I added a markdown rendering at one point, because I was just like “Everybody likes markdown, and it’s crazy that browsers don’t render it already, so let’s get that in there.” Actually, that kind of is the guiding principle - what would make creators happiest? That’s sort of what we stick to.

[24:09] With Dat, what that ends up meaning first of all is the kind of two biggest things you get out of that is the ability to create a website by pressing a button; it amends a public key, and that becomes your new domain, and now you have a website you can share. The kind of secondary facet of that is that you can go to a Dat website and copy it, which we sometimes call forking the website… Because it’s almost the exact same thing - you create a new public key, you take all the files off that website you wanna fork, you duplicated them over to your new website, and boom, there you go, you now have a version of the website that you control. So it’s a forkable web now, which is pretty cool…

Then after that, it’s a lot of web APIs, so that you can read and write files on these Dat sites, and also watch the files for changes, because it’s a real-time, mutable networks. That ends up becoming the basis of a new application stack for building web applications that don’t require any kind of server, and hopefully don’t require any DevOps. You can just publish it, and it goes out and uses people’s own computers to run.

Suz Hinton: Yeah, I definitely think that that’s true. It’s this sort of hidden facet that you might not have noticed, and then it’s another sort of shift in how you approach designing and also writing code, for sure.

I think what’s really illuminating especially is watching humans access your site in ways that you don’t personally do so on a daily basis. I think that all of these automative processes are really great, with testing and validation, but I think that nothing really replaces sitting down next to somebody, watching them use your website with a screen reader, watching them use your website with just one button; no keyboard, just one button, cycling through elements on your page…

Or even just trying to access something like a video when they’re deaf. Just watching somebody do that and feeling that awkwardness, and just sitting there cringing, because they’ve stumbled upon something that’s not working can just be incredibly illuminating, and I think that it should be a necessary part of your cycle if you’re able to do that as well, just because that can really inspire action in you, when you are seeing the user on the other side of everything struggling to use something…

And they can really show you how they use a screen reader. If you test manually yourself with a screen reader, you’re not gonna use it in the same way as somebody who’s really good at it… And apparently, it turns out that people use screen readers very differently, depending on who they are, which operating system they’re on, and things like that.

So it can be super awesome to just talk to people, rather than just trying to automate everything away, which I think doesn’t always replace everything.