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

171–180 of 395 posts

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

#171

Post by kerneloftruth »

"Looping in others" is an opportunity for others to say NO, or to try and redirect you, or to jump (unwanted and unneeded) onto your band wagon. If I'm working with true peers (not age or title peers, but truly similar in talent and ability), then their early involvement or collaboration is great.

Generally, however, I prefer to get solutions developed to the point where they are their own proof. It's much harder to argue against something that's (near or entirely) completed and which proves to work. It's fine for me to then involve others to get their feedback, etc.

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

#172

Post by TameAntelope »

kerneloftruth wrote: post #171

"Looping in others" is an opportunity for others to say NO, or to try and redirect you, or to jump (unwanted and unneeded) onto your band wagon. If I'm working with true peers (not age or title peers, but truly similar in talent and ability), then their early involvement or collaboration is great. Generally, however, I prefer to get solutions developed to the point where they are their own proof. It's much harder to…

Proof to whom? Shouldn't you be developing things your customers need, not some pet project you enjoy working on for its own sake?

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

#173

Post by TameAntelope »

bob1029 wrote: post #163

I am stuck with a delicate balancing act around this one. Our organization arguably would not exist today if it were not for developers doing "too much" work on things before bothering others. Our product would certainly be worthless trash today if we had to design by committee for every feature. We took extraordinary risks that simply could not have been planned into reality. Most of those risks were taken by indivi…

I think it's telling when you call this "asking permission". You should never need to "ask permission" to give customers some small amount of value with a short turnaround.

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

#174

Post by blindmute »

I'm of the opinion that if the problems outlined in the article happen, it was because of poorly defined work. A senior engineer should be able to work on something with no communication for a week and it be correct. If it isn't correct, the work was not defined correctly prior to starting the work. Daily updates and frequent collaboration are not the solution; they are a stopgap masking unclear requirements.

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

#175

Post by pcmaffey »

The challenging part of this is that knowledge work is intangible and uncertain. Showing progress is difficult, especially with low context. So we want things to be perfect or finished or at least to scope. There's a lot more that goes into our work than commits, PRs, and completed tasks.

Second, "showing your work/progress" should be async. Otherwise, it's taxing for both parties as it requires a request and then some sort of feedback.

People though are generally curious and want to know what others are working on, if they can help, how it aligns, etc. Having that ongoing visibility into each other's progress makes it way easier to build off each other.

What we need is a simple, async way to share progress--outside the scope of tasks or timelines.

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

#176

Post by jkaptur »

zachlloyd wrote: post #2

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

It's great to see "I'm still exploring X" called out as a standup antipattern. I've heard and (hi Zach!) said this many times.

... But I've generally heard it most frequently from the tech lead and/or manager at the standup. It's easy to justify: "as the TL/M, my work is ill-defined, meeting-heavy, complex, externally-focused, and long-term! I'm not just building a feature! It's hard to describe!"

In my experience, this culture percolates with lightning speed: more junior folks immediately understand that to be senior and high-status is to give vague updates (often with a dramatic sigh and a self-deprecating joke about getting nothing done).

So it's good to exhort feature-building ICs to show incremental progress on that feature, but I think this article should have a heavier focus on the most senior folks at the standup.

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

#177

Post by dogleash »

TameAntelope wrote: post #150
Panoramix wrote: post #80

Earlier quoted context omitted.

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.

I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…

I used to work at an R&D company. While that cadence is possible in a website mill, it’s a laughable blanket statement.

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

#178

Post by [deleted] »

TameAntelope wrote: post #150
Panoramix wrote: post #80

Earlier quoted context omitted.

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.

I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…

[deleted]

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

#179

Post by spmurrayzzz »

io98763 wrote: post #52
spmurrayzzz wrote: post #16

Earlier quoted context omitted.

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.

This seems, at best, an anecdotal and/or an arbitrary distinction about what qualifies as "Engineering". Software engineering, as an applied discipline both in name and in practice, has existed since at least the mid-to-late 1960's. And many of the orgs in those days which adopted that title normatively, employed many folks who were "focused and trained in their skills" (e.g. NASA) and worked alongside of those in the more classical engineering domains.

Speaking in my own experience, working closely with hardware/mechanical/electrical folks on a novel product line, they are exposed to a lot of the same subject matter covered in the article. Many of the tradeoffs explored there are absolutely relevant to the older engineering disciplines.

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

#180

Post by AlwaysRock »

amelius wrote: post #170
abofh wrote: post #55

Earlier quoted context omitted.

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…

> If your work is bullshot, I bill tighter than my lawyer Lawyers must hate their work.

I believe it has one of the lowest job satisfaction of any white collar jobs. I've wondered that is folks didnt have the massive student loans to pay off early on if they would stick with it.
Post reply on HN