For further actions, you may consider blocking this person and/or reporting abuse
Read next
Music of the Month β What are you listening to? (Halloween Edition π)
Michael Tharrington -
C# { get; init; }
Baltasar GarcΓa Perez-Schofield -
20 JavaScript Tricks Every Developer Must Know π
Jagroop Singh -
JavaScript Memory Management and Optimization Techniques for Large-Scale Applications
Shafayet Hossain -
Top comments (57)
I'm quite fond of the "ninety-ninety rule", it's so true and so heartbreaking.
In computer programming and software engineering, the ninety-ninety rule is a humorous aphorism that states:
I can't think of any other's Ben. You nailed it.
I always heard that as the 80-20 rule.
Thatβs a different rule
The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes.
Recently I discovered that if you run "import this" on a python shell you get this beauty:
A function (or method) should do one thing, and do it well.
I like seeing this applied on the macro level too. ie keeping a command line tool specialised to doing one specific task very well.
You'd be surprised at how god-damn much those command line tools actually do.
Also Google's rule for browser extensions, each extension should do one thing.
This is an idiom which sounds nice but cannot be applied, due to the underspecificity of both "one thing" and "well". It is as meaningless as the following function signature:
Oh, there are so many. One of my favorites, though, comes from Fred Brooks:
You know Brooks from Brooks's Law:
Oof, some old managers/owners needed to hear those
YAGNI: you aren't gonna need it
Need a mug with this on it for retros. Some coworkers want the kitchen sink "in case our app grows bigger."
I only actually heard this aphorism a few years ago (although the original quote is from far earlier). But it's amazing how often I think of it now. Obtuse, hard-to-follow code can often be "magically" transformed by applying the proper descriptive names to the variables / methods / functions / classes / etc. And yet, it can often be soooooo difficult, when you're writing the code for the first time, to settle on just the "perfect" names that will render the code clear and self-explanatory.
Small code duplication is better than a bad abstraction
"Perfectionism can motivate you to become good. But it will destroy your ability to become great" - Joel Klettke.
There's no single favorite. But a few:
They are generic and didn't originate with software, but I think they are very applicable.
The first one feels like, one should not touch it if it works, but bad code still needs to be refactored.
I think it depends on the situation, refactoring for the sake of it may not be worth the effort. If it works and you won't have to touch it or worry about its performance, it can be left alone. If it is a commonly used piece of code and it is causing problems when building features, then that is a good time to refactor it.
Ofc, it depends, but I would build my mind around refactoring the bad code, rather then thinking not to touch it, unless its broken π
Some comments may only be visible to logged-in visitors. Sign in to view all comments.