Join John Peebles from Administrate on how to become a 10x Engineer.
← All talks
Build Engineering Turing Fest 2023
10X Engineers are Real. Here's how to become one
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Thank you. It's always nice when we can get together and relax and let our hair down, you know. And I've told that joke probably ten, twelve times all around the world. Actually it was the most recent time about three or four years ago and I told that joke and afterwards somebody came up and they said and nobody laughs every time just like today and this guy came up and said, You know, was that a joke what you said?
And I said, yeah, it's a joke. And he said, well, I don't really understand it because your hair's up. And I said, that was the joke. And he goes, okay, thanks. And he just left. So I've got two goals today on this talk.
Alright? And that is the first one is to convince you that 10x developers are real. Alright? And the second goal of mine is to kind of illustrate maybe a path towards how you could become a 10x engineer or 10x developer. I'm gonna use that term interchangeably today.
And I was really excited about this talk and so I went to a friend and said, Hey, I'm gonna talk about this and I think it's a great topic to discuss in the tech community. And this is their reaction, which is, Oh my god, you're going to get canceled.
Right? This is a super controversial topic actually and a lot of people just don't believe that a 10x developer or a 10x engineer exists. So I want to spend half the time this could be a totally you know, one hour, two hour talk on do they actually exist and how do we measure it and all this stuff.
And then it could also be a completely other, you know, two hour talk on how to become a great engineer. But I'm gonna smash them together, we're gonna hopefully go at warp speed and and finish on time. So what is a 10x developer? Where did this term come from?
How many people have heard of this term? A couple a lot. Okay. Well, this originally came from the eighties, right? Where all good things come from, like us millennials, right? And it was this book called PeopleWear. I don't know if anybody has read this book, but this is a seminal book for how to build software and how to build productive software producing teams.
And it came out of this book where they did research on what they called coding war games. And they had a bunch of engineers from a bunch of different places do a bunch of different problem solving exercises, and they came out and they said, here's the results.
Right? And that was that the best outperformed the worst by a ratio of ten to one. Okay? And this was like controlling for things like defects and making sure that the code, you know, is working and so forth. So the best outperformed the worst by ten to one and the best also outperformed the median by two point five to one.
Alright, so this is multi year study, very scientific and it was published in this book. This is one way to think about the 10x engineer and what they can accomplish but another way to think of it is and one I probably prefer is that 10x developers can effortlessly solve problems that median developers will never be able to solve given infinite amount of time.
Okay? Now that is kind of a bold statement to make, and the reality is when you hear things like this, Oh wow, ten to one productivity, and they can effortlessly do things that other people can't, you kind of think of this, right? There's this mythical creature, right, which also happens to be the, animal patron animal of Scotland.
It's a unicorn, right, that doesn't exist. And so I think there's been a lot of kind of folks talking about how this isn't really a thing and people who talk about this or you know it's not inclusive and all this stuff and and so I want to dive into this a little bit more.
But first a little bit about me as Hilda said I work for a company called administrate. We have platform, enterprise training infrastructure. We solve some of the biggest brands in the world. But it's important to remember, I'm just a guy talking. I do have a computer science degree, but I earned it a very long time ago.
I haven't programmed for money for about fifteen plus years although I like to dabble in it. I was given a technical talk about ten years ago or seven or eight years ago and I said you know hi I'm the CEO of this company and somebody in the audience just went boo.
And I was like, What? And it's like, Yeah, boo. And I'm like, Matt? It was my colleague, right? And I just thought that was really strange. So you know, I get it, right? We're engineers and we're skeptical of people who are not engineers or at least not doing it full time.
But back to this problem of the 10x engineer right? There are two reasons I believe for skepticism and why there's been increased skepticism over the last thirty years when we talk about this subject. Right? And the first is that we confuse this concept of talent distribution.
We misunderstand the talent distribution model for our industry. Okay. Now what what the hell does that mean? Well, Nadia already wrote this blog post that does a much better job than I will do today going through this in detail to describe what this means, but I'm gonna summarize it.
And that is there are three different distribution models for talent. Okay? You have the normal on the left, the Pareto, and the bimodal. Alright? And on the normal distribution model, this is kind of what we expect. It's a bell curve. Right? There are people on all different spectrums of skill set.
And, you know, the idea here is you hire a bunch of people and you train them, train them, train them. And these are the kinds of companies that administrate loves because they do tons of training. They hire everybody. And even if you know what you're doing at manufacturer A, if you leave your job and go to manufacturer B, you're gonna be somewhere on this talent spectrum.
They're have to retrain you. And so our software is great for that. And so this normal distribution model is what most of us intuitively kind of understand about the world and how talent is kind of spread around. And the solution to this is lots and lots of training.
You can get great results. And you see logistics companies, manufacturing, construction, that type of thing. This is what you'd expect. But then you have the Pareto model, which is there's a there's a cluster of people that are really highly talented and you kind of find companies that are like management consulting firms, investment banks.
Are there any VCs in the audience? VCs, like, only hire from the best universities, and then within the best universities, they only hire the top ten percent of the class. Right? And this is their business model. They want the best and the brightest, and then they put them in training programs and and whatever, and that's the Pareto distribution model.
And then there's bimodal, which is what software engineering is and how talent is distributed there. And that is there are these clusters of people that are referred to as linchpins, right, which are very, very good at something that very few people can actually do.
Alright? Now, it could be a bunch of different things. There's a lot of aspects of software engineering, and everybody is good at something, something I've learned. But these linchpins exist. And for a long time in our industry, in order to get a software company off the ground, you had to find these linchpins because they're the ones that could really propel you through that innovation, you know, gap that you needed to clear in order to to deliver a product or whatnot, and and they're really, really important.
And, actually, if we go back to this talent distribution model, over the last thirty years, if you rewind thirty years ago and some of my programming heroes like John Carmack and the guys that did Doom and Quake and I'm probably really dating myself right now, but these were very small teams of people that had outsized impact on the industry.
Right? And now, Grand Theft Auto, the next one's going come out. There's been like a thousand people working on that for like nine years. And so actually, a lot of the software engineering, a lot of the companies and so forth today look a lot more like the left hand side.
Right? Because we've got thousands of people working at these companies where thirty years ago you just had a few and it's gotten a lot easier right because we can use the cloud and we don't have to build everything from scratch, don't have to code an assembly and all that kind of stuff.
Alright But these linchpins used to be really critical for success in software, and so as the industry has kind of developed and it has become more people in the industry, it's probably been something that's a little bit less important. But I would recommend if you're starting out on a start up, try to find your technical linchpin, and there'll be other linchpins in other areas of the company as well.
Try to find those people because they'll be very, very good at something that very few people can do. And the second reason I think that there's skepticism about this ten x engineer idea is that many of us have never actually experienced one face to face or worked with one.
And that's another bold statement. Right? But it reminds me of one of my favorite essays of all time, which is here written in two thousand four. And it's ironic because, you know, I've worked for ten years at a company that really believes that education and training is like the magic silver bullet.
Right? Basically, this essay is you can't tell people anything. Right? And it goes through and it talks about how, we can sit in class and we can think, and you guys are all listening to me today and so forth. And the bottom line is until you've actually experienced something, you can't tell people anything.
We can you can say all you want, but until people actually experience something, it's very, very difficult to them for for them to truly understand. So this essay is great. And by the way, all of you YouTubers, all the links will be in the description below.
Another terrible joke. I'm actually gonna have a link at the end of this talk for a bunch of these resources. So if you're taking pictures or writing stuff down, and then we can fight about it on Twitter or, you know, at the bar afterwards, and it'll be great.
But this idea that you can't tell people that most of us have never experienced working with a ten x engineer, why is that? Well, it's because everything is worse and getting worser. Okay? Everything is getting worse. And if you've seen this crappy movie with Tom Hanks, he's a grumpy old man.
And that's I know what I sound like. Right? And you just get off my lawn. And this whole movie is basically him being grumpy, and there's some other candidate films that I could put up here, but we chose this one. And it reminds me of a text that I got about four or five years ago after talking with an engineer about their startup.
And I said, you know, it seems to me like you need this really key feature. And I said, yeah. And I said and I said, that's gonna be pretty difficult to build. And I said, yeah. But it'll be done in three weeks. And I was like, it's not gonna be done in three weeks.
Like, you know, where where are you? No chance of being done three weeks. And so and they went and talked to buddy of mine, Chris, who is the founder of Current Health, and he kinda had the same conclusion. And then they went to a third person to talk to him.
They sent this email and said, actually, John and Chris are a bit old fashioned for me as engineers. Right? And I knew this day would come that somebody would call me old and out of touch. I just thought I'd be in my forties and not my mid thirties.
You know when it happened. But it happened. Right? And actually, when you think about this idea of who's old in this industry and who's washed up and who doesn't know what they're talking about, this graph I found this actually blew my mind. In fact, I'm so happy that I did this research for this talk.
My own mind is blown, and I'm really I've gotten the value that I needed out of this talk already myself personally, which is I graduated you're not supposed to go too far over. I graduated right around there, okay, in two thousand four. Worst time ever to graduate with a degree in computer science, by the way, because it's a dot com bust, and nobody is hiring anybody.
And there's even a West Wing episode about how even though software engineers may still exist in some form in the future, they're all gonna be offshore to India and China and all this stuff, and they'll never come back to the US. It was a very depressing time.
But actually you look at that and it's so low on the curve. There was only like a couple million software engineers at the time when I graduated globally. And you can find different competing graphs like this and there's different statistics and we can debate about the details here and there.
By and large, this is pretty much everything I've found has upheld this graph, which is a hockey stick up to the right. Today, there's like twenty six million, twenty eight million, something like that, global software engineers, which is quite a change over the last twenty to thirty years.
And that means a few things, right, which is one in six have less than a year's experience in software. Alright? And one in three have less than two years, two in five have less than three years, and ultimately, half of all developers today have less than four years of experience.
Okay? This blew my ******* mind. Okay? Like, I knew this was true, and I knew everything was getting worse. But actually, like, you go online and you just see, like, all the stuff on Stack Overflow and it's just like junior engineer after junior junior engineer incorrecting each other on the Internet.
Right? And then it's gonna get even worse because we're gonna take all that **** and we're gonna feed it into AI and we're gonna have even more crappy code being generated by machines based on the stuff that, you know anyway, back to that grumpy old man picture.
Alright? Ultimately, I'm trying to convince you that ten x developers are rarer than ever. It's very difficult to find one and it's very very difficult to experience what it's like working with one. And I'm kind of reminded of this idea like for years I've obsessed over this idea like you know if I could somehow make my way onto an NBA court could I, like, even guard one of the players?
Right? Could I could I get a shot off? Would they just block everything? Know, it's like, what is the talent differential between professionals and, you know, maybe, you know, highly competent amateurs and then me in terms of basketball. Right? And actually for a long time, I just thought, you know, this is one of those things that is fun to think about.
You go to the pub and you talk and whatever and, like, you know, could could the best ever women's basketball team beat, you know, the the worst ever men's college basketball? They have all these debates and so on. And anyway, there's very it's very, very difficult to gauge that.
But there is one sport where you can actually measure yourself in identical conditions, on the identical course, with the identical equipment as professionals. Does anybody know what this would be? No. Maybe chess. Man, we're not going to take anything but my answer. Anyone else?
Golf. That's probably a good one. Yep. Okay. So there's many actually and you know, thank you for your participation. It's it's this cycling. Right? This is another one. Right? So these are these are professionals, and they're cycling up the courses, and you can go out and ride them today, and you can actually ride them virtually if you're on Zwift and you have a smart trainer and all this stuff.
And and it it's it's amazing. Right? Because you look on Strava, some of the pros will put on their their stuff on Strava, which is, like, you know, with wattage and all that stuff and the timing, and it is unbelievable when you compare yourself even as a very very like competent amateur against these folks right that are just blasting up the mountains.
Now they're doing drugs and so they've got a slight advantage but there's actually a documentary where an amateur was like well I'm gonna do drugs and you should totally watch that. It's called Icarus, I think, and it was really, really cool. Okay. So the idea is when you actually compare yourself against professionals that have been training and devoting their lives to this for a long, long time, it is actually mind blowing differential in terms of what they can do.
Same human bodies, same equipment, all that type of stuff. Yes. There's some talent here and there, but these folks have devoted their lives working towards this. And actually, you might be sitting here and you're like, oh, man. This is weird. Like, we're talking about these unicorns and everything's getting worse and there's no hope.
Whatever. Well, actually, I've got some, I think, good news for you, and that is none of this matters. Okay? None of this actually matters for your well-being or your future. And this was predicted thirty years ago in the same book with PeopleWear, which is there's actually a very weak relationship between being this incredible engineer and your financial compensation.
Right? And so, really, you know, I did all this stuff like finding, like, the Japanese code of Bushido and, like, craftsmanship, whatever. I can't convince you to be a craftsman or to devote your life like Hiro here dreaming of sushi. And the reason I can't convince you is because, actually, there's no real massive financial impact to this.
Right? You can become the best engineer ever, and you're not gonna make a whole lot more money. Right? You can totally have a nice highly paid career and do none of this stuff. Okay? So that's it. That's part of why I'm grumpy all the time.
But there is another way and I this is this is the second I have the talk which is I really want to kind of maybe get you to think if you're an engineer how you can really invest and get that reward and it's not gonna be financial necessarily into developing your craft and becoming something that not only is very fulfilling for yourself personally, but will bring your teams and the people you work with along and and just make life significantly better.
I've had the opportunity to work with three ten x developers. Okay? I've worked with some amazing engineers in my career. Guys that were like core Clojure contributors, like literally wrote the book, were were on my team for a while. Zuni were remember Squirrelmail is like on every distribution.
I know those two guys very, very well. Those are not ten x engineers. Okay? They were amazing engineers, but they didn't quite get to the level of what I've seen on these three guys that I worked with, which are ten x engineers. And one thing that I realized when I got exposed to working with them was that I was not a ten x developer.
And this actually was, like, kinda heartbreaking for me. I was, like, you know, middle of college, and, you know, you get exposed to, like, this superhero level ability where they're just going through tons of code and they model stuff intuitively and they had all this experience and stuff.
And I was like, this is just not me. Right? I don't have this level of talent. And it was kind of demoralizing in many ways. And I thought, you know, so I was thinking about this and it's like, you know, but I love computers and I love working in this industry and I love building stuff.
And so I thought, could I become one? Is there a way that I could kind of will myself or work myself into a ten x engineer posture? And the conventional wisdom is no. Right? This is not possible. Right? You either got it or you can't.
It's more demoralization today before lunch. But actually, I think that's a myopic way of viewing what engineering is. So a lot of times and maybe what we've all gravitated to naturally today is thinking that I'm talking about the coding aspects. Right? The idea of like, you know, I used to sit around in college and there'd be like five or six of us who were system administrators and we'd try to like, you know, out reg x each other.
What is the smallest piece of one lining one line code that we could do to, like, you know, fit some pattern? We are total dorks. Right? And, like, we just spend all our time underground and computers and and all this stuff. And and and that stuff, that leak code stuff is really cool, and I enjoy it.
But I'm not naturally gifted in that kind of arena. Right? But, actually, when you think about it, software engineers weigh more than just coding. So I got very interested in the idea that I would never be this brilliant coder that would just intuitively understand why these pointers are different from that, all this stuff.
It's just but I could devote a lot of time and work and effort towards becoming a better software engineer, how to write better bug free code that's easier to use and maintain, and how I could do it faster and faster and faster. And actually, the more that I observed working with these outstanding engineers, I learned that they were really good at the coding stuff, but they were also really, really, really good at problem solving.
And that's something that we can all learn and be trained to do very well. And this was actually another clue within this book, the same section in people wear, which was it actually mattered a whole lot who your pair mate was when you were doing these exercises.
So if you're if you're if you're the person you're paired with was really, really good, you became better. Right? And, you know, the more I thought about it, I really love this idea, which is the person you're gonna be next year is a product of the people you hang out with, the things you do, and the books you read.
And this is really my moment of hope. Alright? And like Pinocchio, I could become a real boy. Right? I could become a real ten x engineer. And so I thought about this a lot, and I was like, well, you know, I this if I've chosen this to become my career, well, this is this is something that I wanna invest in.
And, actually, this is not an easy road. Right? This is two two guys in a post apocalyptic thing with a shopping cart. It kinda looks like Leaf Walk where I live a little bit from time to time. But this is a hard road. Okay?
It's gonna take a lot of work, and it's gonna take a lot of effort if you wanna dig in and do this. And like we said, you don't have to do this. You probably can already most people here, you're already done something that a lot of engineers won't do, which is you decided to take twenty or thirty minutes out of your day and invest time in how to become a better engineer.
Most engineers read less than one book about the profession every year. So you can already most of us are probably standouts in here if we're into engineering at all because we've invested just a little bit of time. But what I'd like to try to inspire you to is invest the time and effort in order to form an opinion and judgment.
Okay? And so I've got basically a few ways to think about this. We can rifle through this and then we can start arguing afterwards and I'll look forward to that. Alright. So the first one is explore the machine. Alright. Master your environment. Solve many problems. Become your user. Alright?
These are the four things that I think will give you the leg up to being a 10x engineer. Explore the machine, master your environment, solve many problems, and become your user. So very quickly, a long list of stuff. And, again, I'll have these slides posted, so don't don't worry about it.
But when we talk about exploring the machine, really learn how the computer works. Today, it's very easy to get a job in the in the software industry to actually do, like, totally get paid for this, to go through a four year university degree and not actually understand how a machine works, how the machine works.
And I'm talking about hardware, understanding the different levels of abstraction, operating system principles. You need to really understand this stuff. You need to understand not only how it works, but why it works the way that it does. And operating systems in particular have gone through a bunch of different evolutions, and all of a sudden, what I'm talking about is when you sit down and somebody just talks about, you know, an operating system, you go, oh, the dining philosopher's problem.
Right? These are the things that people have had to grapple with as they're building up these abstractions to get to what we use today, which is the cloud or these massively abstracted things, and you'll learn a ton about how the computer works. Have strong command of your primary language.
A lot of engineers today, we don't actually know the intricacies of our language. We don't understand really the language in very in great detail. Instead, we're kind of hopping out to Stack Overflow or we're using GitHub Copilot to kinda suggest things, and we don't really, really spend time and invest the time to understand our primary language.
And kind of coupled with that, you also need a breadth of experience with other languages and other types of languages. Right? So compiled language is very, very important. Those are different from scripting languages. And then this one's a little bit controversial, but I believe that Lisp is kind of the programming language equivalent of LSD.
Right? It'll open your mind. It blew my mind when I was programming Lisp. I don't ever wanna do it again, but it's it's an amazing language, and going through a course in AI twenty, thirty years ago using a lot of Lisp variants was really, really interesting.
I wouldn't wanna program in it day to day, but the ways of thinking and kind of shoehorning your brain into solving these problems, it was instrumental in kind of just opening up whole new ways to think about problems. Deep experience with SQL and relational databases. Okay.
This one is like a bugbear of mine, but we are not talking Mongo. In fact, I used to get trolled by a friend about six or seven years ago and I'd be talking about something and they'd like, so what you're saying is use Mongo.
Right? And I would just like, every time, my blood pressure would spike, and that's probably why I'm on the road to diabetes. And, anyway, SQL, structured query language, and relational databases is so important, and a lot of engineers today have completely skipped this or ignored this or kind of, oh, we'll let the cloud deal with that or whatever, an ORM, and you need to understand how to model data, how to retrieve it, and to think and understand the concepts of relational algebra, which are embedded in SQL.
Broad appreciative broad appreciation of various data structures. This comes up time time again when you're trying to solve hard problems. You know, rewind ten fifteen years ago, it's like Ajax was the new thing in two thousand and six and, you know, Internet Explorer still ruled the world and all this stuff.
And we had a pharmacy database of drugs that we needed to be able to very quickly surface to user through a web interface. There's eighty five thousand drugs in this entry. Right? And, you know, today that would be a very slow search that would take, you know, tens of seconds to return, and yet we used a specific data structure called a CDB that was written by a guy who's written a bunch of stuff like tiny DNS, and we could get, like, literally lightning fast, I mean, to the second returns on this stuff.
Just understanding that different data structures can be out there to help you solve these problems can really, really give you a leg up, and that helped us a ton in launching our product to pharmacists who are really, really time conscious. Experience multiple operating systems, again, as a sizzleman and as a user.
Try running something different on your desktop for a year. You'll just you'll develop an opinion. You'll develop judgment on when it's good and when it's not. Alright. Moving on to mastering your environment. I'm gonna blitz through all this stuff. Like I said, I could talk for a long time, but really master your primary tool set.
And I'm talking like your IDE. If you're using a compiler, you know, understand like, get out the manual and read the manual on this stuff. Because incremental gains in your day to day workflow, and I'm talking even things like shortcut keys, hot keys, keyboard navigation, all that stuff, really, really add up.
Even for myself, like, my primary weapon of choice these days is email. Right? I got a new email client about six months ago, and it's all hotkey based. And it's unbelievable how much more productive I am just on email by knowing my application, understanding how to quickly navigate this stuff.
Don't use the mouse if you can avoid it. Speed and quality, you should be pursuing relentlessly, and it's that idea of, like, how can we do this safer, better, faster every single day? How do software is the most amazing thing in the world.
It's infinitely malleable medium. Right? You can build your tools to help you go faster, and you can invest in that stuff every day. And the last one is really, really important. Invest significant time in learning to read code. Now this is something I think really separates outstanding engineers.
Like, actually, we say reading code, we don't mean, like, you know, reading it out loud. It's like loading the program into your brain and tracing the execution through often with a debugger and say, okay. I think the next step, the variables will be this and so forth because of that, and then seeing if it's gonna work that way.
And that that stuff just really, really helps you along the way. And then solving many problems. Okay? Just get exposed to as many different types of problems as possible. And I like to think about this in terms of different development environments. So, you know, are we doing native mobile development or doing web development?
Are we doing desktop apps? You'll learn techniques and so forth on the various different ways that people are using your software that will really help you think through these problems. But I also like to think of it in terms of different industries, right, in different user types.
So B2C users are very, different in the things that they care about than B2B users. We have this debate a lot in the administrate. We're deploying to enterprise users. They have not bought our software. Somebody else did, an executive did. And, you know, all just the other day, I was talking with our designer and we had these tool tips where, like, you log in to this scheduler of ours and had all these tool tips all over the place popping up.
Great. Now let's do this. Right? Like we've all seen in b to c apps. Well, it's kinda like a pilot climbing to a cockpit of the new plane they've just purchased, and they're tool tipping them away through, like, everything. That's not how it works in an enterprise environment. Right?
You get trained on this software. You get rolled out, and and it's just a completely different pattern. Right? Mixing these and understanding when they're when they're important is is important. And then ultimately, disciplines. Like, I cannot tell you how valuable it is as an engineer to understand basic accounting principles.
Right? Because often, you'll be put in a situation where the ways of executing a program or going through the problem solution of a program will match up to accounting patterns and so forth, and you need to understand this language because you're gonna be building systems that accountants are gonna be using.
And finance is gonna be flowing through your your application, and it's really important to get that stuff right. Ultimately, though, becoming your user is the most important thing. And this last bit here, actually working the job for a week or two, that's the best possible thing that I could leave you with.
Hopefully, you remember one thing from today, it's understand the job that your user is doing better than they can do themselves and do the job. So I learned this firsthand about ten years ago, fifteen years ago, we were building software for pharmacists. I realized I just didn't understand how a pharmacist did their job.
So I actually called up a pharmacy, and I got hired. Well, they it was for free. But for two weeks, I worked in a pharmacy filling prescriptions. Right? I would do all the work, and then the pharmacist would double check me as I did.
And that meant that I could anticipate problems and issues and design stuff for these pharmacists that they would intuitively understand and like and it voided months and months of back and forth feedback with the users. So that's a lot of ****. Right? Yes, it is. Okay?
And we whirlwinded through that. But, if you could only choose one of these to really think about and devote time to, it's choose your users. Alright? Because that is where you will gain the biggest advantage in your career is you can really understand how your user works in the job that they do.
Another pro tip here, computer science doesn't actually change very much at all. So a lot of these concepts that we're talking about today, AI. Right? I got a degree in AI twenty years ago. And the thing is is, yeah, there's been some updates and so forth, but mostly it's just machines are faster and they can do more.
Right? So it doesn't actually the principles stay the same. You know, NoSQL, that was a big deal. It's very, very defined problem set that it that's people use. Same thing with blockchain. Right? There's, like, one use case maybe for blockchain. It's not gonna go and all of a sudden turn the world around.
And conventional wisdom is often wrong. Right? So we get excited about various tech. This is a text message I had with a buddy of mine. He says, do you remember when I told you wrong about microservices? I said, yeah. I remember it very clearly.
And he said, you're right about microservices. Right? They suck, and they're a bad idea. Okay. Reading plus learning. Doing is learning, so we can all sit here and watch and read whatever, but actually getting out there and doing is really important. Don't underestimate the power of incremental gains.
If you work on this every day, people always overestimate what they can get done in a year and underestimate what they can get done in a decade. Okay? Explore the machine, master your environment, solve many problems, become your user, and then you'll become ten times the developer for one point one times the salary.
Right? And that will be totally worth it. Thanks so much. This is a link to those resources and a whole bunch of other stuff and hope to talk to you afterwards. Thanks a lot.