4 ms·
In addition not being able to measure 10x just makes things hairy. Am I a 10x, probably if you ask me to pump a couple of CRUD pages. Am I a 10x in adding featu
by nojvek 10y ago
In addition not being able to measure 10x just makes things hairy. Am I a 10x, probably if you ask me to pump a couple of CRUD pages. Am I a 10x in adding features to a compiler. Probably not.
If a business hires me thinking I am a 10x-er they have high hopes that I can't satisfy for their dimension of X.
There are good programmers, great programmers and dangerous programmers. But that's all relative to what work needs to be done.
- sqeaky 10y agoAt first I read this like a brag, but then I realized you meant that your skills lie in one place and not another. So perhaps it is like this for many. Maybe many under-performing devs are simply not in an area engaging to them, but they are doing something to get their bills paid. If so how do we address such a problem?
- DougWebb 10y agoIf 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 10y agoyou realize that the tests are primarily for other developers (on your team, in the future) and not yourself, right?
- DougWebb 10y agoThat'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 10y 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.
- ozim 10y agoGets even more funny when you add team dynamics, in one team you can be 10x programmer if people are decent. When you are in a team with maybe not better guys than you so they don't have to be really 10x you and you just feel bad, you might not pump even 1x off yourself.