5 ms·

I have no doubt that there are programmers who are 10x as productive as other programmers. I witnessed it over and over. But as I understand it, the "10x" mean

I have no doubt that there are programmers who are 10x as productive as other programmers. I witnessed it over and over. But as I understand it, the "10x" means 10 times the productivity of an average programmer. I wonder how productive the average programmer is. I find this question super interesting. For example, I see more and more programmers who use "Query Builders" and "ORM layers" without understanding the underlying database mechanics. Coding this way not only takes multiple times longer then - for example - just writing plain SQL. It also often results in code that runs hundreds or thousands of times slower. And complexity explodes as the project grows. I have the feeling that - with the rise of frameworks - this might be the new "average" of coding. If so, then there definitely are coders who are orders of magnitude more productive then this average.

drvdevd 9y ago
I believe this is an easy trap for developers of all skill levels to find themselves in. I imagine the "10x developer" would just be really good at avoiding this kind of thing ... most of the time.
- beagle3 9y ago
  Yosefk.com has a great article about being 10x more effective by being 10x more selective.
  - mfukar 9y ago
    That article is a post-mortem with an awful lot of hindsight. Not everybody would able to ask the questions Yossi identifies in the post-mortem while the requirements are presented. Would somebody then, instead, be able to become 10x more effective by thinking 10x more about their work, before they do it?
    - drvdevd 9y ago
      Personally, I believe there's some level of "intuition" involved, that perhaps some people are just gifted with naturally. I think these people still have to practice though, to build upon that natural ability. Note that I'm certainly not referring to myself here -- I consider myself Just Average. I'm thinking of friends and colleages I've known over the years who have this seemingly natural gift. That being said, I also think everyone can benefit by finding some sweet spot between 'thinking hard up front' and 'analysis paralysis'. For me personally that means start by doing something, then revise and iterate. That's just my cognitive style I suppose.
GreaterFool 9y ago
When I hear 10x programmer I think "10x me". I've worked with a handful people like that over the years and it has been a pleasure. If there's a 10x programmer in my team I know I'm in the right team!
Bahamut 9y ago
There is a huge cost to handwriting SQL too that one mist be careful of - it is very easy to result in poor abstractions as a result of inconsistent apis from lack of abstraction over SQL. My company is currently in the process of moving back to an ORM after 5 years or so abandoning ORM usage due to nightmarish performance using NHibernate in .Net (maybe more of an indictment on the code than anything else, but I don't know the specifics of the history). We found the company had a lot of problems that resulted from handwritten SQL, including lack of ability to adequately abstract the logic for proper unit/integrated testing, and inconsistent data fields being returned by various queries, resulting in inconsistent api endpoint data returned to the client and thus inability to safely abstract without significant hacks/nebulous data model state. The worst thing we encountered with handrolled SQL over ORM was that it actually hindered our ability to deliver major business requirements. We had no ability to gate content by various values from other tables without modifying the handrolled SQL in every single location...not a good situation to be in at all.
- fnord123 9y ago
  > inconsistent data fields being returned by various queries, resulting in inconsistent api endpoint data returned to the client and thus inability to safely abstract without significant hacks/nebulous data model state. You are coding against actual queries? Why not functions to hide the table abstractions: https://www.postgresql.org/docs/current/static/sql-createfunction.html https://www.postgresql.org/docs/current/static/sql-createfun... https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html https://dev.mysql.com/doc/refman/5.7/en/create-procedure.htm... >We had no ability to gate content by various values from other tables without modifying the handrolled SQL in every single location Again, don't sql functions solve this?
  - icebraining 9y ago
    That's essentially building an ORM (well, a data mapping layer) out of PL/SQL functions rather than your main language. Why would that be better?
    - 9y ago
ajuc 9y ago
This is not only about frameworks and ORMs, it's about refusing to comprehensively understand stuff before you use it or change it. It can be any abstractions, even (usually) the ones you created by yourself. It's easier to add a special case check, than to read through the codebase to see if it's even needed, or, God forbid, to refactor in 5 places so it's not needed (it might break sth else!!! I would have to read and keep in memory the whole control flow of the program!!). Programmers have to do dozens such decisions every day, so after a few months if they go the easy way too often it adds up and creates chaos. I've done this myself, and seen this done by younger programmers. It's that crucial skill of stepping a few steps back and looking at the code as a whole. I've seen a great compact example recently, one of the students I supervised wrote sth like this: List<Person> findBySurname(String surname) { List<Person> persons = session.find(surname); if (persons.size() == 0) return null; return persons; } ... List<Person> persons = findBySurname(surname); for (p : persons) { p.doSth(); } The student wrote both methods, and got rejection from tests because of NPE. He wanted to fix it by adding if (persons != null) { ... } :) this example is easy, but in more complex situations it's easy to do the same, and it adds up. This is one of the reasons I dislike OO programming (especially the kind where you hide everything behind a few layers of interconnected objects). Because it makes it harder to understand what REALLY happens on the data level.
- UK-AL 9y ago
  I think types should not be nullable unless explicitly specified.
  - AstralStorm 9y ago
    That, much like a null check, solves only a special case.

drvdevd 9y ago

I believe this is an easy trap for developers of all skill levels to find themselves in. I imagine the "10x developer" would just be really good at avoiding this kind of thing ... most of the time.

beagle3 9y ago
Yosefk.com has a great article about being 10x more effective by being 10x more selective.
- mfukar 9y ago
  That article is a post-mortem with an awful lot of hindsight. Not everybody would able to ask the questions Yossi identifies in the post-mortem while the requirements are presented. Would somebody then, instead, be able to become 10x more effective by thinking 10x more about their work, before they do it?
  - drvdevd 9y ago
    Personally, I believe there's some level of "intuition" involved, that perhaps some people are just gifted with naturally. I think these people still have to practice though, to build upon that natural ability. Note that I'm certainly not referring to myself here -- I consider myself Just Average. I'm thinking of friends and colleages I've known over the years who have this seemingly natural gift. That being said, I also think everyone can benefit by finding some sweet spot between 'thinking hard up front' and 'analysis paralysis'. For me personally that means start by doing something, then revise and iterate. That's just my cognitive style I suppose.

GreaterFool 9y ago

When I hear 10x programmer I think "10x me". I've worked with a handful people like that over the years and it has been a pleasure. If there's a 10x programmer in my team I know I'm in the right team!

Bahamut 9y ago

There is a huge cost to handwriting SQL too that one mist be careful of - it is very easy to result in poor abstractions as a result of inconsistent apis from lack of abstraction over SQL. My company is currently in the process of moving back to an ORM after 5 years or so abandoning ORM usage due to nightmarish performance using NHibernate in .Net (maybe more of an indictment on the code than anything else, but I don't know the specifics of the history). We found the company had a lot of problems that resulted from handwritten SQL, including lack of ability to adequately abstract the logic for proper unit/integrated testing, and inconsistent data fields being returned by various queries, resulting in inconsistent api endpoint data returned to the client and thus inability to safely abstract without significant hacks/nebulous data model state. The worst thing we encountered with handrolled SQL over ORM was that it actually hindered our ability to deliver major business requirements. We had no ability to gate content by various values from other tables without modifying the handrolled SQL in every single location...not a good situation to be in at all.

fnord123 9y ago
> inconsistent data fields being returned by various queries, resulting in inconsistent api endpoint data returned to the client and thus inability to safely abstract without significant hacks/nebulous data model state. You are coding against actual queries? Why not functions to hide the table abstractions: https://www.postgresql.org/docs/current/static/sql-createfunction.html https://www.postgresql.org/docs/current/static/sql-createfun... https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html https://dev.mysql.com/doc/refman/5.7/en/create-procedure.htm... >We had no ability to gate content by various values from other tables without modifying the handrolled SQL in every single location Again, don't sql functions solve this?
- icebraining 9y ago
  That's essentially building an ORM (well, a data mapping layer) out of PL/SQL functions rather than your main language. Why would that be better?
  - 9y ago

ajuc 9y ago

This is not only about frameworks and ORMs, it's about refusing to comprehensively understand stuff before you use it or change it. It can be any abstractions, even (usually) the ones you created by yourself. It's easier to add a special case check, than to read through the codebase to see if it's even needed, or, God forbid, to refactor in 5 places so it's not needed (it might break sth else!!! I would have to read and keep in memory the whole control flow of the program!!). Programmers have to do dozens such decisions every day, so after a few months if they go the easy way too often it adds up and creates chaos. I've done this myself, and seen this done by younger programmers. It's that crucial skill of stepping a few steps back and looking at the code as a whole. I've seen a great compact example recently, one of the students I supervised wrote sth like this: List<Person> findBySurname(String surname) { List<Person> persons = session.find(surname); if (persons.size() == 0) return null; return persons; } ... List<Person> persons = findBySurname(surname); for (p : persons) { p.doSth(); } The student wrote both methods, and got rejection from tests because of NPE. He wanted to fix it by adding if (persons != null) { ... } :) this example is easy, but in more complex situations it's easy to do the same, and it adds up. This is one of the reasons I dislike OO programming (especially the kind where you hide everything behind a few layers of interconnected objects). Because it makes it harder to understand what REALLY happens on the data level.

UK-AL 9y ago
I think types should not be nullable unless explicitly specified.
- AstralStorm 9y ago
  That, much like a null check, solves only a special case.