I think this should've been two separate blog posts.
Kind of hilarious though that it talks about scope creep and then transitions into a whole different long topic.
Sabotaging projects by overthinking, scope creep, and structural diffing
81–90 of 159 posts
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#82In one of his speeches, Obama said "Better is good". I think about this a lot. It feels like better compounds over time, too. Small improvements add up. From experience, nothing new is perfect the first go round, so sitting around trying to come up with a perfect design is counterproductive because there's no such thing. "impediment to action advances action. what stands in the way, becomes the way".
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.
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.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#83Earlier quoted context omitted.
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.
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.
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.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#84For someone who says they are overcome by scope creep, they sure do seem to get a lot done — so many linked articles on all sorts of topics at the end of the post.
I think the author is indeed someone who just really enjoys learning and doing all sorts of things, so the rabbitholing is part of the fun that tickles their brain.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#85Incidentally, this describes what I believe to be the great difficulty of PhD research. You have to take a topic you find interesting and read all possible related work in it, which tends to result in significant scope creep as you realize just how much there is that already does you want to do. Having exhausted your initial energy and excitement for the project, you have to force yourself the remaining 20-30% of he…
This, all while battling the increasingly heavy burden of regret towards having started a PhD in the first place.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#86In one of his speeches, Obama said "Better is good". I think about this a lot. It feels like better compounds over time, too. Small improvements add up. From experience, nothing new is perfect the first go round, so sitting around trying to come up with a perfect design is counterproductive because there's no such thing. "impediment to action advances action. what stands in the way, becomes the way".
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.
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
we should use XYZ here
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#87Earlier quoted context omitted.
> You have to take a topic you find interesting and read all possible related work in it This is definitely the wrong way of going about a research project, and I have rarely seen anyone approach research projects this way. You should read two or at most three papers and build upon them. You only do a deep review of the research literature later in the project, once you have some results and you have started writing…
Unless you're already an expert in the topic a literature search is literally step 1 since you have to check if your idea has already been done before.
That's where your supervisor comes in. In most cases, they should be an expert in the field, and guide you towards a useful and novel problem.
Moreover, I am not suggesting you don't look at other papers at all. But google scholar and some quick skimming of abstracts and papers you find should suffice to check if someone has already done the work. If you start fully reading more than a handful of papers, your ideas are already locked in by what others have done, and it becomes way harder to produce something novel.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#88Earlier quoted context omitted.
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.
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.
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.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#89Earlier quoted context omitted.
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.
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.
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.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#90Earlier quoted context omitted.
Oh man I feel that in my bones. Any advice on how to mitigate this?
Switch back and forth between trying and reviewing. Often it can be good to just try before reviewing, to get your feet wet. Don't spend too much time. Then when reviewing you're going to understand it more. Repeat this process. But there's some things to remember that are incredibly important - a paper doesn't *prove* something, it suggests it is *probably* right - under the conditions of the paper's settings, which…
Your bullet points explain most of the replication crisis, from my perspective.