Soft Skills Engineering - Episode 422: Moving in to big tech and building support

Episode Date: August 19, 2024

In this episode, Dave and Jamison answer these questions: A listener named Maria says, Hey guys! I am a software engineer working in web development at a small/mid-sized SaaS company. I come from a non-traditional background (self-taught, no CS degree) and I currently have 6 years of experience under my belt, the last 2 years of which I have been tech lead of a small team. I want to move into big(ger) tech, but I’ve not worked on any large scale systems so far. The biggest thing I’ve worked far had a user base of ~100k users and traffic would typically max out at ~2k concurrent users at peak times. Due to the nature of the work I’ve been doing at smaller companies (and also thanks to this podcast!) my soft skills are strong - I am good at working with lots of different people, I can deliver broad/vague projects, and I’m comfortable tackling ambiguous problems. I think my technical skills are probably decent, I’ve spent time learning system design and best practices, and I’ve put in the work to study CS fundamentals. Thing is, I would have absolutely no clue how to maintain an API that needs to handle 100k requests per second. My hands-on experience of concurrency and threading is basically just simple ol’ async/await. Grinding Leetcode aside, what can I do to make myself a stronger candidate for breaking into big tech? How can I be competitive against folks who already have big tech experience? Are there any projects I could do that would sway you as a hiring manager? I know it’s terrible market timing, I am just planning ahead. Love the show, thank you for making me a better engineer! :) Hi! I have been working at my fully remote company with around 100 people in the engineering department for over a year now. While I see a lot of really smart people here, the code quality is lacking. We’re moving from a monolith powered using an opinionated framework to small services powered by a lightweight library, so there are fewer guardrails. I have many ideas on how to structure the code, add layering, etc., so the code is easier to understand and maintain. However, the company is very hierarchical, and despite being at a senior level, I don’t talk much to anyone higher than my lead. There are no staff or principal roles. There are also hardly any meetings, and the only ones I attend are within my small team of five people. Most of slack channels for teams are private, and I don’t ever see company-wide ideas like that thrown in the “general” channel. I initially wanted to present this to my team first, but I am afraid that if they don’t like it for some reason, it will be awkward to take it to higher management afterward. How can I share my ideas with a wider audience and ideally get this approved as part of my work so I don’t have to work on it in my free time?

It takes more than spending five minutes searching your terminal history for a four-character command to be a great engineer. This is episode 422 of the Soft Skills Engineering podcast, where I'm your host, Jameson Dance. I'm your host, Dave Smith. Soft Skills Engineering is a weekly advice show about all of the non-technical things that go into the technical field of software development, like saving time and being efficient. The four-character letter you were looking for is HIST. Yeah, don't repeat yourself can take a lot of time. That is true. I have the sniffles today, if you can't tell.

So sorry, we're doing a show anyways. You can't stop me. It's just going to sound slightly gross, slightly moist. Not the word. Yeah, I like how we seem to have collectively settled on that word as a gross word in the past few years. Yeah. Dave, do you want to thank our patrons?

Yes, here we go. These are the people slash entities slash hyper-conscience shades of color that support the show at a level where they get a weekly shout out. They are Hawk Tua, some kind of compound banana family emoji. Javier Gonzalez, Chewy, Ted, Timbrel,

becomeaseniorengineer.com, Unsalted French Fries are morally objectionable. Dan from Drone Deploy, Chase W. Norton, level up your type script with type hero.dev never is not just a crater on mars flamingo emoji i like chicken i like liver miamix miamix please deliver trash panda the computer science book.com kyle boss can't see dodds nivar is not just a planet in the vulcan system jenny kim owen chartle the stochastic parrot helicone.ai the best observability tool for ai red panda is best panda everyone in this list question mark jonathan kings and i beautiful

of functional user documentation, a second two-time shout out to Will Angel, is a great engineer. Nice. Travis, Brayden Keyes, Lies, Damn Lies, and Product-Driven Deadlines. What's your favorite salad is the final name. I had a lovely Caesar salad this week. It's a classic. That is monkeying with the format of the show, which is we answer two questions. And so you found a way to jailbreak it. We answered multiple questions. Dave, should I read our first question? I was hoping you would.

All right, I will read it. This is from a listener named Maria who says, Hey guys, I'm a software engineer working in web development at a small to mid-sized SaaS company. I come from a non-traditional background. I'm self-taught with no CS degree, and I currently have six years of experience under my belt, the last four years of which I have been a tech lead of a small team. I want to move into big parentheses bigger tech, but I've not worked on any large scale system so far. The biggest thing I've worked on had a user base of about 100,000 users and traffic would

typically max out at about 2000 concurrent users at peak times. Due to the nature of my work I've been doing at smaller companies and also thanks to this podcast, my soft skills are strong. I'm good at working with lots of different people. I can deliver broad or vague projects and I'm comfortable tackling ambiguous problems i think my technical skills are probably decent i've spent time learning system design and best practices and i put in the work to study cs fundamentals the thing is i would have absolutely no clue how to maintain an api that needs to handle 100 000 requests per second my hands-on experience of concurrency and threading is basically just simple old async await grinding leetcode aside what can i do to make myself a stronger candidate

it for breaking into big tech. How can I be competitive against folks who already have big tech experience? Are there any projects I could do that would sway you as a hiring manager? I know it's a terrible market timing. I'm just planning ahead. Love the show. Thank you for making me a better engineer. You are welcome. Awesome. Can we just ignore the question and focus on all the praise? That felt good. Yeah, it did feel good. I'm going to say you said your soft skills are strong, partially thanks to the podcast. I feel like I could go two ways of this. One is like make a joke about how it's actually all thanks to the podcast and another be self-deprecating and say no it's all you and none of it is the podcast and the third one will be a meta analysis

of your joke options yeah i will i will let you pick which way i went just imagine which one of those we went with oh this is very a very thoughtful question i have an immediate reaction to this question, which is that I think your understanding of what it is like to work at a big tech company is probably skewed. It's like if you think of the Air Force and then you think of fighter pilots because they're kind of like iconic, right? But there's a lot of people who work at the Air Force who are not flying fighter jets around. And just like every big mega tech company has these very high capacity services that have these outrageous technical requirements, you kind of think of that as like, well, that's what happens at a big tech company. I would say probably the

majority of engineers working at giant megatech companies are not directly on the cutting edge of this massive scale. And it's all just internal stuff, this giant web of internal systems. I don't know. How does that ring to you? Does that feel right? I know you worked at a different megatech company than I did, though. It rings like a bell. Yeah. It's so hard to anticipate actually the things that will be required of you on the job. And I spotted in this question one false assumption about the challenges that will be or the experience that will be required in order to come to this job. And that was the biggest thing I've worked on. Oh, no, what was it? I wouldn't have the first idea of how to maintain an API that needs to handle 100,000 requests per

second. And it's like, yeah, you think I know exactly why you're thinking this. You think, okay big tech co they have massive concurrency tons and tons of volume i have to show experience doing that well this is a false assumption because it turns out handling massive volume usually that's all been solved for you yeah yeah like that's already maintained you just keep doing the stuff that the team that maintains it does exactly like these companies have built tools and platforms that they use internally that make all of that stuff just work for developers and and in fact they even have guardrails in place where if you do something which it's hard to do something that would break that but if you do something that will bring the you know request

per second down they'll usually catch it in with automated code review and stuff like that that was my that was my experience anyway and so that's not the hard part it was not my experience we certainly let some stuff through okay okay yeah but but it certainly wasn't the challenging part Because that's basic kind of reusable table stake stuff that developers at that company have already figured out. And now you're working within the framework that has already been established to do that. Yeah, exactly. You're not going to have to sit down and say, okay, we have nothing.

I will now from scratch create a service that will handle 100,000 requests a second. That would be so stupid, actually, if you did that. It would be so stupid to build that from scratch. Oh, yeah. Because it's like, yeah, this already exists. All of our services do that. So what will be hard, though, is that most of these companies, like I'm thinking here, yeah, I think it's probably, I haven't worked at, I've only worked at one, Megatech Co.

But I think most of them have interesting non-public development practices and frameworks. Like at the company I worked at, we had our own Java-based web service framework. It wasn't Spring. It was its own thing. We had our own build system. It wasn't based on GitHub actions. It wasn't based on Maven or Gradle. It was its own thing, you know, and we didn't use deployment tools that are out in the open, like GitLab stuff and GitHub and CircleCI and all these things. We had our own internal thing. So the challenge was actually,

how can I quickly ramp up on new technologies where the documentation might be sparse and there's not a body of public work that I can draw on or a community that I can draw on that's bigger than my own company yeah a lot of the public kind of open source stuff is like derivatives taken from these yeah yeah like someone sees how google solves a problem and they say ah i will make a polished well-documented open source extensible version of that yeah and it doesn't have all the cruft of like this random business case that came up 15 years ago that is still like critical and like corporate login integration and yeah yeah internal stuff pci valve i don't know Yeah. So that's just to say that the assumptions you might make about what skills you need to

develop are probably wrong. And the best way to figure out what skills you actually need to develop are to talk to people who work at these companies who participate in the interview process and ask, you know, what do you ask your candidates? I think there is some amount of like operational complexity and kind of on-call handling stuff that maybe doesn't come up as much at smaller companies. You could read the Google SRE book for a very specific view of what that is like, but you might be able to kind of squint and say, okay, like at least I know this is a big deal and there's going to be something around that. And here's a way to kind of figure out some expectations. The other thing that is going to be different, I think caters well to

the stuff you are good at, which is there are going to be so many people. These big tech companies have tens of thousands of engineers and the systems they work on are enormous, not just in scale of how much traffic is going to them, but just like how many pieces there are, how many different parts of it are worked on by different people. And there's no way you're ever going to be able to fit it all in your head. But a big part of the job in engineering at a large tech company is talking to other teams and figuring out what on earth they work on and why is it important to you? And how does the thing you're working on impact them? And how do you trade off against this other team you just found about the other, like last week that wants a completely

different thing? And so I actually think your description of your skillset around working with lots of different people and handling ambiguity fits perfectly with a lot of the challenges at a big giant tech company. Yeah, it totally does. And so I would double down on that at your current company and look for opportunities to work on projects that have a bigger dependency tree than just one or two engineers working on it. And the reason I say that is because when you go interview at one of these big tech companies, you're going to have to distill years of experience down into anecdotes that really punch and tell people what they want to hear. And so like an example of that would be, you know, I led a project that involved three teams with five engineers on each team

that had dozens of dependencies between those teams. And we successfully delivered this project over the course of three months. And it had this impact on our customers or on our business. And if you have experiences like that, that you can turn into punchy answers to questions that check their boxes for, does this person manage complexity well? Are they highly technical? And can they get other teams to march effectively together? Then you're very likely to be more successful in the interview process. At the end of the question, Maria says, grinding LeetCode aside, which I think is kind of a joke, but also maybe indicates there's this idea that I have to be really good at writing the code. And I feel like understanding and

building systems is maybe more important at these megatech companies than just like cranking out the tightest individual lines of code. I think that's kind of what we've been talking about anyways but so so there is a a growing body of resources around kind of architecting large systems some of it is sort of based on the interviews at these giant tech companies some of it is based on how the products actually work if there's one book i could recommend to you it'd be designing data intensive applications which is sort of about databases, sort of about scale and a bunch of stuff that is useful to understand if you're working somewhere that has gigantic systems. But the meta point here is it might be worth it to

search out resources around just how these big systems work, both for interviewing and just kind of learning itself. We talked a little bit about how grinding leak code might actually not be the most important thing but i disagree i i think that really yeah and and i'm i'm basing this on my experience as an interviewer at my megatech co and hearing anecdotes of others who have interviewed from other megatech cos the the leet code style grind out code to solve a a technical problem is still like 60 to 70 percent of the interviews that i hear about it's almost like that first stage you have to get through, at the very least, is that you have to demonstrate that you can really crank out code to solve a complex, challenging problem. Okay. So I'm maybe being

idealistic and saying like, well, yeah, the job is this. You're saying it doesn't matter how good you are at that if you cannot get past this hurdle. That's right. That's exactly right. And I think you're right about the job. You know, after I got into my Megatech Co. for four years, I realized that, yeah, there were some pretty interesting technical challenging problems, but probably none of them were as hard as the problems i got during the interview and so i also interpret you saying my megatech co as saying and by the time you left it was yours like you became the owner i did own some stock in the company for a few hours yeah i became an owner and yeah so even and and that's what that's what you got to go figure out and this is why i

suggest going and finding interviewers at these companies make friends with them and ask them what they assess for and how they do it. Because in my case, I was surprised. We really expect these people to be able to crank out solutions to coding problems. And of like a five or six hour interview, probably four of them would be dedicated to just straight up coding. And it also depends a lot on your level. But with the years of experience that Maria has, which is six at my company, this would have been totally the case. At least two thirds of the sessions would have been just straight up coding. And then of course they also had behavioral questions to assess your alignment with the company culture. And then like you said,

Jamison, system design questions, which are like design a badge system for a company that's distributed across the world, you know, like building security stuff, you know, things like that and or design a sandwich making robot that takes online orders to make sandwiches you know just design the software part things like that systems like those are great problems to practice and most people do not have a lot of experience practicing those because it's not the thing you do every day you know you write code every day and so you can crank out code on a whiteboard for an interview no problem but when they say design the system you're like well i only design the system like a couple times a year you know like we just often we aren't often starting from

scratch. And so that's something you really need to practice. Yeah, that's fair. Well, have we answered the question? I think so. Go for it. Oh, and I got to pitch just one more thing. There are actually companies out there who you mentioned, Jameson, that there's a growing body of resources. Well, one of those resources is there are companies who you can pay and they will provide you mock interview sessions with people who they have hired as contractors who either work at currently or recently worked at a megatech co then you can choose so you can say hey i want a mock interview with a system design question from a google interviewer for someone who has about six years of experience and they will pair you up with someone who will then do

an interview and write you up some feedback on it and it's expensive a lot of these are like multi-thousand dollar costs to do to buy a batch of interview sessions and coaching but it can be worth it and if you're really serious about it and the money and you have the money i do think it's a good idea it'll give you practice yeah well good luck good luck i think they would be lucky to have you dave you want to read our next question i do okay this comes from an anonymous listener who says hi i have been working at my fully remote company with around 100 people in the engineering department for over a year now while i see a lot of really smart people here the code quality is lacking we are moving from a monolith powered using an opinionated framework

to small services powered by a lightweight library so there are fewer guardrails i have many ideas on how to structure the code, add layering, et cetera, so the code is easier to understand and maintain. However, the company is very hierarchical, and despite being at a senior level, I don't talk much to anyone higher than my lead. There are no staff or principal roles. There are also hardly any meetings, and the only ones I attend are within my small team of five people. Most of Slack channels for teams are private, and I don't ever see company-wide ideas like that thrown in the general channel. I initially wanted to present this to my team first, but I am afraid that if they don't like it for some reason, it will be awkward to take it to the higher management

afterward. How can I share my ideas with a wider audience and ideally get this approved as part of my work so I don't have to work on it in my free time? That's sad. One of the benefits of working at a larger company is often there's like a larger shared space to hang out. I mean, I know you still work with a core small team of people no matter how big the company is, but the fact that all the team channels are private. Sounds horrible. Yeah, I agree. I'm a big detractor of private Slack channels. Yeah, they should be the exception. But I mean, you probably can't do anything about that either. How about another problem that is difficult if there's lots of hierarchy and you're low in that hierarchy? Yeah. So I also had some, much like the last question, I had some initial

reactions to this that i want to run by you that last paragraph says i wanted to present it to my team first i'm afraid if they don't like it it'll be hard to kind of take it to other people yeah if your team doesn't like it you're kind of screwed like yeah if the people you know the best and work with the most don't like your idea they they have the most context you will have the most time to explain it to them they'll have seen your work the most so if you're trying to propose kind of company-wide architecture and coding standards, they should think you have great technical judgment. And if they don't, then the people who don't know you very much, if you can't win over the people you work with a lot, then it's going to be harder to win over the people you don't

work with very much. Yeah. And you wouldn't want to, in my humble opinion. I mean, there's a possibility that your team is a bunch of idiots and have terrible opinions and you should do the idea anyway but that's probably not true and and so if if they don't like your idea that's a data point and it's like it's kind of a microcosm of what might happen when you try to take this idea more more broad than just your team like the other teams probably also won't like it and you know what maybe it's because they work at the same company you know and it's like actually it is a good idea but at this company it's a bad idea and those other people have the same context that your team has yeah your team is a great sounding board the the other reaction i had was

it's very easy for engineers to have strong personal preferences about architecture and code standards that and and guess what they almost never align with how it already is And if I were your boss, I would have little alarm bells going off in my head saying, wait, does this person want to propose a ton of work of dubious business value that is just like, I do not like how the code is today. So I think you need to have more than like, the code is bad, it is poorly factored, which you said more than that. But you need to be really, really clear with examples about why the current way is a business

problem, not just why it is not well-crafted. Because the business doesn't care about it being well-crafted. They care about it being a tool to make them money. And there's an argument that, well, if it's easier to work on and easier to extend, then that means we can go faster and build more stuff. So you can get there. But just saying it as an artifact in itself is not well-done doesn't matter and risks getting into subjective discussions of what well-done means. so i think you you want to avoid sounding like you don't like it because every code base has people who work on it that don't like parts of how it is done and that doesn't mean it's worth the cost to take on a bunch of work to change it exactly i feel like if oh go ahead nope just

agreeing with you like always oh thank you well i'm gonna cop stuff you've said before i think when topics like this have come up in the past, you've always mentioned how it can be great if you can attach numbers to this. Here are bugs caused by this. And theoretically, these bugs would go away or X number of hours spent dealing with this problem that we could design a way. We can make it so it's not even a problem. Am I the only one who finds it just really challenging to come up with those numbers? No. We always recommend it because then we don't have to actually do it. But yeah, it's crazy hard. I recommend it, but I'll tell you what, after I do those exercises, I always feel so much better.

Like, oh man, I've really got my arms around this problem, you know, but boy, did it, boy, was it a grueling three hours of reading every Jira ticket we've ever logged in the last year to see how many can be attributed to this one pattern. Yeah. And it's possible that you don't have the data to, I mean, if you don't log tickets for issues caused by poor architecture decisions, then you might not have a concrete thing to point back to. So yeah, I'm just full of thoughts on this topic. Another thought is this sounds like a big project to me. And so I'm making some assumptions here.

The more you can lump the stuff you want to do or propose under a catchphrase-like umbrella, the easier it will be. And there's a lot of room for nuance, but you need something to hook into people's brains so maybe the the there's this trade-off between monoliths and opinionated frameworks and lots of services maybe you say okay we're we're making opinionated services maybe that's like your your theme for all of the changes you want to make and the reason i say this is because 100 people is a lot of people and getting 100 people to understand one shared idea is really hard, especially if the idea has a lot of nuance

and complexity. And the more you can give people a shortcut to it to hang all the complexity and nuance off of, the easier it'll be to stick in their brains. If it's like, here's my 95 theses of how to write good code, which are somewhat disconnected, but all end up in a great result, that's going to be tough to do, especially at once. Maybe you can kind of pick one of them at a time. Yeah. And this really is a challenging situation because it is surprisingly difficult to develop a framework. And here I don't necessarily mean a coding framework, but like a behavioral or architectural framework that developers should live within and have it actually be good. And there are graveyards full of old web development and other frameworks that

people abandoned because they had so many hidden hazards that people didn't realize when they proposed them. And so I would advise just a little bit of humility here. And having said that, it does seem like this company is lacking some top-down direction in the technical architecture and coding behaviors and patterns, because you mentioned these roles don't exist. There's no principal engineer, no architects. And that's actually, in my opinion, a pretty big problem. Those people should exist. Those roles should exist. But having said that, I would be cautious to step into that role unless you have a bunch of experience under your belt and you can say, look, I've worked with this framework before, which by the way, I have a guess as to what

we're talking about here. We went from an opinionated monolithic application framework to a different framework, lightweight library. It sounds like Rails or maybe Play, right? Isn't Play fairly opinionated? Yeah, I'm guessing it's like a Rails style or like a Django for Python going down to like a super lightweight thing like Flask or I don't know what the Ruby equivalent would be

where it's like basically like, yeah, we'll give you a web service and you figure everything else out. Yeah. So unless you have experience designing a set of rules and patterns and framework for doing development here, I would say be very cautious about proposing anything until you've seen it work with enough

time and iteration to know that it's actually going to be good and able to scale out to all these people. A hundred engineers is a lot. And so we talk about force multipliers as usually as a good thing, but this can be a really bad thing too. If you make a mistake here and it gets adopted by a hundred people, now every hour of mistake, person mistake units that can happen, that's multiplied by a hundred yeah yeah man we're really down on this question we're saying don't do it just just live in the wild west enjoy the freedom yeah we're given a lot of stop energy of like whoa whoa whoa you got to think of all these things that that doesn't mean you shouldn't do it certainly but i do think this is a common failure mode for smart engineers as they come in and say

wait a minute this all sucks we gotta we gotta change it and and it can be unanchored by the constraints of reality and working at a business. Some of which are like, well, you have to convince a lot of people that it is worth changing it. Yeah, exactly. That's big too. Yeah. Really challenging. But you know, there is an alternative way to solve this problem, which is to convince your leadership, which it sounds like you might not have much access to, to hire a principal or architect to work with and guide these 100 people. Because honestly, that's nuts. Not having someone, I mean, we got 100 people and no one's job is to unify their work. That is a recipe for disaster. And I'm sure working on a monolith was really bad on its own

account for its own reasons, especially with 100 people working in the same monolith. But now with 100 people working in like 20 different teams and no common direction, that's going to create its own set of, honestly, probably worse problems. So that might be the real solution here is you need to hire maybe like five architects. I mean, it's a lot of people. You got 100 engineers that need to be aligned. You definitely need some people in charge of that alignment. Yeah, that's a good point. Maybe identifying the problem and having it solved by somebody is still a positive step, even if it's not specifically the solution that you would have chosen, as long as it's better than the current state.

Exactly. And boy, Jameson, you just triggered, I think, a really cool thought that I got from a book I recently read. And you know, I don't make a lot of book references on the podcast, but I'm trying to do better. And I just recently read a book called Inspired by Marty Kagan. It's kind of the reference manual for product managers. In that book, the author describes two different ways to approach problems. One is to fall in love with the solution, where you say, I have just the best solution here. I'm going to push it and that solution is going to be awesome. And that's actually not a good way to operate, Marty Kagan says. Instead, he says, you should fall in love with the problem. Then you're obsessed with that problem. If solutions come along that

help make that problem better, you adopt them regardless of where they came from. Maybe they were your idea, maybe they weren't. But as long as you stay in love with the problem, you will be able to define it better. You'll be able to convince others that it's a real problem and you'll be able to find better solutions for it. And here, like what I'm seeing is that this person has already jumped to the solution. I want to define a framework and a pattern for working consistently across teams. It's like, okay, but what's the problem you're solving? Because you're not going to convince anyone that some random developer on one of these dozens of teams should be the one to then govern how all the other teams operate.

Like that solution just doesn't, it's not very persuasive, you know, when I say it that way, But if you can define the problem really well, like write up a document saying, and this goes back to what I was saying earlier, like if you can analyze all the bugs, like Jameson, this was your comment, if you can analyze all the bugs, if you can somehow analyze the wasted time or duplicated effort or, I don't know, product performance problems, whatever they are, if you can quantify all these problems in a nice written document and really fall in love with this problem space and try to find a way to make it better, you will be so much more persuasive with others when you present any solution to that problem. because they will see that your intentions are pure. I want to make it better. I want the company to operate better. I want our customers to get better product. I want all of our engineers to be more efficient. I want them to be able to move faster.

You know, and if these are the problems you focus on, then the solution will be much more likely to be well-received rather than just, oh, some random developer has delusions of grandeur, thinks he can create a framework that can regulate a hundred other engineers. You know, who are you?

Hi, I'm Mike. But anyway, that's the risk you run when you come with a solution. Yeah, I like it. Fall in love with the problem. What's the book called? It's called Inspired. It's really an unfortunate title. It says nothing about the book.

It's basically a field guide for product managers. But boy, I actually think all engineers should read it. You'll like it for reasons that are not obvious from the title or from my summary as a software engineer. Yeah. I'll just like it because you recommended it. Yeah. Every time I read it, I'll think, ah.

Oh, yeah. Dave recommended this book. Closer to Dave. Yeah. All right. Have we answered the question? I think so. Good luck, anonymous listener.

Get out there and change the lives of 100 developers for the better by rising above them and becoming their overlord. Yes. You know how everywhere you go, there's some cursed abstraction that someone clearly put a ton of time into? You want to be that abstraction. This is like your pyramids. You want to leave something that persists long after you're gone. People will be cursing your name for generations. At least they remember you.

It's better than not being remembered at all. Yeah, exactly. What should people do if they want their own questions answered? Go to softskills.audio and click the ask a question button. And boy, do we have to say thank you to so many people who have written in with just wonderful, wonderful questions. our backlog is growing but that in no way reduces our resolve to answer all of these questions at some point yes in our life the fact that it's that just means we need to live longer yes

but look it doesn't mean you need to stop sending in your questions no in fact yeah the more you send the longer we will live yeah we'll be answering questions thousands of years well after the craft of software engineering is no longer a thing to make sure we get all these questions answered. This will be an anachronism, a historical oddity. It'll become an ironic podcast. Yeah. Hey, remember when computers weren't made out of sentient goo?

Yeah. You should check out our other podcast where we give advice to how to make a plowshare. All right. Thank you for listening. We will catch you next week. I'll see you next time.