Live data from Hacker News

The Radiating Programmer

dev.37signals.com

21–30 of 33 posts

Re: The Radiating Programmer

#21

Pushing is fine if people can consume it asynchronously, and if you actually stick with it and don't forget to publish frequent updates. In my decades as a SWE, there is one way that worked better than all others: having a competent project manager who individually polls team members with weekly, short(5-10min) 1:1s and then takes care of handling schedule updates, resource assignment and unblocking the dev. This all…

Which is frustrating, because on the tech side, "use boring technology" has a couple essays written about it, but when it comes to project management, everyone things they can do better. Unless project management better is your core competency, like if you're Monday.com, (it isn't) you have more important things to burn energy on than reinventing project management from first principles.

Re: The Radiating Programmer

#22
You can radiate information and still be told “Cool, I’m so glad you keep everyone in the loop. You still need to attend the standups / retros / IPMs / etc.”

Re: The Radiating Programmer

#23
post #5
post #4

Earlier quoted context omitted.

> If you just say “no blockers” you’re doing it wrong in my opinion. This only works when you trust your team members. This means absolutely nobody who can fire me on the spot, not my supervisor, not my skip, not the CEO/CTO/VP should be on the call. No non-technical staff from the above list should have a right to challenge estimates. No product owner can belong to the above list. There should be openness when techn…

> This only works when you trust your team members. This means absolutely nobody who can fire me on the spot, not my supervisor, not my skip, not the CEO/CTO/VP should be on the call. not sure how I'd've ever justified suggesting engineering standup without our engineering manager present

What’s… the EM there to do?

Re: The Radiating Programmer

#24
post #5

Earlier quoted context omitted.

> This only works when you trust your team members. This means absolutely nobody who can fire me on the spot, not my supervisor, not my skip, not the CEO/CTO/VP should be on the call. not sure how I'd've ever justified suggesting engineering standup without our engineering manager present

It sounds like your dev team isn't very empowered. In the companies I work at we can create whatever ceremony our team deems nessesary as long as we're meeting our metrics.

> ...isn't very empowered. ...as long as we're meeting our metrics.

"Empowered to meet metrics" still doesn't sound like a very enlightened philosophy to me.

Re: The Radiating Programmer

#26
We do standups a couple times a week as a text chat, one person pings everyone as a reminder then we all put in just a couple sentences on what's going on before we go to lunch. Most days someone's message starts a thread where two or more of us chat about something in their update.

Re: The Radiating Programmer

#27
post #6

I'd rather have a 5-10 minute standup than have to write such an oddly detailed report twice a week on what I "weighted" in on.

I would probably spend an hour or two just writing something like that. On the surface, I'd agree. With that said, in my experience, many stand-up formats devolve into some version of "the two most talkative people have a conversation for 30 minutes while everyone else listens". I'd probably get more value out of doing a write-up than sitting through a meeting like that. It really depends on the health of the stand-u…

Yeah, I would also generally agree. But what they are showing is the 'Basecamp workflow', where instead of monopolizing a meeting or posting walls of text on slack or sending an email, you surface the issues on the project management level, where everyone can find it. It's their thing.

Re: The Radiating Programmer

#28
*squints* However when Javascript is disabled, the font/lettering displayed on this page is, uh... one nobody should ever radiate information in, ever.

(A mix of capital letters and enlarged lower-case letters.)

Re: The Radiating Programmer

#29

That's a great way of putting it. I have found that communication strengths and weaknesses can vary, from person to person, and it's usually a tough sell to come up with "one size fits all" solutions. One example, is that I had an employee who is probably the best engineer that I've ever met, and I've worked with top-shelf people. But he is "on the spectrum," so his verbal communication tends to be in monosyllables,…

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 that: a myth. Some cultures do better at it than others. I worked for a Japanese company, and they came very close to it, but at a cost that most folks here, would find prohibitive.

High-performing teams can be difficult to manage. There’s often significant differences in personalities, egos can be high, and everyone has an opinion that is the only “right” one.

Great teams require good management. It’s always fun to dis managers, but good ones are force multipliers, like nothing else.

Re: The Radiating Programmer

#30

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…

Strong agree; I wish companies worked harder to support and develop managers. They're crucial to team success--and I would even argue to the individual development of the people they manage.
Post reply on HN