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

71–80 of 395 posts

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

#71

Post by Trasmatta »

daenz wrote: post #61
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…

The trick is to make the "right" decision yourself while helping people feel like they were heard and had a chance to give their input. From my experience, people don't actually want to control the output of everything, they just want the opportunity to be heard. What you do with it from there doesn't matter as much, so long as the desired outcome is "correct". If the desired outcome is not correct however... then yo…

The tricky part for me is that sometimes I did actually need that input from others on the team. Sometimes it's all just bikeshedding and a waste of time, but sometimes it does help me from going down a rabbit hole that might have wasted weeks of development.

But regardless, I find that whole process exhausting and disempowering, even if there is sometimes a benefit from it.

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

#72

Post by [deleted] »

mattferderer wrote: post #59
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…

As much as I love the feeling of writing something clever or that feels really well done, I hate the feeling of realizing it's the wrong thing even more.

[deleted]

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

#73

Post by jseban »

zachlloyd wrote: post #2

I'm the author of the post - would love any feedback / similar experiences / contrasting opinions!

The description of the "problem" is that the requirements specified in the beginning were wrong, and then the developer is blamed for solving exactly what was specified, and not constantly asking management every day "have you changed your mind?". I don't understand at all, how this is the fault of the developer, talk about expecting the developer to bend over backwards for any product manager. How is it not reasonable for management/PO to be responsible for 1. sending devs off in the wrong direction, and 2. not notifying them as requirements change?

This is just another way of saying "management is right, even when they're wrong, and you need to accept that".

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

#74

Post by Trasmatta »

peakaboo wrote: post #68
Trasmatta wrote: post #65

Earlier quoted context omitted.

Agreed, and that's why I mentioned I think you shouldn't just silo yourself. That doesn't seem to work either. I don't really have a good answer or alternative, more just pointing out how the dynamics of team based software development seem to be optimized towards burning out programmers. I don't know how to fix it, but it seems to be a problem. A first step is probably treating your developers skilled specialists (h…

You do know how to fix it - you don't loop in others until you want to. The problem is our industry, forcing developers to exhaust their energy on pair programming in open offices. May as well be in a daycare center with children all around.

Ugh, my worst development job ever was one that had mandatory full time pair programming. Full time pairing is one of the worst ideas ever conceived in the software world.

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

#76

Post by nuancebydefault »

waynecochran wrote: post #46
zachlloyd wrote: post #2

I'm the author of the post - would love any feedback / similar experiences / contrasting opinions!

I am an older software engineer and have noted that a lot of introverted engineers love to work in their own silos. Some of the smartest engineers are introverted and do not want to be bothered; worse yet, because of pride they often do not "suffer fools" well and avoid working with others. Working with a group of smart and humble engineers that are constantly "borrowing each other's" brain is very effective and enjo…

I feel the same way. Lot's of experienced engineers don't like to be bothered too much, have the feeling they know best and just design and implement the way they have it in mind. Juniors on the other hand don't like to bring their beginners mistakes too much in the open, hence they work hard and long to avoid that. Both of these situation are largely sub-optimal. A good manager knows this and asks for feedback in time, in an interested way, without being too pushy.

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

#77

Post by adverbly »

They missed one reason why it can happen: Because doing things "the right way" is too slow, and the engineer is trying to skirt around process because the company moves way too slowly. Not out of malice or negligence, but out of a fear of the megacorp killing agility. I've seen entire teams at megacorps or governments try to keep others in the dark with projects that would be crushed under strict corporate rules.

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

#78

Post by alokedesai »

I work at Warp (https://www.warp.dev/) where Zach, the author of the post, is the founder.

One practice we’ve gotten into the habit of is demoing projects at standup as soon as possible. I’ve found this has been useful to force myself to get to an end-to-end version of a project sooner. This is useful not just in derisking the technical implementation but also in getting product feedback sooner. By playing around a live demo earlier, we often find that the product experience needs to be refined in ways we couldn’t validate from Figma mocks alone.

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

#79

Post by belval »

6gvONxR4sf7o wrote: post #67
davidhyde wrote: post #38

> "the biggest mistake I see engineers make is doing too much work on their own before looping in others" > "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process." Not saying the above statement is incorrect but here is an alternativ…

> It also offers chance to produce memorable work as nobody remembers the set of 3 point tasks you completed ten sprints ago. This is one of the more toxic ones. To get past senior, you often need to be seen to do Big Memorable Things. It sometimes leads to perverse incentives.

I mean it's not that toxic, if you are a good worker bee your manager will usually notice and be happy with your performance. Then from time-to-time you branch off to do something more high-risk to add to your promo doc.

I think a lot of people have weaker communication skills than execution skills. So they could loop in everyone early on, but their idea might get killed off because they failed to justify it properly. If instead they leverage their execution skills and make an MVP that will speak for itself, then they bypass that issue.

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

#80

Post by Panoramix »

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…

I wholeheartedly agree, if you need daily feedback you're a bad manager (unless you're in some exotic situation like a rocket launch or something).

This issue largely disappears if your engineers are given the proper context, background and system overview.

I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.

Post reply on HN