Jason in a Nutshell

Exceptional programmers

One thing that seems to be a perennial favorite on Hacker News is discussion of the characteristics of a good programmer. Inevitably, people disagree on this subject. I think this is a difficult question to answer not because it's difficult to recognize good programmers, but because it's the wrong question.

Human talent cannot be reduced to a simple boolean proposition. People have different talents in different areas. People often have problems recognizing good programmers because they try to fit people into a box. They try to say that good programmers have characteristics x, y, and z, but that characteristics a, b, and c are never qualities of good programmers.

It turns out that for every good programmer you do recognize, there are probably several other people you wouldn't have guessed in a million years would be any good. So here's my attempt to help people understand good programmers better. Oftentimes, good programmers will fall under more than one or even all of these categories. But usually, they're most talented in one area.

I should also point out that I'm probably just scratching the surface here. There are probably more types of good programmer than this.

The machine

The machine is probably the first person you think of when the words "good programmer" hit your ear. The machine is someone who has the job you asked for finished yesterday. Sometimes the most challenging task is simply finding things for them to do.

Machines are the easiest to recognize simply because their talent is more measurable: they get their tasks done way ahead of schedule. However, they're not without their tragic flaws. Although machines are good at writing code, they rarely see code as anything but a means to an end. Left unchecked, machines can turn your code into a steaming pile of crap. Fortunately, that's where the other types of good programmers come in.

The method man (or woman)

The method man is the one who brings discipline to the team. Their greatest strength is attention to detail. Usually, they're the ones to poke holes in the architects' brilliant ideas or to get the machine to slow down, take a breath, and think before coding.

It's a bit more difficult to recognize a method man than it is a machine. The key thing to watch for is process. They're the ones who describe everything they do in excruciating detail. This is also their Achilles heel. They're good at applying rules and processes, but they freeze the instant they are faced with a situation that falls outside them.

The architect

The architect is the crazy guy (or gal) who rambles on and on about design patterns. Get him involved in a conversation and he'll be delighted to tell you his latest theory about whatever random thing he's thinking about at the time. While their ideas may come off as crazy, there is almost always a method to their madness.

They're the people who make sure machines don't have to care about their code. They're also the ones to offer guidance to the method men when the rules don't apply. They're the ones who look out for the big picture while everyone else is distracted by details.

The hallmark of the architect is inconsistency. They're the ones you come to when you have a really difficult problem. But assign them the most mundane task and a two-hour project just turned into a two-day project. Ask them to explain Goedel's Incompleteness theorem, and you'll get the most brilliant description you've ever heard. Ask them what a database is and you'll probably get the most obtuse and technically dense answer you've ever heard.

So what other types of brilliant programmers have you come across?

Persistence is a subset of immutability

Whenever I tell someone I'm working on a persistent data structure
library for Python, I almost always get the same response:
"Persistent means that something is stored across process boundaries.
I think you mean to say immutable data structures." In fairness, this
response is understandable. But it's not quite right. I'm going to
address both of the points in the above statement.

Persistent means that something is stored across process boundaries

Did you know that letter can mean a note you send through the mail or a thing you use to make up words? Did you know that programming can mean writing computer programs or mathematical optimization? I'm sure if I sat down long enough, I could think of more examples. The point is that the language we speak is full of ambiguities and whatnot.

Before we consider the computer science meaning of persistence, let's
look at the common meaning. If we look at the word persistent in
Merriam-Webster, the first two definitions we run into are:

1 : existing for a long or longer than usual time or continuously: as
a : retained beyond the usual period b : continuing without change in
function or structure

The meaning Python programmers tend to think of is the definition in
part a. That is, a persistent data structure is stored beyond the
usual period (the process's lifespan). However, when I talk about a
persistent data structure, I tend to mean the definition in part b.

Going with definition b, we can see that lists for example aren't persistent:

 
>>> a = [1,2,3] 
>>> b = a 
>>> b.append(4) 
>>> a 
[1, 2, 3, 4]

Tuples, however, are a different matter:

 
>>> a = (1,2,3) 
>>> b = a + (4,) 
>>> b 
(1, 2, 3, 4) 
>>> a 
(1, 2, 3)

Ah, but here's where the second part of this post comes in.

I think you mean to say immutable data structures

In the case of the tuple, you are correct to say that a tuple is
immutable. And I'm correct in saying that a tuple is persistent.
Just like I'd be right to say that I own a car while someone else
claims that I own an automobile. However in both cases, they can't
quite be used interchangeably. After all, an automobile isn't
necessarily a car. It can be a truck or a van or an SUV.

In the same sense, a persistent data structure is effectively
immutable. But an immutable data structure isn't necessarily
persistent. Let's consider the definition of both of these words from
wikipedia:

Immutable object

In object-oriented and functional programming, an immutable object is

an object whose state cannot be modified after it is created.

Persistent data structure

In computing, a persistent data structure is a data structure which

always preserves the previous version of itself when it is modified;

such data structures are effectively immutable, as their operations

do not (visibly) update the structure in-place, but instead always

yield a new updated structure.

These definitions have a lot of common ground, but there is some
difference between them. Let's consider a data structure that is
immutable but not persistent. Prepare yourself. This will be
complex. Ready?

 
>>> 1 
1

Has your mind been blown yet?

In this sense, the number 1 is definitely immutable. You can't change
it. It's always the number 1. However, it's not persistent. How do
you update the number 1? No matter what you do, it will always be the
number 1. Sure, you can get 3 by adding it to 2. But in a
mathematical sense, that's not really changing the number 1.

In this sense, the number 1 is atomic. It simply doesn't make sense
to modify it. Heck, you can't even copy it:

 
>>> from copy import copy 
>>> a = 1 
>>> a is copy(a) 
True

Conclusion

With this semantic difference in mind, remember that it's just that:
a semantic difference. Call them Bob if you want to. However, bear
in mind that when someone uses the word persistence in this way,
they're not being inaccurate.

Filed under // functional-programming persistence programming python

Comments (0)

Jason in a Nutshell

functional-programming