Doing too much work on one's own before looping in others • Hacker News Board

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

#181

Post by Trasmatta » Tue, Jan 25, 2022, 9:35 PM UTC

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 strongly disagree with this. This is an approach to development that encourages an extremely limited and short term view on development that leads to low quality software and unhappy developers. It's also only remotely possible with a certain type of software.

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

#182

Post by commandlinefan » Tue, Jan 25, 2022, 9:37 PM UTC

This whole post strikes me as somebody making up a world as he believes it ought to be and then suggesting advice for navigating that world, rather than the real one. For example:

> Always encourage engineers to show their work as quickly as possible

Yep, that sounds like great advice. On "paper", anyway. I tried to do that when I first started out, too. What I found was that communicating "this is just an early draft, it'll be better when I'm finished" was well-near impossible, no matter how hard I tried.

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

#183

Post by Phelinofist » Tue, Jan 25, 2022, 9:41 PM UTC

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.

Can confirm. My lead is pretty picky with everything and expects 110% correctness. Even if my solutions works, is maintainable and extensible it is not how they would've implemented it, so it's no good. Argumentation is sometimes pretty artificial where some made up rules are the gold standard. That plus comments like "that is bad style" (for something that I've seen in all my past jobs + in a lot of OS code) make me not really want to loop them in.

But the job pays well and has interesting problems to solve, so I guess I will put up with it for some time more.

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

#184

Post by jbay808 » Tue, Jan 25, 2022, 9:46 PM UTC

strict9 wrote: post #34

Insightful article but surprised at the recommendations. Teamwork is important, yes... but smaller task sizes should have been mentioned too. > Finally, after several weeks, the engineer shares an update, and one (or many) of the following bad things transpire: Several weeks? If you are giving developers open-ended tasks that take weeks or more to complete, imo it's asking for things to go off the rails. The most eff…

I'm currently realizing that laying out a moderately complex PCB can take more than a week, but there's not much to be gained from breaking it up into smaller pieces. You kind of just have to do it.

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

#185

Post by reureu » Tue, Jan 25, 2022, 9:47 PM UTC

pojzon wrote: 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…

Amen to this. In a similar vein, in a heavily resourced constrained environment, the rest of the team may be really competent but be struggling to meet their own deadlines so just don't have the mental bandwidth or time to provide any feedback.

I've had this issue at a few jobs in the past, and I know I've come off as the lone developer who ventured too far... but at every step along the way I stopped, sent in a PR, scheduled a meeting, etc but got virtually no engagement. And I was still getting pressure from stakeholders to deliver, so had to keep moving :-/

I think OP brings up an interesting problem, but I don't think the solution is often as easy as sending in earlier PRs. It might actually be a structural or cultural problem in the organization.

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

#186

Post by beefield » Tue, Jan 25, 2022, 9:47 PM UTC

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…

Thanks for this comment. It pretty much confirms my hunch that I would not be happy in a "developer" role. I have done quite a lot work that requires writing code. But often it has been projects with literally months before there has been anything that anyone might call functionality.

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

#187

Post by TillE » Tue, Jan 25, 2022, 9:56 PM UTC

blindmute wrote: post #174

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.

That's basically true, but I don't think anyone has a good general solution to unclear requirements besides constant communication and fine-tuning, a la XP/Agile.

I like working on a module with interfaces and behaviors which are set in stone, but I find most of my work is a lot more exploratory than that, so the "clear requirements" can only come after it's about 90% done.

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

#188

Post by rurp » Tue, Jan 25, 2022, 9:57 PM UTC

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…

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 solving really difficult problems, but really, 99% of day-to-day development work isn't that special. A motivated and conscientious developer with average skills can get an awful lot done with minimal distractions.

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

#189

Post by onemoresoop » Tue, Jan 25, 2022, 9:58 PM UTC

Trasmatta wrote: post #106

onemoresoop wrote: post #87

Earlier quoted context omitted.

Pair programming should be optional and for whoever wants to get team members (especially juniors) up to speed and on the same page. It could be very productive but like all methods/tools that are shoved down everyone's throat and forced to apply them, I could see them being a disaster.

I generally enjoy pair programming when utilized occasionally and as needed, but mandatory pairing is just horrible.

Each tool has its use case. Forced use results in misuse.

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

#190

Post by dfsegoat » Tue, Jan 25, 2022, 10:00 PM UTC

mbrameld wrote: post #135

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?

It's not unusual in the US military for a lieutenant or captain in their early 20s to manage many senior non-commissioned officers in their late 40s.

No mil. experience myself, but I'd say that while the officers may technically 'manage' the NCO's, that with few exceptions it is the NCO's that actually get things done.