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

81–90 of 395 posts

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

#81

Post by sodapopcan »

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.

Exeactly. There is too much emphasis put on rewarding those who make big, disruptive change and large, solo wins. Someone making a lot of little wins are just as valuable yet usually don't any great accolates for it. Not to mention, putting one person on a large-ish project is a great way to create silos.

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

#82

Post by mberning »

Spending a few weeks on exploratory or speculative work is not really a huge time commitment. If it was going to drag on for months I would question it.

I also challenge the “deliver in small PRs” idea. Yes in practice that would be ideal. But often when you are doing something completely off the map there is no point to submitting the PRs for the 5 things that didn’t work. The author is falling into the same trap that scrum advocates and agilists fall into. Anything can be broken down into teeny tiny bit size deliverables and managed that way. Again, it would be ideal if that were the case, but sometimes you just need to give your best engineers some time and space to swing for the fences.

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

#83

Post by crehn »

sdoering wrote: post #29

I was more often than not 'guilty' of what the author describes. And I actually love being the lone detective on the hunt for a cool solution. I am not a dev by trade (data analyst) but still love to work on problems solved in code. A lot of the advice hit home, but what struck me was this part: > Encourage engineers to get something end to end launched internally as quickly as possible. This is something my boss nev…

This should nearly always include writing integration tests (that run on every change) to ensure you can refactor with confidence.

If there are no tests, the team will waste a ton of time anxiously monitoring and reasoning about the messy code and the impact of their changes.

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

#84

Post by Ensorceled »

I have two big rules for developers that report to me:

1. The 5 minute rule. If you are stuck for more than 5 minutes reach out. Once the developer is on the team for a while, this becomes 15 or 30 minutes.

Caveat ... truly stuck ... tried a couple of things, googled, tried some more ... wondering what to try next.

One thing I try to do with a new start is go ask them for help in the same way, "Hey, 5 minute rule, I'm think I'm missing something simple here."

2. Project Initiation Memo

The is NOT a PRD, it is a high level "I think this is what I'm supposed to be doing on this project and why". It might turn into a PRD if one is warranted. It's really just a "did you understand the problem correctly"

I've avoided so many massive f'ups or developers drifting into silent frustration for hours with these two rules.

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

#85

Post by closeparen »

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 think it's management and their "agile" philosophy that's toxic here, intentionally depriving engineers of any sense of ownership, autonomy, or vision-fulfillment over their work by constantly bouncing them around across small disjoint tasks.

I am incredibly fortunate to work in a place that values ownership, both explicitly and in practice. Given how widespread the opposing value system is, I'm afraid to ever leave.

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

#86

Post by Victerius »

abofh wrote: post #55
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…

You are not wrong. I generally sell as a mercenary, and prefer it that way - I've been doing this longer than some of my managers have been alive. I'm paid just as well if they want to "pair program" or jira the whole process, but yeah, you hired me to fix a problem - if you are the problem, I get paid just the same. Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having f…

> I've been doing this longer than some of my managers have been alive.

In what organisation do 25 year olds manage 50 year olds?

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

#87

Post by onemoresoop »

Trasmatta wrote: post #74
peakaboo wrote: post #68

Earlier quoted context omitted.

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.

Pair programming should be optional and for whoever wants to get team members (especially juniors) up to speed and on the same page. It could be very productive but like all methods/tools that are shoved down everyone's throat and forced to apply them, I could see them being a disaster.

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

#88

Post by swagasaurus-rex »

sdoering wrote: post #29

I was more often than not 'guilty' of what the author describes. And I actually love being the lone detective on the hunt for a cool solution. I am not a dev by trade (data analyst) but still love to work on problems solved in code. A lot of the advice hit home, but what struck me was this part: > Encourage engineers to get something end to end launched internally as quickly as possible. This is something my boss nev…

I find when this happens, it never gets refactored. The edges can be smoothed, but the architecture is dried and hardens into something that needs to be worked around by everybody else touching the code. The easiest way to solve the issue becomes the only way.

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

#89

Post by AtlasBarfed »

When you are doing idea creation and getting your head around an idea, I don't know about other people, but in addition to not being well quantifiable and structured (which standups and their tickets need), but looping in other people in the IT industry exposes you when you most look like an idiot.

It's the same reason IT interviews are this big cockpuff show. Everyone is insecure due to a combination of impostor syndrome, constant tech churn undermining your expertise, stack ranking culture, our industry archetype of socially unskilled/introverts, projection of bullying from schooling, etc.

So it comes down to functioning social dynamics in your group: people not trying to elbow other people in stack ranking, helping out, being eval'd fairly, etc.

Things, you know, that IT companies and manager generally aren't good at because technical understanding and achievement is paramount.

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

#90

Post by Ensorceled »

abofh wrote: post #55
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…

You are not wrong. I generally sell as a mercenary, and prefer it that way - I've been doing this longer than some of my managers have been alive. I'm paid just as well if they want to "pair program" or jira the whole process, but yeah, you hired me to fix a problem - if you are the problem, I get paid just the same. Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having f…

> Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having fun.

Ha! Yeah, I worked on a really cool project for a charity a few years ago: "How many hours is this going to cost us this week, you were working like a warrior?" "35"

Post reply on HN