The Pragmatic Engineer AMA

Today's episode is a different one. It's an AMA where I answer questions that you submitted. Asking the questions is Giggs, that is Voldemir Gigniak, CTO at Wurtsmith. Wurtsmith is a legal AI startup where I'm an investor and know the team well, and Giggs was just in town to help out with this AMA. We've grouped the questions as observations across the industry, opinions on AI, opinions on hiring, questions about myself, advice on specific situations, and the pragmatic engineer as a business. Thanks to Antithesis for being our presenting sponsor. With Antithesis, you can verify your system's correctness without human review or traditional interrogation tests and avoid bugs or outages. With this, let's jump in. Hey, Gergely, welcome to this reversed podcast AMA. It's really nice to be a guest on my own podcast. This is really cool. And thanks, Giggs, for coming here. For some background, we know each other from Wurtsmith, which is one of the very few startups I still invest in, because I stopped investing, but about two years ago, I invested with a friend, Ross, who I worked together. It's really nice to have you here. Yeah, and I very appreciate you putting trust in us, investing, and let's get started. So first question, what made you switch from a full IC role, like at Uber, to focus on sharing, reporting tech content? So at Uber, I started as an IC, and I was an IC for about 10 years before Uber. I started as a senior engineer. I became an engineering manager pretty quickly. It wasn't an IC role, but I guess a manager role, but it doesn't change the story too much. I was hitting about four years at Uber, and two things happened at the same time. One is Uber in 2020 had layoffs because COVID hit Uber's business really bad. I had access to our internal dashboard, where we saw the revenue for rides, and it was just going down very close to zero. And I was actually sharing it to my team, because I figured transparency is a good thing. I'm not sure that was the smartest thing, but I'd probably still do it again. I was showing people like, this is not looking good, and we were all collectively freaking out a little bit. And layoffs came very predictably. It was a 20% layoffs. About a quarter of my team was unfortunately gone, and the remainder of my team, our mission no longer made sense in this new world, where we were building something for drivers, when we thought there would not be as many drivers, and we would have to compete with them. But because of COVID, drivers actually were flocking to the platform. And so I got a new team to work with. But it felt to me for the first time in four years that they were going really well. And I just felt demotivated. I knew that the business would be doing poorly. And I also asked myself what I wanted to do after Uber. And right before I joined Uber, I got this offer, which was an amazing compensation package, which was a bunch of stock. And I told myself, well, stock, I mean, who knows if Uber will go public or not. But I said, if Uber does go public, and this money turns into stock, I got about $500,000 worth of stock as a grant option. I'm like, if I have like 500k in my bank account, well, I can take a risk. And for the next thing, I can actually do a startup. So I remember this. And Uber had gone public. And that 500k stock turned into 400k because the stock price was a bit lower. And then you have to pay taxes on it. So it was less. But I still had a lump sum sitting in my savings account. And I was like, huh, I don't have to work, actually. I could not work for two, three years easily. I was like, well, maybe I should take a risk. And my plan was, leave Uber, finish writing the Software Engineer's Guidebook, which is something I started writing at Uber. Just finish it in six months. And afterwards, do what you've done, which is start a startup, join a startup. Because I was a little bit tired of being a middle manager. They tell you, you're a manager, congratulations, you became a manager. They should have said, you became a middle manager. Because now your job is to keep your team happy, to keep management happy. Especially, I was in a different region. I was in Europe. So this was easy. But when layoffs came, it was a lot of politics, a lot of explaining regulations. That wasn't what I wanted to do. Also, keep your peers happy, in terms of being a manager of peers. It was pretty tiring. And I was like, I want to be in charge next time. Because I have a lot of ideas. But I felt I was fighting the machine, if you will, in some sense. So that was my plan. It involved nothing with writing, except just finish this book. I have a legacy. I can give this book to people. I can be proud of it. But then what happened is, similar to software engineering. When you start a project in software engineering that you've never, ever done before. You're a junior engineer. You're doing your first migration. You think it'll take two days. And then two months later, you're still stuck there. And it was the same with writing this book. I've never written a book. I knew it's a big project. But I was like, yeah, six months should be enough. Six months later, I'm still treading water. I wrote three other short books. But my main book was not progressing. And I asked myself, OK, I gave myself about six to eight months to get this book out. And then just go and have a real job. In my mind, a real job was either just start a startup, be a founder. Or go back to being an engineering manager. Or staff engineer. Or CTO at a smaller place. And I was like, OK, well, I should be honest with myself. What am I doing right now? And what will I be doing? And I was like, either I start and I raise funds to start a startup. And my idea of startup was just Uber and Site had a lot of platform engineering teams. Copy one of the things that they were doing. My idea was actually we had an internal RFC system, request for comments. Where we actually had a system that put these Google Docs together. And we graded and all that. And it was a pretty cool system. I thought maybe I could productionize that. A lot of Uber startups actually came from people looking at internal platform stuff. And taking it and either making it open source, temporal. Is Xuber, Chronosphere, Xuber, our observability system. And many others. So actually, it's not all that radical. But then I was like, well, if I did that, I just have to fully focus on that. And on the side, I was doing writing. I was writing a few books, actually. I was blogging. I was doing YouTube videos out of fun. And I was like, well, I need to stop that if I do that. Because if I raise money, I owe that to my investors. I will hire people. And for about 5 to 10 years, I'm going to be happy to be just focused 100% on that. I talked with my brother. He was on his second startup. If you start a startup, do it because you are ready to spend 10 years of your life on it. You need to believe that right now. Because if you don't, it's not going to work. Because startups are just really hard. It's not a popular thing to say. And I wasn't sure I was ready to spend 10 years on an RFC system. I wasn't that excited about it. And then I asked myself, what is this drive? Why do I really want to do this startup? Or a startup? And I was trying to be honest. I had two answers. One was the money in the sense of this was 2021. It seemed everywhere I looked, ex-Uber startups, they were valued a billion. They were unicorns in a matter of a year or two. It seemed too easy. And I was reasonable. I was like, that will probably not happen to me. But what might happen is I might be able to build a unicorn in, let's say, 10 years time. And by that time, if I'm a sole founder, I might have 5% or 10% stake. Because I'll count with a lot of high dilution, which is $50 million. And let's say we have an exit, and I leave. And then I pay taxes, and I still have $25 million, which is exactly $24 million more than I would need outside of buying a house. And then I have this ex-U money. What would I do? The answer was, well, I'd probably share what I know. I'd probably write a book. I'd probably do some YouTube videos. I was like, huh, interesting. I could do that right now. And the other reason I wanted to do this startup was the small teams. I always loved working both at Uber and at my previous companies, at Skyscanner, where I met Ross, co-founder of WordSmith. We were a small team, us against the world. And I loved that feeling, being either an engineer on that team or the manager of that team. I didn't enjoy being a manager of managers, but I no longer had a connection. And that was the other reason. And actually, that was, I guess, the more legit reason. But in the end, I didn't have this exciting idea. And actually, I was like, if this startup was successful, I would just be writing, probably. So I was like, let me try that. I saw Substack was taking off. Lenny Roshinsky shared that he had 2,000 paid subscribers for his product management newsletter. I thought, if Lenny has 2,000 paid subscribers for product management, there's 10 times as many software engineers as product managers on every single team. And they're not as likely to buy. But there was no paid newsletters for software engineers. So I was like, let me try it out. I gave myself six months, and I figured it might not work. And then it just worked. It took off. Yeah, makes sense. Next question. Have you seen engineering teams at Big Tech that adopted AI-native SDLC? And how do they collaborate across engineering product and design? Yeah, so AI-native, SDLC, Software Development Lifecycle. Even the whole, you know, like SDLC is an interesting one before we get into AI. Because like, what is SDLC? It used to be, you plan, you code, you deploy, you monitor. And some people used to call this waterfall. And then there was Agile, where you just like iterate a lot faster. And interesting thing, like outside of Big Tech, or outside of these large tech companies, if you go to a large company that is not like a Big Tech, not one of the Googles or Metas, they often have like pretty rigid processes around Scrum specifically. They say we're very agile, we have Scrum, or they have the SAFE system, the Scaled Agile Framework, which has a bunch of meetings and like a really rigid way to be agile. And of course, there's a bunch of like money and consulting and all that, but they think they're very agile. And then they're very surprised to see how most of teams inside of the likes of Uber or Meta or even Google work, which is like, oh, we kind of have this like, you know, problem. We actually plan, we sit together, we kind of do like, I don't know, a few days of planning. And then we code it, and then we deploy it. And then we get some feedback, and we might iterate. And they're like, well, that's waterfall, we're so much more agile. Actually, like the whole thing about waterfall and agile is it doesn't matter anymore. Waterfall used to be a thing. I talked with Kent Beck when it literally used to be like a year or two of planning and like having like this much documentation. And we don't do that anymore. So the software development lifecycle is an interesting one. And almost every modern company up to AI used to have RFCs or RFDs or design docs where people would write down because they realize that you should, if you plan things ahead, and then They'll take home, fix a real bug in a few hours or a few days, and they could actually see, like, oh, you're actually doing the work. And startups who are doing open source often will just hire the contributors to the repository. What AI has changed is, first of all, the algorithm will interview. It just whizzes through it, so remotely doing it no longer makes sense. And with the take home, where you used to get someone a difficult take home, you can do it in a, AI will complete it pretty well, so you don't really get that signal. So my bet is that what will happen is these worlds will stay, except the in-person part is where the decision will be made. You'll have a filtering, like have a take home task that you can do with AI and you can cheat, if you will. But when you will talk with them on Google, they will still have you come into the office and you'll have to do those whiteboard interviews, and if you didn't prepare, like, AI is not going to save you because you don't have access to it. And startups will probably want you to what you did, is explain what you did and a small percent of your startups who can do, they will just have the trial weeks, what Linear does. Come work with us for a week, like you need to collaborate. You can use AI, of course you can, but it's not the main thing of it. So I think hiring will be, honestly, just more, there'll be more, as a candidate, there'll be more friction. You'll need to invest more time. It'll feel more unfair because there will be no clear rules that we have been gotten used to. And it will be messy. It will be also more subjective. Just the reality. Yeah, work together weeks, by the way, is an amazing way to hire. We did that at the earliest stages, just a little bit hard to scale, but it's interesting that Linear managed to scale it. That's well done. And by scaling, you mean that, yes, it's hard to do it, so most candidates will say yes because you need to take time off. The only reason Linear can do it is they have, they are very, very well known in the industry. And even a lot of people say that I'm so sorry, I cannot do it. I'd love to work there, but I just don't have the time. And so they lose a bunch of those folks. What kind of engineers are thriving and excelling right now? We hear about layoffs and slowdowns, but surely some are doing better than others. Yeah, so we do hear about layoffs, but I talk with engineers who are very much in demand, just as or maybe more so than before. And what these people have is, they either work at startups or well-known tech companies. They are interested in the business. They're so-called product-minded. You know, they don't stop at borders. And by this time, whenever when AI came around, they just got into it. They somehow wheezed their way either at their company saying, okay, I'm going to work on this AI project, building something on top of AI, often AI infra. Like I will help build this part. And now they are, they're actually considered experts in this. And most companies that are hiring and trying to hire positions, the ones that are hard to fill, is I'd like an engineer who has a few years of experience. They've actually built something with AI. Like they're not an absolute noob to this. They will help me be able to decide what architecture should we use? Should we use Rack? Should we use fine-tuning? Should we use off-the-shelf models? Should we use our own models? Should we run on on-prem? Should we do it off-prem? What about the inference costs? What about, like, should we use Grok? Should we use Cerebus? And so whatever, you know, like five years ago, this was you hired an engineer who knew about cloud and could help you figure out at a startup. Now you're hiring someone who knows about inference and some of these things. And so engineers who have been doing this are in very high demand. The only problem they have is sometimes if they work at the likes of Google, Meta, or a well-funded startup, these other companies are surprised at how high of a compensation ask they have. But these people are very in high in demand. The people who are having trouble is either at their current work, they just have no exposure to use any AI, so they don't have this experience with AI building AI infra. You know, they still build software and they use cloud code and codecs, but everyone does that. They feel a bit stuck on how to go about this and they don't have good pedigree, meaning they don't work at a company that is assumed to be a modern company. And those people are finding it hard to make the jump. So now they're thinking, should I just do some side projects? And my answer will be like, well, at the very least, if you want to make that jump between the tiers of companies and in my mind, there's, I have the tri-model of course, but also I have this model of like the company where you have like consulting companies where you're just like an Accenture or Capgemini or one of these where you're given a client project. They're really struggling right now. You have the product companies where you work and you build products. And within the product companies, you have the venture funded product companies where you actually have a bunch of money to, to build quickly, scale, the composition will be higher. You're now competing and hiring from the likes of big tech. And then at the very top, you have right now it's the AI labs, the Entropics, the OpenAI, whatever Google used to be in 2004 and Meta in 2010, that is right. And Uber in a short time in 2015 or so. Now that's, that's Entropic and OpenAI. And it's hard to jump between these tiers. So for example, the P a lot of people are like, Oh, I'd love to work at Entropic. Well, I mean, dream big, but the reality is that I know so many people working at Google and Meta and, and Facebook that they want to get into those places, but these places are extremely selective now. So entry-level web product engineers is saturated. But what's the hiring landscape for juniors in low-level system, hardware, software integration, embedded, or the femme stack looks like? Same surplus or general shortage of system-level thinking? I'm less familiar with, with, with lower level systems programming. I, I would just assume that it's not as saturated. When, when I talk with the Pragmatic Summit in February, I talked with an engineer who was working on low-level systems, mostly C++ and Assembly. And we talked about who's using AI, cloud code, codecs, cursor, etc. And he was the only one in the group. There was about eight of us talking. Everyone's like, yeah, using it almost, almost 100% of my code is generated by back then, it was Opus 4.5 or 4.6 or I think it was codecs 5.4. And he was the only one saying like, we're using it, but uh, maybe like 30% of my code because it's just very low level. Uh, these areas have always been to me a different world than the general big tech, like big tech hires these people. They feel a little bit closer to electrical engineering, hardware engineering. Now that area in general, I've observed there's just a big demand. There's a lot more startups. There's a lot more money in hardware tech. So hopefully it will be good. And I also believe that knowing the basics, like knowing if you can code in C++ and Assembly, like, I think that's really useful knowledge. And you can build on top of that because most people who know a high-level language, TypeScript, whatever, like most of them will not know how to go down to C++. If you know C++ and you can build high-performance, low-latency systems, you can learn easily the rest of the stack. And if you're in this situation, I would just look for those specific offerings in junior positions. Either you have pedigree, which makes it easier, which means you're in a good school or you had an internship at a good place. Or if you're in school, try to get that pedigree, try to get into an internship program or build some impressive projects either on the side or contribute to open source, which is still a pretty good way to stand out, especially with AI contributions being rejected. Uh, you will have to work hard if you want to get to a prestigious place and accept the stepping stone as well. Like right now, I think getting as a junior, a job is better than getting no job. And once you have a job, try to excel even if it's a shitty job. Try to be the best there. You'll, you'll build up a good network and at some point, hopefully you'll, you'll have a stepping stone, a new opportunity to come in to go to the next level. A few questions about Big Tech. So when a company like Meta lays off 10% after a record year and then reassigns another 10% without consent, how does leadership fail to anticipate the obvious hit to culture and morale when everyone inside and outside can see it? Yeah, this is the question, right? The interesting thing, I talk with Meta inside of like some directors and, and even above, and they see it. So, so this is not a question of like, does the leadership not see it? This is a question of, does the founder specifically, Mark Zuckerberg, not see it and why does he not see it? Or if he sees it, why does he Yeah, but it did something that people wanted. Oh, and here it was the right place in San Francisco. So I wonder if like AI native is overrated and like once you have a business model, of course, you can optimize it, but will AI native make all the difference? I'm not sure. And another good example is Coinbase. You know, they're really trying to be AI native, do all of those things, but they're in the end, they're a crypto company. If the crypto market goes up, they will do great. And now they did layoffs because crypto market just went down. So like you can be as AI native as you want and maybe you'll be able to do the same with fewer people, but I'm not as sold on this. Yeah, to me, it feels like artificial artificially trying to become AI native is a bad strategy, right? Like just saying Anthropic is doing that, so we'll copy it and try to implement. What I think works really well is when you're seeing the problem and you understand that, oh, actually this problem can be solved really well with AI. For example, you know, incident response, right? So why don't we try AI to do a first pass, understanding what's happening, right? Like it seems like an obvious idea. And like if we have problems with incidents and debugging time is taking a lot, we can try and if it sticks, then good. But some other process might not work in the company. So it depends if there is a problem and it feels like it can be solved with AI, then it's like a good idea to adopt the practice. I wonder if instead of AI native, we should just think about like companies where like AI is a natural tool that you reach for, like you, for anything, you try it out and it might or might not work, but you're not precious about it. You use it if it makes sense and you throw it away if it doesn't, or you'll revisit it later. Yeah, and just see if another tool that can help you. Next one. Can you share something about today's presenting sponsor? Was like, is this really the question that people are asking? No, this was actually not submitted by anyone, but I still want to talk about it. Now I admit this was the one question I sneaked in because I really wanted to share something visually interesting about our presenting sponsor, Antithesis. It's how different their UI is. Let me show you with three examples. We already know that Antithesis verifies your system's correctness by running your whole system in a hostile simulation and finding bugs. Here's the UI for casualty analysis. You can open a report for a bug and see the probability of a bug occurring throughout the timeline of the simulation. In this case, we can see that at virtual time 25, something happened that makes this bug close to 100% to occur. So we can jump into this point in the virtual timeline simulation to read the logs. This kind of bug probability visualization is one that I've just not seen before. There's also this neat log explorer. You can filter on error messages and then visualize how common or uncommon the error is over time. For example, here we're looking for failing linearization failures, the purple line. And you can understand how rare or common a specific failure was. Again, I've yet to see this kind of error visualization and I really like the innovation on the UI here. And finally, the multiverse debugger. You can go back in time and replay a debug timeline. And you can inject Bash commands at any time without affecting the playback of the bug. How cool is that? For example, here we're listing files in the current directory, but as you can imagine, you can debug the whole environment much easier. I really like how the team at Antithesis is pushing what's possible with both debugging and verifying software. Head to antithesis.com slash pragmatic to learn more. Is ignoring code quality for speed with AI worse in the long term? Some engineers still review the plan, architecture and code. Others rely on SDD plus harness and these regards the code. Faster short term, but is AI good enough to make up for worse code? This is a big question, isn't it? Like, and I wonder if there, there's like any answer. Like, I, I feel as engineers, I think we, we know what we want, what answer we want. We, we want the answer to be, yes, quality is important. Yes, care and craftsmanship is important. And this hasn't changed. Like even before AI, like we, we wanted this to be true. But when I got inside of Uber, I learned about some horrible hack that hacks that Uber did that was looked really painful. For example, the old Uber app before 2016, before we had the rewrite, you would open the Uber app and you would see the ETA of, of the, the cars. You saw the products and you could like pull the slider and then it would show like how many minutes the next category would be like. For example, Uber black is like two minutes, Uber van is like six minutes, and you pull it and you saw some other information on the screen. And what, what happened is that app was polling the server every five seconds to give me all the information. It was a package. And then, so every five seconds you would get an increasingly large data package. By that time, it was a few hundred kilobytes, I believe that was coming back. And the reason that they did this is, is the, and this is just terrible, like strategy. It's, it's inaccurate. It's slow. It's really wasteful on resources. It's also just stupid, honestly. And this was in 2016. By that time we should have just pushed this information. But the reason this happened is the backend team was small and the, the front-end, the mobile and the web teams were larger and they were getting frustrated that whenever they needed, wanted to change on the backend to get some information back, it will take, you know, like days, weeks, months. And so they asked the backend team, like, Hey, can we do something about it? And they're like, well, there's this really hacky solution where we just send this like big blob together and you can go on the backend and you can add whatever you want into this blob. And they're like, perfect, perfect. And it actually unblocked Uber for a long time to like grow independently. But it was terrible architecture. And so this is an example where like, this is clearly tech debt, but tech debt can speed you up. And I wonder if with AI, this is also true that should we not look at tech debt in the stages of a product or a company? Early stage, you're looking for an idea, just like go with tech debt. We don't know if it'll work. You'll probably toss it out. There's companies at this stage where we just try out prototypes and it doesn't matter if it's beautiful or not. Once you've found product market fit, there's this Kenbeck has the three Xs, the I think explore, expand, extend. And there's other, other ways to say this. But in, in the expand phase, you've found product market fit. You want to scale up. You want to quickly reach a bunch more users and you're kind of okay with hacks at this point to grow faster. And the last phase is, is when you're mature, you want to make things good. And what I've seen at the likes of Uber, again, pre-AI, is when you find product market fit, you have a bunch of customers, you have a bunch of demand, you will now have enough revenue and money that you can hire people who can help you fix these hacks. So I wonder if it's the same with AI. Maybe we're overthinking it that if you're in the early stages, you're just doing a prototype, just go all in and don't worry about the code quality, which might hurt you. If you're at a stage where you're now scaling up, I mean, pay more attention. And if you're at a stage where it's a mature product, it's actually making money. We don't want to mess it up. And I'm looking at Instagram's product, for example, which is a mature one, but meta still mess it up. That is probably where you want to be very careful and, and pay attention, understand it. Oh, and final thing is AI doesn't only let us build faster. It allows us to refactor faster. So we have no excuse not to do that every now and then. Yeah, I completely agree. I think it's basically a false dichotomy that it can be only speed or quality. Like it's more about segmenting in time or in code base, right? So infrastructure, maybe more attention to quality. Product, maybe more attention to speed. There have been repeated shifts in AI tooling and best practices. AI makes it easier to find exploits and create them in AI jungle. What will it take for the industry to seriously create standards rather than hoping they emerge? Yeah, first, AI is so new. It keeps changing. Like I think like any standards would make no sense. And I think standards just naturally emerge. Like I, I, I, I haven't seen any patterns to it. MCP, Entropic, when they were still a small lab, they're not a leading lab. They're very small. They created this thing called MCP and everyone thought it's kind of, it makes sense and it comes from a non-threatening place. It's from a small lab, which we don't really know. They're kind of cool, but they're, they're not Google was bigger. OpenAI was bigger. And then like all these large companies adopted it because there was a lot of politics in it. So I think it's accidental. Entropic today, if they tried to do an MCP, people would be like, no, like they are, we don't want to be locked in. So I think they'll Find a position even though she was doing like SRE work and infrastructure work, and I think in the end, she said that she's either considering changing fields or just doing her own thing. And that's the thing, that I think it's easier than ever to do your own thing, but companies I think will be more picky. And the value of the degree, it's a bit underrated if you're living in your current country and you don't plan to leave, like it might matter a bit less. But first of all, large employers often like have this requirement just for filtering, saying we need a degree, it just filters out a bunch of non-qualified people. Saying we need a computer science degree, just filters out the art majors and they don't have to look through as many resumes because they already have too much, even if they have this one thing. But a degree is very important for visas. If you're, for example, in a country and you'd like to move to another country, typically more towards the West, and they like, without a degree, it will be very difficult with the immigration system. So like that's something that's worth keeping in mind. That thing can pay dividends even decades later when you're not thinking too much about it. So a few questions about yourself now. Do you still spend time programming yourself or testing large language models? And if so, what percentage of the time? I spend most of my time researching and writing, but increasingly now for my business, the pragmatic engineer, I have a backend that manages group subscriptions, some customer support functionality that I'm building. I'm building it myself. And now I might have like some folks help me on my team as well. But when I could get a SaaS now, I'm like, I don't want to get a SaaS. I just want to build it myself. So it's simpler stuff, honestly, it's like crud database that it runs on on infrastructure like render. I use the tools. I, I use Codex. I really like Codex and GPT 5.5. I also use a cloud code as well. I play with cursor. I sometimes try factory AI. So I try to rotate these tools and it just makes it so much easier for me to get back into it. But I don't spend most of my time on it. And in your own workflow as a creator, writing, podcasting, researching, have you seen productivity gains from AI? So this is the interesting thing where I think I should have. So I don't use any AI for my own writing. Like I, I did a few of these experiments more for curiosity, saying, hey, here's, here's some notes, generate an article in the voice tone of the pragmatic engineer. First of all, it didn't address this job on it. I don't think it sounds like me. Second of all, like it's, it just has those, I don't know, it just feels artificial, like, like, like links. And then most importantly, I really, really enjoy, like, like I love writing. I don't like, it's not the thing of writing, it's the thinking. Like when I write, I keep thinking. And a lot of times on social media when I will post something and, and it gets a bunch of likes or views, it's often, I'm just writing. And I have this idea when I'm like revisiting the, you know, this topic for the third time. And I'm like, that's an interesting idea. So I just post that idea out there and I just go back to, to writing and then later I see like, you know, people respond to it because I guess what people see is, is just an original idea that comes like, most of my social media is my byproduct of writing and researching. Like most people don't know this. Like there, there are so many people who are optimizing social media for likes or things or all of this thing. But for myself and a bunch of people that I, I know and respect it, it's kind of like their side thing. One good example, I read someone on Hacker News wrote about this, that their favorite YouTube creators in photography, this person was a hobby photographer. Their favorite photography creators are not professional YouTube creators about photography. They're photographers who have business and they actually like do shots and then they have a YouTube channel where they share every now and then. It's infrequent. It's not there. And I also think of myself as my, my main thing is I research what's happening at a tech industry. I talk with engineers. I try to keep an ear on, on the ground as much as I can because I talk with, and I do this by just being in touch with a bunch of software engineering folks I know. So some friends. And when I see interesting things, I dig into it. You know, that's for example, how I noticed that something was really off at Meta. I've only ever sensed things being like slightly off at Meta for so long time, but now I have like 10 or 15 people who I know there for years. And now like most of them were like sounding the alarm bell. I'm like, that's new. I haven't heard that before. And you know, it turns out I, I was right about how just how bad things have gotten there. But in my workflow, I, I use it for research when I'm like, here's a topic, like, all right, I'm gonna research ramps, engineering culture. All right, deep research on all the platforms, like give me all the stuff. And I would have thought that this would have like freed up time and I guess it frees up some of that time, but I, I would have never spent that much time researching. So I don't feel that I'm working less. Interesting enough. And what capability do you worry AI might weaken in you personally? For example, coding fluency or technical recall or writing from blank page? I don't think like the, the writing will, will suffer because I, I just don't use it there. I don't even have spellchecks on. I just don't like it. Or I know I turned Grammarly off, off as well because I hate when it like wants to reorganize it. I think it's whenever you over-rely on something, it could make it less efficient. Like, for example, one thing I now over-rely on is like just deep research. Like I, I want to find all the things on the web. So my ability to like find things on the web might be worse, but I'm not too worried about that because first of all, it was, it was just grudgy task. Second of all, I don't really trust the internet that much. Like in deep research, I still check where it gets references from. When it's too much Reddit, I'm like, I'm not sure this is gonna be 100% checked out. But with coding, uh I now just prompt and, and write the code and my ability to write code by hand will probably be degrading. But I don't personally mind that part all that much. So I think it goes back to like, look, like whenever you're using AI for a bunch of, so just know that that skill will go down. And are you okay with that? And I'm kind of okay with it. Has AI ever tempted you to go back to building software? It sounds so much easier to build software. Like it probably would, would have tempted me, but right now I just love what I do and I actually love the human connection of actually talking to people and getting a window into what other people are doing. But it is making me build more software and be more ambitious. So there's this project that I've been putting off for a while, which is a self-service signup flow for, for companies for the pragmatic engineer. So like the whole company domain and I'm actually just building it because it's so much easier to get started with. It's less intimidating. Vladimir is QA engineer in banking early 30s, and he's worried about staying relevant. So he's tempted to quit for full CS education, but it's quite scary to give up good paycheck. Feel stretched. How should he think about future proofing his options? What I see in terms of future proofing is the single best way to future proof it is work at a company, which is doing stuff that is very relevant. You know, this is building products, building modern products, building products that incorporate some level of, of AI where it's okay to experiment. Banking when it's a rigid place, it might be the opposite. But my first advice would be inside the company. Can you start a project where you are just doing some experience with AI? This is why Google is such a great place right now. I, I know it might not be too popular to say, but they encourage doing this. Like, oh, you're on, you're on your team, you're building a product. Cool. And you have a, you have a suggestion to like build this new experiment with AI. Yeah, go, go ahead and do it. And I have a feeling that a lot of companies will be receptive to this because right now there's a bit of like every leader thinks like we should use AI more. And if someone comes and says like, I have an idea and I'll do it on, on part-time, it's a win-win. Worst case is, you know, you've learned about rag or you learned how to implement this thing. It can be an internal tool. And that's why there's an explosion even at larger companies like Uber with internal AI tools. Just, just start doing that. I think that's the best way to stay relevant because if you take a computer science degree or do it full-time, it will still be, it could be behind the industry right now. Also, like you can do a degree part-time, but because it's such a big technology shift, like the best way is to be hands on. So my, my advice would be try to do that as part of your job. That's the easiest. Everything about the money or these things, I started to focus on just writing that one really good article. I did this for a year and a half, two years actually. And then I looked up and I was like, well, I actually really love doing this. It actually, I didn't know that you could, you could make more than working at the big tech by doing this thing, your own business. And this is also something that you can realize if you're, like with your own business, you have the potential to make more. And also, you know, one of the reasons you probably left Meta as well where you were probably very highly paid is you have the opportunity with a startup, with your own business. I'm very lucky that this has happened, but also one thing, like, I love my days. I find it very, very exciting every day, what I'm doing. And that, that is what keeps me doing this. And I, honestly, I just love being in charge. Like, right now I'm sitting here because I'd like to sit here and I'm having a great time with you. But if I didn't want to, I didn't have to do this. And I, I'm, I do well when I create my own structure, but it really helped me. I don't think I could have done any of this without going through that, like 15-ish years as being a developer, like just doing the work. I always tried to do the best work that I could. I had a lot of structure. I have a lot of, I made a lot of connections who actually helped so much with this business. Like a lot of times my guests are people that I know or I reach out for advice. So luckily I, I feel almost like, like, wow, like was this possible? And I didn't think this was possible, but now I'm just kind of rolling with it and I'm like, yeah, it's, it's great. I love it. I enjoy it. I'm also not too attached to it in the sense that like, look, if the business wouldn't do that well, or people for some reason, you know, they, they stop being interested, it's like, well, I, I can live with it as long as I help some people. I give value to some people. And also, this is, this is an interesting thing, like, I could make more revenue by like juicing it more. Like I could put more things behind paywall. I've gotten feedbacks from people saying, why did, why did you put so much of this outside of the paywall? And whenever I think something is important and more people should get access to it, I try to not put it behind the paywall, even if it hurts the business. Because again, it's, it's kind of nice to be able to do that. What's next, Gregory? Any expansion plans for The Pragmatic Engineer? Yes, the interesting thing is, if this was a VC-funded company and I took VC funding, I would have to expand. But I don't. The only plan I have is I would like to make the Pragmatic Summit more regular. There was one in February in San Francisco. There will be one in, in the beginning of the year also in San Francisco. And I'd like to get to a point where I can have one in Europe as well. And I'd like to be able to do this on a more regular basis. So ideally, my dream, but like, this is more down to logistics and energy on some of those things, is, is to have one in the US, a Pragmatic Summit and one in Europe and London or somewhere else. And getting to that point, I would be very happy. And also, I'm growing my team very slowly. We now have a small team, so I'm, I'm just figuring out ways that I can have folks involved and help with, with even more ambitious research. I'd love to do even going deeper. I have so many ideas of, of companies to research, industries to research, sometimes some boring industries. Like at some point I'd love to go into a utilities company and like go through like how they build software. It's, it sounds pretty boring, but it's pretty darn important. Have you ever gotten in trouble over an article? Has anyone tried to sue you? Yes, once. Two articles, actually. One I never published because I decided not to publish. I, this was the beginning of the publication. For some reason, I really got upset at, at Neobank bunk in the Netherlands because I read about their hiring practices. They do intelligence tests, roshar tests before doing a technical interview. And I thought that's kind of messed up. And I tweeted about this and a bunch of people who were unhappy at the company wrote to me like, oh, here's some juicy stories about how terrible this company is. And here's all the things that they do. And here's, I have, and they had evidence and all that. And it was like some of it was like, oh wow, this is like, oh, crazy. And so I started to write an article about that. This was in the first year of the Pragmatic Engineer. This was December. So I started in August and this was in December. And I had an article ready that was pretty, pretty damning. It probably, probably read like a hit piece. Like I, I didn't have any agenda, but it was just like negative, negative, negative, and this, and can you imagine this and that? I was about to publish it. I even sent it over to the company, to bunk and saying, do you, because I, my editor was like, you should probably send this over to them. Like, but then I slept on it and I was thinking, what am I going to achieve with this? Like at the company inside of bunk, I'm not helping anyone because they'll be defensive. And it's actually a business. It employs people and it's growing and it's playing more and more people. And then I also got a message from someone who, who said that they had a bad experience there, but it was also very helpful because this person came from, I think, Egypt and no company would hire him in the visa on the Netherlands, but bunk did. And they were pushing him really hard and some things felt unfair, but it was a stepping stone. And that person now works at Facebook and said it could have never happened without bunk. And they took a chance on me. I was thinking like, well, I'm not going to help the company. The article has zero positives. It just says, don't do this. Don't do that. And also, despite this, they actually have a business. And I was like, I'm probably missing something here. And I decided to not publish it because I decided, that's when I decided, I want to publish things where I actually like share things that work. Like, and I wasn't sharing any of the things that made bunk work. And actually they're now even more successful company. So they, well, and I think this is the thing, like every, every company has its ups and downs. So that was the thing that I did not publish and I didn't get in trouble for that. A bunch of journalists reached out to me later to like get all the juicy details because they want to read, but I just deleted the whole thing. The thing that I almost got in trouble for, I was really stressed about is the deep dive on Poland. Poland, the events company who really pissed me off because I, I was just covering layoffs across the industry. I mentioned that Poland was one of the many who did layoffs and I knew people there who left Twitter and Deliveroo and some good companies to work at Poland because it was a good company, good salary, flexible perks. And I just briefly mentioned them in my article saying like, they did layoffs, it was poorly handled on an all hands. Someone brought up saying the Pragmatic Engineer was the only one who mentioned it. The Pragmatic Engineer mentioned that we did layoffs and it was poorly handled. What do you think of it as a CEO? And the CEO said like, ah, this is, this is not like, it's like a BBC or Panorama. It's like some, some small publication with an agenda against us. Don't worry about it. It's incorrect anyway. And I was like, and they shared this back with me and I was like, what? And so the company did not pay employees. They lied about them. They canceled health insurance. It was like, it was lots of lies and unpaid salaries. And I just decided like this, this thing with me, like the guy said, I'm not a Panorama. So I did a proper investigative article where I collected a lot of stuff on how it went wrong, including a double charging of a payment. That was a Deliberate double charge disguised as an outage. There's now reporting out about it from the BBC. I might or might not have helped with some of that reporting for the BBC, not for my, I couldn't put it in my article because when I sent it over to Poland, they said that this is libelous. This is libelous. This is libelous, meaning they could sue me. And I had to think about like, do I really want to do that? so I actually self-censored and I put so much effort into the article, so much stress. And I realized that investigative journalism is just not for me. And it's a, it's a good read. The BBC later made it, made a documentary. I also helped them with that, but I realized this, this world is not for me. Other than the book and newsletter, What's something surprising you have found through your writing? Usually just find ideas as, as they go because they fester. I, I also have a long list of things that I, I collect. Like, I'm not sure if I have any specific things. Trends sometimes