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

#191

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

davidhyde wrote: post #38

> "the biggest mistake I see engineers make is doing too much work on their own before looping in others" > "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process." Not saying the above statement is incorrect but here is an alternativ…

In my case, I'm the senior engineer and the rest of the team are juniors. There's generally not much I can ask them that they'd know the answer for. On the other hand, looping them in is a good learning experience for them even if they can't help me solve the issue. But due to time constraints that isn't always possible.

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

#192

Post by BurningFrog » Tue, Jan 25, 2022, 10:01 PM UTC

AlwaysRock wrote: post #180

amelius wrote: post #170

Earlier quoted context omitted.

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

Many law firms are incredibly well paid sweatshops.

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

#193

Post by emptybottle » Tue, Jan 25, 2022, 10:02 PM UTC

My experience is different in that large patch sets usually get a “looks good” while smaller sets get a lot of varied feedback.

Depending on what your personal goals are (and your tolerance for accountability should things go wrong) doing the work up front can be a good approach.

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

#194

Post by schrodera » Tue, Jan 25, 2022, 10:03 PM UTC

Going dark alone does not very often yield results - even if the right solution comes out getting others up to speed will remove any time gained before easily.

Going dark as a team is a different story.

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

#195

Post by EGreg » Tue, Jan 25, 2022, 10:05 PM UTC

philote wrote: post #191

davidhyde wrote: post #38

> "the biggest mistake I see engineers make is doing too much work on their own before looping in others" > "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process." Not saying the above statement is incorrect but here is an alternativ…

In my case, I'm the senior engineer and the rest of the team are juniors. There's generally not much I can ask them that they'd know the answer for. On the other hand, looping them in is a good learning experience for them even if they can't help me solve the issue. But due to time constraints that isn't always possible.

You nailed it. Senior engineers build things on their own because their company can’t afford to hire enough advanced enough people who can learn the system and take over the work without being trained for 6-12 months, and often there is no budget for this kind of ”distraction” from the core moneymaking path.

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

#196

Post by gffrd » Tue, Jan 25, 2022, 10:18 PM UTC

dogleash wrote: post #177

TameAntelope wrote: post #150

Earlier quoted context omitted.

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.

Just wanted to say thank you for "website mill" … I'm reminded of this stark difference when talking with a friend who builds ultrasonic hardware.

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

#197

Post by redisman » Tue, Jan 25, 2022, 10:18 PM UTC

emptybottle wrote: post #193

My experience is different in that large patch sets usually get a “looks good” while smaller sets get a lot of varied feedback. Depending on what your personal goals are (and your tolerance for accountability should things go wrong) doing the work up front can be a good approach.

I think that’s just because it’s too much work to review so people give up

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

#198

Post by skissane » Tue, Jan 25, 2022, 10:23 PM UTC

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.

> Lawyers must hate their work.

A friend of mine is a criminal defence lawyer. I get the impression he really enjoys his work – he gets to meet a lot of people he never normally would (bikie gang members, terrorists, murderers, drug dealers, drug addicts, etc) – and he feels safe in doing so (he tells me that defendants trying to harm their own lawyers is quite rare, rare enough that he isn't worried about it).

Once, at a work function (previous employer), I met one of the lawyers from the contracts department. He was telling me how he used to live in a rural area doing agricultural real estate transactions, now he had moved to the big city to do in-house contracts review for a multinational software company. He was a "top performer" (indeed, this was a function to reward people who'd been nominated as "top performers" by their management)–but he didn't give me the impression he really loved what he did, more that he was just doing it to support his family.

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

#199

Post by Trasmatta » Tue, Jan 25, 2022, 10:24 PM UTC

drawkbox wrote: post #145

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…

> 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. I use this exact description when discussing balancing creative side of the value creation project processes, design and development over the value extraction side of products. Small empowered teams with an almost startup mindset i…

I don't have a lot to add except to say I loved this reply. I think a lot of people might miss it since it's down in the replies, maybe you could expand on it, and make it a blog post at some point?

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

#200

Post by emptysongglass » Tue, Jan 25, 2022, 10:35 PM UTC

The longer I work in this industry the more I reflect on the value of all this accretion of process: Agile, Scrum, PI planning, daily stand-ups are counterproductive to real work. So much of it, the sprints, the retroactives, the sprint planning, feel like taking place in the stead of real work. (I reached for the common "instead" of here but wanted to emphasize the work being removed or substituted by not-work).

Real, deep work, is largely a solo affair. Teamwork is trusting your team that they will do their work.

I can think of only two processes which truly requires communicating over real, smell-that-earth honest work. That is: seeking counsel and asking for help because you are well and truly blocked. For the latter, the process of learning enough to become unblocked, even if it takes a long time, can make the practitioner a better software developer forever vs the shortcut of a quick, "do you have a minute" disruption to another developer's time.

Gumroad's philosophy and practice of work [1] struck a chord with me. No meetings, no deadlines. Just a commitment to production, whatever the method, whatever the schedule.

[1] https://sahillavingia.com/work