Hacker News Reader

Comment by alistairSH | Hacker News Reader

The premise of this essay seems flawed.

As a manager, I actively encourage my employees to automate their jobs. Almost every sprint, there is at least one task on the board to automate some mundane detail of their jobs.

I'm happy to have them do it. It frees them to do more valuable work. "Pushing buttons" isn't valuable (we can't sell it). And like most good developers, they hate sitting around pushing buttons - they'd rather work on more stimulating problems.

It's win-win. My boss sees us doing more with less. The sales team gets more new features to sell. The employees have more rewarding days.

This all presupposes the employees aren't inherently lazy. But, that's been my experience - "lazy" developers aren't generally lazy, just bored.

View on HN

This is absolutely the right way to do things. My time, and my developer's time is far too important to handle mundane tasks, and if we're manually doing those tasks, that just another thing I need to double check to make sure I did correctly, and that seriously wears on me.

I'm paid a lot of money to solve problems, not write code. Is code involved? Yes, of course, I'm a programmer, but my job is to solve issues. I have never been at a place where I've though, "you know if I automate this button, I don't have a job anymore." There is always WAY too much work to do that actually requires my attention.

Agreed! There's always more work to do, no matter how much you automate.

I run my company's admittedly very small IT. If I could automate everything on my list, that list would immediately fill up with even more stuff that needs to get done.

> This all presupposes the employees aren't inherently lazy. But, that's been my experience - "lazy" developers aren't generally lazy, just bored.

In fact, afaik, it's kinda 'proven' loosely in psychology studies that "laziness" isn't a bad trait per se. In fact, from our ancestral laziness comes our drive to build things (systems, organizations, machines, civilization!) to do our job for us, anywhere from 'streamlining' to 'automating'.

Many great developers are self-reportedly very ambivalent between laziness and the drive to make things — alchemy notably happens when what you make today will let you be lazier tomorrow (you probably need to be at least 25 to 'feel' it though).

Of course, being a nerdy creature, you'll rinse and repeat indefinitely — there probably never will be a shortage of things to automate in your lifetime — but that's the spirit. As you said, we gotta keep ourselves busy to balance the lazy. ;-)

I hadn't thought of the evolutionary benefits before but this makes a lot of sense. Related to this, I have noticed that I really like efficiency for sake of efficiency, which is probably a trait many other tech people share.

As a silly example, I was hiking at night recently and my headlamp had gotten a little dull because the batteries were starting to get low. Even though I had a spare set, I didn't swap them out because the old ones still had hours of power left, albeit at reduced output. The cost of a few batteries is trivial, but the thought of throwing them away while still useful bugged me more than the reduced light output. My partner thought I was crazy for this, and I don't disagree, but for whatever reason little efficiencies matter a lot to me.

> efficiency for the sake of efficiency

Oh dear rurp, you don't want to get me started on that! ;-)

Your hiking example is a textbook page of my life, I do things like that all the time. Partner openly jokes that I'm crazy / weird / funny — all in good spirits, I concur that it's not exactly statistically average (i.e. 'normal') behavior. — "but why do you do this like that?", eyes usually roll before I even finish my elevator pitch; but every once in a while I catch her imitating. Good times, haha. Small victories, you know.

That being said,

I have a gazillion justifications for this. From ancient Zen and Stoicism (you guessed it) to modern scientific organization of work / tasks / labor, passing by cognitive science and physics and what-have-you.

It's. Just. More. Efficient. To. Be. Efficient!..

¯\_(ツ)_/¯

But it's also a delusion, to some degree (when you mistake the means for the ends I suppose, when it becomes a zero-sum rat race from a 3rd person perspective). Hence a healthy distance with the concept, I treat it as one parameter/rule of our universe — nature favors the efficient ones — but I've learned to just shrug at the general inefficiency of my civilization. Sometimes, I admit I'll even take pleasure and find beauty in a wildly inefficient thing that nonetheless passes the threshold of "it works", however barely. Politics, states, institutions feel like that to me: it should all collapse under its own weight and complexity, and yet it goes on... fascinating feat. It's like e.g. Windows (the biggest codebase in existence, at least as reported a few years ago, 50 million lines iirc?), you have to revel at the wonder that it even works.

This is my life.

My wife does pretty much everything in a way that simply blows my mind. Probably once a day, I start to mutter "But, why....?" Most of the time she just looks at me like I'm the broken one, meanwhile I swear it's her!

Packing for a trip is the worst. For me, it's hours of over-analysis and optimization. Packing everything into a minimal volume. Ensuring nothing unneeded makes it way into a bag. For her, it's grab an armful of {whatever}, toss it in a suitcase, and assume it'll all work out. And yet, we both love traveling and we're equally as likely to forget something.

Life is strange.

Just responding because I feel similar to what you're describing and my partner is similar to what you described.

I agree that I think it's a common trait among people in our line of work.

As famously pointed out by Larry Wall: http://threevirtues.com/

Making more money is what ultimately allows me to be lazy, so I just need to find a way to make enough money so I would have no more obligation to work.

> "lazy" developers aren't generally lazy, just bored

Well said, this has been my experience as well and so I also encourage automation as much as possible. I guess it depends on the business and tasks to do but there's generally no shortage of work in the backlog and if work can be automated, more resources can be spent on adding tests and new features.

If the tasks are straightforward, I often find it helpful for new starters to take on some of the automation projects. It allows them to get to grips with the pipeline a bit more and gets them to ask questions to other developers to clarify things, all whilst providing immediate value.

The premise of this essay is that workers should benefit from automation, not owners/stockholders. In your case, workers do benefit in some way, like less boredom, but do they work 15 hours a week instead of 50?

> but do they work 15 hours a week instead of 50?

no. If they automated a part of their job, and yet is unable to contribute new value (in the form of other tasks completed), then they will either be made redundant or their pay is lowered correspondingly. Workers are unable to reap benefits from value derived through their automation if they don't own the equity of the business they are working in.

Unless they of course keep it to themselves. If employer hired you for data entry and nothing else. And there is no other work for that employer, is it fair that you automate the job and not get rewarded for it somehow? The only way to make things just might be keeping it from your employer. If the employer was intelligent they would have realized they could automate it in the first place and this type of employer likely will not reward the employee, but instead just get rid of him/her.

That's a solid approach. I may try it with my teams too.

I always try to be very conscious of anything that will create / remove future interruptions in the decisions that we make around our work but haven't yet made a point to get "automate something" in regularly.

I've found it's far easier to build this into sprints/backlogs/whatever than rely on the team to automate on their own. Benefits include: better understanding of the problem, testing (is the automation robust, etc), and making time for formal sharing with other teams. Also, some developers want to automate, but might not feel enabled - they want to stick to the rules (sprint plan, etc).

I applaud your willingness to manage up as well as down. I can't tell you how rare it is for a middle manager to trust the engineers in their charge to make these types of decision. At most places, where bastardized "Agile" has taken root, if any change can't be directly tied to a feature then it's not happening.

I've been really fortunate to work with reasonable product managers. At worst, I've sold automation as an IOU - let me do this 1 thing now, and you get 2 things next release. But, even that's the exception.

> This all presupposes the employees aren't inherently lazy. But, that's been my experience - "lazy" developers aren't generally lazy, just bored.

Laziness is lack of motivation, for whatever reason. Am I working on a project that's ever going to be used? If not, do I at least feel like I'm getting something out of it?

I can enjoy working on a project I personally don't intend to use if I know someone will get value out of it, and I can enjoy working on a project that only I will ever use if I foresee getting sufficient use out of it or if I'm learning interesting stuff along the way, but if none of those things are true, it all just becomes a chore, my mind goes blank, and my productivity begins to dry up. I can power through, but I dread the work.

Empirically, for me, creating "boring" report-generation software is plenty fun if I know someone's going to read and use the reports, and that those reports will make a difference to them. I'm not "making a report" as much as I'm spending minutes of programming time to save them hours of hunt-and-peck work getting the same information manually. I like doing that, even if there's nothing to it, from a programming perspective.

Contrariwise, the worst project I was ever on was an "interesting" one which involved automating web browsers, essentially writing something like Protractor for automating website testing. It had plenty of little technical rabbit-holes to go into, plenty of stuff I could do to learn more about the technology, and I hated it because it devolved into a make-work project I knew nobody was ever going to use. The fact it was a school project, which meant there was no work-life balance and I felt obligated to work on it every spare moment, certainly didn't help.

Most software development is internal software which will never be sold. That shouldn't discourage anyone, because it means most software developers will know who's using their software by name, and possibly have friendly relationships with them.

Q : Does the extra output (value) also translate into shared monetary benefits for workers and employers?

Not directly. It's a large, PE owned company, so no profit-sharing or stock grants. But, over time, via access to more interesting projects, quicker promotions, and more visibility with senior management, in theory, yes.

If you're in a startup with shares, I guess it indirectly does.

Either way, having engineers focus on more stimulating projects has its own intrisic value for the engineers themselves. Additionally, it reduces the likelihood of burnout because whether the business needs to know how much is automated is up the manager, as long as the team is delivering the agreed tasks by the deadline, the business doesn't necessarily need to know that the team had some slack. It's these slack moments testing, refactoring, and experimenting can happen - things often downplayed by business until stuff hits the fan.

Reply on news.ycombinator.com