Cory Forsyth » general

CTO School Session 4: Recruiting and Hiring

cory — Thu, 10 Nov 2011 03:52:49 +0000

Vivek Sodera from RapLeaf @vsodera

+ - recruiting at Rapleaf
- start out interviewing 25-40 engineers/month, goal was to increase that multiple times
- pattern recognition
- by the end: averaging interviewing 1200-1300 engineers per month
- philosophy: pass over someone good rather than pick someone bad
  - passed candidates were picked up by google, facebook, etc
questions
- + - how many were/are you trying to hire?
  - wanted to keep lean, didn't want to drastically effect culture
  - hire 1-2 per month
  - hiring 1 out of 1000, or 1 out of 1500 people
  + - if you know you only want 1-2 people a month (for a total of, say 10-ish), why not sniper and just choose those people and go after them directly?
  - part of the rejection marketing is to get the word out about the company
  - it's not just hiring, it's also marketing for the company
  - rejected candidates sometimes ended up becoming customers
  + - how many man-hours did you spend on this process?
  - hiring is the most important thing, so that's always their primary focus
    not everyone in the company is involved in the recruiting...the first 15 people were, after about 20 hires not everyone was involved
    depends on where the company is. When you're small you're going to work your ass off finding people and figuring your process
    over time their engineers got much better at pass/failing test results
  + - when you were bringing in 1-2k people per month, how many were involved?
  - the ops specialist who was managing it
  - new engineers would get trained on how the process works and to bring in new people
  + - what about online contests/games for devs?
  - yeah, useful, but sort of low ROI
    helpful if you have a platform you can make available for them to use/learn on
    example: they had their own brilliant dev come up with a very difficult problem, and market it around (to ACM entrants, etc)
    - 50% respond, try it out
    - got a handful of decent apps
    great to find research-minded thinker types...but if you're small maybe you need a *doer* more importantly
  + - q about interns: are they a good use of time?
  - 40% of the interns they ended up hiring full-time
  - vetted them well
  - summer internship
  + - did you ever measure your cost-per-hire
  - outsourced lead gen was the cheapest by far
  + - did you use adsense, facebook ads?
  - yes...but fb ads didn't do well
  - what ended up working was going to conferences (posting little ads above urinals in the bathrooms)
  - played with auto-retweeting, auto @mentioning people who say certain things...
  + - what's the referral process?
  - at one point giving 10k if the person was hired and stayed for more than 90 days
    toned it down to 5k (which was contested)
    if you send us someone who passes the first round, you get $20, 2nd round you get $100, etc etc -- didn't get much success from that
  + - what was best?
  - outsourced lead gen
  - send very informal emails (lowercase words in subject line)
  - a paragraph or two tops...the PS was the call to action
  - A/B test up the wazoo
+ - snipering vs shotgunning
- snipering
  - passive candidates
  - lots of experience
  - looking for vp eng, cto level roles
  - number of hires small (1-5)
  - outreach via recruiter, referral, phone, email
- want to give the impression that it's hard to get into your company
  - message is: we want high quality people
- shotgunning
  - looking for active candidates
  - 0-10 year experience range
  - looking for lower-level positions (software engineer, manager, director)
  - large number of target hires (3-100)
  - the person who runs this is the operations specialist (they build the machine/funnel)
  - need to clearly show what your culture is
  - (preferred approach)
+ - rejection marketing
- want to give perception that your company is sought-after and exclusive
- bring as many people into the pipeline as possible
- and reject as many people
- rejectees will tell friends, friends will want to apply to see if they are "up to the challenge"
- increases the number of high-quality organic applicants
- feed the funnel with low-quality candidates (they will get rejected and tell their peers)
+ - building a recruiting machine
- define and document core values
- + - modify recruiting/interviewing flow for scalability
  - phone interviews don't scale to this many candidates...hence online tests
  - "here is what we would ask you in a phone interview, you have an hour to get back to us"
- hire ops specialist to run the machine
  - they own this
- outsource menial tasks
- make the copy interesting
  - no one gets excited by '3.5 years of X, 2 years of Y'
  - think of it as a brochure for your company...
- fire recruiters, they suck
  - they are working with X companies, maybe you have a retainer
    if they come across a great candidate, they will send their best people to the companies paying the highest commission (which will not be your company)
    they all source from the same places, they all have the same candidates
    caveat: there are some awesome recruiters (but are very rare0
    doesn't like getting candidates from recruiters...they (the candidate) are often lazy...it's a lazy approach to looking for a job
- iterate, iterate
recruiting channels
- outsourced lead generation
  - create a fake linkedin profile
    add linkedin open networkers (they have tons of reach)
    once your linkedin network is highly expanded, you can find more people
    also: odesk...find cheap labor, pay people to go on linkedin and look for types of people, scrape the data...email thousands of those people, see who you can bring in
    get those people onto a monthly newsletter so you can keep emailing them
    - the newsletter was engineering-related
- direct mail blasts
- content for developers
- social media outreach
- ads/flyers
- university outreach
- distributed job posts
- developer-centric events
  - events that had free beer/sandwiches, learning opps for developers
- research data sets

Kurt from Intent Media @kurt

Kurt from Intent Media @kurt
- internet ecommerce advertising company
- 2.5 yrs old
- 42 people
- just raised $20MM
questions
- + - what to do if you come in to a startup as CTO and there's a team there that doesn't agree with you?
  - get credibility
    look at every set of commits that comes in...comment on them if necessary
    (audience suggestion: pair program w/ some of the developers to get familiarity with the code, and respect)
- + - approx what team size do you stop being a coding cto?
  - it happened organically
    it got to the point where there were so many meetings that he couldn't block out 3- or 4-hour blocks to code
    have to make the decision whether you are coding all the time or you are going to protect your engineers from distractions so they can be coding all the time
    "I never had a 4-hour block, so it was never worth getting started" on some coding
    try to keep engineers out of meetings
- + - how should the biz side relate to engineering? what level of communication is appropriate?
  - they still all work in an open space
  - priorities get decided upon by sales, bizdev, chief product officer
  - along w/ that, he adds technical thigns like "we need to upgrade rails"
  - present the biz folks with a list...this is what we can do...what do you want me to do
- + - Q: You have a CTO above you...so what does he do and what do you do?
  - Kurt handles inward-facing stuff
  - CTO handles outward-facing stuff
    - investor relations
    - he's technical, not a technologist
  - they have each other's backs
- advice on what to do with an underperforming engineering team and an overbearing demanding biz side?
  - used to work at thoughtworks (agile consulting), they would go into places and consult on agile
    there's a 'consulting answer'
    in a startup environment, the answer is fire those people
    if someone is underperforming, there's no point in saying "let's wait a while and see"
    - never gone back and said, "glad I waited to get rid of that person"
    along with that, if you come in to an underperforming team and it continues to underperform, it looks bad on you
    little more tricky on the biz side of things
- what are other ways you protect your team or other things the team needs protecting from?
  - protect from: meeting/overhead that you can absorb
  - don't let some sales guy go talk to them to get something developed that they need developed
  - minimizing distractions
  - letting engineering run the show (sort of)
- can you comment on your hiring process vs vivek?
  - part of it is a numbers game
    need to get out there, meet people, find people
    referrals is a huge part of the way to do it
    open-source some of your company code that is not core to your business...people will use it, fork it, develop it...hire those people
- do you involve engineers in hiring?
  - yes
  - multiple interviews, multiple tech interviews, a non-tech interview
  - have recruiters in-house
one of the first employees -- in charge of creating a dev team
- half engineering/qa/data science
+ - culture
- if you have an engineering culture it has to permeate the entire company
  - can't just be siloed to the dev side
- they work on 2-week iterations, releasing 4x a week
- there's a company meeting every tuesday...very open
  - the biz people explain how they are goign to close a deal this week
  - then if it doesn't close that week they explain why the following week
+ - first steps
- make it a strong engineering culture
- the first 2,3,4 hires really set the tone. they are important
- first hire needs to be a tech guy, needs to be a doer
+ - coming in to a new situation
- if you come into a place that is in a bad situation
- need to change engineering, force people to write tests, write good code
- all the consultants except for one fired themselves
- "this is an engineering company, engineering always has a say"
- can't let biz or sales guys run over the engineering
- have to constantly broadcast information
  - whole company needs to know where the build is
  - what's coming down the pipeline
  - make it clear to see what the tradeoffs are
- if you are one of the first...at some point you are not an engineer anymore, you are overhead
  - your job is to make it so that the engineers can write code (unimpeded)
    when the CTO is trying to write code, there's no air cover for the rest of the engineers, they are vulnerable to biz folks sneaking in requests, distractions, etc
+ - hiring
- at an early stage, when you really need to hire, you can't always get the perfect person
- + - you need to build to your team's strength
  - e.g. he likes ruby, they built first stuff in ruby
  - for the backend ad server, they could only find java guys to hire, so they built in java
- + - need to keep people challenged
  - don't let people get bored
  - if they get bored, they will leave
  - have to let engineers be engineers
  - if you lose a couple of really good people, it is a waterfall from there on out
  - anyone here (in this room) can walk out the door and find 10 new job offers for more money
- he brought in people he worked with before, they all knew they would work together well
+ - development
- allow engineers to code
  every afternoon has time blocked out when no one is allowed to talk to engineers so that they can work
  + - be constantly refining how things are done
  - have an engineering/product retrospective every six weeks where we sit down and talk about what's wrong and how it can be made better
    sometime that's "there are too many meetings"
    sometimes it's "this bizdev person keeps bothering me with requests"
    important thing is to have the input/feedback loop and keep building the culture toward what you want it to be
  keep asking: does this feel right?
  - you have to keep defending what you are there to do

CTO School Session 3: Peter Bell

cory — Thu, 03 Nov 2011 04:02:38 +0000

I was lucky enough to make session 3 of CTO School tonight, where Peter Bell, CTO of Skinn.io, spoke about Project Management, Quality Assurance, Estimation, user stories, metrics-driven development, and more. As I've come to expect, it was a very informative and thought-provoking session. I'm looking forward to the next one. Here are my notes:

+ - metrics-driven development
- be willing to pull out a feature when it isn't working
- book: continuous delivery
+ - deployment
- continuous deployment
  - automated unit/acceptance tests
  - also biz metrics tests
    - if orders/day decreases significantly, rollback
  - perf tests
    - after deploying, look to see if common user behviors are taking longer than normal. if so, rollback
- when do you do this perf/biz metric testing?
  - when the pain of not doing it exceeds the pain of adding new features
  - "probably not before you hit product market fit"
+ - pivots & rewrites
- it's gonna happen
- need to think heavily about what tech to use...don't over-scale early
- neil ford: "if you add a feature early, you are incurring tech debt"
  - ex: pull in info about twitter friends/followers
    perfect fit for async msg queue
    however, start by doing it sync -- takes a few seconds, but no real pain point there until more load, so don't change it yet
    "what is the simplest thing that will work"
    if you put in a hacky solution, put enough tests around it to avoid breaking the whole system (and reduce the fear of refctoring)
+ - user stories
- 1/2 the room is using user stories (~ 15-20 people)
  As a 'role' I want 'feature' so that 'benefit'
  if you can't come up with a reason for a user to use that feature, they are probably not going to use it (don't build it!)
  INVEST
  - I-independent
    N-negotiable (if you can't fit all the info on a 4x6 card, get a bigger sharpie and a smaller card (you are doing too much)
    V-valuable
    - if it doesn't have a benefit, don't do it.
    - If you can't clearly articulate the benefit, don't do it
    - two types of feature ideas
      - one type you think of offhand and then forget about it
      - the other type bugs you every time you use the system, everyone clamors for it
        those are the ones you should build
    E-estimable
    - needs to be clear that we can figure out how to do it
    - if it's not estimable, maybe it's a spike
    S-small
    - break things down...good size of story is 'half a day'
    T-testable
+ - user story decomposition
- tracer bullets - not tasks
- decompose into something that a business user can test
  - not necessarily something releasable
  - ex: registration system
    - hardcore--lots of steps, health care, etc etc
      start with the simplest thing (first/last/email/password) now I know who you are
      so simple it won't even validate these things...just laying out a form with a message. (first story)
      - now it's something a biz user can test! "yes, I like that message" or "no, that message is wrong" etc
      now going to require validation (next story)
      - automated test: make it ID-based (look for #registrationError). Don't make it check for a string...too brittle, that string may change
      now add one more screen with some healthcare info (next story)
      at each point ask, "is this an MVP," could we release here?
      this way new stuff is available for internal biz users to view and test on a daily or near-daily basis
  - 'happy path'
  - add validation
  - add data
  - add robustness
  - ex: algorithm:
    - what's the simplest algo to write that can do something useful
      - something that just returns a 0 or 1, maybe, rather than the full prediction value
    - then what's the simplest improvement you could make?
    - repeat
+ - questions
- institutional memory -- how do we make sure we keep the deep knowledge behind something available
  - the problem is, most institutional memory has alzheimers...
  - the info is on a wiki
  - but the wiki gets out of date
  - our institutional memory becomes misleading
  what acceptance test do you recommend?
  - they use rspec
    committed the pretty-print rspec html output and made it available for everyone in the company to see, so they know what's up
  + - when you are small, getting all stakeholders to sit down and agree on everything itself becomes an overhead...?
  - yes, all process is an overhead
  - ex: daily standup: what did I do yesterday, what am I doing today, what's blocking me?
  - you can use an event to drive process
    - let's get beers tonight and make a decision about the specs
  can you give ideas for product roadmapping?
  - i like eric ries' definition of a lean startup
    - a human institution developing products or services under conditions of extreme uncertainty
      - intuit even decided they were a lean startup
  - how much uncertainty do you have?
    - if your customers are signing up for v17 of your software and they're expecting a roadmap and you're expecting them to stick around for a long time, maybe they need it
  does a roadmap have to be a fixed direction, or can it be a set point? ( a vision)
  - assumption: no one is creating a blind startup
    - == a startup that makes a 2-year roadmap, follows it no matter what anyone says, and checks to see if they are relevant at the end of 2 years
    what's the value of having a roadmap, knowing that you are in an uncertain world, knowing thigns will change?
    diff b/w vision and roadmp.
    - vision: "we are going to staten island"
    - roadmap: "this is how we are going to get there"
  reality: VCs are paying for our dev time...THEY want to know what we'll be building for next 3 months
  comment: any planning past 6 months goes nowhere...we plan for 3 months (and can usually hit it), but plans for 6-months+ never happen. and these are guys that manage 500+person orgs with millions of dollars behind them. And they had predictable businesses with established pipelines
+ - iterations
- 1/4 doing 2-week iterations
  - 1-week iterations are awesome if you can keep the pace up
  - the world is moving toward 2-week iterations
  - month is really long these days
- kanban-based approach
  - you have some kind of backlog (stuff to do "next")
    - this comes out of manufacturing
  - you focus on limiting work in progress
    - goal is to minimize cycle time
      in manufacturing, thngs half-built are worth nothing (you don't get paid until you ship *completed* cars)
      same with programming...all half-finished features add 0 value to biz...kanban says: let's get the NEXT feature done as fast as possible, and get it out
- iterations v kanban
  - when an organization has little structure, iterations can be good
    - because they force you to focus for a few weeks
  - kanban can help you, too, because it makes you focus on just one thing
  - books
    - lean software development (from 2003)
+ - estimation
- why estimate at all?
  - cost go/no-go (if this takes 3 weeks to build, we can't do it.
  - market window
    - if it takes 6 weeks but it's necessary for somethign happening in 3 weeks, don't build it)
  - ROI comparison
  - not just "because" -- use estimation if it helps you
- time, price or both?
  - most of the time it matters how much or how long it will take
  - sometimes it doesn't matter how much it costs (within reason)
  - worth knowing which is most important (can spend more to dev fast, versus dev slow but save money)
  - what's successful -- 5% over time budget but 1000s use it, or 5% early but no one uses it?
    - if you need estimates granularly at wildly accurate numbers, something is not right
  - ideal days:
    - problem with using ideal days is not every day is ideal (meetings, installing software, etc etc)
  - story points
    - 1,2,5,epic
      - split epic into smaller amounts
      people always ask "how many hours is a point"? so use ideal days when you're just starting
      to get over the hump, just use ideal days and drop the days. 3 ideal days = 3 points
      don't allow 0-point cards
      - because you can end up with 100 0-point tickets and everyone expects it to happen immediately
      - roll up multiple small ones into a 1-point story
      problem with using larger numbers (10,20,50) is people will end up saying "oh, 47.5"...no one can be that precise
      - small story points numbers makes people not estimate so granularly
      t-shirt sizes (small, medium or large)
+ - quality assurance
- automated tests
  - unit
  - integration
  - acceptance
- build in quality
  - you don't improve quality by doing more inspection
    - best way to improve software quality is not to do more QA
      - although you do still need that
  - two important things:
    - build in quality by writing automated acceptance tests
    - do qa before you write the code
      - Test-driven development
  - if you have a QA resource (tester, manager, whomever)
    - bring them into the meeting when you spec the feature...ask them how they would break/test it
    - write down what they say...that's one of your automated acceptance tests
- what to do if you get a legacy codebase with no test coverage or lousy coverage
  - very first thing: make sure the developers know *how* to write tests (get a consultant, figure it out, whatever you need to do)
    every time you get a bug, WRITE A FAILING TEST
    - you will start getting clusters of tests in the important parts of your app
    every time you tweak a method, write a test or two
    - the boyscout method...leave the code cleaner than when you got there
- it's ok to not have code coverage in certain places, too
  - you might have code you know you're going to throw away in a week
    write tests for the parts that scare you, that you don't know well how they work or think they'll break
    write tests for the critical parts of your codebase
+ - pair programming
- having a pair is about 15% less efficient than two people programming separately
- but there are 20% fewer defects/bugs that way
- ends up being roughly a wash, efficiency-wise and much better code

CTO School Session 1: Being the Tech Leader

cory — Wed, 12 Oct 2011 15:51:55 +0000

I went to CTO School Session 1 on Monday night. Charlie O'Donnell interviewed Mark Uhrmacher, CTO of Ideeli. I was in the back of the room and couldn't hear all that well but I used FreeMind to make a mindmap of what I did hear. These are my notes:

+ - hiring
- distributed ok
  - timeshift
  - mumbai, canada, ukraine, us, spain etc
- look for people who can think at all levels of stack
- ask lots of technical questions fast and furious
+ - key technology decisions
- chose Rails (early on)
  - max dev productivity
- no time to rewrite
  - two modes: what sticks? and omg it's working
+ - dev methodology
- 2-week sprints
  - keeps QA in sync w/out drifting
- no religious philosophy
+ - biz-minded CEOs who don't understand tech
- how to provide visibility to non-technical CEO?
- agile methodology helps b/c short timeframes
  - short timeframes: less deviation b/w biz side and tech realization
- have to appreciate you have a better understanding of the tech
  - set expectations and beat them slightly
  - if someone asks for the impossible, say it's impossible
- be transparent
  - "share your risk"
    - here's what at stake
    - here are the tradeoffs
    - becomes join risk/decision
  - engineers have a tendency to want to please
    - keep that in check
    - you are managing for shareholder value
- being the best technologist is not a requirement for a CTO
  - communication is the key thing
+ - how does structure of org change over time?
- QA:
  - outsourced in phillipines, india
  - never as automated as he would like
  - they do full regression tests
- product manager
  - hired at 10 people
  - while rebuilding UI
  - actually needed someone w/ good proJECT mgmt skills to corral different aspects
- outsourced, distributed dev team
  - program mgmt becomes more important
    - program v product v project
    - program: set of projects. mixture of product and project
    - requirements gathering, feature definition, herding cats
+ - any conflict about who is managing developers? (product v cto v ?)
- did not happen
- could happen where people are more naive about dev process
+ - at what point did developers become managers?
- first dev became manager, was doing both, started to flame out
- hired head of development to replace him, moved him to architecture manager
- organization truck number:
  - how many people have to get hit by a truck before you are dead in the water?
+ - how much do you think about developing roles?
- cool think about growth companies is they are ruthlessly merit-driven
- lots of room at the top
- if your skills exceed your years, this is the place to be
- no need to "pay your dues"
+ - how do you find a peer group of other managers?
- there is a CTO club in nyc
  - range from technical people to great managers
+ - characteristics of good hires
- curiosity
- thinking at multiple levels
- initial impression of NYC dev market was people were looking to fill particular roles/niches
- but doesn't think that's a good thing
- need people who can adapt to changing roles/products/technologies as opposed to experts in one particular one
+ - how do you manage communicaton w/ distributed time
- skype
- mingle (thoughtworks product), didn't scale past 20 devs
- now use jira
  - card tracking/bug tracking
- added confluence for wiki (recently)
- most dev and ops guys live in skype
  - and in card tracking tool
  - IM
    - long-lived dev chatrooms
- it's a tough environment to write code in
  - very obvious who is phoning it in
+ - any formal processes to keep in touch aside from ticket tracking?
- daily scrum call (they have to shift time to get on that call)
- break into smaller groups as opposed to all 70 devs on one call
- daily scrum calls keep things working
+ - how did they manage outsourced QA, making sure they had a test plan etc?
- for regression tests, for every bug they'd automate a test or put in their plan
- work from the same user stories used to develop features
- for critical functionality, or something subtle, program managers would write out test cases
- now they have product managers do further user acceptance test
+ - growth period
- 15% month-on-month growth last 40 months
  - just keeping the wheels on the train is a challenge
  - things that are annoying now become unmitigated distasters in 180 days if not handled well
+ - big advantage of distributed team
- they can fix problems overnight
- interesting: much higher productivity from developers who are not in the office
  - offices are distracting
  - corporate culture is very interrupt-driven
+ - how do you measure productivity?
- "how full is the parking lot at 6pm" -- fairly standard metric (in SV)
- cards are either getting done, or not getting done
- look at your 2-week sprints...what is getting done?
+ - how do you balance time to market v code quality? (esp when you are small, starting up)
- you WANT to get a product to market
  willing to incur tech debt to get there
  the hope is you get large enough that eventually you can get a "team B" who can pay down tech debt in parallel w/ new features
  12-24% of SW development bandwidth goes to refactoring
+ - what is the value YOU personally contribute now to your company?
- worried about org structure
  - how good are they at getting thigns done? (features, bug counts, happy customers?)
- is there a better way to organize?
- continuous improvement model
- Am I putting pieces in place to ensure future success?
  - if it's too hard for devs to figure out what to build, bring in product person
+ - how do you build trust and recruit developers internationally?
- finding people who knew rails was hard
  - in NYC mostly impossible
  - had to look elsewhere
- building trust: spent many hours w/ open skype sessions...like sitting next to him

DFW Words

cory — Wed, 07 Sep 2011 22:52:45 +0000

I read David Foster Wallace's The Pale King in April. These are some of the words I looked up while reading it.

specular
obtrude
cruciform
applique
gimbal
incursion
chert
invaginate
connubial
parenchyma
irrupt
divest
umbrage
exacerbate
merrythought
sally
discursive
thanatology
plaint
imperious
imbrication
cowl
spindle
prolix
dyad
dyadic
labial
agnate
anfractuous
stridulate
carmine
blancmange
iterant
timorous
bandolier
forbearance
prostrate

Such a sesquipedalian guy, that DFW. (I seem to have lost some of the other words. The full list would be about twice this length.)

Every Book I Read In 2010

cory — Thu, 27 Jan 2011 21:22:59 +0000

Every book I read (from cover to cover) in 2010, and the date I finished it. The ones with stars are my favorites. Looking back, there's clearly no pattern. I was a bit of a book slut in that I read anything anyone recommended to me (if I could make it through it). The attitude for last year was: read at any cost, just keep reading. This year I am going to be a little more selective (but only just). I read more YA books than I ever did when I was a YA myself (thanks, Guillian and the generous bookshelves of Simon & Schuster). Somewhat disappointingly there are no math or science or tech books on here. I've already improved on that this year. Best fiction: Special Topics in Calamity Physics. Total edge-of-seat, keep-me-up-at-night read. The final third of the book is a graduated series of shocking plot twists and revelations. Unputdownable. Marisha Pessl: Release Night Film, already. Best non-fiction: Open. The writing style was cloyingly precious at times, but the story was very interesting and inspiring for me. World Lit Only By Fire was a very close second. Most forgettable: Spook Country. Took me 15 minutes just now to remember what it was about. Thanks to all my friends who gave me recommendations and especially the New York Public Library. Keep the recommendations coming; my goal this year is to read more than I did last year.

✩Lush Life by Richard Price (January 4th, 2010)
The Girl with the Dragon Tattoo by Stieg Larsson (January 12, 2010)
Close to the Machine by Ellen Ullman (Jan 16, 2010)
Zodiac by Neal Stephenson (Jan 21, 2010)
Lowboy by John Wray (Jan 28, 2010)
black swan green by David Mitchell (Feb 23, 2010)
how to lose friends and alienate people by Toby Young (Feb 14, 2010)
✩The believers by Zoe Heller (Feb 12, 2010)
✩Chronic City by Jonathan Lethem (Feb 5, 2010)
Kite Runner by Khalid Hosseini (Feb 10, 2010)
Bridge of Sighs by Richard Russo (Mar 29, 2010)
Ender in Exile by Orson Scott Card (April 11, 2010)
✩Stones from the River by Ursula Hegi (May 7, 2010)
The Nimrod Flip-Out by Etgar Keret (May 11, 2010)
✩Although of Course You End Up Becoming Yourself by David Lipsky (May 15, 2010)
Spook Country by William Gibson (May 20, 2010)
The Girl Who Played With Fire by Stieg Larsson (May 31, 2010)
✩A World Lit Only By Fire by William Manchester (June 30, 2010)
✩Before I Fall by Lauren Oliver (June 10th, 2010)
Distracted (June 15th, 2010)
Asterios Polyp by David Mazzucchelli (July 1, 2010)
✩Hunger Games by Suzanne Collins (July 26, 2010)
Catching Fire by Suzanne Collins (August 5th, 2010)
✩Special Topics in Calamity Physics by Marisha Pessl (August 10th, 2010)
Logicomix by a group of folks (August 14, 2010)
The Girl Who Kicked the Hornets' Nest by Stieg Larsson (September 1st, 2010)
Vurt by Jeff Noon (September 7th, 2010)
✩The Secret History by Donna Tartt (September 20th, 2010)
Mockingjay by Suzanne Collins (Sep 24th, 2010)
Wake by Lisa McMann (Sep 26th, 2010)
The Mortal Instruments by Cassandra Clare (Oct 4, 2010)
✩The Particular Sadness of Lemon Cake by Aimee Bender (October 24, 2010)
✩Open by Andre Agassi (November 7th, 2010)
✩Inherent Vice by Thomas Pynchon (November 19, 2010)
✩The Unnamed by Joshua Ferris (November 23, 2010)
I, Claudius by Robert Graves (December 26th, 2010)
Netherland, by Joseph O'Neill (December 29th, 2010)
✩Shades of Grey by Jasper Fforde (December 30, 2010)

Destiny is a thing to be achieved.

cory — Thu, 13 Jan 2011 17:13:18 +0000

"Destiny is not a matter of chance; but a matter of choice. It is not a thing to be waited for, it is a thing to be acheived." — William Jennings Bryan, my great-great-grandfather.

Year in Cities, 2010

cory — Tue, 11 Jan 2011 20:34:36 +0000

My yearly retrospective. These are cities I spent the night in during the year 2010. You can also see lists for 2009, 2008 and 2007. Asterisks indicate cities I spent non-consecutive nights in. You can also see this in map form, somewhat, at my Family 2010 World Map.

January

Maho Bay, St John, USVI* (pictures)
Brooklyn, NY*

February

Red Hook, St Thomas, USVI
Maho Bay, St John, USVI*
Bangkok, Thailand (pictures)
Chiang Mai, Thailand
Chiang Mai Highlands, Thailand (Trek)
Chiang Rai, Thailand
Luang Prabang, Laos

March

Koh Samui, Thailand
Logan, UT*

April
May

Allentown, PA (Father-Uncle-Son Road Trip V. pictures.)
Strasburg, PA
Gettysburg, PA
Front Royal, VA
Charlottesville, VA
Blowing Rock, NC
Asheville, NC
Pigeon Forge, TN

June

East Hampton, NY
Bovina, NY

July

Jersey Shore, NJ
Maipú, Chile
Santiago, Chile
Reñaca, Chile
Great Barrington, MA*

August

St Louis, MO
Montauk, NY (pictures)

September

Montauk, NY
Great Barrington, MA* (pictures.)

October

Binghamton, NY (Nat'l Mini-golf championship. pictures
Seattle, WA (Visit Jenna. pictures)
Key West, FL
Manhattan, NY*
Fort Lauderdale, FL*

November

Atlantic Ocean (Cruise. pictures)
Fort Lauderdale, FL*
Logan, UT* (Thanksgiving. pictures)

December

Maho Bay, St John, USVI* (pictures)

Today is the 34th Birthday of Punk Rock

cory — Fri, 04 Jun 2010 22:12:13 +0000

On June 4th, 1976, the Sex Pistols played their first gig at Manchester's Lesser Free Trade Hall. There's a book written about it called The Gig That Changed the World. You can read an interview with the author here. The reenactment from 24-Hour Party People:

Thing a Week: Meditation

cory — Tue, 01 Jun 2010 20:29:30 +0000

This week I'm going to try meditating every day. I read AJ Jacobs's article about unitasking and the focus-destroying properties of multi-tasking last week. It reminded me that I have been wanting to try meditation. Last night's meditation: 5 minutes. Notes: That went much faster than I thought it would (meaning I didn't get bored), but my mind still wandered like crazy after a couple minutes. Today I'll push it a little. I'll include some more thoughts here as the week goes by.

Year in Cities 2009

cory — Sun, 10 Jan 2010 19:11:50 +0000

Here are the lists for 2006, 2007, and 2008. January St John, USVI Salt Lake City, UT Logan, UT* Washington, DC Brooklyn, NY February Edinburgh, UK* March Edinburgh, UK* April New Haven, CT May Barcelona, Spain Gualala, CA Garberville, CA Arcata, CA Crescent City, CA Gold Beach, OR Coos Bay, OR Portland, OR Seattle, WA June Nashville, TN Bovina, NY* July Logan, UT* October Berkshires, MA November Bovina, NY* Atlanta, GA Logan, UT December St John, USVI*