Live data from Hacker News

Sabotaging projects by overthinking, scope creep, and structural diffing

kevinlynagh.com

31–40 of 159 posts

Re: Sabotaging projects by overthinking, scope creep, and structural diffing

#31
i feel a lot are missing the point here of identifying the "why" in why you want to build a project.

do you want to learn a new skill? do you want to scratch a very specific personal itch for just yourself? do you want to solve problems for others as well? do you want to build a startup/business around the idea?

all of these necessitate different approaches and strategies to research and coding. scratching an itch? maybe fully vibe coding is fine. want to learn? ditch the vibes and write by hand and ignore prior art. want to build a business? do some actual market research first and decide if this is something you actually want to pursue.

this post was a good reminder for me to identify the why as early on as possible and to be ok with just building something for myself without always having to monetize a side project which, for me, just zaps all joy from it.

Re: Sabotaging projects by overthinking, scope creep, and structural diffing

#32
Our 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 and waste time.

Re: Sabotaging projects by overthinking, scope creep, and structural diffing

#34
In 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".

Re: Sabotaging projects by overthinking, scope creep, and structural diffing

#35

Earlier quoted context omitted.

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…

It's been a long long time since I was the academic research world - but isn't 3 published papers pretty much the expectation for a PhD quantity of research?

Really depends on the field. Computer science research usually has pretty short cycle times. If you're working on, say, biology or anthropology, collecting data can take substantially longer.

Re: Sabotaging projects by overthinking, scope creep, and structural diffing

#36
post #34

In 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".

Obama - what a time to be alive

Re: Sabotaging projects by overthinking, scope creep, and structural diffing

#37
Firstly - Greetings! It’s so rare to see a Clojure person in the wild! and secondly, I really resonated with this! it feels like we, computer programmer, typically overthink too much to begin with, and then LLMs come along and actually help us overthink even more!

Re: Sabotaging projects by overthinking, scope creep, and structural diffing

#38

Earlier 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…

This is spot on. My dad was a professor and had dozens of PhDs. The only thing differentiating them (as I remember him telling me) was the resolve to keep work as /tiny/ as possible. Who is remember for his/her PhD? Only the smallest cream of the crop. He even made good fun of worthless thesis by (then) well known professors. It’s not about your PhD.

When I did my MSc thesis he told me it was a pretty good PhD. (Before giving me a months work in corrections.) I didn’t understand back then, but I understand now. It was small, replicatable and novel (still is)! Just replicate three times and be done with it. You’ve proven your mastery. Now start something serious.

Re: Sabotaging projects by overthinking, scope creep, and structural diffing

#39
Sabotage is intentional, but the problem is unintended excursions, which is endemic to any scouting.

The real problem is avoidance, when cuts are warranted and you don't want them, so you ... hide, often by working hard on something else.

The solution is to value your time. Most don't, so (self-) managers instead need to dangle other opportunities: finish this so you can do that. You can't take candy from a baby without trouble; instead, you trade for something else.

Re: Sabotaging projects by overthinking, scope creep, and structural diffing

#40

Over planning and scope creep are a problem, but let's not swing the pendulum to far the other way. Some of my most successful projects were projects where I planned out and worked through most of the features ahead of time through the process of modeling my data without any working software to try out. When I'm in that phase, I often don't really know what is too much. If I leave out features I think I or the users…

I think the ideal solution is to spend a lot of time in the analysis phase to load your brain up with the correct context, but then be ready to throw out the overengineered solution and just build what feels right.

Don't fall prey to sunk cost fallacy. Just because you spent hours researching a PhD level topic doesn't mean you now have to use it in your project, if it's not quite the right application.

Post reply on HN