3 ms·

I think you have misunderstood what an engineering productivity worker is. It's anybody who works on tools, frameworks, systems, processes, practices, etc. that

by mkanat 10y ago

I think you have misunderstood what an engineering productivity worker is. It's anybody who works on tools, frameworks, systems, processes, practices, etc. that help make developers lives better.

barrkel 10y ago
That's also what senior engineers do. And it's certainly how I develop code - my primary approach is building tools to lever up productivity and bring the level of abstraction closer to the domain. More generally, process improvement and practices have normally been introduced on the suggestion of engineers in reaction to problems, in consultation with management, in companies I've worked at.
YZF 10y ago
Sorry. I'm not very familiar with that term. That sort of sounds like anything between what a regular developer would do, a build engineer, and a VP Eng. There's a big difference between someone joining the team with the role being helping the team build better internal tools to someone who is joining to change the way the team works. I was thinking about the latter and it seems your definition includes both?
- 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 ago
    Kind 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.

by mkanat 10y ago

I think you have misunderstood what an engineering productivity worker is. It's anybody who works on tools, frameworks, systems, processes, practices, etc. that help make developers lives better.

barrkel 10y ago

That's also what senior engineers do. And it's certainly how I develop code - my primary approach is building tools to lever up productivity and bring the level of abstraction closer to the domain. More generally, process improvement and practices have normally been introduced on the suggestion of engineers in reaction to problems, in consultation with management, in companies I've worked at.

YZF 10y ago

Sorry. I'm not very familiar with that term. That sort of sounds like anything between what a regular developer would do, a build engineer, and a VP Eng. There's a big difference between someone joining the team with the role being helping the team build better internal tools to someone who is joining to change the way the team works. I was thinking about the latter and it seems your definition includes both?

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 ago
  Kind 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.