What skills will stay in demand as AI changes how we work? For developers, preparing for the future might mean looking beyond the next framework and building skills that open doors across different roles.
Matt and Mike discuss five areas worth developing: ideation and prioritization, user empathy, sales, evaluating the quality of work, and owning the outcome. Drawing on their experience in software development and running a web agency, they explore when to push back on a client’s request, why understanding users matters beyond finishing a ticket, and how to tell whether AI workflows are actually helping.
Nobody knows exactly where the industry is heading. This conversation is about building more options - whether you want to strengthen your current role, move into product or technical sales, or eventually run your own business.
Prices subject to change and are listed in USD
Learn to code using Scrimba with their interactive follow-along code editor.
Join their exclusive discord communities and network to find your first job!
Use our affiliate link for a 20% discount!!
We receive a monetary kickback if you use our affiliate link and make a purchase.
This transcript is machine generated, there may be errors.
[00:00:00]
Matt: What skills do you think will remain in demand? We've been seeing a lot of AI, I don't know if you wanna call it hysteria, but I'm gonna call it hysteria in the moment. We've seen a lot of AI hysteria and worry. Justified worry, though, I would say, because AI is coming in and, I mean, how many people are still freelance writing?
How many people are coding? How many people are doing this? How many people are doing that? Is robotics gonna catch up? Lots and lots of talk in the automation space about, what skills are safe, what skills people should be trying to learn, and even if they go to try to learn something, how safe is that skill gonna be and for how long?
Now, no one can predict the future. However, we're gonna be discussing some skill stuff today. We're gonna be talking about what skills will remain in demand and kinda talk about this whole sorta smorgasbord and hysteria, if you will, over the worry over, AI automation and all that other stuff that I already mentioned.
So if this sounds interesting to you and you wanna support the show, you can go and check us out on that Patreon, leave a review or rating in your podcast app, join us in our Discord [00:01:00] server, or share this with your friends. And if you wanna learn how to code and you wanna take some courses to do so, I think you should check out Scrimba.
And not only can you just go check out Scrimba, Scrimba has a pro pa- pro plan that is paid, and you can get up to 20% off of, of that pro plan by clicking our link. That'll be in the RSS description and in the show notes with details on how it works in those show notes. All right, Mike, you are actually the one that wrote up this episode, so I'm gonna pass the mic figuratively over to you to, uh, get your thoughts.
Mikhail: And I'll take that mic happily from you. Uh, so yeah, I think you, I think that's a good, like, baseline that you had. There is some hysteria here. There is some AI hysteria going on. I know personally that, like, engineers are struggling out there for sure, both mentally, like both that have jobs and don't have jobs.
And what I wanna do with this podcast is help in the best way I possibly [00:02:00] can. I'm not an expert in a lot of things, but from what I'm seeing in the industry, I can point out some things that can potentially help you either land a job, keep a job, or move your skills to another area. That's where I wanna focus on as well is, like, we don't know what the industry's gonna be like in five years.
We don't know. Anyone that's predicting it is wrong. I can almost guarantee that. It's going to be very different than it is today. but we don't know if it's gonna be maybe back to more code-heavy, maybe less code, maybe no code at all. Maybe it's gonna be a completely different language that we're gonna be speaking.
Who the hell knows? Uh, but what we do know is that there's certain skills that are foundational and can, like... I can't even... I, I don't even know how to say this. They, they, they break out of the field. They break out of any field. They're really something that you could take to any other field. They're something that you could take to further your career.
They're something that you could take to expand your own [00:03:00] horizons kinda thing. And that's what I wanna really focus on today is g- like, really nailing down on those skills that I've seen. And I'm sure there's more, by the way. These are the ones that I've personally encountered that I think could differentiate.
And also, the other thing that I wanna preface this with, I'm not an expert in some of these. I, in fact, most of these. This is something that I'm working on myself because I see there being a gap, and I see that being as something that could help myself personally continue in the industry
Matt: I, I think that what your intro kind of brings to light or brings up is, is almost the elephant in the room, which is that one is gonna know the future, no one knows what's gonna be replaced, when it's gonna be replaced, how it's gonna be replaced, or if it's gonna be replaced. Is it gonna be replaced partially?
Not at all? Is it somewhere in between? Usually things land somewhere in between, but who knows for particular niches. I was on one of the subreddits for freelance writing at one point earlier this week, and I saw some posts on there [00:04:00] that was like, "Who's actually here still, you know, doing freelance writing for money?"
And there were some people, quite a bit of comments that were sort of like, "I'm just doing it for passion. I'm just doing it for fun. I'm doing it for hobby." Clearly it's, you know, the freelance writing space, or at least in that particular community on that particular thread, obviously it's not a sample size of everyone, having some trouble.
But then I went on, then I went on Medium. I was doing something on Medium and, and there was an article there that was talking about this person who in 2026/2027 had started their, their paid writing career and is doing great. So there's a, there's always, you know, gray areas. There's always questions.
There's always this. think the thing with this whole AI thing is I think a, a good piece of general advice is gonna be To try to skill up as much as you can. If you, if you think that coding's gonna be replaced, what I mean by skill up is maybe don't [00:05:00] go all into coding. Maybe go and look and say, "Okay, you know what? I'm gonna start to..." And just even just start, even if you just start sort of, sort of doing some light reads. "I'm gonna do some light reading in X field that I think might work out." Because you're estimating the best that you're doing, everyone else is estimating the best that, what everyone else is doing. I think the thing is is that, and, and at least in my opinion, it's, it's possible that developers will be replaced in 10 years. It's, it's entirely possible. I know that some people think that that's absolutely true. I know some people think that that's absolutely false. And, and, and the fact is is no one knows.
No one knows that. Not even the, the guys in charge. Not even OpenAI. You know, Sam Altman doesn't know that. He doesn't know that stuff. But I would say that it makes a lot of sense to say, "Okay, I'm going to try to skill up in another place." Like Mike, you have some skills listed here, like sales for example. we've mentioned GTM engineer, the go-to-market engineer, which is closer to the consumer, closer to the client than ever if you're working for a [00:06:00] company. And I think that those are just smart decisions. This isn't a radical change. I'm not saying you have to drop everything and go from developer to plumber.
That's sort of the meme that's out there right now, and I'm sure some people are doing that, and whatever. I mean, if you wanna be a plumber, go ahead and be a plumber. My advice might be wrong. The whole point right now is that everyone's sort of in flux. Everything's sort of abstract right now. And I think ultimately what we need to work on is...
Or what we need to do is we need to, to look at how to navigate the situation we're in, I think is, is the most important thing right now. And, and what the situation is telling me, and it might be telling you something different, is that I need to do different things. Maybe I need to make some apps that make money. "Oh, software's dead. Software's dead." That's all I hear now. Okay, maybe software is dead, but I'm not seeing that en masse, so personally I'm not gonna worry about it. But if you believe software is dead, then maybe you shouldn't be into that area. The [00:07:00] entire point is is that you should be... you're a competent person.
Like, like think about it this way. You're a competent person. There's an adversarial situation going on right now with AI. Do you think that AI's gonna be your adversary, yes or no? How are you going to navigate it? And Mike, you and I had talked about this prior to the podcast, but I was like, y- we can either navigate it or we can navigate it and panic. It's kind of the, it's kind of the two choices. I suppose you could just lay down and do nothing, I, I guess, but if that's not an option, which it isn't for many people, you can either navigate it or navigate it and panic. Personally, I'd rather just navigate it and not panic,
Mikhail: Yeah,
Matt: panic gonna do?
Mikhail: and, and I think exa- exactly. And I think navigating it is a really good point as well, 'cause there's a lot of people that are just, like, blindly doing the same thing that they were doing before, right? Like, they're just ignoring what's happening, and I think that that is arguably a worse thing than panicking.
I'd almost rather you panic than do nothing. But obviously pa-
Matt: say if you're in a secure job though, I don't [00:08:00] necessarily think that that's the worst. If y- if you are in a place that really values traditional coding, hasn't really been hit by layoffs, you don't think you're gonna get laid off, you think that, like again, intelligently work toward your own situation.
I understand that it's
Mikhail: Yeah
Matt: maybe, maybe somebody's gonna show up in the administration of your company, be AI pilled and, and fire everybody, sure. But also this could have happened years ago. Someone could have showed up and said, "We're gonna use no-code tools for everything. Everybody out." They could have did that 10 years ago. So to me, I just think that you should navigate your own situation. Obviously, we're speaking to the general public right
Mikhail: Угу
Matt: and so, like, you have to kind of take genera- a thing. And you're, you're making a, a case of... I kind of cut you off there, but you're making a case of like you should skill up in other areas no matter what. I think in a utopia, sure. But I think that you should really look at your own individual case. I don't know what you think about that.
Mikhail: No, y-y-you're not wrong. if your boss is constantly harping how AI is bullshit and don't use it, and constantly, like, pushing towards that, [00:09:00] I could see where you can c- you can, you can come in and be like, "Okay, I'll just continue doing what I was doing then." That's fine, because if, If it's coming from top-down, that helps.
My only worry with that kind of mindset is if the industry you're in has other players that maybe are focused on expanding and growing and doing things differently, they could eat your company for lunch. Now, not saying that using AI would change-- would potentially, like, give an advantage to your competitors.
there, there hasn't been actually a lot of evidence of that specific use case yet. So, like, take this with a grain of salt. but if, if your company is not adapting and the-- your competitor is adapting, maybe in a year that will change, and therefore your company could go down anyway, even if your boss is constantly harping on the fact that AI is bullshit.
So I don't know. I, I would still keep my eye, my hand, my, my finger on the pulse. I would s- Like, especially in the industry we're in [00:10:00] today, I would spend a little bit of extra time skilling up, like you're saying, making it so that you're a little bit more hireable in a market that could potentially shift.
Because if, if you go down the path of just being complacent and your company's fine with it, but then they lay off everyone in a year because they weren't able to keep up, you're not gonna be as hireable as the person that was, that was going through the wringer with their boss being AI-pilled, unfortunately.
Matt: Yeah
Mikhail: That's the, that's the risk you take. And, uh, you're right. Every, every situation is different. Your life pos- Your life changed. you might be in a com- in an industry that can't be affected by AI. It's possible. I don't know if, uh-- I don't know what those industries are, but I'm sure there's something, like, out there.
So, like, yeah. Use your own judgment for sure. U-use your own common sense. But my suggestion, again, it, it stays the same to the general public is I highly recommend you skill up. I highly recommend you broaden your horizons. Look outside of [00:11:00] just pure code and, code quality and whatever else you were focused on a year ago.
Matt: Well, I, I was actually gonna just t-touch on that and I'll ask you. So, what I was saying is like, you know, if your boss is, like, anti-AI... It doesn't matter if the boss is anti-AI. If your company respects you as a developer, you're doing your manual coding, you like doing it and, you know, everything's good, profit margins are good, whatever, yeah, anything could happen.
I mean, job security was kind of a myth, like, 10, 15 years ago, so I
Mikhail: Yep
Matt: and I get that. My, I guess my question there is, is do you think... 'Cause, like, people, people in, in the space, so I, I had a conversation a, a while ago, and I'll link it in the description, with Dyl- Dylan Israel, and one of the things that we had discussed, one of the points that we touched on, was if you are a person that never leveled up your planning, or never leveled up your coding skill, then you're gonna have trouble getting hired.
So e- an example is, and I'm paraphrasing from memory, but an example was is that he had seen or heard of somebody who had been in a kind of a traditional web agency, web development agency, who had been fired or laid off or whatever, I think it was laid off, [00:12:00] and this person has, like, basically was a jQuery expert.
And the industry in terms of the zeitgeist certainly, and a lot of the frontier stuff certainly, is not really on jQuery. Now, jQuery is still used. It's still used a lot. It's not used by two people. It's used by a lot more than two people, right? But the thing is, is then he goes, "Oh, I'm, I'm a web developer," right, kind of how he identifies obviously, and tries to go get a modern, a modern sort of job in any of these frontier areas, and is of course gonna struggle to do so because he's never leveled up his skill. He's likely, I would imagine, leveled up his skill in jQuery, but hasn't taken a look at the industry. My point there is, though, is the advice in that context is try to level up your skill and go learn React or go learn this or go learn that. For the sake of this episode, are you kinda saying that you shouldn't even be doing that?
So if, if you are in what you think is a secure position, you're, and you have React, so you're on the, quote-unquote, "frontier" or whatever. You're in a modern area where, like, you're w- using NextJS and you're using React. That's a modern stack, right? [00:13:00] the sake of conversation. would say, "I'm in a really good, solid position. I'm gonna continually level up my skill in React and NextJS." You're saying to maybe level up in other areas. Like, you're saying to, like, expand out from that normal stack skill learning, I suppose.
Mikhail: I am, I am. I am very much, uh, saying exactly that. Like, spend... You still need to, you know, do your work, which will inherently level up your skill. If you're doing traditional coding, the more you code, the better you get. Uh, but outside of that, I would start looking at, you know, agentic coding and then some of the skills that I'll mention in this episode.
That's what I'm saying
Matt: Yeah. So, okay, so essentially, 'cause I know that some people are gonna listen and say, "Oh, I should just keep... As long as I keep skilling up in my React and my whatever, you know, I'm safe." And maybe that's the case. And, and that's also gonna be a bit of a tug of war because if you're
Mikhail: Naprzód
Matt: position and you think you're gonna be there for another five or 10 years, I mean, you can't just sit and be like, "I'm just gonna know the [00:14:00] skills I have today and not get better." You kinda, like, have to get better at the skills you're doing, right? 'Cause if you think you're gonna be there...
Mikhail: It's tough. Yeah, no, I, I--
Matt: this is, this
Mikhail: It is a mess. Yeah, it, it is absolutely a mess. Um, yeah, it, it, I... It's very difficult to give recommendations in that situation, but I just don't see any world where at some point someone comes down the line in some leadership or maybe even like senior engineering forum and is like, "We have to try this."
At some point it's going to happen. I'm sorry. Like, a-again, unless you're in a lockdown industry of like, "Hey, we can't have any external connections," and that-- It might take a long time i-in that situ- in that situation where IP is extremely important and, you know, all that stuff.
Matt: There's
Mikhail: it's still doable
Matt: there. Like, we, we, you know, you can't account for all of them in a conversation.
Mikhail: Absolutely. So I'm talking generally. I'm talking generally, uh, and I, I just don't see a world where, like, an industry [00:15:00] is just gonna-- Like, a, a company's just gonna stay stagnant for an extended amount of time while this stuff is happening. it's very difficult for me to see that. Possible, probably will happen, but it's gonna be outliers, in my opinion
Matt: Well, the other thing too there is that even if, even if it isn't anything to do with AI coding taking over or whatever, the economy in general is kind of in a weird questionable space. We see a lot of complaining about it on social media. I have not checked the economic numbers from whatever politicians and everything else. But the thing is, is that we, you know, we see a lot of complaining and, and et cetera, et cetera, and we know that the job market, especially for tech workers, is in a weird spot. Now, this morning I saw, oh, there's, there's been more job postings than ever, but companies are slower to hire. But then I've also seen maybe it's different positions, like not programming and stuff. I haven't done my research into this, but we do know that there are people that get laid off are not getting hired right away. It's not like they're being like... It's not like a company's like, "Oh, thank God you were laid off. I need your help," and then you come, you know, rush in. You know, you literally go leave one building and run into the other.
It's like it could be weeks, it could be months. It's, it's a tumultuous [00:16:00] time for software engineering, in terms of a job. My point there is if your company doesn't a- adopt all the AI nonsense, whatever, and then they end up g- having some sort of business trouble in a traditional sense,
Mikhail: Yep
Matt: just decides they wanna do a reorg, and then you get laid off, now you're thrown into the modern,
Mikhail: That's the problem
Matt: market.
That's ... Which is another huge, another huge problem
Mikhail: It's a huge problem. Like, that, that, that I think is one of the, top problem right now is that, like, you're just not prepared for what you're about to hit. The mo- the modern job market. And it might get better. That's the thing. Like, uh,
Matt: Well, it
Mikhail: I think, I, I think it will get better personally. I think right now it's at maybe an all-time low, at least anecdotally, like from everyone that I've talked to recently, it seems like an all-time low.
not from a job posting perspective, from like actually getting a job. 'Cause people like, the, the people I've talked to are, are getting interviews. They're getting like a good, a decent amount of interviews, honestly. Like, even compared to like a year ago, it seems like the interviews are [00:17:00] going at it. So there's jobs available.
It's just, I think no one No one knows, how to hire right now because the inter- like the... Everyone's skeptical of the interviews, everyone's skeptical of the applications, everyone's skeptical of the resumes, everyone's skeptical at every stage. It's becoming extraordinarily difficult. Now, I don't wanna get too far down that rabbit hole right now, because I think we're gonna do maybe a web news on that, on that, or maybe, like, a whole episode later on on that.
But there, it, it's, it's a very weird time in the job space market, and this can help you either, again, penetrate the jobs a little bit more, talk yourself into a job in a, in, in a, uh, during a interview, or potentially, again, shift a little bit, like, like the GTM engineer role that Matt mentioned.
Like, that's p- along the lines of what I'll be talking about so let's jump right in to the skills that I [00:18:00] think are still in demand and aren't going to be affected as much, by AI, at least in, in the near term, right? I can't tell you what's gonna happen in five years. I can't.
Matt: I was gonna say, and, and,
Mikhail: Even a year.
Matt: to begin with
Mikhail: Very much a ve- a very big estimate. But these are the skills that I think could, could still be pretty relevant. Number one is kinda like a combination here, which is ideation, prioritization, and saying no. So this is a skill... This is like a... A lot of these are gonna be soft skills really. They're not gonna be very hard technical skills because of all the shit that's going on.
This skill I'm not very good at, I'll be honest. Ideating especially is something that I struggle with, like just coming up with a list of ideas that I think are actually going to be good. I'm much better at critiquing an idea, I found. So I'll... I can come up with like 100 ideas, but I will find the exact reason not to do each and every one of them.
Whether that reason's correct or not, maybe yes, maybe [00:19:00] no, but I'm always leaning towards the not doing an idea rather than doing an idea. So I feel like if you're good at having that gut feeling and then f- following that gut feeling up with like actual analysis on why that idea is good and why it's worth the risk and why, and, and why it's, it's worth doing and et cetera, et cetera, that can set you apart ' Cause it's hard.
And that's another thing, that's another trend with these. These are soft skills that are actually difficult If something is
Matt: like, like bra- the brass if
Mikhail: Absolutely.
Matt: You're speaking up to the brass
Mikhail: You're speaking up to brass and you better have good, good way to, s- explain why you're saying no. You better articulate yourself really well, right? So this is not an easy skill, and again, that's why it's valuable.
A lot of these are not easy. That's why they're valuable. And some people might say "Oh, you can't learn this kind of stuff." I disagree. This is something that you can learn. It's gonna take you some [00:20:00] time. You're gonna fail at it, but you can learn it. It is learnable. It is something you keep trying, you keep doing different things, you keep finding a way forward.
you go down different paths, you talk to people. You d- you, you know, you have hard conversations and eventually you'll get better at figuring out, okay, what's this? Is this-- Does this make sense, If this amount of people can buy it, et cetera, et cetera. And a- again, prioritization and saying no, it's all in the same bucket, right?
Like prioritization refers to like what feature should you prioritize? Like you can build 100 features now
Matt: Yeah
Mikhail: a, in a week. That building is no longer the problem, but maybe fixing onboarding can get you 10% more customers. Knowing that direction to go, knowing where to look to get a result at the end that is satisfactory to the effort that you're gonna put in is difficult.
It's not easy. It takes ti- trial and error. It takes-- There's systems involved here, right? You need to, you [00:21:00] need to look at the, at, at, at the project as a whole. You need to look at the stakeholders. You need to look at the management of like what they want. Maybe they don't care about increasing signups.
Maybe they only care about retention, knowing that, knowing that factor. Like there's so much involved in each one of these that learning how to do it right and learning how to do it well, you're gonna fuck up even d- even if you're amazing. But like y- learning how to do it well, that's gonna set you apart.
You're gonna be someone that people are gonna be looking for. A lot of these like higher level management people, the successful ones I wanna say, this is where they're good at. This is what they're good at.
Matt: Yeah
Mikhail: They're good at seeing the picture. They're good at seeing the audiences. They're good at seeing what, what, what needs to be built.
They're good at pointing the right people in the right direction to get the right results. Now this is a management thing, I understand that. But it's also if you look at it from a smaller perspective, if you're building a small app for yourself, if you're building a small app for a [00:22:00] company, you as an engineer can make some of these decisions.
You can say no. You can tell them that, "Hey, if we build this, this is the consequences of building it." you can start providing that feedback and it-- and the, the engineers, the developers that are able to put themselves in this position are going to be harder to replace
Matt: It's also difficult 'cause it's a bit of a tug of war when you, when you say no people are gonna say, "You're just saying no 'cause you don't wanna do it," and then you're gonna have to justify yourself. E- especially if you're customer-facing. We're, we're a web dev agency. Mike and I run a web dev agency, and, like, the thing is, is, like, we'll have some customers, and I've had customers complain and say, "You just didn't wanna do this, this, and this because you, you just didn't wanna do it." And my argument is, of course, "Well, hey, like, you pay me to do it, obviously, so why would I, disagree with that?" But then I have to have, like, a good justification, and the justification often is, "This is a big amount of money. You've been my customer for a while, and I think that this isn't gonna help you at all. Now, if you really, really push, I can do it, you know, [00:23:00] I don't think that your, one-person or two-person business is gonna be able to benefit from, this cra..." Like, oftentimes they're asking for, like, a crazy, a crazy thing.
Mikhail: Mm-hmm.
Matt: "Let's have a full custom CRM built for me." Why? know, why, why are we talking like that? Or, or even just to set up, set it up. "Hey, can you set up this, like, crazy CRM?" Again, I, I... and, and we've gotten cr- uh, feedback, critical feedback on this podcast in the past w- 'cause we've said no to clients for stuff, and people will say, "I just do whatever the client asks."
Y- yes, and, like, for us, though, we treat it more like we're a solutions engineer. The person who really pushes, fine, and I'll make that clear, yeah. fine, I'll just do it. And, and it's the, it's the same case here. If y- if you're the engineer and you say no to your tech lead, and your tech lead's like, "Well, we're doing it," you do it, and if it crashes, it crashes.
at least your, you know, your voice was heard, I suppose. Little solace there, but but,
Mikhail: Mm-hmm
Matt: the thing is, is, is, you know, with a [00:24:00] client, we are trying to sell them on a solution that benefits them, I'm going to say no to things that I think is, I think legitimately is gonna hurt them. And I'm down to have a conversation.
I've been convinced otherwise. If they say, "No, we actually hired these people, and we think this is the reason, and this is why we need this CRM, because we're having so much trouble with our email," and then, they show me, and I say, "Oh, you know what? You're, you're doing way more than I thought you were doing.
Okay, let's have that conversation." that's more of the relationship that we have with a lot of our clients 'cause a lot of them are longstanding. And then I'm down to do it. I'm down to have that conversation. So I th- reason why I even mention that is because it's important to say no, but when it's appropriate, but it's also important to be able to have the back and forth. 'Cause you might say no because you heard one version of the story from them, and then there might be more details that they just hadn't divulged yet. Maybe it changes your no to a yes. at the very least, that conversation was had, and oftentimes it's important.
Mikhail: Yeah, and it's important how you say no too, right? Like, I'm not gonna give ... Like, this episode isn't about me teaching you these [00:25:00] skills. That's one thing that I wanted to- I should have pointed out at the start. Because again, I'm learning these skills as we go as well. these are the skills that I've identified for myself that I need to get better at.
Matt: Yeah
Mikhail: So you do your own research, go down the paths, but I, what I know is that, like, if you just say flat out no to a client with no reason, they're gonna be pissed
Matt: Oh, sure. Like, I don't do that. it's definitely like a, more of a conversation,
Mikhail: Yeah, it's, it's like, "Oh, that's a good idea, but da, da, da, da, da." Right? you give a positive take on their idea. You're not just gonna shut it down, but be like, "Hey, what have you thought about this?"
Like, you don't even say no, you're just like, "Okay, we could do that. Let's think about this. Let's think about this." And then let them get to the path of saying no themselves. Like, there's many different ways that you can get to a no, right? As long as you're able to communicate it in a respectful way to the client, and there's some clients that might want you to be blunt, right?
So it, it's all about knowing that nuance, and it's not easy. Again, this is not going to be easy, but that's the point. If you can do the hard stuff, this, [00:26:00] this kind of social hard stuff, yeah, it's gonna set you apart. I can guarantee you that. It's gonna make you more hireable. It's gonna make you move up faster.
It's going to make you one of the, a top person in a space where we can build infinite things if you know what to build. This is part of that. The next one here I have is user empathy. So user empathy is an interesting one. When you're designing something, this is kind of like a designing thing,
this is a UX/UI designing, and the reason that I bring it up is because I think a lot of engineers are very jaded towards users. They're like, "I get a ticket, I finish the ticket. I don't care if the user, is able to do it. I, I completed the ticket to the spec of the ticket." That's the traditional engineering mindset that's been around for a really long time That kind of mi-mindset right now I don't think is gonna cut it.
It's, it's still there. it's fine if you need someone to kill tickets. It's fine. But to set yourself apart [00:27:00] is being able to understand how your ticket affects the stakeholder, the end user, and being able to implement something that is going to be a, a, a benefit to them rather than a negative, right?
Like so if, for example, your ticket is to create a 2FA system for a, like a two-factor authentication system for an application, you could make it in many different ways if you have the, the freedom to do that. One of the ways could be like, you have to type in your code, manually. You can't even copy-paste it.
you could add friction points just for the sake of adding friction points or by accident.
Matt: Right
Mikhail: But if you're a user, if you think about the user, you'd be like, "Okay, what's the easiest way for them to do it? Well, maybe I should add pass keys." That's a 2FA method, right? That's an easy one.
Maybe I should make it so that it's super easy for them to copy-paste the, email 2FA code, right? You start thinking a little bit ahead. You start thinking the next step of what makes it easier for the [00:28:00] user to actually do something. And again, when you bring this up in a product meeting, when you bring this up in a management meeting, that's going to put you above.
That's gonna take you a step up 'cause you're starting to make it so that the users are enjoying using your application. And if product has anything to do with it, they're going to be happy about that outcome, and they're going to be, be like, "I need to keep this person because he cares about the product."
That's the mindset that I'm coming into, to this from because right now product kind of... I-It is fairly important. the product managers or the product, you know, developers, they're, they're starting to get elevated because they're the ones, again, that are coming up with the ideas.
They're the ones that are leading the design of a product. They're the ones that are going end to end with the product. And engineers are starting to lose that importance. So you need to put yourself higher on the product list
Matt: It's interesting you say this 'cause I, the thing I think of immediately is that customer [00:29:00] service has kind of gone down the tubes in a lot of
Mikhail: Угу
Matt: I mean, I see a lot of just blatant bugs even in major software where, oh, I went into the two-factor screen and I pressed escape to get out for a second 'cause I didn't have the app ready and it was gonna time out, and then now I can't get back into it.
And just, like, little things like that. That's just a couple of examples. I'm not gonna go down, like, a laundry list. The, the thing is though is that I think user empathy would solve a lot of that, but I
Mikhail: Mm-hmm.
Matt: wonder because this, these bugs and because these issues with customer service is making it into customer-facing software or interfaces, how much this is actually true, which is interesting.
Like, you mentioned product coming into the meetings, and that makes a lot of sense. if you're, if you are a person that's in there with the product managers, then, then yeah. Or the UX, UX, UI/UX people even to an extent where they're like, "Yeah," like, "You should make this easier to copy. You should make this and that." I question this. Like, I would love this to be a, a main priority of companies. I kinda think it isn't, though, unless... and that's just evidence that I'm seeing. [00:30:00] Maybe I'm being pessimistic, but... 'Cause we've e- you and I have even had conversations, Mike, about getting to market is the only thing that matters. if you're gonna spend 10 minutes making the code easier to copy, I don't wanna talk to you, is the idea.
Mikhail: So yes, you're, you're correct. The prerogative has been build, build, build, fast, fast, fast. The reason I still think that this is relevant is that by having user empathy when, when you're prompting, the output can be better, and I still think that they're internally, companies are still doing evaluations on, which engineers are building the features that have the least amount of issues r- reported to them.
Because yes, the prerogative has been build, build, build, bugs, bugs, bugs everywhere. Screw it. But there might be a reckoning at some point.
Matt: Oh, sure
Mikhail: So you're kind of hedging your bets [00:31:00] there. And second of all, if you can, in the interview process, talk through user empathy to, to the product team or whatever, that's going to help.
Talk about...
Matt: good. It,
Mikhail: Exactly
Matt: world, you would have, you know, top user, top user empathy as well as, you know, amazing QA and all the rest of the things that come along with it
Mikhail: Exactly. Exactly. You're, you're thinking ahead a little bit. You're thinking more product-minded, and again, thinking more product-minded right now is a, is a foot in the door
Matt: I will say that th- that particular angle makes sense because I remember working with a guy who just dealt with the VPN driver and couldn't tell me where the VPN menu was in the settings on a particular app we were working on. It was like he worked on the driver, I think he worked on the driver or like the backend code of it, and he worked on the actual networking mechanism. But then I was like, "Yeah, let's open up your VPN. Let's see if it'll work," 'cause I was more IT facing and he, he didn't know where it was. He's like, "Where's the VPN menu?" And so that guy was completely blind to user empathy. [00:32:00] Doesn't even know where the VPN menu is for a customer-facing menu.
Mikhail: Yeah, for the thing that he's working on. Yeah.
Matt: thing he's working on and has been
Mikhail: Mm-hmm
Matt: But then when, when I talk to somebody, and this is me paraphrasing from memory, I think I've told this story before, but it's been a long time. But it was something like I spoke to someone after and they're like, "Yeah, that guy just solely works on this and has been doing it for years and is amazing at whatever the heck he's working on, that driver, what have you, and, he doesn't know anything else."
It's sort of interesting to me like, okay
Mikhail: Yeah, there might be some value there be- that I don't know about where you still have some of the domain knowledge experts that, are keeping systems together. That, that there is a thing there where if the system's big enough still, AI is not able to completely replace it. That's still a thing, right?
A million, million context is, is what we've hit, hit against. That's not enough to replace like a massive code base. There's still issues there for sure. But I have a feeling that's gonna be solved at some point, so it's not-- I wouldn't rest on those laurels, but it is a thing. [00:33:00] So the next thing I ha-- the next skill I have here is sales.
we had an whole episode on like sales engineering, GTM engineering. This is along those lines. knowing-- being able to be called upon to do like the demo on a sales call and to be able to speak to a client i- is a differentiating factor. That is a very good skill to have for an engineer. If you're able to sell the product that you're working on, if you're able to understand it, I can almost guarantee you that'll put you above someone else that is, has a lot of trouble with that.
Matt, you need to have a rebuttal. I need to go grab a water because I just drank my entire water. Be right back
Matt: Well, I was, I don't really know if I necessarily have a rebuttal while Mike goes and gets his water there. But I have experienced this where I've been a, a part of engineering a system together, getting, getting these servers to work here, getting these servers to work there, and getting everything kind of up and [00:34:00] running and, and working in that regard. I've been a part of those calls too where they're like, "Hey Matt, can you do like a quick demo?" And being able to ver- very quickly, do a quick demo on the thing that I architected is, is extremely valuable. Mike, I think you were I think listening through, through, through all that, but you and I had worked on a system where we had distributed a whole bunch of kiosk machines, and I worked on all the backend stuff, making sure all the logins worked and all that kind of thing, and then w- I was just kinda thrown into a call and we were able to, you know, be able to demo the product to, to people.
And so it's... 'Cause I understood what was going on. I didn't just go, "Well, I only understand the admin panel in, in, in the background," which goes to, user empathy. You see how these like skills are starting to like meld a little bit, but also sales,
Mikhail: Mm-hmm.
Matt: it's like, okay. And, and like there's, there's been times where people will say, "Hey, is, you know, is Matt or whomever a- available for questions?"
Like can, can you have him on the thread for questions? 'Cause if someone is looking at replacing a major part of their infrastructure, their technical infrastructure, they're gonna have questions, and if they like your demo, like now you're kinda close to sales. You know, the, the salespeople [00:35:00] were on that thread and so were you for the technical questions, and like if you have good answers, then that could help the sale 100%. And so being kind of like aware of, of being a- I mean aware of sales and, and, and that end user is, you know, kinda goes, in my opinion, goes hand-in-hand
Mikhail: And, and one other important thing about sales is that it gives you options. So if you become good at sales, and again, I say become good because you're probably gonna be shit at first. This is something you have to practice at, something you have to learn. If you become good at sales, that gives you the ability to potentially shift to a more, technical sales position if, if it, if it comes to that.
That gives you the ability to maybe start your own business, because starting your own business, most of the work that you're gonna be doing is gonna be sales, at least the, the beginning of your job. It, it gives you the ability to shift horizontally, vertically. It, it's just... It's a core skill that enhances what you already have and gives you the, gives you flexibility, which is, I think, kind of like the epitome of what we want [00:36:00] in this episode.
It's not for everybody, and it's not easy. Again, it's not an easy thing. And like the sa- sales jobs in themselves are really, really tough jobs, but they're high-paid, and I don't think anytime soon at least AI is going to be replacing a traditional sales position. And I might be wrong on this, but for, for most people that I've talked to, they don't want to have an AI call them and try to sell them something.
it makes them angry. they're already angry at sales calls. People hate cold calls. When they hear an AI talking to them, if they can figure out it's an AI, so that's a whole other conversation, but if they understand that it's an AI talking to them, they start to get even more angry.
So I think sales is still gonna be a human thing for a quite a long time, and being good at it will differentiate you quite a bit from everyone else. So again, it's a skill that's worth looking into. It's a skill that's worth trying out. if you're in a position in your company where you can be like, "Hey, can I join you on a sales call and kinda help you out here or [00:37:00] there?"
I would recommend it just to put that on your resume because, again, it's GTM engineer is something that's growing quite a bit
Matt: The robocalls thing is definitely a good point. I mean, even if you're... Could you imagine, like, high-class sales? Like somebody who,
Mikhail: Nie
Matt: a mill- like, a million dollars in spend at your company, or $10 million in spend at your company, and then you'd be like, "Yeah, just throw them to the robo guy."
It's like, no, they're gonna want probably their salesperson, their dedicated agent or whatever, and that's who they're gonna wanna talk to. And I mean, even our, we work with a host who's ef- effectively a small business, I guess from a legal perspective, small to medium business and, and I had, like, a pretty big ask of them, during COVID, and they were kind of having trouble securing hardware, quickly because of all the shortages and stuff.
But they, they sent me to a, a live agent. they got me, they were like, "Oh, I'll give you this person, they'll call you up," and then they had, like, a big conversation with me and gave me a discount and stuff, and we've been with them ever since. Now, I'm not saying it's 'cause of that, but the thing is, is that's sales.
Like, that is [00:38:00] sales. So I still remember that. I just talked to you about it, and it, like, I don't think that that's necess- I'm, I'm not gonna be like, "Man, that robot was great. robot, that robot gave me 5% off. What an amazing, what an amazing tool. I hope that robot calls me again."
Mikhail: Mm-hmm. Yep. I just, I don't see that happening anytime soon. I don't know, like, it, it could be a barrier that's never broken, to be honest, and that's why I think, again, sales is, is a good thing, like a good skill to have if you can do it.
Matt: I agree
Mikhail: Yeah
Matt: At the very least, e- even just transitionary, like you said, with
Mikhail: Yeah
Matt: opening your own business or whatever. Transitionary or if you work at a small business that might need help with multiple h- like wearing multiple hats, I mean, there you go
Mikhail: Yep. Next thing here is evaluating whether work is actually good. This is probably the most technical one on the list, honestly, because what, what I, what I think is still a very important skill to have in engineering is providing the right feedback loop for a specific feature that you're working on or for your [00:39:00] application, right?
So when you're giving, an agent a task, eval-- like having the right criteria of completion for that task is part of this process, evaluating whether work is actually good. There is a lot of gut to this. There is like, you know, you have to actually go in and know what to test and know what looks good and what doesn't look good, so there is some taste here, and it's not just technical.
But there is a very big technical component to how do we evaluate if this agentic infrastructure that you've implemented across your company is actually providing the right output? That's a very-- it's not a solved question. Right now, like we've talked about this on the podcast before, but companies are looking to like figure out if agents are actually providing any boost to their productivity or not.
Matt: Yeah
Mikhail: you come in with an answer to that or a potential ability to, pitch an answer, that's gonna be something to think about. That's gonna be something that could separate you apart. if you come up and, you talk about it on, [00:40:00] during a management meeting or during like an all-hands or something and be like, "Hey, I have this system that I want to put in place to evaluate."
Like there's-- it's not an easy thing to solve. On a small scale in like a feature, yes, you can, you know, you can use your technical skills to figure out like what tests to provide, what end-to-end, you know, out-- like, you know, agentic computer use systems you wanna use to be able to see if the login form that you've implemented has the right information.
The more, again, the more feedback loops you give an agent, the better the output is, so that's a big part of this. But also on the grand scale, okay, a new model just came out. How does your company evaluate if it's worth switching to it? A hundred, you know, if it's, if it's $100,000 more a month, is it actually providing $100,000 more value a month versus this other model?
That's, that's-- those questions are very di-- like they're, they have not come out, come up yet, and they're going to come up, I can guarantee you, within the next, one to five years. It's gonna be a [00:41:00] very big thing that companies are gonna be like, "How do we evaluate this?"
Matt: Well, it's 'cause, it's just like we mentioned this in a previous podcast, which is the, open concept craze
Mikhail: Mm-hmm.
Matt: It was, it was almost like you got kudos just because you had open concept.
Mikhail: Yep
Matt: they were showing off trailers and stuff, they'd be like, "Take a look at our office.
It's fully open concept." And other companies would do the same thing, but no one actually did that evaluation whether the work was good. It's like... And I don't mean the work as in the contracting. Like, if, you know, the contractors go in there and they make your, your area open concept, as long as it's, you know, secure and safe and w- up to code, then, I mean, then that, that work is good. But is it good work for your business? Your business, the goal is to make more money or to have more staff or to have less staff or whatever the heck it is your goal is. Is the work that's been put into this, the idea of, you know, going open concept, is it actually helping productivity? And in a lot of cases, it was actually hurting productivity for companies, open concept was.
And AI is sort of a similar trend in that it's like people are getting kudos just for having agentic workflows and just for using AI. But no one's gone in and said, "Are you [00:42:00] actually doing more?" Mike, you and I just had a conversation over context switching, and, like, context switching is getting out of control.
We run a small business together, and there's not that many things to do at the end of the day, but there's still a bunch of different contexts. You're still running around with multiple hats. AI has helped it but has also kind of made it worse, where there would be times where multiple of, multiple agents are done their work, and you need to go in and verify it.
Or they were, preparing something for you to actually then do the next step of. You're the next step. And you're context switching all over the place. Small businesses naturally context switch with the multiple hats, but now there's even more it seems because the AI isn't doing the closed loop.
Now, you could say, oh, maybe, you know, you have a closed loop this and that, but that also needs to be evaluated. That also needs to be looked at. Maybe you do have an AI that does go do all your cold calls, but are you only getting 10% and before you were getting 20 and people actually messaging back? Okay.
Well, is that actually good or bad?
Mikhail: Yeah, we don't know. Like, it's, it's a whole, it's a whole thing. Like, it's, it... Thi- [00:43:00] again, this is a hard problem to solve. I'm, I'm mentioning these. I'm mentioning all of these are hard. None of these are easy, but that's good. That's, that's where you can, you know, differentiate yourself because it is hard
Matt: It, it, it's, it, it's like A... It, the first thing I'm thinking of is like A/B testing, but
Mikhail: Yeah.
Matt: really, in a, in a
Mikhail: how do you ha- Yeah, it, it is. It, it is that, but, like, how do you do that on scale? How do you do that across, like, so many weird workflows that you're implementing and, like, what do you, what do you determine good and bad? Like, you can A/B test all the-
Matt: is like you, you oftentimes like will have like a focus group. You know, well sometimes you'll
Mikhail: Yeah
Matt: group of the consumers, let's say you're AB testing what the consumer sees. The problem with these AI workflows, especially internally, is that a lot of the time there's no standardization.
So I might be using Codex and like you might be using Claude, 'cause some of these companies have multiple AI subscriptions. I might, I might have a workflow that's completely different to you, Mike. And so now it's like, well what do we... how do we eval- evaluate that? Like we have to evaluate Matt, who's a different entity than Mike, [00:44:00] and we have to somehow evaluate is it, if it, is it helping them individually.
But what if Mike is getting 20% more productivity? Okay, great, so then we'll apply Mike's system to Matt, but Mike works different than Matt, so now Matt is actually hurting in productivity 'cause he's trying to use M- Mike's sys- Mess
Mikhail: Yep, absolutely. Just an absolute, absolute shit show Last thing I have here is owning the outcome. So this is kind of putting everything together, but... And this is a very product-oriented skill where, a product manager would want this skill, but, like, if you're an engineer that has this skill, that's an, again, a way for you to move to something like product, product engineering or product management.
It's a way for you to shift and, and de-risk yourself from losing a job, right? That's the whole point. So owning the outcome, it means, going through all of the planning, implementation, feedback, deployment, monitoring, and communication. taking something from nothing to the very end of it being a successful product or feature.
And [00:45:00] that is... There's a lot there. it's not just like, "Hey, I'm buil- I built this two-factor authentication system, and I deployed it." That's part of it. But what you wanna do is, like, as you're building it, you wanna ask, you wanna check, you know, your competitors, make sure that you're building it in the same way or you're building it better.
Then you wanna check with the end users after you've built it to see if they've actually been using it. You know, you wanna add, add hooks in there for, like, analytics to see if it's blocking anyone, right? Like, this is the kind of thinking that you have to have when you're outcome-oriented.
If you're building a 2FA system, is it actually lowering your sales? Well, you have to make sure that it's not. So that's part of the process. The outcome of a 2FA system is better security, but it should not be lower sales, for example. you can do, think of a million examples in that space, but it's not, it's not a simple straightforward answer.
And so that's what I'm talking about, of going from start to finish on a prod- on a feature or a product and owning the, the result. If it's bad, if it's a bad result, how do you fix [00:46:00] it? There, there's a lot there
Matt: Well, you could also say that you're the most qualified to fix it because you, you were there start to finish, so you would, you would
Mikhail: Exactly
Matt: what to do. I mean, I, I have a, a story from a, uh, and it ended up being a feature that we did implement, but I, I have a story from a client who was just absolutely adamant that we added a chatbot to their website, I was like, "Okay."
And this was, like, before all this LLM stuff. This is years ago. So the most you had was, like Basically a, a tree for, for the bot. So if you had a bot in the, in the chat, in the little chat pop-up, there'd be like a little tree where it's like, "Hi there," like, "What do you wanna do today?" And there'd be like, you know, three little, like, selections.
You select one, then it goes down a tree of "Oh, they selected this, so now show them this, or they selected this, now show them this," and that type of thing. Or it could be manned. Somebody could be there and actually be running the chat. Or it could be kind of like an answering system. and many places still use this one, where someone sends a text and it, it kinda [00:47:00] like goes into their ticketing system, and then
Mikhail: Угу
Matt: you back later, right?
They send you an email back later, or they, or a text later or whatever it is you've signed up for. And that works fine. Like that, that, that makes sense 'cause, you know, you texted a friend, you don't necessarily res- expect a r- a, a text right back an- anyway. So it's kind of a similar system to that. But this person just like really wanted this thing to be like super active.
They didn't want the tree. They wanted, like, someone running it. I said, "Okay, yes, that's fine. But, someone there has to run it. you understand that, like I'm not a professional in your industry. there's no way..." said I could, I could technically go and like try to recruit someone in your industry, but this is now, this is a little absurd.
Like, I'm not a recruitment agency. This is not my job. I was like, "I'll help you. Like, I'll help you do it." are our early days, so I was kinda like jumping through a lot of hoops for people. And, the whole point is we got all the way through to, "Okay, your, your team is now set up. Your team is now set up, and they will, they will do it." And then they said, "Well, no one actually wants to r- run the bot," 'cause I got everything working from a technical perspective. "No one actually wants to run the bot. Just this one person said they will do it." [00:48:00] So then I contact the person, I say, "What's your schedule? I need to have like a schedule on here." Person goes, "I don't have a schedule. I'm not, I'm not, I'm not being like beholden to a bot." Uh, okay. So then I gotta go to the, the, gotta go, you know, up a level of administration, talk to them, and they're like, "Well, I can't tell him what to do. Like, he has his own schedule for good reasons." Okay. Can someone please help...
Like, can someone please agree with me that this is not the way to do this? And finally we have, finally it came to the conclusion that this is a complete failure. Now, the, the p- the point, the point of the matter is, is like I went through the testing, I went through the implementation, and like we hadn't gone live. We were in the, at the staging stage. So we were like ready to go. And the whole thing is, is like unfortunately w- at the, at the end, they kind of asked me, "What's the, you know, what, what's the outcome here?" I said, "You..." Again, 'cause I've owned the whole situation. These are our options. Someone mans it, it's a, it's a voicemail, a voicemail equivalent, or it's a, it's like a very simple tree robot, and that's it. Because I've already owned it. I didn't come in at the end and not [00:49:00] understand the options and not understand what had been set up. And then I was able to de- decommission it quickly So, like what you're saying, Mike, is where even if the outcome is bad, I have, know, all the options. Or I shouldn't say I have all the options, but I'm the most qualified for this particular client trying to do this particular thing because I've been, you know, working with them for weeks on this particular thing.
So I'm the person where it's like I understand what feedback they're expecting, what they should expect, what I've already told them, what I should push, you know, what, which I should say yes to, no to, et cetera. and also, clients love it too when you actually watch something go live, and then if anything goes awry, you just sort of like fix it as well. So in this case, we fixed it by decommissioning it. Get it out of here. Clearly, this isn't gonna work. But we have also had things where I'm like, "I feel like this cache is gonna mess up when they press publish." Like, you know, just something stupid, but let me just watch it. So you, you know, you, you know they're gonna go live at nine AM.
Nine AM rolls around. You're like, "Oh, shoot, this thing's a little bit, little bit awry," and you just go fix it, and you just let them know, "Hey, man, this went awry. I just fixed it." And you get, like, great feedback, and that's because I own the [00:50:00] outcome. I was there for the development of said feature.
I went through a whole thing, and I knew about the cache and everything, and then when we did it, it was like, okay, there's a cache issue. Let me just go clear that, and then boom, there we go.
Mikhail: Yeah, these are exactly the type of examples, for owning the outcome. This is, this is what makes you referable as a business w- in an agency perspective, but internally in a company, it's also what makes you, promotable, keepable in a layoff, right? Like, if you're the engineer that owns the outcome versus the engineer that just finishes the ticket and moves on, who are they gonna keep?
I mean, unless it's a random layoff obviously, but, like, who are they gonna keep? Like, that's the, that's the reality. So again, it's one of those skills that it makes you transferable. It makes you transferable to product, it makes you transferable to promotion, it makes you transferable to not getting laid off, it makes you transferable to your own business, right?
Like, that- that's, that's the point. All these skills are like that. Any of these. Like, if you, if you combine them all, you're, you're a business owner. Congratulations,
Matt: Yeah,
Mikhail: Like, that's the whole point. Like, [00:51:00] yeah, but if you're a business owner, you have the mindset to be, you know, a, a very good employee as well
Matt: You can help the business owner. Like if you
Mikhail: Absolutely.
Matt: you can help the business owner
Mikhail: Yeah. You're in a different spot. And the, the, like, the reason I bring these skills up is I think that AI is gonna have trouble replacing any of these.
Matt: Yeah
Mikhail: it's still not very good at ideation. Like, it's gonna give very generic, middle-of-the-ground ideas that anyone can come up with. It's not very good at user empathy, it's just doing the ticket, end to end.
Now, you could give it the prompt to do user empathy, but you have to be the one that do- does that, right? you have to tell it what it, you mean by user empathy. Like, what is a succ- success metric, right? It's not good at sales like we talked about because people don't trust it. It can't tell you if something is good or not other than some empirical stuff.
You need to be the one that tells it. And it can own the outcome to a certain degree, but you need to be the one that prompts it and controls it to get it to the point where it can do all the loops to own all the [00:52:00] outcomes and to monitor and to communicate and all that. You need to set that up. So it's-- These skills are key in today's world with agents.
Key. Super key. And if you can master them all, like I said, I, I have not. Very clear. Be very clear. I've not mastered all, all of these. I'm middling at best for most of them, maybe slightly above average on some of them, low on others. Anyway, it's something I'm working on, and I think others can too
Matt: Yeah. I, I, I honestly, I think I'd agree with that. I mean, these are, these are good transferable skills to transfer you into potentially, positions that are adjacent what you're doing, talking to, like, software engineers. adjacent to what you're doing would make you a great employee at, like, a small business where you have to wear multiple hats and you can help in multiple areas, or help with, a frontier team.
If a team is, doing the experimentation even for a large team, for a large company, sometimes you're kinda like a small business inside of a large business, and so you could help with that kind of stuff. You can talk to a lot of points, [00:53:00] and y- probably you could transition to management if there's a management position up there as well, especially with the ideation and, you know, saying no and kinda taking ownership as well is a big management really.
So, I, I'm, I'm in agreement with Mike. I think that this is a, you know, a good skill set, but I'd love to hear from you, the audience out there, what other skills. I'm sure there's a bunch more skills that you think that you should learn. plumbing might be one of them. I'm sure someone's gonna come in there and say plumbing. We're gonna get, gonna get that piece of feedback. But what, what do you think, should be added, removed, modified from this list of skills that we've just listed out? And remember, I also have a... I'm gonna have a link to that Dylan Israel episode as well if you wanna hear that. that'll be in the show notes.
But, uh, I think it is time to end, um, unless you have anything else to add, Mike
Mikhail: No, that's it. I think, I think we're good to go. Roll her up
Matt: That is the end of the episode. Remember that we're on Patreon if you wanna support episodes like this via patreon.com/htmlallthethings. M- And many thanks to our $3 tier patrons, uh, Tim from the Web [00:54:00] Hacker on thewebhacker.com, Jason from Geek Life Radio via geekliferadio.com, Garrett Segall, Level Up Financial Planning via www.levelupfinancialplanning.com, Magnus from Yes Web via yesweb.sc, Syntaxify from the HTML All The Things Discord server, and Stacy Mosler from the website swoonworthydesigns.com. And we'd also like to give a shout-out to Michael Laraga, a contributing author on htmlallthethings.com. Michael is the author of Self-Taught: The X Generation blog at selftaughttxg.com. And remember that we have a discount if you wanna use our link. That's a Scrimba affiliate link. It gets you into Scrimba.
You can learn with their interactive media player code editor. Go and learn how to code, taking some courses. Up to 20% off Scrimba Pro. go and check that out. Link is in the RSS description. If you want a description on how the link works, it's in the show notes on htmlallthethings.com. Feel free to leave a comment or review in the platform you're listening to this on, and we are signing off