I have found somewhat of a mitigation to temporary solutions. (Because it's all temporary solutions until the software dies, amirite?) The mitigation is obvious in principle: write code that allows itself to be easily refactored or replaced. But how? What works for me is to write important decisions as pure functions 1. Important decisions might mean "whether or not to display this element" for front-end work. Or "what things should happen as the result of this request" for back-end. Decide first, then perform side effects (e.g. modify DOM, save to db) separately from decisions, because once you tangle decisions and side effects, the decisions become harder to understand and even harder still to separate out again. I've also found that pattern matching on these kinds of solutions (separating decision from effect) breeds more of the same in a good way.
If you think about it, humans work this way. Your brain makes the decisions first (sometimes subconsciously), then instructs your body to act on them. Unless you are Ash and your hand has a mind of its own. Can't help you there.
I use a particular paradigm (Functional Programming) and languages (F# / Elm) that encourage me write code this way. But it's possible to do in the OO paradigm / languages with some discipline. The discipline becomes easier once you get bitten pretty bad... the value of it starts to become clear. :)
That doesn't automatically fix the mountain of tangled code I already had, though. :(
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have found somewhat of a mitigation to temporary solutions. (Because it's all temporary solutions until the software dies, amirite?) The mitigation is obvious in principle: write code that allows itself to be easily refactored or replaced. But how? What works for me is to write important decisions as pure functions 1. Important decisions might mean "whether or not to display this element" for front-end work. Or "what things should happen as the result of this request" for back-end. Decide first, then perform side effects (e.g. modify DOM, save to db) separately from decisions, because once you tangle decisions and side effects, the decisions become harder to understand and even harder still to separate out again. I've also found that pattern matching on these kinds of solutions (separating decision from effect) breeds more of the same in a good way.
If you think about it, humans work this way. Your brain makes the decisions first (sometimes subconsciously), then instructs your body to act on them. Unless you are Ash and your hand has a mind of its own. Can't help you there.
I use a particular paradigm (Functional Programming) and languages (F# / Elm) that encourage me write code this way. But it's possible to do in the OO paradigm / languages with some discipline. The discipline becomes easier once you get bitten pretty bad... the value of it starts to become clear. :)
That doesn't automatically fix the mountain of tangled code I already had, though. :(