3 ms·
Well like others said, this reads more like an opinionated piece on how to be a good teammate. I think Antirez[1] has more practical advice on how to actually
by reese_john 7y ago
Well like others said, this reads more like an opinionated piece on how to be a good teammate.
I think Antirez[1] has more practical advice on how to actually become a "10x programmer"
Key points:
* Experience: pattern matching
* Knowledge: some theory is going to help
* Low level: understanding the machine
* Debugging skills
* Perfectionism, or how to kill your productivity and bias your designs
* Design sacrifice: killing 5% to get 90%
* Simplicity
* Focus: actual time VS hypothetical time
[1] http://antirez.com/news/112 http://antirez.com/news/112
- carlmr 7y ago>The programming community is extremely polarized about the existence or not of such a beast: who says there is no such a thing as the 10x programmer, who says it actually does not just exist, but there are even 100x programmers if you know where to look for. I think it depends on your definition. If you compare with the average programmer in your company then you can easily be a 10x if you're working in a big company where the average abilities are low. But it becomes very hard in a smaller company where most of your colleagues are competent. If you define it relative to a more global average I think it's too difficult to know what an "average" programmer even is. Now if in that big company you have to work only on small parts of the whole it often becomes harder to be fast again, since your colleagues might be writing APIs with a lot of hidden complexity. If however your task is more isolated it becomes easier to do good design.
- djmips 7y agoI think this is the closest I've seen to a concise answer to the 10X programmer's advantage. Earlier in my career, I noticed a fellow programmer who was quite noticeably faster at completing tasks than everyone else including myself. We also had a coding competition and I 'programmed' as fast as he did in direct comparison on the same task. So it turns out, the performance boost was not in raw coding speed but a lot of other things like not being distracted, being ok with a great but not the greatest design, getting to work and avoiding analysis paralysis. A sense of urgency from day one on a project. When competing head to head for a fun competition, many of these things come naturally but when given 'time' it can be easy to fall back to less productive habits when a deadline is months away. Like my mentor Steve Hayes once told me 'hands on keyboard'