One problem of scale here is that unless a tooling investment has made literally 100% of the work easy, most of a developer's workweek almost by definition winds up spent on the remaining slow and hard problems.
So investing in tooling certainly improves productivity, but whether it can make things "fun" depends on which categories of hard/slow problems a given developer enjoys.
Well, they weren't Google-wide teams, they were teams for specific platforms/areas within Google. So I don't have any experience scaling it to 100k SWEs.
But in many cases it's a question of prioritization and polish. Just as an example, it's very easy to cut corners on API design for internal customers - unless the TL of the devex team is in the room. Or sometimes there are cross-cutting technical issues that no one really owns and no one will prioritize addressing, in part because of the relatively high organizational overhead of doing so and ambiguous ROI...unless the org has specifically staffed a devex team to search out and fix such issues.
bluquark|2 years ago
So investing in tooling certainly improves productivity, but whether it can make things "fun" depends on which categories of hard/slow problems a given developer enjoys.
endtime|2 years ago
But in many cases it's a question of prioritization and polish. Just as an example, it's very easy to cut corners on API design for internal customers - unless the TL of the devex team is in the room. Or sometimes there are cross-cutting technical issues that no one really owns and no one will prioritize addressing, in part because of the relatively high organizational overhead of doing so and ambiguous ROI...unless the org has specifically staffed a devex team to search out and fix such issues.
jvanderbot|2 years ago
galaxyLogic|2 years ago