Unexpected Learning

Posted by Darin Pantley on August 27, 2017

I’ve learned many unexpected lessons by working with others. For example, I occasionally talk to my boss about Python code. In those conversations I expect to learn something new about Python. However, I sometimes leave those conversations with an unexpected new skill, like the ability to track pending work items or or a deeper understanding of Kubernetes. I look forward to discovering the hidden lessons that working with new people can bring.

Several classmates, coworkers, and friends have helped me learn these sorts of lessons. The following names are bogus but the situations are real. In each situation I walked away better informed in ways I hadn’t anticipated.

1. Levi Appleton

You get what you build, not what you wish you built.

I had a hazy relationship with artificial intelligence, but that didn’t stop me from attempting to build a chat bot with my friend Levi. I hoped that we could do some cool one-shot learning, so we set out to build the thing. Levi helped me with the math and we cobbled together an n-gram slurping markov monstrosity. It ultimately featured zero code to perform one-shot learning, but it did feature some minimal artificial intelligence.

I did my best to stomp out our biggest bugs before demo day. Levi warned me that even if our code performed flawlessly, it wasn’t going to be very impressive without a significant amount of training data.

Demo day arrived and some unimpressed kids tried to talk to our chat bot. Their parents said they remembered ELIZA being significantly more advanced back in the day.

Now I understand the importance of training data, the difficulty of minimizing the need for training data, and the importance of being very explicit about the purpose of a project. I hadn’t expected my time with Levi to be so educational, but sometimes it’s easy to learn new things when you’re starting from a position of ignorance.

2. Mikael Alduino

It’s important for others to know what you don’t know.

I was once assigned the task of creating white-box unit tests for a large code base. My manager Mikael had heard good things about me, so he let me work on it for a couple months with minimal supervision. Once I had gotten some things to work, I scheduled a meeting with him and confidently presented what I had.

He stopped me. He did his best to explain to me how useless my code was, because it was based on incorrect assumptions about how the Linux kernel works. At that moment he learned that his assumptions about my competency were wrong. I was missing essential knowledge needed to do my job. I learned that knowing what you don’t know matters a lot, but helping others know what you don’t know matters too. To this day, I have never heard anyone sound so disappointed as Mikael did at that moment.

3. Eliseo Adriaans

Learning how to gain new knowledge is more important than having knowledge.

I had the good fortune of working with Eliseo for several years. He taught me the importance of applying the scientific method to programming. If you want to figure out why something is broken, theorize what might be the cause, change one relevant input, and then test your hypothesis. Measure everything. Back up opinions with data. Present ideas clearly.

Eliseo knows that I took the large stockpile of knowledge sitting in his head and copied as much as I could into my own head. It’s less obvious to him, but arguably more important for me, that this process taught me how to create my own stockpile of knowledge when needed.

4. Clayton Higgins

Why do the work if the computer will do it for you?

Clayton tried to teach me about Q-learning, but it was his use of Eclipse that stuck with me longer. He would type a function name, add some parentheses, and feed it some arguments. The function didn’t exist, but that didn’t matter to Clayton. With a few clicks of the mouse the function did exist. Visual indicators of errors popped up all over the place, but he quickly clicked on each one and let the IDE auto-resolve his code into existence. The amount of boilerplate code written by the IDE exceeded the amount of code that he had written manually for the initial prototype.

I was a little horrified and a little impressed. Today, I re-use that lesson in other contexts. For example, why should I have to point out syntax errors in code reviews? I can offload that job to an automatic linter.

5. Farrell Hope

The first step to replacing the status quo is defining a new vision.

Every manager I’ve worked under has had a different style. Farrell exceeded at managing “up”. He was very skilled at shielding our team from the chaos above us, where people in upper management debated which projects to pursue, leaving us to work in peace on well defined goals.

I appreciated Farrell’s ability to instill a vision in the team. During a time when our company was facing issues with SVN merge-info metadata and a lack of automated tests, he encouraged us to use Git and set up a continuous integration system. He wasn’t in a very powerful position, but his actions easily impacted the entire company.

Even though Farrell had minimum involvement with the implementation of these ideas, it was his vision for the team that gave us something to shoot for.

6. Fernão Rooiakker

Do not over-engineer.

We were a team of four working together and Fernão was our fearless leader. Our initial prototype worked, which was awesome, but it was also very limited because it only supported the ability to process four inputs at a time. We discussed the need to support more inputs and I spent a day or two writing complex memory management code in C to dynamically support any number of inputs. Meanwhile, Fernão replaced inputs[4] with inputs[20] in the source code. My code worked fine, but it wasn’t needed. Supporting 20 inputs turned out to be sufficient.

His solution was vastly simpler than my solution. On one hand I wasted several hours writing code, but on the other hand I learned a valuable lesson: do not over-engineer.