Real 10x Programmers Are SLOW To Write Code

- Some people feel jealous of people that call themselves ten X programmers because they can write code really fast. But a company isn't looking for someone who can be more efficient. So here are six techniques I have used in my career to be a ten X programmer. - Speaker A: The fifth thing to be a true ten X programmer is to minimize architectural complexity. Speaker F is to be careful not to just introduce new innovations to the code, new patterns, etc.

It's inevitable that once you get that in front of the product manager or the customer or the client, they're not going to accept that they're going to have issues with it. And then you risk having to go back, re code things, refactor things, waste a bunch of time with recommunicating. That's going to waste any gains that you would have had by being a faster programmer. Ever feel jealous of people that call themselves ten X programmers? You see them write code really fast and kind of secretly wish it was you? Well, when a company thinks about a ten X programmer, they aren't actually looking for someone who can crank out code faster. They're looking for someone who can be more efficient. This just really means getting stuff done quicker, and sometimes the way to get there isn't by writing code faster. In the over 20 different software companies I've worked with on different software projects, I've run across many programmers who kind of think they're God's gift to programming, but they actually slow the project down by writing code too fast. If you can write less code in the first place, you can be a true ten X programmer. So here are six techniques I've used in the actual ten X programmers I've met in my career use that'll help you be more efficient by writing actually less code. The first one of these is technological empathy. This is being able to make technology and coding decisions based on your team, not just yourself. Now I can hear the objections already. Well, who cares about my team? It's me that's being measured. I want to be the ten X programmer. Well, let me tell you a quick story. I was actually out at a company here in Austin. We'd agreed on a $160 an hour bill rate. It was a great project for me. I was there for about a year, and they had a pretty big architectural problem. Their company needed to rewrite 13 different web applications, and most of their developers were.net developers. Now, I'd done a lot of.net coding already in my career, but I also had moved on many years before that to doing single page application development, node, react, vue, all that kind of good stuff. If I chose the code that I wanted to write, that I could be fastest with the languages that I preferred, I probably would have went with a more modern stack. But this company had nine other programmers that were going to take over whatever I built for them and whatever I proposed for them. So I actually picked kind of the latest.net stack that they had at the time. And even though I probably could have personally written code maybe faster. When I looked around at the team and the skills of everybody else, it was actually a lot faster to build something they were familiar with, and that client was really happy with me, and they actually brought me back for two other projects after that. The second way you can be a ten X programmer by writing less code is to learn to negotiate streamlining of features. Have you ever been on a project and you get a user story or a feature from your product manager, and you look at it and you think, you know, this is going to take me a lot of code. I wonder if I can convince the product manager to come up with a simpler approach, or I can pitch something to them that will be easier to code. So that's less effort for me. This is sort of what I'm talking about. Here's the difference, though. If you try to pitch to your product manager a change to their design that's supposed to satisfy their customer with a feature, and it doesn't give them the same outcome that they want, they're not going to care about you saving effort by writing less code. You have to actually still achieve the same customer outcome, or allow the customer to be able to do the same thing that the product manager wants them to with less code. Now, if you can learn to do that, if you can actually propose simplification to designs that your product manager, you can tell them, hey, this is going to take me, you know, a certain amount less time, or it's good, you're going to get this in the hand of customers quicker and they can achieve the same outcome. You can actually be much faster than many other developers that can maybe write code faster than you and maybe, you know, are wizards with algorithms. But you save a ton of time by just not having to write as much code in the first place with a more simple feature. The third way that you can be a true ten X programmer by writing less code is having cross technical insight. What this means is the more different technologies you get exposed to over your career. Let's say you've written 4510 different programming languages, or you've done web development in two, four, six different you, web application frameworks, or different platforms of some sort, every time you then go get a new feature to build, or a new piece of code you have to write, when you go into something new, a brand new library that you've never had exposure to, your brain is going to start to light up and go, wait a minute, this aspect of this technology is super similar to that other thing I used before here. And wait a minute, this configuration setting, I've never seen this before, but I see what they're trying to do. They're trying to do this other thing here. If you actually can draw parallels between new different features of programming languages, of libraries, of frameworks that you're exposed to to get your job done and things you've done before, and not have to go to stack overflow and not have to do a bunch of searching and reading discussion groups and getting on discord, but you just can draw those connections, you can often save a ton of time if you think about, you know, somebody who can't do that. As soon as they run into, and I've ran into these people, as soon as they run into a new aspect of a language or a framework or, you know, something they've never done before, they're wasting hours reading about it, researching it, trying to understand what it is, what it means, what it does, when, if they would have had, or maybe they even did have some exposure to a similar technical concept before, but they just can't draw the connection. So the more you can leverage stuff you've already learned and apply it in new situations, you can save a ton of time over someone who's just really fast at writing code. And hey, if you're ever frustrated with this pressure that we often feel in the industry to be a ten X programmer in the classic sense that we think we have to be super fast at coding, you watch people on twitch and maybe at your job and you just see them banging out algorithms and it impresses you and gives you a bunch of imposter syndrome. You know, I want to tell you to consider joining the discord that I have for this channel. You can get in there through a Patreon membership or the YouTube membership. There's a link in the description. There's quite a few people in there who have joined that are big supporters of the channel, and they're trying to advance their tech careers and thrive in a healthy way where they don't burn themselves out, they don't kind of fall prey to a lot of the popular but not really helpful tropes about software development. So if that's you, check it out. The fourth way you can be a true ten X programmer and actually be seen as one by your company is to absolutely reject ever moving forward on any kind of ambiguity. If you get handed a user story or a feature or a Figma design or screen mock ups or some spec for an API, it doesn't matter what it is and got questions about it and you're unsure and you just jump in and begin building it. But you have that feeling in the pit of your stomach, I don't fully understand this, or I think there's some major holes to it, and you kind of move forward anyway. It's inevitable that once you get that in front of the product manager or the customer or the client, they're not going to accept it, they're going to have issues with it. And then you risk having to go back, recode things, refactor things, waste a bunch of time with recommunicating. That's going to waste any gains that you would have had by being a faster programmer. So I'd really encourage you, if you get anything assigned to you, if you have any ambiguity in there, things that aren't clear to you, just stop what you're doing. Even if you're in the middle of coding a feature and you've got a, let's say, acceptance criteria, a bunch of steps of what the code's supposed to do, you get all the way through five steps of it. You've been coding for a couple days or, you know, couple hours, and you suddenly hit a spot where there's any kind of, you know, unclearness or ambiguity. Resist that pressure to just, I'll talk to someone else when I get a chance, and I'll just make an assumption here. I've found the more I'm able to just stop myself, not move forward on assumptions and get clarification, the more complete my work is and the more efficient then I am. Because when I say I'm done with something, I'm actually done with it. The fifth thing you can do to be a true ten X programmer, from the standpoint of really multiplying your impact on a project and really making everybody and all the work you produce more efficient and effective is to really minimize architectural complexity. When I was about the third year into my career, I'd read so much about architecture. I've learned a lot of different, you know, programming techniques, about three or four languages at that point, tons of reading, you know, all kinds of stuff. This was in the late nineties, and I really felt like I had a better grasp on architecture kind of than I did. And I used to really enjoy, you know, trying to make code dry to a point that I would introduce new abstractions or new coding patterns that I understood that did make the code simpler on the surface. But then when my team would pick up those patterns, they weren't the ones who created them. So I had to actually explain those patterns even though they were simpler to them, they were having to understand my unique invention. And then on top of that, once they started using them, if there were any problems, now they've got to go dig underneath this pattern or this library or some sort of abstraction I've created and understand what did Jamie do to try to make this code simpler in the first place? And often I don't know if you've experienced this, the implementation of abstractions we create is more complicated than if we didn't abstract it in the first place. Maybe pause for a second there and see if you fully grok what I'm saying here. But ultimately what I'm saying just is be very careful. I've really blown this in my career many times and in the last probably 1015 years I got a lot better at it, really be careful not to just introduce new innovations to the code, new patterns, new libraries that make things from your standpoint easier to code. Unless you're ready to support the team. When they have questions, when there's issues, you're confident that if there's problems and they have to go into the implementation of this thing you've abstracted, they're gonna get it, they're gonna grok it, and then be prepared too to document everything. And that gets to the 6th point, which is if you really wanna be seen as a ten X programmer, you actually wanna have ten times the effect on your project as everyone else. One of the best things you can do is learn to step back and document. Anytime you innovate, anytime you're working on a code base and you're like, oh, I'm going to combine this NPM package with this NPM package and come up with this new pattern of how we do some aspect of, let's say integration in the code base, you may think to yourself, well, and I've thought this, there's two or three examples in the code. If somebody needs to do it, they've got examples now, they can go to it, maybe. I threw a couple comments on there I've seen many times over my career where I made that assumption, and it was just a wrong assumption. Once other developers on my team got in there, looked at the code, looked at the patterns, they couldn't connect the dots between the pattern that I'd sort of used in the code, you know, the architectural pattern, the coding pattern, and how they needed to apply it in their unique situation because there was some little detail of what they were doing that was slightly different, wasn't represented or just, I made assumptions that it was easier to understand than it was. And I had a lot of stuff in my head that I thought was fully conveyed by the code. Some of this is just a pride problem that I had earlier in my career. If you actually instead can step back and go, how do I write a wiki topic? You know, something, if you're using confluence or Jira, whatever you use, hopefully something that supports markdown, how can I just, you know, at least describe what is this pattern? When would you use it? Here are some examples that show how it could be used in some scenarios. And then describe those concepts. Give them names, explain what they are, and make sure that's available to anybody who has access to the code. That's going to minimize the chance that somebody jumps in, makes some assumptions about the code and then implements it wrong. And it's also going to reduce the time any new team member joins your, your dev team that they're going to have to spend to kind of get up to speed on unique innovations that you've put into the code. So if you ever felt pressure to code fast from management, probably just from the tech industry, maybe from other youtubers who are telling you that's what makes a good programmer. Have you ever seen somebody come into a company who's really fast at programming, but they write sloppy code, or they write over complicated code, or they create, you know, inventions, innovations and designs. They don't document anything. They think it's simple, they're frustrated with their team, and then everybody has a hard time moving forward. How could you look at a person like that as a ten x programmer? But let me know what you think. Let me know in the comments. Until next time. Thanks.