Recently, my wife and I dropped our son off as a new freshman in college. It
was as bittersweet as everyone says and we both wish we could be a fly on the
wall through his experience. He has so much to learn in the next four years as
he fully blossoms into an independent adult. We couldn’t be more proud of him.
College is a time of great discovery and learning. But, in the years since I
was in those same shoes, I now come to realize that some of my most profound
learning was done after I left the university life. I now know that experience
paired with theory is far superior to theory alone. I grew to understand that
my mother’s advice to be responsible was insufficient, since I needed to rely
on and work with others to accomplish anything of value. And no matter how much
I loved it, I had to give up on the idea that “Walk the Dinosaur” by Was (Not
Was) represented the height of cultural enlightenment. That spot is reserved
for “Thunder Road” and I’ll entertain no arguments to the contrary.
I’ve had many roles in the course of my career. I’ve been a software developer,
worked in QA, and I did a stint in operations. I’ve been an individual
contributor and managed teams of up to 85 people. I worked at some of the
largest companies in the world and tried my hand at co-founding a startup for a
few years. Through it all, I’ve had the pleasure of working with some
extraordinary people at various stages in their career.
There is no single path to developing as an engineer. Even the very idea of
what it means to be a senior engineer is not universally agreed to, though
John Allspaw’s post from several years ago is
right in pointing out that much of what makes one senior has less to do with
technical skill than in how you behave with others. With that in mind, here are
seven practical things anyone can do to become a better engineer:
Read as much code as you can. It’s very easy to get so wrapped up in what
we have to do for our day jobs and forget to broaden our perspective.
Reading code written by other people is hugely beneficial to see how others
solve problems. Just as authors improve by reading books by other authors,
so too do engineers advance by studying the source code of other developers.
Pull down open source projects that interest you and see if you can figure
out how they work. Find some part of the system you’re normally not working
in and tease it apart until you know it as well as the code you write
Expose yourself to new languages and frameworks. Every technology stack
brings its own set of constructs and idioms. Learning their features will
change how you think. Some languages have lambdas and closures and some
don’t. Coffeescript has comprehensions. Learning Clojure will help you to
learn programming in a functional style. Studying the Ember guides
will help you to better understand how an opinionated framework can bring
predictability to a large team. And an understanding of Elixir or Erlang
will inform your view of how to build scalable systems. When you learn new
languages and frameworks, you learn new ways to solve problems.
Watch great presenters. Find everything you can by Jim Weirich, Sandy
Metz, or Rich Hickey and watch it. Their talks aren’t about how to solve a
specific problem. They’re also not surveys of what’s new or interesting in
some technology. Their talks are about the craft of software itself. What
constitutes great software design? What is the best way to build and
refactor code to make it easier to maintain and evolve? What practices are
applicable in most any situation? I’ve seen dozens of presentations from
them – mostly online. I’d wager that watching these presentations taught me
more about software development than all of my time as an undergrad
Practice. Whether it’s on a personal project or by doing stand alone
exercises (the Gilded Rose kata
is a great example), practicing your craft is critical to improving.
Learn to recognize and account for your biases. All of us are fallible. We
suffer from cognitive, prejudicial, and other biases
that cloud our judgment, reduce our effectiveness, and cause us to
unintentionally hurt others. Our industry’s embarrassing diversity problem
is in large measure perpetuated by these kinds of failings. While there is
no cure for the human condition that makes us vulnerable to these mistakes,
we can learn to better see them in ourselves and take corrective action.
Get involved with the community. Talking to other developers helps stir
your interests and exposes you to new ideas. So, go to a user group or a
hack night and find like-minded individuals. Attend a conference of
something outside your comfort zone. Volunteer to teach and mentor those who
come after you.
Talk to users. Too many developers settle for advancing their technical
skill. But, we should never forget that building software is rarely the
point of what we do. We are here to solve problems for people. Talk to them
to ensure you know what their problem is, how they’re solving it today, and
how what you build will make their lives better. Building great software is
only valuable if we’re building the right thing in the first place.
We talked to our son about his early college experience on the phone last
evening. We loved hearing about the books he’s reading, the professors he’s
learning from, and the new friends he’s met. We’re relieved that he’s not only
found a quiet place to study but that he’s also joined a student organization
that’s a perfect match for his major. His field of study is not software
development; it’s political science. But, as I reviewed the set of practices
I’ve seen fellow engineers use as they developed, I realized they’re actually
universal. Becoming a great engineer is about much more than proficiency with
the most recent developments. Becoming the better version of ourselves requires
growth in both the personal and the practical if we are to make the kind of
impact we are capable of.