Live data from Hacker News

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

thezbook.com

321–330 of 395 posts

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

#321
post #109

I’ve faced worse issue. So you are thinking about problem solution, you created a design and you ask ppl for their opinionated view about the problem and your solution. Issue is - they cannot even give you a good feedback because they are not that advanced. The issue of being a great engineer is that there are not many great engineers you can have a constructive discussion with. You are sometimes even “expected” to d…

This reminds me of a coworker that I've had bad experiences with. He fancies himself an architect, but he consistently refuses to accept any feedback on his designs. If we give feedback early in the process, he complains that we're nitpicking an incomplete design. If we give feedback when he deigns it completely ready for our review, he complains that he'll have to throw away so much work. All throughout, his refrain is that we "just don't understand his design".

I agree that it's harder when there's an absence of peers at the same experience level, and for problems that can be completed by one person, it's probably not necessary to seek validation. But if it's a problem that requires a team effort, building shared understanding of the design is at least as important as creating the design in the first place. Yes, it's more work if it doesn't click immediately for everyone else, but it's essential.

And sometimes in the process of explaining it so that even a "not great" engineer can get it, we can better understand it ourselves. And sometimes even a layperson can bring valuable insights once they get the gist of it.

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

#322

Earlier quoted context omitted.

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?

I don’t really know. My uneducated impression is that Australia’s prisons are harsher than those of many Western/Northern European countries but not as bad as those of the US-but I don’t know of any hard data on the issue. Rehabilitation is officially an objective and of course the prison system makes some attempts but we can always question if they do enough.

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

#323
A late comment I know but one I just realised is important.

This whole article bothered me. And the realisation is that it expects upfront design to work as something distinct from coding.

"The code is the design" (Jack Reeves) is a fundamental point - until you write the code, you are just dealing with "artist's impressions" - vague ideas that might not hang together. The code has to be written (to be thrown away) so that things can be really worked out.

Other points:

* everyone does not have time to be always commenting on everyone elses iterations. Yes there is time for the big architectural design. But every day? If I am commenting on some other engineers work daily and not actually working with them something is off.

* going off and coming back with a big PR. YEs thats bad. Going off and coming back with a Proof Of Concept that will inform the discussion. Thats good.

With a Big System, the right way to do it is to do one (at least) to throw away.

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

#324

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…

> "usually it should be more like a day" is bad advice in my opinion, and a likely source of micro management.

Depends what "showing" means - on the other end is doing all prototyping/exploration as pair programming - thus immediately "showing" work to at least one other engineer.

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

#325
post #188

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…

Due to some turnover I ended up working mostly independently for about a year at a previous job. Nobody cared one bit about the code I wrote, just the end result. Overall it was great! I was surprised at how productive I was in that time. I'm not a partiularly amazing developer, but I managed to ship a ton of work that held up quite well. Obviously there are limits to this approach and it wouldn't work well for solvi…

Sounds like high bus-factor. Were you also expected to pick up "alien" code dumps as other programmers left? Were you happy/efficient working with these unseen code bases?

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

#327
post #234

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…

> 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. I believe this is why books most often have a single author. A solution to t…

> I believe this is why books most often have a single author.

... And at least one editor, no?

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

#328
post #309

Earlier quoted context omitted.

> 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. I'm going through exactly this at the moment. For reasons HN will probably consider fiction, my superiors have started treating me as a toddler that needs oversight on every single decision that needs to be made. It's something I've been dealing with in therapy, and the way…

So, you do scrum?

No. We do "do whatever for 3 weeks and work 12 hour days on the week before a deadline comes". Maybe there's a name for that :p

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

#329
post #309

Earlier quoted context omitted.

So, you do scrum?

No. We do "do whatever for 3 weeks and work 12 hour days on the week before a deadline comes". Maybe there's a name for that :p

"Procrastination driven development" maybe?

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

#330
Interestingly, I just realized another sphere where this occurs: management. A manager sees some perceived problem, comes up with a policy to "solve" it, and then requires their employees to follow the new policy.

Wonder what this sort of approach would look like for management. It seems like the employees are the "customers" in this arrangement.

Post reply on HN