We all have an extra gear. Our day-to-day existence requires just a fraction of our full mental and physical focus. This makes evolutionary sense - most of our time is spent dealing with the same problems we dealt with the day before. If there’s no environmental change, then there’s no reason to spend finite willpower to change our behavior.

Put yourself in a situation where 120% of your focus is needed to survive.

I remember two times in my life where, under both extraordinary external and internal stress, I had to break the glass.

The first time was when I first got to college. I coasted through high school on the belief that I was smart enough to not have to work hard. I failed algebra. Acing your exams isn’t enough when homework is worth half your grade.

I didn’t get into the university of my dreams. That hurt. I remember asking an orientation leader at the college I ended up...

Last year I made a list of goals I wanted to complete by the end of the year, which I got about a 50% success rate on. This year I want to do things a bit differently. First because I’m late to making my resolutions, but mostly because I want to take a longer view on my growth.

One year is a very short amount of time in the grand scheme of learning new skills on a deeper level. I’m not a polymath, I can’t learn to be an expert on something in just a month, or even a year. I don’t have the dedication, the time, or the natural ability.

As in wealth management, there’s an entire industry dedicated to telling you that you can be X in Y time, where X grows ever larger in scale while Y shrinks to smaller and smaller timeframes. It takes real mental effort not to listen to that crap, especially when X is something you really want and Y is something you don’t have enough of.

In defiance of...

It’s in the books! A little bit over a year ago I started this blog with a post about my goals for 2017. Let’s see where I ended up on those:

• Read 6 books - I read 4 and am working, slowly, on the 5th, more on this in a later post
• Complete 3 online courses - I completed 1, of all my goals I’m most disappointed in not having finished this one
• Run 24 miles - I didn’t run 24 miles in open air, but did enough cardio to be well past this
• Travel to a foreign country - I did this twice over by travelling to India and Canada, I’m proud of myself for finishing this
• Publish a mobile app - I didn’t publish a mobile app but I did conceive and superficially start one

Taken altogether, I’ve got about a 50% success rate on my goals for 2017. This is actually surprising since I haven’t looked at this list since I first wrote it, even though I told myself that I would be tracking my progress during...

No language is perfect. Every language has warts that can’t be designed away. Recently I’ve been noticing this pattern show up a lot:

thing, err := methodCouldErr()
if err != nil {
    return err
}

useThing(thing)

Error propagation in golang is done by returning error objects through the call stack until it’s ultimately consumed by some terminal caller. Done enough times – and I’ve seen entire functions comprised of successive uses of this idiom – this uses a lot of vertical real estate without adding much information. One way to avoid the vertical pollution is by combining the method call with the conditional:

if _, err := methodCouldErr(); err != nil {
    return err
}

This has an obvious drawback. A variable assigned inside the conditional can’t be used unless declared previously:

var thing Thing
var err error
if thing, err = methodCouldErr(); err != nil {
    return err
}

My first experience with git was when I was an intern at my first job. I knew very little about programming. I knew even less about git.

The extent of my knowledge on version control software was the time I had to use TortoiseSVN to download source code for a robotics project back in college. I never “committed” anything, whatever that meant. To me, version control software was just a fancier way to download stuff to my computer.

With that background on VCS, during my internship, I committed a week’s worth of code with the message “Update some stuff”. Someone who wasn’t even my manager rejected it and said, simply, “no omnibus commits”.

Since that point I made a concerted effort to practice good git hygiene. This involves knowing why git, or any kind of version control, is useful.

Version control is critical for understanding how a project evolves over time.

Likewise, it enables the...

Learning a new programming language is painful sometimes. I remember when I was learning Python, and I would run into language quirks all the time. It was only after suffering through a few embarrassing pull requests that I finally grokked the dang thing.

The same thing is happening to me in Go. Let’s say you have two structs that have the same field:

type A struct {
    C string
}

type B struct {
    C string
}

and then you have a list of interfaces that include two of these:

interfaces := []interface{}{A{"hello"}, B{"world"}}

In this reduced example, all I wanted to do was access C from both of these. It seemed natural to use a type switch:

for _, value := range interfaces {
    switch c := value.(type) {
    case A, B:
        fmt.Println(c.C)
    }
}

Uh oh. Go complains that c is still an interface, and as a result has no field C. That’s really strange, because this...

Young Pat walked up excitedly to Master Dsa.

“I’ve fashioned a factory to make shoes! Now I don’t need to make shoes by hand any more!”

Master Dsa was curious.

“How did you make that factory?”

“By hand.”

Master Dsa looked at Young Pat’s feet.

“How many feet do you have?”

Young Pat looked down, and was enlightened.

Blink is an interesting and short read.

Structurally, the book is an example of its own thesis - reading any random subset of it is enough to discern the central insight. From the very beginning, Gladwell uses examples of “thin-slicing” to show that our intuitive machinery is powerful enough to make reasonably accurate judgments even with very little data. Some of the examples really are incredible, as in, if I didn’t trust that there’s data to back them up I probably wouldn’t believe them.

The most compelling example to me personally is the one of basketball players and “court vision”. I watch a lot of (read: too much) basketball. Some of the decisions professionals have to make cannot possibly be made in the rational mode of thought, the game moves too fast. Steph Curry practices with sensory distraction tools, and yet his body gives him enough information to make split second...

I just finished my first week at my new job. I took the opportunity to learn a new technology that I’ll hopefully have fully integrated into my toolbox soon.

I’ve realized over the years that if I really want to learn and internalize something like a tool, I have to start at the very beginning. It takes a lot of discipline but I think the end result will be worth the effort.

That means not changing defaults, customizing shortcuts, or anything like that. I’m forcing myself to use vanilla tmux until I can open, detach, and reattach sessions with my eyes closed. To keep the scope of what I have to learn as small as possible, this is all I’ll be using tmux for, for at least the first few months.

As a reminder to myself, these are the commands I have to make second nature:

tmux new -s [name]            create a new session
tmux det                      detach from session
tmux ls