How individual contributors get stuck (2017) • Hacker News Board

Re: How individual contributors get stuck (2017)

#91

Post by Aqueous » Thu, Jun 30, 2022, 7:15 PM UTC

cecilpl2 wrote: post #16

Aqueous wrote: post #6

When I've gotten stuck it's usually because the previous engineer completely screwed up the data structure design and in doing so made it impossible to change. This boxes me in because I can't implement the feature in an architecturally sound way without a significant refactor. This has happened to me many times.

Please take this the right way, but blaming your predecessors is not a productive mindset, nor is it really the topic of this post.

Data structures being badly designed is a perfectly valid and common blocker. That is why we try to design things correctly, after all - to avoid blocking future engineers when they try to change the system. Badly designed data structures can make a system impossible to extend. Regardless of who is to blame, we need to call such things out so that people actually pay attention to data design in the future, and avoid things that are extremely costly but necessary to fix. So I'd say it is productive to point it out.

Re: How individual contributors get stuck (2017)

#92

Post by [deleted] » Thu, Jun 30, 2022, 8:05 PM UTC

ska wrote: post #44

Aqueous wrote: post #6

When I've gotten stuck it's usually because the previous engineer completely screwed up the data structure design and in doing so made it impossible to change. This boxes me in because I can't implement the feature in an architecturally sound way without a significant refactor. This has happened to me many times.

[narrator] The previous engineer was themself, 18 months ago. I turns out that usually (not universally!) the problem isn't that the previous person did a bad job, but rather that they made a set of tradeoffs that made sense at the time, and make less sense now. Or it could be that you work with uncharacteristically incompetent engineers, but that's not the first place to look.

[deleted]

Re: How individual contributors get stuck (2017)

#93

Post by [deleted] » Thu, Jun 30, 2022, 8:07 PM UTC

ska wrote: post #44

Aqueous wrote: post #6

When I've gotten stuck it's usually because the previous engineer completely screwed up the data structure design and in doing so made it impossible to change. This boxes me in because I can't implement the feature in an architecturally sound way without a significant refactor. This has happened to me many times.

[narrator] The previous engineer was themself, 18 months ago. I turns out that usually (not universally!) the problem isn't that the previous person did a bad job, but rather that they made a set of tradeoffs that made sense at the time, and make less sense now. Or it could be that you work with uncharacteristically incompetent engineers, but that's not the first place to look.

[deleted]

Re: How individual contributors get stuck (2017)

#94

Post by Aqueous » Thu, Jun 30, 2022, 8:11 PM UTC

ska wrote: post #44

Aqueous wrote: post #6

When I've gotten stuck it's usually because the previous engineer completely screwed up the data structure design and in doing so made it impossible to change. This boxes me in because I can't implement the feature in an architecturally sound way without a significant refactor. This has happened to me many times.

[narrator] The previous engineer was themself, 18 months ago. I turns out that usually (not universally!) the problem isn't that the previous person did a bad job, but rather that they made a set of tradeoffs that made sense at the time, and make less sense now. Or it could be that you work with uncharacteristically incompetent engineers, but that's not the first place to look.

It was, in fact, not me.

And the tradeoffs did not make sense. This was a simple case of bad normalization - a missed many to one relationship. It just so happens that it happened to be a relationship at the center of a very large platform, and is baked through many services. And without fixing it early-ish, we'd be fighting the schema for the next 10 - 20 years and creating unmanageable complexity in the process, all the while making it harder for ourselves to eventually fix it.

So I'm just pointing out something factual. Sometimes making sure something doesn't happen again means calling a spade a spade. If that means pointing out a mistake, then we absolutely should.

Re: How individual contributors get stuck (2017)

#95

Post by bcbrown » Fri, Jul 01, 2022, 3:14 AM UTC

itsmemattchung wrote: post #72

bcbrown wrote: post #70

Earlier quoted context omitted.

My office used to be right by the local art museum, and I was a member. Whenever I felt stuck, I'd go take a half hour to look at art, and usually a solution would quickly come to mind.

I'm seriously intrigued by how the unconscious mind works as it relates to problem solving. Anybody here have recommendations to literature that digs into this beautiful phenomenon of taking breaks/walks resulting in the answer manifesting itself?

It's not scientific literature, but I got the inspiration from the book "Pragmatic Thinking and Learning".

Re: How individual contributors get stuck (2017)

#96

Post by ska » Sat, Jul 02, 2022, 12:48 AM UTC

Aqueous wrote: post #94

ska wrote: post #44

Earlier quoted context omitted.

[narrator] The previous engineer was themself, 18 months ago. I turns out that usually (not universally!) the problem isn't that the previous person did a bad job, but rather that they made a set of tradeoffs that made sense at the time, and make less sense now. Or it could be that you work with uncharacteristically incompetent engineers, but that's not the first place to look.

It was, in fact, not me. And the tradeoffs did not make sense. This was a simple case of bad normalization - a missed many to one relationship. It just so happens that it happened to be a relationship at the center of a very large platform, and is baked through many services. And without fixing it early-ish, we'd be fighting the schema for the next 10 - 20 years and creating unmanageable complexity in the process, al…

I wasn't really suggesting you were. I was pointing out that your described situation is actually pretty rare. Your opening " ... it's usually ..." suggested the anecdote you offered generalized easily, but that isn't true.

Re: How individual contributors get stuck (2017)

#97

Post by hyperpallium2 » Sat, Jul 09, 2022, 2:53 AM UTC

bradstewart wrote: post #71

hyperpallium2 wrote: post #53

Earlier quoted context omitted.

It may be that "being stuck" is "uploading the problem and interconnections"... a necessary pre-condition for the walk, the shower etc to work. It could be that one is stuck longer than necessary for uploading... or it could be that one is only able to let go when uploading is complete... What evidence would show which it is?

You're on to something here. If I had some signal that indicated "sufficient information uploaded, algorithm running" it'd be easy to stop. But the (obvious) problem is that signal is, usually, the discovery of the solution. Which happens well after all the being stuck. There is something comforting about accepting that banging my head against a wall might just be a requirement of figuring the thing out, though.

"Banging your head" usually means lots of trial and error, that is all error. But beyond uploading information, every experiment creates new information. ("I haven't failed - I've discovered 1,000 ways that won't work!" https://quoteinvestigator.com/2012/07/31/edison-lot-results/)

When the search space is exponential, with too many combinations to try, pruning off a branch is enormously helpful (and perfectly harmless... provided the solution doesn't happen to lie on that branch - those are my most stuck times).

One signal is when I can't think of anything else to try - that means I've extracted all the information I can. The trouble is, I'm pretty good at thinking of things to try.