2 ms·
Sort of, yeah. See https://testing.googleblog.com/2017/04/code-health-googles-internal-code.html https://testing.googleblog.com/2017/04/code-health-googles-i...
by mkanat 10y ago
Sort of, yeah. See https://testing.googleblog.com/2017/04/code-health-googles-internal-code.html https://testing.googleblog.com/2017/04/code-health-googles-i... as one of the examples of a type of Engineering Productivity work that I do at Google (although as you have basically pointed out, there are reasons we avoided that word for the work that I do, although I still think it falls under the broader umbrella).
It seems like the thing that you're worried about (I mean, correct me if I'm wrong, this is just the sense I get from your post) is people hiring a sketchy consultant to come in and have everybody follow some process whether or not it has anything to do with their work or making things actually better. I'm definitely also opposed to stuff like that and I've made a few jokes or snide comments about it here and there on the blog, in http://www.codesimplicity.com/book/ http://www.codesimplicity.com/book/, and on my Twitter feed.
- YZF 10y agoKind of. It's mostly a people thing, not a strictly technical thing. A lot depends on the company culture. In my company in theory the IT department is there to help everyone with their IT needs. In practice interacting with that group is painful because they are not necessarily aligned or motivated by the same things other people are. I can imagine that having an "engineering productivity" group can suffer from similar problems but if the culture is right then it can be a win/win.