The cost of ‘the customer is always right’

I came across an article today entitled ‘Fake it ’til you make it’ is psychologically damaging, it’s an interesting read (I like learning about human behavior, i’m weird like that). One statement stood out to me (2nd excerpt below), mostly because this is the first time i’ve seen the topic of the cost (meaning money, for losing good employees, lack of employee engagement in their job, etc…) of requiring staff, such as those in the hospitality business, to act as if the customer is always right even though we ALL know this is bullshit.

Hotel staff, for instance, might wield tight-lipped smiles and impeccable manners during exchanges with even the most disagreeable travelers. Kouchaki calls this “surface acting”—common behavior for those whose jobs depend on politeness and constant restraint. “This type of emotional labor has consequences,”

 

It seems to be true that to act in accordance with one’s own self, emotions, and values is a fundamental aspect of well-being,” Kouchaki says. “Leaders might want to factor that in. The knowledge that inauthentic behavior has costs and that prosocial behavior”—like assisting or mentoring a colleague—“increases moral self-regard—this is something leaders might consider when designing their organizations.

Automobiles: a new landscape for programmers

In this frank and interesting discussion about the future of automobiles and the role they will play in the Green (environmental conservation) Movement as well as resolving the ever growing problem of traffic gridlock, Bill Ford discusses his vision of communication and networking between every vehicle on the road. Literally your car talking to mine, telling it things about traffic and road conditions. This vision will be accomplished through software, running on every car on the road, and the world will look to programmers like us to develop that software. The future of your programming career could quite literally be in your car.

Where Do Good Ideas Come From: Just Ask Steven Johnson

We all have good idea’s, at least we would like to think so. But have you ever really thought of “how” you get a good idea? I mean really really thought about it?

Maybe “good” ideas are cultivated over time as each of our unique experiences, both past and present, come together in a connected manner to bring meaning to things we care about and are interested in.

In this intriguing and insightful talk, given by Steven Johnson at TED 2010 in England, this exact question is raised. It’s well worth the 18 minutes of your life you will spent watching his talk.

There is never only “one right way” to develop something

A great statement from Scott Guthrie in his article entitled About Technical Debates

There is never only “one right way” to develop something. As an opening interview question I sometimes ask people to sort an array of numbers in the most efficient way they can. Most people don’t do well with it.

This is usually not because they don’t know sort algorithms, but rather because they never think to ask the scenarios and requirements behind it – which is critical to understanding the most efficient way to do it. How big is the sequence of numbers? How random is the typical number sequence (is it sometimes already mostly sorted, how big is the spread of numbers, are the numbers all unique, do duplicates cluster together)? How parallel is the computer architecture? Can you allocate memory as part of the sort or must it be constant? Etc.

These are important questions to ask because the most efficient and optimal way to sort an array of numbers depends on understanding the answers

Growing stronger by stretching yourself

Another great statement from Scott Guthrie

Developers (good and bad) can grow stronger by stretching themselves and learning new ideas and approaches. Even if they ultimately don’t use something new directly, the act of learning it can sharpen them in positive ways.

Change is constant in the technology industry. Change can be scary. Whether you get overwhelmed by change, though, ultimately comes down to whether you let yourself be overwhelmed. Don’t stress about having to stop and suddenly learn a bunch of new things – rarely do you have to.

The best approach to avoid being overwhelmed is to be pragmatic, stay reasonably informed about a broad set of things at a high-level (not just technologies and tools but also methodologies), and have the confidence to know that if it is important to learn a new technology, then your existing development skills will mostly transition and help. Syntax and APIs are rarely the most important thing anyway when it comes to development – problem solving, customer empathy/engagement, and the ability to stay focused and disciplined on a project are much more valuable.

Learning Fatigue, Sustainable Pace, and a Programmers Death March

Have you ever been at the gym, running on a treadmill, while the guy next to you (who is in much better shape I might add) is not only running faster than you but appears to be doing it with ease. You adjust your speed trying keep up, it works for awhile and you feel good about it, but eventually fatigue sets in and you find it increasingly more difficult to stay on pace. Eventually you have to slow down to something thats “sustainable”, something you can keep up for your entire workout.

Learning (and working) can, and often is, just like this.  In the sequel to Alice’s Adventures In Wonderland, Through the Looking-Glass by Lewis Carroll, the Red Queen says “it takes all the running you can do, to keep in the same place”, eventually becoming known as The Red Queen’s Hypothesis

An excellent article written by 37 Signals entitled Sleep deprivation is not a badge of honor offers some great insight into this analogy.

Learning Fatigue

In the software development world learning is something we as programmers/geeks are, or at lease should be, constantly doing. I read articles/blog posts/chapters in books on a daily basis and still find it nearly impossible to keep up with the ever increasing complexities of our industry.

This can feel very much like being on the treadmill, trying to keep up with that guy next to you. Now don’t get me wrong, I love to learn new things and am constantly fascinated by all the incredibly cool stuff thats coming out these days, but I do need to have balance, one that is “sustainable” (a.k.a Sustainable Pace) otherwise I will suffer from Learning Fatigue.

In a very interesting article written by Dr. Bruce D. Perry, MD. Ph. D. entitled How the Brain Learns Best he discusses Learning Fatigue (what is referred to as Neural System Fatigue).

Through the process of education, we are trying literally to change the brain…Learning requires attention. And attention is mediated by specific parts of the brain. Yet, neural systems fatigue quickly, actually within minutes.

With three to five minutes of sustained activity, neurons become “less responsive”; they need a rest (not unlike your muscles when you lift weights). They can recover within minutes too, but when they are stimulated in a sustained way, they just are not as efficient.

Sustainable Pace

To combat Learning Fatigue, and the guy next to us on the treadmill, we can use the wisdom found in the old parable The Toroise and the Hare:

Slow and Steady Wins the Race

We need to be learning daily, in small consumable chunks, in order to prevent burn-out while maximizing our retention of the ever-increasing complex topics we study and grow to love. This is called Sustainable Pace and its something I believe in, preach about, and practice religiously.

A Programmers Death March

So lets jump back to the Treadmill example at the beginning of this article and make some small changes. The story starts the same way, you’re on the treadmill with Mr. America next to you and you’re trying to keep up. But this time it’s different, this time your boss is standing behind you telling you that you need to “get it done” because his boss put a finger on a day in his calendar and said “it HAS to be done by this day” (with little or no understanding of what it will really take to make that deadline).

So there you are, trying to keep up, knowing that you might not be able to and even thinking that you’re just going to turn around and tell your boss to go screw himself because you have decided to quit your career and sell hot dogs out of a buggy downtown. Sure this example is goofy, but while we chuckle nearly all of us are saying to ourselves “i’ve been there”. This is the “Programmers Death March”, it’s the exact opposite of Sustainable Pace, and it will lead you to either having a heart attack or quitting your career (or both).

So what do we do to avoid the Death March? We have to be realistic about what we can achive in a given time span. In software development we often don’t know how close to finishing a project we really are: the requirements change, the technology available to us changes, and our skills change. The answer is tocommunicate with stakeholders openly, honestly, and most important REGULARLY. This last piece, the part about regular communication, is an Agile Development pholosophy cornerstone. If you aren’t familiar with Agile then definetely take a look, much of it is about how to make your work and ultimately your career more productive and enjoyable.

In addition we cannot forget that ultimately we are the ones in charge, while this may seem rediculous it is actually true. If you slowed down the treadmill and then told your boss that it was necessary in order to be able to complete the project at all, much less on time, there isn’t much he could or would do about it. I strongly encourage you to read the book The Inmates are Running the Asylm by Alan Cooper, its a book about Software Developers taking charge and it will change you’re perspective in many ways.