How chickens and programming are kind of related

I believe that everyone should work on a working farm for at least a month.  There are a few reasons for that.  Firstly, it would probably make a bunch of people shut up about a bunch of pointless things.  I heard one person say "a chicken is a person too" once.  That person has clearly never been around chickens in their full glory.  The person who said it had about a half dozen pet chickens.  "Pet" chickens (wearing diapers, for what it's worth) are not what chickens are truly like.  Chickens are vile creatures that poke in their own fecal matter looking for a scrap of something worth eating.  They are also cannibals.  Thankfully, they are yummy too and so they do have some redeeming qualities, none of which are present in their live state.

There's another thing that I think people should do.  Well, not quite people; programmers.  Every programmer should spend a month both as a system administrator and in front line tech support.  The reason for the former is that they really need to see what hell they put the sysadmins through, especially if there is a problem.  The other reason is because as a sys admin they would see what an application behaves like in a production environment.  Not just their application, but any application.  Things that go smoothly in development may not go smoothly in production and programmers should experience this so they can learn to build better applications.  And not only that, but also learn to use the tools that admins use to diagnose problems.  Tools like vmstat, top, strace, etc.

Programmers should also spend time in front-line tech support.  But the reason here is a little different.  It's not so they can learn to empathize with the support engineers (they already did that with the sys admins), but so they can learn what it is and is not supportable.  Programmers like to solve problems.  But more than that, it seems like they like to create them.  And so learning to say "no" to people is a big deal.  Well, not really "no", but "we don't support that."

Why is that a big deal?  Because people seem to like to be creative in how they work with software.  I know I do.  But a problem arises when problems arise.  Now you need to work with a support engineer to figure out just what went wrong.  People often complain about support engineers working off of a script.  But that's EXACTLY what they should be doing.  If you don't have a predictable environment, your support costs increase significantly.  Not only do your support engineers have to spend longer diagnosing a problem, but they'll probably have to bring in one of the programmers who's familiar with the system to diagnose that someone did something outside of what is supported.  Everyone loses.  So, programmers should spend some time on front-line support so they can see what people are doing wrong and actually make their software more restrictive, in some cases.  "We don't support that" is a valid response.  It is not done because people are lazy, it's because supporting every possible option or configuration means higher costs, which means more expensive software (even the free stuff).

It also works in home life:

Wife: Babe, the toilet's leaking
Me: I'm sorry, but I don't support that

(and chair manufacturers should have to sit in squeeky chairs all day long)

But what it really comes down to is that programmers affect a LOT of people.  Good programmers are not necessarily people who come up with borderline ethereal architectures, worthy of song and praise.  Good programmers are people who take look at all the things they affect; operations, support, customers, and build a system that balances the needs of as many stakeholders as possible.  And the only way to do that is to spend some time in the trenches.  Just like looking at a picture of a groomed Bantam rooster does not give you an accurate picture of the villainous chicken, simply working with code does not give you an accurate picture of the ecosystem in which you work.