Hack hack hack...

An open journal-- some of it written for you, but most of it is for me.

What Working in Professional Baseball Taught Me About Web Development

Before I was a web developer, I spent my time on baseball fields helping teenagers realize their ultimate dream of playing in the Major Leagues. All of them had talent. Somewhere, someone had seen glimpses of it. Cultivating that talent and turning their potential into performance was the primary purpose of my job. In the vast majority of cases we failed. Now, a few years removed from the game, most of the players I worked with are out of professional baseball. Those who did succeed, found a way to endure the grind and adjusted to the game’s mental and emotional demands.

In 2012, I hit the reset button on my career and became a web developer. I thought I would be leaving baseball forever. However, I found that many of the same traits I saw in successful ball players, even those with very little formal schooling, were some of the very same characteristics I observed in talented engineers. The inability to manage failure, maintain consistency, and learn how to be a professional shattered the dreams of the vast majority players I worked with because they were skills that were so difficult to master.

When I see one of them on TV, it’s hard to not recall the younger, yet unmolded version. It is why I was never the best scout. The baseball scout’s job is to imagine the possibilities. They envision a future version of a gangly youth whose body and mind has matured and whose flaws have been smoothed away to the point they can perform in the Major Leagues. It is a hard job and one that I wish existed in other industries.

Facing failure

Successful people, in any field, often struggle with making mistakes. This isn’t surprising, we are wired for bad news. We internalize it. We personalize it. Repeated failure is exhausting. Ball players, whose hitting success rate is at best around 30% are forced to cope. Failure is inherently part of the game.

Resilient players’ confidences seem immune to repeated failure. In fact, failure appears to be inextricably linked to their progress. This makes sense. We improve fastest based on negative feedback. The great thing about that big red error message is that it leaves an obvious clue. Sometimes these hints are more obscure than others, but bugs and errors inform us where to look and where to improve.

Getting repeatedly beaten by the same pitch provides feedback on where hitters need to improve in the same way that a familiar error in our terminal window instructs us where in the code to start looking for our mistake. As humans we learn through repetition and experience. The goal is to not getting beaten again by the same pitch or the same problem.

When I first started learning to program, I focused on never repeating the same mistake twice. This, of course, is impossible but I recorded most my thoughts and posted it online so that I had a searchable collection of my mistakes. The frequency of my posts have waned, but I still find myself searching my blog archives when I know I’ve solved a similar problem in the past. While it was rare to see ball players jot down notes on opponents, most hitting savants have the ability recall previous pitch sequences from past at-bats. Either way, the secret to coping with failure is to reframe it as valuable feedback to be used in the future.


As developers, we know that consistent performance is important. We construct our dependencies on the most stable parts of our applications. The same goes for managers: when Sarah demonstrates she can be depended on to meet deadlines on a day-to-day, week-to-week, sprint-to-sprint or quarter-to-quarter basis, Sarah can be relied on to build the feature to satisfy the high priority business objective.

Consistency creates the opportunity for measurement. Like the measurement of feature velocity based on a set period of time, comparison of player’s abilities would be worthless without a standard 162 game schedule where the participants play nine innings with nine players on the field. Without a level playing field, comparisons are no longer valid and people can get really upset (see baseball and steroids).

Consistency is difficult because we are wired to break free from it. We are not as perfectly repeatable as the scripts we write. Our brains thrive on novelty. The day-to-day becomes mundane without it. We seek out adventure and variety. We create drama where there is none. We endeavor to learn new things.

But mostly being consistent is just showing up. Being there when products ship and stuff goes down. Career defining highlights are created when people are in the right place at the right time. Crashes on the production server and DEFCON 1 bugs are inevitable but these panic moments create opportunities. Under pressure, acting as you always do makes you a hero.

Derek Jeter’s lifetime batting average was .310. A consummate professional, he hit .308 in the playoffs. Just being yourself when the pressure is on and more eyes are on you makes it seem like you are rising to the occasion. No one is perfect, but bringing your best everyday provides predictability to our human unpredictability and separates the amateurs from the pros.


Professional baseball is a child’s game played by overgrown men who make millions of dollars. Make no mistake about it, baseball is a grueling sport. The schedule is relentless. Players arrive at the stadium five-plus hours before the first pitch to weight train, stretch, hit, throw, review scouting reports, etc.

After a three hour game, players are expected to hold court in front of their lockers and answer questions that essentially boil down to, “Tell us about your glaring mistake that you made in front of thousands of people across America.” Each major league team plays 162 games in about 180 days – not to mention the the month of spring training before the season starts and, if they are lucky, a month of postseason games. Eighty-one of these games in other cities meaning players are switching time zones for weeks on end. The truly blessed ones do this for 20+ years. What the casual fan sees of a player on any given night is the result of thousands of hours of refining subtle movements through exhaustive repetition.

And while we developers don’t enjoy the fame and fortune of Major Leaguers, we get to solve the worlds’ hardest puzzles. The impact of our code has touched the lives of nearly every human on the planet. The drudgery of implementing the vision of others is offset by the natural builder’s high.

Hacker News is littered with discussion on how writing software can crush your soul, but for the lucky ones, the “job” retains its joy. Despite the jeering fans and elusive bugs, there are a blessed few who simply love what they do.

The Same But Different

Of course, there are stark differences between baseball and software engineering. Software has been in the hands of laymen for less than a generation and baseball has remained unchanged since before the Civil War. While software’s impact continues to accelerate, we should pause to take breathers and remember that what is old becomes new again. There are lessons to learn everywhere we look and baseball has proven no different for me.

I love what I do. I’ve never been as challenged as when I’m muddling to make sense of a new concept or totally lost in a self-created code mess. The wins and losses I’ve experienced as a developer are like nothing else I’ve experienced as an athlete or a coach. While I’m still a relatively new programmer, my experiences in baseball have transferred as valuable lessons on coping with failures, reliability, and professionalism.

Not all that long ago my work day consisted of spotting the subtle deficiencies in a pitcher’s delivery and the sound of a shortstop’s feet as he ran a 60 yard dash, but when I watch how a junior dev deftly uses her VIM shortcuts or the ease of which she writes a complex SQL query, I’m reminded it’s not so different after all.

Kris Gale

This was a great interview.

Responsive Organization

Evaluation is a busted idea

  • “It’s my opinion that the big company evaluation systems we all think of have been broken for a very long time. Long before Drive came out, W. Edwards Deming was practically yelling at the world that performance evaluations were a busted idea.”

  • “Remember that annual bonus money is not free money that comes into existence when a company decides to give bonuses. Bonuses are, effectively, a group of people agreeing to give up a percentage of their salary for their managers to redistribute to the people those managers arbitrarily select. What sane group of people would agree to that?”

  • “Bonus-tied reviews by the management layer reduce an organization’s ability to change direction, because it incentivizes people to deliver what they’ve committed to, even as new information suggests different work would be more effective.”

  • “It’s interesting that everyone asks about the evaluation process. I think that’s a really strong signal that most engineers don’t work in structures or environments that provide enough transparency.”

Oren Ellenbogen

From the author of leading snowflakes.

Q & A

Q: do you insulate devs from business objectives so they can concentrate on their task or let them understand the big picture so that they buy in?

A: Juniors need to be execution machines. KPIs filter down to the technical lead and engineering leads.

Q: How would you approach evaluations in general?

A: Need to let go of the idea that evaluations are purely objective. You want them to fit culturally and grow. If they are accomplishing these goals they should be rewarded and if not are way off, they should be fired.

Notes from discussion with Oren

  • Learn from your peers:

    • Make a list of ppl that do things well. Pick their brain on it.
  • Expectations

    • What are must have qualites and what are deal breakers?
    • What makes your tick?
      • I work best when___
      • It annoys me when ___
    • write down a charge’s 6 month performance today
      • if you really have a solid foundation of trust, share it with them

Own thoughts

Personal preferences are based on YOUR preferences – I had misinteerpreted what they represented in the book. But why should your charges adjust to you, rather than the other way around?

The book’s perspective seems to be for teams little bit larger team than what we have (currently 7) - so I’m interested in your thoughts on goals for small teams before WE REALLY DON’T NEED A REPORTING STRUCTURE when things are pretty messy still and people have to do a lot of things (like a startup), but we still want to give inexperienced developers some structure.

- baseline expectations - which we have done and they are soft (passion, 'getting it done', making the 'right' technical decision) - so they are subjective
- Personal expectations - technical risks, technical growth

This is all pretty soft and that means that performance is pretty subjective which makes it pretty hard to align goals with our future direction or OKRs.

site speed? user acquisition? We aren’t close to that.

If you could pick one and only one metric to systematically increase over time, what metric would have the greatest and most sustainable impact on you and your team’s effectiveness? But these quantitative number really can’t be all of it…

Helping others, code review, their code is breaking seem like more appropriate and directly pertinent to a dev’s day to day performance.

Circle Ci Debugging

Chasing a crazy bug on circle ci. Passes locally. Used VNC to drop into circle ci to try to track it down. Really cool to get into that box but it didn’t shed any light on the error.

The next step was to capture screenshots of what was going on. The capybara-screenshot gem was a perfect fit but the screen shot was not showing the element actually being tested. For some reason it just wasn’t being displayed. It clicked that the window width was at tablet size meaning the element was being hidden by a media query. Shit.


Polymorphic Brain Hurt

Polymorphic association from parent to child

So this succinctly summed up my issue.

Deprecated conditions in rails 4

Deprecation warning when using has_many :through :uniq in Rails 4

Then once I did get it working with:

Conditions Refactor
# lesson model
  has_many :readmes, :through => :lesson_contents, :source => :readme,
    :conditions => "lesson_contents.content_type = 'Readme'"

  has_many :labs, :through => :lesson_contents, :source => :lab,
    :conditions => "lesson_contents.content_type = 'Lab'"

# stabby lambda
  has_many :readmes, -> { where("content_type = 'Readme'") },
    :through => :lesson_contents, :source => :readme

  has_many :labs, -> { where("content_type = 'Lab'") }, :through =>
    :lesson_contents, :source => :lab

Hat Tip

Polymorphic Migration

Creating a [polymorphic migration](http://stackoverflow.com/a/5534614/1496757)
class AddImageableToProducts < ActiveRecord::Migration
  def up
    change_table :products do |t|
      t.references :imageable, :polymorphic => true

VIM Shortcuts

File Search

  • cntl + p => file search

Nerd Tree

  • go => preview pane

Run the specs

  • \r runs the closest spec
  • \R runs the whole spec suite

cmd + shift + d

  • control + n

vimium for life

  • \\f + character you are looking for
  • \\w + word
  • \\e goes to end of words
  • you get it

Go to line

  • line number + G

Tab in or out

  • >> & <<