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

51–60 of 395 posts

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

#51

Post by salt-thrower »

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 discount what the author is saying. It rings uncannily true to me, and it sucks when it happens.

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

#52

Post by io98763 »

spmurrayzzz wrote: post #16
ziggus wrote: post #12

Why the conflation of 'engineer' and 'developer'? That's a bit confusing.

I'm curious, what about that semantic differentiation is confusing for you? At least in my experience, "Software Engineer" is a standard title for the kind of work the author is describing in the article and is often used interchangeably with "Developer".

I think they mean generally. And I tend to agree. I had suspicions while reading it but wasn't completely sure till I checked the Author's bio on the right. Some, if not a lot, of it doesn't apply well if at all the the "classic" fields of engineering, where engineers tend to be much more focused and trained in their skills.

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

#53

Post by Trasmatta »

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 this may be one of the factors in burnout for a lot of developers. Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input.

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.

> Always encourage engineers to show their work as quickly as possible – an engineer on a project should never go more than a week without showing something, and usually it should be more like a day.

"usually it should be more like a day" is bad advice in my opinion, and a likely source of micro management. Let professionals do their work.

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

#54

Post by kitsunesoba »

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…

The frustrating thing is when only the first half of this philosophy (ship now, fix/polish later) is adhered to, where things get shipped frequently but seldom followed up on. The incentive to finish things needs to be strong for not only the engineers but also for the product teams and managers directing them, but as far as I can observe this is exceptionally rare — in fact it almost seems like the norm for non-engineers to push for shipping new features over polishing older ones. A lot of the engineers I know would love nothing more than the opportunity to polish the project they’re responsible for to perfection, but are never given the chance.

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

#55

Post by abofh »

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 fun. If your work is bullshot, I bill tighter than my lawyer

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

#56

Post by zachlloyd »

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…

i see the point here.

i do think giving space for hard work is important. i still more often see the opposite problem of too much silo'd work leads to wasted effort, but for some really hard problems, having a bunch of space to think them through is beneficial.

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

#57

Post by zachlloyd »

disposableuname wrote: post #19
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.

The original post contains > It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process. I think the author would agree with you.

i do agree

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

#58

Post by zachlloyd »

eatbitseveryday wrote: post #30
zachlloyd wrote: post #2

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

Please write the insight into the title of the post, rather than hiding it under a click-bait. Your site is down now due to traffic and the original HN title (reflecting the title of your writing) provides no value.

yup, i messed this up, apologies. site is handling the traffic better now thanks to cloudflare

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

#59

Post by mattferderer »

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.

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

#60

Post by leeoniya »

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…

it really depends on what you're working through.

i do this on occasion while experimenting and thinking through an architectural design. what matters is whether the end result is representative of the time spent on iteration and writing thrown-away prototypes. i will often not start writing code until a reasonable path is formed in my head, and then i may write a prototype that doesnt work out and have to loop back and rethink various aspects. it may take a week with nothing but vague updates in daily standups, but then something awesome to show that has gone through a bunch of private "pre-alphas".

> For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions.

this really only applies if you:

A) dont have a history of delivering quality solutions to non-trivial problems

B) refuse to ask for help/feedback when you actually need it

typically, the rest of the team is working on other things. there would be little value in me pushing various crappy prototypes just for the sake of providing updates that only serve to distract people with information that will be out of date in 24hrs. "too many cooks in the kitchen" is a real thing, too.

Post reply on HN