Writing Words, Writing Code, Hemingway Style

One thing that motivates me to write is reading great writing. Whether I'm writing words or writing code, the ability to capture an idea and write it in an impactful way is powerful.

Hemingway – much like Apple – knew how to pare away the cruft to get to the heart of the experience.

When I first began writing fiction I read Hemingway's short stories for inspiration. The first one I read was The Snows of Kilimanjaro where he vividly described a scene without explaining the details.

...he and the British observer had run too until his lungs ached and his mouth was full of the taste of pennies...

This description hit me like a ton of bricks. In this single sentence I understood Hemingway's writing style. When someone's shooting at you the adrenaline deep in your throat tastes exactly like copper pennies. Hemingway had seen combat – he knew what adrenaline tasted like – so there's no need for him to explain it.

The West Wing: "You tasted something bitter in your mouth.
It was the adrenaline. The bitter taste was the adrenaline."

A reference to the bitter taste of adrenaline is also seen in an episode of The West Wing. Josh Lyman is in denial about his PTSD after being shot. A Yo Yo Ma performance triggers a PTSD episode and a psychologist jump starts Josh's counseling session by telling him about the bitter taste.

Hemingway left out details which pulls in the reader rather than shuts them out. That's hard to do. And Hemingway knew exactly what he was doing which he described in his essay, The Art of the Short Story:

A few things I have found to be true. If you leave out important things or events that you know about, the story is strengthened. If you leave or skip something because you do not know it, the story will be worthless. The test of any story is how very good the stuff that you, not your editors, omit.

Writing workshop

It's pure chance I came across Joyce Maynard's writing workshop, last spring, that lead me to her home in Mill Valley to work on my writing. There's nothing better than being taught by a woman who's earned her living as a writer her entire adult life. I'm writing this piece, today, because, yesterday, she pointed out that even the best writers have to handle rejection. And it's through Joyce I feel a connection to Hemingway since she lived with J.D. Salinger and Salinger met with Hemingway during WW II.

Damn XO: Give every order as if it were your own

When I was at the Naval Academy we were taught a lesson called Damn XO (Section 2.9 on page 11 of this PDF).

In a nutshell, orders and directives should be stated as if they are your own and not as originating from someone else (and particularly from someone senior).


From the Damn XO leadership guide:

There is a natural tendency, when faced with implementing directions that may encounter “push back” (objection or disagreement) from subordinates or peers, to phrase them as coming from someone else and thereby mitigate the situation for oneself. Responsibility for the directive is deflected to the originator rather than taking personal ownership. Sometimes characterized as “lazy orders” or “Damn Exec” syndrome (i.e., “Damn XO says ___________”). Giving orders to subordinates and attaching the originator’s name to them does not support the chain of command and has long term adverse effects on attitude, performance and unit integrity.

Issues with the “Damn Exec” approach:

– Demonstrates lack of ownership and “buy-in” to organizational goals.

– Subordinates may see you as only a puppet or mouthpiece of higher authority, lacking personal authority and responsibility.

– Subordinates may question decisions you make/ orders you originate.

Personal ownership of orders/directives is a fundamental responsibility at each level in the chain of command. “Damning the Exec” may be subverting your leadership role through loss of respect and support of your crew.

Let Him Fail

I learned a lot at Officer Candidate School (OCS) in Quantico, VA.

Before you can lead you first need to learn how to follow. In boot camp, at Parris Island, my drill instructors taught me how to follow. At OCS, the goal was to see how well I could lead.

I was one of the only prior enlisted Marines in my OCS platoon, so my sergeant instructors assigned me as the platoon commander. The candidate assigned under me, as my platoon sergeant, was a subpar performer. Pairing top performers with subpar performers was a common tactic at OCS. It’s a learning experience for both.

Two things stick out in my mind when I was the platoon commander.

Non sibi

First was the fact that I ate last. The Marine Corps is a big believer in taking care of your Marines’ needs before your own. My platoon would file into the chow hall before me and we’d all leave at the same time.

Stay in Your Lane

Second was the fact I had to supervise and lead without intervening or interfering. As the platoon commander, I didn’t march in formation with my platoon. The problem was my platoon sergeant kept making mistakes. He’d make mistakes marching the platoon, taking muster, organizing his reports, etc. When this initially happened, I jumped in and took over. The third time I did this my senior sergeant instructor pounced on me with a loud and resounding, “Let him fail, Moreno! You can’t do his job for him. He needs to learn for himself.”

In a flash I learned a valuable leadership lesson. It’s hard to sit back and watch someone learn from their mistakes at your expense even though it’ll pay off in the long run. Give your subordinates a little buffer and breathing room to try new things so they learn what works and what doesn’t. This is a key principle when transitioning from an individual contributor to a leader as it builds trust and confidence in the team.

Band of Brothers
You can see this leadership lesson in action at the 4:00 mark in this clip. Dick Winters is the battalion XO (although this scene portrays him as the battalion CO) and he tries to step in to lead a company that's pinned down due to poor leadership under fire. In the heat of battle Winters's commander stops him to remind him it's not the battalion commander's place to lead a company. That's a tough lesson to learn when people you know are being killed before your eyes and you can fix it.

Proper Scrum in Agile

I once had a consulting gig in Austin with a software firm that told me they implemented Agile and Scrummed every morning. I sat in on their Scrum with about six software engineers and it lasted more than 45 minutes. That's not a Scum.

A proper scrum should last about 90 seconds per person. The person seated or standing to the left of the Scrum Master starts off and each person addressing three points:

1. Tasks I've done since we last met.

2. Tasks I'm going to do before we next meet.

3. Any blockers that require outside help.

Pigs & Chickens

There are pigs and chickens in the Scrum. Only the pigs (engineers, producers, etc. i.e. the workers) are allowed to speak. Any chickens (managers, etc) get to talk after the Scrum is over.

Real World Practice

At Apple, I worked with fellow engineers and managers who had formal Agile training. They were masters at sticking to the three points I mentioned above. The key to keeping the Scrum from turning into a working session was, anytime a person veered away form these three points, someone would say, "Sidebar." At that point, the person who veered off track would either correct him/herself or s/he would list their Sidebar issue on the whiteboard.

After the Scrum was done, anyone could leave the meeting if none of the Sidebars concerned them. More often than not, we made it though a Scrum without any Sidebars.

Epilogue
Sticking to these three Scrum principles is harder than you'd think, especially when people have questions or you've accomplished a task you want to brag about. But, if you're a well disciplined Scrum, you can simply list your self-congratulatory attaboys as a Sidebar. There's nothing wrong with tooting your own horn now and then – just don't do it during the Scrum.

There's more to Agile/Scrum then this, but this is the key to running a successful daily Scrum meeting.

Amazon CloudFront

Amazon's CloudFront brought CDN to the casual coder about five years ago. When Amazon announced CloudFront it had much of the same basic functionality as Akamai. But, the problem with CloudFront was many features were only accessible through APIs, not the AWS dashboard (management console). One of the key features missing from the dashboard was the ability to invalidate an object in the CDN. For me, this was a showstopper.

When caching an object (file) on an edge server, the CloudFront default setting stores it for 24 hours. To clear out a file before it expires requires an API call to invalidate it and fetch a new copy from the source. This setting was not originally available to the casual CloudFront user via the AWS dashboard. The API functionality was there, but, unlike Akamai's dashboard, it required a coder to put it in place.

I recently began using CloudFront, again. I'm happy to see the AWS dashboard can now invalidate objects with a simple click. Or, even better, the invalidation of a subset of objects is possible by specifying paths or patterns.

AWS just keeps getting better while dropping their prices. What could be better?

Taking Inspiration from Others

Everyone wants to be an astronaut.

My college buddy is a Navy SEAL and astronaut. He traveled to the ISS in 2009, aboard the Endeavour, and then he went back to the space station, last March, where he remained until September. Even though I had nothing to do with his success – I only sat next to him in english class at prep school – I, like the rest of my classmates, take great pride in his accomplishments. After visiting him, in 2009, for a personal tour of Houston, he became my inspiration for learning to fly a few months later.
Last summer, NASA released a light hearted video of Chris shaving his head and growing a goatee in a move of solidarity to welcome Italian Astronaut Luca Parmitano.

What a great job and let's not forget the first step to becoming an astronaut.

Communication Pipe

When I was a 19 year-old Marine I listened to a captain talk about communications and military operations. He told us stories about his part during the invasion of Grenada and his time in Beirut. In the 1980s, very few Marines had seen combat, so his thoughts carried a lot of weight.

The captain had some insightful experiences. One point he made was about, what he called, the communications pipe (we call it bandwidth, nowadays). As a communications pipe increases, more stuff gets added. The problem is that we always fill it to capacity. The upside is as bandwidth increases, the older technologies, like text chat, can shine during a crisis. His point resonated with me on 9/11 when I couldn't reach my boss and fellow Apple coworkers in NYC via phone or e-mail. But, AIM, being such a low bandwidth channel, worked without a hitch.

Cache is King in Safari

One trick to speeding up an application is caching. Rather than fetching data from a database or over the network each time you need it, it's better to retrieve the data as soon as possible and hold on to it as long as possible --- and no longer. The only thing worse than slow or no data is bad data.

Autocomplete prefetching over the network before I hit enter.

Last week, I was monitoring a web server log for a URL shortener when I noticed a neat trick Safari does. Rather than waiting for me to hit enter after I typed in a URL, Safari automatically loaded the webpage during the autocomplete phase. It's a brilliantly simple solution. After all, why not start loading a webpage before I ask for it? Actively loading data before it's needed is known as warming up the cache. It's smart since it makes for the best possible user experience (BPUX).

There's nothing like proper optimization, done in small steps, when needed. On the other side of the coin is premature optimization which is the bane of any software engineer's existence. (Rules to Code By)

Another Safari optimization trick I read about but haven't confirmed is that, after loading a web page, Safari will prefetch each link's IP address for faster loading when a user clicks on it since the DNS lookup has already been done.

Anything to speed up my Internet experience is OK by me.

Work Hard, Be Productive

I've worked in some fast pace environments, from the Marines to startups. The one thing I've noticed is there's some confusion between working hard, looking busy, getting excited and actually being productive and making money.

Many people are drawn to day trading because it's exciting. Big mistake. If you're looking for a rush then ride a roller coaster or go to Vegas. If you're going to war or building a startup then work smart and be productive. In the Marines, we used to say, "It's easy to be hard. It's hard to be smart."

The key to good leadership is to give your people enough direction by prioritizing tasks (with deadlines) and then let them go. The antithesis is to interrupt them. I once worked for a boss who was horrible at communicating in a timely fashion. Nearly all phone calls and meetings had no agenda or succinct purpose. Non-pressing deadlines were set and then changed without clear reason. Actually, the real reason is he was disorganized and he had poor time management skills. He never wrote down any of his tasks that I saw and he couldn't  prioritize tasks or timelines. Ideas would pop in his head and he'd spit them out, regardless of the urgency. It was interruption after interruption.

Interruptions Be Gone

One thing to realize is that every call, text, IM and e-mail is an interruption. Each interruption is going to knock a person out of their productivity zone so it's important to weigh the interruption with the importance and urgency of the information being passed along. Many people constantly interrupt coworkers and subordinates because they're worried about forgetting their own assignments. Instead, they should simply write down everything they need to do (both what they need to do and what they need others to do) and then sync up with their coworkers during planned meetings rather than unplanned interruptions.

If you think making money is directly proportional to how smart you are or hard you work then you need to think twice. I worked way harder in the Marine Corps than I did after I left Apple when I just sat back and watched the price of my Apple stock, originally purchased at less than $10/share, go to $500–$700/share. Guess where I made more money: USMC or AAPL?

So, before interrupting a colleague, ask yourself if your interruption is urgent and important enough to justify it or can it wait until the recipient is better prepared to receive the information? Another test, before interrupting, is to ask yourself what will happen if you wait to pass the info?

Need more tips? See Time Management in the 21st Century.

Webification with Web-ins™

Webification is the process of converting content so it can be viewed on the Web. It's a big deal to simplify a technical process or protocol by overlaying a human readable Web interface. Hotmail did it for SMTP/POP (e-mail), Blogger did it for FTP, RSS did it for XML, and then Twitter took it one step further and did it for RSS.

Google's search results for CNN.

A friend, who runs a green website, created what she calls web-ins™. What she's done, without realizing it, is webified the XML sitemap.

Sitemaps help search engines understand the hierarchical structure of websites. When I google "CNN" I see that the search engine returns more than a simple summary and link to the cnn.com homepage. With the help of CNN's sitemap.xml the search engine deep links me directly to the content I'm looking for rather than me needing to first visit the CNN homepage followed by clicking through to the content.

Each web-in™ is manually created depending on the destination website. Different areas of a web-in™ link to different parts of a website:

Sample live web-in™

KISS

Web-ins™ are nothing more than HTML area and map tags. It's such a simple solution it could easily go unnoticed. But, then again, Twitter is nothing more than 140 characters of text without markup.

The next step in standardizing web-ins™ is to have webmasters create their own for third parties to display on their websites in place of simple links to home pages. Webmasters could provide web-in™in sizes that conform to IAB guidelines as either static HTML or, even better, as a Javascript that implements an iframe whose content would be maintained by the content provider instead of the third party.

There's an elegant beauty in simplicity.