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

341–350 of 395 posts

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

#341

Post by jraph »

alexashka wrote: post #339
jraph wrote: post #306

Earlier quoted context omitted.

Yes. I hope we get rid of this cliché of the technical person who is not good at human interactions. Most developers I know are good at human interactions, some even among the best. I don't want to be put in that box, and I'm not willing to excuse someone bad at human interactions because they are technical. Obviously some people are better at human interactions than others, and I'll be happy to adapt, but let's not…

Your anecdotal evidence and personal preference is irrelevant in a discussion about statistics.

Do you have statistics on the matter?

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

#342

Post by dogleash »

TameAntelope wrote: post #320
ngc248 wrote: post #304

Earlier quoted context omitted.

Exactly .... Agile works pretty well in the "execution" phase when all of the requirements are known upfront. For any kind of R&D agile is not a good fit at all. R&D fits the waterfall model better. Ideally it should be like you do your R&D with waterfall and the agile for execution.

"Waterfall works best in well-understood domains without a lot of uncertainty."[0] Agile is, by far , a more effective way to run an R&D shop. By far . "Agile teams show progress with working software, not documents. Right from the beginning. And that's huge." [1] [0] The Art of Agile Development, pp. 35 [1] The Art of Agile Development, pp. 8

In my aforementioned example, the set of development practices most often called "agile" was neither the right approach nor what we did. Agile as defined as the ideas in the agile manifesto might have been what we did. It would depend on who you asked and whatever their particular axe to grind was.

So I don't know, and quite frankly we didn't really care if we were "agile." All we found was that "agile" is simply too lossy of a descriptor for meaningful conversations about development process.

People writing books and blogs about what they mean when they say "agile" hasn't caused the industry to coalesce on a concise definition. That horse is out of the barn, and I don't expect we're getting it back.

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

#343

Post by nine_zeros »

zomglings wrote: post #300
nine_zeros wrote: post #297

Earlier quoted context omitted.

> But I also think it will be difficult to convince you otherwise if that's what you believe. This is true. I have been on both sides of the pairing equation. I am currently on a team that pairs too often and I am annoyed on a daily basis because I could have been utilizing that same time for actual work. So yes, it's going to be difficult to convince me but feel free to take a stab.

Okay, there are three other common scenarios where I have observed pairing to be immensely valuable: 1. You are in the middle of a death march and pairing with a team mate gives both of you the moral fortitude to keep going (and keep your programs relatively correct and relatively secure). 2. You are working on a tedious but difficult task and working with a team mate makes it so that you are less likely to make mist…

All the above examples do not describe my day-to-day experience. Are you literally on a death march 5 days a week, every week? Are you literally on a tedious but difficult task 5 days a week, every week? Are you literally working on such a difficult problem that it needs true collaborators 5 days a week, every week?

I specifically want to talk about - The Jeff Dean + Sanjay Ghemawat collaboration at Google is the most famous example of this.

Do you think they really produced all they did by pairing together? In my experience, the best things were produced by independent thinking, collaborating on experiments and trusting each others decisions. Not by actual pairing on the screen together.

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

#344

Post by samjewell »

I'm amazed that the author doesn't recommend Pair-programming as one of the techniques to avoid "Doing too much before looping in others"

He mentions: > an engineer on a project should never go more than a week without showing something, and usually it should be more like a day

But in my experience by pairing you can shorten this feedback loop to seconds.

A few other people have commented about pairing: It's clear people have different preferences and that it's wise to use pairing at the right moments, but it still seems a glaring omission from the article to me.

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

#345

Post by Chris2048 »

TameAntelope wrote: post #251
Trasmatta wrote: post #248

Earlier quoted context omitted.

You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door. This also ignores the fact that there is a huge amount of important wor…

There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe. And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.

Just off the top of my head: what about legal requirements that a customer isn't liable for?

> I urge you to think about how that work could affect a customer's experience

Why is this the be-all and end-all?

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

#346

Post by jacobyoder »

TameAntelope wrote: post #286
jacobyoder wrote: post #281

Earlier quoted context omitted.

> Suffice it to say, it's all been accounted for. Agile works. And if you are doing "Agile" but it's not working... then you're Doing It Wrong(tm). Right?

Would it make you feel better to hear it's not your fault? There are lots of reasons agile won't work for you, but they're also great indications you should probably leave a given org.

Why not just say "Agile Works Sometimes"? Or "Agile Can Work"? Because when "Agile Works" is touted, and then things go wrong, people get blamed, vs the actual processes and concepts. If "Agile Works", but we're not getting the results, then someone must be doing something wrong - can't be "Agile" that's wrong (for this scenario).

"Agile" software development doesn't work when there's 5 non-technical stakeholders and 1 software developer.

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

#347

Post by jsprogram »

superfrank wrote: post #118
Victerius wrote: post #86

Earlier quoted context omitted.

> 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?

I worked at a start up where the founders were 25 & 26 and most of their first 25 employees were their friends who were similar aged. In less than two years, there were almost 100 employees, plenty of which were in the 50s. The company's last valuation has it worth over a billion dollars now and they have a few hundred employees. A good chunk of the C suite and VPs are still those same early employees who are now in…

Which one was it?

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

#348

Post by TameAntelope »

dogleash wrote: post #342
TameAntelope wrote: post #320

Earlier quoted context omitted.

"Waterfall works best in well-understood domains without a lot of uncertainty."[0] Agile is, by far , a more effective way to run an R&D shop. By far . "Agile teams show progress with working software, not documents. Right from the beginning. And that's huge." [1] [0] The Art of Agile Development, pp. 35 [1] The Art of Agile Development, pp. 8

In my aforementioned example, the set of development practices most often called "agile" was neither the right approach nor what we did. Agile as defined as the ideas in the agile manifesto might have been what we did. It would depend on who you asked and whatever their particular axe to grind was. So I don't know, and quite frankly we didn't really care if we were "agile." All we found was that "agile" is simply too…

You can be as cynical as you like, the general idea of (very) quickly iterating to stay focused on what your customer wants is a proven and effective way of build software.

It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.

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

#349

Post by js8 »

comp_throw7 wrote: post #312
strictfp wrote: post #216

Earlier quoted context omitted.

You can just let some people make mistakes, and give them feedback on it for next time. That way, you get autonomy and eventually mastery. We don't all have to agree on everything. I think that's a fallacy.

The idea that people will better learn from spending several weeks doing something useless (i.e. unnecessary design) instead of having that headed off at the pass is silly, when the specific thing they should be learning is to _not spend several weeks working on something without feedback_.

I don't think that's what GP was suggesting at all.. everyone in the thread agrees that feedback is good.

However, the opposite extreme, spending time in meetings where lot of good ideas get proposed but most of them get killed, because somebody doesn't like a detail, or nobody champions them strongly enough, is not a good learning experience either.

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

#350

Post by 3pt14159 »

Slartie wrote: post #107
3pt14159 wrote: post #70

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 t…

I have found that the attitude of "just silently do the robust and proper thing immediately and push it, instead of letting the entire team discuss this important infrastructure topic forever in order to ultimately come up with an abomination of design-by-committee-architecture, just to then find out that the remaining time now is way too short to implement it, which is why they then take all the stupid shortcuts to…

Yes, exactly. Again, if you have a good team though, they'll trust you to do the right thing from the get-go because they know you got their back.
Post reply on HN