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

291–300 of 395 posts

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

#291

Post by owlninja »

skissane wrote: post #268
Shared404 wrote: post #244

Earlier quoted context omitted.

> and perhaps forgiveness. I would agree here, on the condition of rehabilitation. Obviously our "justice system", isn't. Edit: Speaking of the US above, no experience or knowledge about other countries systems. It appears I've found a new gap in my knowledge, anyone have a good intro to how courts work in their country?

My lawyer friend and I are both Australians, and he works as a criminal lawyer in the Australian legal system. The US inherited the basics of its legal system from that of England. Australia did too, along with many other countries. So at a very high level, the basics are the same. But, there has been a lot of divergent evolution, so as we drill down into the details lots of differences come up. I think one huge diff…

Can you shed some light on rehabilitation in Australian prisons?

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

#292

Post by jlokier »

TameAntelope wrote: post #288
jlokier wrote: post #287

Earlier quoted context omitted.

Proof to whoever the stakeholders are, presumably the customers in your model. Proof that it satisfies what the customer needs or wants - something which can't be demonstrated until the would-be solution reaches some level of demonstrable maturity. For many engineering solutions, you can talk about them earlier, handwave, present, but nothing conveys that it actually works, or sometimes even makes sense, short of a w…

So... how do you know what those people want? How do you know what you're building in 3 weeks isn't something totally different from what the users now want? The answer is that you, alone, don't. By spending more than a small amount of time building out the simplest possible version of what the customer wants, you get their feedback along the way. It's generally not true that you need many weeks, or even a full week,…

Ah, I left that out by mistake when editing.

You know what they want because they told you, up front, when they hired you.

In the example, let's say the customer has said they would find it really useful if the GPU could calculate twice as much on the same power, but they don't know how that could be done. Perhaps it's in a self-driving car and these are hard specifications. And then they crank up some agile "creative" process, encouraging devs including you to work on whatever areas of the system make sense to improve it. As long as you ship code PRs daily and a little report.

You talk to them about your idea, and they don't understand it. It's not convincing to them, but it is to you - and you're the expert on this. You are hired for your expertise and the customer doesn't have anyone else with it in the GPU algorithm design area. Your team peers are either busy or don't understand the area well enough. They can't recognise what will solve their stated problem, and you can't convince anyone that your method will work until you have reached the "proof" stage after 3 weeks of not producing any PRs, which is against what the customer or your managers incorrectly believe a competent developer would invariably produce almost daily.

I'm not saying you should do that as a dev. I'm saying it's an example of what "proof" refers to, while being something that gives a customer what they said they need, and is not a dev's pet project. Addressing the incorrect assumptions implied in "Proof to whom? Shouldn't you be developing things your customers need, not some pet project you enjoy working on for its own sake?"

There is no pet project, and you don't actually enjoy workng on it all that much. You're just trying to solve the customer's stated problem in an environment where they openly say what they'd really want and have set up a process which prevents it - a very common combination.

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

#293

Post by TameAntelope »

jlokier wrote: post #292
TameAntelope wrote: post #288

Earlier quoted context omitted.

So... how do you know what those people want? How do you know what you're building in 3 weeks isn't something totally different from what the users now want? The answer is that you, alone, don't. By spending more than a small amount of time building out the simplest possible version of what the customer wants, you get their feedback along the way. It's generally not true that you need many weeks, or even a full week,…

Ah, I left that out by mistake when editing. You know what they want because they told you, up front, when they hired you. In the example, let's say the customer has said they would find it really useful if the GPU could calculate twice as much on the same power, but they don't know how that could be done. Perhaps it's in a self-driving car and these are hard specifications. And then they crank up some agile "creativ…

> You know what they want because they told you, up front, when they hired you.

This is, very often, a fatal mistake, and what they hired you to do is not what they need, nor what they want you to do in three weeks, let alone three days.

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

#294

Post by mjrbrennan »

I absolutely hate hate hate having to do rework at the end of a feature or other project, so I loop others in with design discussions early and often. I don’t want to get to the end of something only for someone to say “Oh wait I think it should be done this way.” Communication is key.

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

#295

Post by mjrbrennan »

LAC-Tech wrote: post #279

I've got the opposite issue, and if I'm being frank - maybe it's not such a great look for me as a senior. But also at the same time... why should we suffer alone? Sometimes something that might take you a day by yourself might take you an hour with another person with a fresh perspective. Isn't it more efficient? Let's loop each other in, often. I'm always down to share screen. Unless of course I'm the only one oh G…

Don’t worry you’re not alone! Sometimes I worry about the same thing too. But ultimately I think it’s dumb to struggle along with something for days or working on something that no one actually wants or is going in the wrong direction for days.

Much better to just loop others in early and often so things are done right the first time, and in the most effective way possible.

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

#296

Post by jlokier »

TameAntelope wrote: post #293
jlokier wrote: post #292

Earlier quoted context omitted.

Ah, I left that out by mistake when editing. You know what they want because they told you, up front, when they hired you. In the example, let's say the customer has said they would find it really useful if the GPU could calculate twice as much on the same power, but they don't know how that could be done. Perhaps it's in a self-driving car and these are hard specifications. And then they crank up some agile "creativ…

> You know what they want because they told you, up front, when they hired you. This is, very often, a fatal mistake, and what they hired you to do is not what they need, nor what they want you to do in three weeks, let alone three days.

Sure but now that's just arguing in circles. Whatever I'd say about what they've shown they need in a simplified example for discussion, you can find a matching argument that it's not what they really need, but that argument doesn't address anything. It's a "no true scotsman".

Assume for the sake of the point, that you are a competent and experienced dev, and somehow you have correctly ascertained something that the customer needs, most likely by talking with them.

The point of this discussion is to ask, are there circumstances where someone needs to "work on one's own" for a while before others will recognise a solution is in progress to the clear need of their customer. And are there circumstances where not doing that will result in the solution being blocked, without any other useful replacement taking its place. There are countless anecdotes, and in all walks of life not just software development, pointing to the answers to both of those questions being a strong yes.

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

#297

Post by nine_zeros »

zomglings wrote: post #290
nine_zeros wrote: post #289

Earlier quoted context omitted.

Pairing is only helpful when you are new and learning from someone more experienced. However, it may be a time-sink for the more experienced person, who could be using their limited time on more critical things. That's why newbies get assigned a mentor, with whom they can pair freely. But pairing rigidly with the whole team just sucks and is incredibly unproductive.

I don't think it's true that pairing is only helpful for new people learning from someone more experienced. But I also think it will be difficult to convince you otherwise if that's what you believe.

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

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

#298

Post by TameAntelope »

jlokier wrote: post #296
TameAntelope wrote: post #293

Earlier quoted context omitted.

> You know what they want because they told you, up front, when they hired you. This is, very often, a fatal mistake, and what they hired you to do is not what they need, nor what they want you to do in three weeks, let alone three days.

Sure but now that's just arguing in circles. Whatever I'd say about what they've shown they need in a simplified example for discussion, you can find a matching argument that it's not what they really need, but that argument doesn't address anything. It's a "no true scotsman". Assume for the sake of the point, that you are a competent and experienced dev, and somehow you have correctly ascertained something that the…

That's your mistake; it's not a matter of competency and experience. You are not a solo venture, you are a member of a team, and part of that team needs to be a customer representative who can tell you, in real time, what the customer wants.

There is no room for a hero engineer in modern software development. That's not how it works anymore, and it may never have worked that way.

Your countless anecdotes of this working stack only a fraction as high as the countless anecdotes of what you're describing completely failing.

This battle was fought in the 00s and won in the early 2010s. Agile produces results, waterfall generally does not.

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

#299

Post by kstenerud »

nine_zeros wrote: post #289
zomglings wrote: post #271

Earlier quoted context omitted.

Haha I like everything you said except the "pair program" bit. From my point of view as both a programmer and an employer, this is the cleanest way to make sure knowledge transfers between short-term and long-term team members. Why the disdain? (If I interpreted correctly.)

Pairing is only helpful when you are new and learning from someone more experienced. However, it may be a time-sink for the more experienced person, who could be using their limited time on more critical things. That's why newbies get assigned a mentor, with whom they can pair freely. But pairing rigidly with the whole team just sucks and is incredibly unproductive.

I've had similar experiences.

I vocalize a lot (in my head) during the development process, and I've noticed that when I have to engage with another person during this time I start vocalizing audibly, which is where the problems start. The other person gets confused because I'm speaking the snippets and half-ideas that are passing through my mind at the moment (and the internal jargon I've developed over the decades), and it degenerates into long sequences of explaining my every move, most of which would have been quickly dismissed internally had I not had to stop to explain them.

Or they misunderstand the path I'm taking for something else that won't work and interrupt me, and then I have to stop to explain first that it's not what they think (which is hard), and then explain the path I'm actually going down (harder), and why I think it's a good idea (hardest). It's like having a backseat driver, and just as infuriating.

Every interruption shatters parts of the intricate glass tendrils that comprise the complex model in my mind, and then I have to rebuild them again before I can continue thinking. The creative process gets completely disrupted and there's zero chance of flow. This is fine if I'm teaching someone since the material is well known and there's no creativity required. But during actual work it's a productivity black hole. Death by a thousand cuts.

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

#300

Post by zomglings »

nine_zeros wrote: post #297
zomglings wrote: post #290

Earlier quoted context omitted.

I don't think it's true that pairing is only helpful for new people learning from someone more experienced. But I also think it will be difficult to convince you otherwise if that's what you believe.

> 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 mistakes despite the tedium (as well as gives you the moral fortitude to continue with the task).

3. You are working on a difficult problem and you have a team mate that you can truly collaborate with to find solutions neither of you would have found on your own. (The Jeff Dean + Sanjay Ghemawat collaboration at Google is the most famous example of this.)

In any of these cases, it is important to pair with someone compatible with you. And you can build compatibility over time.

Post reply on HN