3 ms·

If you're capable of both pumping out CRUD pages and adding features to a compiler, then you may be a 10x developer. I consider myself to be a 10x developer, b

If you're capable of both pumping out CRUD pages and adding features to a compiler, then you may be a 10x developer. I consider myself to be a 10x developer, but I'm not 10x all of the time for all tasks. Things that set me apart are the quality of my code vs other developer's code for a given amount of development time, the higher probability of my code being bug-free or nearly so before I've even run it, my skill at tackling extensive refactoring tasks with zero change in code behavior without needing to write and constantly run tests, etc. These skills all come from long-term experience, wide variety, and a fearlessness and belief that no development task is beyond my capability. If you look at athletes, you'll see some that are really good at one particular sport, some that are naturals at pretty much anything they try, some that enjoy sports but aren't particularly good at it, and some (like me) that are so non-athletic that it's embarrassing. I think development skills are like that too. We can't really identify what '10x' means, because it depends on context and isn't tied to specific skills or behaviors.

metaphorm 9y ago
you realize that the tests are primarily for other developers (on your team, in the future) and not yourself, right?
- DougWebb 9y ago
  That's highly dependent on the team, the code, and the tests. For my work, most of the time, comments in the well-structured code are much more likely to still be useful and valid to me and my team over time than a test suite that won't get maintained. In the past six years, I only worked on one project that justified an extensive test suite. It was a scheduling system for a large machine shop, which allocated multi-step manufacturing tasks across a suite of metal-working machines for dozens of concurrent jobs, while taking into account available machinists, working hours, breaks, vacations, and scheduled maintenance downtimes for each machine. Testing the algorithms for that required setting up a variety of consistent starting conditions, running the scheduler, injecting changes to existing jobs and inserting new jobs at certain times, and making sure that the resulting scheduling decisions were acceptable to the experts who'd been doing the schedules manually and to the machinists.
dahart 9y ago
> If you're capable of both pumping out CRUD pages and adding features to a compiler, then you may be a 10x developer. This is a valuable point; many of the most productive people I know are breadth first not depth first. Being able to glue disparate systems together without having to stop and iterate with someone else saves a ton of time. > Things that set me apart are... the higher probability of my code being bug-free or nearly so before I've even run it I totally applaud your self confidence, and kudos if you're writing big chunks of nearly bug-free software before ever running it. My personal experience has been that even when I've been at my most productive, is that the probability of code of any nontrivial size being anywhere near bug free before running it is exactly zero. I'm scared of people who believe otherwise (I've never met someone who could prove it), and much of the success and productivity I've enjoyed in my code and management career have rested on the strategies to avoid assuming that code is nearly bug free. The very best programmers and the very smartest people I know are people that came to the same conclusion - that every line of code is another bug - and then used that information to decide and inform how they're going to write software. They consciously avoid using fancy language features or playing code golf, they refactor often when architecture gets crusty, they spend a lot of time making sure other people can read their code, and they test and test and test.
- DougWebb 9y ago
  "higher probability" doesn't mean "always". Of course I test my code thoroughly before committing it. But the fact is that my code tends to be really close to done before I've even run it. I'll admit that's sort of a technicality, though. I've been programming for a long time, most of my career without anything more sophisticated than a text editor. I've taught myself to be pretty good at running code in my head, even fairly complex code. So what I'm really doing while I'm writing code is running it in my head as I write it, and finding the unhandled edge cases and other bugs while I'm doing it. I'm also compiling the code (if applicable) which finds other bugs. So, by the time I run the code for real, most of the bugs are gone. This is all a natural part of the act of coding for me, so I see it as coding rather than running/debugging. (I often debug in my head too; handy when you know roughly where a problem is but can't reproduce it.) I agree completely with your last paragraph; that all helps to be able to hold the execution state in your mind while you're reading through the code.

metaphorm 9y ago

you realize that the tests are primarily for other developers (on your team, in the future) and not yourself, right?

DougWebb 9y ago
That's highly dependent on the team, the code, and the tests. For my work, most of the time, comments in the well-structured code are much more likely to still be useful and valid to me and my team over time than a test suite that won't get maintained. In the past six years, I only worked on one project that justified an extensive test suite. It was a scheduling system for a large machine shop, which allocated multi-step manufacturing tasks across a suite of metal-working machines for dozens of concurrent jobs, while taking into account available machinists, working hours, breaks, vacations, and scheduled maintenance downtimes for each machine. Testing the algorithms for that required setting up a variety of consistent starting conditions, running the scheduler, injecting changes to existing jobs and inserting new jobs at certain times, and making sure that the resulting scheduling decisions were acceptable to the experts who'd been doing the schedules manually and to the machinists.

dahart 9y ago

> If you're capable of both pumping out CRUD pages and adding features to a compiler, then you may be a 10x developer. This is a valuable point; many of the most productive people I know are breadth first not depth first. Being able to glue disparate systems together without having to stop and iterate with someone else saves a ton of time. > Things that set me apart are... the higher probability of my code being bug-free or nearly so before I've even run it I totally applaud your self confidence, and kudos if you're writing big chunks of nearly bug-free software before ever running it. My personal experience has been that even when I've been at my most productive, is that the probability of code of any nontrivial size being anywhere near bug free before running it is exactly zero. I'm scared of people who believe otherwise (I've never met someone who could prove it), and much of the success and productivity I've enjoyed in my code and management career have rested on the strategies to avoid assuming that code is nearly bug free. The very best programmers and the very smartest people I know are people that came to the same conclusion - that every line of code is another bug - and then used that information to decide and inform how they're going to write software. They consciously avoid using fancy language features or playing code golf, they refactor often when architecture gets crusty, they spend a lot of time making sure other people can read their code, and they test and test and test.

DougWebb 9y ago
"higher probability" doesn't mean "always". Of course I test my code thoroughly before committing it. But the fact is that my code tends to be really close to done before I've even run it. I'll admit that's sort of a technicality, though. I've been programming for a long time, most of my career without anything more sophisticated than a text editor. I've taught myself to be pretty good at running code in my head, even fairly complex code. So what I'm really doing while I'm writing code is running it in my head as I write it, and finding the unhandled edge cases and other bugs while I'm doing it. I'm also compiling the code (if applicable) which finds other bugs. So, by the time I run the code for real, most of the bugs are gone. This is all a natural part of the act of coding for me, so I see it as coding rather than running/debugging. (I often debug in my head too; handy when you know roughly where a problem is but can't reproduce it.) I agree completely with your last paragraph; that all helps to be able to hold the execution state in your mind while you're reading through the code.