3. Delete as much code as you can.
14. Use other people's code religiously.
15. Corollary: Most code out there is terrible. Sometimes it's easier to write a better version yourself.
17. Know when to break the rules. For rules like "don't repeat yourself," sometimes a little repetition is better than a bit of dependency.
Well there is of course more gold to dig for where those come from https://matt-rickard.com/reflections-on-10-000-hours-of-programming/.
I will focus this piece on *3 though. One of the things I dread most is the PR process is having the green number too high:
It's crazy hard to go through PR's that spread more than 750 LoC for me if I don't properly allocate time for them. However there those that have red only:
and I feel joy whenever I see them!
Having less code to manage is great. After all, the less code to maintain the better! Here is a perfect example https://github.com/kelseyhightower/nocode - the state we strive for.
I've recently found myself in a situation when I was not sure if some library was being used in the project and instead of doing a simple cmd + f , I have gone on a hunt for a package.
Behold the power of static analysis and code inspection! With:
You will know exactly what to get rid of (oh and trust me you will find artefacts that were meant to be deleted but have somehow evaded the hangman for months!) Just be careful as the "exactly" part may be somewhat misleading if you don't set it up properly - see below for some migrations it was suggesting getting rid of. As with any tool remember you are the captain of this ship, so control your steering wheel!