Posts Tagged behavior

Pokerbot Lesson: Work Hard During the Good Times

August 26, 2009 at 9:03 pm · Filed under Random Thoughts ·Tagged , , ,

As I mentioned in an earlier post, I wrote a poker bot in 2004.  I learned a lot from that project, and I’d like to share some of the lessons learned over a series of blog posts.

All poker players are familiar with the game’s swings.  Poker’s unpredictable sequence of wins and losses stems from the addictive cocktail of uncertainty and randomness that makes the game so popular.  There are many lessons to learn while riding the roller coaster of wins and losses, but I’ll focus on one that’s particular to a poker bot author (or an investor in the markets).

Imagine if you unleashed your poker bot algorithm and observed the following performance over the first 10,000 hands.

Pokerbot performance over 10,000 hands

Pokerbot performance over 10,000 hands

It takes a poker bot about 22 hours to play 10,000 hands.  This assumes that the bot plays 10 tables simultaneously, averaging 45 hands per hour at each table.  For comparison, it takes a human about 28 days to play 10,000 hands, assuming he plays an intense 30 hands an hour, 12 hours a day.  Although it’s not a large enough sample to yield a statistically significant win rate, it’s a sizable sample.

The first couple of times that this happened to me, I couldn’t help myself from leaning back and thinking that my troubles were over.  Instead of analyzing more data or writing more code, I’d relax.  Then I’d see this turn of fortune.

Fictional graph of big bets won or loss over time.

Fictional graph of big bets won or loss over time.

The downturn would give me a kick in the pants, and I’d dive in again to my work with vigor.

After this pattern happened a couple times, I realized how much time I was wasting.  Frustrated by this inefficient cycle, I made a point of staying vigilant even when the results looked promising.  I learned that you have to work hard even when everything’s going smoothly.

This lesson is applicable to both investing and software development.  When your PnL is positive, you need to make an extra effort to stay sharp.  When you’re writing software, you can’t assume that your program is correct just because it runs without throwing off errors.  Be suspicious and stay vigilant, even when things seem okay.

Comments (2)

Navigating New York’s Attitude toward Technologists

August 17, 2009 at 5:52 pm · Filed under Business, Random Thoughts ·Tagged , , , , ,

I just read Zed Shaw’s post where he announces that he found a job in San Francisco.  Congratulations to him.  In his post, I appreciated his concluding comparison of how companies in New York and San Fran perceive and approach technologists.  Zed says:

NYC prospects were looking for a badass/ninja/rockstar beta-male “techie” employee to make them rich creating lame applications for giant Finance/Fashion/Marketing companies.  SF prospects were looking for a partner to get rich with them creating great products for customers.

To a large extent, I agree.  New York is filled with companies that have non-technical core competencies.  These businesses treat technology as a necessary cost.  When they search for a rockstar ninja, their goal is to minimize cost.  The thinking is “that last tech we had was too slow and too sloppy, and his mistakes cost us money.  We need a superstar tech guy to come in here and do things right (not screw up).”

The dynamic is top-down.  The business wants a super star who will take orders and work efficiently.  On the whole, this makes perfect sense.  As Judge Smails says, “the world needs ditch diggers, too.”

This system fails for superstar techies like Zed Shaw.  This class of techies are often prima donna’s in the same vein as star wide receivers in the NFL.  Instead of taking orders, they want to provide advice.  Instead minimizing cost, they want to generate value.  Indeed, they want to be partners, not employees.  (Even if the company pays well, as many New York firms do).

San Francisco, on the other hand, is a town filled with ninjas looking to band together.  Each one is a Steve Jobs looking for a Steve Wozniak to join them in the garage.  This is a natural and attractive situation, as evidenced by Zed’s move from his beloved LES.

New Yorkers do have hope.  The key is to pursue and promote every opportunity to increase revenue instead of decreasing costs.  When you see this opportunities, you need to explicitly point them out.  Then, if you’re given the green light, work extra hard to execute.  If you score a couple wins, then you can take a partnership role (even in New York).

Comments (1)

Maker’s Schedule in Finance

July 29, 2009 at 10:03 pm · Filed under Business ·Tagged ,

I just read the Freakonomics article responding to Paul Graham’s recent essay, “Maker’s Scheduler, Manager’s Schedule.”  The short summary is that managers break their day into 1 hour blocks and makers (programmers, writers, etc) break their day into halves.  Therefore a one hour meeting can destroy half of a maker’s day.

I’m certainly a maker who’s usually pessimistic about the utility of meetings.  I know the productive rush of putting on my headphones and diving head first into a program.  I’ve worked that way before.  It’s nice, and it works for me.

But I work at a startup in finance.  It is simply not possible to structure my day to avoid meetings or interruptions.  In particular:

  1. You can’t work all night and saunter in at 11am the next day.  The market is open from 9:30 to 4:00, so you absolutely must be there for those hours.  Even if you don’t personally interact with the market, it’s against the culture to be absent during trading hours.  If you want to get ahead and make a difference, you need to be there early and leave late.
  2. The financial world is fast-paced and event-driven.  You can’t go dark for hours or days on end.  When something happens, people around you react, and winners jump up and pitch in.
  3. For technologists in finance, the customer is king.  The “customer” might be an investor, trader, or boss.  If they want to talk, you respond immediately.  An attitude of “hey, I’m knee deep in some code” will not work.

These realities mean you either need to adapt or fail.  Here are some of my techniques for producing quality software within the fast-paced, event-driven world of finance.

  1. I use OmniFocus to manage my tasks.  I’ve tried other task management programs before, but none of them work as well as OmniFocus.  It encourages me to target small, bite-sized tasks that are robust to interruptions.
  2. I put off deep dives to the evening or weekends.  I think it’s counterproductive to make a habit of long hours or working on weekends, but it’s sometimes necessary.
  3. I take note of common requests, and find time to write a program to help me fulfill them, even if the program is an undocumented script that’s for my eyes only.  This reduces the severity of interruptions.
  4. Be blunt about ending meetings.  You can’t always be Mr. Nice Guy.  Sometimes you just have to cut somebody off and get back to work.

I’d love to hear how other makers manage the reality of their work environment.

Comments (1)

Zen and the Art of Elevators

June 29, 2009 at 11:19 pm · Filed under Random Thoughts ·Tagged , ,

I work in a high-rise building that secures its elevators with keycards.  In principle, the access system is simple and intuitive: employees and visitors are given keycards that they swipe past a sensor inside the elevator before pressing their floor button.  In reality, the building’s access system has a bad user interface, which regularly frustrates both employees and visitors.  During one early morning ride, the frustration was so bad that it almost boiled over into fisticuffs.

When I’m riding the elevator, I enjoy observing how various people react to the security system’s quirks.  I view it as a sort of a Rorschach test that exposes how people interact with technology.  A couple small quirks in the security system make the familiar interface of elevator floor buttons awfully cumbersome.  Only people who take the time to think about the implementation details succeed in calmly selecting their floor.  Those who take the Zen approach, avoiding any detailed thought of the elevator’s control system, typically end up spastically jabbing the buttons or missing their floor.

I drew up a simple flowchart that describes the security system’s behavior.  When the elevator doors open in the building lobby, the system is in the non-blinking state at the top left.  To keep the drawing simple, I haven’t drawn what happens when two people swipe cards or press buttons simultaneously.

Elevator Control Flowchart

Elevator Control Flowchart

The correct path for trouble-free operation is marked with bold arrows that move counter-clockwise around the drawing.  To follow this path, you must:

  1. Swipe your keycard past the sensor.  Be sure nobody else swipes their keycard at the same time.
  2. The sensor’s red light starts to blink.
  3. Wait 1 second.  Do not press the floor button too quickly because the press will be ignored.
  4. You’re now able to press the floor button.  The sensor is still blinking in the same way.
  5. Press the button for your floor.  It will light up.
  6. Everybody else must wait 5 more seconds for the sensor to stop blinking before they can swipe their card.

This description and the flowchart make a few design flaws apparent.  Most glaringly, any deviation from the correct path causes confusion or delay, and the flowchart depicts many potential detours.  The most common detours are:

  1. A person swipes their keycard and immediately presses their floor button.  The button doesn’t light up, and access is delayed.  The typically causes the person to start jabbing at the button.
  2. After somebody has selected her floor, but before the red light stops blinking, somebody else swipes his card and tries to press his floor button.  The swipe is ignored and the button press is rejected.  Everybody must wait roughly 5 seconds for the little red light to stop blinking before starting the process over.
  3. Two people swipe their card at roughly the same time.  Neither are sure which swipe, if any, was accepted.  The more aggressive of the two people starts jabbing their floor buttons while the other person steps back.  Typically all the button presses are ignored until the red light stops blinking and somebody tries again.

With such a poorly designed user interface, there’s no surprise that temporary visitors usually get confused.  I’m somewhat surprised that long-time employees remain confused.  In the terminology of Robert Pirsig’s Zen and the Art of Motorcycle Maintenance (which I’m re-reading now), these people are taking the Zen viewpoint toward technology.  They don’t want to trouble themselves with taking the time to think about the system’s details, which causes frustration when they encounter a problem.

If you visit my building, beware of the elevator.

Comments (1)

Follow

Get every new post delivered to your Inbox.