Everyone says do what you love, but what is it?

Hmm, this may be turning into a book blog... Stay tuned, I'll be posting less fluffy stuff as well.

It is a familiar phrase - "do what you love", and it has been repeated over and over again at several hacker/security cons all over the world. I do not know about you, but it took me some time to sit down and figure out what I love. Being a book nerd, I picked up Business Model You for some inspiration. It is a strange book, somewhat an offshoot of a very successful (apparently) book Business Model Generation and applies the same framework to individuals instead of businesses.

What I really liked about this book is not the "business model". Instead, have a look at Chapter 4 "Who are you?" It has a lot of great advice on figuring out what it is that you really love, if you do not know it yet (many people do not).

A thought experiment. Think back to any time before you were 20 years old:
What did you love to do? (I do not think the authors include sex under this rubric, hehe)
What activities - games, hobbies, sports, extracurricular events, school subjects did you enjoy? Recall your natural, uncoerced proclivities.
Think about what kept you absorbed for hours and made you happily oblivious to the rest of the world. What tasks made time fly?

They include a bunch of other thinking prompts - e.g. thinking over what events in your life related to what feelings, what kind of environment you like to be in and so on, yet this "inner teenager" exercise is the most unusual and most powerful. Obviously these memories need to be re-interpreted in the world you are living in, abstracted, re-applied - the core idea still stays.

So, people who love what they do are following their inner teenager..

P.S. If you are wondering, I love solving complex puzzle-like problems (preferably computer-related), working alone or in a small group of peers who share  goals and learn from each other. The rest is, erm, syntactic sugar.

Changing things when change is hard

NB: If the post below makes you think that I have succumbed to managementese and became some kind of consultant, this is a false impression. I am simply reflecting on an unexpected connection between security improvements in code produced by Twitter developers and a management book.

"Switch"

A recent read of mine, recommended by one of the Atlassian owners - Switch: How to Change Things When Change Is Hard. I am not a huge fan of management books - many of them turn out self help books in disguise, others spend 200 pages chewing through an idea that can be explained in a paragraph. "Switch" initially looked like it belonged to the latter category, but to be honest it is worth reading from cover to cover.

The book is about exactly what its title says - changing things when change is hard (Hello there, "security evangelists"!). The premise is simple (and borrowed from another book):

"Jonathan Haidt in "The happiness hypothesis" says that our emotional side is an Elephant and our rational side is its Rider. Perched atop the Elephant, the Rider holds the reigns and seems to be the leader. But the rider's control is precarious because the Rider is so small relative to the Elephant. Anytime the six-ton Elephant and the Rider disagree about which direction to go, the Rider is going to lose. He's completely over-matched."

They draw lessons about change efforts:

Elephant looks for quick payoff over the long term payoff. When change efforts fail, it is usually the Elephant's fault, since the kinds of change we want typically involve short term sacrifices for long term payoffs. Yet it's the Elephant who gets things done in change situations. You need to appeal to both. The Rider provides the planning and direction, and the Elephant provides the energy. Understanding without motivation vs. passion without direction.

...And make another simple but non-obvious observation that change is hard because people wear themselves out. The "one paragraph" summary of the book is that there are three components to a successful difficult change:

1. Direct the Rider - provide crystal clear direction. What looks like resistance is often a lack of clarity.
2. Motivate the Elephant - Engage the people's emotional side. The Rider cannot get his way by force for very long. What looks like laziness is often exhaustion.
3. Shape the path - Shape the situation in a way that facilitates your change. What looks like people problem is often a situation problem.

There are other interesting simple thoughts sprinkled throughout the text. For example:

• Build habits if you want the change to stick
• Shrink change - give simple actions
• Create a destination postcard (pretty vision of the final state) to motivate

Twitter, SADB and elephants

Now, why am I going on about a management book?

In my previous post I included a slideshare link to a talk about security automation from Twitter. There is also a video at http://videos.2012.appsecusa.org/video/54250716. Prominently featured is Twitter's central security dashboard, SADB ("sad-bee", funny) - Security Automation Dashboard.

One of its main functions is checking newly pushed code for known vulnerable patterns with Brakeman (see slides 46+ in the slideshare and quick demo video at https://www.youtube.com/watch?feature=player_embedded&v=0ZZKCyBR8cA and immediately bugging the responsible developer with specific recommendations on what has to be fixed and how.

This strikes me as a perfect implementation of "Direct the Rider" principle and "Shrink the change" approach.

I am going to try similar approach at work, we will see how sticky the resulting improvement is going to be :)

Some links:

Extracts from the book:

http://www.heathbrothers.com/resources/download/switch-framework.pdf
http://www.heathbrothers.com/resources/download/switch-for-organizations.pdf

A related behaviour change framework:

http://www.behaviorwizard.org/wp/ - from Stanford

Paradigms of failure in brigde design, or learning from failing

I've read a book some time ago - Design Paradigms: Case Histories of Error and Judgement in Engineering by Henry Petroski. It is mostly about bridge engineering (did you know there is a major bridge failure in US/UK every 30 years?)

"Paradigms" Petroski talks about turned out very much applicable to software engineering - to topics of security, availability and so on. Here is the summary of the paradigms, so that you do not have to read the book (unless you're into of bridge architecture)

1. Conceptual errors. Fundamental errors made at the conceptual design stage are the most elusive. They manifest only when the prototype is tested (=too late), often with disastrous results. They are invariably human errors and by definition cannot be prevented.
2. Overlooking effects of scale. Every design can be scaled only to a certain limit, after which the initial assumptions are no longer valid and a failure occurs. If you are scaling a successful design or a model, be mindful that this limit exists. You probably will not know what this limit is exactly.
3. Design change for the worse. This paradigm involves improvements over existing safe designs without re-evaluating the original design constraints. Any such change can introduce a new failure mode. Any change, no matter how seemingly benign or beneficial, needs to be analysed with the objectives of the original design in mind. An "improved" or enlarged design could hold unpleasant surprises over the original.
4. Blind spots are preconceived ideas about failure modes that drive analysis or design of the system, while other failure modes are ignored. The point here is that no hypothesis can ever be proved incontrovertibly, yet it takes only one failure (in analysis or reality) to provide a counterexample.
5. False confirmations. An incorrect formula for design is arrived to from wrong assumptions, yet due to a large initial safety factor it is "confirmed" by subsequent designs. Following this "success", the safety factor is gradually reduced to the stage when it no longer compensates for the wrong results and failure occurs.
6. Tunnel vision in design. Not considering failure outside of the narrow confines of the principal design challenge to the same degree as inside it. The designer needs a special effort to step back from each design and consider more mundane, less challenging aspects of the problem, those appearing to lie on the periphery of the central focus.
7. Not considering failure seriously. Document expected failure: what failure modes were anticipated in the design, what failure criteria were employed, what failure avoidance strategies were incorporated. Do not ignore case histories of failure and do not misuse them either - often such histories are used only to justify extrapolations to larger and lighter structures.

TL;DR failure is the only real learning tool in engineering - without failing there is no learning, but blind luck or "confirmation" of wrong theories.