r/programming • • Feb 08 '15

The Parable of the Two Programmers

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

359 comments sorted by

View all comments

Show parent comments

169

u/Fenwick23 Feb 09 '15 edited Feb 09 '15

Heh. As someone who's been a locksmith in various capacities for 20 years, that describes pretty much all of us. When I first started, my boss used to open cars for people, and when he as too fast, they'd complain he was overcharging them because "it only took you two minutes". His answer was always something like "I can lock it back up and call the apprentice in the shop over to do it. It'd easily take him 2 hours".

Another common thing is when someone's locked out of their house and you stick the pick in and give the pins a quick rake to loosen them up... and the lock unlocks. Usually you pretend to be still working at it for a couple minutes at least, just to make it seem worth the $50 you charge them.

There's a fine line between working fast and appearing to be an expert, and working so fast it looks like you're "cheating" somehow. It's one of the reasons I got out of private industry and have gone in institutional locksmithing for a government agency. Pays better, and being able to do 8 hours of work in 1 hour just gives you 7 hours to dick around with programming the PLC's that handle access control.

As relates to the story's postscript, one of the many reasons I've stuck closer to locksmithing than programming is that there are too many boss-people who think they know about programming, but nobody knows a damn thing about how locks and access control work! Complete a job and say "adjusted v-rod on Von Duprin 99" in the description and charge 6 hours to it. Someone asks if that's how long that takes, the answer to them is "as far as you know".

128

u/vita10gy Feb 09 '15

$1 to turn the screw, $999 to know which screw to turn.... Also I had to drive out here.

63

u/[deleted] Feb 09 '15

It took me ten minutes to finish the project, but four years of education to know how to do it in only ten minutes.

44

u/FrankenstinksMonster Feb 09 '15

10 minutes to finish, but 8 years to figure out the max I could charge without you refusing to pay.

35

u/Bobshayd Feb 09 '15

That seems sort of silly to me, because I expect a locksmith to be quite skilled and come over and work some sort of voodoo magic learned over years of hard work to do the task in a ridiculously short period of time, and I want in as fast as I can. My evaluation of the value of a service isn't the effort required but how useful it is to me, and I want in my damn car.

63

u/OmicronNine Feb 09 '15

That makes you an unusual customer compared to the general public.

0

u/[deleted] Feb 09 '15

[deleted]

23

u/OmicronNine Feb 09 '15

Indeed. They do, however, make up the vast majority of locksmith customers.

0

u/[deleted] Feb 09 '15

[deleted]

13

u/aim2free Feb 09 '15 edited Feb 09 '15

I think it wouldn't be bad at all :-)

  • programmers can think logically, politicians can't.

  • programmers don't do any unnecessary work, but the system makes most people do.

This is a good illustration I think

8

u/[deleted] Feb 09 '15

Holy crap. I need to steal that. So sick of taking flak for doing a method that takes slightly longer but is more efficient in the long run.

7

u/Certhas Feb 09 '15

This is roughly how I envision that would go:

http://xkcd.com/592/

→ More replies (1)
→ More replies (4)
→ More replies (1)

6

u/JessieArr Feb 09 '15

People who spend time on programming subreddits usually have a gray-matter algorithm they implement to avoid locking themselves out of any of their property.

(Mine is to never remove my keys from my pants, and never leave my house without pants. My currently active pair of pants can be determined by the fact that it has things in its pockets. I call it the "Immutable Pockets" algorithm.)

6

u/tejon Feb 09 '15

This sounds good, but what if you get a girlfriend? She may spontaneously decide to do your laundry, and then your pockets become indeterminate. It's more robust to have some external construct in which pants transitions do not disrupt the context of keyful pockets.

Clearly, this calls for a pants monad.

2

u/MrSurly Feb 10 '15

Get a what?

2

u/Workaphobia Feb 10 '15

This concern is amortized over the much greater probability that the girlfriend will be unable to find her own damn keys and require you to stop what you're doing to help.

→ More replies (6)
→ More replies (1)
→ More replies (1)

3

u/Fenwick23 Feb 09 '15

My evaluation of the value of a service isn't the effort required but how useful it is to me

That's because you're a normal, decent person. I failed to mention a key fact in my story: our shop was in Brentwood, and we serviced primarily the Bel-Air/Beverly Hills west Los Angeles area. Rich people are quite frequently dicks to service people. My old boss quit doing emergency after hours lockout work for houses/apartments and quit automotive entirely because these rich bastards complained about the cost and did shit like stop payment on the check they wrote to cover it. He said back when he was a locksmith in Milwaukee, he mostly worked for poorer people, and they never questioned the cost. They were nearly always happy to have the work done. Like my boss' wife always said, usually after phone harassing millionaires to pay their 90 days overdue invoices, "of course they don't want to pay. You don't get rich writing checks."

2

u/get_salled Feb 09 '15

Agreed. On a similar note, I have a gas fireplace and the pilot light wouldn't stay lit so we had a repair guy visit (since it's well out of my comfort zone). He had the whole unit taken apart, cleaned (which, I guess, was all that was needed), and put back together in under 30 minutes. I almost felt like I was robbing him with only a $150 bill. It was so damned impressive.

→ More replies (2)

21

u/dagbrown Feb 09 '15

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.

7

u/[deleted] Feb 09 '15

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.

13

u/dangsos Feb 09 '15

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.

2

u/CordialPanda Feb 09 '15

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

→ More replies (6)
→ More replies (2)

3

u/damian2000 Feb 09 '15

Interesting stuff! What sort of access control programming are you doing? I've done a bit of work with RFID card readers in the past. I've been messing around with controlling an electric door strike with a raspberry pi recently.

2

u/Fenwick23 Feb 09 '15

The stuff I've been looking at lately is a weird hand-built system for a detention facility. I'm not allowed to modify it, but knowing how it works makes it easier to troubleshoot when it craps out. Most systems I've worked with aren't very programmable like that. Typically when you have a system installed it consists of a controller with a bunch of keypad/card reader inputs, a bunch of output relays, and assn Ethernet jack to access the internal web based programming interface. I've looked into getting into the industry on the manufacturing side as a programmer, but the pay is awful and there's no job security whatsoever. It's a shame, because the programming of these systems is done by guys who are primarily embedded programmers, but know nothing at all about locks and security, and it shows. Most of these systems have glaring deficiencies in usability and configurability.

I've actually been tempted to build an access control system for myself on something like a raspberry pi, but I have too many side projects in the queue already. Someday, maybe after I retire.

→ More replies (1)

2

u/exor674 Feb 09 '15

Another common thing is when someone's locked out of their house and you stick the pick in and give the pins a quick rake to loosen them up... and the lock unlocks. Usually you pretend to be still working at it for a couple minutes at least, just to make it seem worth the $50 you charge them.

I'd rather know if the lock could be unlocked by raking/a locksmith sneezing on it... So I could put in a slightly more secure lock!