The Programming Butler

Peer feedback

Tue, 25 Apr 2023 00:00:00 +0000

It’s that time of year again and I’m asking for peer feedback and writing feedback for teammates and realized I’ve learned a few things about this process over the years that I think are worth sharing.

Asking for peer feedback

A close teammate and friend @kmcq gave this piece of advice recently and it really stuck and has made this review cycle at work much more straight forward and enjoyable:

One thing that I’ve found helps me write better peer reviews more efficiently for folks is for the requester to mention something that they’d like me to highlight: a project, quality, or whatever that I can speak to that adds evidence to what they’ll be writing themselves. This helps focus things and saves a lot of time.

I took that idea and ran with it and when I started asking my peers for feedback I included links to things I wrote or code I shipped that they could reference.

This greatly reduces the burden on the people you are asking but at the same time I don’t want to limit what they include in their feedback so my requests went something like this:

Would you be willing to provide me peer feedback? The feedback form has pre-defined questions but here are some potential areas from our IC expectations that I would appreciate feedback on and links to work related to those areas that I completed during this review cycle:

Leadership and Communication

Provides substantial technical leadership to help others learn and grow

example 1

example 2

Technical Contributions

Demonstrates deep knowledge of data – knows what data is needed, how to find new or missing data, connects disparate or ambiguous data

example 1

example 2

Typically when I provide feedback I focus it on just one expectation or project so you could just pick one of those examples above that you feel comfortable speaking to or choose something else entirely. Critical but constructive feedback is welcome and desired. If there is something I can be doing better for you or the team please don’t hold back.

I would of course be happy to give you peer feedback if I can be of service.

Writing peer feedback

I’ve been writing peer feedback two to four times a year for up to a dozen individuals for the majority of my 11 years at GitHub. Here are a few guidelines I use today that I’ve learned over the years.

First, when someone asks you for peer feedback ask them to apply the advice above! It’s a lot easier and faster to write feedback when the range of possibilities has already been narrowed down.

Second, address the feedback to them and not some third party like their manager. For example instead of saying “I appreciate how Rachel gathers requirements from stakeholders and delivers high impact results” say “Rachel, I appreciate how you gather requirements from stakeholders and deliver high impact results”. This feedback is for them! Not their manager.

Third, there should be no surprises when giving constructive feedback during a review cycle. What I like to do is reinforce feedback I’ve been giving during the review cycle and if at all possible provide examples of how I see them improving and encourage more of that behavior.

Year in review

Sat, 30 Dec 2017 00:00:00 +0000

This year flew by with a couple life changing family events, several projects shipped at work, and a lot of learning.

Family

We took two family trips to Florida this year to visit Natalie’s parents. The first trip was after her father found out he had cancer and the second trip was to help her mom pack up and move after he passed away. Of course these weren’t easy trips but I cherish the time we had with them.

Adalyn is growing up faster than I can comprehend most days. She’s opinionated, independent, and can be sweet and then harsh in the span of a few seconds. Right now I’m trying to learn how to help her concentrate on a task or project for more than a few seconds at a time.

In August Natalie and I celebrated our tenth wedding anniversary (and fifteenth year together). My mom flew in to take care of Adalyn so that Natalie and I could get away for a few days. We flew to Portland and had a great time exploring a new city kid free!

The final piece of big news is that Natalie is pregnant and due in April!

Work

I can’t go into detail about most of my projects now that I’m on the security team at GitHub. I still write blog posts regularly but they only get posted to a private work blog. What I can talk about here is some of the cool tech I’ve been learning and using.

React, GraphQL, and design

One of my responsibilities is building workflow tools for a team of analysts. Most of these workflows are queues and the analysts have to review items in the queue as quickly as possible.

We chose Rails with webpacker and a React frontend implemented in Typescript that reads from a GraphQL API using the Apollo client library. We’ve been able to build super fast and information rich user interfaces with this tech stack and we’re loving it for the most part.

One thing that hasn’t worked great has been combining multiple API’s into a single unified GraphQL API, specifically re-exposing the GitHub Platform in our apps GraphQL API. We’ve had to duplicate a lot of the objects the GitHub Platform exposes and whenever we want to expose a new object or field we have to touch half a dozen places in our codebase.

Thankfully the folks over at Apollo have built a server side solution but it’s implemented in javascript so we’re planning on swapping out Rails in our stack for a node app. We believe schema stitching will have a significant impact on our development speed and maintainability.

I’ve also spent a good deal of time reading about user interface design and applying that knowledge to the analyst workflows. I started by reading through this site from 1999 by Jenifer Tidwell and am now reading her book Designing Interfaces: Patterns for Effective Interaction Design.

Machine learning

We’ve deployed multiple models to production now and have pipelines for training, testing, tuning, and deploying new models. While I haven’t been very involved with the actual model building process I have been spending a lot of my time developing new features for us to use in our models.

During model development our ML stack is Presto, Jupyter, and scikit-learn. When it’s time to put things into production we use Airflow to train and tune models on a regular schedule and then the models are deployed as microservices in our kubernetes cluster.

Stream processing

Over the past few months we’ve switched to publishing our signals as protobuf messages to kafka so that we can use any number of consumers and start experimenting with stream processing.

We’re currently running two types of stream processors. The first is a Ruby app using the Racecar gem. This app has let us experiment quickly with new streams and has helped us enable everyone on the team to do some basic stream processing.

The second one we’ve been experimenting with is Flink. It is way faster and has many more features than our simple ruby consumer app but we’re still ironing out the development process for the rest of our team as you have to write Flink apps with Java, Scala, or Kotlin. Our initial spike with Flink was in Scala but recently we’ve been writing apps with Kotlin which I think we’ll end up preferring to Scala or Java.

2017 Reading List

Stop, Start, Continue for 2018

I need to stop hurting my health with snacks and sugary drinks and stop working late nights and being immobile for hours on end staring at my laptop.

I would like to start exercising consistently, finding medical help for ongoing pain, spending more time playing with Adalyn and hanging out with Natalie, and interviewing again.

I’m going to continue studying machine learning and learning new technologies while consistently shipping at work, supporting my family and my teammates, and taking time to reflect and evolve.

Thank you!

Thank you to everyone who helped me through 2017, especially Natalie and Adalyn, my parents, and my teammates at GitHub :heart:

Ten Years a Software Engineer

Mon, 05 Dec 2016 00:00:00 +0000

Ten years ago I started programming professionally and now I’m a Senior Engineer at GitHub. This blog post begins with a retrospective and ends with what I’m looking forward to in the future.

How did I get here?

Growing up I was always building, repairing, using, and teaching people how to use computers. With a steady stream of spare computer parts from my Uncle John and encouragement from my parents it was easy to get started and advance quickly. Most of my friends were into computers too and a couple of them got into software development but for some reason I didn’t start considering it seriously until 2006. I had done some html, css, and javascript hacking starting in the late 90’s but everything I had built up until 2006 was for myself (like my first blog).

In 2006 everything changed when customers of my company SabreTech started asking if we could build software for them. The opportunity to make money was enough to get me interested and I asked my friends Christian Metts, Daniel Parker, and Joshaven Potter for advice and help. With their help we shipped a couple of projects for customers (foreverrememberme and sixsigmaforms) and I started to catch the programming bug. That same year I attended the first RailsConf in Chicago and started building software to run SabreTech’s operations.

The first half of 2007 we took on more projects including building a centralized billing system for a chain of tanning salons and a network and computer monitoring system with remote access infrastructure to make helping customers faster, easier, and cheaper. Programming work was still my secondary job though, my primary responsibilities were building, installing, and repairing computers and training people how to use them. At this point I was driving an average of 1000 miles per week for work and I would continue to do so for the next 3 years.

The second half of 2007 brought major life changes including getting married and moving to Elkhart, Indiana. Shortly after moving I did a google search for “ruby south bend” and came across the SBRB group that met at the University of Notre Dame. I attended my first meeting that fall and met John Nunemaker and Steve Smith.

Over the next three years I would continue doing programming projects for customers (jukeman), for my business (suitecs), for family (globalauto), and one little side project with John Nunemaker and Steve Smith.

That little side project turned into a job offer in late 2010 and I sold my share of SabreTech to my business partners and started working full time as a software developer at Ordered List. Brandon Keepers joined our team a few weeks after me and then Matt Graham joined a couple of months after that.

Over the course of 2010 our small team built a new product while maintaining our existing products Harmony and Speaker Deck as well as paying our salaries by consulting for companies like Zynga (we helped Zynga scale Words with Friends and helped design and build the javascript version of Words with Friends for Facebook).

Along the way our friends at GitHub noticed our products and our work and in the fall of that year made an offer to acquire our small company. The five of us joined GitHub on December 5th, 2011.

Since joining GitHub I have helped serve our support team, finance team, sales team, customers (specifically GitHub Enterprise admins and Organization admins), and now our security team by designing, planning, building, and maintaining software. I’ve built and led teams along the way but my responsibilities have mostly been solving problems for my coworkers and our customers using software. Earlier this year I was promoted to Senior Engineer. This promotion was especially exciting for me as I looked back at the previous ten years and what it took to get here.

What did I learn along the way?

So. Many. Things.

The importance of mentors as accelerators to growth. Being a leader is often about building trust, giving ownership, and avoiding surprises. That figuring out a process that works for your team matters. That deliberate iteration paired with discipline is a driver for success. That it is important to know your weaknesses and deal find ways to deal with them. That focus is an ongoing struggle. That solving the right problem, doing the simplest thing first, and failing fast are things I value. That listening to friends and family can save your life.

But I’ve written about all of those things already. So what haven’t I written about?

Retrospectives

This blog post is a result of reflecting on the past 10 years so I figured talking about my process for retrospectives would be fitting. Consistent retrospectives are probably the largest contributing factor to who I am today compared to 10 years ago.

Taking time every day, week, month, and year to analyze decisions I’ve made, actions I’ve taken, and the actual outcomes versus my expectations is how I learn what I need to change who I am into who I want to be. A recent example, taken from a personal SWOT analysis, was that I have a tendency to talk over my peers when I get excited about an idea ☹️ As soon as I identified this behavior I started working to change it.

A retrospective goes something like this:

Set aside distraction free time.
Think about something that has happened, whether it was something I did or that happened to me.
Consider the situation, how I feel about it, what I can do better the next time I’m in that situation.
Follow up homework if needed. This could be anything from repeating the situation so I can get better at handling to reading about the subject to learn how other people think about it.

Setting aside time is the hardest part for me, so I’m always keeping an eye out for these distractions:

Social media
Entertainment (TV/movies/podcasts/audiobooks)
Speeding through life

Likewise these are opportunities for reflection that I’m constantly looking for:

After personal devotions (or meditation)
After receiving feedback (good or bad)
After pretty much every conversation
After reading, watching, or listening to something (entertainment made both lists!)
The end of the day, week, month, and year

I like to write down the things I’ve learned through my retrospectives and I often use frameworks like Start/Stop/Keep or a SWOT analysis to help me organize my thoughts and find patterns. This gives me a great opportunity to find repeating themes over the years and track my personal progress. And sometimes it even turns into a blog post 😃

Where do I see myself going in the future?

I’ve been interested in Machine Learning for the past year and recently took a new position at GitHub working on the Security team where I get to use my current skillset and learn some ML and computational statistics techniques. I’m really enjoying it so far and I think I’ll be focused on Machine Learning and Artificial Intelligence for the next few years. I’ve also been hardware hacking as a hobby for the past few years so maybe I’ll get to build that robot butler someday.

Intention vs Perception

Sun, 23 Nov 2014 00:00:00 +0000

It is interesting to study the gap between the intention of communication and the perception of communication in the context of leadership. “We’re going to do X going forward” can be interpreted as “You’re doing a crappy job at Y so we’re going to try X now” or “We decided that it is better to do X instead of Y because we had a meeting you weren’t invited to since we don’t really value your opinion” and the list of interpretations goes on.

In my experience perception rarely matches intention, so figuring out how to change your message to get across what you actually intended is a fun challenge.

There are probably many ways to do it successfully, but I only have experience with a few so I’ll share those (YMMV).

Earn the trust of those impacted

Earning trust takes time. Time spent learning about someone, how to communicate with them, what they are passionate about, understanding their fears.

I like to take people out to lunch, video chat, pair program on a code kata, or help with a problem they are having.

This is the first opportunity to be a servant leader I think. Serve the people you lead and, more likely than not, you will gain their respect and trust.

Give ownership

When someone is going to change the way I work, what I’m working on, or who I’m working with, the psychological toll of that change can be greatly reduced if I feel like I have control over my own destiny.

I look forward to working with leaders that engage me and get me involved in the decision-making process. They ask things like “What do you think about doing X instead of Y; what would be the benefits and what would be the drawbacks?”

Asking for, listening, and reacting to my feedback gives me ownership of an idea, even if it was not my own. Reacting is not necessarily implementing my feedback, but this process of involvement changes the way the idea was communicated and perceived.

Avoid surprises

There is a bonus to talking one-on-one with everyone on a team about an idea before announcing it at a meeting or in an email. You avoid surprises. Turns out not many people enjoy surprises, unless it’s a surprise party.

Having an opportunity to hear and discuss an idea before it is executed gives me time to get comfortable with it. If you have gained my trust then I also feel like I have time to provide feedback before the idea becomes reality.

SWOT Analysis

Mon, 17 Nov 2014 00:00:00 +0000

In college I learned how to do a SWOT analysis and I’ve been using it in one form or another at work and in my personal life ever since.

Update 5-19-2015: The authors of this amazing SWOT guide reached out to me to let me know about their work. After reading my simple how to below check out their full guide to learn even more.

So why do I care about my strengths, weaknesses, opportunities, and threats? Because I’m ambitious (both a strength and a weakness) and I constantly want to be better at everything I do and I want everything I’m a part of to constantly be improving.

How do I identify and analyze these areas with regard to my personal life or work life? I choose what I want to analyze (myself, a friend asking for feedback, an area of my job) and then sit down with a pen and paper.

I start by draw by drawing a vertical line down the center of the page and then a horizontal line across the page. I now have four quadrants and I label them S, W, O, and T.

Next I write down weaknesses and then strengths in their quadrants. You probably won’t be sharing this analysis with anyone so be brutally honest. Depending on your disposition you may find it easier to write down weaknesses than strengths, or vice versa. With time you’ll get better at identifying both if you practice consistently.

Once I have an understanding of strengths and weaknesses it is usually pretty easy to identify opportunities that capitalize on strengths and work to turn weaknesses into strengths. Likewise threats are anything that could turn a strength into a weakness or further entrench an existing weakness.

Now you have to decide what action to take based on the opportunities and threats. After repeating this process a few times you start to see patterns and improve your process even more. Here’s an analysis I did on myself a few months back with regard to my work life.

I noticed after this analysis that my first opportunity, “listen more”, was the most important thing to act on because it addressed several of my weaknesses while building on my strengths and lessened at least one threat. This is one pattern I look for now, opportunities that apply to multiple concerns.

Try a SWOT Analysis next time you want to level up.

Deliberate Iteration

Thu, 22 May 2014 00:00:00 +0000

I’ve never been good at New Years resolutions but this year has been different. Starting the year I decided to iterate on life in a much more deliberate way. Here are the results.

Writing

I’m starting to understand how important it is to measure iterations in order to continously improve, instead of just changing things for the sake of change. Writing things down is the best way I have found to to measure change.

I’m on my sixth notebook for the year. I write notes when I get up in the morning, when I’m in meetings, when I handle email, when I’m reading, all throughout the day really.

When I sense change I can look back at my notes and see the evolution of an idea. After testing change to see if the results are better than previous results I can identify patterns in the ideas I wrote down and repeat them or discard them.

Scheduling

A few weeks ago I started using a calendar, like for real.

(the first one is what my calendar looked like before I started using it consistently)

The results have been dramatic. My work and life balance feels better than ever, I don’t feel like I’m dropping the ball anymore, and I rarely have to spend time thinking about what to do next.

Before I only used to schedule meetings, dates I had to be at. This barely worked, I would sometimes miss meetings, or I would get anxious because I would suddenly have the feeling I had missed a meeting (even though I hadn’t).

Now every Sunday evening I schedule the upcoming week, from 8am to 5pm every day (+-1 hour). I use Calendars 5 on my iPhone and it buzzes me 10 minutes before my next scheduled thing and I use Fantastical on the desktop.

I have trained my brain to rely on the technology, by using it consistently. My error rates and anxious moments have been reduced to almost zero.

I’m getting more done at work, I’m exercising more, and I’m spending more time relaxing. What am I spending less time doing? Spinning my wheels because I’m not sure what to do next.

Meetings

A lot of people have a visceral reaction to the word “meeting”. I used to but I don’t anymore. Every day I set aside time to meet with people. These meetings range from standups to work lunches to video calls to catch up with remote coworkers.

As our company has grown I’ve come to realize how important it is to be deliberate about spending time with people and not just shipping code. Without connecting it is easy to quickly become lost.

Every week I do at least one working lunch, I spend at least one hour on a video conference with a remote coworker, and I attend at least one planning meeting (whether it’s for my team or a team we interact with).

Staying connected to coworkers has improved my mental health 10X as well as improving my value to the company by being able to connect people and ideas.

Conclusion

Figure out how you are spending your time (maybe write it down?) and then look for things to change. Try using tools and doing things you think suck (calendars and meetings oh my!). Measure the results. Do it all over again.

Other notes:

Writing things down is a lesson I have learned before and forgotten. Why is it that good habits are so much harder to practice than bad ones?
I’m writing this during my scheduled time off today :)
I’m also deliberate about meeting with people outside of my immediate circle, inside and outside of work.
I realize some people will laugh at me for just now starting to use a calendar, but I think I’ve just now grown out of my 20’s “I enjoy chaos more than order” lifestyle.

Robots can do support too

Fri, 28 Feb 2014 00:00:00 +0000

GitHub launched the Atom beta this week and the response has been great. As the first day was winding down a coworker suggested we write an FAQ and add a robot to answer the frequently asked questions in the irc channel where people were congregating. Here’s how we taught hubot to do support.

Questions and answers

First my coworker gathered the questions that were being asked over and over again:

where do I get an invite?
is there a windows or linux version of atom?
how much will Atom cost?

Next he wrote short and to the point answers:

Are you looking for an atom invite? Go to https://atom.io/ and put in your email, or join the #product-invitations room.
Are you looking for a windows or linux version of atom? We don’t have one yet, but we will in the future.
Were you inquiring in the channel about Atom’s price? We haven’t set a price yet, but expect it will be on par with the cost for similar editors.

Finally he compiled the regular expressions that we could use in hubot to listen for people’s questions and then reply to them with the answers.

/invit(es?|ation)/i
/(windows|linux)/i
/(pric(e|ing)|cost)/i

Training the robot

Meanwhile I used the Getting Started instructions to fire up a hubot instance.

Using npm I installed the hubot and coffee-script packages.

npm install -g hubot coffee-script

Next I created the hubot instance.

hubot --create atomicHubot
cd atomicHubot
git init .
git add .
git commit -m "Create atomicHubot"

Then I started hacking on the script (this is the final iteration with my work and my coworkers).

# Description:
#   Replying to people in atom channels on freenode.
#

module.exports = (robot) ->

  isNotified = (keyword, username) ->
    robot.brain.data[keyword] ?= []
    robot.brain.data[keyword].some (x) -> username == x

  replyTo = (user, msg) ->
    robot.send({user: {name: user}}, msg)

  robot.hear /invit(es?|ation)/i, (msg) ->
    username = msg.message.user.name

    unless isNotified("invite", username)
      replyTo(username, "Are you looking for an atom invite?  Go to https://atom.io/ and put in your email, or join the #product-invitations room.")
      robot.brain.data.invite.push username

  robot.hear /(windows|linux)/i, (msg) ->
    username = msg.message.user.name

    unless isNotified("winux", username)
      replyTo(username, "Are you looking for a windows or linux version of atom?  We don't have one yet, but we will in the future.")
      robot.brain.data.winux.push username

  robot.hear /(pric(e|ing)|cost)/i, (msg) ->
    username = msg.message.user.name

    unless isNotified("price", username)
      replyTo(username, "Were you inquiring in the channel about Atom's price?  We haven't set a price yet, but expect it will be on par with the cost for similar editors.")
      robot.brain.data.price.push username

Every so often I would test the script in hubot’s shell console.

bin/hubot
> where can I get an invite?
hubot> jonmagic: Are you looking for an atom invite?  Go to https://atom.io/ and put in your email, or join the ##atom-invitations room.

Next I installed the irc adapter in atomicHubot.

npm install hubot-irc --save && npm install
git add .
git commit -m "Add irc adapter"

Now I needed atomicHubot to actually live on the internet and connect to the irc channel so I read the Deploying Hubot to Heroku instructions. These required that I have the Heroku toolbelt installed.

Step 1 was creating the application on Heroku and configuring it.

heroku create atomichubot
heroku addons:add redistogo:nano
heroku config:set HEROKU_URL=http://atomichubot.herokuapp.com
heroku config:set HUBOT_IRC_NICK=atomicHubot
heroku config:set HUBOT_IRC_ROOMS=#channel-name
heroku config:set HUBOT_IRC_SERVER=irc.freenode.net
heroku config:set HUBOT_IRC_UNFLOOD=true

Step 2 was deploying to Heroku.

git push heroku master

That was it, I didn’t have to do any trouble shooting, atomicHubot connected to the irc channel and began fielding questions!

Conclusion

Adding this hubot to the irc channel helped reduce the number of questions we had to answer and increased the speed at which common questions were answered.

There are probably easier ways to setup auto reply answers in irc channels but hubot is a tool I’m familiar with and love to hack on. It only took a few minutes to setup and I’ll probably use the same technique in the future.

This may not work for everyone but hubot sure helped out in a pinch, give it a try sometime. For tips on writing hubot scripts see my post hubot Scripts Explained.

Sleep Apnea Survivor

Thu, 13 Feb 2014 00:00:00 +0000

Almost two years ago a friend and my wife saved my life. They got me to go see a doctor because my sleep was a mix of bone rattling snores, deathly silence, and gasps for air. If this sounds like someone you know, help save a life.

I should have listened to her

She wouldn’t say “I told you so” but I am certainly guilty of not following my wife’s advice several years ago to go see a doctor because I snored so loudly.

I should have had more empathy for her situation, struggling to get sleep next to a roaring locomotive. Some nights she would go sleep in another room so she could be rested enough in the morning to go to work.

Resorting to the bathtub

Then there was a night in Lansing Michigan where I shared a hotel room with three friends while attending a tech conference. In the morning I found one of them sleeping in the bathtub, another with headphones on, and the other with his head wrapped tightly in a pillow.

When they woke up they were exhausted, trying to laugh it off in order to resist the urge to kill me (something discussed during the night). They described my sleep as snores loud enough to shake both beds in the room, interspersed with moments of sweet blissful silence, followed by sucking gasps for air.

Death as a motivator

Through all of this I still hadn’t taken the time to see a doctor. I didn’t think the snoring and silence were affecting my daily life, I wasn’t tired during the day, and going to see a doctor was a pain and would cost a lot of money.

Plus I had read up on sleep apnea treatments online and the thought of wearing a mask at night sounded awful. It seemed like all my searching just turned up stories of abandoned CPAP machines.

Finally a friend and coworker told me how his father went to bed one night and never woke up the next day and sleep apnea was the likely cause. This was the motivation I needed to finally go see a doctor.

Sleep studied

In the spring of 2012 I had my first sleep study. I walked the two blocks from our home in Elkhart to the hospital, where they set me up in a small room that looked like a hotel room. Before going to bed they connected two dozen sensors to my head, chest, and legs.

About 6 hours laster I woke up to go to the bathroom and they said they had enough data and sent me home. They told me I would hear back from the doctor in about two weeks.

You are not my patient

The afternoon after the sleep study I received a call from the doctors office asking if I could come in the next day. This was a surprise but I guessed the doctors business was just running a little slow so the sooner they got me in the faster they could collect their money.

I arrived at the doctors office the next day, they took my weight, showed me into a small room, and then the nurse had me do the Epworth test and said the doctor would be in shortly.

When the doctor entered the room he looked up from my chart, concern on his face, then did a double take when he saw me. He looked as if he was about to turn and leave but asked “are you Jon Hoyt”? I answered yes and the concern on his face turned to a look of confusion, but he sat down and the appointment proceeded.

He explained that based on my study he was expecting a seriously overweight and exhausted male, someone over 300 pounds that looked like they hadn’t slept in years.

Diagnosed

This is when I learned just how close I came to death every night. The doctor explained that I stopped breathing 70 times per hour on average and my brain had to wake up just enough to kick start my breathing every time. This also meant I rarely, if ever, got the deep sleep we need to be truly rested.

The doctor prescribed a CPAP machine and another sleep study to get the machine configured to the right settings to help me overcome my severe sleep apnea.

10X your life

Within a week of getting the CPAP my life and my wife’s were completely changed. She was no longer fighting with the locomotive next to her and I was getting the deepest and most restful sleep I’d had in a decade.

I went from 8-10 hours of sleep per night (I sleep without an alarm clock) to 6-8 hours of sleep per night and felt more rested and smarter. Yup, I felt smarter. I could reason out harder problems while programming, I could retain more information throughout the day, and I could communicate more easily at work.

Almost two years later I can’t imagine life without my CPAP. So cheers to life, to sleep!

New Team and Lessons Learned

Mon, 16 Sep 2013 00:00:00 +0000

The past few months I have been building a new team at GitHub focused on solving problems for our business teams. Here are a few valuable lessons we learned along the way.

Solving the right problem

We solve problems for a living and we have one major constraint, our time. This means we need to be thoughtful in choosing which problems to solve. We cannot solve them all.

We decided to solve employee expenses at GitHub by building our own expensing system. We had evaluated 3rd party services and while they did 90% of what we needed, that last 10% made it seem like it was worth doing on our own.

What we failed to account for were the other opportunities, the other problems that needed solved, that ultimately would have a more lasting impact on GitHub.

If we use our company vision, to help people build software better together, as a framework for deciding what to work on, choosing the right problem to solve becomes much easier.

We should be sensitive to opportunity costs. Solve the problem that will have the greatest impact with the lowest cost.

Failing fast

After choosing the wrong problem to solve we did not set clear goals so that we knew what success or failure meant. As a result it took us four months to realize we were working on the wrong thing.

Our first goal was to ship a system that received receipts, connected them to transactions, provided automatic and manual classification, and then entered the data into our accounting system.

The more I learn about software development, or solving any problem really, the more I realize a winning percentage requires breaking down problems (and their solutions) into smaller and smaller pieces. Shipping quickly and constant iteration mean faster course corrections and less costly failures.

The fact that we could not easily break the expensing problem down into smaller pieces should have been a red flag.

We can reduce the costs of failure, both emotionally and economically, if we fail fast. We can’t fail fast unless we ship quickly and iterate.

Do the simplest thing first

We also started building a platform for different teams (and apps) at GitHub to be able to easily invoice customers. We dreamt up the perfect platform for invoicing, without having tried the simplest thing first.

The lie we often believe is that we understand what our constraints will be in a week, or a month, or six months and therefore we can save time by optimizing early. The truth is that we cannot foresee the future.

In the end we learned that invoicing integration needed to be built inside of the products it serves first. After it has been proven it can possibly be extracted into a shared service. This sounds like more work in the long run, but ultimately this process can adapt to change more quickly and easily.

One more thing

We could have avoided a lot of heartache and wasted resources if I had sought mentorship from people with more experience and context at GitHub.

For long term success I need to constantly be learning, which means keeping an open mind and a humble spirit. I look forward to the journey \m/

Business With Pleasure

Wed, 15 May 2013 00:00:00 +0000

Hi, my name is Jon. I’m an addict. It does not matter what it is if it makes me feel good I do more of it.

But I Love It So Much!

I love my job, or more specifically, I love the work I get to do every day. Combine my love for work with my addiction problem and I end up working too much and spending too little time with my wife, or reading a book, or taking a walk.

When things are going well at work I have a sense of accomplishment, which feels good, and I want more. How do you get more of something? You just keep doing the same thing over and over again that got you that good feeling right?

Being Honest With Myself

Right now I have no problem identifying that my line of thinking, doing more of something will result in more pleasure, is wrong. When I am in a destructive cycle I am completely blind to this fact.

A destructive cycle is wanting one thing too much and being blind to the costs of achieving it. We also call this being obsessed with something. Ultimately these destructive cycles lead to some sort of meltdown for me when increased input does not lead to an equal or greater increase in output.

During a cycle I can’t stop thinking about whatever I’m obsessing about; I bring it to the dinner table, I bring it on a date, I go to bed with it. This damages my marriage and my mental health.

Thankfully I am getting better at recognizing and breaking these cycles. I can’t take the credit though, my wife usually notices and starts to warn me early on. Learning to listen to her concerns is something I need to get better at. My last obsession lasted about ten days before she got through to me and I recognized the error of my ways. That was yesterday.

Shortening the Cycle

There are a few things I am going to try to shorten this cycle. The first is obvious, listen to my wife. But what if you don’t live with someone?

Recognize the signs. If I am spending less time doing things that relax me, like reading, walking with my dogs, or doing chores around the house, these are pretty good signs I’m not balancing work and life very well.

I’m trying out a checklist of sorts. It is just a long list of non-work things that I can do each day. I made this list by observing what has been healthy for me in the past. I’m not going to check off everything on the list each day, but doing three or four a day is a good sign, and doing one or none is probably a bad sign.

Make yourself accountable to your peers. If you know your signs ask a coworker and friend to watch out for them. Most of the time someone other than yourself will recognize the signs much sooner than you will. There is a caveat, if you are going to make yourself accountable you have to be willing to listen when they warn you.

Getting it right feels great too. Excuse me while I add blogging to my list of non-work things to do.