Essential Skills for Engineers to Thrive in the AI Era

The dirty secret of all of this is it depends on training data, and that training data is so important, right? Having enough of it, having it cleaned up enough, having it, you know, marked, categorized, and sorted and available. That's why data engineering has become so important over the last decade or so. And I think it becomes even more important as we look to use that and we have more and more data. We want to use it to train more and more AI models.

In this conversation, I talk with John Crickett, who is a seasoned engineering leader who worked both as a Staff+ engineer and a senior manager as a VP VP and head of software development. We talked about a lot of important things, including what should engineers do to thrive in the AI era, evaluating AI tools, career strategy, overall productivity, and also long-term perspective on what the future with AI will look like. Now let's get straight into our conversation. John, uh, really great to have you here today. Um, today we're gonna be talking about What should engineers do to thrive in the AI era? And for the beginning, to start, what do you believe are the core skills that engineers should prioritize today to stay relevant in the industry as obviously AI gets better and better?

Cool. Well, thank you for the welcome, Gregor. The more I think about this, the more I end up back with skills that should always have been important. So the few things that I really pick out are clear communication. After all, most of our interaction with AI tools is going to be written or spoken, so all about communication. The other side of that is, as we have made coding even faster, potentially, as we've been able to iterate on certain areas of, uh, development even faster, say producing documentation, even to some extent some code reviews with some of the code review AI. It enables us to focus more on the product. So that's going to then mean that we need things like stakeholder management and project management and that domain knowledge and being able to focus on what does the business need, what do the users want. Combine that then, we need to start thinking a bit more about adaptability. We've got more tools, we can potentially be more productive in certain areas of what we do. That frees us up, as I say, to do more stakeholder management, to do more requirements gathering, to focus more on the domain. So I think then that means that we need to be more adaptable and focus on quick learning so we can learn how to use new tools as they become available. We can learn how to incorporate this new knowledge we've got from our domain, and we can adapt to that changing environment a little bit quicker. I think all of those tools allow you to adopt any tool better, but in particular the AI tools we have now where communication is the way that you interface with them. Those really set you the groundwork to leverage all those tools. And that's whether you're using, say, ChatGPT, one of the chat interfaces, to help you prepare some documentation or to help you prepare a presentation or to help you prepare a PRD or RSC or whatever process you use, or whether you're using some kind of chat interface or coding agent, communicating your requirements to it, all going to have those skills being the fundamental elements of what enables you to use that AI effectively.

Awesome. You, you touched a lot of, a lot of good points today. I like to map it to, to like to two different areas, which is human-related skills and then pure problem-solving abilities. And you mentioned a lot of good tips here about, you know, what things should people, should engineers prioritize. What about particular habits? Like, what do you think would make, if an engineer like us has these particular habits, what do you think would enable them to thrive in the AI era? What kind of habits would they need to incorporate?

So before I answer that, let's pick up a little bit on what you said with the human-led skills and the problem-solving skills. I don't know if it was Einstein that said it, because there's some debate over who said this, but there's a quote he allegedly said that goes something like, "If I had an hour to save the world, I'd spend 59 minutes understanding the problem and 1 minute solving it." And I think that the same applies now. AI allows us to generate solutions quickly, potentially. So that problem-solving of How do we define what the problem is? How do we understand it? How do we clarify exactly what it is, what the constraints are? Those problem-solving skills, again, as you say, are becoming even more essential. And they tie so heavily to the people skills because, you know, what is the problem? What are the constraints? What does a good solution look like? They're all questions we have to go and ask a product owner or a user or some other stakeholder. So they're absolutely key. To then bring that back to habits, I think the underlying one, I don't know whether you call this a habit or trait, that I come back to, and I know you and I both feel strongly about, is curiosity. If you're curious and interested in things, that's going to enable you to ask better questions and keep pulling at these threads of, well, what do we want to build? Why do we want to build it? Why is that important to you? And that being curious and asking those questions will help get all that information, define the problem, and allow us to solve it effectively, and then leverage the AI tools to generate that solution relatively quickly. The other habit I think is continuous learning. And, you know, we've both been in this industry a while, and we've both seen how much it changes, and there's always something new to learn in tech. Sometimes that new knowledge and those new things to learn are just a repackaging of the old ideas. Sometimes they're genuinely new. Sometimes they're new and they're a dead end. But by at least being open to continuous learning, you get a chance to see a lot of those things, start to recognize the patterns, and start to be able to say, "Yes, that's going to be worth pursuing," or "No, it's not going to be worth pursuing." You start to recognize things like, "Oh, that's a great idea. It's a repackaging of this idea, and then so we can use a lot of that knowledge we had from the past of how to use it and how to move it forward. So I think that the two that I would really push people towards is be curious and continually learn. And you can make that habit of making yourself, for the curiosity, pause and just ask one more question, you know, try and make sure, have I understood this one? What extra question could I ask to get some more detail? And the continuous learning, just make a habit of it. Pick out 10-15 minutes every day, read a great newsletter or read an industry newsletter that curates a topic. Grab a book every so often, read a book about something. You know, there's some great books on your bookshelf behind you there that demonstrate that you've been doing this. I'm sure you can list some newsletters that are great if you want to learn more about different topics in software engineering. So just create that opportunity each day for some new information to come in, so you've learned something new. And don't just limit it to tech as well. If you're working in a particular domain, maybe read something about that domain. If you're maybe a forward-deploying engineer, read a little bit about stakeholder management or sales so that you understand that, or consulting. Maybe if you're in AI, read a book that's adjacent to the area. I can't think of a good example at the moment. I'm sure there are some.

Yeah, those are really good points that you mentioned. I like to map curiosity to growth mindset. One of the best questions I like to ask on an engineering interview is, what kind of new things have you learned in the past 6 months, right? And then I look for, you know, everything that they have learned. Are they— how they also answer the question. Are they smiling when they're answering? Are they also, you know, feeling happy about what they learned, what they're learning? What kind of resources are they, you know, looking at regularly? What kind of books are they reading? And stuff like that. All this matters a lot. And some people may believe that it's not that important to do that, but it is. It's crucial in our industry. If you're not learning, if you're not growing, you're stagnating, especially in the current age, as you mentioned, you know, continuous learning and also being curious. Those things are, you know, more and more important. People with 10 years experience, 15 years experience, if they don't learn the new technologies or try to try out the new tools, they will be not as relevant these days.

Also, it's be a very dull career, you know. I have met a number of times in my career, I've met people that have been in a role for 10 years, and in that role they've done the same project 10 times. So maybe they've been in a software consultancy, they've done the same project 10 times for 10 different customers, they haven't progressed, they haven't learned. I would find that just insanely dull and boring. Yeah, I want to learn new things. It's what gets me out of bed in the morning, hence why I love doing coding challenges. I get to learn about a new topic each week, picking out some new different challenges and adding those to the ones I've done in the past.

Yeah, definitely. I, I feel the same way. Like, if I'm, if I'm doing something for 2 times, 3 times or more, it's, it's, uh, kind of, uh I feel less energized about it, right? I need to constantly be thinking like, hey, how can I do something new? How can I learn something new? How can I try out a new, a new thing? How can I read a certain new book that I haven't already and stuff like that? And that, that makes me energized, right? So yeah, good, good point about it. But what about, you know, obviously, you know, you can be curious, you can go into many different tools, There's so many different AI tools available these days and you can go and play around with them for hours, right? But what about how would you evaluate like which, which kind of AI tools are worth, you know, looking into and also integrating like in your daily day-to-day workflow?

So I think particularly at the moment where a lot of the tools are in the early days, try as many as possible. People are still figuring out what the tools are and what the tools should be. Different manufacturers' tools are taking different directions with them. And I think the other thing that we've missed a lot in software engineering is don't just limit it to, you know, Cursor, Windsurf, Codex or Chord or all those. There are lots and lots of AI tools around at the moment that aren't just limited to software engineering, but they can all help. So you can use the chat interfaces to go and iterate on requirements documents, to maybe give you feedback, you know, dump out some requirements and then say, what am I missing? Use it to iterate and get some feedback on there. There are— we're recording this podcast using a tool that allows you to use AI for editing, allows you a lot of very, very beneficial things there to you know, create the transcription, which it gets remarkably right. It also allows you to edit it, allows you to, to process the audio. So there are a lot of AI tools that aren't just about coding that are very, very useful. And in many ways, I found those more useful for what I'm doing these days, in that a lot of what I'm doing is writing, preparing things, asking questions, doing some research, processing some audio or video. Again, a lot of us as software engineers have to do that. You know, we like to pretend we can just code all day and have that focus time, but the reality is we have meetings and other notes we're going to summarize there. We have documents we need to summarize, or we have documents we need to write. We have documentation we need to update. We need— we have documentation we need to consume, where quite often there's a lot of documentation and we're interested in a couple of paragraphs. So you can leverage all these tools to improve those other areas of your work as well. So don't just try, you know, the coding agents. Think about how you can use tools in other ways to improve the work that you're doing and to remove some of the frictions from your work.

Yeah, well said about it. You know, a lot of people try to use the tool for the sake of either everyone saying it's a good tool, or they see it either from their colleague, or maybe they see it on X or somewhere else on social media, and then they immediately go and adopt and try to use that tool, right? But the thing is that you want to use a tool to help you improve either your workflow or what you're doing to make you more productive and so on. And I like to give an advice to stick with what works for you, right? Don't try to just go and jump from one shiny tool to another one, to the third one, to the fourth one, because that's actually going to be less productive for you because you need to, you know, every time is going to be a different onboarding. You need to understand how it works and so on. But You want to build the tools that can help you be better at what you're doing. So if you like Cursor, okay, stick with it for, for some time. If you like Cloud Code, stick, stick with that for, for some time, and so on.

Um, and again, on that note, focus on what is your bottleneck. So I've been doing this for nearly 30 years. Writing code is not the bottleneck in most of my workflows, but there are level areas where you know, it can be very, very useful, and that can be, you know, an enhancer to productivity. So you don't just have to use it in one area. Think about the different areas you can leverage it. And to follow on to what you're just saying there as well is don't just chop and change every couple of days. Try and think about how you use the tool. So a lot of the people I've seen with, um, using AI for anything, whether it's producing some content that they want for their website or whether it's producing some code that they want, they are just using it as a chat interface. They've said, you know, just, you know, you chat to it, great, so, you know, make me a website that does X. That's not really enough detail. You couldn't communicate that to a person and expect a developer to build a website that does X for you. And have it exactly match what you want, 'cause there's not enough detail. So I don't wanna sound like the meme of, you know, you just need to prompt better. Yes, we do actually sometimes need to just prompt better, because ultimately getting good software built has always been about getting good requirements capture. And that's why I think software engineers will always be needed, 'cause requirements capture is part of software engineering. But whether you're catching those requirements and writing them down to communicate to a software engineer to go and build it, or whether you're capturing those requirements and writing them down clearly and ambiguously to give them to an AI. You need those requirements to be clear. So learn how to do that. And I feel that we've, in some respects, it's been a good transition as we move from waterfall to agile. But I feel that now that we don't spend a long time in waterfall writing a big requirements document, people have forgotten how to write requirements. And I think it's a good thing that we've moved from waterfall and we do far more agile. But we need to go and relearn those skills of writing good, clear, and ambiguous requirements, because that allows you to prompt an AI well and get something good out of it. So learn how to do that. Relearn those skills of good requirements, because they will contribute to how you prompt. And be aware that there is a— we can debate whether or not it's a craft or an engineering skill, but there is definitely a skill to prompting well, just like there's a skill to writing good requirements for a human developer.

Yeah, definitely. I like to say that, you know, managers are in a good position to be doing AI coding pretty well because they know how to write requirements, they know how to delegate, they know how to give feedback, and they know how to also be patient when working with people. You learn that as a manager. And a lot of engineers, a lot of, you know, and people who are working based on doing their individual contribution, they don't have those particular skills, especially the patience. They're lacking patience and they don't try to, they don't want to delegate something they already know, but instead, okay, let me solve this myself because I know exactly how to do it, right?

So, uh, yeah, there's an interesting spin on that. You know, there's this famous debate of the maker versus manager schedule, and one of the things I find interesting with some of the software engineers that are so hyped up about AI, they talk about, I've got an agent doing this, an agent doing that, and I just manage this army of 20 agents. I send this agent off for 2 minutes, then I focus. They're now describing that they have that manager schedule. They're spending 2 or 3 minutes on something, then switching to a different task, then switching to a different task, then switching to a different task. That's very, very different to what we've argued for ages as software engineers. We need that 4-hour block of focus time. Yeah. So again, I think for some workflows, being able to work from that manager mindset is incredibly useful. I still think for other workflows with AI, having that focus time will be very, very useful. And it's going to depend on, again, how you work, whether or not you want to work from, I'm going to feed it a big chunk of requirements and have it build, you know, 20,000 lines of code at this big system. And I'm going to hope that I can specify that clearly enough it can do it all.. Or as I tend to be a bit more from the habits I've developed over the last 30 years, I tend to write a small bit of code at a time. So I've mostly worked in Test Driven Development, so I've written one test, just enough code to pass that test. So my workflow looks quite different to some people that maybe are moving towards a Spec Driven Development. I think you've got to fit your workflow in and think about that maker versus manager. What approach you're going to take. But I think it's an interesting dilemma we've got that we might potentially change that for software engineers. And again, it might suit some people that are better suited to that manager schedule rather than those people that want to work with that maker schedule.

Yeah, it's going to be very interesting to see how things play out, especially as you mentioned, right, that time in between, between like actually computing and you giving instructions and then waiting for doing something, especially if you're working with a larger code base that has like a lot of that you need to, you need to put in a lot of context in order to get outputs. You know, things take time to give you the specific information that you need. And you also need to be, as you mentioned, very patient and so on. But what about obviously there's also so many ways we can misuse AI, because, you know, we get access to something that we can use in so many different places. What I think are potentially like any kind of examples engineers misusing AI tools and, you know, how can they avoid those pitfalls?

So I think the obvious one to start with is vibe coding. If people truly follow what was talked about there, I'm just going to describe something to it, not even look at the code, just trust the code, and it either works or it doesn't, and keep describing it. I think a lot of people have misunderstood that to be just, I'll give it these very simple prompts like, build me a website that does X, I'll try it, if it works, great, if not, I'll ask again. Again, as we mentioned, you need to have a more detailed set of requirements. So just, I think, vibe coding and trying to in the genuine spirit of what was meant by that first post on vibecoding. I think that's a misuse. You need to focus a little bit on learning to use the tools a bit more if you want to get a good result. I think the other example of misuse is kind of follows on from that and just trusting what you get given, whether it's AI, whether it's another software engineer, whether it's your own code. All those should have the approach of trust but verify. I've written code that I look at and think is, is, yeah, great, I've done that, it's simple. Can't possibly mess that up. And then, you know, classic off-by-one error or something. You know, it's trust but verify. So that's why I have tests in my code. That's why I get somebody else to review it occasionally, or that's why I pair program it. So there's that other person that's going to verify, or there's that test that's going to check that I don't mess it up when I refactor. And then I think the third thing that really stands out is just letting the AI do most of the work and not maintain some of that skills. We saw, I don't know when you're going to put this out, but we saw yesterday that Cloudflare went down and that removed access to most of the AI tools. If you're fully dependent on those tools, you're then stuck if they're no longer available. And whether or not it's another outage like that, or the very real risk of somebody like OpenAI or Anthropic going bust and failing. They are burning through huge amounts of cash. We're in relatively economic uncertain times. If one of them fails to raise that next big tranche of cash, and they're getting to the point where people don't have that much money to invest in it, one of them fails to raise, it could cause a bubble to burst. And it's true that the tools can be very, very useful and the businesses can be overvalued. So we do run the risk that if one of them fails, it results in them all failing. And these tools might become less available because those companies have gone and nobody else is willing to pick up the price tag of making them available, or anyone does pick them up and carries on going has to put up the price. So they may then become less available because they'd be less affordable. Now, we might be able to adapt to open source models running locally, but there will still be challenges with that. So I think it's important to keep your hand in, keep that awareness, have that contingency to fall back on that you still have the skills and knowledge to be able to do it yourself and fill that gap if it happens. And again, you don't want to be on an incident at 3 AM, and that incident has also taken out their system, and you can't jump into that code and figure it out yourself unaided. So, yeah, keep your hand in, keep, you know, do some of it. I think it was Adil Osmani on a podcast recently said that he has like a day, a week, or a month, I can't remember, where he'll deliberately not use it, so, you know, and do it all by hand. So you're maintaining that practice and I think that's a good approach to follow.

Yeah, definitely. And I see this today as well, like engineers coming to the industry today or 10 years ago having like a less, less knowledge of engineering fundamentals because the tools are getting better and better. And the people, I believe the people who will have those really good engineering fundamentals, understanding engineering well, those are going to get to have advantage. In our industry. That's kind of like what scares me a little bit, what's going to be in the future. And that's also a little bit, you know, why junior engineers and, you know, people just coming into an industry might have some issues getting roles because they don't understand those engineering fundamentals well. But yeah, you mentioned obviously by wipe coding and trying, but what I see a lot happening is just some engineers just creating a PR without actually checking that the code works exactly as it should. They're just doing a prompt and then just opening a PR. Now, those kind of things are what you should avoid at all costs. It doesn't make you a good engineer, doesn't make you a great, even a great person to work with if you're just dumping work to someone else to check the functionality. But no, you, you should be the one who who is really making sure that the code is working correctly and everything works the right way. Let's go a bit more about, you know, about career and overall how can engineers progress in their careers in this AI era. What do you think about, you know, different roles and specialties? Like what kind of things do you think will become more and more valuable as AI advances? Maybe 1 year, 2 years, 5 years in the future?

So I think the very first thing, and apologies for sounding like a broken record here, is requirements capture. That business analysis, product owner, depending on the domain you're in, somebody that can talk to users, has that deep domain knowledge, can understand what the customer or the user wants and why, and figure out what a good solution for for them would look like, and can describe that unambiguously. The requirements capture, as we used to call it, I think that's going to come back to being far, far more valuable. You capture those requirements well, you can feed that into a spec-driven workflow, and then potentially have AI deliver a lot of the code for you. So I think that, that is one key role that's going to really stand out. The other thing I think that's going to be increasingly important is AI, machine learning engineers, and data engineers. You know, as we use more and more of these tools and as we integrate them, we're going to want to tune them, we're going to want to train them, we're going to want to deploy them, and that's going to be even more important than ever. And that requires sort of the AI/ML engineers and the understanding of that. But more than anything, it also requires data. And the dirty secret of data science and machine learning, now that we've gone the full circle after 20 years of bringing back AI as a popular term, The dirty secret of all this is it depends on training data, and that training data is so important. Having enough of it, having it cleaned up enough, and having it, you know, marked, categorized, and sorted and available. That's why data engineering has become so important over the last decade or so. I think it becomes even more important as we look to use that and we have more and more data. We want to use it to train more and more AI models.

Yeah, definitely. Those are two really good, good examples that you mentioned. I love that you mentioned requirements gathering. Those also consist of, you know, being able to write well and being able to clearly write and also explain your thoughts and also what you're seeing. So writing is not going to go anywhere. It's just going to be more and more important skill tool as, as time goes on, I believe. And obviously the data as well. Without structured data, you can't do anything great, great with it. And also how and where, where you get the data, because the problem is going to be people not using Stack Overflow anymore, but the AI is trained based on Stack Overflow answers. And similar with Reddit answers, uh, obviously Reddit is more kind of like a more overall in different topics, but Stack Overflow is more for just engineering concepts. It's going to be interesting to see how they will— well, when, when like new technologies comes up and new frameworks and so on, there's not going to be new Stack Overflow and so on.

But again, it's easy there to, to forget that AI is so much more than just ChatGPT or Claude. A lot of this, the advancements in AI and generative AI, focuses on images. Focuses on audio and focuses on other non-text-based data. So there are many, many use cases of AI that aren't just that text-based chat, and they all require data engineering as well. They'll require cleaning the data and managing it. You know, for example, I've worked for about 8 years in the last decade on data engineering, and not a single bit of it has been to do with SQL and text and databases. It's all been audio data or meteorological data in a binary format. So, you know, all of that data is to do with machine learning and AI. So there's going to be a lot of that, and they're going to be a— even within data engineering, a vast set of skills, you know. So I see a lot of posts on LinkedIn and other social media about data engineering. I don't recognize any of it because I didn't do any SQL for that. It was all about binary data and, you know, processing audio data, adapting it, tweaking it, identifying signals in it. Or it was about meteorological data, which again is a big blob of binary data. So, you know, those are going to be vast skill sets and there's a vast range of different areas of AI and I think will become increasingly important and fit into what we're doing. And talking of the meteorological data, The data we were using wasn't necessary to do with AI, but, um, it's been in the press recently about WeatherNet that DeepMind are working on. So again, they're applying AI to doing climate modeling and weather predictions, and from what I've seen, it's getting fairly, fairly accurate and competing with the traditional scientific climate models. So there's going to be AI deployed into a lot of other areas. It's a massive scope of growth. For software engineers and machine learning engineers and data engineers.

You mentioned really good, good points about here. Let's, let's get back a bit more to engineers in general. And what do you believe are kind of like, obviously it's a million dollar question and we don't know what's going to happen in the future and so on. But what you know right now, what do you think are some of the, how can engineers future-proof their careers, you know, without, you know, trying to chase every new trend. And also, you, you've seen, uh, we were seeing in the industry that junior roles are, are getting less and less popular these days. What kind of advice do you have for engineers and also junior engineers to make sure they future-proof their careers?

So I'm really, again, sounding a bit like a broken record. I think you should focus on learning the fundamentals, the fundamental software engineering still apply. The fundamentals of problem solving still apply, and that's how we get a lot of compute. So the, the computer science algorithms, they are applications of problem solving techniques. The fundamentals of machine learning and AI still apply, and they haven't changed for decades. You know, LLMs are very big neural networks. Neural networks, you know, go back, depending on how you want to trace it, 50 to 100 years, and some of the concepts. So if you learn those fundamentals, you'll start being able to recognize those patterns and apply that to the advances in technology. So focus on that fundamentals, focus on really understanding them, and that will set you up well to be able to learn all the new things a lot, lot quicker because you'll recognize the patterns, you'll recognize how these are in some respects repeat of the fashions. You know, we, we've had, uh, in computing we've had this idea that there was one computer when everyone got a time slice of it. Then we've moved to desktop computers, then we moved back to there being a central server that everyone used, and we've moved back to more distributed models. Then we moved to everyone had their own device with mobile phones, and we've gone back to a lot of things are SaaS platform. So we've gone through fashions of computing being everything's on one big computer to everything's distributed onto a personal device to everything's back on a central computer. So if you recognize the fundamentals there of why those choices were made and why the trade-offs were made, you'll be in a good position for whatever the next application of that is. And yes, there have been iterations in how the communications varied. We've gone from the very first ones were serial data to eventually we had, you know, cable network to eventually then we had Wi-Fi to now we have global optical networks. We have satellite communications.. And so the kind of technology that's provided the connection between those has changed, but the fundamental patterns, the fundamental infrastructure and design of those systems repeats.

Yeah, especially, you know, junior engineers, as you mentioned, might be a bit harder to get, to get roles. One of the things I love to suggest to especially people that are starting their careers in our industry is building projects, right? You don't want to be just waiting for you to get a job, but you want to proactively search and look for things to, for you to work on. That can be freelance, it can be just building side projects and so on. But yeah, what— obviously you're a big fan of building projects and side projects. You write a newsletter called Coding Challenges and also What, what do you recommend? What types of projects do you recommend for engineers to demonstrate, you know, their, their knowledge and also to get more opportunities, to get better visibility, and also maybe like a junior engineer to get, to get a role faster?

So I've thought about this and I've picked out two areas that I think are really worth focusing on. So the first one is actually a project around communication. So figure out how to communicate what you know. And again, if you're a junior engineer, that might not be a lot. So maybe communicate what you're learning, because let's say you have zero professional experience, you've just graduated from university. You know more than somebody that's a first-year student at university. You know more than somebody who's still in school. So start sharing and demonstrating that you can share that knowledge, you know, either what you learned last year that somebody that's 2 years behind you doesn't know, or what you're learning now, and demonstrating that communication. That communication skills, I think, are going to be so important in, as we said before, communicating with AI and communicating with other people. And if you do that in public as well, it starts to show that you're an effective communicator, starts to show that you can share knowledge and you can disseminate it. And again, you don't have to be an expert on something to be able to communicate. Well, you could go and curate that information. So maybe you decide that the opportunity in your town, your city, your legion is to become an expert in the use of, I don't know, let's say windsurf. Go and curate information. Go and reach out to some people and interview 30 people about how they use it. Put together a document of I've talked to 30 people. This was the top 10 recommendations that they had for how to use windsurf well. So you don't have to be an expert to do that. You've just curated information, but you will learn something about it in that process. You will create something of value that will get shared and be useful to other people, and you will demonstrate the value you can add with communication skills. So that's my first project. Pick something in communication, maybe like a newsletter. You know, it's worked for us, hasn't it? You know, that's something that anybody can do. There's no barrier, and you can start doing that whether or not you've got a job. And I was actually listening to another podcast this morning as I walked the dog, where somebody was saying that they got a job halfway across the world, paying a 6-figure salary as a 22-year-old, because— and this is going back a few years— somebody read the blog that they wrote. Somebody saw their ideas that they shared on a blog post and went, 'That's somebody smart, I want them to come and work for me.' Again, that was just showing communication skills and that building in public. So everybody can do that. Start doing it, find an avenue to do it and share what you're learning, even if you don't necessarily have anything that you know already. I think there's some great examples on social media of people who are doing this and leveraged that into getting them opportunities. The other side of that is leaning a bit more back on the kind of coding challenges of actually building something. Let's go and build a project that has some traction. It's now easier than ever to ship something. You know, there are lots of free platforms like you can use Cloudflare, Vercel, even GitHub for hosting different projects. None of those cost you anything. There's no barrier to entry. There's no pay-to-play. So you can deploy something on the web easily. You can create— it's very easy to find problems or even scratch your own itch, you know, solve your own problem.. And if other people have got that, talk about it. Do that again, building in public, the communicating. If you can actually build something, deploy it, and get some users, even if it's maybe you've got, um, an online version of Minesweeper, or you've built your own version of Pong, or an online chess thing, anything that shows that you can build something, you can deploy it, you can keep it learning, and you can get some traction to it, you're showing them that you, you can be product focused. You're showing you can actually do the job. You're showing that you understand the need to get users. You're showing you understand how to communicate with those users and share it. And you're showing you can solve a problem and identify where a problem actually exists. So I think those are great things for her to demonstrate and to show. And if you're a junior, it's going to put you head and shoulders ahead of a lot of people, including a lot of seniors.

Yeah, I really like, I like your points. And to mention, yeah, the hardest part of building a product is not actually building it and coding it, but it's actually getting attention and getting users and monetizing it. You know, everyone who has tried to do that knows how hard it is to do that. And especially when tools are getting better and better to build stuff, more and more products are going to be out there and there's going to be more fight for actual attention, for, for getting people to actually care about your product. Right. So yeah, those skills are crucial, crucial and really, really important. You mentioned also in the beginning about communication, right? The problem, the problem I see with universities and also schools in general these days, especially like and also happening this also a long time ago as well, they incentivize individualism instead of like just helping others. And sharing knowledge and, you know, being a person that is going to help everyone around you. But they want everyone to be on their own studying, but that's not how the actual real life works and actually how, you know, working a job and full-time job works as well, right? You need to be a good team player and to be a great person to work with, someone that makes everyone around better and so on. That, that's where I see a lot of issue. I need to go over that hurdle because maybe you can, you can resonate with this as well, but it took some time for me to understand what actually coding is. It's not actually building, but it's actually collaborating and working together with the team to, to, to provide the best project as possible to the, uh, to the clients, the users, and so on.

Yeah, absolutely. And it's not a competitive sport. You don't win by building the cleverest code that no one else on the team can understand. You win by putting your ego aside and building the simplest code that will work so the rest of your team can understand it and can work to it. And I think we see some junior engineers, and even some senior engineers haven't had the right experience, still then pushing back about that, saying, why do I have to dumb my code down to the lowest level? Because as you say, they've been given that mindset that, you know, meritocracy should be the way, and we should like trying to lift everyone up. And we should try and lift everybody's standard up, but that's by raising people up, not pushing people down and getting rid of the bottom layer. Um, the other thing I think that school is really bad at is that we get taught very, very fluffy communication. So I remember, particularly in English language in school, being told that the things I wrote were too short. Nobody wants to read that. Make it longer. You know, your average sentence is 5 words. Can you make a few that are 20 and 30? And you get taught to write kind of very fluffy, long, elongated sentences and demonstrate a great vocabulary, which is absolute tosh when it comes to actually learning to communicate. Because in the real world, you know, you're dealing with people who, for me, A lot of people I deal with aren't natural English speakers. English is not their first language. So if you go and use a very complex vocabulary, you're making it harder for them to understand. Now, you could be dealing with people from a different domain. I deal a lot with business people who don't understand tech. If I start talking a lot about technical things, they're not going to understand it. If I start simplifying it to a common shared language, they've got a far better chance of understanding and us having effective communication. The other side of that, and I know people on a lot of social media platforms don't like it when they see like one-sentence paragraphs, but go and study a newspaper. Newspapers are designed to be read. People have— journalists have been studying how to get people to read things and take on that information for years. You will see short one-sentence paragraphs, paragraphs that are 3 or 4 sentences max in between, and you'll see that completely different structure that you won't see in an English class. In an English class, you'll get told to start at the introduction, work through, and you save the best bit for the last bit at the end. Look at a newspaper and you'll see that they tell you the most interesting thing first at the top. That's the headline. You could skip— stop after headline and you've got 60% of the content. That first paragraph gives you maybe the next 20%, and again, you can stop after that. You've now got about 80% of the content. So, you know, I think the military use the term like bottom line up front, you know, get the facts up front, be clear, be precise, and don't use complicated words. It's not a competition to show off how clever you are. It's about communicating effectively and getting the other person to understand, because communication is not about you speaking and broadcasting and saying something clever. It's about you getting an idea from your head to the other person or the other people and having them understand it and knowing because of the way they communicate back to you that they have understood it.

Yeah, that resonates, uh, really, really well with me, especially, you know, as, as I'm reading a new book, I immediately see what kind of style it's written in, right? And if that style is not something that, uh, you know I can really quickly kind of like get value, value from it is trying to be more kind of like a novel type or trying to be clever or trying to put like those fancy words in there. I can really quickly see that I'm getting less, less kind of excited about the book, right? And similar with any kind of newsletter articles, anything I read online as well, I can quickly see. And that's what I try to focus a lot when I'm writing articles is how can I make sure I provide as much value in as short amount of time possible for the reader. The value, value per minute is kind of like a good metric for, for writing, right?

That should apply whether, you know, you're doing your newsletter as a business or whether you're doing a book because you want it to sell well, or whether you're writing a PRD or whether you're writing an email to somebody in work. Or whether you're sending somebody a Slack message. Again, that's where we get that no hello movement from, because Slack message to somebody, hello, nothing. It's not actionable, it's not useful. The Slack message of, hey Gregor, I'm working on this, I need to know this, can you answer this question for me, is far more useful. Now, you know, you need a little bit of understanding, you know, particularly if, say, I'm your manager, that you don't need to drop everything and respond.

Immediately.

But at least now when you see that message, it's actionable and you can respond in your own time, rather than when we get the hello, you respond hello, I've, I've gone off to get a coffee, so I don't see your response. We spend 25 minutes or 2 hours going back and forth with hello, oh, I'm in a— sorry, I was in a meeting. Hello. Oh no, you weren't there. All right. Where— just put the message in, make that communication effective. As you know, hi, I'm working on this, I've got this question. And then leave it because then the other person, whenever they're available, can answer your question for you.

Make it as easy as possible for the other person to get a context as quickly as they can. And speaking about productivity and overall making sure that you're spending your time the right way, do you have any kind of like a favorite practical productivity tool or technique that you use Uh, you know, especially with any kind of AI tool and so on that you would like to share.

So I was thinking about this and I think it just boils down to two things really. Two, three, depending on how you look at it. First is just start. With so many of these things, just starting is the biggest hurdle. Oh yeah, commit. I'm gonna sit down and I'm gonna put 5 minutes into using this tool or doing this task. Just start. Set an alarm if you like and say, "I'm gonna just do 5 minutes." And that 5 minutes isn't that daunting. You should be able to, you know, commit to that without— if you can't commit to it, maybe there's other problems you need to deal with. Once you've done that 5 minutes, you'll have started to actually create some momentum. So after that, then, just commit to another 5 minutes. And after that, again, that momentum builds, so you see, keep going. Now, if you apply this to productivity, and maybe getting something done that you don't like, just start the task, commit to doing 5 minutes. After you've done 5 minutes, it might be a little bit clearer how to do it. So, you know, maybe you've no idea how to tackle this, which is why you keep procrastinating about it. So put 5 minutes in, and just do something on it. After 5 minutes, you might think, ah, this is, this is clear, I can approach it this way. So you then do another 5 minutes. And then after that, as you've got momentum and clarity,, it'll become easier and easier to keep going and finish it. And I apply the same to learning. So if you want to learn something new, I focus on start learning. So go and pick up a book, learn something about a topic, and learn just enough that you can then start applying that knowledge. Then start applying it. After you've started applying it, when you get stuck, go back and learn a little bit more. So again, this is how I advise people to, to learn a new programming language, for example. You know, pick up a book, a blog post, documentation online, whichever method you prefer, and learn just enough to be able to go and write the first basic program and compile it. Great, you now know how to compile and execute a program in that programming language. Then start building something real. Pick a project off Coding Challenges, pick a project that solves your own pain point, pick a project that you've done before maybe. It doesn't really matter which, but having a real project to solve will get you to focus on actually understanding the language. So, yeah, make a start there. Start. When you get stuck, learn a little bit more, start again. Yeah, so iterating between starting, applying, going back and looping over again.

Yeah, a lot of times is more or less just starting, and then, you know, once you get that small first win, that's gonna get you going. And continuously, once you get there you're going to be motivated to do a lot more further and so on. So yeah, that's really good advice. Now, now for the end, I have a more kind of like inspirational question for you. You know, obviously it has changed a lot basically today, you know, people starting their careers today and when you started your engineering career, if you were starting your engineering career today, What would you focus on first? What kind of advice, what kind of things would you do? What would the steps look like from start then to getting your first role and maybe to second and progress in your career?

So if I was starting again today, I would really focus on the fundamentals. Then I would focus on trying to solve a problem and demonstrate I could solve it. I would, I got into software engineering because I was interested in AI. I wanted to build AI when I was 9 years old, and this was in 1980-something. So didn't get very far on the kind of computers we had in those days, and with the state of AI. And AI fairly soon went into one of the AI winters, as there was a lot of investment at that time, and it all spectacularly We failed, and there was a massive AI bubble, which current times look a little bit like. But there was a lot of useful technology that came out of that. So again, I see a lot of useful technology will come out of this one. I do think we're in a bubble that will burst. So again, one, don't be put off. We've had lots of these, uh, claims that various technologies are going to come along and replace software engineers and remove us. So don't be put off by that. So be curious, try and solve a problem, try and demonstrate in public that you can solve that problem. Focus on learning what are the current in-demand tools, because like it or not, people recruit for, you know, 5 years of FastAPI, 5 years Java, 10 years of ChatGPT, or whatever the thing that they ask for. And normally it's, as I've just demonstrated, number of years of experience in something that hasn't been around that long. So you do need, unfortunately, to learn some of the tools and frameworks because they they will be a gatekeeper to a lot of things. But make sure you combine that with the fundamentals so you can actually go and deliver something. I think it's going to be even more important you can demonstrate some commercial awareness, and even more important that you focus on the soft skills. So the things we've talked about, like the communication, the teamwork, and the ability to do stakeholder management and do requirements gathering. So I guess I could sum that up as fundamentals and soft skills balanced with a little bit of one thing that people are asking for in the market that you want to work in.

Yeah, I really like what you said. So yeah, John, thank you very much for sharing all these great insights. It was really great having this conversation with you.

Thank you, Gregor. Thank you for having me on and talk about it.