4 ms·

Yes the author strikes me as a early/mid career SWE rather than a seasoned professional (10K hours is often used as an allusion to "mastery"). 1. Junior: hack

Yes the author strikes me as a early/mid career SWE rather than a seasoned professional (10K hours is often used as an allusion to "mastery"). 1. Junior: hack a solution from A to B by any means necessary 2. Mid-level: wait, design matters. Abstract everything up front! 3. Expert/mastery: wait, complexity also matters. Consider many paths and finds sweet spot that is simple, robust, extensible, maintainable.

ilrwbwrkhv 2y ago
I think the intermediate level, do the refactoring first, clean code mentality is a big one to grow out of. The ultimate mastery is to think about "what does the computer need to do?" If there is a button click and some data has to be aggregated, those are two operations that should result in two blocks of code changing, the event handler and the db select group by (or other data source). Everything else beyond it is extraneous code and you should think very carefully if you are adding any line beyond that. The worst in the typescript world is elaborate types which do not work all of the time. Better to have implicit types doing most of the heavy work and remember you are building software, not doing type system research.
- jakelazaroff 2y ago
  For me, the most important thing in this situation is coupling. The code implementing a feature may be an ungodly mess, but by minimizing its coupling to the rest of the system I make it easy to improve (or remove) later. I would much rather have messy and confusing code that is self-contained than an elegant abstraction with a large blast radius.
  - hinkley 2y ago
    And you do that decoupling by… Refactoring. So I’m a little confused about why it sounds in this whole thread like we are vilifying refactoring without actually saying we are doing so. It’s weird.
    - pphysch 2y ago
      Refactoring "up front" is what people are taking issue with. It's extremely rare to have a project where you know every requirement and they never change "up front" before writing any code.
      - hinkley 2y ago
        Either Fowler’s 2nd edition made some pretty big changes I’m unaware of, or we are all using very different definitions of Refactor. Do you guys mean “redesign”? Because that’s a very different word from “refactor”.
    - jakelazaroff 2y ago
      No, I’m talking about the first time I write something. At that point in the game, my highest priority is to minimize the coupling between that code and the rest of the system (rather than, say, performance).
valval 2y ago
The article reads a bit like those blog posts from junior developers in third world countries who are trying their hardest to prove that they’re capable developers who know what they’re doing, in order to make it out of their current situation.

ilrwbwrkhv 2y ago

I think the intermediate level, do the refactoring first, clean code mentality is a big one to grow out of. The ultimate mastery is to think about "what does the computer need to do?" If there is a button click and some data has to be aggregated, those are two operations that should result in two blocks of code changing, the event handler and the db select group by (or other data source). Everything else beyond it is extraneous code and you should think very carefully if you are adding any line beyond that. The worst in the typescript world is elaborate types which do not work all of the time. Better to have implicit types doing most of the heavy work and remember you are building software, not doing type system research.

jakelazaroff 2y ago
For me, the most important thing in this situation is coupling. The code implementing a feature may be an ungodly mess, but by minimizing its coupling to the rest of the system I make it easy to improve (or remove) later. I would much rather have messy and confusing code that is self-contained than an elegant abstraction with a large blast radius.
- hinkley 2y ago
  And you do that decoupling by… Refactoring. So I’m a little confused about why it sounds in this whole thread like we are vilifying refactoring without actually saying we are doing so. It’s weird.
  - pphysch 2y ago
    Refactoring "up front" is what people are taking issue with. It's extremely rare to have a project where you know every requirement and they never change "up front" before writing any code.
    - hinkley 2y ago
      Either Fowler’s 2nd edition made some pretty big changes I’m unaware of, or we are all using very different definitions of Refactor. Do you guys mean “redesign”? Because that’s a very different word from “refactor”.
  - jakelazaroff 2y ago
    No, I’m talking about the first time I write something. At that point in the game, my highest priority is to minimize the coupling between that code and the rest of the system (rather than, say, performance).

valval 2y ago

The article reads a bit like those blog posts from junior developers in third world countries who are trying their hardest to prove that they’re capable developers who know what they’re doing, in order to make it out of their current situation.