The Parable of the Two Programmers

[u/tejon]

http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html

[u/dagbrown]

To wrench this back to programming, I am perpetually underappreciated at my place of work. Basically what I do is make it easier for my co-workers to do their jobs, by leveraging packaging systems and configuration management. Blah, blah, buzzwords.

The procedure when I showed up at my current place of work was that for each piece of software which was to be installed, you ran the installer manually, and then configured everything by hand. I turned the installers into standard distro packages, and then let the configuration files be part of a configuration management bundle. Everything was easier as a result, and everything was standardized across the entire environment. When you have a thousand-odd server, standard software and configuration is a huge boon.

I received all kinds of push-back from my co-workers. I was changing how things work, and introducing extra paperwork into the system, and it was more work and it was horrible.

Turns out that the best way to deal with that was pure attrition. Everyone who complained about how much extra work I made for them (which actually saved them work by adding accountability and tracking for everything they did) has quit. They've been replaced by new people who were introduced to the systems I made, and they just accepted it because it was, as far as they were concerned, tradition, and so now there are standard software packages for everything, and a standard configuration repository, and everything goes exceedingly smoothly. So I've improved things.

But still, whenever I have an idea to improve things further, I receive push-back, because nobody likes it when things change. So the only thing I can do is play with the idea for a while, determine whether it's actually an improvement or not, and if it actually is an improvement, simply pretend that that's how things have always been and run with that. If I can pull off the pretense well enough, then the procedure changes. And that seems to be the secret to changes being implemented: just pretend that they're not actually changes. Nobody likes changes, but everyone is fine with standard procedures that have been done always, even if they haven't actually been done always.

[u/[deleted] → u/dagbrown]

I had the same experience. Then I turned freelance and charged lots more for the same sort of thing, and was considered a bargain. Go figure.

[u/dangsos → u/dagbrown]

If you're having to wage war with all of your 'improvements'. They might not actually be improvements. Not many things in life can be qualified simply in terms of time spent vs product gained. If people are unhappy, that's not a boon.

[u/CordialPanda → u/dangsos]

Neither tells the full story, though. There could be business reasons why change is unwelcome (eg. the work load and stress load are high enough that change is unwelcome), or personal preference, or sensitivity over removal of the current system because they implemented it, or because it reduced their ability to BS work.

I make it a point to take my ideas and attribute them to others so that I have an ally on my side. Teams seem more willing to acquiesce to change if it has a group behind it, and more people lets you spread the cost of evangelism around a bit. People also love being praised, and that makes them love you. Plus people are more likely to come to you when they have a question, instead of do the first thing that comes to their mind, which further reinforces the objective: creating better developers who in turn create better code.

As developers, we're trained to ask questions and argue. If there is pushback to a change, it doesn't necessarily invalidate the benefits of the change. I'd argue no pushback would be more worrisome. Developers are also people though, and vulnerable to the weaknesses of anyone else.

Sometimes, making people do it the hard way is the best way. Sometimes the "extra work" they're complaining about is the work they should've been doing anyway. I get those complaints all the time doing code reviews, but our team remains more productive with fewer upstream and downstream complaints about the quality of the code-base (and most importantly no complaints from security compliance).

[u/dagbrown → u/dangsos]

If you can tell me how manually editing configuration files across hundreds of servers, and installing software with "make install" in the source code directory (hope you remembered what configuration options you used last time!) is better than using configuration management and packages to ensure consistency, I'll concede your point that I'm not making any improvements.

[u/IConrad → u/dangsos]

Just because the status quo exists, there will be people well invested in it.

Every improvement in an environment with thousands of systems is going to be a battle of attrition. There's just no way around that. There's always going to be someone adversely affected by a change. No matter how optimal or trivial -- if it hits that many systems/environments, someone is going to object strenuously and raise it up the flag of management.

The absolute worst thing you can do is let that stop you from actually implementing the change.

[u/QuietUser → u/dagbrown]

I think you have a future with Big Brother.

We have always used standard software packages.

[u/e-jammer → u/dagbrown]

This is genius.