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

371–380 of 395 posts

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

#371

Post by Kaze404 »

sunny3 wrote: post #368
Kaze404 wrote: post #253

Earlier quoted context omitted.

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

Seems like you got a plan! How to avoid this situation in the future is also something I've talked about in therapy, and while I haven't reached a conclusion on that, a major takeaway from my session is that it's sometimes beneficial to not rationalize uncommon situations, as that can lead to self doubt and unnecessary guilt.

Even if we do get into a similar situation in the future, we'll be much better prepared to not only deal with it, but to identify it before it necessarily becomes a problem. To me that's the important bit.

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

#372

Post by Kaze404 »

heurist wrote: post #275
Kaze404 wrote: post #253

Earlier quoted context omitted.

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

Leave that company immediately and find something that gives you room to breathe.

Thank you. That's currently the plan :)

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

#373

Post by Kaze404 »

tangjurine wrote: post #315
Kaze404 wrote: post #253

Earlier quoted context omitted.

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

tell us the reason! can't be as bad as https://news.ycombinator.com/item?id=27454589

I usually wouldn't mind, but my theory involves personal information that would make me very easily identifiable. I'm not hiding my online identity by any means, but when it comes to work related things I'd rather not give the impression like I'm throwing dirt on any specific person. What I talked about in my comment is much more of a systemic issue from my perspective, and I feel like a coworker reading it knowing it was written by me could take it personally.

Edit: you're right though, it's definitely nothing like that. 1 job is more than enough for me :D

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

#374

Post by Treblemaker »

TameAntelope wrote: post #252
yibg wrote: post #226

Earlier quoted context omitted.

Possibly in an ideal environment. But expecting the same someone to work with me for an entire week to either debug or design usually hasn't been realistic. Keep talking with different people, or the same person on and off has a huge context cost. What I've found to be a good middle ground is take some time to think things through myself first, at least in rough strokes. Then have someone else come in and review the…

I'm confused about why you're suggesting the only options are "work together for an entire week" or "don't keep anyone updated about what you're working on for a week". There are a lot of ways to keep your team updated, but more importantly, it's frankly arrogant to think you can or even should tackle any problem on your own.

Joe is the expert on feature X. When we have a problem in X we ask Joe for help and he invariably provides the insight needed to solve the problem.

When Joe has a problem with X, he should go ask for help, even though he's the one best able to deal with it? Should he ask himself for help?

Can you see the problem with blanket statements like this?

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

#375

Post by tomnipotent »

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.

> we can invent stuff they haven't thought of

Except you're not inventing things, you're discovering things. That's a big difference. The best way to discover if something works, is to put it into the hands of customers as fast as possible while minimizing your expense at doing so.

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

#376

Post by zomglings »

nine_zeros wrote: post #343
zomglings wrote: post #300

Earlier quoted context omitted.

Okay, there are three other common scenarios where I have observed pairing to be immensely valuable: 1. You are in the middle of a death march and pairing with a team mate gives both of you the moral fortitude to keep going (and keep your programs relatively correct and relatively secure). 2. You are working on a tedious but difficult task and working with a team mate makes it so that you are less likely to make mist…

All the above examples do not describe my day-to-day experience. Are you literally on a death march 5 days a week, every week? Are you literally on a tedious but difficult task 5 days a week, every week? Are you literally working on such a difficult problem that it needs true collaborators 5 days a week, every week? I specifically want to talk about - The Jeff Dean + Sanjay Ghemawat collaboration at Google is the mos…

Who said you have to pair five days a week every week? That doesn't sound reasonable. Very few things should be taken to an extreme like that.

For Dean-Ghemawat, I think they produced many great things by pairing on the same screen together. They also obviously did good work independently of each other.

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

#377

Post by pojzon »

throwaway71683 wrote: post #321
pojzon wrote: post #109

I’ve faced worse issue. So you are thinking about problem solution, you created a design and you ask ppl for their opinionated view about the problem and your solution. Issue is - they cannot even give you a good feedback because they are not that advanced. The issue of being a great engineer is that there are not many great engineers you can have a constructive discussion with. You are sometimes even “expected” to d…

This reminds me of a coworker that I've had bad experiences with. He fancies himself an architect, but he consistently refuses to accept any feedback on his designs. If we give feedback early in the process, he complains that we're nitpicking an incomplete design. If we give feedback when he deigns it completely ready for our review, he complains that he'll have to throw away so much work. All throughout, his refrain…

It only sounds good in theory. Reality is that in most cases this discussion is pointless and you are much better just explaining.

Example. You discuss different ways of data replication and have to decide which suits the project the best.

Issue is only you have experience with multi-region data replication and people you discuss the issue with dont even understand how replication works.

From manager point of view -> you were hired to guide those ppl.

Thats what happens in consulting like 99% of the time. You are the part of the team but you are often expected to provide the solution.

You can “explain” how it will work, but 9/10 times you wont get any feedback because ppl that you are supposed to deliver that project with simply dont have the knowledge required to have a good level of discussion.

Its like saying “PHD Doctors should have even field discussion with anti-vaccers, because both of them have something to say”..

Everyone has something to say, whether its something valuable, its a different matter.

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

#378

Post by Dudeman112 »

TameAntelope wrote: post #251
Trasmatta wrote: post #248

Earlier quoted context omitted.

You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door. This also ignores the fact that there is a huge amount of important wor…

There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe. And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.

>There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe

I took a week to refactor some nasty crap a few months ago. No customer noticed it.

I was rather happy to lower the estimated time for a bunch of other tasks from weeks to days/hours after doing it.

Now you can argue that was not "absolutely crucial", but then we'll just disagree on what that means.

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

#379

Post by Ensorceled »

watwut wrote: post #361
Ensorceled wrote: post #334

Earlier quoted context omitted.

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…

No post body was provided.

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

#380

Post by someguydave »

closeparen wrote: post #246
someguydave wrote: post #241

Earlier quoted context omitted.

because programmers must be replaceable parts for the industry to keep going at status quo

We have plenty of turnover and it works out fine. In fact turnover of the senior engineers who are service/project owners usually creates the opening for one of the more junior contributors to demonstrate L+1 competency by taking over.

“the status quo is fine”
Post reply on HN