Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sabotaging projects by overthinking, scope creep, and structural diffing

kevinlynagh.com

Post reply on HN
Print view View original

41–50 of 159 posts

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

#41

Post by abdullahkhalids »

bennettnate5 wrote: post #5

Incidentally, 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…

> 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 them down.

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

#42

Post by bennettnate5 »

wasabi991011 wrote: post #8
bennettnate5 wrote: post #5

Incidentally, 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…

Oh man I feel that in my bones. Any advice on how to mitigate this?

For me, it wasn't so much about mitigating this cycle as much as recognizing that the grit of pushing through that last 20-30% is actually a valuable life skill that the PhD could teach me to do, and that projects that I felt like I would never want to touch again actually started to become interesting again after I had left them for a year or so.

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

#43

Post by ericmcer »

wasabi991011 wrote: post #8
bennettnate5 wrote: post #5

Incidentally, 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…

Oh man I feel that in my bones. Any advice on how to mitigate this?

It seems almost inevitable...

Acknowledge it is normal? Attempt to buy deeper into the delusion ("Yeah my work is awesome and unique!"). Use stimulants to force enthusiastic days every once in awhile?

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

#46

Post by bennettnate5 »

abdullahkhalids wrote: post #41
bennettnate5 wrote: post #5

Incidentally, 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…

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

The usual justification is that if you don't do at least a breadth-first literature review, you can get burned by missing a paper that already does substantially what you do in your work. I've heard of extreme case where it happens a week before someone goes to defend their dissertation!

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

#47

Post by dgb23 »

I'm _exactly_ in this situation right now with a side project.

It's in a field that I have little experience with (Information Retrieval). So there is obviously prior art that I could learn from or even integrate with.

This article motivates me further to learn things by focusing on building my own and peek into prior art as I go, when I'm stuck or need ideas.

Recently a Clojure documentary came out and the approach of Rich Hickey was seemingly the opposite: Deep research of prior art, papers, other languages over a long period of time.

However, he also mentioned that he made other languages before. So the larger story starts earlier, by making things and learning from practice.

Maybe that's also the bigger lesson: Don't overthink, start by making the thing. But later when you learned a bunch of practical lessons and maybe hit a wall or two, then you might need that deeper research to push further.

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

#48

Post by godelski »

wasabi991011 wrote: post #8
bennettnate5 wrote: post #5

Incidentally, 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…

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 aren't yours
  - just because someone had X outcome before doesn't mean you won't get Y outcome
  - those small details usually dominate success
    - sometimes a one liner seemingly throw away sentence is what you're missing
    - sometimes the authors don't know and the answer is 5 papers back that they've been building on
  - DO NOT TREAT PAPERS AS *ABSOLUTE* TRUTH
    - no one is *absolutely* right, everyone is *some* degree of wrong
  - other researchers are just like you, writing papers just like you
    - they also look back at their old papers and say "I'm glad I'm not that bad anymore"
  - a paper demonstrating your idea is a positive signal, you're thinking in the right direction
As soon as you start treating papers as "this is fact" you tend to overly generalize the results. But the details dominate so you just kill your own creativity. You kill your own ideas before you know they're right or wrong. More importantly you don't know how right or how wrong.

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

#49

Post by dgb23 »

haunter wrote: post #26

Funnily this aligns perfectly with the WW2 era CIA Sabotaging handbook https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/... Organizations and Conferences: 1. Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions. 2. Make “speeches,” Talk as frequently as possible and at great length. Illustrate your “points” by long anecdotes and accounts of perso…

This reads like satire!

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

#50

Post by sylware »

Just code using c++ (or in a language with a similar syntax complexity or a massive runtime, java, microsoft rust, etc). It gets even better with ISO regular feature creep: you'll find always a dev to manage to make hard dependent on the latest "standard".

Basically, you will end up dependent on the massive complexity of a compiler due to the syntax complexity, and the cherry on top, thanks to ISO, you'll get feature creep creating a cycle of planned obsolescence around 5 to 10 years.

Oh, sorry, "they" called that "innovation".

Post reply on HN