Mat Ryer: Hello! *coughs* That’s a bad start. Sometimes, kids, things don’t go to plan… And that was one of those. Just a little cough at the exact wrong time. But don’t worry, through the power of editing, this will definitely make it into the end thing.

Jerod Santo: Jerod here in the editing room. At this moment, Taylor’s power cut out and he dropped offline. Thankfully, he scrambled and got reconnected using his phone… So we just skipped him and went on to Thomas. Taylor does make it back before the end of the round, but he missed some guesses, which explains why he just blindly picks the second one. Okay, hope that helps.

Jerod Santo: Sure. So in software world, as you know, Kball, we use Riverside to record, and that’s a web app that we pay for. It’s a software as a service web app that puts I think almost every newfangled web technology into play in order to have a really nice experience for us. And that handles a lot of the problems that we used to have to work around. It used to be a lot harder to podcast. We had Skype, and we had multiple enders, and we had this, that, and the other thing, call recorders, blah, blah, blah… Riverside has really simplified the tools that we need. And we’ve been using that for a couple of years now, pretty successfully.

There are competitors to that, which are also good… So lots of cool tools in the podcasting space. And then we take the recorded stuff and we do all our editing in Adobe Audition. Now, there’s a lot of tooling around that now that didn’t exist before as well, around editing specifically, whether it’s Descript and the ability to read the transcript, delete words out of the transcript and it edits the audio, which is just a really cool idea… But for us, we’ve been doing it this way for so long that we just prefer kind of the power and control that we have in Audition, that you give up when you use some of these online tools for editing. So everything goes into Audition, all of our files are synced via Dropbox… So we don’t think about Dropbox very often, but it’s just a core piece of our business, 100%. Long-time users of that.

And then everything else in terms of publishing is all just self-built. So I built an open-source web app, the one I mentioned, that does everything from like we have an mp3 file, to completely published, syndicated, promoted, blah, blah, blah, blah, it’s all just coded up. So a custom tool.

Peer Richelsen: But just the two– I don’t know how many; two, three people maintaining it as a hobby… The likelihood that a commercial open source software has any severe vulnerabilities is I think lower, because you have the budget to do security audits and hire the same amount of people that would usually work at Stripe on Microsoft or Facebook.

Adam Wathan: Totally, yeah. That’s the thing. People say they wanna have the power to name things, but I’m not convinced that they would actually enjoy it. I think the other thing is that the names – it’s important that they’re pretty good, but eventually it just gets to a point where you’ve learned them and you’re using them to accomplish a certain thing, and you don’t really care what the exact characters that you have to type to get there were. There’s like a threshold where a name is good enough, and this is something I’ve been battling with Tailwind 1.0 that I’m working on - kind of auditing the existing stuff and seeing like, you know, if I knew what I know now, after so many people have used it over the last year-and-a-half, would I have made this class named differently, or something? And that’s been really hard, to decide when – even if I think I have a better class name, it’s like “Is it worth changing? Was that old class name actually bad, and is it worth creating a breaking change and kind of throwing people’s muscle memory away?”

Josh Goldberg: Yes. Thank you for offering. Typed linting, or type-aware linting - it’s the big thing. The major value prop, why we’re putting so much effort into TypeScript ESLint, the ESLint plugin is that we are the main - and I believe currently the only mainstream - lint situation that can do type-aware or type-informed linting. That’s writing ESLint or similar lint rules that can use the power of the type checker such as Typescript. That’s huge. That is a hugely important thing to be able to do.

The big banner rule that we always talked about is no floating promises; rules that can detect when you say create a promise and forget to await it, which is a very common problem that we all accidentally fall into. Rules around other async things like awaiting stuff that’s not [unintelligible 00:45:38.28] custom rules that help you migrate off deprecated endpoints, because you know that the type of the thing is dot dot dot.

Typed linting is really hard, because you’re mapping between the ESLint way of doing things, which is a linter, and the TypeScript way of doing things, which doesn’t even use the same AST format. As we were saying earlier, you have to map between the two to use TypeScript APIs. So that’s why I haven’t jumped over to something like Biome or Deno_Lint yet, because we’re the only thing - TypeScript ESLint is the only thing that supports typed linting right now.

I’m very excited they’re all working, or at least have it on their roadmap to work - on their public RFCs in all these projects like Biome, the open source ones… But it’s a really hard problem to solve, because these projects are intentionally written in a native speed, typically, like Rust for many. You get incredible parallelization, you get very nice performance… But then TypeScript is not written in Rust, it’s written in TypeScript, so JavaScript. And no one has yet solved the problem of “How do you call to TypeScript type-checking stuff in a way that doesn’t slow your Rust linter down to the speed of a JavaScript linter?” And I can’t wait till someone does that. But until they do, I’m stuck, I’m keeping myself in the TypeScript ESLint space to be able to work on typed rules the way we have them now. Ta-dah!

Adam Stacoviak: And the power of a good name, obviously, and the power of a good description is probably equal. Every time I come up with a podcast show summary, I’m always like “How do I do it?” And now we use Riverside. Not here in Seattle, but when we’re in our distributed studios, we use riverside.fm… And when we’re done with that, we can just hit “Summary notes”, and it summarizes the podcast, it gives us keywords that were in there, it helps with some chaptering information, like what are we talking about at each point… So even when we’re editing and doing chaptering, we can define that kind of stuff. That to me is like paramount for just not burning out.

Scott Chacon: Yeah, I mean, there’s always – I’m curious how they do it. I wish I could speak a little bit more intelligently on this particular tool, but… There’s always this issue of “What strengths and weaknesses are you choosing between a centralized version control system and a decentralized version control system?” So there’s obviously a lot of things – we’ve all moved to decentralized version control; that was the whole thing in 2005, 2006, 2007 and 2008, is sort of this rise of decentralized version control systems. But with it, I think, comes more by default, by definition almost, more forking, and more merge conflict problems. Because you can keep things sort of separated from each other. That’s how the systems are designed, to have some advantages. But the disadvantages are they’re not in sync all the time. You can’t have merge conflicts with Google Docs. It’s a perfect separate comparison, is you can’t have – people are editing the same file simultaneously, which makes it really difficult to go off on a tangent and test something out, and see if it works… And yes, the power of that is that you can experiment in a way that is completely freeing. You don’t need to worry about what trunk is, or whatever, if this is mergeable. Anything – I can do my experiment, I can test it out, I can see if it works. I might have merge conflicts later, because lots of people can do this, because lots of people can do this, but it allows you to do that. Google Docs - you can’t have merge conflicts; you can mark that up as a win, but on the other hand, it’s very difficult to experiment, to sort of fork it and do something different and say “What if it was like this?”

And so I find that very, very interesting. What is a good combination of these things where you can go more down one route or another route, depending on kind of what your needs are, and what the feature is, or what the project is you’re trying to do? And I don’t think there’s a great answer. I think everybody kind of has the ways that they like to work, or whatever… But anytime you go more towards one, you go more away from the other. You always have this sort of balance of strengths and weaknesses with decentralized versus centralized sort of concepts.

Toby Padilla: Thank you. That is sort of a perception that’s there, and it’s partially true and it’s partially not true; it’s difficult… One of the reasons we’ve built this is because Christian and I have been on the command line each for like 20 years apiece, and neither of us considered ourselves experts… Because the learning curve for this stuff is just a sheer cliff wall. You spend your life learning about that… And that shows you the power, but it also scares a lot of people off. So it’s like, “Command line? No. I don’t want anything to do with it.” And then a lot of the tools are really dated. Some of the dated tools are excellent; I’m a huge Vim guy. Not the most newest editor out there… But still, I use it every day.

There’s kind of – on the command line you get these things that look like lifer technologies, where it’s like you invest your life in learning this thing, and then it’ll pay off in the long run. I spent a lot of time moving to Vim from TextMate, or something like that. And it was difficult at first, but I knew “Suffer through this and it’ll pay off 10 years from now, 20 years from now, when you’re SSH-ing into a server and you’re just like kicking ass, editing text”, right? So that’s one. Or piping commands together; learning basic, Unixy workflow stuff there. All of that stuff - it’s a big investment, but it pays off in the long-run… Versus learning a proprietary stack, or even a proprietary bit of technology. I’ll use a web example for this; and this is by no means to bash the project, but D3 - I always look at D3 and it’s like “Hey, you can do awesome stuff with D3 in terms of visualizations.” And then I start learning it and I’m like “This is so much to learn.” It’s so much to learn, just this like very specific framework, in this very specific spot. It’s not gonna be knowledge I can apply across the computing world. So when we think about command line stuff, doubling down into your knowledge there should be applicable across a whole range of tools.

Toby Padilla: Thank you. That is sort of a perception that’s there, and it’s partially true and it’s partially not true; it’s difficult… One of the reasons we’ve built this is because Christian and I have been on the command line each for like 20 years apiece, and neither of us considered ourselves experts… Because the learning curve for this stuff is just a sheer cliff wall. You spend your life learning about that… And that shows you the power, but it also scares a lot of people off. So it’s like, “Command line? No. I don’t want anything to do with it.” And then a lot of the tools are really dated. Some of the dated tools are excellent; I’m a huge Vim guy. Not the most newest editor out there… But still, I use it every day.

There’s kind of – on the command line you get these things that look like lifer technologies, where it’s like you invest your life in learning this thing, and then it’ll pay off in the long run. I spent a lot of time moving to Vim from TextMate, or something like that. And it was difficult at first, but I knew “Suffer through this and it’ll pay off 10 years from now, 20 years from now, when you’re SSH-ing into a server and you’re just like kicking ass, editing text”, right? So that’s one. Or piping commands together; learning basic, Unixy workflow stuff there. All of that stuff - it’s a big investment, but it pays off in the long-run… Versus learning a proprietary stack, or even a proprietary bit of technology. I’ll use a web example for this; and this is by no means to bash the project, but D3 - I always look at D3 and it’s like “Hey, you can do awesome stuff with D3 in terms of visualizations.” And then I start learning it and I’m like “This is so much to learn.” It’s so much to learn, just this like very specific framework, in this very specific spot. It’s not gonna be knowledge I can apply across the computing world. So when we think about command line stuff, doubling down into your knowledge there should be applicable across a whole range of tools.

Jerod Santo: Four years old… Not under-powered by any means, until I started doing more audio and video editing. That’s really where I feel it, of course. As well as livestreaming, when I was doing those live Elixir sessions and I would have to compile code while running OBS, and streaming to somewhere… That’s where I really started to hit up against the power limitations of that machine. So I’ve been waiting for an upgrade, because I wanted this machine that I bought.

[04:10] I didn’t want the MacBook Air edition. I knew the M1 last year was brand new, there was gonna be some transitionary time… We still have – I don’t know if you’ve hit the Rosetta thing already, but I have… Installing Rosetta for certain things that aren’t ported to the new architecture… But what are you upgrading from? I know you were on a beefier machine than I was.

Guillermo Rauch: So one example that I think is super-interesting is that technology that has been approachable for authoring for the web has also been quickly discarded, as I mentioned. I actually used to use DreamWeaver, many years ago… And I remember – again, you kind of outgrow it. I think we’re gonna create technologies very durable in that sense.

[01:09:52.10] I always actually point out that I would have investors years ago tell us “Well, frontend is not interesting, because frontend frameworks get changed every other day, and whatnot… And now we actually look at reality and we see that actually the choice of React, for example, for major organizations, corporations and storefronts etc. in the U.S. has been super-stable, super-durable. Durable like Git has been durable. And I think that’s gonna happen in lots of different ways. I think you see it with Shopify now taking headless a lot more seriously, and welcoming React developers worldwide to build on top of that… But I think the same is gonna happen with folks on the authoring side, on the editing side. The folks that contribute through no code and low code. It’s not that they’re gonna be any less of a contribution or that their work is not gonna be as important, or that it’s gonna get rewritten by a developer a year later. Perhaps even the opposite. Developers will start saying “Well, for this simple page that I need to build, I’m gonna build it entirely visually. Or I’m gonna build it entirely in the web browser. I’m not gonna use the power tool for this anymore.” And yet, that’s gonna be the right decision, that’s likely to stay for years and years and years to come.

At the same time, I think AI will play a very important role here. I’m a big fan of the work that GitHub put out, with better autocompletion. I’ve always been a fan of this. I created a demo called ThoughtComplete back in the day, where you would type and it would autocomplete from tweets that other people wrote, to just augment your cognition. I think there’s gonna be a lot of that going on, where we augment the developer cognition, we augment the non-developer cognition, we augment the marketer cognition, in that marketers can try more things, more permutations of copy and ideas assisted by AI. You can almost think of this as a website building itself. And we’re not really far away from that. We’re talking maybe months, if not single-digit years; obviously, I’m too optimistic sometimes… But the websites that build themselves are certainly coming.

Jerod Santo: Goodness gracious… So I have been knee-deep in Adobe software products the last few months, which is like - is that exciting? Is that news? Is that interesting? …I wouldn’t use any of those words… That being said, I’ve been doing a lot more audio editing, I’ve been learning After Effects, so I find myself on YouTube, looking for mentors, trying to figure out how to do the most basic things, and get things done… So it’s been a departure for me from coding all day every day, to trying to do creative things related to code. So I haven’t learned any new software things.

One concept I came across recently, which I thought is interesting and I would like to apply in my work and in my life is this idea of the MoSCoW method, which is really a prioritization framework… So when it comes to how to pick what to do next, sometimes that’s a huge issue. I know that for me specifically these days I have 1,000 little things to do, more so than one big thing… And so prioritization is a struggle. Like, “What is the most important thing right now?” So there’s this blog post from Browser London (which I’ll link up) called “The power of the MoSCoW method”, which is basically a prioritization framework. It kind of lives in the Agile-planning-weird-project-managementy space, but I take all these things and apply them personally and see how they work out.

The idea with MoSCoW - it’s a weird backronym for Must, Should, Could and Won’t… So the idea is you just create these buckets for yourself - the Must bucket, the Should, the Could and the Won’t… And that’s MoSCoW if you squint at it. And then you take all of your tasks, or your stories, or what-have-you’s, the things that you’re trying to accomplish, and it’s just a way of really quickly bucketing each thing. And you can do it on a Trello board, you can do it however you’re doing it… You can do it on a piece of paper if you’d like to… And it just helps you quickly prioritize what you’re gonna do next, what really matters, and you can just compare them side by side. It seems like it’s useful… I started to do that a little bit, and it seems like it’s pretty good.

So I’ve been trying that as well… I wouldn’t say I’ve been learning too much, but… Yeah, After Effects. Is that exciting?

Sahil Lavingia: Yeah, so we went through some downs at that point, in 2015. We shrunk the team to five, and then shrunk the team to one, just me… No one had joined the company to build a lifestyle business basically, so I was like “I’m gonna go run this thing… At some point it’ll grow to a point where I can start hiring new folks again. And if Gumroad doesn’t grow, I can shut it down. If it does, we’ll figure it out.” It ended up doing great actually. Even though basically we didn’t ship any new features for almost two years, it continued to grow, which is the power of technology and the power of software.

I think we’d built a solid product, with venture capital; we didn’t do it for free. So in late 2017 Kleiner sent me an email, wrote off the investment that they had made six years ago. Our partner at the time, Mike Abbott, had left Kleiner Perkins; they were trying to probably readjust their books a little bit… And just took the write-off for their taxes.

That gave me this newfound – our liquidation preferences fell from 16,5 million to 2,5. So all of a sudden I was like “Maybe I can do something with this business, and maybe this commitment that I made to this investor to build it into this–”, you know, our valuation at the time, that Kleiner gave us, was 28 million dollars. So that commitment, that promise, implicit or explicit, is now gone. So I felt more comfortable saying “Okay, I’m gonna do what I think I should do with this business.” We had the profits at that point to build a team out and refocus on that.

I think the thing that really changed is writing this piece – I wrote this piece called “Reflecting on my failure to build a billion-dollar company.” That did really well on Medium in February 2019… And writing that and editing it - I sort of had to answer all these questions for myself, like “Who am I? What am I doing? Why am I doing it? What is Gumroad? What does Gumroad wanna be? What do I wanna do long-term?” I had to start thinking about all these questions as I was writing that piece. And then the fact that it did super-well made me accountable to those decisions. If I had written those and no one read it, I could have disappeared off into the internet and done whatever…

Jerod Santo: Very cool. Well, if you are not like Suz and lucky enough to get in on the beta yet, I know there’s lots of people still awaiting… Well, while you wait, you can hear from Kyle Daigle all about it. We had him on the Changelog a few backs; I’ll link that up - “GitHub Actions is the next big thing.” We go deep into that, and he even answers my question about Bitcoin mining… So they have a response to the leeches out there who want to have the free compute power. So listen to that in the meantime, and hopefully we’ll all get in that beta soon. Or hopefully it’ll come out of beta and we can all start using it.

I’m excited for the community-shared workflows to start flowing towards my repo, so I don’t have to write very much code, and I can get all the benefit. That’s just kind of the lazy, selfish guy that I am.

Alright, thanks, Suz. Chris, you’re up. How about some shout-outs from you?

Jerod Santo: This HackerOne site is cool, and I think it’s a necessary thing to really bring together two disparate communities - we’re talking about security researchers and open source developers. In my experience - and you guys can tell me yours - there doesn’t seem to be too much overlap; there’s a few people who play in both pools, but it seems like there’s a somewhat strict divide there, in those two communities, and really to all of our disbenefit… That’s not even a word, but I guess to our harm… Because there’s a lot that we have to offer in terms of open source developers, to security researchers, and vice-versa. So anywhere that we can create places that we can come together and collaborate, and they can hack on our code, and we can fix things as they find problems, those are things that are necessary.

[20:34] Just thinking about some of the stuff you’re saying about what happens at GitHub - there’s a lot of best practices; you were mentioning the principle of least power, and defense in depth… There’s a lot of things that we can do as developers that really mitigates the problem. It’s similar to “Well, if I get hacked, at least they don’t have root access. There’s no god mode immediately.” So we can do things that help mitigate when there are breaches, but if we don’t have those things taught to us or explained to us, or reiterated or exampled to us, we just don’t know what to do, how to do it well… So it’s cool that they offer this free for open source.

It made me think of proprietary companies, and the advantage that they have is that they can actually offer cash for bugs, cash for vulnerabilities. As open source people, we can’t even get any cash to buy a sandwich, let alone to fund some security audits.

Russ Cox: Honestly, I’m sure that you’re all lapping me with all your fancy editors, so I don’t know that I would encourage you to go use Acme. [laughter] The main selling point is that it’s programmable, in much the same way that Plan 9 - everything was a file system, so you could program through the file system and present things… Acme had that sort of idea, too. In fact, under the covers, Acme actually is a file server, but it’s running on Unix, so you can’t see the files that easily… But it lets you do plugins that talk to the editor, but there are separate processes, so it doesn’t matter what language they’re written in. It’s not like Emacs, where everything is written in Elisp. That actually gives you a fair amount of power.

I have written Acme plugins, essentially, different programs that talk to Acme, and a lot of those are written in Go. I can do GitHub issues, I can look at code review comments, I can do all that in Acme, and that’s all external programs written in Go. That for me is – you know, I have all these comforts that help me be more productive…But watching other people, as far as actual text editing - you guys are light years ahead of me. And that’s okay.

Julia Liuson: Yeah, so first of all, why we started to do that is that we realized that there are different types of developers. When you start talking to a lot of developers - a lot of different needs… And I always ask people, like “Do you use Microsoft Word?” Usually I get a nod. “Do you use OneNote?” I also get a nod. “Do you use Notepad?”, I again get a nod. Personally, I use all three. And I’m not really confused about when I’m gonna use each one. You can say they’re all for editing words, but I use them and a lot of different people use them for different scenarios.

The power of the IDE is that there’s a whole set of – it’s particularly powerful when you have very complex multi-step processes that will just simplify and automate it for you. That is actually one of the biggest powers of the IDE.

[20:03] Think about, for example, what we download on-stage in terms of mobile development. You’re developing a bunch of code, we’re compiling it, and then we’re actually patching that into the device or emulator, and then setting up the debugger with it, and we demo very similar scenarios for Docker’s development against our Azure Kubernetes Service (AKS), and from Visual Studio IDE’s. A simple, almost F5 gesture, and all of that workflow is done for you.

A lot of developers love them, but there are also developers for some scenarios, like “I don’t wanna use your workflow. I want to go construct my own workflow, so I just want the code editor to go do a thing for me, and I can go assemble my own workflow for me.” That also happens. So we’re like, “You know what? In that case, Visual Studio Code is great for you.” You define and you decide what your workflow is. It’s not going to package these things up for you, so you have the full freedom to go do and write whatever code you want to go write. And we provide this light IntelliSense to help you, we have this light capability of debugging to help you… So it’s not going to decide your workflow for you.

We see those two things as fundamental differences in how developers approach certain scenarios, so we think it’s very valuable that we provide both of those to enable those scenarios.

Techno Tim: Oh, yeah. Oh yeah. I mean, I can’t even plug in a PCI Express card. Mac doesn’t allow that. They don’t allow any video card. You’ve got to use theirs. And so what I’ve had to do is get this USB-C dongle that powers this thing that allows me to plug in PCI Express cards, so I can capture video and you can see me right now. That’s what I do. I mean, that’s the lengths people have to go to get things to work that just work in Windows. You get them on the board, you get PCI Express, you plug the card in - boom, it works. Drivers are already there.

So I’ve gone both ways. I use both, and I flip flop on both all the time. It was honestly harder for me to go to Mac than to go to Windows… Obviously, probably because I ran it for 20 years. But making that switch I realized Mac is great, stable, fantastic… I never have to worry about it waking up or it staying on. Like, it just works. Apps are so stable all the time, with the exception of editing every now and then. And I don’t know, I kind of have a beef with Apple’s biggest release – their software release with everything. I feel like every single thing I use from Apple right now has a bug and we just need to get past this point. But going to Mac, I kind of sometimes miss Windows, if that’s a thing. For me, it is. Sometimes I do miss Windows. To be able to just, I don’t know, do whatever I want, because Windows works with everything.

Jerod Santo: So that’s not even false advertising. Now, the other one says PODCAST in all caps, and then ing in lower caps, because I think you probably forgot to put that in there… Exclamation mark. Mics. Software. Sales. Editing. Questions.

Community. Clips. Gear. That’s good. That’s good advertising.

Jimmy Miller: Yeah, I mean, it depends on what columns you’re grabbing. You have to know what things are where. And most applications – I mean, most of these columns were completely pointless. I’m sure if you actually looked at them, they were completely not used for eight years, or something. It’s just like somebody decided, “Oh, I’m just going to add another column.”

All of our SQL schema was not actually in any source control. You just had to submit forms to the DBAs, who would manually run them. For actual like stored procedures, of which there were hundreds or thousands, you had to like manually check them out in different environments, and then write your name, like “I am editing this. Please don’t edit it.” And then you would leave a little change log of what you did… And you’d end up finding out someone didn’t do it in the lower environment, so by the time you get to production, it’s wrong… And all sorts of fun things there. So adding a column, as long as you can get one DBA to agree, you’re good to go.

Alex Russell: I think the way you’ve framed that in terms of trying to understand which architecture is going to make the most sense is really a pressing problem for our community. So I’ve been talking with colleagues and friends about this sort of little tiny model - I need to write it up in a blog post, but sort of like, every system, every interaction that you do… I wrote something about it last year, a kind of generalized theory of web performance, unified theory of web performance… And it kind of includes something like this. Basically, the idea is you start with a system being responsive, that is to say it’s not doing anything, right? It can take input at low latency; so you provide it input, it starts to do the work, and it acknowledges to you that it’s doing the work. That can be like, I don’t know, starting a loading spinner, or something. You do updates about that work, you do part of the work, you learn more about how it’s going, and then you continue to update the user about its progression. Eventually, you retire the work, and then you present the results of the operation, and then you’re back to square one. You are interactive again for the very next thing. And that loop, that core interaction loop, where you start quiescent and you end quiescent… Like, you start being able to take input, and then you return to being able to take the next input - that describes clicking on a link, or typing in a URL, just as much as it describes some update through a local data store or through a templating system to generate some diffed DOM. And so you can model the same interaction as either a full HTTP round trip, or as a fully local interaction, depending on where the data model lives.

[38:00] You remember the old Mapquest, where you had to like click north, south, east and west, and maybe you could get northeast, northwest? …this very painful thing. And then Google Maps, of course, the slippy maps made the world a lot better for folks who are doing that kind of interaction, because each incremental interaction involved much less variance and lower latency as you took each individual turn through that loop. Because grabbing it and moving it was a whole turn through that loop. And you could – again, at an intellectual level, you could model all those interactions as being full round trips. And we all came to agree that that was less good. But we didn’t say under what conditions is that less good. And so I’ve been trying to enunciate this with folks at work, and the closest thing that I can come up with is session depth weighting. So that is to say – think about a distribution of sessions, right? Because we’re never talking about just one user doing just one thing. We’re talking about users doing a series of things, in a session. And they have a distribution of actions they take. And there’s a distribution of different kinds of users through a site. But if you’re thinking in terms of, say, an eCommerce site, you have a couple of sort of prototypical session types that you think most about. So you’ll think most about a user who comes into the site door through a product page, from a search result; they add to their cart and they checkout immediately. Okay, that’s one flow.

There’s another flow, which is they go to your homepage, they go to the search box, they go to a search results page, they sort and filter a bunch, and then they go to a product detail page, and then they do some configuring and some futzing around there, and then they add something into the basket, and they do a little bit more shopping, and then they come back to the basket, and eventually they do a checkout. Those two sessions are extremely different in maybe their composition, and the question that I think we can try to tease out is, “If we know about the kinds of sessions that a site or product has, we can learn a lot more about what trade-offs are going to be better.”

I like to bring up the example of Gmail. I can click on a link to an email from Gmail and see just one email. Or I can load up Gmail as like my daily driver email client, or Outlook, or whatever; I can load up the thing to do 1,000 interactions through an extremely long session. Now, I think you’re right to be cheesed every time you see a loading bar to get to a single email, right? That 10 kilobytes of text shouldn’t require 10 megabytes of JavaScript, or something; or 3 megabytes, as the case may be. We can do better. So that’s related to session depth. And so if we think about SPAs being appropriate for long and deep sessions, especially where there’s like high frequency and low latency interaction, editors - editors are a perfect example. The Figmas, and the Photoshops of the world - you need a local data model, because otherwise network variance and network latency in the critical flow are not great. Whereas for lots of other kinds of applications, which are either not editors, or have much shorter sessions, even if you could imagine the most engaged user, fetishize the user who will spend all day on your thing, the reality probably isn’t that that’s who most of your users are… And we can know something about most applications, because honestly, most software projects today are not greenfield. Like, we’ve built these on the web before. We were building email on PIM clients, again, with tools that I used to help build back in 2006. Full business intelligence suites with Ajax in 2006-2007. The stuff isn’t new under the sun. We can say that we know something about these classes of applications now. And so as a result, we can start to characterize them by those session lengths, and then we can start to decide whether or not we need a local data model, and all the tools that are premised on operating over a local data model.

[42:01] When we talk about this SPA technology, what I think we’re really talking about is, “Do I have a local copy of some subset of the data that I’m going to be manipulating frequently, applying optimistic commits to, and then updating my UI about as quickly as I possibly can in order to make it feel better?” And that’s extremely subject-dependent as to whether or not the app itself is going to feature long sessions on average.

I love WordPress as an example here… So WordPress is two applications, right? WordPress is an editor; so you sit down and you want to write a blog post, you go into the editing UI, and you have a very long session, probably. It’s a drilled-in editor, that editor does lots of stuff, loads of stuff… You can sit there and preview, and refresh, and all that kind of stuff. Whereas if you’re a reader, that experience is mostly going to be thin consumption; like, one to two clicks.

And so in those sessions, the user who has a very long session can divide the total session costs in terms of latency, or payload, or whatever you want to call it - because those things kind of blend into each other - over the number of interactions that you take. So if you can drive down the resulting fractional number, if you can get that to some low number because you front-loaded stuff, and therefore each subsequent cost was much lower, versus the sort of full-page refresh model, then you’re winning. But if you’re a reader of a blog, you can’t afford any of that, because the denominator is one, maybe two. Scrolling doesn’t count, because the browser does scrolling for you, and it’s magic, but–

Jacob Kaplan-Moss: Yeah. I mean, I told them three hours. And so if they hit three hours and weren’t done, I would expect them to give me not-done code. The analogy that I like to think about is I’m not looking for production-quality code. I’m looking for ready to open the pull request. So I may not even be– at the point of opening the pull request, it doesn’t necessarily work. I mean, how many times have we gotten like 90% there and then gotten stuck, and we open a pull request and we say, “I think something’s wrong. I don’t know what’s going on. Can someone else take a look and help me figure it out?” And as long as that code is mostly good, it’ll eventually hit production. We’ll just get some feedback, right? So I kind of think of any sort of work product that I see as part of the work sample test as a draft or as a pull request. It’s the first version you might share with colleagues, because the part that the work sample test doesn’t include is the feedback that you get that makes whatever your work product is really good.

Another good example, the position I have open right now, the work sample test involves writing in English this time. And if you look at the writing on my site or the writing that I do for work, it’s well organized, it’s mostly free of typos, it’s fairly clear, it’s cogent… And you might think that it springs from my keyboard looking this way, but you’d be totally wrong. My rough drafts are full of typos, confusing, hard to follow. In almost every case, there’s an editing step; always me doing a few passes of editing, but often someone out else, especially for my work product. I’ve got a whole team of colleagues that I share drafts with that give me feedback on.

So when I’m assigning this work sample test that involves writing, I’m telling people, “I’m not looking for something that would be done here. I’m looking for ready for feedback from my colleagues level.” And it’s the same thing with code. I’m not looking for ships to production. I’m looking for ready to open a pull request. So the bar is much lower, but I need to know that people can understand and talk about and have a conversation about that code, because that’s exactly what’s going to happen at work. I’m going to open a pull request and someone’s going to say, “Oh, you’re using mocks here. I thought we usually use stubs. Why don’t we change this?” And you have to be able to have that. I need someone who can both write the code and also then have that conversation with their colleague and get to the right point.

Adam Stacoviak: Yeah, I like this “productive as you can be.” Let’s pull in some of the commentary here inside of GoTime FM Slack… So if you’re listening to this in the aftermath, meaning it’s produced and you’re listening to it on the podcast feed, you can listen live every week. We broadcast live on Thursdays, and you can have things like these mentioned on the show. Corey Lanou says “Command line or bust!”. I like that. He’s definitely a fan of Brian, he’s in that vein of like “Take it from me, I dare you!”

And then you’ve got other comments… This one is from Fernando, he’s saying “I basically use VS Code for projects” – I like this idea here. “I use VS Code for projects, and any single-fire one-off editing, maybe something that’s happening inside a terminal, I’ll just pop it up in Vim.” So it’s like “I’m gonna use the tool that’s available for me in the right context. Maybe I don’t know everything about Vim and I can just use it for quick in and outs”, and that makes sense because Vim is everywhere, pretty much… You know, using the tools that are available to you to make it efficient. But Go specifically, programming in Go - you may want to use something that’s a bit more souped up (in Carlisia’s terms) for you.

[32:09] There’s some other mentions of Git… You’ve got “Tower is a tool for using Git”, you’ve got – something else we’ve just mentioned was “It’s Magit!” That’s kind of a weird name for a project. (Magit instead of Magic). I don’t know if that’s how you pronounce it, but that’s what it says.

Jessica Lord: [laughs] Yes, alright. First of all, if you haven’t heard of Glitch director/browser to Glitch.com, Glitch is this really awesome IDE coming out of FogCreek. Jen Schiffer is the community engineer there, and it is all the things - I’ll try not to spend too much time just gushing about it… It’s an in-browser IDE; you can have multiple people editing the code at the same time, but it’s also free hosting, and it’s free hosting with a Node server. Everything you build, you get free Node hosting, and then similar to like forking a project on GitHub, you can remix a project on Glitch.

Glitch really wants to lower the barrier for entry, and building things on the web and making it fun. I think last week they released a new feature for getting help called “raise your hand.” If you go to Glitch.com, you’ll see at the top of the page it says “Help others - get thanks” That will show you if anybody has any questions at the time. What it lets you do is anywhere that you’re editing code in a Glitch project, if you highlight some lines of code, you’ll get an icon with the emoji handraiser, and you can click it and you can describe your problem and it will go to this section on the homepage.

Then anyone who wants to help people who are learning and working on projects on Glitch can go and see who’s asking for help. When you respond to someone in need, it’ll ask that person to give you access to their project, and then you can get in and start coding with them.