upvote

points

by tra322 hours ago |
comments
upvoteby zoogeny17 hours ago|
next
[-]
A saying I've come across is: "Don't let perfect be the enemy of good"

I had a coworker who would always be diplomatic about code changes he felt could be improved but when he felt he was nitpicking, where he would say: It's better than it was. It allowed him to provide criticism while also giving permission to go ahead even if there were minor things that weren't perfect. I strongly endorse this kind of attitude.

reply
upvoteby flutas16 hours ago|
parent|
next
[-]
Hmm, in every team I've been in (only 3 tbf) we almost all followed the "nit" approach for PRs.

    nit: this could be changed to XYZ
vs

    we should use XYZ here
where it was understood nits could be ignored if you didn't feel it was an urgent thing vs a preference.
reply
upvoteby zoogeny16 hours ago|
parent|
next
[-]
It's worth noting that this is a kind of different "nit" than something that might be attached to a line of code. Like, someone might "nit" using a bunch of if statements where a switch statement might work, or if someone uses a `for each` where a `thing.map` would do.

What I am describing would be something higher level, more like a comment on approach, or an observation that there is some high-level redundancy or opportunity for refactor. Something like "in an ideal world we would offload some of this to an external cache server instead of an in-memory store but this is better than hitting the DB on every request".

That kind of observation may come up in top-level comment on a code review, but it might also come up in a tech review long before a line of code has been written. It is about extending that attitude to all aspects of dev.

reply
upvoteby lazyasciiart10 hours ago|
parent|
[-]
I had someone reject my code that improved/regularized half a dozen instances of a domain object we had, where they were showing up in code paths I cared about. He said there’s dozens of these, don’t submit this unless you fix them all.
reply
upvoteby YZF9 hours ago|
parent|
[-]
I had something similar but convinced the other person the rest of the work can be done later. Then the person went ahead and did it despite the other instances having no use/value. Go figure. I guess having consistency has some value to argue the other side. I tend to be extremely flexible in terms of allowing different ways of doing things but some seem to confuse form with function insisting on some "perfection" in the details. I think this is partly why we get these very mixed reactions to AI where LLMs aren't quite "right" (despite often producing code that functions as well as human written code).
reply
upvoteby strogonoff4 hours ago|
parent|
[-]
Consistency reduces the mental cost of acquiring and maintaining an understanding of a system. In a real sense, moving from one approach to two different approaches, even if one of them is slightly better than the original one, can be a downgrade.
reply
upvoteby YZF9 hours ago|
parent|
prev|
[-]
But then you end up with nit inflation, people feel like they need to fix the nits, and do, and there's no meaning to nit any more. I try to just not comment unless I feel there is some learning from the nit.
reply
upvoteby jiggawatts17 hours ago|
parent|
prev|
[-]
I have a crippling guilt about not keeping my apartment as spotlessly clean as my parents did theirs, to the point that I end up procrastinating, which just makes it worse.

The trick to overcoming this is not to aim for "clean" but for "cleaner than before".

Just keep chipping away at it, whether it is a messy codebase or a messy kitchen.

reply
upvoteby zoogeny16 hours ago|
parent|
next
[-]
I use it for cleaning all the time. Whenever I have dishes, I always give myself permission to do as little as I want knowing that one clean dish is better than nothing. Most often I end up doing them all.

The other saying I say is "completion not perfection". That helps me in yard work especially. I'm not going for the cover shot of "Better Homes and Gardens", I just need the lawn to be cut.

reply
upvoteby Waterluvian16 hours ago|
parent|
prev|
[-]
I call it “sweeping back the desert.”

The sand blows in endlessly. You don’t aim for a pristine, sandless land. But you can’t ignore it or it takes over.

I’ll just pick up a few things and ferry them towards their “home.” Or go do a small amount of yard work. Etc.

reply
upvoteby YZF9 hours ago|
parent|
[-]
weeding the garden is another analogy.
reply
upvoteby nonethewiser19 hours ago|
prev|
next
[-]
It's perfectionism.

I always thought perfectionism meant extremely high achievements (for too great of a cost). But it can also be quitting without any progress because you can't accept anything less than perfect (which may or may not be achievable). Perfectionism can be someone procrastinating on a large task.

reply
upvoteby astrobe_5 hours ago|
prev|
next
[-]
The thing is, "better" is an ambiguous word. I can change a program in some way and make it smaller. I can change it in some other way and make it faster. Both are "better", but in different ways. More often than not, however, you can't have both smaller and faster - or else your are just fixing a performance bug. Often even improving one property makes some other property less good, as you can see in the numerous "pick two" rules.

So "better" means "more specialized" more often that it means "more optimized". I don't say it is a bad thing per se, but it is best to keep in mind that they are two types of improvement, fixes and specializations, because the latter is a commitment.

reply
upvoteby tt_dev22 hours ago|
prev|
[-]
Obama - what a time to be alive
reply