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

31–40 of 395 posts

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

#31

Post by zachlloyd »

jack_riminton wrote: post #25
uejfiweun wrote: post #22

I feel like one of the biggest antidotes to this is just a simple daily standup. My team does this, a daily 30 minute meeting, and everyone says what they're working on as well as any blockers. Seems to work very well in terms of course correction at an early point.

I think because most people give very short descriptions in their standups i.e. "Working on x today, with a bit of y, no blockers". Perhaps due to things mentioned in the article, people don't want to or feel the need to invite feedback

Right, we do a standup, but if you're not careful the updates can be generic enough like "making progress on X" where you still end up working too long without feedback

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

#34

Post by strict9 »

Insightful article but surprised at the recommendations. Teamwork is important, yes... but smaller task sizes should have been mentioned too.

>Finally, after several weeks, the engineer shares an update, and one (or many) of the following bad things transpire:

Several weeks? If you are giving developers open-ended tasks that take weeks or more to complete, imo it's asking for things to go off the rails.

The most effective way I've found to avoid this situation is to ensure that worked assigned is broken down into tasks that are as small as possible.

When assigned work is limited to small deliverables you get smaller PRs, limited business logic changes to get lost in, fewer integration changes, etc.

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

#35

Post by claylimo »

jack_riminton wrote: post #25
uejfiweun wrote: post #22

I feel like one of the biggest antidotes to this is just a simple daily standup. My team does this, a daily 30 minute meeting, and everyone says what they're working on as well as any blockers. Seems to work very well in terms of course correction at an early point.

I think because most people give very short descriptions in their standups i.e. "Working on x today, with a bit of y, no blockers". Perhaps due to things mentioned in the article, people don't want to or feel the need to invite feedback

Where I work everyone will do their check-in but the important part is that everyone has a different personality. Like some people can be more confused and have a hard time explaining or even remembering what they did before so it's helpful to ask questions during their check-in to see if they need help. Some people might work on the same task for weeks. People are often afraid to ask for help. Or, maybe their task needs to be broken into something smaller given new information. The daily check-in is also a way for them to connect with someone else in the team who can actually help them. I'll tell them to either hang out at the end of standup or schedule a meeting with each other.

Having someone leading the standup, if done correctly, can help hold people more accountable for what their progress is toward the sprint goal and remove obstacles. This is one of the responsibilities of a scrum master although you don't need to be a scrum master at all to do this.

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

#36

Post by peterangular »

vanusa wrote: post #9
alexfromapex wrote: post #7

I've been guilty of this at times but what I would add is a certain type of environment encourages this behavior. If the business or teammates are very reluctant to let engineers work on what they want or give harsh feedback it encourages people to retreat into their safe space and try to create something they feel is worthy of feedback.

Y-e-p. It's not like these retreats happen in a vacuum.

I'll be honest - half the time it's trying to keep it from other engineers who are overly eager to have an opinion because a) they're low-output and looking to posture, and/or b) or want things to be done a different way.

At least the business side of the house appreciates the spec'd work being accomplished.

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

#38

Post by davidhyde »

> "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 alternative explanation that is also viable: Senior Engineers are often hired into large large projects so that the company has the capability to address emergencies or modify the existing system accurately as it is often more difficult to work on a large complex code base than to build a new one from scratch. Those engineers sometimes never get to work on greenfield projects and "doing too much work on their own before looping in others" is a way to scratch this itch without the opportunity being taken away prematurely. It also offers chance to produce memorable work as nobody remembers the set of 3 point tasks you completed ten sprints ago.

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

#40

Post by 908B64B197 »

zachlloyd wrote: post #2

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

In this industry we use "developer" and "engineer" interchangeably, but one is not like the other. They don’t hand out brass rats at the end of a bootcamp…

> For early career engineers, it often happens because they lack practice working on teams. They train in school environments where they do classroom projects on their own, or work on long-term intern projects in a silo.

Serious engineering school would have student work together to ship projects.

Post reply on HN