Effective Engineering Productivity | Hacker News Reader

Effective Engineering Productivity

codesimplicity.com

92 pointsatsaloli25 comments

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.

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.

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.

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?

Sort of, yeah. See 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/, and on my Twitter feed.

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.

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

"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.

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.

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.

Also, sometimes I feel like bloggers are getting paid by the word. Start with some bullet points. Give me a tldr. I read for 10 minutes and only learned what not to do if I ever happen to work in engineering productivity.

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?

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.

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?"

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

https://en.wikipedia.org/wiki/Chief_programmer_team

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

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.

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.

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"

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

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.

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

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

Isn't this another name for Chief Programmer Team model

https://en.wikipedia.org/wiki/Chief_programmer_team

One way to define that is in terms of the customer: quality (no defects), calendar time to deliver, benefit to customer, and value (cost-benefit ratio). So you can say things like, "if we refactor this code now, we can schedule less time on maintaining it in the future, spend less unscheduled time fixing bugs in the future, and deliver features in less time with less effort."

Reply on news.ycombinator.com