I'm pretty mixed on patents. I understand that if a company invests huge resources into discovering something, it is unfair for someone else to simply piggyback and copy it (but I think companies should make money from execution and service, not ideas). I understand there is societal benefit to sharing inventions (but I think the current system doesn't accomplish that since it's impossible to keep up with the multitude of patents granted and in-progress).

I believe that many of the lawsuits around software patents are frivolous (and many of the duplicating/overlapping patents shouldn't have been granted in the first place), so the whole situation is a mess.

Too many people still pay attention to "patent portfolios" (with quantity often more important than quality), and that attitude causes difficulties for entrepreneurs wondering if they should spend their time and money collecting [often useless] patents simply to show off.

Also, the recent law change that gives priority for patentability to those who file first instead of those who invent first requires filing patents immediately upon thinking of an idea, which is costly and sort of ridiculous/impossible for everyday people or entrepreneurs to do (and incentivizes patent trolls).

I heard an interesting session last week at UCLA Anderson by an accomplished patent attorney, Todd Miller. It was generally on tips for entrepreneurs (and less on controversial issues like should there be patents or how the system should be reformed). Below are my main notes and takeaways. What do you guys think about the issues I've raised above?

Tip 1: Work backwards.

• First figure out your business goals and strategy.
• Then think about if/how IP fits into that.
• Most money spent on IP is inappropriate.

Tip 2: Be flexible.

• You will have to pivot your business.
  
• Smart while being lean: Use an omnibus patent application (put all ideas in one application to save money and time).

Tip 3: Basics of IP

• Many patents not valuable because protection is too limited.
  
• Patent infringement requires each element listed in a claim.
  
• Use Google Scholar and Google Patents to check before you file.
• Trade secrets protect business info.
  
• Trademarks protect source of idea.
  
• Patents protect idea.
  
• Copyright protects expression of idea.
  
• Requirements for patent: novelty, usefulness, non-obviousness
  
• Claims at end are the actual protection.
  
• Use the USPTO website.
• In trademark, define description of goods as broadly as possible.
• Trick: File patent in Korea (if green tech, it's expedited to 6 months); then file in US and bypass the line.
• Another good search engine: prior-ip.com
  
• Search for your idea and find clusters of other patents and ideas

Tip 4: Avoid common mistakes

• Public dissemination (and discussion with anyone or public release in talk or website) kills patentability in most of world besides US (like Europe)
  
• Prior employer: invention might belong technically to prior employer (check your employment contract)
  
• Licensing terms: don't license out all IP early at bad terms; avoid "most favored nation" clauses in licenses if you can
  
• Chain of title: anyone who works for you must sign agreement that IP belongs to you

This quarter, I'm lucky to be taking a class taught by Jim Stengel, the former Global Marketing Officer of P&G (the "UCLA CMO Experience"). I wrote about this class in my admissions essay, and I'm excited about finally experiencing it.

Below are my main takeaways from this week's readings and lecture.

• Firms of Endearment
  
• It's not share of wallet anymore; it's share of heart
  
• Freeman: customers are best served by companies that enjoy good relationships with all their stakeholders-employees, suppliers, the communities in which they operate, and of course, their stockholders (SRM = stakeholder relationship management)
  
• Aging population => search for meaning in life
  
• Characteristics: Endearing companies are enduring companies; Align interests of stakeholder groups; Executive salaries are modest; Open door policy at executive level; Greater employee compensation; More employee training; Lower turnover; Employees empowered to ensure customers satisfied; Hire people who are passionate about company and products; Humanize the company experience; Genuine passion for customers; Lower marketing costs and higher customer satisfaction and retention; Suppliers as partners; Honor spirit of laws; Corporate culture treated as greatest asset
• An increasing number of companies are behaving in ways that mirror the growing influence of self-actualization needs and processes that derive from our aging society.
• Effective communication: 4 principles: Principle 1: Establish a Positive Relationship (or Reinforce an Existing One) Before Getting Down to Business; Principle 2: Show Willingness to Be Vulnerable; Principle 3: Foster Reciprocal Empathy, Whereby Stakeholders Reciprocate the Company's Empathy; Principle 4: Conduct Conversations with Genuine Reciprocity
• Ideals as the ultimate growth driver
• Ideal: A business’s essential reason for being, the higher-order benefit it brings to the world; the factor connecting the core beliefs of the people inside a business with the fundamental human values of the people they serve; Not social responsibility or altruism, but a program for profit and growth based on improving people’s lives.
• Discover a brand ideal of improving people’s lives in one of five fi elds of fundamental human values.
• Build organizational culture around the brand ideal.
• Communicate the brand ideal to engage employees and customers.
  
• Deliver a near-ideal customer experience.
  
• Evaluate progress and people against the brand ideal.
  
• Coke is a happiness brand.
  
• Steve Jobs was one of the top 3 business people ever, and he was a marketer.
  
• Pampers: instead of focusing on product function, focus on what mothers actually care about
• If your ideal is high enough, it’s universal, and you just need to find a way to bring it to life around the world.
• Goal of brand: strong relationships which lead to strong loyalty
• Take what works for you in building a human relationship, and use that to build your business.
• Hardwire relationships into your business
• Marketing influences life, and life influences marketing
• 5 ideals fields of fundamental human values: joy, connect, explore, pride, impact
• Build your culture around your ideal
• Brand as culture, culture as brand
  
• Every communication is about the ideal

In Steve Jobs' bio, it said he read Autobiography of a Yogi by Paramhansa Yogananda every year. So I figured there must be something to it. (I had also heard of the book several times from other yogis and figured I would give it a try.)

The book was slow to start (and sometimes included way too much detail), and I had trouble getting used to the writing style for a while. I also didn't really understand the overall point or trajectory of the work. Then, part of the way through, I began to enjoy it, and I noticed more and more pearls of wisdom on the pages.

The book is about religion, but it's also not about religion. It's about faith and spirituality and the common one-ness uniting everyone, and I like those ideas. (The book is not about doing yoga sports exercises. It's about meditation and mind control, some of the most difficult and rewarding activities a human can apparently engage in.) The book featured many accounts of supernatural episodes (visions, reincarnations, levitation, and teleportation); those didn't sit well with me, but I will tolerate it as there's enough good elements in the book ignoring the supernatural events.

After reading the book, I'm wondering what parts of it appealed most to Jobs. Meditation? Spirituality?

Below are my notes. I apologize for butchering the spellings of many of the people and places mentioned in the book; I was listening to the audio version (which again unfortunately but understandably featured a reader with an English accent).

Ch. 1: My parents and early life

• Bengali
  
• Life as infant
  
• Born 1/5/1893 near Himalayas
  
• Kshatriya caste parents
  
• Aversion of instant acceptance
  
• Due reflection
  
• Recreation in spiritual practices
  
• No luxuries
  
• No pursuit of money
  
• Started bank but didn't want shares in it
  
• Man arrives penniless and departs same way
  
• Magic power of man's words spoken confidently
  
• Guru photo 
  

Ch. 2: Mothers' death and amulet

• Saw vision of mother dying and was true
  
• Powerfully drawn to Himalayas where yogis and swamis lived from vision
  
• Guru told his mom he would be yogi and bring souls to light
  
• Magical amulet materialized for mom who gave it to son
  

Ch. 3: The saint with 2 bodies

• Second pension from divine of peace
  
• Story of transportation/2 bodies of swami
  
• Yogi Lahiri Mahasaya
  

Ch. 4: Interrupted flight to Himalayas

• Escape failed
  
• Got tutor at home
  
• Deep meditation
  
• Learned Sanskrit
  
• Kriya yoga
  
• Magic healing
  

Ch. 5: Perfume saint

• Perfume magic
  
• Electrons and protons manipulated by prana lifetrons
  

Ch. 6: Tiger swami

• Fought tigers with hands
  
• Mind and determination control body
  
• Tamer of wild passions
  

Ch. 7: Levitating saint

• Only true way to know divine is love
  

Ch. 8: Indians great scientist JC Bose

• Botany and physics research
  
• Uniform plan links all life
  

Ch. 9: The blissful devotee

• Classroom boredom
  

Ch. 10: I meet my master

• Unprepared for school finals
  
• Finished school and ready to leave home to seek divine
  
• Had to detach from family
  
• Finally met guru
  
• Had to leave ashram
  

Ch. 11: Two penniless boys

• Passed tests to show faith in divine
  
• Went without money, found people who provided for him
  

Ch. 12: Years in my master's hermitage

• Guru told him to get university degree so would be more accepted in future by westerners
  
• Vegetarian
  
• Morning strolls with guru
  
• Be comfortable within your purse
  
• Sri Yukteswar
  
• Yogic trance with no vital signs
  
• Super conscious state
  
• Mosquitos: just change consciousness and will not bite
  
• Thoughts heal, placebo
  
• Every natural passion can be mastered
  

Ch. 13: A sleepless saint

• Thought would have to go to Himalayas to study
  
• Guru told him does not need to do so
  
• What one does not find within cannot be found outside
  

Ch. 14: An experience in cosmic consciousness

• Cosmic vision of connection to all life
  
• Soul must have cosmic reach while body does daily mundane work
  

Ch. 15: The cauliflower robbery

• Importance of music
  

Ch. 16: Outwitting the stars

• Astrology
  

Ch. 17: Sasi and the 3 sapphires

• Divine responds to urgent prayers
  
• Astrological bangles
  

Ch. 18: A Mohammedan wonder worker

Ch. 19: My master

• Teleportation
  

Ch. 20: We do not visit Kashmir

• Got sick when wanted to go to Himalayas
  

Ch. 21: We visit Kashmir

• Guru finally blesses him to go to Himalayas
  
• Physical transfer of disease to cure others
  
• Lots of mentions and comparisons to Jesus
  

Ch. 22: The heart of the stone age

• Reformed brother in law through example of spiritual miracle
  

Ch. 23: University degree

• Little time for study
  
• Repeatedly doubted divine and then was saved
  
• Received degree
  

Ch. 24: I become monk of swami order

• Guru finally allowed him to join order
  
• Selected new name
  
• Yoga and swami orthogonal
  
• Yoga is science of mind control
  
• Patanjali Yoga Sutras
  
• Eightfold path
  
• Yama: moral
  
• Viyama: religious
  
• Asana: posture
  
• Pranayama: breath
  
• Pratyahara: withdraw from external
  
• Dharana: concentration
  
• Dhyana: meditation
  
• Samadhi: super conscious experience
  
• Yoga ok for worldly people
  
• Hatha yoga just one branch
  

Ch. 25: Brother and sister

• Brother died and he felt sad
  
• He and his guru healed sister
  

Ch. 26: Science of Kriya yoga

• Cause and effect
  
• Rejuvenates body
  
• Transmute cells into energy to teleport
  
• Christ used it
  
• Life force control
  
• Neutralize lungs and current
  
• Om sound to concentrate / Amen
• Life force controlled by breath action
  

Ch. 27: Founding yoga school

• Man must have some family, either wife or school
  
• So founded school
  
• Class instruction outdoors
  
• Yoga and agriculture
  
• True development of body and mind
  
• Death doesn't end all
  
• Unattachment: let dead move on to higher role
  

Ch. 28: Reborn and discovered

• Relocated reborn child
  

Ch. 29: Compare schools

• Visited other school
  
• Also outdoors, child's natural setting
  
• All learn yoga concentration skill
  

Ch. 30: The art of miracles

• Maya world of illusion
  
• Relativity
  
• Unified field theory
  
• Light
  
• Duality of nature
  
• Light speed only world constant
  
• Matter energy duality
  
• All matter light, yogi can manipulate
  
• Motion pictures directed by people like yogis can direct real light and matter
  
• Miracles are just natural to masters
  
• Everything is a miracle
  

Ch. 31: Interview with sacred mother

• Wife of Lahiri Mahasaya
  
• Levitation in lotus pose
  

Ch. 32: Rama is raised from the death

• Account needed in west of Lahiri Mahasaya
  

Ch. 33: Babaji Christ of India

• Guru of LM
  
• Avatar: body free from material bondage
  

Ch. 34: Materializing a palace In the Himalayas

• Spiritual enlightenment comes to worldly people who still fulfill civic responsibilities
  

Ch. 35: Christ like life of LM

• Life of balance
  
• Kriya initiation to worldly
  

Ch. 36: Babaji's interst in the West

• Saint told author to write book equalizing Christian and Indian beliefs
  
• LM reincarnated
  

Ch. 37: I go to America

• 2 legged newspaper (word of mouth)
  
• Invited to speak at conference in Boston
  
• Chosen to spread message of Kriya yoga to West
  
• Meant to unite nations under one holy father
  
• Lectured throughout America
  
• Started Self-Realization Fellowship at Mount Washington in LA
  
• Spent 15 years in America 
  

Ch. 38: Luther Burbank

• Plant breeding from talking to plants and love
  

Ch. 39: Therese Neumann

• Eager to meet saint in Germany
  
• Saint who lived without food
  
• Stigmata wounds on hands
  
• Weekly trance of Christ's Passion
  
• Visited holy sites of Europe
  

Ch. 40: I return to India

• Return to see guru
  
• Created permanently endowed school
  
• Free hospital
  

Ch. 41: An idyl in south India

• Wanted to have best exchange between East and West
  

Ch. 42: Last days with my guru

Ch. 43: Resurrection of Sri Yukteswar

• Went to be prophet of astral planet
  
• Detailed description of astral beings and logistics
  
• Anything can be created from thought like we create any image on TV
  

Ch. 44: With Gandhi

• Weekly day of silence to devote to correspondence and spirituality
  
• Husband as guru of wife
  
• Worship of all religions equally
  
• Taught yoga to Gandhi
  
• Nonviolence
  
• Forgiveness is holiness
  

Ch. 45: The Bengali joy-permeated mother

Ch. 46: The woman who never eats

• Was at first over-eater
• Stopped eating at age 12
  
• Lives by external light
  
• No bodily excretions
  
• Uses Kriya breathing technique 
  

Ch. 47: I return to the West

• Lecture in London
  
• Christmas mediation in LA
  

Ch. 48: Encinitas California hermitage

• Retreat by the ocean
  

Ch. 49: The years 1940-51

• East West magazine
  
• Hollywood temple
  
• Translated New Testament and Bhagavad Gita
  
• Saw vision of Jesus
  
• Kriya yoga: breath as key to world and spirit
  
• Leave a few mysteries to explore in eternity
  

Afterword

• After died, his body did not decay (in mortuary records)
  
• One of India's great saints
  

Another awesome talk by the guys at LeanLA and IMVU!

Here's the blurb about the talk and the really knowledgeable speaker:

"Continuous Deployment takes continuous integration one-step further, where every commit goes live to production servers. When this process is described it is frequently met with skepticism around site reliability and the ability to scale a business this way, but it works, it scales (with challenges) and it is embraced by the entire organization. IMVU is a leader in Continuous Deployment, with over 5 years of experience scaling this process to support a technical staff of 50 and a business of more that $40 million in annual revenue. Brett G. Durrett, Vice President of Engineering & Operations for IMVU explains the basic mechanics of Continuous Deployment and discusses the value it creates for the entire company. Specific topics that will be covered: Attendees will understand that releasing to customers 20+ times per day is possible and that it does scale from individual developers to large companies. In addition, they will understand how they can make Continuous Deployment successful at their company, from both a technology and cultural standpoint.

Brett G. Durrett has over 20 years experience leading development of software and systems ranging from large-scale Internet services to video games. He serves as VP of Engineering at IMVU where he leads the engineering and technical operations teams and was responsible for the operations infrastructure that successfully scaled from two machines to over 700 servers. Prior to IMVU, Brett served as the Director of Engineering, VP of Operations and General Manager for the virtual world at There.com. Brett was also co-founder and CEO of Asylum Entertainment, a game development company."

You can watch the talk (in two parts) and see the slides above. I'm pretty much sold on what Brett preaches and am thinking of how to implement continuous deployment in my current projects. He says that having little code and process in place puts you at an advantage, though I'm still wondering how to put in the right infrastructure to have all the tests and deployment run as smoothly and automatically as they do (and how much to prioritize this process infrastructure work around other initial start-up goals).

My notes on the talk are below. Overall, I learned a lot and very much enjoyed hearing Brett speak.

Their process:

• develop a feature increment
  
• verify on buildbot
  
• commit code to live in production immediately for some set of customers
  
• whole process takes 15 min, release about 50 times per day
  
• no staging cluster
  
• no QA review
  

Why would you do something like that?

• most companies develop, release, then pray for customers
  
• now, smart companies develop, release, learn, iterate
• minimize total time through build, measure, learn cycle

Why continuous deployment is good:

1. release overhead reduces opportunity to iterate
   
2. way easier to find regressions/bugs in small batches of commits
   
3. fast response times for business opportunities
   
4. more turns at bat
   
5. book: Principles of Product Development Flow (reducing batch size, lean product development); reducing batch size reduces cycle time, reduces variability in flow, accelerates  feedback, reduces risk, reduces overhead; large batches reduce efficiency, inherently lower motivation and energy, cause  exponential cost and schedule growth, lead to even larger batches; the entire batch is limited by its worst component

Work process:

1. local tests pass, engineer commits code
   
2. lots and lots of tests run
   
3. all tests pass [if no, revert commits]
   
4. code deployed to % of servers
   
5. metrics good [if no, rollback]
   
6. code deployed to all servers
   
7. metrics still good [if no, rollback]
   
8. win
   

amount of time you need to run test depends on volume of people going through funnel

all work done on trunk (no work on branches)

• avoids merge conflicts
  
• all code gets validated in production immediately to test now
  
• at bottom sees actual PHP test files and their status (time to complete, running status, etc.)
• a tag includes multiple PHP test files
• tests run before checkin on local sandbox
• push for being test-driven but let people work how they want to work
  
• each person responsible for writing tests for their own code
• local sandbox test suite running through a web browser
• checkboxes: stop after last test, pause after failure, run tests in random order, only run selected tests
• want to make testing as unburdensome as possible

great slide in presentation with sample output of "RunTests" test view which allows filtering tags, turning test on/off, seeing tests that pass, fail, run, skip, wait, etc.


use selenium

continuous integration: they use buildbot, others use hudson, jenkins, atlassian 

bamboo


build servers

• good screenshot in slides of buildbot view
  
• each box represents a server
  
• split all the tests up between multiple servers that takes an 8 hour build to be an 8 minute build
• each server running many tests; they have 40K tests running through test suite
  
• having good tests allows new people to start working and new experiments to happen quickly
• unit tests of code
  
• user workflow tests of site UI
• if code fails in build server, email goes out and immediately the engineer's supposed to revert the code so others can continue to use build server
• saves and emails output of the test failure
  

Deployment:

• code rolled out to cluster
  
• a bunch of perl and rsync code
  
• symlinks on site
  
• keep multiple copies of code
  
• process of rolling forward and backward is just changing symlink
  

hard part: cluster immune system

• monitors metrics
  
• system performance (web services, disk space, DNS, cron, API availability)
  
• business performance (various critical actions/functions, graphs, revenue, registrations)
• use nagios for system and business metrics
• if metrics bad, do rollback on cluster (changes symlinks back to previous release, blocks further commits, sends email)
• server push status web page to diagnose rollback and which metrics killed the push
  
• one unfortunate thing in the system is false positives due to real variability in business
• once metrics good, goes out to entire cluster
  
• most wait periods: a couple minutes
  
• something it's not very good at: catching very small changes that hurt
  

deployments of deployment system:

• was manual for a while, hacked together
  
• only recently got good test coverage of deployment system (some not even in repository)
• don't change deployment system that often
  

aesthetic tests? they don't

everyone emails changes to the change list (basically everyone in company) with before and after state and people can catch problems

they have one monolithic code base

don't have anything that ensures they have test code coverage automatically


Getting Started (story):

• there were no customers
  
• he came in for operational role
  
• engineers wrote code and SSH'd in to cluster
  
• no auditing, no monitoring
  
• would see PHP syntax errors on homepage
  
• only 30 customers at that time so didn't matter
  
• set the culture of getting stuff out there
  
• wrote a nagios check for "are we rendering HTML out to the customer?"
  
• if you're writing new code, it should have some coverage (functional easiest at first)
• commit to making forward progress
  

new product advice:

• start w/ sandbox
  
• just push
  
• ideal time for failures
  

established product:

• start w/ production
  
• automate deploys. first automate the push. then automate QA.
  
• build confidence
  

new code must have test coverage.

if new code breaks something old, must write test to catch that

expect some hurdles:

• you will have cluster outages
  
• you will spend engineering time on deployment system
  
• have culture where failures are looked at as opportunities
  
• how do we get excited about never letting this happen again
  
• if have blame-searching culture, will have more challenges
  

scaling:

• buildbot would go red, and everyone would be blocked
  
• when build time 20-30 minutes, bad news
  
• problem with intermittent tests
  

solutions:

• build isolation [but not solution; didn't need to build this because could get away with faster test runs, buying hardware and virtualization, sorting tests by speed, dependency injection by instead of calling on real DB, just getting data that would be returned, and also built a hypothesis builder, which is like build isolation where you tag code to run on hypothesis builder that does not run on main buildbot and doesn't block anyone if it fails]
• added a test metrics system that keeps track of success rate and speed (a lot of builds were blocked on slow tests)
• got build times down to 8 minutes
  
• when builds were over 25 minutes, it was a huge cultural issue
  

flaky tests / intermittent tests have huge costs:

• disable or ignore the test
  
• third-party providers
  
• running tests around time and time spans is much more challenging than normal tests (DST, leap years, etc.)
• state dependency across tests (overnight, keep running tests in random orders until they become red, and then in morning you see which tests are intermittent and can investigate)
• they run about 40K tests now
• even with 5 9's of reliability, you get many failures
  
• move them from having to fix them when they happen to fixing them on a schedule
• if buildbot gets a test that runs green once and then red another time, it will mark it as intermittent, start an issue in bug tracker, and allow the build to go through

trickier bits:

• catching issues that fail slow (SQL selects from growing tables)
  
• critical areas cause hard lock-ups (MySQL, memcached)
  
• lack of test coverage of older code: not an issue if you start with test coverage
  
• outsourcing (different hours, culture, branching, slower integration)
  

changing schema requires sign off from tech lead (checking indexes, scalability of changes)

added query killer (issues kill statements on long queries; better to have code die than DB to be overloaded and take down everybody)

schema changes on large tables (they use mysql):

• create a new table
  
• do copy on read
  
• have background process later migrate the rest of the data
  

memcache changes require second set of eyes (hard to test on local sandbox)

hard to work with outsourcers who build over several days (impossible to integrate)

build system itself is critical business function; keep metrics on build system (web dashboard of build process)

integration with A/B testing inside the code (nice slide with pseudocode)

• name the experiment
  
• specify initial rollout % or amount of users
  
• specify customer branches with percentage weightings of what % should see enhanced versus non-enhanced (e.g., 50% A/B split)
  
• helper function that returns which branch a certain customer should see (enhanced or not) and if not yet assigned then to permanently assign [so customer always gets same experience]
  
• simple if statement that splits between if user should see test feature or not
  
• web page listing all experiments (available to everyone in company)
  
• to user % (QA and admin only, 0%, 10%, etc.)
  
• closed on status (they have a page that lists experiments that were closed but the code still exists; this allows easy housekeeping to remove unused code after a while)
  

per-experiment dashboard to see user groups (male, female, etc.), #s, results (highlighted by desired/undesired colors) and p-values

sprints:

• planned sprint schedule usually not met (outstanding issues, incomplete features, tech review, refactoring)
  
• when releases happen every 15 minutes, "planned sprint ends" can be arbitrary
  
• changed to just say that the sprint ends when the work is done (but still understand overage reasons)
  

IMVU culture:

• first day on job, engineer pushes out to live customers immediately
  
• makes people feel empowered
  
• hack-week: you can build anything and company provides food and drink
  
• if you're convinced something's important for customers, just build it and allowed to release to 1% of customers without approval
  

A friend of mine recommended to me The Finkler Question by Howard Jacobson, which recently won the Man Booker Prize. The book explores the question of religious (Jewish) identity in modern times through one man's daily life experiences. The book features both Jews and non-Jews, and the different levels of religious observance (or anti-observance, including self-hatred) tell the story of how different people viewed religious identity differently. I found it remarkable how various non-Jews in the book, like the main character, did more to be Jewish (and wanted to become Jewish), while the Jews behaved in the opposite manner. The book raised many questions, like the meaning of religion and its differences from culture and family (style and tradition).

Overall, the book started very slowly and was quite a long read. It takes place in England, and the audio version featured a reader with an English accent. While this was "authentic," it was painfully difficult to understand (at double or triple speed like I like to listen to audio books); it took me about half the book to get up to triple speed with good comprehension. (Audio books should be offered with multiple speakers to choose from!)

I found the book mostly depressing and sad (this was also the main character's recurring personality), with many themes related to mourning and death and little in the way of humor or comedy. I guess it's not my preferred genre, but after making it through to the end, I do realize why the book won its prize, and the central questions of religious identity and cultural tolerance the book raises are important for everyone to consider. I did enjoy the actual language and literary style as there were many plays on words and cool language tricks that I appreciated.

My notes on the book are below; I'm sure I must have messed up some chapter numbering (and name spelling) at some point, but I hopefully captured the main elements of the plot and my most important takeaways.

Part 1

Ch. 1

• Treslove: Journalist at BBC, non-Jew
  
• Student, writer from Oxford
• Sam Finkler: Jew
  
• Stereotype
  
• Role of Israel
  
• Philosophy
  
• Death of wives
  
• Grief
  
• Bereavement
  
• Loneliness
  
• Trouble finding and keeping love
  
• Robbed and called a Jew by a woman who mugged him 
  
• Libor: teacher, wife Malki beautiful and passed away
  
• Finkler: Jewish, dad pharmacist with stomach pill, wife passed away
  
• Tresolve: BBC journalist, works as a party lookalike, trouble with women
  

Ch. 2

• Role of guilt
  
• Widower bonding
  
• Mistaken identity
  
• Real Jew not faithful
  
• Non-Jew confused with Jew
  
• Had 2 sons with different women who left him
  
• Rodolpho and Alfredo
  

Ch. 3

• Woman who liked him mistook him for Jew
  
• 2 mis-identifications as Jew
  
• Made love to Finkler's wife (Finkler cheated on his wife too)
  
• Finkler's wife Tyler converted to Judaism
  
• Finkler preferred shiksas
  
• Lots of global antisemitic attacks
  
• Thinks others think he's Jewish
  

Ch. 4

• Two girlfriends that had his sons but couldn't be with him
  
• Could he be with a living woman?
  
• Jews aren't the only broken-hearted people.
  

Ch. 5

• Ashamed Jews
  
• Antizionist Jews
  
• "Jewess" word
  
• Cut or uncut: preference by women
  
• Seder
  
• Met woman from fortune teller: Juno
  

Part 2

Ch. 6

• Finkler didn't like Gaza reaction, platform against it
  
• Boycott from universities
  
• Tresolve took vacation with sons
  
• Sons asked if he's Jewish
  
• Just because parents Jewish doesn't mean children necessarily
  
• Can you be part-Jewish?
  
• Antisemitic attacks in London
  

Ch. 7

• Fell in love with Jewish woman Hepsiba
  
• Studied Yiddish dictionary to woo woman
  
• Gave up working as a double at her request so he could be himself
  
• Became assistant curator for Anglo-Jewish museum

Ch. 8

• Can you be defined by what you're not?
  

Ch. 9

• Antisemitic attack at university against Finkler's son Emanuel
  
• Sister Blaise
  
• Emanuel accused Jews of stealing a country (followed what Finkler said)
  
• Emanuel (who is Jew) did an antisemitic attack
  
• Treslove learned Hebrew and Jewish history
  
• Circumcision to limit lust
  
• Book: Moses Maimonides
  
• Commentary on commentary
  
• Hep is true Jewish mother, large body
  
• Bacon smeared on museum doors
  

Ch. 10

• Want to think ill of Jews in their own way
  
• Blogger who tries to restore circumcised foreskin
  
• Meetings of ashamed Jews
  
• Treslove wants to be Jewish to feel more gloom

Ch. 11

• Trouble with women, relating to people
  
• Face-painting incident
  
• Talking feverishly about hating being Jewish is being Jewish
  
• Finkler: online poker
  

Ch. 12

• Libor committed suicide by jumping off ledge
  
• Burdened Libor with info on Treslove's affair
  
• Libor funeral at Jewish cemetery
  

Ch. 13

• Treslove hits Arab demonstrator at museum opening and falls on ground
  
• Stands up for something as a Jew 
  

Epilogue

• Hep said Kaddish for Libor
  
• Cried for Julian
  
• Finkler doesn't give up saying Kaddish for wife after 30 days
  
• Last line: "There are no limits to Finkler's mourning." (True Jew in end?)
  

Noah Kagan is the founder of AppSumo and has worked on marketing for 4-Hour Workweek, Facebook, and Mint. You can watch the video above, and the main things I learned are below. He's a funny, straightforward, and brutally honest speaker, and it was cool to hear about many of the specific tactics he used to get AppSumo off the ground in a lean fashion. He even included a couple deep life lessons in here as a bonus.

• Started AppSumo ("Groupon for software") with just a landing page
  
• Only had registration system at first
  
• Paid an outsourced developer in Middle East $50 for PayPal payment system
  
• Needed a deal, so sent an email to head of imgur (main site for images for Reddit)
• "The most valuable resource is your time."
  
• Just use email to solve your problems.
  
• Learn how to do things with just email lists.
• Took out guy from Reddit for breakfast and got free exposure on their site
• Do something nice and unique for someone.
  
• Sent running shoes, running magazine to someone who runs
• When someone sees something you give them everyday, they remember you and will listen to you.
• Send cookies to people
  
• Initially had ugly designs, just trying to validate as quickly as possible
  
• He emailed every single person manually their discount code by hand.
  
• After the business was validated, they started building the back end and then getting deals.
  
• "There's no way to optimize shit; it's still shit."
  
• Before you get 1000 unique's per day, you can't AB test.
  
• Focused on emails initially to get users
  
• "There's only 1 metric and 1 goal of your business."
  
• At Facebook, the only metric that mattered was growth.
• Only 1 metric at AppSumo is "# of emails"
• They have a daily goal and a monthly goal.
  
• This month's goal: 550,000
  
• Each day have a target of # of emails they need to hit
  
• Used Google Website Optimizer
• Hired an engineer whose sole job was AB testing
• Their view: profit and revenue today is short sighted
  
• Just focused on growing emails for later
  
• If they asked for email up front before showing deal, people were more likely to buy deal than if didn't ask for email up front.
  
• 5% difference in conversion at top of funnel makes huge change.
  
• Spent $6K for 4 iterations just on landing page
  
• Were bringing 3000 to site
  
• Biggest spammer in America: Facebook (recently changed policy)
• No one talks about them as big spammer
• People complained about Facebook but it increased retention and engagement.
  
• Now that Facebook's big, they turned off emails.
• "You'll get some backlash from 1% but will grow the 99%."
• When you travel, you remember just the abnormal stuff; no one remembers the normal stuff that happens everyday.
• Created AppSumo Golden Ticket ($100 credit for no reason whatsoever)
  
• Golden Ticket just emailed by a customer service girl daily
  
• If you're average, customers will never remember.
  
• Think Zappos customer service.
  
• Unsubscribe email sends sad photo that's just something different, memorable.
  
• At Facebook and AppSumo, they put Easter eggs everywhere, fun stuff people will remember.
• They have 3 developers.
  
• If they don't need to build something, they don't.
  
• Instead of building a 404 page, they used a Google Doc.
  
• Do minimal work and if result worth it, do it nicely later.
  
• Did first educational video to actually teach how to use the tools they were selling.
• Did it ghetto with minimal editing
• "Your business should look like shit in the beginning."
  
• Now have full time content and video people
  

I was lucky to visit Walt Disney World for the first time in my life this past week. On the one hand, the weather was great, but on the other, it was the busiest week possible for the theme parks. Given the craziness of the week, I learned a lot of lessons during the trip on what worked and didn't work. I also spent some time researching and preparing for the trip beforehand at the recommendation of some good friends, and I just wanted to share what I learned in case it can help other travelers.

The advice and observations below are made from the perspective of a twenty-something male with no children and a large appetite for action and rides, so the points below might not apply to everyone.

General:

• Disney has four main theme parks in the area (Magic Kingdom [poor imitation of Disneyland], Epcot, Hollywood Studios [poor imitation of Universal], and Animal Kingdom), each of which requires a full day to cover.
  
• Besides the four major Disney parks, there are also several Disney water parks.
• Besides the Disney area, there are also Universal Studios, Sea World, and (I'm sure) many others.
• Plus, there are lots of non-theme park things to do, like golf and shopping (Downtown Disney [like our Universal CityWalk] and others like it).
• A great book I read was Eyewitness's Walt Disney World Resort & Orlando.

Accommodations and transportation:

• There are many Disney hotels right near the parks.
• If you stay at a Disney hotel, you get to go to one theme park per day for an extra hour before anyone else can.
• The closer the hotel to the Magic Kingdom, the more luxurious and expensive.
• There are Disney dining plans, which might give some sort of savings but do come with restrictions.
• The area is HUGE and takes 20+ minutes to make a trip from most of the hotels to any of the theme parks.
• If you stay at a Disney hotel, you can take free shuttle buses and ferries to get to the theme parks. These are a nice convenience, but they can get very crowded and sometimes make many stops and take a while.
• There are also taxis available. A trip is about $18 from hotel to park, but it's a lot faster and direct than a shuttle, so you can use it in case of emergency (or if you slept in late).

Theme parks:

• Biggest obstacles when the parks are this crazy: strollers and scooters/electric wheelchairs. Watch out for the stampede, and definitely avoid the mid-day parade routes.
• Animal Kingdom is awesome. Real animals, unique walking paths and rides, really cool (especially for those who have already been to Disneyland).
• Epcot's World Showcase features architecture, food, and movies from many of the world's countries. Each area is manned by employees who immigrated from that country, which is really fun. This part of Epcot was my favorite.
• Most parks have an end-of-day show. Fantasmic (at Hollywood Studios) is just like at Disneyland, and so it's very good. I thought the fireworks at Epcot were really cool as well. You need to find a spot to view any end-of-day show about an hour in advance.
  
• Disney World has a deal with Verizon that its mobile customers can access a special app to view waiting times. All other people can view them on the general mobile site (though the information is more limited -- no specific waiting times just low/medium/high).
• I used an iPhone app with crowd-sourced waiting times that worked decently well (it also had show schedules and opening times).
• (AT&T) cell phone reception wasn't great at the parks, maybe due to the large number of people there that week, so don't rely on phones for very important communications. Try to plan as much as you can in advance. Portable family radios might be nice to carry for groups.
• Get to the parks as early as you can. It's tough if you stay for the end-of-day show the previous night, but do your best. 8am and 9am are still ok for ride waiting times, but by 11am, the park is packed.
• Get FastPasses every 2 hours to the rides in highest demand. You can come back and ride them anytime after the FastPass window you receive.

Food:

• Make dinner reservations ahead of time. I totally didn't expect to need to do that, but when my friends recommended it to me and I checked availability online, I realized they were right. There are about 2-3 really nice places in each park, and the "normal" meal times fill up weeks ahead of time.
• The Cinderella restaurant in the Magic Kingdom apparently fills up months ahead of time, so if you have little kids, you'll want to bring them there. If you don't, just stop by and take a peek; it's a pretty restaurant.
• There are some surprisingly good lunch places in each park as well, and these take reservations as well (and they book up days ahead of time). I was always used to just eating "theme park food," and on this trip, I learned I could actually eat nice, healthy, non-fried food in quieter, sit-down environments, which offered a nice break in the day.

Favorite restaurants:

• Animal Kingdom Tusker House
• Animal Kingdom The Yak and Yeti
• Epcot Biergarten
• Epcot Bistro de Paris (one of the best soufflés of my life)
• Hollywood Studios Prime Time 50s Cafe (awesome decor)
• Hollywood Studios Hollywood Brown Derby
• Magic Kingdom Tony's Town Square
• Magic Kingdom Liberty Tree Tavern

Favorite rides:

• Animal Kingdom Expedition Everest (really nice coaster with single rider line)
• Animal Kingdom Safari (real animals, best early in the morning)
• Animal Kingdom various walking paths
• Animal Kingdom veterinary hospital visit
• Epcot Test Track (fun and fast)
• Epcot Spaceship Earth (cool way to teach history of science)
• Epcot World Showcase (ethnic food and foreign languages -- 'nuff said)
• Hollywood Studios Tower of Terror (really fun at night)
• Hollywood Studios Toy Story (worth the hype, really fun interactive game)
• Magic Kingdom Enchanted Tiki Room (funny)
• Magic Kingdom Tom Sawyer Island (lots of secret things hidden and cool walking paths)
• Magic Kingdom Space Mountain (seemed better than Disneyland's)
• Magic Kingdom Thunder Mountain (as good as Disneyland's)
• Magic Kingdom Haunted Mansion (almost as good as Disneyland's; only worse because it seemed shorter)

Least favorite rides:

• Animal Kingdom Dinosaur (not worth the hype)
• Hollywood Studios Backlot Tour (way shorter and less interesting than Universal's)
• Epcot Mission to Mars (a bit boring)
• Magic Kingdom Pirates (seemed shorter and worse than Disneyland's)
• Magic Kingdom Jungle Cruise (after seeing real animals in Animal Kingdom, this ride pales in comparison)

James is the VP of Engineering at IMBU, the very first Lean Startup founded by Eric Ries. IMVU experimented heavily on its way to tens of millions in annual revenue. In his talk, James describes how to build a culture and team of experimentation in your startup. You can watch the video and see the slides above.

Below are my notes on James Birchler's talk on experimentation at IMVU. I enjoyed his talk, particularly the segments that dealt with the specifics of IMVU's processes.

The Scientific Method is based on experimentation.

Core:

1. culture
   
2. technique
   
3. examples
   

Story of Copernicus

• heliocentrism
  
• experimental observation
  
• was met with violence; Church threatened him
  

Giordano Bruno (burned at stake)

Galileo

• scientific method
  
• put on house arrest
  

It was hard for these guys because the folks in charge didn't like hearing "bad news."

IMVU

• experiments
  
• share results freely, no matter who's pet project
  
• rapid iteration and learning
  

1. ask question
2. do research
3. form hypothesis
4. test (science?)
5. analyze data
6. conclusion
7. report results

And cycle back to beginning

Lean startup: build, measure, learn loop

1. talk to customers for use cases
   
2. form a hypothesis to test
   
3. write code, test on dev machine
   
4. test in production as QA/admin
   
5. roll out to a % of customers
   
6. analyze results, conclusion
   
7. share learning
   

Culture of experimentation:
Started out as simple as this:
if (setup_experiment(...) == "control") {
// do it the old way
} else {
// do it the new way
}

Then later built robust experiment management system

• Columns: experiment name, to which users (QA and admin only, 100%, 50%, etc.), status/close date
  

Also built tool to calculate statistical significance

• sample count: control and treatment
  
• mean: control and treatment
  
• variance: control and treatment
  
• p-value
  
• significance
  
• chance of occurring randomly
  
• table of user data with rows highlighted to show which validated or invalidated experiment
  

Embrace failure with exec team and whole company.

Embrace failure as an opportunity to learn.

Highest paid person's opinion (HiPPO) is not assumed to be correct.

Reference to paper "Practical guide to controlled experiments on the web."

Easy to screw up process at every stage

• use cases
  
• test hypotheses
  
• rinse, repeat
  

Don't ask customers what they want.

Instead, ask customers what they are trying to do.

Focus on use cases and not what they say they want.

What not to do: build what customers say they want.

Do this:

• start with use cases
  
• test hypotheses to learn best ways to fulfill them
  

It takes a lot of courage to balance experience, instinct, imagination, and experiment results.

"If you design a toaster oven and need to include directions for making toast, you have failed at designing a toaster oven." -Laura Klein

Don't just run a bunch of experiments without a strong point of view of what trying to learn.

Experiment design

• start with use cases
  
• have a specific hypothesis
  
• ask the right questions
  
• ask the right people
  
• ask enough people
  
• randomized control trial
  

experiment interpretation

• use the right p test
  
• don't rely only on p test
  
• don't confuse correlation with causation
• find psych or stats PhD's to help

Experiments are a great way to test hypotheses, not form them.

Product development

Build:

• 2-3 week sprints
  
• stop and adjust process each sprint
  
• agile and XP methods
  

Agile & XP methods:

• change, flexibility, iteration, continuous improvemnt
  
• Agile and XP support each other
• physical scrum board with post-its
• self-organizing teams, short sprints, daily stand-ups (15 min), no emails (just talk)
• clear roles and responsibilities: product owner, tech lead, visual designer, UED, QA
• stay flexible, don't be dogmatic
  

Measure:

• projects/stories completed
  
• time spent on tasks
  
• story points delivered
  
• unplanned vs. planned work completed
  
• how productive and happy do we feel
  

Learn:

• project postmortens
  
• sprint retrospectives
  
• 5 why's root cause analysis
  
• support open communication
  

Open communication:

• engineering project managers (just to assure engineering communicates ok)
  
• matrix management (managers manage people across teams to get slice across company)
  
• scrum of scrums (weekly uber-scrum mtg)
  
• team swaps (individuals switch teams liberally)
  
• open floor plan
  

Postmortems and retrospectives:

• meeting roles
  
• metrics
  
• action items
  
• all levels of organization must be in it
  

Meeting success:

• appoint a skilled facilitator
  
• foster communication and engagement (talk about elephant in room)
  
• table: days, project, story points
  
• whiteboard columns: misc., keep, stop (action item), start (action item)
  

5 Why's: fix root cause

Make the size of the fix commensurate with the size of the problem.

Handling interrupts

• Share interrupts among teams
  
• Create "interrupts" team; establish home team and rotate others through it
  
• Whenever someone commits code that fails battery of tests, interrupts team needs to fix the tests or the code.
  

Time tracking (used to do it more but now do it less):

• Focus on features and value to customers, not time
  
• Short planning meetings
  
• Caution: reduced ability to predict progress
  

Scrum 2.0: continuous planning

• based on successful process experiment
  
• just-in-time planning: kanban
  
• are we working on the right stuff?
  

User testing:

• pay $50 for 30 min of someone's time
  
• ask them to play your game, watch their reaction
  
• stop them after 15 min. and say they can go
  
• if they want to keep playing, then you're doing well
  

Keep your team together: embed designers, QA, data analyst, engineering and product in same location

Have a fixer: remove blocks, remain objective, team happiness = team productivity

Technical project reviews:

• organized by team tech lead: tech review of code, improve quality, reduce tech debt
  
• in-depth reviews of code
  
• all engineers welcome
  
• note follow-up action items
  
• prioritize actions and do them
  

Experiment they ran: small teams in a bare garage + no rules = big win

• break out of routine
  
• minimize process overhead
  
• focus on value to customers
  

Self-selecting teams: let people self-select to the teams they want to work on

Shake things up

• Switch to continuous planning
  
• Story points vs. Ideal Days
  

I wanted to write a short post on the topic of time management, mainly asking a question as opposed to providing an answer. I'm curious to learn how readers manage their busy schedules and what time slicing method works for them.

By "time slicing," I'm referring to two opposing methods that I've considered for time management:

1. Intra-day/small slices: Each day is filled with many types of activities that you need to be involved in. This means everyday you exercise, meet with customers, network with colleagues, do informational interviews, recruit, write code, do online marketing, eat, have fun, and sleep. That's a ton to fit in to one day, and each slice is necessarily small (or non-existent on certain days).
2. Intra-week/large slices: Separate days are devoted to separate activities. Huge swaths of time are devoted for intense focus on 1-2 important activities. For example, all coffee meetings, interviews, phone calls, etc. are on Fridays. All marketing work is on Wednesdays. Workouts are 2-3 days a week. And the rest of the days are all for intense work on ____ (fill in the blank for your most important function, like coding, recruiting, designing, etc.).

There are clearly pros and cons to each method. Large slices allow more intense focus and less switching costs. Small slices allow more "balance" in each day and quicker responses to opportunities that come up (like for phone calls, meetings, etc.). And sometimes you don't have a choice: if you really need to meet with someone who can only meet on a day that's not your "meeting day," it will disrupt your rhythm.

This decision also gets into the need to say no to various requests for help or meeting (or at least delays if not no's), which can often be painful to do.

What do you do? What methods have you found useful in managing your time along this axis?