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

Doing too much work on one's own before looping in others

thezbook.com

Post reply on HN
Print view View original

361–370 of 395 posts

Re: Doing too much work on one's own before looping in others

#361

Post by watwut »

Ensorceled wrote: post #334
watwut wrote: post #308

Earlier quoted context omitted.

> Caveat ... truly stuck ... tried a couple of things, googled, tried some more ... wondering what to try next. That is not even possible within 5 minutes. I would not want to work there honestly. Just being unable to solve problems demotivates me. It sounds like I will get off everytime I am slightly slower to pick something. This would be too stressful for me.

Yeah, you missed the point. You don't need to solve the problem in 5 minutes. You need to be 5 minutes in a state where you have no idea what to do next. Why would you want to be sitting there spinning your wheels? Most people find that feeling of helplessness demotivating and stressful which is why I created the rule.

Because, when I don't know what to do for 5 minutes, there is super high chance I will figure it out within reasonable time still.

Giving up after 5 minutes of not knowing what to do is absurd.

> Most people find that feeling of helplessness demotivating and stressful which is why I created the rule.

Your rule is making people helpless, it makes them think slight stuck means they can't do it. So they will forget how to solve problems and will end up limited to do only simple straightforward tasks.

Re: Doing too much work on one's own before looping in others

#362

Post by rtikulit »

TameAntelope wrote: post #358
rtikulit wrote: post #357

Earlier quoted context omitted.

This may be true if you have no aspirations for your software beyond what your customer can imagine in the present. Almost seems like a methodology that has internalized learned helplessness.

If you think the process I'm describing here is, "Ask customer what they want, do exactly what they say." then I'm not being very clear. "Don't assume that your team should build what it's told to build. Instead assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team's job is to take those ideas, test them , and learn what you should really build." [0] That's your…

Actually, "my" team's job is 1/2 asking the customer, and 1/2 not asking the customer so we can invent stuff they haven't thought of and ideally can't/won't think of.

I think the reason people aren't fully agreeing with you is that there's a lot of important stuff where a quick iterative cycle in front of a customer eliminates the possibility of high-value outcomes.

Re: Doing too much work on one's own before looping in others

#363

Post by TameAntelope »

rtikulit wrote: post #362
TameAntelope wrote: post #358

Earlier quoted context omitted.

If you think the process I'm describing here is, "Ask customer what they want, do exactly what they say." then I'm not being very clear. "Don't assume that your team should build what it's told to build. Instead assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team's job is to take those ideas, test them , and learn what you should really build." [0] That's your…

Actually, "my" team's job is 1/2 asking the customer, and 1/2 not asking the customer so we can invent stuff they haven't thought of and ideally can't/won't think of. I think the reason people aren't fully agreeing with you is that there's a lot of important stuff where a quick iterative cycle in front of a customer eliminates the possibility of high-value outcomes.

That's only true if you're interacting with your customer in some weird, subservient way that has nothing to do with anything I've said at all.

The point you're trying to make isn't the novel insight I think you're trying to present it as. Of course you don't just build what your customer asks for blindly, of course you design with the future in mind, none of that is precluded whatsoever by iterating quickly to provide value and test what your customer needs.

Re: Doing too much work on one's own before looping in others

#364

Post by lukas099 »

beerandt wrote: post #264
rockemsockem wrote: post #240

Earlier quoted context omitted.

Lol, you think physical engineers don't throw together prototypes that they know won't be good enough for the final design just to get everything working together?

They do a preliminary design. They don't throw up some 2x4s and corrugated aluminum to use as a building in the meantime while doing a real design. Or they iterate designs and prototype manufactured products. They do not stamp and accept professional liability for thrown-together designs that bosses want to prematurely push out the door into production. They tell the boss to budget them what's needed, or go find some…

But the difference between preliminary design and final product is much smaller in software than in building, so the cost of making an actual working prototype during the early phases is much less.

Re: Doing too much work on one's own before looping in others

#366

Post by alexashka »

jraph wrote: post #341
alexashka wrote: post #339

Earlier quoted context omitted.

Your anecdotal evidence and personal preference is irrelevant in a discussion about statistics.

Do you have statistics on the matter?

Yes. It may shock you, but there are highly educated, intelligent people on the internet and elsewhere.

There are also people who don't know how much they don't know.

Re: Doing too much work on one's own before looping in others

#367

Post by baby »

e12e wrote: post #327
baby wrote: post #234

Earlier quoted context omitted.

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input. I believe this is why books most often have a single author. A solution to t…

> I believe this is why books most often have a single author. ... And at least one editor, no?

I see the editor as the code reviewer :p

Re: Doing too much work on one's own before looping in others

#368

Post by sunny3 »

Kaze404 wrote: post #253
Trasmatta wrote: post #53

I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constantly need to get feedback and buy-in from other people, and takes away a lot of the creativity and joy in programming (for me). Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think th…

> It's disempowering to feel like you're never able to make a decision yourself, despite supposedly being hired for your expertise in the field. I'm going through exactly this at the moment. For reasons HN will probably consider fiction, my superiors have started treating me as a toddler that needs oversight on every single decision that needs to be made. It's something I've been dealing with in therapy, and the way…

I think I'm in a similar situation and try to find out how to cope with it. The strategy I'm thinking about is - realizing what's happening (as you have articulated wonderfully), anchoring my self-worth else where (writing code / designing original solutions -> pushing what ever that's being discussed by those 3 people to an executable conclusion), finishing and delivering this project asap.

I guess the next step for me is to figure out how to avoid going into such situations (I entered the situation because I was joining a team in an area that I wasn't familiar with and decided to work on an existing project whose owner has a very strong presence and I didn't clarify the specific work item / boundaries clearly in the beginning).

Re: Doing too much work on one's own before looping in others

#369

Post by sunny3 »

nitrogen wrote: post #336
anonymoushn wrote: post #222

Earlier quoted context omitted.

let's have a meeting about how to break down our investigation of the unexplained segfaults in nginx that occasionally happen in our cdn into chunks that deliver value daily!

This is really not that hard: "Yesterday I looked for correlations between segfaults and hardware vendors. I did not find a correlation, and my deliverable for the day is narrowing the search space. Today I will set up a micro cluster of random traffic to try to reproduce the crash. Tomorrow I will look for patterns in request bodies and stack traces."

Seriously, I feel you should write a blog post about this types of reporting strategies that describe the work that are both accurate and palatable to management (and perhaps most importantly avoid despise from other developers).

Re: Doing too much work on one's own before looping in others

#370

Post by Treblemaker »

TameAntelope wrote: post #218
yibg wrote: post #204

Earlier quoted context omitted.

For larger pieces of work, some times it takes me more than a day to just figure out what's where and where I can even get started. I guess I can still give updates daily, but it'll just be "still investigating". Hell, I've fixed 1 liner bugs that have taken me a week to figure out.

You shouldn't be figuring any of those things out on your own, is the whole point of both the article and my comment.

How many times do I need to go down this path:

  ...
  - ask for help
  - try to explain how it's supposed to work
  - try to explain how it's not working
  - Listen to them come up with all the ideas that I've already ruled out
  - Try to explain why their preferred idea has already been
    ruled out or is not actually relevant to the problem
  - conclude they still don't understand the problem or even
    how this part of the system works
  - go ahead and just solve the problem myself
  ...
before it's OK to stop "asking for help", and just fix the damn thing?
Post reply on HN