From Failure to AWS: What Actually Makes a Great Engineer

And it's like, yo, you're not even supposed to know that yet. And then he's just like it's it's like a walk in the park to a lot of these kids going to that school. And I wasn't prepared like that. Um so that was uh I guess, you know, the the lesson there is kinda like you have to be ready for the level of competition that you're you're about to take on.

Fa learning stuff on YouTube? I don't know. Do you would you recommend like if somebody's watching this, some young person, whatever, would you still tell them to go and get your C S degrees at? Especially with everything happening in the world, you'd be like, uh, maybe not. Or would you

Data structures and algorithms and operating system concepts, all these fundamentals. But at the job, they actually want me to know.NET and they want me to know, you know, or JavaSpring and then like the specific libraries React. AI just does that. You know now what w what your job is is to know the fundamentals. So I think college is gonna make a comeback if anything.

But at the end of the day it was the people who you know, they had communication skills, they could talk to whoever, they could uh I don't know. There was a lot of non technical skills that made good software engineers better. Hundred percent. I guess.

It's just a learning curve, man. So it's like you you're you're paying somebody to spend basically like two to three weeks looking at docs and just just ramping up on this language. Nobody wanted to do it. Nobody hired. And uh now it's just like you j if you just know the concepts of what you want, if you worked on a similar framework e even in a different language, Claude just spits out the code for you. So the ramp up is much faster

And as you you know, like as the hotel onboarded a new customer, they just interpolated the balance into the template manually, saved the HTML file, uploaded to an FTP server, and that's their website. It's just like seven hundred HTML files. So if you need to update a header.

we would write little scripts to update the header in all seven hundred HTML files. And we would no version control, nothing. So like I remember one time I clobbered a bunch of updates that another engineer was working on. J and what I was doing was updating the fab icon. So the most meaningless, most BS up that you can imagine. And I clobbered a bunch of like actually important work that this other engineer had done.

Uh but luckily, you know, he you have the files locally, so he just re-uploaded them again. Um so yeah, that that was my first job. Like things were not advanced back then.

I totally remember doing all that stuff. It's a I don't know. Sometimes I look back on it with I feel like I learned a lot at the time, you know, you learn how to get into a server, you learn about networks, you learn about IP addresses and security and I don't know, I feel like that's good stuff to have.

know if that world still exists today, right?'Cause everything is so abstracted every decade that goes by. It feels like more and more abstraction. But like you said, learning the fundamentals, doing stuff like that. I still think there's value in it for people to set up their own server to get inside it, understand how web server works, right? I think it positive, like you said, understanding that it just sets you apart from everybody else.

So actually thought in that job I thought that I didn't like software engineering. Bec but what I I made the mistake was for mature I I didn't

I couldn't tell the difference between not liking the profession and not liking the job. So actually went and got a master's in finance and as luck would have it, I graduated right at the moment of the two thousand eight financial crisis. So I couldn't get a job in finance, I couldn't make that transition. It ended up being for the best, you know, because I ended up coming back into tech and then

Next thing I did, like I when I did a freelance project, I was like, Oh my god, this is actually kinda cool. Like you're creating and just having that freedom to do things the way that I wanted and not be constrained by all of these limitations working with the super old technology that I didn't care to learn was uh was

a complete change of uh of perspective for me and that that's when I decided, oh my God, what am I doing? Trying to'cause you know, w after I after I got my degree in finance and I failed to get a job, I tried to start a financial advisory practice. It turns out that nobody wants to give their money to like a twenty seven year old that's broke, right?

a freelance gig, I was like, oh my God, this is awesome. And that's when I resolved, okay, this this needs to be my long term plan, but I couldn't find a job with that either because the the skills that I had were very haphazard. I did I hadn't built any kind of like real cohesive skill. And uh so I I got into this school as a network admin and uh teaching computer science.

And that's kinda like how I made a living for a while and then I got into leadership at a um for profit school from the from the high high school where I was a network admin. I got into leadership at a for prof for for profit school and I helped found their coding program. So I have designed the curriculum, I hired the instructors and whatever. So it was awesome. Got a lot of experience with leadership and operations.

and uh reporting and all of this stuff, like the the for profit school industry super highly regulated. So I got a lot of exposure to what it takes to be like a real leader, you know, like paperwork and type of stuff. And um

That pretense that you can learn the code in ten weeks if you just work hard enough is ridiculous. We used to say that, you know, um lear thinking that you can learn the code in eight weeks. by just spending more hours a day on it. It's like thinking that nine women can make a baby in a month. It just doesn't work. You know, it takes time to to establish the neural pathways. It takes time to to learn the concepts and

what we did was half ten curriculum. So you would only come in the afternoons, like five thirty to ten thirty. Uh, and then it will last nine months. So you would have a much longer period of time to to actually absorb the concepts and be able to to have them settle in and and build something meaningful by the end by yourself instead of just like copy pasting a bunch of boilerplate and restyle.

Absolutely. Getting frustrated, those are the times that you typically grow a lot when you stressed out, can't figure something out, you're staring at it all night, kind of thing. Usually the best way.

they it just become and and you feel that mental discomfort, they just disengage from it and then they think, Oh, this is not for me. It's having that growth mindset and that perseverance and stick to it and it's to just keep going with it and and Feel that discomfort and just keep going. It's okay. You're not gonna die from it, you know? So just like keep trying in tomorrow. Yeah. You know, and and the people who can do that. Guaranteed success. Yeah. Sooner or later.

I feel like maybe it's not true, but just the way software job jobs can be, especially in the beginning, you know, it's sort can be stressful depending on where you're working at. You feel like there's a lot of pressure, like definitely I see what you mean of Like you gotta love you gotta kinda like love what you're doing a little bit. I don't know.

A lot of them would come in, like our most successful students were people who come in from Latin America, especially Cuba. And because they're they had some kind of technical degree in math, electrical engineering, something like that. So they had the mental scaffolding for the analytical thing. But they were just stuck in a warehouse carrying boxes. Sure. That's kinda how it is when you're an immigrant.

And uh so they come to our program, we scale them with these things. So you had asked me about the technology. So we started with Angular and Node.js, and we finished with React and Node and MongoDB, and also we we also taught SQL. Uh we even taught data. in that in that program. And um after going through the program, they would find a job and I a lot of them, basically all of them, had this uh experience where They would come in and they would be given a task.

And it's a bigger task than they can handle. Because you're coming in, you're not building a little you're not building a little tooth full stack to do it. You know, you're coming into this big sprawling system that has a ton of tech debt. You have to like add Console log statements all over the place to even figure out what the heck is going on. And like you have to fix this, you know, by next week.

So, like literally, like I remember one of them was telling me the story and he was like cold sweat. And he said, But but I gotta do it. I gotta do it. I'm gonna do it. I'm either gonna do it or or I'm gonna or or I'm gonna run out signed by money and then they're gonna fire me. But I'm gonna I'm gonna spend every minute that I can on this. And he did it. You know, he kept the job and he got promoted like freaking four times over the next two years in the company.

So they would just basically have a machine learning algorithm in the background that with the human interviewers and the ratings that you gave gave to the interviewees on each question, they would use that into an input to a machine learning algorithm and then train it over time, follow the the career of the candidate and see you know which Interview questions were predictive of success at which company. So they would also even use that to pair. To pair the

The candidate with companies. Depending on where their strengths were, they would show them to companies where like, oh, this guy that's good at you know understanding async JavaScript, they're gonna love him at this company, type of thing. That's kind of like what the high level output was of the audience.

Um, so yeah, it was a great company. I learned a lot about interviewing there, learned a lot about hiring, learned a lot about what impresses companies. Um, and uh was there for like two years while consulting, while building apps. Um the Yeah, b building apps for mostly so mo most of my customers I found them through this platform called Top Town.

So you could command higher rates and and like you could like the the f the first meeting with a customer was like snap and you you got the deal. It's not like upwork where you have to be bidding, bidding, bidding, bidding. Uh four five thousand projects and people wanna pay twenty bucks for you to deploy their vibe coded garbage to AWS.

Um, so yeah, like I I was building software projects on the side mostly for very, very early type of companies and um like idea stage and working at Triple Byte. And then eventually some Amazon recruiter hit me up and I was like, Yeah, sure, like I'll I'll go, I'll interview and then I learned that they actually flew you there. So like they flew me, they paid for my hotel. So I got to visit a new city and then they inter and they pay for a whole And uh interview there.

Personality as it relates to work. So more like it it would be more accurate to characterize them as work style questions. So things like tell me about a time where you were wrong about a decision that you made and what happened. Tell me about a time where you disagreed with somebody about a decision that you made and if you wanted to do things one way, somebody else wanted to do it another way. And uh what happened?

So then if you y you give those examples like that and that shows a little bit about how you deal with disagreements and um whether you're the type of person that that Yeah, I told you so type of person or somebody who can actually just disagree with something and and Say, look, I don't have better evidence, let's just not fight. We can do it whatever way the the rest of the team wants.

Yeah, so if you're a difficult person that it has to be your way even though it's like ten people thinking the same thing versus you, that would come out in the interview. So I think they have a good component of the Of the interview that measures that that's a good thing.

what they would might the word culture fit is so soft it can be it can be used the word culture fit can be used for pure evil, just saying, Hey, like we don't like this guy so let's let's fire him but I think if you use the word the term culture fit in in என்னைப் பாரித்திருமைத்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்திருந்

in a good way, let's say, then they do a good job of measuring that. And so there were there's like one system design interview, three coding interviews, um And Yeah, just two two more interviews that no, it's one system that's an interview, but four coding interviews, and one interview that's just just leadership for. So in the coding interviews you do one that's straight lead code, straight DSA, one that's more like job specific.

Um so like the pe like they want you to know a little bit about the type of thing that you're gonna be building. So if you're a front engineer, for example, they'll give you like, hey, design a React component that does this. And then one that's more about code quality. So they ask you this like the the exercise is always very complex in terms of

You have warehouses and warehouses have packages and packages have this. And how do you model that? How do you model that complexity? And basically what they're looking for there, do you come up with classes that actually make sense and that actually encapsulate the domain model? It's a it's it's almost like a domain-driven designer.

They're they're asking you to domain model uh to model the domain that they're giving you and then write a little simple function that does something within that domain. But the the tricky part is modeling the domain and and Grokking it and asking all the questions that you need to ask and coming up with something that actually makes sense within thir thirty minutes that they give.

Um how is a good question. I don't know. I don't know.

Because I just don't type that much of it in my hand. You know, so like what's that gonna mean in ten more years when everybody in the market is like that? So and and what what used to happen in my opinion, like coding fluence. was a very good signal. It's not sure it's it's like a it's it's a correlating signal to skill.

You know, so it doesn't mean that you because you can wrangle syntax fast that you're actually gonna be a good engineer, but typically the opposite is the case. Like good engineers wrangle syntax fast. And so it was a very good processing signal and that signal is So I think that the interview process is definitely gonna have to change. I don't know how. It's a thing that I've been trying to think about and and and trying to entertain. I think that the the domain model in question

is gonna become much more important. And then just watching candidates giving them a problem domain and watching how they model it because that's what what you would need to give to an AI in order to get AI to not give you a piece of garbage back. It's like give it a good domain model, define good interfaces, define good module boundaries.

And all day I can cook. But before that, if you just give it like a high level, hey, you just give it the problem statement and have a warehouse and this and that, like it's gonna give you a pile of trash. Yeah. So yeah, I think that that's gonna be the new linchpin of the interview problem.

You know, again, it's might amplify some of your not best decisions you would make or you're not gonna notice when something's a little off, right? Or like you said, it's doing something that's nah and I don't know, I feel like again, yeah, it's more of like like you said, systems design will be super important, architecture, like that sort of being able to understand the system at a whole and know if that a uh agent's going down the right plan and I think even watching

Even watching what some prompt somebody uses, right? If you have an interview exercise and just seeing what the how they're interacting with A, what questions, what they're stating. It's gonna give a the view into like how they view the system and what they think the problem is and yeah, it'll probably end up being something like that. Um yeah, but it's a weird world. Who knows? Are you generally

pessimistic or optimistic about the future of software? And I mean that in multiple ways. Like is there gonna be more of us in the future? Less? Hard to say.

Um, from my point of view it's just another innovation, you know, it's the it's always whether it doesn't matter what industry and there's always innovation, things change. It's and typically with innovation comes yeah, things change, but typically they change in a good way and they're you know, I don't I just feel like there's gonna be more innovation with AI, whether that's more products being made or whatever, so I think

I don't know. Yeah, I feel like all the layoffs and stuff are sorta just kind of like it was just timing. I don't know if that's a hundred Do I know? But feels like a lot of timing, right, with the world, unstability, wars, things, companies looking for an excuse to lay off people, which is fine as a business and blame AI, I don't know. I mean I'm sure there's some truth to it, but yeah, I feel like in the future I think people should still go into software and I think it's a great a great uh

place to be, place to go to for young people. I know it could probably be scary just because of the online echo chamber and I don't know, you do at the same time there's a lot of People looking for jobs that are struggling, but I don't know what to say. Hopefully they'll find it.

With wars, with economic uncertainty, with just like weird shifts in American politics. and just yeah, that that all compounded into

a much worse job market. But I think the biggest factor there, and this is, you know, some an opinion that I read that I heard from a YouTuber. I forgot. And I think that the biggest factor there that's lining up with it. is that companies feel these big AI leading companies feel like they have to compete on capital. Because they fear they have this massive fear of being left behind. So they actually companies that used to be super, super cash rich are basically cash flow negative.

And they're just investing so much into building data centers and they're firing employees just as a way to free up cash. And that th they do that because they think that this is once in a world history type of event. Sure. The AI revolution and they wanna be at the forefront. So they're betting the farm on it and that just

tears up the job market even more. So I think it's a com just a a tremendous amount of factors colliding together to create a historically uh a very bizarre mismatch between the potential of the profession and the actuality of the job market at present.

He still hasn't he hasn't installed a single AI tool. He refuses. He's old school. He's just like he's like the blacksmith man. He's like I'm gonna hammer out this metal with my own two fingers.

And then you've got people on the other side who are like, I'm running gas town, man, I don't I don't do nothing. I don't even do my own PRs anymore and I feel like I feel like it's sort of there is this like I don't know if you see it online or I mean it depends who's noisy on LinkedIn or whatever, but do you see that in places like AWS is there's still people who the old school is like, I'm not I love my code as a craft, I'm writing it.

I'm not gonna use any tools and then you've got the people that I don't want to write my own PR and I I feel like I'm in the middle. So like I use my own head, but I also use Claude every day. I don't know. Where would you put yourself at and do you kind of see that as well around you, people on all ends of the spectrum?

We're all roughly the same in the middle. Nobody's gas downing. Sure. There's not a chance. Like the only thing that you're gas downing is like some like I'll give you an example. An internal tool, right? So like we have these um We have a distributed throttling system that for any any service team has a bunch of APIs, right? And you sign up for this throttling system and then you can control, hey, look, each

AWS accountant can call this API under whatever rate. So we have this attributing withdrawal system, which is how every API rate controls the calls that are committed to a particular operation. the rules, the way that you interact with a distributed traveling system is this massive dump of J

So like writing that is tedious. So we created a CLI tool that spits that JSON out for you based on like you you just basically write a little command, hey look add a throttle rule to allow create policy store and 30 TPS for account ID blocks And in regions data da. And so they just write a we have a little command line arc syntax for that. And it'll do it'll go and translate that to the JSON that it needs to be in a bunch of JSON files because we have one JSON file per read.

You know, so that's like a ton of JSON files that you have to modify sometimes. Doing it by hand is super tedious and it would be a freaking nightmare. We vibe coded that tool. Barely looked at the code um and then the tool does the job, that's good. But like a system that is actually gonna be serving people, nobody gas down that. You know, and and there's I to m I have yet to see a single person that's like

Oh, I'm gonna call it with my own two fingers because it's just it's just too good. Like once you like if you actually give it a chance, like if you copy pasting from a browser window.

then it's garbage. But if you actually give it a chance, if you actually install a coding agent and you actually invest a couple of hours into learning how to enable the coding agent to correct itself and tell it, Hey, look, you're gonna have to compile the code, you're gonna write a test first, like the things that basic stuff that you need to do to get it to work decently.

It's just too good. And the fact that you can leave it spinning, walk away and leave it spinning and come back tomorrow with a day of work advanced. Half the time you have to throw the day of work away, but like the other half, you have an extra day of work, you know, that you did that it did it overnight. So it's just too good to pass up, you know.

start from the project from scratch and maybe a whole new feature and it's like most of my time is spent like systems, it's spent in like the tariff one repo, getting infrastructure figured out, thinking about flows. containers, things like that. Um And less about like the actual fun you know.

I spend less time on like like you said, like the actual code is spit out to do this certain little Python thing or this endpoint. It's like that problem has been solved ten thousand times. Of course Claude can do that in a second, so I don't spend a whole lot of time on that. But um s I've been

building certain like tools that use L LLMs inside them where L you know like AI workflows everybody calls them now. What I've noticed is that it's sort of for me as someone who's always been on the back end, it's kind of dragged me, it's dragging me into different parts of the stack that I wouldn't have worked on before. Like it's dragging me into networking more. It's dragging me in closer to the front end, if that makes sense. And I feel like that seems to be

Sort of the f like, who knows whether it'll be true. It seems like the future is more full stack in a sense, where like there's less of a There's less of a th like a defined line to me now between the front end and back end like it was in the past. It was always one or the other it seemed like. Whereas now people are need to be more full stack in that sense because

I don't know, Claude is spitting out your little widget and so your time is more probably spent on infra and you're getting and that means you're probably getting closer to the front end and that integration between the front and back end. I don't know if you've seen the same sort of thing.

next level full stackers to just pull in the components and it does things right. Um, so I think you can create front end abstractions that make it almost foolproof for Claude to not get a hit. You know, so I think that and that's gonna be the role of the front end developer. in the future working on those foundational libraries. So like inside AWS we have this one called Cloudscape. It's a very, very robust library. And like there's

Yeah, it's not that not that AWS is the most amazing UI in the world, right? But it it has a bunch of different flows and a bunch of different types of components that all you have to do is drop the component, pass it enough. Properties and then you're good, you know? And it's it's tough for a claw to mess it up. Yeah.

Doesn't know anything about anything and you give him all the groundwork, all the awful shit that you don't want to do, you know. So that that's what a junior engineer is, you know, like you give him the hey you have to fan out this config change. manually'cause we don't have a system for it to these, you know, two hundred regions. Like that that type of stuff. You know, we we

Probably a bad example. Maybe maybe for five years ago it was a decent example. Like these days there's like almost nothing that's not automated in AWS. But um but yeah, that type of stuff. You know, like oh you have to there's this campaign from SecOps where we have to add this little scanner to all our packages. So go and add it to the config files one by one. Like that type of stuff. And

The and very simple features. You know, we need to add a new page to the UI where user can users can crowd on this particular little entity and it's very well defined here, the mockups, go and do that. Um

I don't think that type of junior role is gonna exist anymore. I think the junior folks are gonna be more Product managers that can take care of little features. I that's my prediction. It could be totally wrong, predicting the future is a fool's error most of the time, but I'm not betting anything on it, so that's what I'm saying. So I think that the the junior role is not gonna be somebody who does coding grunt work anymore because the AI is just so good at that, but somebody who

comes with a little bit more of a product mindset and can just implement simple features and and find simple things to do by themselves. So it's not gonna be about coding simple things, but about like adding simple enhancements to the product and adding polish to the product. So like people who come with a more product mindset are gonna be Yeah, I think that potentially

People even from from a product management background are gonna have a good time. So like that that that would be an interesting thing to see. Like people more from a product management background filling in the role of junior engineers and just making sure that They they have this thing that they need to implement. They're driving the feature and they're using the seniors and staff level engineers to validate that they're not destroying the system as they introduce the the change.

Um, so that could be a potentially interesting shift that I'm already seeing, like the PM of my team has already cloud-coded like a whole lot of stuff. You know, like this is a guy that, bro, like. and make fun of him on a podcast, but like to make a little fun of him on a podcast, he still uses SharePoint, dude he's sending word files back and forth. So like it's not uh you know, he's uh he's he works in AWS so he's a tech forward

type of guy, but he's not I would have not imagined that. And I'm seeing this guy bust out apps with cloud cloud code like it's nothing. And it's it's yeah, it's cool how people are adapting, I think.

You know, they wanna do something like I would have done it five years ago maybe or something. I don't know if you've seen the same sort of thing. I'm trying to I don't know if you see any of like sort of shortfalls. I mean that feels like that's about the only I mean,'cause if you're if you know how to use clawed code well and you're using plan mode and you've got some skills and you take your time, it feels I feel like that's about the only

like, I don't know, maybe that'll be solved, but if you like the newness thing where have to like either give it the doc directly and say, No, look, you can actually do it this way. Have you seen it is there any have you run into any issues like that?

How can I minimize the amount of minutes that I need to spend to close this ticket? Just just concerned with the next ticket, right? With the next task. And strategic is how can I keep the business healthier and able to implement features?

This bug is happening because we're actually not modeling the data correctly and we're representing a state that's invalid by having these two optional properties that always have to be set or always have to be unset. We're allowing the data structure to represent invalid states. So let me just refactor that.

Right. And and not allow the data structure to represent invalid states anymore. And then that type of bug will be caught in compile time and go away forever in in this particular instance. So like they they just don't do that.

You know, and I don't think they ever will because they ne they don't reason, they just create next tokens. You know, so like in order for it to do that, you have to tell it to. Mm-hmm. And in order for you to ha to tell it to, you have to be in the code and read and and know what's going on in the code.

Making it past the lints and all of that stuff we can automate. Like you just walk away and save yourself an hour of work from that bug fix. You know, and and I think that's the the great utility of LLMs and I find I have the exact same experience.

How can someone listening to this or watch this and they're like, Well, I'm just I'm that guy that just gets the next year ticket and then just going through my that's my deal, that's my week, get the next one, I close them all. But I see I don't see I'm getting anywhere, but I'm doing twice as many gear tickets as everyone else. How can they change that and become a high impact engineer that gets promoted or gets seen?

Just a little quick background on Dynamo D V. Dynamo D V has this thing about partition. So like whatever the partition key is, you can only write a thousand Right, assuming all the items are small, you can write a thousand items per second to that partition. Right. So let's say that you modeled

All your customers' data would just be a customer account ID, which is a common mistake that they made in early days in many AWS teams. So all of the customers' data is not just the account ID is a partition. Right. So that customer might have hundreds of thousands of resources.

that need updating, many of them at the same time, and now you're bottlenecking them all into one partition. So that leads to what's known as the hot partition. And now nowadays Dynamo DV actually splits a partition key for you under the hood and It's nice with it, but it's still a design mistake to do things that way. So let's say that you see that and you recognize it. There's an you're on call one week, there's an operational incident.

The some some team caused a hot partition issue. It recovered immediately. So it's not a big deal yet. It's only happened once. But you see that and you look around corners and you recognize, oh my God, as we keep growing, this is going to cause a huge problem for the team. So let me create a design doc about how we could repartition the table and looking at our access patterns, go look at metrics, create a detailed design of how it needs to work.

And then put that in your manager's hands and propose and advocate for that to actually get done. So that's the type of thing that an engineer with impact actually does. It's not about doing the tickets the fastest, so that's a huge common misconception. Doing more tickets than everybody. It's not

That's not how you how you really really drive impact. And uh certainly the other big misconception, the other big mistake that people make here is collecting technologies like Pokemon. You know, like it's not it's not j just because you add more and more stuff to the stack.

that you know you you bring in, oh, we have workflows, so let's bring in Zookeeper for distributed locking and bring in this and bringing that and and no, that's not that you're actually creating tech debt. You're actually doing the opposite. You're having negative When when when you do that in the long term, teams tend to see those things and they tend to abandon a lot of those tools and they tend to just

go back to boring technology. They they they go from having four different data stores to just consolidating into one. Uh once they go through that maturity curve and realize what the heck did we do here? What mess did we create? Um, so yeah, I think that that's the main way to have impact, being the one to steer the team towards better decisions.

What do they care about? What do they like listen to what they're talking about, the problems that they have and yeah, just definitely seeing it more than like a just a jer ticket to jeretick it for sure. Do you think that um

I was just reading some of your LinkedIn posts recently. Do you have you started learning, do you think people just every engineer should start learning what a reg is, what a vector D B is? Um this is kinda related to the whole AI question. Do you think that based on where the future could go that people need to Does everyone need to understand what a reg is and how it works, a vector database, how you know what an LLM model actually is, the weights, how to do you think that's

the new fundamentals that people need to understand, or do you think that's still do you think an abstraction will stay enough away where people don't necessarily need to or do you think it'd make you more valuable? I'm curious if you've done some of that stuff, are you kinda like, eh

Somebody working on the Chrome team knows more about those topics than I'll ever know in my whole life. You know? Um I think that what the safest bet on is you're gonna be in uh A really specialized if you're going to a really specialized ni niche, the the the best

most broad job market is when you're well rounded. And I do think that understanding L and understanding RAG and some of the ways you can use L and within production systems, not just as a code assistant, but that's gonna become a part of the basic skill set that's required for software engineering.

job market and their job and they're new to all this. Um do you have any pieces of advice you would give them, leave them with for whether they're new and they haven't they're in college coming out or they're maybe one or two years in their job and they're thinking, Oh man, do I need to go be a plumber or something?

I would give myself the advice of just, you know, lean into it a little sooner and find a way to stick to with things. A lot of people c make the mistake of getting too focused on what they should be learning. Instead of just doing stuff that's fun. There's plenty in software engineering that's fun. When I actually got back into engineering and how I prepared for teaching computer science and stuff, was I just did a bunch of game tutorials. So I built a bunch of games.

You know, and I I had incredible blast, you know. Um after having been, you know, with the financial practice for several months. I was rusty. So that's what I did to get back into it. And I wish I would have done that sooner. There's so such an important The amount of material is that that's available to each of us is indisc indistinguishable from infinite.

You know, it's not actually infinite, but it's from the amount from the perspective of the amount of time you have it's essentially infinite. And you can just pick and choose and do something that actually interests you and you pick up skills from that. Don't obsess over doing what you should learn, what you should be learning, because then you're not gonna actually enjoy it. You're not gonna stick with it in the long term.

Have fun. Have fun. Stick with it. And you will compound skills little by little over time. And before you know it, you'll be able to produce value at it at many different