Programmers often mistake a working program for an effective one. Their code could be a nightmare to read and debug. It could take forever to run. It could be filled with poorly named variables. No matter. As long as their code works — that is, it yields the correct result — then they’re happy and move on.

This is the wrong attitude to have.

Getting the program to work is only one part of writing an effective solution. Other factors include: clarity, meaning, and performance. So instead of focusing exclusively on correctness, we need to also focus on effectiveness.

A…

The hosts of the Crafting Code podcast raise an interesting question on an episode about deleting code: is code an asset or a liability?

It’s a good question to consider, since most of us think we make something better — from a recipe to a piece of art — by adding to it, rather than subtracting from it.

Additions have a cost, as the trio of hosts on this episode point out. “[Software] gets more and more complex as you add things to it,” they explain.

They’ve got a point.

Say you added a bunch of conditionals to address all…

I was like a fish out of water without my laptop by my side.

I needed a new computer battery, so I left my MacBook at the Apple store. I was hoping that they’d simply swap out the old battery with a new one on the spot.

That was wishful thinking. “Your computer should be ready within three days,” I was told. I’m sure my eyes bulged open and my face turned white when I heard that response.

How does a programmer program without a computer for three days?!

The answer: by hand. So that’s what I did.

I settled…

You’ve probably heard of deliberate practice: an intentional and informed type of practice that’s used to enhance performance.[1] It means entering your practice with purpose, rather than mindlessly going through the motions. Setting specific goals, receiving feedback, and getting outside of your comfort zone are some of the core parts of deliberate practice.

The popularity around deliberate practice is rightly earned: research across a variety of fields has shown its effectiveness.[1]

But something is missing from the deliberate practice conversation: how can you apply deliberate practice to programming?

I answer this question in this blog post. I offer three ways…

Programming is a fantastic skill to develop. But, as a self-taught programmer, I’ve found the learning process unnecessarily ambiguous and complex. I’ve spent a lot of time figuring out what to learn (and when to learn it), which resources to use, and how to learn a vast number of technical topics.

So I’ve put together five lessons I’ve learned (so far) from my own journey. I hope the ideas and resources in each lesson will set you up for a more direct route for learning and getting better at programming.

1. Learn the fundamentals of programming.

One piece of advice shaped my entire learning trajectory as…

Something about Julia Child caught my attention. This American author, teacher, and television personality is famous for bringing French cooking to America. Indeed, mastering the French cuisine and having such a remarkable cooking career is impressive.

But what’s equally impressive is that Child found her “life’s calling” — French cooking — when she enrolled as a student at the Le Cordon Bleu school of cooking at age 37. In other words, Child wasn’t a French cooking child prodigy. Rather, she learned the art and craft of French cooking later in life. …

There’s so much new and dense technical information coming at you when you begin learning to program. How do you learn and retain it all?

That’s a question I’ve asked myself many times on my own programming journey. In an attempt to find an answer, I’ve experimented with many learning tactics along the way. However one stands out among the rest. I call it the apply first, study second approach.

If you’re looking for an efficient and effective way to learn to program, I suggest you give it a try.

Learning in Action

Apply first, study second means attempt the problem first. The…

It’s sometimes thought that short, “clever” code is the aim when writing programs. However, shorter isn’t necessarily better. Neither is “clever” code. You know, code that reads like a cryptic puzzle, which causes you to spend an unnecessary amount of time trying to figure out.

We shouldn’t aim for short, terse code. We shouldn’t intentionally make code complex or confusing. Instead, the best type of writing, be it prose or code, is clear and meaningful. This should be our aim.

That’s because it’s the easiest for the reader to understand. “Clarity is not the same as brevity,” writes Brian Kernighan…