Reflections on building software for, and with, people.

Retro Roulette

Frequent reflection on how we can do better work in better ways is one of my favorite things about my team’s culture. For a long time, this took the form of monthly “retro” meetings where we all get in a room for an hour and talk about what’s been fun or frustrating, and how we can do more of the former and less of the latter. However, as my team grew to around 10 people, we noticed a creeping resistance to speaking up which led to conversation feeling more artificial. This only got worse as we grew past 20, when we finally put the meeting out of its misery. I really missed these opportunities for reflection, and want to share a new approach we’ve been trying to encourage this kind of reflection on larger teams, with which we’ve seen promising results. I call it Retro Roulette.

Continue reading...

The Many Motivations of a Programmer

A conversation with a friend yesterday prompted me to reflect on all the different ways I’ve felt motivated in my career, how motivations have come and gone, and how often they’ve changed not just between but within jobs.

Continue reading...

The Misunderstood Art of Delegation

One of the most-misunderstood skills of a manager is delegation. Before becoming a manager myself, I had the common impression that delegation is when your boss gets you to do their job so they can go take 2-hour lunches. It turns out that’s only half true: delegation is about your manager getting you to do some of their job. But I’ve come to see how delegation is so much more than that: it’s the engine of individual and collective growth within an organization.

Continue reading...

Reflections on My First Few Months as a Manager

A few months ago I accepted a new role at Lessonly: splitting my time between building software and managing 5 of my colleagues. It’s been one of the most challenging experiences of my career so far, but at times pretty rewarding. At some point in your career as a developer, you’re likely to be given the same choice, so I want to share what it was like for me in the first few months before the curse of knowledge sets in.

Continue reading...

My Favorite Quiet Places to Work in Indianapolis

After reading Deep Work, a compelling case for the power and necessity of focus toward doing our best work, I began to realize just how distracting the modern office—especially the open-plan ones—can be. So I decided to experiment with working from somewhere else. I began searching for quiet, public spaces in the city and was surprised and delighted to discover these gems.

Continue reading...

Tips for Naming

Naming things is famously one of the two hard things in computer science. The humor in this adage derives from the fact that naming seems like it should be easy. And yet, most of us can relate to the importance and difficulty in coming up with good names for objects and concepts in our code.

Continue reading...

Using Ecto Schemas with Database Views

Database views are a great way to provide a simplified abstraction over complicated data logic. They provide a way to treat a complex query as if it were a simple table, and with no extra work, you can build Ecto schemas on top of database views to bring the power of that abstraction into your Elixir code!

Continue reading...

Elixir In Action

I just finished Saša Jurić’s excellent Elixir in Action published by Manning. I’ve been learning Elixir for about six months now, having learned the basic concepts and syntax from Dave Thomas’s Programming Elixir, which is a great introduction to writing Elixir. But I still lacked an understanding of how to build with Elixir, specifically how to create, structure, and deploy OTP applications, set up supervision trees, and leverage the power of concurrency and distribution. That’s where Elixir in Action was the ideal next step.

Continue reading...

Optimize for Deletion

I just watched Greg Young’s talk The Art of Destroying Software. It’s a compelling, unconventional argument for changing the way we write code to maximize our ability to delete it. Young’s rule of thumb is 1 week: don’t write any self-contained part of your system that would take more than a week for someone unfamiliar with it to rewrite from scratch.

Continue reading...