[k__]

Some stuff I learned:

Don't write/use abstractions you won't understand later. Often you start with 2-3 copies, try to merge them and end up using it at a place were it doesn't fit 100% anymore.

Keep nesting low. Often it's faster to scroll over one big okay-ish structured function than to find all the clean tiny things around the the project. Same goes with Objects/Classes/Components etc.

Stop using abbreviations and try to write code more readable and not as short as possible. IDEs help with autocompletion and code gets read more than written anyway.

[ethbro]

> Keep nesting low.

This so much. One of the bigger differences between academic and professional coding is software system longevity.

Premature refactoring is incredibly harmful to readability.

1. You have no idea what the future will require. You will always know more about the requirements in the future.

2. You have no idea how the current use and system will need to evolve. You will always learn more about this in the future.

3. You have no idea how long the current system will be used. Could be 20 years; could be a week (if it's an executive's pet project).

4. Time to MVP > perfect code in almost all instances.

Writing code with clean, documented potential refactoring points, but stopping short of actually pulling all those things apart has served me far better than the alternative.

If you have one function that may not be applicable to a future use case, and you refactor it into two, now you have two functions that may not be applicable to a future use case.

Develop a feel for what's "reasonable" in an initial write, and don't code yourself into an inflexible corner, but defer actual refactoring until it's necessary. Because then you'll have the benefit of knowing far more about the new needs and how the system is used.

[nhteou79snt]

> Premature refactoring is incredibly harmful to readability.

Is that a thing? If it is, I've never run into it. I always run into the opposite - never refactoring and everything turning into a god object. It never occurred to me that premature factoring would be bad because I can't recall ever running into it!

[cstrahan]

I've seen plenty of this. The most common offenders are junior to mid-level developers who, in the pursuit of attaining the trappings of sophistication, cargo cult various patterns without understanding the original rationale behind those patterns, nor when they should be applied. What they fail to realize is that needless indirection is not the same as useful abstraction.

Think what you will of Zed Shaw, but he actually has a pretty good piece on how indirection and abstraction get mixed up:

https://zedshaw.com/archive/indirection-is-not-abstraction/

[k__]

Haha, interesting.

I always assumed abstraction was only a special case of in direction. Indirection on a meta level.

Like loops are abstractions for jumps, but this means that you "indirectly" use jumps when using loops.