Learning (and teaching) how to be a good programmer

Alexandre Borrego
May 10, 2019 · 7 min read
Image for post
Image for post
Coaching at Blue Harvest

I recently finished coaching a handful of engineers on Node.js development as part of Blue Harvest’s 6-week-long coaching program. I’m by no means an expert on the subject of coaching, teaching, training or whatever you want to call it (I’ll use those terms somewhat interchangeably throughout this article), but that last experience prompted me to share a thought or two about it.

Whatever the context (be it at Blue Harvest, Hack Your Future where I used to give Sunday lessons, or at work, where I spend as much time as possible mentoring juniors), I noticed one thing: teaching and learning programming (or a programming language in particular) is a lengthy process but a relatively simple one. There’s only one rule, the same that applies to learning natural languages: practice.

Teaching and learning how to become a good programmer, however, is a much trickier task.

What I mean by “good programmer”

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Robert C. Martin has been honing the same idea throughout his books and talks about clean code: being a professional software engineer isn’t so much about managing complexity at the machine level (i.e. merely getting code to work) as it is about dealing with it at a human level (i.e. writing maintainable and predictable code that is easy to reason about).

A lot of theory has already been written about what this all means (if you didn’t get the hint, read Fowler and Uncle Bob’s stuff), but to master it, to put it into practice, merely following an enumerable set of guidelines and principles just won’t do. This is where teaching comes in.

What teaching code is about and why we need it

Knowing what you don’t know

As a mentor, I believe that my role in this area should be mostly that of a curator or a guardrail: I’ll orient my students or mentees to the resources (books, articles, tutorials, etc.) and concepts they need to get started or unstuck. I’ll help them not to waste time and to stay on track, providing them with an outline of what they don’t know. But it’s crucial that they do the heavy lifting, come to solutions on their own and enjoy those very important, very personal aha moments.

This has the added benefit of letting me focus on what’s key and what written and video materials are not so suited for: instilling the right mindset.

“You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.”

— Robert C. Martin

Of course, the heuristics — the plethora of acronymic paradigms (OOP, DDD, TDD, BDD, AOP, etc.), design patterns, principles and language-specific best practices — pave the way. But the core of it all lies in more fundamental mental constructs that require a discursive approach to be fostered.

“Whatever is well conceived is clearly said”

Passing on that mental discipline requires more questions than answers on the part of the teacher, in a Socratic kind of way. While the challenge of learning heuristics lies with digesting a large pool of information, acquiring a certain mindset can only come from challenging one’s perspective and approach to problems.

When I see a mentee struggling with an issue or coming up with hard-to-read code (which is quite often the same thing), I’ll start by pulling the thread of their reasoning, asking them to describe, step-by-step, what they’re trying to achieve. The goal is for them to lay out, either mentally or on paper, the constitutive parts of both the problem and the solution in the most straightforward way possible.

Getting to a clean representation of the task at hand is usually not too difficult if you focus on building a solution composed of very simple, very dumb components — which will ultimately result in very simple classes, functions, loops. Doing this through discussions makes that process even easier, as the constraints of verbal communication will tend to ensure a certain degree of simplification.

This is unfortunately too often overlooked, especially by junior developers who “just want to make it work” and “clean it up afterwards”. If I can convince you of only one thing though, please let it be this: refrain from writing code until you’ve built a clear and simple picture of its overall structure. Not only will you solve problems faster and faster as this habit grows, but other developers will understand your solutions with less and less effort.

These discussions with my mentees and students also help me to improve my coding skills and clarify my own outlook on programming. This famous quote from Richard Feynman comes to mind: “if you can’t explain something in simple terms, you don’t understand it”. I don’t know whether teaching code made me a “good” programmer, but it certainly makes me a much better one. And I can only recommend trying to explain or simply discuss the stuff you learn and know to someone else as often as you can, even if you only just started programming.

In practice

At Blue Harvest, we tried to achieve this flexibility by coming up with a set of guidelines rather than a strict plan for our coaching program. Something flexible enough to let us quickly explore new avenues and tailor the format of our coaching sessions to the engineers who would join them. And — maybe more importantly: something centered around actual practice and real-world engineering problems.

Learn and teach by doing

To tackle that, we built our coaching program around a real world project. Instead of coming up with our own, we chose the realworld.io example application. It has enough moving parts to offer a healthy variety of problems and raise some fundamental and generic questions, yet the requirements and features are very straightforward and can fade into the background.

The goal was really not to deliver a functioning app, but rather to have a pretext for practice, code reviews, pair programming and informal chats about translating abstract principles into lines of code in a very tangible way.

Save time with good educational materials

The group didn’t need an actual presentation of the syntax, as all of them had experience with another language and at least once tried their hand at JavaScript. But if you do need a formal language introduction, cheat-sheets and videos like those of Derek Banas’ Learn in One Video series should be enough to get started with your first program. Keep them at hand and start hacking. Proficiency will come later.

As far as libraries and frameworks go, we’d briefly introduce them by giving an overview of their philosophy and then refer to their documentation, without going into detailed expositions of their idiomatic usage. Learning new libraries, frameworks and APIs on-the-fly is an essential part of the job. So if lack of guidance in that area becomes a problem, it makes more sense to teach how to effectively parse docs in general than painstakingly walking students through this or that specific library.

Lessons and discussions

Some other areas — like functional programming, git best practices, unit-, integration- and functional testing, etc. — were also on the menu, but we decided to scrap them as the participants asked for other specific topics to be discussed and especially enjoyed the time spent coding (so we made sure they had plenty of that).

Learning to be a good programmer is not something that you can just achieve and be done with. It’s also not something that you can do alone. I hope I’ve managed to convince you that mere technical knowledge is only part of the story and that I’ve inspired you to seek out — and become — mentors.

Blue Harvest Tech Blog

Learn more about software development from the best Blue…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store