Experienced this building a decision support framework - started simple, ended up with dual architecture and 18 languages. Sometimes scope creep reveals the real problem you're solving.
Sabotaging projects by overthinking, scope creep, and structural diffing
111–120 of 159 posts
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#112Earlier 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.
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.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#113Earlier quoted context omitted.
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 o…
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.
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).
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#114Earlier quoted context omitted.
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.
weeding the garden is another analogy.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#115Our CEO at Rec Room put this a way I really like, "Teams are always telling me they wish they did shorter projects. I've almost never heard a team say, 'we wish we delayed launch, did something more complex, polished more'" I don't think it holds in 100% of situations but I do think if you're going to make an error one way or the other, I'd rather do something smaller and release too early than do something bigger an…
There's features and there is quality and there is domain.
I worked on a team that built high precision industrial machinery. The team and the project manager decided to delay shipping because there were still problems. We delayed, fixed the problems, and the machine worked really well and was used for at least a decade. If we'd had shipped it too soon we would have to try and fix it at a remote site and likely it would suffer from problems.
With most products you want to figure out what is your MVP (minimal viable product) and what is the quality level your customers expect. If you ship something less than that it's probably not a good tradeoff. If you build too much and ship too late that's also not a good tradeoff. When shipping increments they also need to be appropriately sized and with the right quality level.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#116Earlier quoted context omitted.
Oh man I feel that in my bones. Any advice on how to mitigate this?
I worked at a chair for 12 years - in that time I've seen a lot of PhD students go through this. If it helps anything at all: It's normal. At this point, you've already proven you're smart and knowledgeable. Now, the universe wants to see if you can also finish what you've started. That's the main thing a PhD proves: That you can take an incredibly interesting topic and then do all the boring stuff that they need you…
Technical feedback yes, but always reject any career feedback from your advisor since the data shows it's unlikely a good model for future career success
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#117[dead]
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#118I think the author is really just getting at the fact that humans are by nature intelligent and by nature tend to think of similar ideas. So you can either unknowingly complete a project which is inevitably in some sense a replication of another project, or you can do the research first and realize it's partially a replication which is a bit disheartening. I think the solution might lie in realizing that completing a…
We all just need a little more sodium in our diets.
We all just need a little more iodine in our sodium.
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#119[dead]
Re: Sabotaging projects by overthinking, scope creep, and structural diffing
#120In 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".
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.