|
|
|
|
|
|
by rglover
1384 days ago
|
|
|
One of the biggest contributors, arguably, to the mediocrity of modern software is the rejection of the inner voice that says "you can (and should) do better" as "perfectionism." No offense to the author, but imo this is a platitude that has done far more damage than it has good. A few quotes to contextualize the thought (ones that I reference when I try to weasel out of doing something properly): “An important part of making good things—it’s extremely underrated in current day society—is having a critical eye for the things that you’re making and assessing ‘are these things of an appropriate quality, do these live up to the standard of what I’m trying to create?’ That’s why it’s not fun sometimes. But it’s also what enables it to be a peak experience in the end when you succeed.” - Jonathan Blow --- “Doing something quickly is not the same as doing it well.” - John Hegarty --- “Any suppression is regression.” - Kapil Gupta --- “If you walk the path of mastery, you’re going to have to walk it all alone. There is no one who is going to accompany you because no one has been taught that. No one believes that. That’s not in the water and in the food and in the air. You’re basically going to have to breathe a different sort of oxygen.” - Kapil Gupta |
|
|
A bad overall architecture is unmaintainable.
An ugly 30 line pure function that has unit tests and hasn't needed changes in 5 years is just meh. 50 of those ugly pure functions are still not going to break a project. They could be untangled at any time as needed.
50 decent but not great functions are definitely not going to break a project.
So much perfectionism is at the level of functions and variable names. Some makes things worse, when people reinvent nontrivial functionality instead of using widely trusted libraries, like as if work projects are their personal playground of weekend educational stuff.