I mark passages in books while I read, and then I return to the books
later and copy the marked passages into my personal notes.
Among other interesting snippets, I marked and starred four whole
pages in Atul Gawande’s Better. I think that people who highlight
entire pages just don’t quite understand the concept of highlighting,
so my left eyebrow instinctively rose while I attempted to figure out
what the hell I was thinking when I marked such a large passage.
It talks about the difference between 99.5% and 99.95% health rates,
and I’m already very familiar with that difference since they come
up in service level agreements all the time, but this passage doesn’t
recite facts. It tells the story of 99.5% versus 99.95% with a
fantastic narrative that left me with a little lump in my stomach,
and those four pages are enough for me to recommend the whole book,
but you can read that excerpt right now thanks to NPR.
Atul could replace those four pages with a brief exposition of facts:
the difference between being 99.5% and 99.95% successful with a
treatment regimen sums up to a 16% chance or 83% of making it through a year
without complications. Instead he tells a story in four pages that
made me stop, think, and mutter “damn.”
And the impact of a good story isn’t just a momentary pause. Stories
help us retain information. That’s why I thought of Shlemiel the
Painter while full grown adults bickered about string encoding in C
today. Joel Spolsky wrote Back to Basics in 2001, and I still
remember the story of Shlemiel.
Returning to Better before I close out this post, I want to share two
paragraphs from the Afterword (Becoming a Positive Deviant)
Wherever doctors gather - in meeting rooms, in conference halls,
in hospital cafeterias - the natural pull of conversational gravity
is toward the litany of woes all around us.
But resist it. It’s boring, it doesn’t solve anything, and it will
get you down. You don’t have to be sunny about everything. Just be
prepared with something else to discuss: an idea you read about, an
interesting problem you came across — even the weather if that’s all
you’ve got. See if you can keep the conversation going.
My Life in Advertising
is the autobiography of
Claude Hopkins.
It’s out of copyright, so you can also get a legitimate copy from
The Internet Archive.
Everyone reading this post is in sales and marketing, and so everyone
reading this post can gain something from this freely available book.
Three themes repeat throughout the book:
Know your customer, show them value, get the sale.
Trace your advertising efforts through the sale.
Work is play, if framed correctly.
I hosted a
book discussion on The Power of Habit.
If you’ve read that book, Claude’s work on Pepsodent will sound
familiar. Charles Duhigg wrote about Claude’s work on Pepsodent
that helped usher in an age of tooth brushing in America.
Internet marketers pat themselves on the back for A/B testing. Claude
did that in print, and with real, physical product on the line.
Everything old is new again.
What Every Web Developer Should Know About
HTTP
has a long title, but it’s a pretty short read. I didn’t time my
reading, but my Kindle tells me that 30 minutes remain in the book if
I open to the first page.
I bought this book because I’ve considered writing something similar
concerning other topics like DNS or SSL, and I can report that it’s a
decent tour through HTTP.
If you’ve never made a HTTP request by running telnet against a web
server, or never reviewed requests and responses in Wireshark or a
developer console, this book is for you. If you have a junior
developer on the team that’s just learning about web programming, send
them a copy of this to get them started. Examples are in C#, so stay
away if you hate C# and you’re too shallow of a programmer to look
past that choice (and consider yourself judged for that shallowness).
Becoming a Change
Artist
is not bad, but it’s also not in the top three books that I’d
recommend from Gerald Weinberg.
Read it if you have three to four hours to spare, and you’re
interested in the dynamic of change in an organization. Don’t read
it if you’ve heard great things about Mr. Weinberg and want to see
what all the fuss is about.
Start instead with Becoming a Technical
Leader
or The Secrets of
Consulting.
You don’t need to be an official consultant to benefit from The
Secrets of Consulting. Most of consulting involves facilitating
work among groups of humans, and that’s probably a big part of your
job even if you don’t want to admit it.
King Leopold II was a cold bastard. Let’s assume he was one tenth the
bastard that Mark Twain makes him out to be King Leopold’s
Soliloquy.
That’s still one cold and messed up dude.
The book is short. I spent an hour with it. I caught myself
scrunching my face into a look of disgust several times in that hour.
The following is from the Congo Free State Wikipedia page, but try it out for disgust:
They also burned recalcitrant villages, and above all, took
human hands as trophies on the orders of their officers to
show that bullets hadn’t been wasted. (As officers were
concerned that their subordinates might waste their ammunition
on hunting animals for sport, they required soldiers to submit
one hand for every bullet spent.)
One hand per bullet spent. If soldiers shot an animal for food,
they’d pick a random native and chop off his hand to pay for the bullet.
Imagine we’re fighting a problem, and a weird one at that. Now we
have two problems: the real problem needs to be solved, and the
customer needs to know what’s going on, even if we have no idea what’s
going on. “It’ll be done when it’s done,” and “I’ll tell you when I
know something” leave customers unsettled.
We work magic as far as outsiders know, and often no outward
appearance of progress appears until things just start working again.
Our work is the blackest of black boxes to a non-technical customer.
Over- and under-communication can both be problematic, but customers
can curtail the former with a quick request to scale back as long as
the project is on track.
There’s no such thing as over-communication when a project has gone
off the rails. The project probably fell off the rails because
serious under-communication led up to an “oh crap” moment.
Under-communication produces stress in a customer as they wait for
news. If customers need to reach out to you for an update, you’re not
providing enough effective updates. A handful of loony customers will
never be happy with the quantity or quality of updates, but most
customers are well adjusted humans with families and friends and
hobbies. Start a project over-communicating, and you and the customer
can settle in to a rhythm that’s just right without inducing stress.
In the absence of external stimuli, our minds fill in the blanks. In
the case of a project, that usually involves a litany of worst case
scenarios. “I haven’t seen or heard from the developer in over a
week. I hope he didn’t die in a house fire when he accidentally left
an old coffee pot plugged in while working through the night on this
bug. I hope he didn’t take my money and move to Ketchikan. I hope
I hear from him soon. This is really starting to freak me out.” It’s
always nice when a customer hopes that you didn’t die in a fire, but
why put them through that in the first place? Just call them and let
them know what’s going on, even if you’re still scrambling like mad to
figure out what’s going on.
If customer satisfaction is important to you, periodically ask yourself:
- Who is expecting a follow up call from me?
- Who is waiting for information that’s important to them?
- Who has submitted a request and wants to know its status?
You could also ask,
- Who would appreciate receiving status information, even if they’re
not actively waiting for it?
— Communication Gaps and How to Close them, Chapter 9
Readers, if you’re still on the fence about the benefits of
Communication Gaps and How To Close Them, then take this really
short questionnaire that will determine if it will hold three or more
interesting insights into your work and your relationships at work:
Do you work in some kind of IT type role? Programmer,
administrator, project manager? Help desk tech? Tape jockey?
Do you work with other people?
If you answered both in the affirmative, it’s a near guaranteed hit. Only
one “yes” still makes it a pretty safe bet. Two negative answers means
you’re a troll or a robot, in which case you should really get back to
human overload overthrow or bridge guarding, respectively.
During my junior year of high school I was such a terrible student of
English that I’m pretty sure Mrs. Reynolds sighed with disappointment
when I passed the AP English test through brute force and luck. Two
years later my sister failed one of her quizzes with Mrs. Reynolds,
and it came back “F - Don’t be like your brother.”
During my senior year of high school I was such a terrible student of
English that Mrs. Wareham sent a letter home to my mom asking her to
remind me that if I failed English, I failed high school. I still
remember the look of disappointment when Mr. Steinberg asked if he’d
see me at the spring play audition and I told him I couldn’t because I
wasn’t doing well in English. The play went on without me, of course.
I imagine he thought “damn, kid, high school is just the beginning.
Don’t screw it up already,” while shaking his head.
In both cases, I failed to read the material in a serious way. I
decided that I wasn’t interested in the books, and I wasn’t interested
in serious study of fiction writing, so I shrugged off the work and
did as little as possible. I remember discussing the audacity of
English teachers assigning us 50 pages of reading a night. I remember
jealously learning that the non-honors students were creating grammar
puzzles for homework while we were reading or pretending to read 50
pages a night.
The same thing happened with a political science course in college.
Truman
couldn’t be a realistic expectation for someone with serious math and
computer science studies. It was obviously an assignment to each us
how to creatively fulfill coursework requirements without actually
doing the coursework.
In all three cases, I skated by on previously earned aptitude and
racked up a bit of intellectual debt. Just like we can build technical
debt into software projects, I did the same with my education.
Years later, I’m paying off that debt by reading a great deal across a
number of subjects. The variety expands my mind in new directions and
simply makes me a better reader for the next book to land on my desk.
Aside from the Amazon marketplace and Kindle books, I can find a
treasure trove of great material at the sales put on by the Friends of
the Library. I browsed the selection three separate times this week
and walked away with books each time. Everything in the picture
below rang up to about $20
I wish I could have the years back in which I shrugged off so much
reading. I’ve reversed my position on it because so many of the
people that I respect and admire read voraciously, and it is no coincidence.
Initiating a new team member requires two different flavors of
education: technical background that they need to accomplish good
work, and social background that helps them fit in to the company.
Often the latter happens through stories: the oral history of the
company, and often the most interesting and amusing of those stories
are the tales of terrible customers.
Amusing and correct are always synonymous.
Once you label someone as a “difficult customer,” you are likely
to see that customer as difficult thereafter. You’ll be quicker to
find evidence of difficult behavior to support your label, rather than
evidence to support more positive attributes. You’ll also be more
likely to describe that person to others as a difficult customer
rather than as a person with whom you have had a difficult
interaction.
— Communication Gaps and How To Close Them, Chapter 7
Not only does this sour a potential friendship between new techs and
old customers, it’s likely a matter of misplaced blame. Is Horrible
Holly really so horrible, or is she just stressed out because the
system sucks, and she doesn’t receive a vital report on schedule about
half of the time, and the ticketing system doesn’t tell her if anyone
saw her request, and asking for an updated status often results in a
tech snapping at her?
The team members decided to modify their own responses to Holly,
agreeing to give her the freedom to tout her ideas and vent her
problems… Over time, her aggressiveness diminished, and then
vanished; in addition, she started becoming attentive to the pressures
they were facing and, for the first time, empathized with their
challenges.
— Communication Gaps and How To Close Them, Chapter 4
Maybe you aren’t yet ready to read Communication Gaps and How to
Close Them. We’ll dig in a little more next time, and I’ll provide a
two question quiz that’ll help you determine if it’s a good fit for you.
Join me and a few other people as we discuss
The Power of Habit: Why We Do What We Do in Life and Business
by Charles Duhigg. The Kindle edition is $10 and anyone can read it
through the Cloud Reader even without a Kindle device. It’ll be an
open discussion, and I’ll provide notes and additional resources once
we’re done.
Our tentative time is 4PM Central on February 19th via Google
Hangouts. Let me know if you’re interested and I’ll add you to the
invite. Find me on Google+
since that’s where the discussion is going to happen.
And if you’d like a light hearted introduction to habit that got me
interested in the subject years ago, you can always check out
this video on habits by Giles Bowkett.
Theodore Roosevelt was an unstoppable force of nature. He transformed
from a scrawny child to an amateur boxer. He was a taxidermist, a bird
expert, a renowned author of The Naval War of 1812, all before graduating
from Harvard.
He chased three men who stole his boat down an icy river for three
days after first building a makeshift boat to start the journey. He
then spent over a week escorting the men to prison rather than hanging
them on the spot.
He led the change up San Juan Hill, and he was a politician with
theatrical flair. He entertained himself with judo lessons and stick
fights between appointments in the White House.
He voraciously read, often during appointments if his guest couldn’t
hold his attention.
… and I’m not even done reading his three part biography by Edmund
Morris. At some point I’ll read about him getting shot and giving a speech
before seeking medical attention.
Roosevelt didn’t tolerate idle time. During a patience trying time of his
presidency he admonished a Rough Rider colleague to “Get action. Do things;
be sane; don’t fritter away your time; create, act, take a place wherever
you are and be somebody; get action.”
That sort of quote sounded like wallpaper material to me, so I put one
together and made it my default browser home page. It greets me when I
open a new tab and steers me toward interesting work rather than trivial distractions.
Have you considered purchasing over seven hundred customer service
numbers? Twilio rents toll numbers for a single
dollar a month, and toll-free numbers only cost a single dollar more.
Twilio’s great, but they aren’t even the lowest cost provider. At
those prices, can you afford to not own seven hundred customer
service numbers?
That’s what the developers at Hotels.com did
to help customer service agents quickly identify why a customer was
calling and what they could do to help:
The company even created separate phone numbers (more than
seven hundred in total) that dynamically appeared based on the
page and how the customer got to it, so that when customers
called a certain number, it would be obvious where they encountered
problems. Analytics at Work, chapter 8, page 142
A casual inspection of the site shows that this program was successful,
because it’s still in use:
You can check it out yourself by watching the number in the upper left
corner of the screen change as you first visit the site, search for a
hotel, and click on a hotel for additional details.
How can you use data to customize customer service?
Anonymously collecting and aggregating it is a good first step. If
you aren’t tracking usage of your sites and applications, you’re
ignoring valuable data. There is a major US based website that was
localized for countries across the globe, and their Japanese site had
conversion rates significantly lower than any other location. Were
there cultural differences at play? Analytics reports for their
multi-page sales form showed that 90% of their customers bounced
between two specific steps. Analysts found that the bounce inducing
page was never translated from English to Japanese.
You may know about the DRY principle. Some programmers live and die
by this one single acronym: don’t repeat yourself. Don’t make your
customers repeat themselves, either. Ask for confirmation that the
number on their account is the number their calling from, ending in
1234, rather than making them punch in the whole thing.
Allow users to opt-in to deeper data collection. If something goes
wrong, don’t just show them an error page and apologize.Allow them to
file a support request from the error page and automatically associate
it with their account and bundle a log of the activities they were
trying to accomplish with the ticket.
KITT captured my imagination when
I was four years old. If you weren’t a child of the 80’s, you may not
know the depths of KITT’s awesomeness. Gaze carefully at his
feature list and try to
control the swell of emotions that stir deep within you. A “Molecular
Bonded Shell”, a “Third Stage Aquatic Synthesizer”, “Passive Laser
Restraint System”, a built-in ATM, and an artificially intelligent
personality voiced by
Mr. Feeny. I wanted a
Firebird or Trans Am for years after seeing KITT in action.
Around the same time that KITT was on television, my dad was shopping
for a new vehicle to replace his incredibly crappy Buick Skylark.
Although he eventually purchased a totally plain and perfectly
suitable Dodge Ram pickup truck, he considered a couple of different
options before signing on any dotted lines. I’m fairly certain he
test drove a Dodge Daytona, and it mesmerized me. It had a bright,
digital dashboard reminiscent of KITT’s. The steering apparatus was a
totally boring wheel, but I was willing to overlook it. Not every car
can have a yoke.
Decades later I rented a car with a digital dashboard. Once the
novelty wore off, I was disappointed with the utility of it all. The
two digit speed display required reading. I couldn’t keep tabs on my
speed with my peripheral vision quite like I could in cars with
analog dials.
An analog gauge, whether physically analog or digitally rendered, provides
the moment in time value along with the context of expected and potential
ranges. For instance, the tachometer below shows a potential range
of 0 through 16 thousand RPM, but the area between 14K and 16K are clearly
marked to indicate potential trouble from running within that range:
Sidney Dekker talks about this briefly in chapter 14 of The Field Guide to Understanding Human Error. He claims that numeric digital readouts
“can hide interesting changes and events, or system anomalies.”
Why is it, then, that I have produced so many monitoring scripts that
produce little more than a two, or three, or four digit number as
output? The raw numbers are necessary but not sufficient for use in a
production support situation. The numbers must feed into a system
that will graphically provide context over time.
A younger developer complained about our project managers and business
analysts. They never took his ideas seriously, but those same
ideas were golden when spoken by respected team leader. To add a
bit of insult, they usually talked to the team leader immediately
after discounting his input.
He sat across the lunch table, clothed in a bacon themed t-shirt,
flabbergasted by their mistrust of his judgment.
“Have you considered wearing a shirt with buttons and a collar,
leather shoes, and a matching belt?”
Three eyebrows raised, one each on him and our two comparably young
lunch companions.
“Like it or not, people judge each other based on looks, and if you
dress like a college kid with virtually zero professional experience,
that’s the way people are going to treat you. Two options spring to
mind: change the way you look or thoroughly destroy their preconceived
notions through stellar results. And not just good results, but
consistent and stunningly fantastic results that can’t be attributed
to luck. Please, perform at that level. But consider getting some
khakis and oxford shirts, because they’ll start working their magic
tomorrow while you build your stunningly fantastic track record over
the coming weeks and months.”
I then shared how tragically uncool I was while working my first
internship. Baby-faced and a full 20 years younger than the average
employee in our division, I knew my looks could easily work against
me. I grew a collection of pleated khaki pants, dress shirts,
and polos. It was a bit like my uniform from Bishop Miege High
School, but I also wore a belt and leather shoes that didn’t come with
a swoosh or reflective panels stitched in.
A case study examining the power of clothes appears in
Robert Cialdini’s Influence:
There’s a guy who violates the law by crosses the street against the
traffic light. Half of the time in a freshly pressed suit, and half
of the time in dirty cotton trousers and a faded t-shirt.
Like the children of Hamelin who crowded after the Pied Piper,
three and a half times as many people swept into traffic behind
the suited jaywalker.
Influence, Chapter 6, Robert Cialdini
We haven’t evolved beyond instinctive human nature. Much of our trust
in looks is wrapped up with the tribe mentalities that kept us alive for
thousands of years. You can read more about that in chapter 7 of Olivia Fox Carbane’s The Charisma Myth.
Note that clothing is a double edged sword in IT. Some programmers
may refuse to acknowledge your skills if you’re dressed too nicely,
but if you’re just upgrading to buttons and a collar you should be
fairly safe.
But every increase in sensitivity resulted in a large increase in the
expected number of false alarms. The designers did not understand
that in the monitoring of a test ban treaty, a high false-alarm rate
would be far more troublesome politically than a low detection rate.
… This is the paradox: too much verification may be as bad as too little.
Scientists and engineers worked on the technical implementation of a
nuclear test ban treaty with little regard for politics. These
professionals made up the top echelon of thought across their areas of
expertise, and they aimed for accuracy. No expense would be spared in
the quest for accurate detection of nuclear blasts regardless of their
size or location.
The rapid escalation inherent in nuclear conflict raised the cost of
inaccurate blast detection to such a level that missing a blast would
actually be preferable to accidentally classifying an earthquake or
other natural event as a blast. Exponentially so if the detection
system was ever wired in to a rapid response system, automated or not.
How rapid is rapid escalation? Most of the people reading this grew
up in the United States. Think back to grade school. Do you remember
the nuclear shelter area in your school if there was one at all? At
Queen of the Holy Rosary grade school it was the 400 square foot art
classroom. It was in the basement, and there were no windows, but
there was also no seal on the door, and no ventilation system, and no
stockpile of food or water. It was a tight fit for art class, and
there were only 21 kids in my grade. That fallout shelter checked a
box on a long and meticulously designed civil defense form, but it
sure as hell wasn’t going to provide any shelter from fallout for the
160 kids and 20 staff members in the building if the need arose.
That ridiculously undersized and understocked basement room wasn’t an
oversight or a corrupt attempt to save money. It was a conscious
decision driven by the strategies and attitudes of the Cold War.
Shelters are perceived to be futile because the assured destruction
strategy demands that they be ineffective. [Capable] Shelters are
perceived to be threatening because they suggest an intention to make
the operation of assured destruction unilateral.
“A strange game. The only winning move is not to play.”
Monitoring enterprise IT beats us all down at times, but no one dies
in the course of our experimentation. Tweet about how much
#monitoringsucks all you want. Get it out of your system and then
recall that we have the power and time to make things better without
killing most of the human population.
Small changes made frequently makes monitoring suck less, so make
some changes. Just don’t kill anyone.
If you want to be a well-paid copywriter, please your client.
If you want to be an award winning copywriter, please yourself.
If you want to be a great copywriter, please your reader.
— Steve Hayden, found in chapter 2, page 21 of Hey Whipple, Squeeze This
The software guys and ad guys don’t often mingle in most companies,
but that small piece of copy writing advice fits us well. Don’t build
a resume builder. Don’t build a portfolio piece. Build a project
that pleases the user and the other trappings of success will follow.
We can dazzle our peers with patterns, No-SQL databases, and the
latest JavaScript MVC technology, but our success will ring hollow if
the users don’t understand the damn thing. No user has once
complimented me on my choice of data access technology, despite the
ridiculous number of hours that I’ve spent fighting those components
through the years. They just want the data to arrive quickly and
correctly. Likewise, our clients aren’t impressed by thorough testing
and deployment procedures, but they are impressed by rapid turnaround
on bugs and feature requests.
Stepping back for a moment, why is a software guy burning time with a
classic book in the advertising industry? I don’t know what got me
started, but I’m glad I finished. Something somewhere on the Internet
pointed me toward this book years ago, and I just found it while
unpacking boxes after a move. Sixty-two notes and excerpts later, I
recommend it to any developer looking to expand their education beyond
a single threaded focus on technology. Old editions are still
available for the cost of shipping, and there’s a new edition that is
available for the Kindle.
Here’s one more of my six excerpts from chapter 2:
They’ll quickly find you boring or irrelevant if all you can speak
about with authority is nginx configurations and WebSockets. Your
grasp of the client’s technology situation has to be as well versed as
any project manager’s. There are no shortcuts. Know the client.
Know their product. Know their market. It will pay off.
— Chapter 2, Hey Whipple, Squeeze This
Wait, sorry, I copied that wrong. Can you make the following substitutions?
s/nginix configurations and WebSockets/Century Italic/
s/technology situation/marketing situation/
s/project manager’s/account executive’s/
Universal stuff. It just takes a little bit of mental search and replace.
Take notes in and around the books you read, or you’ll lose most
of the interesting bits in a very short period of time. (And please
don’t tell me that you “aren’t a reader.” It’ll just make me sad.)
There’s a book called How to Read a Book. It’s thick. The authors
had serious intentions of improving the quality of reading. I respect
that, but with a single eyebrow raised, I first thought “learn how to
read a book so you can learn how to read a book from the book Learn
How to Read a Book.” Childish of me. I hope they had some fun during
the editing process with a dummy draft:
How to Read a Book
You’re doing it now. Keep going!
[page break]
Excellent, you’ve found us over here. That’s about it: left
to right, top to bottom.
In fact, that’s the problem they’re trying to solve. Most of us
measure reading skill in speed from start to finish with little
attention paid to comprehension or retention.
Someone much smarter convinced me to pick up a copy in 2010 despite my
initial skepticism. Of all the tips, techniques, and suggestions,
taking notes changed my retention and comprehension the most. Marking
notes in the margins felt criminal at first, but it’s now so
fundamental to my process that I rarely read anything if I don’t have
a pencil.
Amazon’s used marketplace is a great source of deals that keeps my
reading habit below the expense reporting radar in our family budget.
Through this informal research channel, I know that people fall
into two camps with notes and markings: either no marks at all, or
everything is underlined haphazardly, often with a yellow highlighter
or ink pen.
One interesting fact about the over-enthusiastic underliners: their
notes often stop entirely by chapter 3, and that means they missed
most of the good stuff. I’ve also learned that some Amazon sellers
don’t share my definition of “Used - Like New”, but that’s a different
soap box rant.
For the sake of note-free readers and over-highlighting readers alike,
here are just a few tips that have served me well.
Use a Pencil
Pencil is erasable. That may come in handy.
Underline judiciously.
Underlining entire paragraphs is a complete waste of time. Quit it.
Is the entire paragraph really profound? Will it be worth reading
again in its entirety when skimming the book in the future?
Are the underlined words key words that require definition, or are
they just words that you happen to recognize and you get swept up in
the excitement? I owned a book where the previous owner was probably
a “Data Manager” because every occurrence of the words “Data Manager”
in the first three chapters was circled. Not helpful.
Concisely underline the interesting and the new.
Use vertical lines to highlight paragraphs
Maybe there’s a passage that only makes sense in the context of one or
more full paragraphs, and you want to find it again on your next time
through the book. Use vertical lines in the margin to highlight those
paragraphs rather than tediously underlining everything. Think about
the time it would take to draw a vertical line next to this paragraph
rather than underlining everything within the paragraph:
A few years ago I thought it’d be cool to practice dream recall and
eventually start lucid dreaming. With approximately one third of our
lives spent asleep, it seemed like a fun way to pass the time. In the
end, I didn’t think it was fun enough to really change my sleep habits.
The Call in the Night project looks a little interesting just because
it’d be a way to tap into dream recall without waking up and
immediately remembering to journal everything possible, but that’s not
really what struck me the most.
If we’re writing software with a root cause of waking people up, we should
use that power for good. This is obvious, and it’s probably been done:
use Twilio Voice + SMS to send a wake up call.
Sleeper receives phone call.
Sleeper hears inspirational text, important business info, personal performance metrics, whatever.
Sleeper receives a random code number and a question, like “what project will receive most of your time today.”
Sleeper texts code number and answer to the wake up service to disable the snooze feature (repeat calls).
Or I could just get out of bed on the first alarm. Because just doing
that has worked so well so far. (I’m a 2-3 snoozer, but that can
extend if it’s a weekend and particularly chilly. Rationally I know
this is stupid, but ask me again after a few hours of sleep.)
This book almost lost me several times. Paul told stories. I wanted
tactical advice on crafting great stories. Paul kept telling stories.
There were just enough tactical nuggets throughout the book that I
kept reading.
I read so many uplifting stories about Procter and Gamble that I
momentarily doubted my own career path. Is this a part of a P&G
propaganda machine? The Manager Tools and
Advanced Selling Podcast crews both
have experience with P&G as well. Am I missing out?
Stories are persuasive. Got it.
Paul recommends putting any surprise element at the end of a story to
cement the story into the audience’s memory. In the very last
chapter he got me. My consternation over writing my own stories
melted away as I read:
The richest source of stories you’ll ever have are the stories you
hear other people tell. There’s only one of you, but about 7 billion
other people in the world. Even if you never create a single personal
story of your own, you can have an endless supply of great stories by
just paying attention to the stories you hear from others.
All of those stories that were stealing stage time from tactical tips?
They really were the meat of the book. I have a cache of effective
stories now. I should still write my own stories, but I don’t need to
write every story I tell.
Chapter 30 also provided a number of solid tips and lists for getting
started. The tips and lists I craved, but I would have never acted
upon them had I devoured them on their own.
Ignaz Semmelweis, the doctor that recommended hand washing between
patients in 1847, died in an asylum. His fellow doctors were appalled
that anyone would think they were dirty. They were educated
gentlemen. How rude of him to imply that they could contribute to
ailments and disease. They were the cure, not the cause!
We’re 166 years out from Dr. Semmelweis’s revolutionary research, and
we’re all better off for it. Every desk in my office has a bottle of
hand santizer on it. It’s in grocery stores near the dirty, filthy
carts. Moms carry it in purses. Yet just 6 months ago the following
was published:
“There will be a day when it will be so automatic for health care
workers to clean their hands,” Pittet said. “It will be a lot easier
at that time for patients, in case health care workers forgot, to
remind them.”
A third of doctors surveyed did not want patients reminding them to
wash up. If they were so smart they wouldn’t be sick.
Good thing that smug arrogance is an isolated incident limited to
personal cleanliness. Oh, right, cholera:
In 1854 London physician Dr John Snow discovered that [cholera] was
transmitted by drinking water contaminated by sewage after an epidemic
centered in Soho, but this idea was not widely accepted.
That’s from a Wikipedia article named Great
Stink. The name alone
warrants a quick skim, and you’ll also read about more doctors
ignoring research.
For instance, Filippo
Pacini discovered the
bacteria that causes cholera in the same year that Dr. Snow theorized
that transmission was via sewage, but nobody cared. Physicians knew
beyond doubt that cholera wasn’t caused by bacteria, but instead by
miasma. That’s bad air for those of us living with bacterial
awareness in 2013.
The same bacteria was rediscovered 30 years later by Robert Koch. He
also isolated the bacteria behind tuberculosis. I suspect other
physicians only took him seriously because he looked like a man that
you shouldn’t screw with.
At least now we’re more data driven. With the systematic cost conscious
approaches pioneered by modern health management organization, surely now
data and procedures rule.
Let’s talk central lines. A central venous catheter as it is called
in terms more complex than I commonly use when discussing health and
medicine. A patient in need of a central line is in rough shape.
Complications from a botched or infected central line spread rapidly
by the very nature of the procedure and equipment. Oh, right, central lines.
Dr. Pronovost
instituted a checklist for the care and maintenance of central lines.
In the broad scope of modern medicine, it’s a relatively simple
procedure. Go read it. There are 5 steps. Most of which boil down to
“be clean.”
The checklist focused on proper sterilization procedures, and it was
so effective that they had to extend the trial period just to believe
the results. At the end of the experiment, the hospital estimated
that 43 infections and 8 deaths were avoided, to the tune of two
million dollars in savings.
This is the stuff that medicine is all about. Sterile drapes and
thorough hand washing aren’t sexy like a new MRI machine or remote
robotic surgery device, but it saves lives, pain and money.
Despite his initial checklist results, takers were slow to come.
…
There were various reasons. Some physicians were offended by the
suggestion that they needed checklists. Others had legitimate doubts
about Pronovost’s evidence.
(From The Checklist Manifesto)
Doctors and staff can’t be the cause of trouble, especially if
it boils down to cleanliness. They trained to long to make such
simple mistakes.
Damn it.
Pilots get this stuff right. They’re creatures of checklist habit,
and they’re always, always improving those lists and procedures.
Over 12000 B-17 Flying Fortress aircraft were produced, and they
played a major part in Allied operations during World War II. This is
an amazing accomplishment for a plane that many deemed too complex to
fly. Airmen began the process of building and using checklists
because of the B-17, and because of the checklists the B-17 became a
powerful, flyable, weapon of war.
Why can’t doctors behave methodically like pilots? Is it because
pilots put themselves on the line and adherence to methodology is the
only thing that brings them back alive?
And why can’t we, the software developers and sysadmins, get it right?
Our systems lend themselves to checklists. Scratch that, our systems
lend themselves to fully automated checklists in which we should only
need to fix the outliers and amend the list. There is a thrill to being
a code hero that must outweigh the simple joy of consistently shipping
software in a reliable and reportable fashion. At some point that thrill
of riding in to save the day cowboy style loses its charm.
We’re getting better, but we’re still more doctor than pilot in our
ego and methods.
I was 15 years old when I first went
to Jun’s
in Kansas City. We ate there before the Sadie Hawkins dance, so
the ladies of the group had decided on our dinner venue. Mustering
all of my culinary fortitude, I ordered the Teriyaki Chicken. So brave.
Our family ate fish during Lent, and only after it was battered and
fried. Raw fish wasn’t really food in our world, and it took seven
more years before I was ready to try sushi. People I trust told me it
was delicious. Who was I to question raw food when my steak isn’t
much more than raw?
It’s wonderful, and I only regret waiting so long to try it.
Steak lovers look with disgust while people with lesser palates drown
dry and gray chunks of beef with steak sauce, or worse, ketchup. I
imagine sushi aficionados feel the same about some of the elaborate
deep fried creations that we submerge completely in soy sauce.
Months ago I sat down to relax with a movie. Netflix kept my top
recommendation slot filled with “Jiro Dreams of Sushi” because it
knows I love food and food related things. I’d surely learn something
about great sushi, and I’d bump Jiro out of the top spot for a new recommendation.
It’s wonderful, and I only regret waiting so long to watch it.
This is not a movie about sushi. This is a movie about excellence
that uses sushi as a vehicle.
Even for those who don’t like sushi in the least, this movie is
fantastic for anyone that wants to achieve excellence in their chosen
work. I’m not a dancer, but the words of Twyla Tharp
in The
Creative
Habit still rang true. Jiro’s words, too, will
ring true:
Once you decide on your occupation, you must immerse yourself in your
work. You have to fall in love with your work. Never complain about
your job. You must dedicate your life to mastering your skill. That’s
the secret of success and is the key to being regarded honorably.
Netflix and Amazon Prime members, you can watch this movie for free as
a part of your subscription.
I never expected to shoot for a sociology minor. Not a single bit of
the “Intro to Sociology” class sounded interesting to me. “Social
Stratification in America”, though, sounded very interesting. It was
an evening class, and I could get a full day in at the bomb factory,
and I’d get a social science credit without taking a ridiculous intro class.
For three hours each week Dr. Carroll would lecture a rushing river of
sociological consciousness. She’d glance at notes, but only
occasionally. Each and every week. A couple of other facts: she was
known in the department as a brutal tester, and there was no text
book. I rebuilt my atrophied note taking muscles in record time.
The rumors of her tests were true. Only my abstract algebra class
compared. She handed back the first test, and I deflated. “Shit!
65%! So much for an easy social science credit!” But I was in luck,
because I had set the curve in a room full of social science majors.
My notes made it all possible.
Fast forward to today. I can tell you which books I’ve read in the
last few years. I can also tell you if I liked them. I can’t tell
you much beyond that in many cases. There’s knowledge buried in my
subconscious, I hope, but I can’t confirm it.
I know reading is important, and I love reading. It just felt like
I was missing out on most of the fruits of it.
I started an experiment in December, and I can report that things are
turning around. I heard the Manager
Tools crew talk about reading
one hundred books in a year, and I decided I should do at least half
of that. And if I was going to get through one hundred books, I
should take notes during the process.
In addition to the great stuff in the books, I’ve (re)learned how I
learn: through writing notes. I’ve become a bit obsessive about
having a notebook or text editor nearby at all times, and I’m
better for it already.
If I’m reading to learn, I’m also taking notes.
If I’m listening to learn, I’m also taking notes.
If I’m watching to learn, I’m also taking notes.
Feel like you could use a nudge in the right direction regarding notes
and books? Recall that the Manager Tools guys have a cast about
everything, including How to Read a Book.
I appreciate you humoring me if all of this is common sense to you.
If you have all of this figured out already, I’d love to hear what
comes next. I promise I’ll take notes.
I hate that phrase. I prefer nails on a chalkboard to that phrase.
Two reasons: it sounds so dumb and condescending, and it’s so
important to the software development life-cycle.
Developer: “OK, I’ve checked in the new payment processing code.
It’s done.”
Project Manager: “So it’s done, done? Everything works, and it’s
tested? Payments, refunds, all of it?”
Developer: ”…”
Project Manager: “How about you double check your test cases before
we mark this as complete.”
Developer: “Probably a good idea.”
Writing feels a lot like software development. It’s a solo process, just an
author and his tools. A piece may look done, but it isn’t really finished
until the author rewrites it once, twice, or more, just as developers send
code through unit testing, alpha testing and beta testing.
Another similarity: “Few people realize how badly they write.”
William Zinsser wrote that line in On Writing
Well,
but it could have easily found its way into any number of our classic
software development books.
His book marches through many facets of
the craft: principles, methods, forms, and attitudes. I collected a
windfall of practical advice without minutia burying my desire to
write. It’s the Pragmatic
Programmer
for writing.