The Radiating Programmer • Hacker News Board

Re: The Radiating Programmer

#31

Post by andygeorge » Fri, Nov 24, 2023, 2:47 PM UTC

jgoodhcg wrote: post #16

andygeorge wrote: post #8

Earlier quoted context omitted.

Same. I don't want to have to write OR read those reports, and a quick daily stand-up is far better, IMO, for effective communication.

I think there is an argument here with no right answer. Writing can have such a better signal to noise ratio but it’s harder to write well. Talking is easy but it’s also easy to forget something in the spot or ramble on too much without editing.

> Writing can have such a better signal to noise ratio

It can, but in my experience with employers who push async as primary communication, the noise is MUCH higher than regularly scheduled stand-ups.

Re: The Radiating Programmer

#32

Post by 01100011 » Fri, Nov 24, 2023, 6:33 PM UTC

ChrisMarshallNY wrote: post #29

01100011 wrote: post #18

Earlier quoted context omitted.

Not saying this is you, but I'm surprised how many managers seem unaware of the prevalence of social deficiencies among the highest performing engineers. 20 years ago this was just sort of a given. I have to regularly defend a few highly productive but socially caustic engineers who are absolutely essential to our products. Management would love to get rid of them and the problems they cause without realizing no one…

There’s always a balance to be kept, between high-performing engineers, and team dynamics. Great products are created by great teams. It’s almost impossible to create anything of any meaningful scope, these days, without a team. There are “superman” engineers, like Linus Torvalds, that can create entire shipping architectures, but those are incredibly rare. That said, the myth of the “cookie cutter” engineer is just…

> Great products are created by great teams. It’s almost impossible to create anything of any meaningful scope, these days, without a team.

Yes, but also there are things that teams cannot do, and in fact make them worse.

To use an example from my org, there is a feature which was proposed to accomplish a specific objective. The feature grew in complexity to address much more than was originally planned. A large team was assembled to rapidly deliver as the original objective was important to business needs. The large team enabled the larger version of the feature.

This mostly happened without the knowledge of one of those smart but ostracized engineers. When they became aware of it, they had to step in and force changes to prevent the large feature from leading to serious technical debt and behavior that would not compose with other features well. More changes should have been done to return to a simpler design that would have focused on the original goal but it was too late.

Re: The Radiating Programmer

#33

Post by ChrisMarshallNY » Sat, Nov 25, 2023, 12:17 AM UTC

01100011 wrote: post #32

ChrisMarshallNY wrote: post #29

Earlier quoted context omitted.

There’s always a balance to be kept, between high-performing engineers, and team dynamics. Great products are created by great teams. It’s almost impossible to create anything of any meaningful scope, these days, without a team. There are “superman” engineers, like Linus Torvalds, that can create entire shipping architectures, but those are incredibly rare. That said, the myth of the “cookie cutter” engineer is just…

> Great products are created by great teams. It’s almost impossible to create anything of any meaningful scope, these days, without a team. Yes, but also there are things that teams cannot do, and in fact make them worse. To use an example from my org, there is a feature which was proposed to accomplish a specific objective. The feature grew in complexity to address much more than was originally planned. A large team…

That's where good managers come in.

We're supposed to be doing more than just spout jargon to our superiors.

We need to be completely situationally aware of the project, make sure that key stakeholders are always consulted for big decisions, and kept aware of plans, push back on senior managers, if what they ask is unreasonable, etc.

And we need to do it in a highly unobtrusive way, that doesn't interfere with developer productivity.

I have said it before, that I was lucky to have the situation I did, and the more I hear about how most companies run, the more fortunate I feel.

It seems that managing my way, these days, in Silicon Valley, would just get me fired.