Perspectives on parenting

One of my most admired tech bloggers Jeff Atwood wrote a great post this week "On Parenthood". It's moving and astute and insightful, and includes this:

My feelings on this matter are complex. I made a graph. You know, for the children.

That one percent makes all the difference

I also liked

I compare the process [of becoming a parent] to becoming a vampire, your old self dies in a sad and painful way, but then you come out the other side with immortality, super strength and a taste for human blood

The whole thing is worth a read.

Then a few days later I came across "Laws Concerning Food and Drink; Household Principles; Lamentations of the Father" [PDF]. This passage tickled me in particular

When you chew your food, keep your mouth closed until you have swallowed, and do not open it to show your brother or your sister what is within; I say to you, do not so, even if your brother or your sister has done the same to you. Eat your food only; do not eat that which is not food; neither seize the table between your jaws, nor use the raiment of the table to wipe your lips. I say again to you, do not touch it, but leave it as it is. And though your stick of carrot does indeed resemble a marker, draw not with it upon the table, even in pretend, for we do not do that, that is why. And though the pieces of broccoli are very like small trees, do not stand them upright to make a forest, because we do not do that, that is why. Sit just as I have told you, and do not lean to one side or the other, nor slide down until you are nearly slid away. Heed me; for if you sit like that, your hair will go into the syrup. And now behold, even as I have said, it has come to pass.

and also

On Screaming
Do not scream; for it is as if you scream all the time. If you are given a plate on which two foods you do not wish to touch each other are touching each other, your voice rises up even to the ceiling, while you point to the offense with the finger of your right hand; but I say to you, scream not, only remonstrate gently with the server, that the server may correct the fault. Likewise if you receive a portion of fish from which every piece of herbal seasoning has not been scraped off, and the herbal seasoning is loathsome to you, and steeped in vileness, again I say, refrain from screaming. Though the vileness overwhelm you, and cause you a faint unto death, make not that sound from within your throat, neither cover your face, nor press your fingers to your nose. For even now I have made the fish as it should be; behold, I eat of it myself, yet do not die.

Again, read the whole thing. It's worth it.

As if I know something (@thebeean is but 15 months old) I've compared the arrival of kids to taking a sudden 90° turn in life. Nothing slows down but everything's different: the terrain, the climate, and the look of the horizon. It's a whole thing.

Long and short clicks, and short patience

I worked at Google 2006–2010 and I remember it as being unique in many ways. While I was there, though, one particular thing which distinguished the core product—Google Search—from other similarly popular web properties was that it had a stated aim of reducing "time on site per visit".

For Google a top-level measure of its success as a search engine is how quickly it can provide you with great results for your query and send you on your merry way. A measure of how well Google's doing its job is how quickly it can get you the result you're looking for. The better it does, the happier you are as a user, the more likely you are to use the product, and the more opportunity to show you relevant ads.

In order to make sure that you're not just being sent away for the sake of it, though, Google decided to measure both "short clicks" and "long clicks". Let's say I click on a Google Search result, find it useless, and immediately click the Back button. Google measures that as a "short click", ie. I wasn't away for very long. The implicit signal is that the search result didn't answer my query well. Google takes note of this.

In contrast, a "long click" is one where I navigate to a search result and don't come back straightaway. The implication is that I found what I was looking for.

Knowing this context it was interesting for me to see for the first time this feature on google.com. Search for [hunter walk twitter] to find Hunter's Twitter account. Click on the #1 result, then click your back button. You'll be offered this screen:

The feature's at least six months old but is the first time that I've seen such a direct manifestation of short click feedback in the user interface.

I'm impressed at the option to customize my search results this way. Never forget, in fact, just how darned impressive Google Search is. It's surprising, though, that this is such a coarse setting. Offering to remove all twitter.com results for all queries henceforth seems a little severe as a proposed reaction to a single short click for a single query.

What I Have Learned: Attorney-Client Privileged and Confidential

Disclaimer: I am not a lawyer.

If you work in the technology sector in the States then at some point in your career you've probably received an email that started with the words in the title of this post.

Sometimes for effect the sender of the email may have bolded them:

Attorney-Client Privileged and Confidential

Others are known to go with a bold & italic strategy:

Attorney-Client Privileged and Confidential

And of course there is the ever-popular ALL-CAPS approach:

ATTORNEY-CLIENT PRIVILEGED AND CONFIDENTIAL

So what does this phrase mean? Is it really necessary? From what types of situation is it meant to protect you and your company? Here's what I've found out.

The last question is the easiest to answer. The law of civil procedure includes provisions for the process of "discovery" whereby each party involved in a civil action can request documents and other evidence, or can compel the production of evidence by using subpoenas or other means. Much of what goes into a company's day-to-day business is "subject to discovery", ie. may be required to be turned over to the legal counterparty (ie. the “other side”) in the suit. That includes product source code, documentation, reports, letters, faxes, files, and phone records.

Most crucially, though, for tech companies: all emails are by default subject to discovery.

This is where our famous phrase comes in: excluded from the discovery process are materials which fall under "attorney-client privilege". Attorney-client privilege is a legal structure which protects from discovery all communications where a client seeks or obtains legal advice from an attorney. Such "privileged" conversations are excluded from the discovery process and may be withheld from the opposing party.

Legally, one needs to consider a number of factors when looking at whether a particular email communication falls under attorney-client privilege; EITHER

• the email is from a lawyer representing the company, and dispenses legal advice or opinion. Such communications are almost always privileged

or ALL OF THE FOLLOWING must apply:

• the communication has to be with a lawyer who represents the company, since attorney-client privilege, as the name may suggest, only covers communication between a client (you) and an attorney (an edge case might be an email to someone with the explicit request asking for a lawyer to be added on the thread);
• the communication must be clearly and directly asking for legal advice or guidance; and
• the communication must not be broadly distributed (eg. if you email a smaller mailing list it is fine, but if you choose to cc a large group then the communication is likely no longer covered)

Note that "the communication includes a banner identifying the email as attorney-client privileged" is not one of the criteria! In fact the text "Attorney-client privileged" is itself not significant in any way, ie. the communication would be privileged—or not—with or without the banner. The only reasons to keep the text in place are

• to make explicit, to teams performing legal discovery, that in the opinion of the sender this message is protected under attorney-client privilege; and
• to remind recipients of the email that the material is sensitive and subject to privilege. Forwarding such an email usually removes it from the umbrella of privilege.

The final piece of legal advice is never to take legal advice from someone who's not a lawyer. The above is a guideline only; when in doubt, always consult an actual attorney.

 

---

UPDATE 12 July 2013 Interesting additional notes from an actual corporate attorney:

1. Attorney-client privilege exists under both state and federal law in the United States. There are a few state-specific differences that can affect when/whether the privilege attaches to a communication.
2. Attorney-client privilege works differently, if at all, outside the United States. For example: at a global company with employees in, say, the UK—when a UK-based employee seeks legal advice from US-based attorneys, attorney-client privilege does not exist for that communication in the UK.

Thoughts on Platforms

I'm a big fan of Steve Yegge. I think that his recent platforms rant is, once you look past the haha-Google-doesn't-get-it and haha-Google-employee-bashes-Google+-on-Google+, a contemporary classic essay on platforms and technology strategy. Articulate, entertaining, irreverent and really insightful—like Steve himself, I'm told.

A friend of mine sent round an email recently asking for thoughts on it. What was Yegge trying to say? Here's what I think: he was trying to say a number of things.

1. A key business/product truism: "a platform-less product will always be replaced by an equivalent platformized product". If your product isn't a platform then prepare to be disrupted by someone who builds a platform and a competing product on top. Platforms enable unimagined/uncontemplated user needs to be met. Ultimately, platforms win.
2. You can't just build a product, slap an API on top and call it done. That's not a platform and it's probably not even a good API. You need to design this stuff in from the very beginning.
3. Once you've decided that you're going to build platforms (rather than adding an API as an afterthought), the way to get good at exposing platforms externally is to live them internally.
4. To live platforms internally they need to pervade your organization, all your thinking and your internal architecture. It can't be just "hey we have an RPC interface". How is that service registered and discovered programmatically? How are quota and rate limits managed? Pluggable authentication? Front-to-back end-to-end tracing? How is it regression-tested as it evolves? Can anyone in the company just pick up the docs for the service and start calling it? Is there an SLA? How is capacity planned and provisioned? Talking of docs, do you have reference manuals and tutorials, code samples, lists of error messages and so on? Who gets paged if it goes down as a result of a supporting service going down? You don't have a platform unless you have a consistent, uniform approach to all these horizontals supporting a vertical API.
5. If you design your internal systems with a platform mindset then every day you're dogfooding your own platform efforts. It'll be easier to expose a rich and thorough platform to your customers and users, and the quality of the platform you expose will be higher.

The part of Yegge's story about Bezos reminded me of my own similar experience. In 1997 I started work at an investment bank in London. The CIO there had just decided that from now on every app developed internally should be delivered in a browser. If you don't build web-enabled apps then you're out. He had mugs and t-shirts made with slogans such as "web or dead" and "wired or fired". He gave them out to employees. I think I still have my web or dead one.

But this seemed like insanity at the time. Internet Explorer 3 was the default browser. The investment bank I'd just come from didn't even have internet access, or browsers, on their desktops. There were many people at the bank who thought that this web app idea was the most stupid idea ever, particularly those who only knew COBOL. Or had spent years building thick clients in Visual C++ or VBA.

I was impressionable, though, kept my head down and became good at building web apps.

And! Once the bank had developed web-based trading apps and web-based finance apps and web-based legal apps and web-based book-building apps for internal use... waddyaknow we could make these same apps available directly to our customers in their browsers. This was utterly revolutionary—and gave us an enormous market advantage, literally years ahead of our competitors.

It couldn't have happened without everyone internally living, breathing, and being hired and fired around, this internal mandate for browser-based apps. The skills we built and lessons we learned while solving for our internal apps were all directly applicable to the turning inside-out of these same apps.

I think that's similar in spirit to Yegge's point. You'll get good at externalizing platforms by internalizing them.