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

61–70 of 395 posts

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

#61

Post by daenz »

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 you have to justify all of the input that you didn't act on.

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

#62

Post by pphysch »

There's also the flip side to this, "doing too little work before looping in others". Management brings overhead. Meetings bring overhead. Not every (sub)project needs multiple ICs.

That said, I think the E2E MVP/"tracer bullet" approach is a good compromise. It sets a clear milestone, which could be achieved by a single IC, but which provides something tangible for a team effort to build on (or meets intractable obstacles and and dies prematurely, saving everyone time before the PM engine is spun up).

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

#63

Post by nuancebydefault »

salt-thrower wrote: post #51
irrational wrote: post #49

> Throughout this initial period there are standup updates of the form “I’m exploring X, or working through problem Y, but should have something for others to take a look at soon” What is really going on is the developer has basically been given permission to not turn anything in. They are spending maybe an hour a day actually exploring/working on the issue and the rest of the day they are working on their own pet pr…

I think that's an overly harsh take. I've fallen prey to the pattern the author describes many times, and I inevitably end up making updates like that because I feel bad that work isn't getting done, which fuels a procrastination doom loop of anxiety and avoidance until I rip the bandaid off and hustle to make up the missing work. It sounds like you've never experienced this, and that's great for you, but don't disco…

Exactly. It is very easy to fall into the trap the author describes, for junior as well as senior engineers. Managers should ask for feedback early on in the process. This could be a first draft of the architecture or even a simple bullet list of assumptions and considerations. A look at that info by a fellow engineer or a product owner can highly impact the set of requirements, the design or the way of implementing.

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

#64

Post by billforsternz »

I chronically suffer from this problem. For example I started working on my chess software in 2008 and just yesterday someone raised an issue on GitHub asking me about pertft(). Gulp. Fortunately it turned out my chess logic does pass that very specific, very easy to check correct/not correct test. But it would have been much better to have checked I was building on solid ground 13 years ago!

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

#65

Post by Trasmatta »

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.

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 (hopefully you've hired a good team, of course), and not just code monkeys who have to show their manager a progress report every single day.

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

#66

Post by peakaboo »

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…

Completely agree with this, and this is why I simply don't loop in others.

I wrote a program the way I think it should be. Clean code, super easy to understand, super low complexity. Anyone can understand what it does.

Thats fun for me, when the code is very simple, reads like English and there are no complex functions.

I don't do real software engineering however (just business intelligence and python programs to extract and load data). But when it comes to looping in colleagues, I avoid it for the same reasons as above.

Its exhausting.

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

#67

Post by 6gvONxR4sf7o »

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.

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

#68

Post by peakaboo »

Trasmatta wrote: post #65
mattferderer wrote: post #59

Earlier quoted context omitted.

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.

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.

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

#69

Post by taurusnoises »

Not a developer, like, at all. But, I see this in myself when I work in groups all the time. I get excited about the project, forge ahead on my own, come back with so much stuff, into which everyone else now needs to "fit". At which point the entirety of the collaborative intention is missed.

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

#70

Post by 3pt14159 »

This is a bit of a nuanced topic with lots of shades of truth or context, and overall I agree with the article, but that said:

Sometimes you know your team is going to do the stupid shortcut if you let them and you save them from themselves by solving the robust solution before they have a chance to "be pragmatic" and pointlessly bikeshed about things that don't matter to waste your time. Sometimes you know it will take you a week to do it right or a week with input to do it half right and you just bite the bullet and do it right the first time and, to the articles point, suffer the consequences if or when you get it wrong or partially wrong.

Realpolitik is part of being a senior engineer. Sometimes you make the call to take the shortcut without mentioning it, sometimes you force the full solution with the big PR (or, even worse, a series of staged small PRs to make it look like you're taking feedback); but most of the time, if you're working somewhere good, you get to be completely transparent about what you're working on and the feedback you get is corrective and flexible.

Post reply on HN