Paul: Hi there, and welcome to PodRocket. I'm your host Paul, and today we have Nnamdi Iregbulem with us. He is a partner at Lightspeed, really into tech, self-taught programmer. He's here to share the riches of knowledge with us of one of the works he's put out called The Programmers Manifesto. Nnamdi Iregbulem: How's it going? Thanks For having me. Paul: Yeah. Welcome to the podcast, excited to have you on. So what is the whole purpose or the ethos behind this work that you created? What was your goal when you were setting out on this journey, and what is it in 30 seconds for people who aren't familiar? Nnamdi Iregbulem: Yeah, so the Manifesto is a three-part series I wrote almost two years ago now that talks about developer productivity and why I think it's such an important topic to focus on. And for context, I've been a self-taught programmer my entire life, PHP websites back in the day, a lot of Python and other things, modifying video games and stuff as a kid. And I've become sort of obsessed with technology over the years and I like to make these sort of analogies between the Industrial Revolutions of the past where... You had these factories and labor was the key input to those factories. And that labor was oftentimes not super well treated, was generally considered low skilled, what have you, wasn't very well paid, to you shift forward to today and everything is software. Software is eating the world, as they say, and every company is becoming a software company on some level. And so, the unit of labor now is the software developer and they are very well regarded in Silicon Valley. They're sort of like the gods among us. It's a very scarce resource. They're very well treated and they're very well paid. And so, anything that can make them more productive is inherently quite valuable. And so, I kind of wanted to explore those ideas in the piece and combining both the technical side of things, which I really enjoy, and also the kind of almost economics of this stuff, which I'm also a huge economic nerd. Paul: Right. Yeah. This is interesting, because we're taking... This is a tech podcast. We talk about repos and open-source projects, and now we're stepping into the economics realm. Because one of the things, I'm so excited to get into this, but one of the things you mentioned is how you think about productivity as the production function. And I was like, "Oh, the Cobb-Douglas." Nnamdi Iregbulem: The Cobb-Douglas. Paul: The Cobb-Douglas. In the cryptocurrency world, you find this everywhere. And it's naturally occurring in describing to a pretty decent model, a bunch of systems that are out there. So I'm really excited to get into that and relate. Nnamdi Iregbulem: Wait. Is that true? In crypto, Cobb-Douglas comes up a bunch? Paul: Oh, it comes up all the time. This manages entire economies at scale right now, as we're speaking. It's quite fascinating. Yeah. It's popping up again in places, I was just like "Who'd have known. Here it is." Yeah. So all right, these developers are well paid, well regarded. We can't disagree on this. They made a TV show about them that's literally called Silicon Valley. So why do you want to focus on increasing productivity if that's the case? Because they're already well paid, they're already well treated. Maybe this kind of will foray us a little bit into the economic side. Why is productivity so important to you? Nnamdi Iregbulem: Yeah. Productivity is important because I think it's the side of the sort of equation that you can continue to grow over a long period of time. And what I mean by that is if you think about this notion of a production function and you think about it having two elements in one kind of version of it, you can think about the number of developers that the ecosystem employs and the productivity of those developers. And you multiply those two things together and that's how much software you get out on the back end. And so, one refrain you might hear is, "Well, why don't we just grow the number of software developers?" And there's all sorts of initiatives out there to do that, and I'm very much in favor of all of those things. Yeah. I would love more people to be technical, I'd love more people to write code. I'm not opposed to any of that. But there are just soft or hard limits in the number of people who can be software developers, the proportion of our economy that can be software developers, the proportion of labor force I should say. And if you're not careful, it's easy to sort of grow the number of developers and actually see productivity decline. There's this really interesting book called the Mythical Man-Month, which is very well known amongst developers and project managers and whatnot, that talks about this notion of there's sort of this indivisible unit of work that you get down to at one point and that can't be subdivided further. And so, growing the team doesn't help you necessarily get the work done any faster. And it's easy to have too many cooks in the kitchen and adding more cooks at that point just makes the cooking time longer. And so, I think everyone who's worked on a software team knows what I'm referring to here. And so, I think we have to be very careful about just sort of throwing more people at the problem, whatever that software problem is, and we have to always keep in mind with the productivity side of things. And so, that's why I tend to emphasize the productivity side. It's not to say there shouldn't be more developers, too. Paul: So your argument is we can kind of say the total output of the software world right now is the amount of labor we have times the productivity. And so, the argument is sort of we're getting to this point of the marginal product of labor is vastly lower than the marginal product of productivity. So we should be focusing on this parameter if we want to make- Nnamdi Iregbulem: Yeah. Yeah. Yeah, exactly. So if you just grow the number of developers just sort of unthinkingly, the marginal product of that additional unit of labor is not going to be very high. And so, we need to treat the productivity of labor as its own thing that's worth optimizing and worth growing over time as opposed to just the total kind of labor force, so to speak. Paul: And another interesting thing you mentioned was that we can continuously improve that productivity. It's sort of a learned wisdom that we have as a industry. If you look back to how we made websites and how long it took to make something move on the page now, now we have all these frameworks and they abstract a lot of things away, for good or bad, we can get into that. And then I can make a react website homepage in an afternoon these days. That is vastly different from the PHP days 10 years ago. So yeah, stepping into the frameworks a little bit, do you think that frameworks are a linear add to that marginal product of productivity? And why or why not? Nnamdi Iregbulem: Yeah. This is a good question. And yeah, there's probably a nuanced answer that says it kind of depends on the framework and blah blah, blah. Look, I would say that there's no shortage of web frameworks out there. I've used many of them. I've invested in some of them. I'm very supportive of the continued development of that ecosystem. I think it's fair to say that a lot of them don't necessarily move the needle much compared to what's come to date. And at the same time, there's this tendency in web development to kind of like the new shiny object. They want to try out the new framework or whatever it is. And there's always this question of, "Is all that actually moving the needle forward?" I think those are all very fair questions to ask. I think there's one version of wisdom here, which is basically use whatever you're kind of most comfortable with. Don't feel like you need to go learn the new thing just because other people are. I think that's roughly right. And that's true not just in web development, by the way. That's true in just across software development in general. Paul: That's just productivity 101. Nnamdi Iregbulem: Right. Yeah, exactly. But unless someone's pushing the ball forward, the ball doesn't get moved forward, so there's sort of a balance there. Paul: So if we're talking as well about what we're actually producing and the units that we're talking about, you mentioned the Mythical Man-Month and breaking down, "How do we classify these units of work and does this framework actually add, does it subtract?" So there's this whole concept of intangibles that you mentioned when I was looking at your work. What is an intangible, and how does that relate to what we would consider that which is tangible, that we can kind of wrap our heads around? Nnamdi Iregbulem: Yeah. So this is an important distinction, and it's increasingly important as our economy becomes increasingly kind of digital. But an intangible, in contrast to a tangible, is just some form of output that doesn't necessarily have a physical representation. Typically, it centers around ideas or things in our head or things that we might have written down somewhere, but again, don't really have a sort of physical representation. So for example, a patent that you file is a sort of intangible, in the sense that the patent itself is not the thing that the patent is describing. The patent is its own sort of mental representation of an idea or a product or what have you. And because humans have certain mental capabilities, we're cable of thinking about these things as separate from the actual physical thing it kind of represents, and it has sort its own value, its own kind of production function, so to speak, what have you. Software also falls in this category. Software, at the end of the day, is just an idea that somebody had and they eventually wrote down into a code editor and then it happens to run or compile. It's not a physical object out in the world. And the reason this is an important distinction versus the tangibles is because what constitutes output or production in the realm of intangibles is very different from the world of tangibles. So if I take a tangible example, a car, two cars is better than one car. We can debate it, is it 2X better than 1 or is it 1.9X better than one? But it's unambiguous that two replicas of the exact same car are better than one or are roughly twice as valuable as one. And that's true of most tangibles. On the other hand, in the world of intangibles, if I go get cloned whatever repo, I've not added value to the world, but I get cloning a repo. The value was added when that code was originally written. And so, the only thing that has value in the world of intangibles is novelty, so new ideas, new patents, new software. And so, when you think about the world that way, you realize that it's very, very important to focus on, "How do we ensure developers can generate new software, not merely sort of scale existing stuff?" If that makes sense. Paul: Absolutely. I feel like we can think of it as the idea space is shrinking. Nnamdi Iregbulem: Yeah. It could be. The low hanging fruit could have been picked, et cetera. Paul: Yeah. The world of math is limitless. I don't know what the researchers are going to find out next week about how we can store information on God knows what. But at a fundamental level, the amount of things that we could foray into computers for a week, I feel like the amount of change 10 years ago between 2012 and 2014 is way drastic than it is now. And that has a bunch of reasons. And do you think Moore's Law has anything to do with that, or the speed of computers or the availability of computing? Nnamdi Iregbulem: Yeah. It's probably all of the above. Moore's Law is definitely a core pillar of that, which for people who... Most people probably have heard of it, but it's the idea that these chip manufacturers, these semiconductor manufacturers, can fit in more transistors on every computer chip every year. And it roughly doubles on some sort of regular cadence. And that has been generally true, historically. Maybe it's slowed down a little bit, but it's still kind of ongoing. And if that's the core driver of how capable computers are, then on some level, as long as that continues, then our computers will get more capable over time. And so, that is one driver of it. There also are these sort of paradigm shifts in how software is getting created that have led to another very quickening pace. Some people talk about this notion of software 1.0, 2.0, 3.0. And I forget exactly what all those mean, but the big shift has been from thinking about software as something that is something that a human has to write the full application logic themselves versus a world where a human writes a machine learning algorithm, and that machine learning algorithm is sort of the core asset, so to speak. And then, it is figuring out for different domains and different situations, "What is the actual work to be done? What is the actual code to be run?" Whatever it is. And you can do a whole podcast on the implications of that. But I think that, in the world of ai, et cetera is a big, big accelerant. I think more people just getting access to computers and whatnot is another big accelerant. And then, there's sort this combinatoric explosion that happens when more people get access to more computes and there are more sort of paradigms for assembling that compute. People throw around this term singularity. But even well in advance of getting to a singularity, things start to accelerate. And so yeah, it's kind of wild times. Paul: Yeah. We're in it now. And I don't know how much you research into the AI stuff, but we're getting companies, this is not a new company on the block, it's been around for a little bit, but these analog chips that are processing AI speeds at just 10, 100-fold that we could ever imagine on the digital scale. It's like, "Yeah, it's coming." And I wonder how it's going to affect our output and our productivity. We're getting a taste of it now with Copilot on GitHub. Have you played around with that much? Nnamdi Iregbulem: Yeah, yeah, I have. And I probably had a healthy dose of both skepticism and excitement about it when it was first announced. There have been some things like Tabnine, et cetera that existed prior to that. But Copilot is very good, I think. I've been very impressed with its capabilities, and it's only getting better over time. And I think we'll get to a point, even though I know a lot of developers don't love these tools, I think we're going to get to a point where it's just going to feel like auto-complete on your iPhone, where it's strictly better than not having it. It's not perfect, but it's definitely just a better experience and it becomes sort of a default thing on all the time. Paul: But the auto-complete is never going to finish your sentence. CoPilot is never going to architect your thing for you, but it's going to get you along. Nnamdi Iregbulem: I don't know. Don't sleep on it, man. Replit announced some interesting AI-powered features a few weeks ago that look very impressive, and they have a lot fewer resources than GitHub does. So yeah, I don't know. I think with these sorts of things, betting against the kind of upside technology case has typically not worked out well. Maybe you can get it right in terms of things taking longer than other people think they will, but they generally happen on some timeline. Paul: I totally agree with what history has shown us. The only voice in my head that wants to disagree with you though is there's this law or collar area, I don't know what it's called or who wrote it, but it's essentially that humans always overestimate the benefit of technology and underestimate the cost. And when we're doubling our transistors and you're telling me, "Oh, I remember when my mother got her first phone and it could take a picture, and I was over the moon. I was like, 'I can't believe that's possible.'" And now I'm like, "There's a Netflix movie filmed on the iPhone 12." So that's a very exciting time to be alive. But if we're getting to the point, maybe that magic might fade a little bit and we might, for a lack of a better phrase, be brought back to our senses about what's actually important. But now we're getting into some hippy stuff, so I don't want to go too deep. Nnamdi Iregbulem: Yeah, fair points. Yeah, again, it's a whole podcast that you could do or more on that specifically. I will say I very much hear the point, especially with mental health and all these things that people are talking about these days, there is an element of this that has been, I think, destructive on that level for sure. On the other hand, I think about places outside the US where the kind of economic output that's created by all this stuff is still very much on the strictly positive marginal benefits, let's call it. And so, I think in the US, yeah, maybe we're on the diminishing part of the curve, but other people are not. And so, there's still a strong benefit to this stuff, I think. Paul: That's a very fair point. Yeah. We're in a bubble here in terms of how much does technology interact with our lives and how does it affect it? We're kind of the Guinea pigs, which is fine. Another cool thing about Copilot that I want to pick your brain about too is it sources a lot of its diffusion capabilities to produce these models and these texts based on what other users are uploading to GitHub, right? So its knowledge base is always improving, it's always being updated. And do you think... Humans are creative. There's some people that think our creativity even comes from other dimensions. There's some brain research out there that are like, "We see neuro signals come in and then we don't see them go out. They're going somewhere, we don't know where they're going." And so, could a singularity exist if that external force or external pressure is always seeding some sort of originality from the human spirit that needs that feed up from the bottom of the pyramid? Nnamdi Iregbulem: Yeah. So you could take this... I could see many sides to this. On the one hand, if I take for example a lot of the generative AI stuff that's happened this past summer and the past year or so, the inputs to that have all been sort of human visual creations, art, photography, et cetera. And in that sort of domain, yeah, I think that humans have to be the input on some level because what the models generate back is going to be evaluated by humans. And what humans are really trying to get back is something that looks like a human created it, which means that the model needs to be trained on things that humans create. So it sort of- Paul: Because it feeds back into the loop. Nnamdi Iregbulem: It feeds back, yeah. And these things tend to degrade. If they start learning on stuff that they themselves created, they start to degrade very quickly for various subtle reasons. And so, that's one side of it. Now there's another side of it, which is if I look at all the stuff that open AI has done and DeepMind around being able to, in the case of Deepmind AlphaGo and all these things, they eventually got these models to the point where they were never actually learning from human games. They were just doing self-play, and all the only input that they needed were the rules of the game, so to speak, where the checker pieces or the Go pieces or the chess pieces could go or not go. Paul: Because that was in discrete finality that they could evaluate on. Nnamdi Iregbulem: Yeah, exactly. There's something discreet about the search space and the different moves that you can make. And so, you can just do that in a closed loop, no human input required. And a lot of what it gets out at the end of the day does look like very human play, but it never actually trained on human input. So I think there will be domains where these models will be in a closed loop able to just generate very interesting behavior. I think there'll be other areas where they will require some level of human input. Paul: Right. I feel like after riffing on this a little bit, I feel the same way, because in GitHub we'll go there and there's some open source projects that are improvements, they're frameworks, they're productivity boosts, and that's kind of this closed loop productivity sort of oriented thing. You can test, "Does this give you better response times with a random basket of requests that you do?" God knows what, but there's also creative things like people posting on GitHub that's like, "Hey look, I found a new way to glitch out a monitor and make a weird static art." That's completely original. And speaking of which, if you're enjoying the podcast, we have, like I mentioned earlier, we have open source creators come on and talk about their projects, what they're working on and all the cool features. So come through, we'll talk about all the things they're making, share some features, and we'd love to see you on some other episodes. But yeah, back to the creative part of GitHub, it's going to be a bilateral system I guess, because you're going to need to have the input and you're also going to want to iterate and complete it. I have a hard time believing that it's going to be completely singularity and closed loop, but I'm very interested to see where it goes. What do you think is the number one drain that is sort of unnoticed on our productivity as developers? Nnamdi Iregbulem: Yeah. I don't know how much it's noticed or unnoticed, but it definitely doesn't get enough attention, which is just the roughly 40% of developer time that goes towards maintaining existing code. Going back to my point about productivity in the world of ideas and intangibles being related to new stuff versus just more of the old stuff, if 40% of developer time is just maintaining existing code, that's a lot of effectively lost productivity that's going into technical debt, bad code, and other sort of things that sap your time as a developer. And a lot of people don't realize that when they get into software development. They think they're just always going to be working on new features and new cool stuff, and then it turns out they're mostly taking Jira tickets. Paul: Oh yeah, there was a time we all thought we were going to be doing that. No. Nnamdi Iregbulem: Right. And so, I think finding ways to either reduce the time it takes to maintain code or just create code that breaks less in the first place is an area worth spending time on. And it's not that I have particular solutions per se, but I think it's super, super important. And there was actually a research paper that I think I mentioned in the Manifesto that talks about this, that if you were to measure the value-add that a software developer provides to their organization as measured in terms of the value of the company they work for, their market capitalization or something, that a developer that's focused purely on maintenance is actually probably destroying value in totality, destroying value as in their wage minus the actual productivity that they're generating is they're basically not covering their own cost, versus a developer that is actually doing a healthy balance of new and maintenance stuff certainly is generating value. So there is some data that backs this up. Paul: I'm just curious for my own selfish purposes now, what does that data look like? Who collects that data? And how can you evaluate something that to me feels so ethereal? Nnamdi Iregbulem: Yeah. And this is where the econ part of me gets excited, but it's sort of hard to grock for most people because there is a little bit of... Well one, there's these econometric statistical methods that people use to sort of extract these values and coefficients and whatnot. And then, there's a little bit of a, let's just say there's a whole industry of economic research that if you just described to the average person, they would just say "That doesn't make sense. You guys are doing stuff that's..." It doesn't pass the smell test, but among economists it's considered to be totally fair. So let's just say it's a combination of those two things is how you get to those kinds of numbers. But it's typically economists, typically either working at an institution of higher learning or the Federal Reserve or something like that, and they get access to these data sets oftentimes from public companies that disclose some of this stuff and they're able to extract these sorts of insights, but yeah. Paul: I was expecting you to say that developer is definitely paying for themselves, because if they don't have the product, the company's going to die. And then, hey, that's how I felt when I was maintaining legacy code. I was like, "Wow, I'm so important." Nnamdi Iregbulem: Probably the most important person in the world, yeah. Paul: So would you say that if you're on a team developing every minute of, or that's too small, let's say every hour, easier to wrap your head around, of "I'm going to do this because we just need to get it out and I'm going to come back to it later." Every hour is a 1, 2, 1 + X, spend later down the line, because another team, another, maybe it's you who wrote it, needs to get into that mental context, they need to reevaluate what needs to be done. Would you say that's a general truth or do you think differently? Nnamdi Iregbulem: As in the overhead that comes from context switching? Paul: Yeah. Tech debt and then since we're talking about maintaining code, going back and maintaining that, fixing it, putting in the right logging, whatever it might be. Nnamdi Iregbulem: Yeah. I think that's probably a good way to think about it. And the X, I don't know exactly what that number would come out to, but in terms of if you push new code, there's sort of this long tail of maintenance to that code that sort of happens over time, and that could be the next year, two years, five years, depending on how long that code actually gets used. And so, it is important for every commits to the main line, just making sure, "Is this actually necessary and what headaches could this cause down the line?" Because software is not something that just exists at a point in time, it's a system that exists over time. And so, everything you do has kind of long-term implications. Paul: So you would say in general you always want to take, "I'm going to do it later" with a grain of salt because that in general is going to play out to 1 + X. We don't know what the X is, but it's going to be more than one, probably. Nnamdi Iregbulem: Yeah. These are getting to what your discount rate is and that stuff, but yes, there's an X and the X is not zero. Paul: It's a hard problem for... Me, even if I'm doing, I guess, a personal project, that matters less, but you just want to... I'm a big cowboy. I love cowboying stuff up into prod, and then hating myself six months later. But it's also depends on the business you're in, because sometimes that's necessary. You can also document something because you're like, "Hey, these five REST endpoints, this is my company." And then six months later using Graph QL, I don't know, just something that's not REST, and then all your documentation time went out the window. So it's a balance. I guess it depends on your group, it depends on your company. There's a lot of things. There's no single truth here. Nnamdi Iregbulem: Yeah. No, I think that's right. I think as the organization gets larger, I think it gets harder to do the cowboy thing, but yeah. Paul: Yeah. It gets harder or it just gets more and more frowned upon and people won't let you do it, even how hard you want to do it. So all right, if we want to hone in a little bit on what are things that people can do to increase their singular productivity, if somebody's listening to this and they're like, "I feel inspired. This is the parameter I want to improve on." Are there resources that you would typically point people to? Or if you're consulting for a company, a point that leader use give to their employees? Nnamdi Iregbulem: It's good question, and I'm usually not in a position to sort of tell people exactly what they should be doing on an individual level. I will say the point I made earlier about "Work in the language or framework or whatever that you're most comfortable with" is always sort of good, generic kind of advice for personal development productivity. It's funny, there are certain things that you wouldn't think about that are personal, that are actually more team level, but that enhance individual productivity. So for example, this notion of how I mentioned earlier at the start that if you put too many developers to work on the same sort of thing, the marginal products of that last developer starts to approach zero. Well, one thing is just don't be that last developer. Don't let your manager or whoever throw you on something that already has too many people on it. Be thoughtful about the kind of projects that you apply yourself to and where you could be most individually impactful. Some of the biggest gains of productivity come from just picking the right thing to work on in the first place, as opposed to how you go about working on it, if that makes sense. Those would be some examples, but yeah, yeah. Paul: Oh, I think those two are huge. I think a lot of times people will try to reach for the fastest running framework or the most talked about one, and it just brings us back to what you said at the beginning of the podcast, "Use the one you're most comfortable with." 99% of the time it's fine. Even if it's Python, it'll be fine, I promise. We have fast computers now for the most part. So what about busy work? I'm really curious how you think about this, because I feel like I have tons of busy work. I'm sure lots of developers out there feel like they have lots of busy work. What is busy work, and how did we get to the point of having this thing that we call busy work that just feels like an eternal waste of my brain juice? Nnamdi Iregbulem: Yeah. Busy work is a very natural consequence of this shift towards knowledge work. And I have an author that I really like called Cal Newport, who writes a lot about deep work and the kind of modern knowledge worker, and all the different ways in which that worker is being hampered by the way we've kind of unthinkingly ended up in where we currently are and busy work is the core component of this. He sort of refers to busy work as "shallow work," in contrast to deep work. And he kind of emphasizes that you should be spending as much of your time as possible on deep work, and that it should be a carved out thing on your calendar that gets done every day. Whether it's two hours of deep work or four hours or six hours of deep work, whatever it is, it should be calendared, it should be sacred, because that's where you're most productive and that's where you're generating the most kind of differentiated value versus shallow work. He kind of defines as basically anything you could train a new college grad to learn in a very short period of time is basically shallow work, so email and Slacking, messaging people, and different kind of minor tasks that they do have to get done on some level, but you should be doing them in the smallest kind of timeframe and you shouldn't be allowing those things to impact your deep work time. The problem most people run into is that they intermingle these things too much, and so Paul Graham talks about manager versus maker schedule or whatever. Even if you have the make schedule, you don't have too many meetings, if you're constantly bouncing between writing code and writing email, you're not maximizing your productivity at all. And so, this is something you have to be really, I think, conscious of and proactive about protecting your kind of deep work time and not let the busy kind of shallow work take over. Paul: Deep work, you're actually producing something. And that kind of brings me to this next thing. I wonder if you've heard of this concept, but there has been some research that's come out I think recently in the past year, I don't want to say two years, it might have been two years, but past year, where some astrophysicists are saying the next type of matter or phase of matter, is it the fifth phase that we're on now? That we haven't really grocked with is information. The next phase of matter is information. And A) I'm really curious to see what you think about that. But B) relating to this example, if deep work, what you really need to focus on is producing matter, you're actually making something that wasn't there previously that now we as a collective, as a human race can now either learn if it's documented or do whatever, you're actually producing this new phase of matter. Do you buy that? What do you think? Do think information is sort of a concrete entity that takes up possibly even mass in the universe, because there's something inherently different between organization of matter information and the lack of. Nnamdi Iregbulem: So one of the things about information that makes it really interesting is the fact that you can write it down in an equation in the same way you would write down sort of physics of other sorts into equations and do math on it and generate theories. And Claude Shannon was the sort of guy who started this whole kind information revolution and showed that you could think about this stuff in a pretty rigorous way. And so, one part of me feels like that's a subtle wink, wink from the universe, that, "Hey, there's something here. There's something to this information stuff. It's not just this human concept, but it actually has some sort of universal kind of relevance and meaning." The other thing that gives me some, it just feels like a wink, wink is if you look at a lot of the theories about black holes, a lot of them do have to do with information and information being lost as it goes past the event horizon and falls into the black hole, and the fact that you can't pull it out, and light and causality and different things having to do with information and how it kind of passes between different parts of the universe. So again, feels like subtle hints that this information thing is important and relevant and could be as important as a either phase of matter or a just sort of core concept of the universe. How we take that and relate it to our daily lives I think is always tricky when it comes to astrophysics and all this stuff. But I will say though that I think a theme of this conversation has been our economy is moving more towards this sort of digital era and information ideas. These are all basically the same concept. That is a very large share of our GDP effectively today of our economic output. It's not measured in stuff that has mass and you could weigh on the scale, but it's this information and these ideas and different things. So I do think they're really worth understanding if you really don't understand how the world works today and how it's going to work forward. Paul: It almost makes me uncomfortable when I try to understand it, because it's just such a non-intuitive idea that you're producing something, but it's also nothing. It kind of brings me back to that intangibles thing. It's really nothing. And you're right, it is just a thought, it's just an idea. But is that idea actually, does it have mass? Is it tangible in some other vector or method of thought? This is billiards talk. We're getting into pool room talk at this point. If people wanted to find out more about your Developer Manifesto, where can they go online if they want to read it, watch it, talk about it? Nnamdi Iregbulem: Yeah. So you can find it in a couple different places. You can find it on my personal site, whoisnnamdi, N-N-A-M as in Mary, D-I.com. You can find it, I've given a talk version of it at a couple different video conferences over the years. Those are all on YouTube. And I also recently started a Substack, which is just all the same stuff I post to my personal site, too. So if you prefer subscribing there, you can do that, too, whoisnnamdi.com. Paul: Substack, right? Nnamdi Iregbulem: Substack. Yeah, exactly. Paul: Gotcha. Awesome. Well, Nnamdi, thank you so much for taking the time to come on. I'm sure a lot of people are going to listen to this and be instilled with some existential crisis and I apologize to those listeners, but it was really awesome to hear about this economy of programming scale. It's a weird thing. It's intangible yet tangible at the same time, so I appreciate all your thoughts and your time. Nnamdi Iregbulem: Yeah man, no problem at all. And now, I'm going to go down a rabbit hole figuring out how Cobb-Douglas applies to crypto. This is a new thing. Paul: Oh, yeah. I'll send you a link after. Nnamdi Iregbulem: Okay. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts.