←back to thread

210 points dakshgupta | 1 comments | | HN request time: 0.201s | source
Show context
glenjamin ◴[] No.41847498[source]
Having a proportion of the team act as triage for issues / alerts / questions / requests is a generally good pattern that I think is pretty common - especially when aligned with an on-call rotation. I've done it a few times by having a single person in a team of 6 or 7 do it. If you're having to devote 50% of your 4-person team to this sort of work, that suggests your ratios are a bit off imo.

The thing I found most surprising about this article was this phrasing:

> We instruct half the team (2 engineers) at a given point to work on long-running tasks in 2-4 week blocks. This could be refactors, big features, etc. During this time, they don’t have to deal with any support tickets or bugs. Their only job is to focus on getting their big PR out.

This suggests that this pair of people only release 1 big PR for that whole cycle - if that's the case this is an extremely late integration and I think you'd benefit from adopting a much more continuous integration and deployment process.

replies(5): >>41847622 #>>41847713 #>>41847719 #>>41849997 #>>41850708 #
1. codemac ◴[] No.41849997[source]
> extremely late integration

That's only late if there are other big changes going in at the same time. The vast majority of operational/ticketing issues have few code changes.

I'm glad I had the experience of working on a literal waterfall software project in my life (e.g. plan out the next 2 years first, then we "execute" according to a very detailed plan that entire time). Huge patches were common in this workflow, and only caused chaos when many people were working in the same directory/area. Otherwise it was usually easier on testing/integration - only 1 patch to test.