5 ms·

> Agreed, I don't know why the industry (or people?) in general have a problem with accepting this abilities gap. Bias and poor processes. When people become r

> Agreed, I don't know why the industry (or people?) in general have a problem with accepting this abilities gap. Bias and poor processes. When people become reliant upon a technique or process to attain viability that means of execution becomes more important than the thing you are producing. As a result people will defend slow unproductive means of execution to the death. This is also a socially reinforced phenomenon. It is completely realistic to achieve 10x (or even much greater) productivity and it isn’t challenging, but it requires abandonment of closely held ideas that are socially reinforced.

dosethree 5y ago
It's harder to achieve 10x in a vacuum, but if you make 10 engineers twice as productive, there ya go
deleted 5y ago
[deleted]
jimbokun 5y ago
> It is completely realistic to achieve 10x (or even much greater) productivity and it isn’t challenging, but it requires abandonment of closely held ideas that are socially reinforced. OK, you piqued my curiosity. Can you elaborate?
- austincheney 5y ago
  This is completely off the top of my head. Objective quick wins: 1) Less code. The less there is the less there is to debug and maintain. This applies to all code including dependencies, frameworks, abstractions, and decoration in your own code. If abandoning OOP means substantially less code then do it without question. 2) Iterate faster. If you have a build that takes 10 minutes and the next guy has a build that takes less than a minute they can fail 10x more frequently and achieve the same level of productivity. 3) Know your foundations with confidence. Things you rely upon become more of a barrier than a help given a long enough time line (shorter time line that could otherwise imagine). 4) The point of software is automation. If you find you are doing manual curation in the code you are likely wasting your productivity. An investment in better automation returns interest on the initial investment. More opinionated personal preferences: 1) Unless you are writing in a language where you manage access to memory, such as C++ or Rust, abandon OOP. In garbage collected languages like Java, JavaScript, C# it only provides composition. It is a tremendous increase in code that does more harm in troubleshooting. 2) Prefer a statically typed language. As a JavaScript developer I have fallen in love with TypeScript. There are performance benefits to ensuring all primitives are strongly typed, but the developer performance benefits come from typing complex types. This is a quick win for defining execution of microservices and functional programming. 3) Prefer functional programming techniques and code portability. Code is less defective when it is highly predictable and explicit. 4) Save composition for last. Don't worry about how to put things together. Complete each micro-task in isolation, which forces a separation of concerns. Once everything is written putting things together becomes natural and typically works itself out. 5) Avoid pronouns in the code. The pronoun of JavaScript is the keyword this. Don't use it. You don't need it. I have been writing in this language full time for 13 years both at work and for personal projects. In that time I have really needed this only twice. The problem with pronouns is that they aren't clear (in either value or intention) by just reading the code, which takes substantially more time to interpret as a human. 6) Think in writing. You can save some refactoring effort by having a solid execution plan. The best way to plan is write things down as if to explain it to somebody who has no idea. If you cannot even explain it to yourself you won't be able to do in code.
  - jimbokun 5y ago
    Great stuff! > 2) Iterate faster. If you have a build that takes 10 minutes and the next guy has a build that takes less than a minute they can fail 10x more frequently and achieve the same level of productivity. I think this is very under rated. There are so many things that can reduce developer latency (time between making a change to the code and seeing if it works, or deploying to production) is one of the most under rated aspects of software engineering productivity. Most other factors pale in comparison.
charlieflowers 5y ago
Yeah, 10x is really fast. Lots of companies couldn’t bear to go that fast … the rate of change scares them.

dosethree 5y ago

It's harder to achieve 10x in a vacuum, but if you make 10 engineers twice as productive, there ya go

deleted 5y ago

[deleted]

jimbokun 5y ago

> It is completely realistic to achieve 10x (or even much greater) productivity and it isn’t challenging, but it requires abandonment of closely held ideas that are socially reinforced. OK, you piqued my curiosity. Can you elaborate?

austincheney 5y ago
This is completely off the top of my head. Objective quick wins: 1) Less code. The less there is the less there is to debug and maintain. This applies to all code including dependencies, frameworks, abstractions, and decoration in your own code. If abandoning OOP means substantially less code then do it without question. 2) Iterate faster. If you have a build that takes 10 minutes and the next guy has a build that takes less than a minute they can fail 10x more frequently and achieve the same level of productivity. 3) Know your foundations with confidence. Things you rely upon become more of a barrier than a help given a long enough time line (shorter time line that could otherwise imagine). 4) The point of software is automation. If you find you are doing manual curation in the code you are likely wasting your productivity. An investment in better automation returns interest on the initial investment. More opinionated personal preferences: 1) Unless you are writing in a language where you manage access to memory, such as C++ or Rust, abandon OOP. In garbage collected languages like Java, JavaScript, C# it only provides composition. It is a tremendous increase in code that does more harm in troubleshooting. 2) Prefer a statically typed language. As a JavaScript developer I have fallen in love with TypeScript. There are performance benefits to ensuring all primitives are strongly typed, but the developer performance benefits come from typing complex types. This is a quick win for defining execution of microservices and functional programming. 3) Prefer functional programming techniques and code portability. Code is less defective when it is highly predictable and explicit. 4) Save composition for last. Don't worry about how to put things together. Complete each micro-task in isolation, which forces a separation of concerns. Once everything is written putting things together becomes natural and typically works itself out. 5) Avoid pronouns in the code. The pronoun of JavaScript is the keyword this. Don't use it. You don't need it. I have been writing in this language full time for 13 years both at work and for personal projects. In that time I have really needed this only twice. The problem with pronouns is that they aren't clear (in either value or intention) by just reading the code, which takes substantially more time to interpret as a human. 6) Think in writing. You can save some refactoring effort by having a solid execution plan. The best way to plan is write things down as if to explain it to somebody who has no idea. If you cannot even explain it to yourself you won't be able to do in code.
- jimbokun 5y ago
  Great stuff! > 2) Iterate faster. If you have a build that takes 10 minutes and the next guy has a build that takes less than a minute they can fail 10x more frequently and achieve the same level of productivity. I think this is very under rated. There are so many things that can reduce developer latency (time between making a change to the code and seeing if it works, or deploying to production) is one of the most under rated aspects of software engineering productivity. Most other factors pale in comparison.

charlieflowers 5y ago

Yeah, 10x is really fast. Lots of companies couldn’t bear to go that fast … the rate of change scares them.