
Effective Engineering Productivity - atsaloli
http://www.codesimplicity.com/post/effective-engineering-productivity/
======
YZF
I don't see how bringing in an "engineering productivity worker" can have
anything but a very low probability of success.

It probably means one or more of the following:

\- Management thinks that engineering productivity is lacking.

\- A lack of communication between management and engineers.

\- Poor management.

\- Poor engineering.

The root problem is almost always management and a "consultant" brought in to
a situation like this can typically not affect any real management change.

It's the same sort of trap that a Scrum Master is in in a "non-Agile"
organization and why "Agile" has failed.

~~~
mkanat
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.

~~~
YZF
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
Sort of, yeah. See [https://testing.googleblog.com/2017/04/code-health-
googles-i...](https://testing.googleblog.com/2017/04/code-health-googles-
internal-code.html) 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
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.

------
vinceguidry
> Solve the problems that people know they have, not the problems you think
> they have.

That's what this boils down to. Being told you have a problem and then force-
fed a solution down your throat never feels nice.

Another thing I've noticed, at least at the few places I've worked at is, the
bottleneck for the company is practically never engineering productivity.
Engineers exist to amplify the efforts of other people, nobody ever sells the
output of the engineering department directly.

Even when they are directly selling software to the public, there's a release
cycle and backwards compatibility to care about before the number of features
in each release becomes important. There is also a lot more to a software
product than the code going into it.

Savvy, politically-aware engineers notice this and carefully structure the
pace they're working at. They could easily plow through dozens of tickets or
stories if it's called for, it's just that nobody ever expects them to work
that hard. Smart management gives the engineers political cover so they're not
kicked around like beach balls between upper management PHBs with too much
time on their hands.

------
cbanek
"The first thing you should do with the data is find some problem that
developers know they have, that you know you can do something about in a short
period of time (like a month or two) and deliver that solution. This doesn’t
have to be life-changing or completely alter the way that everybody works. In
fact, it really should not do that. Because the point of this change is to
make your work credible."

This approach has worked well for me in the past. In one of my past roles, I
was writing tools to try to improve "quality."

One of the main problems we had was the bugs written were hard to reproduce,
or had some kind of invalid configuration or incompatible build.

It took me a while to figure out that everyone is using host files to point to
environments, and different mixes and matches of servers, which were causing
lots of problems (but not real bugs). This was taking developer's time
(testers couldn't debug the problem), tester's time (waiting for resolution,
blocked), and made us think real bugs were not real bugs.

In the end the solution was to centralize hosts file management through a
tool, where there would be approved configs that could be chosen, and they
would be set automatically. Thing caught like wildfire. Super simple technical
solution, and that gave me the street cred to make more complex proposals
(like a CI system).

Be on the lookout for the small gains, and use them to build your cred. Also,
if you get your foot in the door technically (like everyone running a tool
they know they want), it's easier to add more things to it and keep the
momentum going.

I do have to point out that there is one type of person missing from the
author's "people who will push back", and that is people who have a vested
interest in keeping the code base terrible, or designed the way it currently
is. Reasons include "we're trying to log all this time against a re-write",
"that code is too fragile and risky to change", and anything else the
developer might think are idealistically correct, and nothing else will do.

------
gjkood
Over the years I have come to agree that "Laziness is the mother of
invention".

If I have to do something more than once or twice, the first thing I think
about is whether it is automatable.

One of the reasons I have always tried to stay close to the Unix view of the
world is the access to simple tools that can be pipelined to provide powerful
toolsets. I am a firm believer in the value of scripting things whether
through shell scripting, awk, sed/vi, PERL (in the earlier days), Python etc.

The first thing I used to do when I get a Windows environment was to install
cygwin or something similar that gave me access to Unix like toolsets. You may
ask "Why not Powershell?" but I have been using Windows before the Powershell
days and sometimes old habits are hard to break. The unix tools are almost
near universal nowadays whether using Windows, Linux or MacOS/OSX.

Once you have acces to these tools simple repetitive/mundane tasks can be
easily automated to increase productivity.

------
valuearb
A very effective tool for increasing productivity of people reading your blog
is to not make the lines a thousand characters wide or not use the tiniest
possible font so it can be read on a mobile device.

~~~
mkanat
On the mobile theme, I'd suggest filing your complaint with wordpress.org.
This is the standard Wordpress mobile theme, so it's the mobile format used by
a significant percentage of all the websites on the Internet.

On the line width, are you referring to the desktop site or the mobile one?

------
coldcode
Many development problems having zip to do with code. Trying to fix the code
without addressing those (which are often outside your ability to change) is
pointless. Organizational issues, terrible overweight processes, political
infighting, poor decision making by management or product teams, or even
dreadful hiring practices all can make the code terrible but can't be fixed my
trying to change the programmers.

~~~
mkanat
Maybe. I've interacted with a lot of companies on this subject and I've found
that not to be the case, though. There's usually more that an individual
engineer can do about the system than sometimes they believe. It's not that
there aren't management problems--there are and they are real and they do
cause many or most of the failures in the software engineering industry in
part. However, purely blaming management for the quality of your code is an
irresponsible attitude that won't actually get you anywhere. And I don't mean
"irresponsible" in the sense that you should be blamed for it, I'm taking
about responsibility as the ability to be cause over your own situation, the
ability to be the source of the things that you yourself produce. If you're
sitting around saying that somebody else is responsible for your production
all the time, then you're not going to be able to be at cause over it or come
t change it in the way that you want. So yes, there are management flaws and
they do cause this sort of trouble, but there's also another attitude that you
can take toward it and ask yourself, "What CAN I do about my code, like for
real?"

------
walshemj
Did not IBM call this a Chief Programmer Team back in the 70's

[https://en.wikipedia.org/wiki/Chief_programmer_team](https://en.wikipedia.org/wiki/Chief_programmer_team)

~~~
mkanat
Sort of. The Toolsmith, Tester, and Language Lawyer would all have some aspect
of Engineering Productivity in their role. But it's more than just that. See
also, for example: [https://testing.googleblog.com/2017/04/code-health-
googles-i...](https://testing.googleblog.com/2017/04/code-health-googles-
internal-code.html?m=1)

------
krosaen
Sounds a lot like product management & UX best practices applied to a
particular domain (understanding user pain points, building things that solve
specific unmet needs). Would be a more interesting if that was acknowledged
more explicitly in the article.

~~~
mkanat
I dunnow. I don't think that finding out what people's problem is and solving
it in a way that is real to them is specifically or exclusively the domain of
PM or UX.

~~~
krosaen
True, but PM & UX might be the domain where it is studied most explicitly.
Overall would just be helpful to point people who read this article to, e.g,
"and by the way, these practices have a lot in common with UX and Product
Management, you can learn a lot more about it if you search for those terms"

------
the_arun
Please define Engineering Productivity. Is it velocity, hygiene, speed of
taking a feature to production? what is it?

~~~
mkanat
In the context of this blog post, it's a group of people (or individuals) who
work to improve the developer experience, usually including testing, code
quality work, and practices. It sometimes also includes tooling, release work,
frameworks, etc.

~~~
alextheparrot
I think the original question was more "How do we measure that we are
increasing engineering productivity, what constitutes engineering
productivity?".

~~~
mkanat
Yes, but the post is about a group of people or an individual who works in a
particular field, not the subject of productivity itself. So I defined the
phrase as used in the post.

I do have another post about measuring productivity:
[http://www.codesimplicity.com/post/measuring-developer-
produ...](http://www.codesimplicity.com/post/measuring-developer-
productivity/)

