My Natural Language

I gave a talk recently to Kyle Coberly’s Full Stack class at Galvanize. The talk was completely open-ended — “come tell my class about yourself or your experience in the software development world,” is the only guidance I was given.

Turns out talking about yourself to a class of new developers is rewarding for both of you. For me, it brought reflection on my own path as a developer, a topic I had never spent much time considering. I’ve worked on a wide variety of things in my [relatively] short career, and I’ve been fortunate to have bosses that have fostered and encouraged that behavior. Although it may scare other developers to think about a firmware engineer writing full stack Javascript applications (frankly, it scares me), it’s a description I rather enjoy.

As I mentally walked through my developer life, I thought about my progression through technologies and languages — low-level C/Assembly Firmware, C++ for enterprise server-based computing, C# as a user-facing client, Atlassian plugins in Java, first Backbone.js, then Ember.js web applications. My colleagues will note one glaring exception from that list: Python.

Python doesn’t fit into the progression, because it’s been woven throughout each of my jobs and projects in some form or another. One-off Scripts, headless worker tasks, distributed continuous integration, PyQt GUIs, CherryPy and Django apps, there’s been a little of almost everything. It’s the language I use when I think about problems.

What a powerful concept! Every developer has a “natural language.” Many developers are fluent in multiple languages, but I would guess that most have one (or maybe two) that are their favorites. What makes the concept powerful is that knowing a developer’s natural language can change the way you engage him/her. It’s a form of “putting yourself in their shoes” that enables you to consider how they would think about and [hopefully] solve a given problem. In a lead or product owner role, you can gauge where they are in their discovery and offer timely advice or guidance. As a collaborator, you can predict and alleviate pain points both in discovery and in development.

Recognizing your own natural language also has broad reaching benefits. It gives perspective on your strengths and weaknesses. It can expose your solution biases. By itself, it won’t make you a better developer, but it’s a key tool in recognizing where you can make improvements. For me, it’s a seemingly simple observation that I’ll carry with me long after giving my talk at Galvanize.

So what’s your natural language?