Douglas and Tyler discuss the 10X Developer. Do they exist? Does everyone have to try to be one? We also discuss the 1X Developer

Links:

https://dl.acm.org/doi/10.1145/362851.362858
https://www.thesun.co.uk/news/3307245/the-knowledge-taxi-test-london-black-cab-drivers-exam/
https://muldoon.cloud/programming/2020/04/17/programming-rules-thumb.htm

Transcript:

Tyler S. Lemke: [00:00:00] Hey everybody. Welcome back to Junior to Senior Dev. I’m Tyler Lemke
Douglas Hirsh: [00:00:06] and I’m Douglas Hirsch. And today we are going to, huh, we’re going to
Tyler S. Lemke: [00:00:12] talk about something interesting.
Douglas Hirsh: [00:00:14] Yeah,
Tyler S. Lemke: [00:00:15] we always, he
Douglas Hirsh: [00:00:16] wouldn’t even let me give it a, this is great. I love this. We’re going to get these intros down at one point, but this should absolutely stay in the show. We’re looking to edit this out, but today we’re going to talk about the, the, the unicorn, or should we say the 10 X dev? Does this person.
Actually exist in what, what do we mean by that? So let’s, let’s kind of jump into this. Tyler, what do you think? What does a 10 X dev?
Tyler S. Lemke: [00:00:48] I think it’s interesting. So 10 X developer, I think of kind of the rockstar, rockstar, developer, you know, all those catchy name phrases like Ninja, you know, coding Ninja. basically I think of developers who are able to crank out code, very quickly and outperform their teammates, whether or not they actually produce 10 X. I it’s hard to, what type of metric you’re talking about is hard to control, but I think it’s someone that’s like noticeably much better than their peers at cranking out production code.
That would be a general definition.
Douglas Hirsh: [00:01:23] So the, I mean, seen other people throw around as the actual definition, they literally mean that this one dev would be, would be as effective as in devs on your team. And yeah. I don’t know. I don’t know.
Tyler S. Lemke: [00:01:42] I mean, it’s possible and I got some proof to back it up, but the, so there’s this, as you know, I’ve read code complete before, which I think is a really cool book.
Cause, you know, I’m, I’m, I like yourself are largely data driven. I like good data and inside a code complete, it says, it says an, a class, a classic study by sacrament Erickson and grant showed that productivity of individual programmers varied by a factor of 10 to 20, a to 20 during construction.
And that was a, a study in 1968. And then, numerous other studies from Curtis Millis, Curtis card, valet, Marco Lister. And Bowen, if you’ve, if you’ve read any, probably heard of bone before, cause he has quite a few different, articles, have all have all said that. So I think you, there are developers who are 10 or 20 X better than other developers.
Right. But it’s like, what are they? Are they 20 to 20 X better than the average developer? I don’t think so from this I have now I haven’t looked at these studies directly, but it said they can vary by a factor of 10. So the worst developer to the best developer could vary by a factor of 20. So you could have a 20 X, 10, 20 X developer.
That’s 20 times more, more productive than the worst developer. So that is a thing.
Douglas Hirsh: [00:03:06] So productivity is, is an interesting question, right? Are we literally only measuring? and, and we can’t measure lines of code, right? Because, well, we could, we could say, can they crank 10 times more code out than someone else?
But we know, we know that measuring lines of code does not necessarily measure productivity because someone could be extremely verbose and write very inefficient code and produce 10 times the amount of code. But then also. Produce a lot more time than other people have to go through that code and see what it is doing because they are produced so much code that may have been able to be produced in much.
Fewer lines of code. So it really this conversation, I don’t know if we’re going to come out of it with a definitive. This is, this is yes. The 10 X dev exists. No, the 10 next step doesn’t I do agree that there will be devs that are more productive, but it is, it is how. I don’t even know if it’s really easy to measure that, that productivity gain that you get between, between the devs at different talent levels.
And maybe, maybe, you have devs that are more talented and can get 10 times more information out of a project owner or product owner than the other dev. But then you have this other dev that can. Like 10 times faster, write some code up, you know, then, then other deaths. So even the fact that what is the measure?
What is a 10 X dev is something that perplexes me a little bit.
Tyler S. Lemke: [00:04:53] So let’s, let’s do another, let’s talk about a different way too. So let’s talk, I don’t know a ton about golf, but I know there’s, I think there’s, I’ve heard there’s like 20 million golf players in the U S. Right. And if you think of the, think of the upper echelon of golf players, right.
They’re much, much, much, much, much at the top. 1% is much, much, much better. So I think if we break things down, I think, I think clearly if you look at distributions on the, on the fringes, you’re going to have 10 X developers or more right. At specific things, they’re going to be 10 times. They’re going to write the code 10 times faster.
Right. And let’s look at it. Let’s, let’s look at it another way. Douglas. So the, the, if, if you were to compare yourself to a developer, that’s in, that’s your teaching in one of your boot camps, right? You’re probably at least 10 times faster than them writing code, if not magnitudes faster.
Douglas Hirsh: [00:05:50] Right? Well, the, the idea would be.
Can I visualize, right? Can, can I actually sit there and go, I need to do this task. I want to create a new application. Do I know exactly what to go do? Or am I going to have to go look those steps up and at the point where I can just go do it? I’m going to be a lot faster than someone that has to go look it up, which actually kind of, that’s another point you’d like to make a lot, which, which, when we had Jeff on the show, when we, when we get to hear, when everyone gets to hear the interview,
Tyler S. Lemke: [00:06:23] it’ll be there at all be out.
Cause we’re releasing that one. So,
Douglas Hirsh: [00:06:27] so this will Jeff’s interview will go out before yeah. Show, which is cool. So, you know, in the interview with Jeff, we talked about the fact that, that, you know, If, you know, if you have more in your head, you don’t have to actually stop and go and look things up. And that makes you that can make you a lot more efficient at completing a task where you’re trying to write some code out.
So yeah, your, to your, to your question. Absolutely. Much more efficient in starting it if an error occurs. So if something, if something occurs, I’ve also seen a lot more errors than they have. So it might not be writing a line of code, but where a student might sit on an error for two hours, I might come in and look at it and go, Oh yeah.
In one minute or 10 seconds. Oh, that error means that something’s wrong right in this method. Oh, That means you need to change this because that’s, it’s not going to work where it might take someone who hasn’t been doing it for as long, a couple of hours. So not only is there like output of code. But there’s also the, the idea of, of even just being able to fix or, you know, just even be able to understand what’s going on in the application
Tyler S. Lemke: [00:07:46] about vast amount of time for a lot of developers.
I mean, I know I spend a normal amount of time debugging, really silly things with environment issues.
Douglas Hirsh: [00:07:57] Right. And, and so I will say that, that, and this is, this is another thing from experience when I did. A couple of really complicated projects using test driven development. I spent very little time with the debugger.
I wrote tests and either those tests passed or failed, maybe sometimes if something really weird was going on, would I fire up an interactive debugger? But when I was writing code to exercise my code. It was, it was a much different thought process and no, I didn’t spend on those projects. I spent very little time sitting in a debugger because there was nothing coming from the outside in some of these unit tests that I was, I was working on
Tyler S. Lemke: [00:08:39] of debug.
I don’t mean just spending time in debugger. I mean, just fixing, you know, issues. In general, I’m using it as a more general term, like, cause I have like, I have an issue right now at work. that my company Peter is the only, is the only one that needs a special piece of that XML inside of the Bay configuration file.
Right. And I had to, I was working with our architect to try to figure this out and I ended up figuring out the problem cause I spent a lot more time on it, but I spent. in order to amount of time, uninstalling, visual studio, uninstalling, uninstalling, all that, these different things in the, in the doc Netspace to try to end reinstalling them, to try to get it working and.
the issue is still there. I have to, I have to actually replace this piece of code that I have. I always have to carry around with me from each, get each, each commit and make sure I don’t commit it if I want it to make it work. I can’t remember how to add it. Cause it’s been in a while, but I’ve added this piece of code back and it’s just silly things like that.
That can take an order amount of time. But I wanted to get back to your point about productivity, because I think you made an interesting point. What is productivity? Right? Because. I think you, can I be interested in dig into these articles more and see how they measured it? Because I imagine that use the, they use some type of metric because if you do, yeah.
After the fact, right? So if you do lines of code after the fact and developers don’t know they’re being measured, like that’s probably a better thing than saying, Oh, I’m going to measure how much lines of code you produced. Right. Cause that kind of starts to even it out, because if you’re not, if you’re not measuring it as a metric, right.
If you don’t tell them you’re measuring their lines of code, then it, th th that’s not in their minds that they’re going to measure it by
Douglas Hirsh: [00:10:18] it. Well, I want to say without. Without actually looking at the lines of code that a developer is writing, that you, you would, you would still have a problem there because you could have a less talented developer writing, more lines of code.
But if you’re only measuring lines of code, then. Then your really talented developer that can very concisely communicate to the computer to do something and mind you in a way that’s still a human readable. So there’s actually multiple variables here, is cool to be more talented than someone that even if you’re not telling them, you’re measuring lines of code has to write multiple lines of code for something that might, should only be one.
Or two lines of code and they’re like doing five. Well,
Tyler S. Lemke: [00:11:08] yeah. And that’s, there’s, there’s other debates about that too is cause I, I actually write so for my, if statements, one thing I loved from, from, from, code complete, for example, was, was the fact that, you can. If you’re, have you ever had a bunch of like oars or, or ans inside like a huge conditional that has like four or five ORs or ans inside of it?
You’re like, what does the same doing right. And that’s what I used to, I used to see quite a bit and I’ve started to break out every single piece of it. I break out into its own variable. So now it just reads if is this, and is that, and is that. Then it go into this, go into this method. So that produces more lines of code, but it’s much, much more readable,
Douglas Hirsh: [00:11:54] right?
Tyler S. Lemke: [00:11:54] In my opinion, like in the, and you know, you can debate about some things, but I don’t see how you could, like, you don’t have to think about it as you’re abstracting away the underlying detail and going. Is that, does this do what I want it to do, which is actually documentation,
Douglas Hirsh: [00:12:11] right? That’s where your, your code, your, what is it?
yeah, you know, uncle Bob has said that, that your code should read like good English prose and, you know, naming variables in ways that don’t lie. Right. You don’t want your want them to lie, but in essence, you could write code that reads like what it should, and what you’re describing is what you’re talking about.
So there is, there is bit of a, You know, balance between being super terse and going, Hey, I just wrote this thing on one line of code that really in your head, you would have to think very long and hard about what this one line of code really is doing, as opposed to having, having your code broken out into separate, like, especially your, your.
Your bullying logic that you’ve broken out and you’re doing all these ifs. Let me ask you something. Do you ever get any pushback on code reviews? As far as that’s concerned? I am curious if anyone has a problem with that.
Tyler S. Lemke: [00:13:11] I’ve only started doing it more recently, but I haven’t gotten any pushback on it so far.
I used to look at code that actually did that. Like, I was like, why did he, why does he, like, I was looking at this code base at one point and I was like, actually, that’s. That’s not bad to actually say what you’re, what you’re trying to return. Cause I know of another developer who would do the same thing for each return value and actually named that return value instead of just, you know, doing some complex statement, or return before it, I think that’s where, you have to value readability over terseness.
Right. Like you have to value, your code being much more readable. And part of that comes down to most developers don’t understand that your code is read nine to 10 times more than it’s than it’s written. Right. It’s read many, many, many, many, many more times than it took you to write it. Right. If you don’t count, right.
If you don’t count, you know, the actual mental, the mental, like, you know, effort, it takes to, you know, decide on patterns and, and implementation details and everything like that. But even then a lot of people, when you code go into a code base, you’re, it’s going to take a while for you to understand.
And any junior developer out there is pro is saying that same thing. Right? Cause that’s what I, that’s what happened when I was a junior dive, when I was actually an intern, I was like, You know, we need comments in this code base. I have no idea what’s going on here. Right? Cause, cause things, and whether that was my own lack of my own ignorance and, and, inability to study it, what could have been part of it.
But, I think code base is in communication. you have to, you have to speak to your lowest common denominator on your teams. Now, if you think everyone’s going to be a senior developer and they all have roughly the same experience, you might communicate differently. Then if you have a bunch of junior devs and that’s just like, if you were to write a book, right?
So going back to the writing analogy, if you’re going to write a book. Are you going to write it to teenagers that are in the adolescent and their youth, or are you going to write to, college students or to grad graduate students? Right. And so, and I think you’ve had this experience as well with even architectures.
I remember you said only one project you’ve worked on. It had so many, what it was microservice-based has 164 different repositories and. and it was very hard for you to understand. I could imagine if I tried to jump in it right now, I’d probably confuse. And then a brand new developer that’s coming out of your bootcamp would probably be very, very, very confused.
Douglas Hirsh: [00:15:40] Yeah. I, I was, I was the, when I walked away from there, I was like, they were really lucky that I was the one that walked in the door. Cause there’s not many people I know that would even have had the patients like they would have come in and looked at the code base and been like, I quit. It wouldn’t have even been like to be in it.
I enjoy stuff like that, but it was painful. It was actually very painful to piece together what was going on and even feel comfortable enough to make changes because of how spread out it was. This is one of those situations where, one day, if we ever want to get into it, like the difference between using multiple repos and motto repose.
that would be, or a single mono repo, to do stuff like this and get, would be an interesting conversation to have, because if we, it had a mono repo at that job, but all these projects, then at least I could have seen how everything connected together in this one on a repo. But that is not how it worked.
And so it was, it was a very painful setup. It was painful to maintain a, it was 146 repos to be exact, that number is seared into my brain forever because
Tyler S. Lemke: [00:16:55] 46. Yeah.
Douglas Hirsh: [00:16:58] Yeah. I mean, do you ever walk into a place with 146 repos? And you’re the only developer in the house? It’s it is, it is not a fun time, but it’s up to you, whether it’s success story or not, you know, most people, it wouldn’t be, I would say that most people would not have the wherewithal to stay in and, try to try to figure that out because there’s places you can go work that are much less cognitively heavy than having to try to work that problem out.
Tyler S. Lemke: [00:17:28] So productivity, what, what do you think are the, I’ve got some ideas for what, what, what productivity is, right? Because we’re, we’re still kind of figuring out what’s this 10 X mean? So what are the different, what are the different pieces of productivity? I think part of it could be. You know, very, a very, non granular metric is lines of code.
Right? I want to say that is some metric, whether how good it is is very debatable, but it’s something right? Because it tells you a little bit of something it’s not, it’s it doesn’t, it doesn’t hone in on whether or not they’re really good or not. But you know, if someone can crank out a million lines of code a year, another, person’s doing 10,000, the million lines of code.
Is probably more productivity, whether or not it’s great. It’s more work, right? Like overall, can we agree on
Douglas Hirsh: [00:18:18] more keys on the keyboard being put, right,
Tyler S. Lemke: [00:18:20] right. That’s what I’m saying. But I’m
Douglas Hirsh: [00:18:21] saying whether that code, whether that code is doing more than the 10 then than the 10,000 lines of code. That might be, that’s a, that’s a really interesting question, but the fact is that, that they, they, they typed out a million lines of code.
Now we don’t know how long those lines are. Like maybe they put their curly brace for the, if statement on the next line and that gave them an extra, a hundred thousand lines of code or something who knows. I mean, if you do have a million lines of code, who knows if that, if, how you do your curly braces after, You know, for your functions and if statements might actually affect how, and I’ve seen some styles where the curly brace goes on the next line, instead of on the same line, as, as your if statement.
So, I mean, just even simple things like, will you talk about a million lines? I go back to. What does the code do? Not necessarily, what did, how many lines of code that they write? And that’s where things get a little strange, because it’s really not. productivity it’s software development isn’t necessarily about writing the right code all the time.
It’s also avoiding writing the wrong code and, and writing stuff that, that, isn’t going to be needed. And cause, I mean, maybe they did specked out like a million lines of code, but only, only a 10,000 lines of that code ever sees, you know, is ever used. Even in that system with a million lines of code in it.
Yeah.
Tyler S. Lemke: [00:19:54] So that’s yeah, I think that’s a good point. So the. But it is some form of metric, right? So it’s some form of metric. Cause you get, you get to something else with the complexity as well. Right? Because actually code complete goes into different complexities. Like the diff it depends on, are you in the aerospace industry, right.
That’s going to be a completely different lines, the completely different type of code versus, you know, you know, spitting out web code. Right. And then, or, or doing, or what if you’re, you know, making lifesaving devices, right. You’re, you’re, there’s different, there’s, you know, there’s different requirements and there’s also, you know, you build things differently in those different environments.
At least I would think so. I
Douglas Hirsh: [00:20:38] think there’s different cultures too. Right? You may not even have the space to have a binary that is. Above a certain size or to use a certain, you know, you can’t use more than a certain amount of memory. So you’re going to have to write things differently to, to be able to, to handle the environment that you’re writing code in.
So, you know, that’s, that’s the thing. I think if, if I really wanted to throw like, like just a wide swath out there of stuff that, that, you know, what I would consider. Hey M. A 10 X developer would be, it’s gonna sound like there’s no, there’s no definite metric for me, but it would be the person that writes the right code knows when not to write code knows when not to even do a project.
That was how to argue against the fact that maybe this project is not something we should be doing and has that experience. you know, even, even to that point, And that means that that, no, it doesn’t look like they were very effective, but they basically stopped an entire development team for working three months on something that, that, that would have been absolutely useless.
So it, it, yeah, you really get off into to this, this, what is a productive. Member of a team and that comes down to what does a productive senior developer, what is a productive junior developer? What is a productive, mid level, you know, and that’s, I think it’s, I think that there’s so many different, what’s a productive art, software architect, you know what, cause I’ve, I’ve kind of had my finger in all those different areas.
And does that make me more productive? That I’ve been in those areas. If I look at a problem and go, yeah, we never want to go down that path. This is the path to go down. Here’s the exact code that we, you know, to, to solve this problem. But then like there were 17 other different possibilities that occurred.
But I narrowed down to the simplest one. I didn’t write 5,000 lines of this other code, but I wrote a hundred lines of this code that did that accomplish the end task. At hand, is it, is it about how fast can we maybe it’s about how fast we can create a solution for the person or for the, for the company or our manager or the product owner that they’re requesting a solution, you know?
And it conforms to what they think that solution, you know, what it conforms to. What they think it should be. Right. It actually does the thing that they ask for.
Tyler S. Lemke: [00:23:30] So I think, what do you think about special, especially because what comes to mind with what the Tenex developer is specialty? Cause we’ve talked about this before as well, like with, there’s a business idea where you basically.
use perfect something and you crank it out over and over and over again. Right? So you, you perfect. Perfect. It actually might be a piece of code, right? So you’ve actually written this piece of code once, and then you go and, you go and reuse that piece of code over and over and over again. So one example might be how about someone that uses Google maps, API.
Is there a developer that could be 10 X on that versus you or me and I haven’t used Google maps very often. I’m sure there’s developers who are 20, 30, 40 times faster than me, especially given the, a specific domain that uses esoteric API APIs. Right. So, I think if you think about specialty and you think about developers who are really good at one thing, we’re not used to having developers who are really good at one thing nowadays, everyone’s trying to go over to the full stack dev so they can kind of, kind of get milk you more for the money.
And it’s just, and you know, smaller teams need people who can do lots of different things. Well, I
Douglas Hirsh: [00:24:44] was gonna say that, that when you said milk you for more money, I’m I’m my, my mind is going to people who want to pay one developer per for what they would normally hire three people. So maybe, maybe give me 25% more since you’re going to only hire 33, you know, pay out 33% of the salary.
You know, that’s,
Tyler S. Lemke: [00:25:05] I’m not against it. I’m not against that business model either. Cause I don’t think they necessarily, like you might have to hire just as many developers, but now you have a more diverse team. So instead of hiring, you know, one front end person and one and two back end people, you might get three full stack devs, and then they can all work on everything.
Douglas Hirsh: [00:25:29] Yeah,
Tyler S. Lemke: [00:25:31] well, might be a much slower than that front end person, right. They might be, you know, half of them that thrown in person could be three times faster than them at doing, working in a framework.
Douglas Hirsh: [00:25:44] Right. So think about that for a minute. So someone that specializes on the front end, who loves CSS, who loves HTML, really has studied how to do semantic HTML properly so that they could just write in the first try.
They write out HTML that screen readers understand for instance, and they do their CSS in a way that looks beautiful to the eye. And, and they’re going to be the, that developer who does. You know, front end, HTML and CSS, and really knows both of those languages very well. And some JavaScript, maybe so pure front end.
They’re going to walk in and someone’s going to say, I need a front end that looks like this, and they’re going to go type, type type. And here’s here’s that. And maybe not even have to go Google as much or anything like that. but if you were to tell someone who specializes more in the backend, Oh, by the way, we need you to make the page look like this on the front end.
Well, you’re a person who specializes more in the backend who has that skill set is going to go, okay. They’ll do the back end. They’ll go to the front end and then they’ll sit there and Google and everything. And, and that’s not necessarily bad. I’m not saying that’s bad, but specialization will help in productivity because if you can narrow the number of things that you have to keep in mind all the time.
Then that reduces the cognitive load of doing your job. It lets you pick the tools that, that narrow set of tools to get the job done faster.
Tyler S. Lemke: [00:27:14] It goes down, it goes down to chunking. Right. Have you heard of it? The, the, the black, the black cat drivers in London? Have you heard of that? Yes. Yeah. So you’re familiar with, from all the different books we’ve listened to, right?
It’s an, every one of those books,

Do you want to relate it a little bit? Yeah, let’s talk, let’s talk about that. So maybe you can correct me, but from what I understand there, I think it’s a certain type of cavity. I forgot the exact, there’s a, there’s a, basically a test that they have to go through.
Sure. And I think on average people fell it like multiple times on average, before they get it, like, I think I’ve heard it’s up to you. I want to say 11 times, but that sounds, it sounds really high. do you, were you able to find which one it is
Douglas Hirsh: [00:27:57] like trying to look it up right now? Cause I know what you’re talking about.
There’s a lot of books that we listened to that talk about learning. And one of the things is that when, when one of these cab drivers and this is in, this is like in the UK,
Tyler S. Lemke: [00:28:13] it’s called the knowledge.
Douglas Hirsh: [00:28:16] And, and, but, but when they get their license, in fact, people have done studies on the brains of these cab drivers because they have to memorize.
They basically have to do what, what Google maps does for you. They have to, they have to come up with the best route to get from point a to point B and they have to do it all in their head and write down the route. I mean, there’s no Googling for them. They have to memorize, literally memorize the streets.
Tyler S. Lemke: [00:28:43] Yeah. So it’s today they have to study 320 routes, 25,000 streets and 20,000 landmarks, and then they have to memorize them all. And they’d done. Did you talk about the brain scans they’d done yet? So people’s
Douglas Hirsh: [00:28:55] brains actually. They changed scan the brains, right? They, they, they change too to be more geared toward a spatial.
spatial ability and, yeah. Right. They’re
Tyler S. Lemke: [00:29:06] not born with this either by the way. No, so, and there’s nothing they’ve done. They’ve done enough studies that show and you lose it. Once you stop doing, you lose it. And so that’s the same thing that happens. This goes back to why I liked the space repetition stuff is cause you don’t lose it.
Cause you’re going to actually go back and learn what, like remember it. But, the,
Douglas Hirsh: [00:29:26] by the way, it’s called a Hackney carriage is what type of cat is. Yeah. The Hackney carriage drivers are the ones that have to pass the test called the knowledge. And but like you said, you, you threw the stats out there about what they have to do, but it’s.
That’s an amazing feat, right? Basically become a human, a human GPS.
Tyler S. Lemke: [00:29:47] Right. And there’s there’s developers who don’t, who’ve done this. I’m thinking there’s this developer who has his own like video service where he he’s a Ruby developer. You might know who it is. I’ve tried searching for him. I couldn’t, because I come across so much different stuff online.
I’ve found him a long time, but he does TDD. And he types it like 120 words a minute while he codes. And he can think he can think that fast when he’s typing. and I’ve just read about what, how, how his videos are. I haven’t actually watched it. but I think people like that come to my mind and go, okay, there’s something different.
If you can type that quickly while you’re coding and you’re actually able to crank it out, that means that you’ve, you’re kind of like these taxi drivers. Right. For at least some things you can crank out code that quickly because all the APIs are in your head. Like you don’t have to think about, you know, the, the design patterns that are all chunked down and you, you you’ve optimized your brain in such a way that you can code potentially five or 10 times faster than.
The average developer. I think it’s definitely possible. I don’t think it’s common. Don’t get me wrong. I don’t think it’s common, but I think it’s definitely possible. And I think he’s one of the examples. That’s
Douglas Hirsh: [00:31:04] not common, but she would have to have so, so it would happen to be a narrow enough space, right?
You’d have to say maybe, maybe I’m going to be in dotnet or I’m going to be in Ruby. And these are my tools that I’m going to use to do the things that I need to do. And then you could actually create that kind of, that kind of internal GPS routing, like you were talking about, to, to be able to crank code out.
Now I do want to say something about. If it’s in a video and someone’s typing, if, if they are. Cause there’s ways to do videos where things look faster. And, and I mean, I, I don’t know. I’d have to actually see the person do it. And, cause I’ve watched people who’ve done these videos and they’re like, I’ll speed the video up to get the typing out of the way as quick as possible.
So I could talk about what I just typed on the, on the screen or two, they have the code sitting at another window next to them. So they’re just typing and talking at the same time, but literally transcribing code, not actually live coding per se, but, but. They’re they’re transcribing a bit of, of what’s going on, but I could see, and this is where I, what I do concede, right.
Is that, is that if you do have the, like, like the, the cab drivers, the Hackney carriage drivers, and yeah. In the UK, if they’ve got, if they’ve got all the streets in their head, it’s someone gets in the car and says, I need to go there. They don’t have to GPS. They can just go and start and start going on their way to get to the place, to, to get there, to get their, the, the writer there.
But the, the other piece of this with development is I could see if you stay in the same, in the same language and you stay with the same API APIs and you do a lot of the same things. You know, maybe just a little bit, you have to do things a little bit differently though, in order to be building skills up.
But I could see someone say, I need to get data out of the database. I need to get it onto a form. I need to do these validations on it. And someone knows exactly the path to drive to get to that. To that position. They know that like, if you have a, a common, a common architecture in.net is, you know, you’ve got your, your services that talk, well, first of all, you got like entity framework and then you got to service that, that acts as an intermediary layer between that.
And then you’ve got your controllers that use the services that you’ve got. You may even have another layer between that, the business logic layer that uses the services. I don’t know for sure. So I’ve seen a lot of different, a lot of different architectures. You have a controller and you have a view and, and if you know how to wire all this stuff up, you’re going to be very productive.
You’re going to know how to get from point a to point B very fast and maybe, maybe. Maybe 50 times faster than, than the new dev that walked in the door. Right. You know? Cause you could visualize every place that has to be touched. Right.
Tyler S. Lemke: [00:33:58] And you know, so that’s part of it. Right. And the other part is the.
The developer like yourself, you know, that project, we keep going back to where you did TDD and I’m a fan of TDD. I don’t, I’m still not practicing it, but I’m getting more used to unit testing and doing more unit testing lately, trying to work my way there. But, Where you did that, you did that project and you said they basically didn’t have to touch the code for like eight years.
Right? So the amount of product dev productivity you had on that project with when you take into account maintenance costs, which is typically, Oh, man. I can’t remember exactly. I think he said maintenance costs are, I want to say it’s like 50, 50% or more of the PR 50 to 80% of the project is maintenance costs.
for, for software development, I might, I might be wrong on that. You’ll have to go refer to code complete, but, maybe I can find it here while I, while I look. But, that’s amazing, right? Because you consider how productive was that, right. If you’re writing, if you wrote something, you wrote it once and you did it in a reasonable amount of time, you know, and granted productivity is hard to measure, right?
We’ve already, where is very said, productivity is hard to measure, and this is why there’s no, there’s no good tooling out there for measuring productivity. Right. Except for the best thing that we have is maybe a scrum and agile, right. Where you try to point things and see, you know, you kind of compare people to their peers, but that’s only comparing people within their same companies within their own domain.
Right. It’s, it’s hard to know is this person at that company 10 times faster than me, right. What are your thoughts on that?
Douglas Hirsh: [00:35:41] So I would say that that’s a, that’s a really good point because the, they didn’t need to add new features to the system. Then they, it may not be, have you been the primary system that they, that they were using for that, like that, that payment system may have not been used a lot, but still any time someone did a transaction on it, it worked.
And so that’s, that is the, the important thing is that it actually stuck around. I mean, a lot of times you write code and things just start. Having problems, but so that code was written with the thoughts of, of dot lions of code, but flexibility and architectural design, architectural boundaries. We can each of the components.
So things just didn’t do things that they shouldn’t be doing. I kept things, I kept tasks in, you know, I kept, yeah. Architectural boundaries. And I worked really hard at maintaining those architectural boundaries, even though I was the only one working on it, I could have done whatever I wanted. Once I set a boundary, I let that boundary be set and I didn’t cross it just to get things done a little bit faster.
And so I was very disciplined about that project and the code involved. In that system, maybe this is there’s a correlation here that we don’t, that we could investigate at some point, but the actual amount of code that I had to write to make all that work in the end was very minimal. Right? It did a lot.
It actually handled, it was a payment system. The, the point of sale system, talk to my payment system. And, and essentially we got, whether transactions were okay to start or not. It got whether they had like, they, you know, Text messaging. When was, was a, was it input into it? The point of sale was an input into it and even, our ACH gateway, was it input and also, well, yeah, basically an input.
Cause you’d send out, Hey, are they good to start this transaction that they’re trying to do a $300 transaction or a $100 transaction? Are they good? You know, are you good with them doing this? And here’s all their info. So. The amount of code involved in that project though, was very minimal. the sad thing about the fact that they hadn’t had to touch it in eight years, and I think they lost all the code is that they lost all the code though.
Like I had a whole suite of tests and everything. And if you’ve lost, if you’re decompiling the binaries, you know, if you’re decompiling the DLLs, you don’t, you don’t have that test suite anymore. That’s a really scary thought. So, I really wish that there was a way that I could have helped with that when, when I got that phone call from the developer at that, at that company.
But, you know, I wrote it intentionally to be something that would just run. I didn’t want anyone to ever have to go into the code and do anything. And it worked. But that was that’s another case. Right. I could have used a lot more code. I could have, I, I was one of these guys that, that, you know, it was like, like don’t repeat yourself and, seagull responsibility principle, and you know, all, all of those, all of these things were in my mind as I was working on this, but other developers that were next to me didn’t know those concepts.
Right. You know, they weren’t familiar with them. So that, and that was the reason why I was working on the project because they, you know, when, when the guy at the top said, I gotta make sure this is done, it’s gotta be done right. The first time we can’t go back and do it again, they threw it at me. Right.
And, and, And not that that’s not a brag, right? That’s yeah. Sometimes I wish they had thrown it at somebody else to be perfectly honest with you. Cause the, the, the few months I worked on that project, it was, it was a real pain. but yeah, it’s a surprise that when I left the company, it just kind of, it kind of kept itself running.
So, and I’m sorry, but, but that’s productivity, right? So. What is productivity? No one had to go in there and look at that code all the time. Yeah. I wrote it once I spent three months, I wrote that code once and no change requests.
Tyler S. Lemke: [00:40:06] You’re the Tenex dev at that company, man. That’s it right there. You were the Tenex dev for them at that time for that as project.
Right
Douglas Hirsh: [00:40:15] for that project that would have been five
Tyler S. Lemke: [00:40:19] X or whatever. Yeah. Like let’s say it was two X, 10 X, whatever. Right. It’s it’s some factor you were much, you were probably much better than other developers would have been. Right. Cause no one had to come and touch that code again, which is really important.
Douglas Hirsh: [00:40:36] Right. I mean, if you’re, if you don’t need to make a change to the code, then, then you shouldn’t have to go in there and, and make a change where even that system was a little, Actually, it was kind of cool because I even made it to where you could modify it from the database. Like it would go in and pull in.
We use stored procedures. Like this is, this, this company did not subscribe to entity framework or anything like that. So stored procedures, whereas a place to do a lot of things. And so, if you add it stored procedures with the right names, it would actually create new commands for the text message parser.
Like you could literally just never touch the.net code. Wow.
Tyler S. Lemke: [00:41:16] That’s really cool.
Douglas Hirsh: [00:41:17] So, no, I mean, that’s, that’s kind of, that’s, that’s kind of the stuff I was trying to do. I was trying to make it to where we didn’t have to recompile and drop new binaries every time someone wanted to do something. And, there was very, it was a very dumb application in the end and even the store procedures were pretty simplistic.
By the way, I test drove the stored procedures. So in case he wants, like, but you didn’t do TDD and the database, TC Quilty absolutely. Was doing test driven development in the database. yeah, so,
Tyler S. Lemke: [00:41:48] so. Yeah, I think so. I think that’s, that’s interesting. We discovered a 10 X developer day, everyone, so
Douglas Hirsh: [00:41:55] well now my face is turning red.
If you’re listening, you can’t see it, but it may be, even if you see the video, you can’t see it. Cause I’m a little bit in the dark. Right.
Tyler S. Lemke: [00:42:04] Douglas, we all know you’re very humble and I’m there you go. Testicle ones. So, but the, so there’s a few articles that we kind of came across in this and. you found one on Twitter. Do you want to read that? I guess there’s was a tweet by, someone, I don’t know if we want to, I guess I had the link in there, but this
Douglas Hirsh: [00:42:22] Scott, go ahead.
Tyler S. Lemke: [00:42:25] Sorry. What’d you say?
Douglas Hirsh: [00:42:27] I would say I don’t, if it’s the one, I think it is, I don’t want to read the whole thing, but maybe we can, we can summarize it a little bit.
Yeah. It’s cool.
Tyler S. Lemke: [00:42:34] It’s quite long. I think I came across this as well. now that I’m seeing it here, cause you said this was quite controversial, so what’s the gist of, sh I think his name’s checar, was saying, how do you spot a 10 X engineer? And, I believe there’s another link I have that, talks a little bit about it on, LinkedIn that I dropped in here, but, he’s a venture capitalist, so there’s a few different means 10 X engineers, hate meetings.
I think a lot of developers hate meetings. I think that’s,
Douglas Hirsh: [00:43:07] that’s, that’s not a telltale sign of a, of a 10 X Def, because if you hate meetings, it means that you’re not going to take input in from people. And part of your code has to conform to some input that they’re, that they’re giving you.
Tyler S. Lemke: [00:43:20] I mean, it depends.
It depends on if, if you have perfect, if you can get, if you can get perfect requirements to a developer and they don’t have to, let’s say that they are, you know, not neuro-typical, let’s say they have Asperger’s or they have, they’re autistic, right? Cause I have some relatives that are autistic that want to become members.
And, let’s say that they have that and they have a immediate, they have someone in between that gives them the requirements in a way that they can understand them. Right. Could that still be a 10 X dev? I’m just trying to play devil’s advocate here.
Douglas Hirsh: [00:43:55] Well, again, I mean that’s, but that is not the tail.
That’s not the end all be all to a 10 X step. Right. They may be good at cranking it.
Tyler S. Lemke: [00:44:06] Yeah. Most of them.
Douglas Hirsh: [00:44:08] Let me give you. Let me give you a story. So, you know, because communication is hard, right? Getting, getting something down that someone’s asking for on to a, into a document and giving it to a developer and letting and making sure that they understand what that means is, is actually really difficult.
And I remember when I was working in logistics, That there was this one time where, I would, I was working on a feature and the product owner would come down and tell me they need this. And I would produce that and they would come back and go, no, we don’t need that. We’d eat this. And I would produce, and I was like, wait a minute, can we just get it?
Like, where’s this coming from? And they’re like, well, one of our customers is asking for this, but we can’t seem to get it right. I’m like, well, put me on the phone with the customer. Like let’s get a meeting set up. So the customer could tell me what they’re trying to do. And then I can, I can take notes.
And then I did, and I was able to, I take the notes down and it was entirely different. Like telephone, that telephone game was in heavy play because the person in the middle was not understanding, meaning what the person wanted. And when the person told me directly what they wanted, I could actually see the code that needed to be written to make that work.
And the next try was a success and we were done. So I’ve had times where it was a lot more inefficient to have someone pull the code. But if I couldn’t talk to someone, if I couldn’t talk to that customer, Then I would have never been able to pull the requirement out and maybe it’s the fault of the company I worked for.
Maybe they didn’t have,
Tyler S. Lemke: [00:45:46] that sounds like a problem with elicitation of requirements. Right? That sounds like that’s the issue. Not, not the, not that, not that you had to be the one to do it. It has to do with Zipcar. Was it good at their job or at the job that you’re given?
Douglas Hirsh: [00:46:03] It took some kind of context of understanding what was going on underneath the covers to really be able to get what needed to be done, to make what they want it happen.
And the one sentence that the person gave me when they said it, it clicked with me what they were, what they were trying to do, but the way that someone was recording it, that didn’t understand how, you know, what the system was doing underneath the covers, kept writing something else down instead. And so that, that five minutes that literally one minute, the first minute with the customer, that when we started talking about it, I was like, Oh, I know exactly what you’re trying to do.
Like, let me, you know, I can go do, and it was an important customer. So that’s why I’m like, look, we don’t need to do this. Let’s just sit down and talk to the customer. and these and this person was good at acting writing requirements down, right? This that we were, it was just the communication, the way that the customer was asking for it to be done and what the person in the middle understood how things worked.
Was not, there was an impedance mismatch between the two. And once I came into the picture and could had it in my head, what the code was doing, that they were asking about changing. I was like, Oh, so you want to do blah, blah, blah, blah, blah. But if I couldn’t talk to someone and I couldn’t even talk to the person above me, well, to tell them that I think we have a problem, I need to sit down and talk to the customer, that.
That would have been, that would have been a, that problem may have never been solved or it may have taken a lot more tries to get it solved than just like on the third, try, go in there and get it. and you could lose a customer over the number of tries. It takes like, Hey, we did it for you. And then it doesn’t do what they want.
Hey, we did it for you. It doesn’t do what they want. Eventually. They’re like, we’re going to take our a hundred thousand dollars and spend it somewhere else. So
Tyler S. Lemke: [00:47:52] I think that’s, that’s kind of, it goes to good analogy of like, you’re trying to climb up a building or something. Right. And you put your out ladder against the wrong wall.
Like, it doesn’t matter how, like how far up the climb up that building. You’re not going to be at the top of the other building right when you’re done or I’m mixing it up, but you get the gist of it is that it requires me if, if. If people don’t understand requirements gathering is so important because if you build the wrong thing, you’ve wasted the most amount of time possible.
Right. So he said all the time critical all the time.
Douglas Hirsh: [00:48:21] Yup. Right. And,
Tyler S. Lemke: [00:48:22] and all the opportunity costs. Right. Cause if you build the wrong thing and you missed out on millions of dollars of business, because it was time, it was time critical. Right. If you’re in a startup or, or, or something’s going on, that is very, Very costly and it’s very important.
So,
Douglas Hirsh: [00:48:39] but that’s why I’d never, I didn’t mind going to meetings. Right. But it had a meeting like that was important to me. Now we did at one place, I work have a meeting where all of development met in one room and went over all of their projects. Like what everyone was working on. So what would happen is because of equalization, you know, in games equally comes from game theory.
Everyone felt like they had to say something. So everyone kept trying to say stuff for longer to make it sound like they were doing more. So these meetings that they had, like $20 Clippers in there kept getting longer and longer because everyone felt like they needed to say at least two or three minutes worth of stuff to get, to get done are to sound like they were doing something.
And what would happen is, is that, like we had one developer who fell asleep during this meeting and we had another developer who would shoot pictures of the sleeping developer. And that meeting to me was like that. Yeah, I resisted those kinds of meetings. I really complained a lot about like having meetings where people were just shooting pictures of people falling asleep, and that was the value that people got out of the meeting.
And, and so I think it’s, again, They saying that they, they hate meetings? No, I loved productive meetings. I hated meetings where we just went and spent time talking about, you know, things that didn’t, that didn’t help me do my job better and try to help me get, get, you know, for more productivity for the person that was paying me a lot of money to do the work.
Right. That’s that’s a misnomer right there. I think.
Tyler S. Lemke: [00:50:17] So this, this article though, going back to the article, I think it’s, it’s, it’s kind of comical reading it, right. It almost seems like a piece of humor to me. And I don’t think it’s entire, it seems like satire, but I don’t want to rag on, I don’t want to rag on Chicago.
Right. I don’t want to be like, Oh, why? Like, I think there’s well, as I read this, like just like kind of unfiltered, I see, like this person doesn’t understand software. Like or development. Like this person is not very technical. That’s how it comes across to me. Things like this are said, 10 X engineer, laptop screens, background colors, typically black.
They, they keyboard. He is such as I F X are usually worn out more than a S E and E it almost comes across. Like they just came up, like it doesn’t sound right. Very, and well-informed, you know, I, I, and doesn’t that seem like. Did to you as well, like this does this kind of just, that’s why it seems like really listening to like satire.
I
Douglas Hirsh: [00:51:18] don’t think it is. No, I think it’s serious, but this person, when, when this, this, Twitter threat came out, it. And this was, this was a year ago. Like we’re literally talking about a Twitter thread from a year ago. If I remember a Twitter thread from a year ago, then it must have cost something because, there were a bunch of people that responded to this.
Like how do you know? there, there were a bunch of other, other people on Twitter that, that just like tore this to pieces and not, not in a way, like directly torque to pieces, but just like
Tyler S. Lemke: [00:51:50] Twitter, come on.
Douglas Hirsh: [00:51:51] That means you don’t just. Just the memes. We could literally do an entire show talking to each of these points and maybe we should have, maybe this entire show should have been talking to, to, these points because a lot of these are the myths, right?
I don’t hate meetings or what have you. And I think a lot of,
Tyler S. Lemke: [00:52:14] yeah, why don’t you pick up, pick another one and, and debunk it or agree with it. And maybe we can pick a few and, and point them out.
Douglas Hirsh: [00:52:26] Well, I don’t want to have too much of a, too much debts, you know, let’s see here. So, Let’s see, 10 X engineers are peers as they can’t teach others on what to do or parcel of the work. They also think it takes long to teach, or it takes too long to teach or discuss with others. I would rather do it myself.
They are also poor interviewers. Okay. That just describes a title of developer. Maybe not one that I would want to work with. Right. That’s that’s the thing is, is that. And I guess this may be the path that I went down. Right. I went and did development for a long time. And then I said, I want to go teach, right.
I, the heart of a teacher. And, but I don’t know many people that are like that. Even the ones that were really good. Even sometimes we would go too much into stuff. And I was, we’ve been guilty of that at one time. Right. If someone said, Hey, what about this? I would just go through the whole like, like throw the whole architecture out there and, you know, put too much out there, which that’s a skill too, figuring out how to give just enough information.
That’s what the teaching helps with. The teaching helps with how much information do I have to give someone for them to learn a new skill? I don’t have to give them everything. I don’t have to teach them everything in my head. I just have to give them enough to let them make the leap to the next point.
And, but I do. I do know. Yeah, it’s it is, it is definitely a hard skill. Actually it’s a soft skill, but let’s talk, it’s a hard skill.
Tyler S. Lemke: [00:53:58] It’s a hard, soft skill to require.
Douglas Hirsh: [00:54:02] But, but this is, this is absolutely another one of those where. Where, if you want a good team player, you might be able to find a dev who is a hundred times could do a hundred times more work than another dev.
But if, if they can’t do all the work by themselves and they require a team, then at that point, everything, all that house of cards falls down. Because, they’re not going to get as much work done because the rest of the team is going to be not working well together. And that’s going to cause that’s going to cause productivity loss across a set of developers.
You’re going to bring down what the potential of a whole group of developers, because one person won’t communicate and I would not want, I would actually say that if I had, if the 50 X or the a hundred X a, I had an opportunity to hire one. I wouldn’t, if that is. A requirement of them, which is that they would rather do it themselves than, than have mentor.
Because at that point I can’t, you can’t scale it anymore. There’s a point where you stop being able to scale. I don’t care how X, how much Xs you have in your, you know, in your skillset, you will hit up into point. You will not be able to scale beyond a certain point. And if you cannot communicate with a team.
You’re going to bring an entire team down.
Tyler S. Lemke: [00:55:29] No. Yep. I totally agree. there’s a lot to, to tear apart here and th
Douglas Hirsh: [00:55:36] this is a good one. This would have been a good one just to even base the entire, the entire episode around, because it
Tyler S. Lemke: [00:55:43] is, I think I want it to be fair. There’s a lot of things in here that I think. Could be applicable to some people, but to say, I think, and you know, what the internet loves, loves when you’re polarized.
Right. And neither one of us are, you know, I’m, I’m dogmatic about certain things. but I think we can both. We’re both rational and we both try to get at the nuance, but, which is probably a problem for actually getting traction and getting people to do things. But, you know, getting like riled up behind things.
And I think that’s why people responded so much either negatively or positively to this message was because. to me, I get this visceral response. Like this is a lot of this is wrong. Right. And I could, I could go part a lot. I could go into a lot of it, but I wanted it to be, this last one. it said that 10 X engineers basically don’t write hacky code.
Right. They don’t hack things. They write quality code and know exactly how the code has to evolve and to have a mental model, the overall code structure. And I actually know an architect who, who, he, he said 10 extra years or people who actually do write hacky code and they’re just produced quickly and they produce junk code quickly.
Right. And he said there, that could be a 10 X engineer. And I could see, I could see both ways. I get to people that crank out code quickly, but it’s not necessarily the highest quality code. It might not be the most readable. It might not be the most, right. If you’re playing code golf with your code, is that the best code?
Well, you know, maintenance, I was just reading, and code complete maintenance programmers spend 50% of the time, time, reading code. Right. So someone’s going to have to come back and, and, on average, you know, re look at your code and go, you know, what does this pile of junk? Right. And that’s what I, that’s how everyone looks at their old code anyway.
Right. They look at their old code.
Douglas Hirsh: [00:57:32] I’ve talked to my students about that. Yeah. Definitely. You’re not going to love your code. If you have to come back and look there,
Tyler S. Lemke: [00:57:37] especially other people’s code, you’re going to go back to their code and you’re going to judge them just as, just as much, if not more.
Right. Cause you’re like, well, I didn’t do it. So they’re even worse. And then I’ve come to realize, man, I don’t think I coded any better. So I should probably be nicer. Right?
Douglas Hirsh: [00:57:50] Well, well the other, the other, the other part of that too, is that if you, if it’s been so long, you, you don’t really know who wrote the code, but you’re like, who wrote this piece of garbage and then you go into blame and realize that yourself.
That’s a, that has happened to me. That’s that kind of mellowed me out quite a bit. Like who wrote this trash? Oh, it was me. That’s so true. So, so that’s, that’s kind of like, Oh, we’re always learning. We’re trying to get, we’re trying to be better at writing code. but yeah, no, the hacky piece about it is, is that now if I had written hacky code for that payment system, how many more devs would have had to jump into the code base?
And, and work on stuff after I left the company. How much is it? Depends on your values, right? It depends on how long the code has to run. I have a hard time writing the hacky code to be perfectly honest with you. If someone came up to me and said, hack something together, as quick as possible. That’s for some reason, my, my background put me down this disciplined coding path, where I think about things I’m methodical about how the system is designed.
I don’t know. Right. I don’t typically I say purposefully write hacky code, and it’s really hard for me to do that intentionally. So it would actually take me longer to write hacky code than to write. Thought out code.
Tyler S. Lemke: [00:59:13] Yeah. I, I like, I like the idea yeah. Of not having hacky code, but I typically end up writing hacky code a lot of the times for whatever reason.
Like, when I was in the legacy system recently, because I tip, I tend to overthink. And over analyze a situation and then it like takes longer to get the code out. So I’d say if you have that same, I don’t think many developers will, but if you’re listening, you have that mindset. I got taught a cool thing by one of the developers on my team and he was like, look, just, just get it out.
Get the code out and then iterate on it, make it better. And that’s really the whole purpose of, of it, especially when you’re learning. Cause if you try to do all the good practices, right. And you’re only in your first couple of years, it’s really overwhelming. It’s very overwhelming because I’m like, I’m trying to do TDD and learn how to land when the API is and learn this and learn this and, and learn like all these technologies right now.
And it’s like, Dude, if I can just do unit testing, that’s great. Like, you know, if I’m doing, if I try to do TDD or approach it, that’s great. You can’t do everything at once. So that’s definitely, cause you just end up overwhelming yourself.
Douglas Hirsh: [01:00:18] Well, the cool thing about, about TDD. Like if you think about this, you could write some hacky code.
Right? You could write something just to get it out. If you’re doing TDD, because what is it? Red, green refactor. So you go read you, you, you get to green. You’re like, I don’t like the way that is. I want to, I want to make that a little bit better. Then you get into the refactor stage things turn might turn right.
Again, you make a green doing the new thing. Maybe you write another test or two and, and you’re good, but you’re right. So the, your. The dev on your team is exactly right. The way to, to get through a problem is to get it is to get the problem written down in some form that works. And then you can look at it on the screen outside of your head and start to look at that and go, Oh yeah, it should be like this, this and this instead.
But if you spend all the time in your head thinking through the problem and never writing a line of code. Yeah, I could see where that would absolutely be a problem. And in the first couple of years, it’s really hard. Like you really don’t want to do it. That’s a culture thing. You don’t want to do the wrong thing, but maybe you don’t want to do the wrong thing because someone on your team is that, is that person that will just kind of filet you in front of everybody because you, you did the wrong thing in the code.
And, You know, what you want is to be on a team with a mentor that you, you go to code review with. It says, you know, say, you know, maybe that way is that right? The best way let’s talk through it. That’s what I always tried to do with people that I had to do code reviews with. Sometimes, sometimes they come back to me and go, Hey, this is what I was thinking.
And this is why I did it that way instead of the other way. Okay. But, you know, if you have someone that publicly shamed someone, or even not even publicly shames, like why are you such an idiot? You wrote this code so poorly, that’s going to make them not want, that’s going to make them think really hard.
and, and not even, you don’t have to say it. Just the look on your face. Just the look on your face when you look at the code and you’re like, you give them a look like, okay, you may not, you know, that, that, you know, that that communicates volumes of speech. I don’t know if you heard the sound or not that I made that, you know, that kind of like, like little bit of, you know, starchiness in your, you know, the first response to it.
and then you’re like, well, why don’t you just do this, this, this, and this. And, you know, people that do that, you don’t want to deal with those people. And so you may want to always have the code written in a way, and you spend so much time overthinking the problem because the person who’s reviewing your code may just be a real jerk.
Tyler S. Lemke: [01:03:00] Right? So I think this might be a good place to end off. We have this, rules of thumb for Onex developer. And I think we both found this article, separately. I haven’t gone. I’ve actually only skimmed over part of it, but I thought it was a really interesting, article. What do you remember from this article?
Douglas Hirsh: [01:03:23] Well, Give me a sec. I wanna, I want to bring it back up so I can see it. What I thought about this article is maybe this person is, is being very humble because some of these rules, they have experience in them. And this person may be, may say, rules of thumb for a Onex developer. But when they say, when someone, when some people say 10 X developer, they think of someone who just eats sleeps and drinks code, right.
They don’t, they go, they go home and they work on more code and they get up in the morning and they work on code before they go to work and work on code that code in their code. So they can code while they code. Yup. You know, that’s, that’s one thing where this person is saying that I don’t do any of that.
And I may not be as quick to go pick up a new framework, but the rules that I read in here that this person goes by, there’s there is there’s wisdom in these rules, which means that there’s experience. And this person may be the 10 X developer, like, like we’ve talked about that, that knows when to write code when not to write code.
And you may not be able to measure their productivity in a really good way. And they may even be, they may be putting themselves down. Right. And that’s, but what I see in here is good wisdom in this article. And I see someone who has some experience with writing code and probably is better than me at hanging up the computer at night and going and doing something else.
Right.
Tyler S. Lemke: [01:05:01] Yeah, for sure. so we didn’t really define what he meant by one X developer either. So from what, from what I gathered, the one X developer is basically, I think he says in here that he wanted to be, maybe try to become a 1.1 X developer, right? He says, if I’m feeling ambitious, I would like to be, come a 1.1 X developer.
And basically he, he, he likes going home and just doing this, he’s doing his own thing. Right. he said he raised, he raised three kids. I’m assuming, I’m assuming this is a guy, might be wrong. but he raised three kids and, yeah, it says, it is a guy. So the, Taking care of his family. He first contributed to open source project like a year ago.
And it sounds like he’s been developing for some time. So, and I’m not that I’m not that you know, that 10 X, if you want to say 10 X developer person who eats breathes and sleeps code, but you have been in the past, right? Douglas you’ve you’ve done that in the past.
Douglas Hirsh: [01:05:59] Yeah, totally put it down. Right. I. I always felt like I was behind the eight ball.
And so I would go home at night. I would read about stuff. I would, I was the person that would do that. And maybe I did it in my more formative years. Maybe I spent that time and took those. It took the hits early, of doing that. But what I really sitter I was doing was I was getting my CS degree, agree.
I was getting the information I needed that I was missing because I didn’t go get a CS degree. And, and that kind of put me in a place that was really interesting because people that had their degrees didn’t think like I did, I would read stuff about how you should code and patterns and, and scalability and all this stuff.
And no one else was talking about that stuff around me, but they had degrees. And it was so funny. I worked with someone who had the, you know, got their master’s degree. And I was sitting there with them. We were talking about the school, you know, they were all talking about schools. They graduated from and I said, I didn’t go to college.
He goes his fault. That’s so weird. You talk like, you basically talk like I do, you know, and he has his master’s degree. Right. And so the thing is, it was a master’s degree in computer science. And so. Maybe that time I spent, there was a lot of imposter syndrome. I dealt with that a lot and I think that people early, there’s no way I could, I could stop someone from dealing with imposter syndrome.
I can try to reassure them and let them know that as time goes on, you’re going to learn more. It, you don’t know everything when you first get started. I can try to do that, but I cannot mitigate it completely. I dealt with imposter syndrome for an instilled, maybe even somewhat to some extent still do.
Cause I’m teaching. Like, look at, look at me with no degree and, and I’m teaching people how to write software, but I have all this experience that I can give out in class when I’m talking about. That’s where I have to be careful though. I can’t give them too much of my experience because a lot of it wouldn’t make sense to them, but I have to go back to when my, my, my, my junior years and bring stuff out and go, yeah, we totally, or something where I show them something like I’ve had to deal with this.
Five or six jobs. And this is something you need to think about, you know, when we’re teaching it. But I try to keep from going into like the really deep stuff that I have in my head. When I look at things like for instance, I’m in spring right now, what we’re doing is, is, you did model binding to a, to a controller.
And so. I mean for anyone who’s done like.net or something similar like MVC framework, she could put an object in your controller method and, and the framework will bind properties that are coming up either through Jason or through a form to that object is what I mean. Well, if you, you know, Right now, we’re just trying to get them to be able to do that successfully.
We’re not teaching them about like going through services and going through a and all this stuff. And I was, I said something to my co-instructor I’m like, you do realize that this is an overposting vulnerability and he’s like, well, I might, I’m just saying to you, I’m not like this wasn’t during a lecture.
I’m like, I, I want to give them all of that, but it wouldn’t make sense to throw everything at them at once. Right. We got to get them to the point where they can post a form and then we get to the point where they do it better and then they do it better. And then they do it better.
Tyler S. Lemke: [01:09:37] I think if I definitely suffer it, that when I teach, I tend to give too much information because my brain just starts making all of these connections.
And I think that’s where I’m, I definitely need to, do better and, come off of it. But I think there is, there are certain details that you can give. That are valuable, but you have to know which exact ones to pick. Right? Like, sometimes like I teach like arguments versus parameters and what those are like, that’s a small one.
That’s like, I try to really emphasize. Cause I’m like, look, you know, communication’s important, right. When you’re talking to other developers and it’s little things like that, that could help you. To get hired when you’re, when you’re talking to other developers, right? Like if you use the right terminology and you’re coming out of the bootcamp, like that could definitely help you.
Yeah.
Douglas Hirsh: [01:10:23] And we try to model the right terminology. That’s actually the way that we, we model the right terminology. And so they hear it all the time. They hear how we talk about the different things. Cause I’m, so this was the, this was a funny thing we were talking about this today. We are alive coding every day in front of our students.
I mean that’s we’re lecturing. So not only are we teaching, but in our lectures, we live code during our lectures. And you see all the people talking about in, in, you know, at the conferences about, Ooh, don’t like try to put your code on slides because something may. Mess up don’t live code. And I’m like, I live code every day for a living in front of people on zoom all the time,
Tyler S. Lemke: [01:11:05] things go wrong,
Douglas Hirsh: [01:11:07] fix things will go wrong, but there are mitigation tactics that you can, that you can put in place to keep them from going wrong.
And I’ve learned those mitigation. I’ve learned a good number of them, but even with that, things still do go wrong. And I had it happen today. Like it just, it just happened. I’m not scared of it so much, but no, I think the reason that we were talking about. About this as the number of facts that we give out at one time, we want to try.
We want to try to give out facts that are pertinent to what they’re trying to learn. Not anything that could distract from the actual lesson content that we’re trying to give them, because we can give them more content later. But if there’s something really specific that we’re trying to get them to get to like a new place, we’re trying to get them to, to make new connections.
We want to try to avoid as many extras. As, as possible that will take them off the path that we’re trying to get them down. Because when you say something, they don’t understand, they stop listening and they start trying to think about what you said. And so that’s a challenge. Yeah. It’s a, it’s a challenge.
And so, no, I mean, Yeah. Knowing what to say when to say it is, is something that we y’all learn it. Like I said, the imposter syndrome was something I was trying to roll this back imposter syndrome, even in that sense, because I’m teaching and I didn’t finish college. Right. There’s actually a lot more to that story.
And one day we might actually do an origins episode. I have not decided if I want to do that on this podcast or not, but there’s, there’s a lot more to that and would make a lot more sense to people. Why, why I do suffer or did suffer a lot from imposter syndrome? it’s still do to a certain extent. but I think with that, I’m, I’m pretty close to we’ve we’ve been recording quite a while.
Yeah,
Tyler S. Lemke: [01:13:02] we have, I think, so I wanted to make some final comments, so let’s do it. Yeah. Let’s make some closing arguments or closing statements here. Act like lawyers for a second or whatever. I’m not a lawyer, but I play one on my podcast. Right. So, the
10 X developers, I think. For the concept let’s back down from TEDx developer and let’s just talk about good developers, right? Everyone has an idea of what a good developer is, right. A productive developer versus okay. Developer versus a nonproductive developer. And so let’s it. The terminology of productivity developers, different developers.
You might have a developer at one company that is looked at as being a very productive developer and at another company they might be looked at as unproductive, right? And this I’ve kind of learned through experience and through like my own experiences that, Oh, like you don’t have to, you don’t have to conform to this one particular idea of what a developer is.
You can use your own strengths and depending on what company, and I iterate this idea a lot, but depending on what company you go to, they’re going to value your strengths or not. So I think the 10 X developer is different. For different companies or productive developer. Right. And that has a different idea idea of what that is for each company.
so if you want to become this more productive, let’s say it’s the 1.1 X developer, right? You’re a better than average. If you want to become that developer, you have to understand what your strengths are, double down on them and then find companies that will, that, appreciate your strengths.
Douglas Hirsh: [01:14:42] Yeah. I mean, to be fair, the article that we’ve been talking about, the guy has a, the guy works for Amazon, or at least that’s what it says in the article. So if you work for Amazon and you consider yourself a Onex developer, then maybe this standard of one X, if you were to go, like you just said, this, this falls on what you just said.
If you were to go to another company, you might actually be a 15 X developer. You got into Amazon.
Tyler S. Lemke: [01:15:10] It’s funny. Cause they actually said, one of the books I read, I think it’s radical candor or something like that. They said they, I forgot which book it was, but they basically said they actually have to let people go at Google and say, look, you’re not a good fit here for whatever reason, you’re either not, you know, for lack of better terminology, not smart enough, it would be, I don’t want to say smart enough, but you don’t produce enough of the type of code that they need or whatever that means.
Right. So they know that if you go to a different company that you’ll actually be more successful there. And this is an interesting concept mountain. I think Malcolm Gladwell talks about, of, of. students that try to get into better universities sometimes do worse because it’s more competitive there.
So if you go to Harvard, for example, you actually, versus, you know, a local school that’s not as difficult. you might actually perform worse because your peer, you will feel worse in that environment because you’re not the smarter person in the room. Right. Or you don’t feel as smart, right. Cause you might be at the bottom of the class.
So it might be better to go to a place that is. where you might be average versus being the worst. I don’t know how to say that in a, in a different way, but hopefully people took it in the right way, but
Douglas Hirsh: [01:16:20] I think it’s a good concept. Yeah. It’s the same thing of like being the, the, the big fish in a little pond.
Right. It kind of comes down to that. To that analogy. If, if, if you are the biggest fish, then, then you might be a tiny fish in the ocean and be eaten up instantly. But man of that little, that little pond you’re in you are you’re, you are at the top of the food chain. So, you know, I kind of feel like it goes there.
So here’s my final summation for right now, because my mind could change over time. My final summation is does the 10 X developer exists? Yes or no? I think yes and no. And it depends. It depends on the company that they’re in. Like we just said, Tyler, I’m just feeding off of what you said. They could be 10 X better than another developer next to them.
But if they were to go to let’s say Google, they might be at the bottom. They might be all the way in the left hand side of the distribution. Right. They might be the worst. So, you know, maybe, maybe, really, if you want to be a. Maybe 10 X developer is not exactly where you want to be, but you always want to be the one striving to be better.
Right? That, that may be what you want to do is strive to be better. Always go to where you’re not all the way at the left of the distribution, but maybe go to where, where you have room for improvement. You might be a little bit to the, to the left of the average. You know, a little bit lesser than, than the average, and you can push up to it and then go to companies that are more and more challenging over time.
And then eventually, maybe anywhere you go, that’s not like a top company you might be in 10 X engineer. Great.
Tyler S. Lemke: [01:18:14] Great. So emotion, we’ll see you next week, guys.
Douglas Hirsh: [01:18:20] Have a good one. Y’all.