Richard Moot: It’s kind of funky, because I think most people think of it as separate companies. And I think they were kind of operated functionally that way… But as far as I’ve understood this, it’s all Block. And each one of these other things are brands that are part of Block. But I joined before we became block, so it’s I still have this thing burned in my brain that I work for Square … Recently that’s changed a little bit, so I work on all Block products, doing developer relations now.

So yeah the relationship is each one of these divisions kind of focused on a different audience in the economy. Square is focused on businesses, and trying to run small businesses, midsize businesses… We even have some enterprises. And then cash is all about consumers; trying to give financial tools to people who are “Hey, I want to go invest in Bitcoin”, or “I want to go buy stocks”, or “I want to send money to my barber.” It really helps essentially act as a consumer banking product. And so that’s kind of where there’s a little bit of – getting both sides of the counter is kind of what we talk about.

And then we have our other brands, Tidal with streaming… And that’s kind of focused on artists, and we’re trying to figure out what ways can we enhance artists… Because they kind of operate their own business. And then we’ve got some of the more out there things, like Spiral doing Bitcoin grants, and open source Bitcoin, trying to really transform Bitcoin into the digital currency of the internet. And so yeah.

Joran Dirk Greef: It did, yeah. That was great, you know? And there’s national projects, three different countries, whether it’s for the whole national transportation system, or the central bank digital currency, or another central bank exchange… TigerBeetle is going into the current production version of that gate switch now, as we speak. But I think, just to go back, Jerod, to the DST - it’s a lot like formal methods. The difference is that formal methods check the design of a protocol, so that you know that the protocol could possibly work. It’s formally proven that it could work. But for me, always the challenge was, “Well, how do I know that I’ve just –” Because I’m not a – I always feel like I’m getting slower every day. How do I know that I coded this correctly? I know the protocol’s correct.

Jeff Smith: I would say the initial reaction is the eyebrows go up, and they lean in. Music is ubiquitous. It’s all around us. It’s amazing. And it touches our lives. And so you have this emotional currency that we all get. So they lean in and say “That’s amazing.” And then they’ll kind of sit back and say “Ooh, what does my music say about me? If I’m listening to Nine Inch Nails, does that mean I’m depressed? Or what’s going on here in my heart?”

So they go through that, and then they lean forward again and say “Oh, this is amazing. How do I incorporate this in my life, in my profession?” And I would say the surprise or the unique things that came out of those conversations is really these tributaries that were created.

So we built the tech, you patent it, you apply it to a sector that you understand, have influenced in, that has a large enough addressable market, good liquidity, there’s a budget item for engagement measurement… And you apply it in there. I didn’t expect then where this would take us, right? We’ve got mental health professionals saying “Hey, we want it as a screening tool to get ahead of certain things in our clinics”, as well as creating a profit center for them. We have athletes and sports psychologists looking at it for performance. We have the US military needing to address suicide rates and say “Hey, if we could just know more about how they’re doing…” It’s all about that early detection, early indicator on how they’re doing. And again, I want to stress, it’s a screening tool. It’s not a diagnostic or an assessment tool. So inside of therapy clinics, it’ll just get them to that BDI or GAD, the formal assessments quicker, which is kind of cool.

[12:18] So I think that was the biggest surprise for me, is I’ve launched a lot of companies, and it’s around the innovation or the relationships or the opportunity… This one was just – I use the word ‘ubiquitous’. It just – it’s emotional, it’s primal, it’s historic… It’s just in people’s lives.

We come to learn that the average person listens to 22 hours of music a week. It’s all around us. And so that’s just really cool. So I would say that was a big surprise for me.

Adam Stacoviak: Well, Cent OS makes it sound like a currency, and low-value.

Acon: Yeah. It’s funny, because I’m pretty sure that the inspiration of the Arcade shop, which is the thing that came before High Seas, is directly from Apocalypse economy; the idea of being able to purchase things using a currency, instead of just “Do something, get something directly in return.” There’s like this middleman that the currency kind of acts as.

Tobias Fried: Sorry, I was going to say… If you go down to the – there’s the type specimen thing lower down the site that has not every single glyph, but you can find the glyph that you want. For example, the A that’s not an A is a Greek Lambda letter. The R that’s not an R is the Indian rupee currency symbol. You could probably find most of them down there, but the idea was just to kind of glitch out the word. There’s obviously like a – it fits the vibe, the retro aesthetic of glitching text, and computer bugs, and stuff… But I think it’s purely aesthetic.

Chris Shank: [00:09:49.23] The component paradigm has gotten us really far. It really enabled us to – like, if you go back to 2012, 2015, whenever that idea started and started to spread, it helped us build more complicated user interfaces on the web. There’s no doubt about that. And I think because of that, we’ve hit this wall… And part of that wall is the limiting factor of a lot of these web applications that we see today, I’d argue are not complexity at the rendering level. They’re complexity at the behavioral level. One of the things that I think we’re really lacking is a set of “Here’s all the different types of web applications you can make.” The ones that I’m thinking about are partly what I worked on; we’re streaming real-time market data, we’re contextualizing new stories that are also streaming in real time with that market data… There’s an endless amount of APIs and data that you want to integrate. Outside of FinTech you have real-time spatial canvases, multiplayer experiences… The type of applications that we’re trying to build today are a lot more complicated than they were 10 years ago.

I’ve had anecdotally experiences of “What the hell is happening in this application? Why is this data coming in wrong? Why are our streaming services being canceled and restarted?” And then there’s also this other aspect of - the UI is staying the same, and all of the bugs and the additions that we’re adding to this application are behavioral. It’s just “Oh, we’ve got to multiply X, convert this currency”, or whatever. And that doesn’t happen in the UI, or how we render things. It’s happening in the behavior, 20 yards away. And I think we really lack primitives and approaches to understanding applications better. We really struggle to see how “Oh, a user interacted with something, and there was a click event. What is the application doing?” And part of that stems from this tension of co-location and components sort of being really encapsulated things. Though Reason React aggressively wants you to co-locate things is “Oh, it helps you think reason about the application.” It’s “This button or this table is just its own thing”, and you just need to think about state inside of that thing. And it’s like, well, what happens when this table is talking with the drawer, and affecting other parts of the application? The behavior that we want to co-locate is getting hoisted up and up and up. And then it’s like, well, when now we don’t have co-location, we’re just passing all this data down. And so when you want to say “Oh, this cell in a grid was clicked”, it’s not just the side effects and the thing that the user interface needs to do in those cases is not encapsulated to the table.

Thomas Eckert: Taylor, have you ever tried to use the plastic babies as currency, like get a cup of coffee? Be like “How many babies do I owe you?”

Adam Stacoviak: Yeah. If you’re solving a problem for somebody, value gets exchanged. Typically in currency.

Tejas Kumar: Yeah. There’s one caveat here, because they can also translate. This is absolutely bananas. If somebody is speaking Korean with the language model, and is like “Convert this currency” in Korean, it will still do it. Because the vector dimensional space transcends language the way we know it. And I think that’s very cool.

Kelsey Hightower: So when I saw the crypto craze, it felt like people were really serious about adopting dog coins in replace of normal currency, with at least some transparency, with some levers, some minor checks and balances in place. I was really nervous about that, so you saw me ask a lot of questions in public…

Ron Evans: And there’s always the opportunities, if somebody genuinely is like “We want to take it in this way”, there’s not a consensus for doing that; we’re taking it in our own way. They should do that, that’s not a bad thing. Like, we don’t have to all – if we reach a fork in the road, it’s not two brothers. This time, it’s actually a business decision about something or another.

[01:04:08.10] And I mean, TinyGo has grown into a very big thing in WebAssembly. It wasn’t originally created to do that. That was an emergent property of the ecosystem. And one I’m very glad for, and I’m very involved with now myself. But the original vision with TinyGo was very specifically for small embedded devices, and bringing Go to the microcontroller. And then it just so happened “Oh, we could actually compile this to WebAssembly.” There was some very nascent support in GigGo for WebAssembly at the time, and that’s something that the LLVM toolchain that TinyGo was based on - not BigGo, but that TinyGo is based on. So it’s like “Oh, this would be a cool feature to add. We should do that. No real specific, more just like “Oh, it’s like a low-hanging fruit. Some people seem really interested in this. We should do it.” Next thing you know, “Oh, wow… TinyGo is so much better for WebAssembly than BigGo.” And we’re like “Wow, it is? How interesting! Why is it better? What does it do?” Like, we didn’t even know ourselves some of it. We were just genuinely interested. It was an emergent property of the community, of a problem that they wanted to solve, that BigGo was not solving for them… So a bunch of people started devoting time and energy to improving that WebAssembly support in TinyGo. And then the WebAssembly system interface, which is WebAssembly on servers, and serverless… The WebAssembly not in the browser. You know, part of the fact that we were interested in it ourselves, that also we move a lot faster than BigGo. We can. We can innovate a lot more quickly. We haven’t given a 1.0 guarantee yet, so we can change things… We’re not – even though largely, I would say the Road to 1.0 for TinyGo is more about the hardware interfaces than it is about compatibility with Go itself. Because we’ve had pretty good compatibility for a while. But it was very much an emergent property of the community.

And as more and more of us said “Oh, wow, WebAssembly… That’s really a very interesting thing. We have some problems we wanna solve with that”, and Go being a really good language, for whatever, that this has been an aspect of TinyGo which was not something that was part of any master plan. It’s something that the community wanted, that the community is, and does, and is not at all – there’s no need for it to be a zero-sum game. Oh, it can either be for embedded or it can be for WebAssembly, or it could be for Linux, or for Windows, or for macOS - that’s a false dichotomy. It could be for whatever we collectively want it to be for. But again, with that sort of curation in mind - like, you can share the park, but you can’t just like go in and start digging it up to build your own little thing, when that’s disturbing the flora and fauna of the ecosystem. And so that’s in a compassionate, kind way… But also looking at like the why. Why is this person asking for this thing? Usually, it’s because they either have some need, or they can’t figure out how to get the thing you have right now to do the thing that they want. Either way, that’s kind of on you. If it’s a need they could solve some other way, you could recommend that. If it’s a thing that your software doesn’t do yet, but that it could, you could mention that, and say “Oh, maybe you can help.” Sometimes they’re like “Oh, I don’t know enough programming.” Yeah, but they already took the project in a better direction just by saying “Hmm, here’s this thing that somebody might need.”

[01:08:19.28] WebAssembly again - a really great example. There’s a lot of people who are very involved in blockchain applications. I’m not really one of them. I don’t judge people for what they choose to do with their computational power. My currency is render graphics, play games, churn through large language models… This is on you, not on me. I’m just trying to create technologies that are useful.

So there’s a bunch of people who are using TinyGo specifically because they wanted to use WebAssembly as part of their engine for doing their processing… And so they were looking for basically what we call WebAssembly unknown, Wasm unknown, which is sort of a naked WebAssembly. It’s WebAssembly with no expectations of what the running environment would be.

So for the listener, if you haven’t checked out WebAssembly, first of all, do. There’s lots of interesting things happening. You can run it in your browser, you can run it on serverless applications like fermion spin, you could use it to build plugins for your current software, like Extism, or you could use it to actually run on microcontrollers and embedded devices with TinyGo and Meccanoid. So there’s all sorts of different, interesting areas to do this in.

So this group of blockchain enthusiasts said “We really want to run TinyGo with Wasm, with no external dependencies.” And the people who are doing Wasi are like “Oh, that doesn’t sound very useful”, just because it doesn’t have any ability to call any specific thing. And these folks were like “Oh, that’s okay. We don’t care. We have our own APIs.” So it took a while before it actually turned into something which landed in TinyGo, just because it had to build a little bit of a critical mass. Just one person wants it, just one or two, they’re not willing to do any programming work on it, but they’d like to have this feature… Okay, that’s a signal of intent. There’s maybe other people. Is it useful for other things as well? Well, yes, as it turns out. That same pattern of Wasm unknown is exactly the pattern that’s being used for Meccanoid, for running WebAssembly on embedded devices, like microcontrollers.

So if it was not for the blockchain community sort of priming the pump of starting to think about this, then those of us who are actually interested in using that same pattern for something completely different would not have maybe worked on it and adding it to TinyGo. So again, the community is defining what the thing is, because the purpose of TinyGo is to serve the community’s needs. It’s a means to their ends, whatever those happen to be.

Adam Stacoviak: There’s so much opportunity with decentralized, non-owned-by-government-entity currency for the world that it scares governments. So just that [unintelligible 00:47:40.29] it’s almost worth exploring as trust nothing, you know what I mean? It’s almost worth exploring, because then the trust becomes the network itself, rather than simply “I trust my government”, or “My government trusts that government, and so therefore it is trusted…” You know what I mean?

Gustavo Vituri: Well, I’d say one of the most important parts is that everything is shared, besides your inventory. So currency is not given to a single player, it’s given to the group itself. So if you spend a lot of the money, [unintelligible 00:09:08.21]

Johnny Boursiquot: Which I imagine if you’re running very high-scale operations, then any sort of 2% to 7% reduction in resource utilization means many, many dollars, or whatever your form of currency is; that means a lot of savings there.

Steve Yegge: And binary formats are wonderful, and have their purpose, and we use them all the time, but text is the ultimately flexible, ultimately debuggable, human-readable… It’s a it’s a currency. And we’re seeing that even more now with large language models, right?

Taylor Troesh: Yeah. So let’s see, Scrapscript. I have made a bunch of different versions of this over the years… I said early on in the podcast I used to work with cryptocurrency. I was less interested in the currency and more interested in the crypto, and so I was like “Oh, what if you made a programming language where everything was content-addressable?” And making that nice to use is really difficult. That’s why I think you’ll see Unison, which I think they started working on it around the same time I did, but they actually worked on it, where I just kind of twiddled my thumbs for a while…

Rachel Potvin: [14:13] You know, something I’ve never been good at is blogging and publishing. I wish I would have written more about this while I was still at GitHub, because I think it’s really important. I think it’s easy to fall into the trap of saying there’s two separate careers. There’s a manager career, and then there’s an individual contributor career, and they’re different. And sure, they are different jobs, but they share a lot of commonality… And one thing I really believe is that there’s a spectrum from the deepest technical person to the most strategic thinking, sort of high-level vision thinker. And that spectrum can exist both on the individual contributor ladder, and on the manager ladder. So you want to be able to give opportunity, and job, and take advantage of that skill set with the different individuals, where they are.

One thing I did at GitHub, I also developed the promotion process for engineering, and I talked a lot about that staff engineer promo, as well… And I know there’s lots of writing out there and so on about staff engineering, but always have to be careful when you make your career ladders. It’s never a checklist, right? It’s always – there takes some interpretation. You can’t be too subjective, but it takes some interpretation to say like “This style of person is having impact in this way.” And the common currency really, at various levels, is impact. So at more junior levels, you’re taking direction really well, you know when to ask questions… By the way, that applies all the way up the ladder. But you’re really good at getting things done in a constrained way. And maybe the next step up, maybe you’re figuring out what the way is to answer a problem, and maybe at a higher level you’re actually figuring out what the problem is that we should be talking about. But I think it can be an anti-pattern to really pigeonhole managers to say, “These are people managers and coaches, and not technical individuals as well, who can understand the depth of what their team is doing.”

If a manager of ICs can’t jump in and help coach their individual - maybe you don’t need to be the deepest domain expert on everything, but you at least have to be able to understand the work that’s happening on your team, and be able to give good coaching advice, or hook your person up with someone who can give them good technical advice, great code review of what they’re working on…

And then I love seeing – I’d love to see at GitHub a distinguished manager; just that someone who’s got a small team of people working with them on the hardest problem that GitHub has. Some people call that maybe the surgeon model, right? You’re the tech lead, but you’re also working so closely with this group of people that you’re the right person to be the manager.

Tim McNamara: Look, we can pick our currency of choice. The thing that I think is significant is that the reason why this saves money is that essentially at the scale that AWS is, energy usage equals cost. And the reason it saves money is because it uses less energy to deliver the same – in fact, a better user experience. So Amazon is a customer-centric company, and I’m more than happy to actually flesh that out, because there’s a lot of cynicism about Amazon and AWS, which I think AWS and Amazon should be prepared to kind of confront… But my personal experience as someone who’s been at the company since about eight months now is that this idea of being customer-centric - it’s incredibly strong through the company. And in fact, yes, the company would like to save money. Yes, it would like to increase its profit. But the thing that really kind of pushes the services forward is this really strong desire for improving our customers’ experience. And since AWS is an enabler of other businesses, because it’s a utility compute platform, or a utility compute – it’s essentially always going to be in the background. But our role is to enable or to kind of facilitate others to grow.

And yeah, that’s one of the things that really struck me… Because I came on to onboard with a very high degree of skepticism myself, but I’ve been really impressed actually by a couple of things. One is this customer centricity. Another one is a very strong dedication for data safety, and data privacy, and security being like utterly paramount to almost everything that we do. And in fact, the internet connectivity issue that we faced before one of these internet slots was because that my computer had shut itself down and isolated itself, because it had detected that the software updates weren’t current, and so it said “No, no, no. The only thing that you can access–” It restricted its own firewall, and so “The only thing you can access is the update mechanism. So do that.”

Jerod Santo: So how should you store currency inside of Postgres? What’s the best practice?

Chris Benson: I have a follow-up to that real quick, if you don’t mind. Would it be right to think – we think of stores of value in terms of money, and we’ve been talking about money in recent years, we’ve looked at cryptocurrencies and we’re starting to think of those as stores of value and forms of currency themselves… Should we be thinking of data in a direct way? Because we’ve kind of talked like one step removed so far, but is data money in the way that we should be thinking going forward?