What Does It Take To Become A Programmer?

So these are my thoughts on this article (hint, it’s utter tripe): Programming Doesn’t Require Talent or Even Passion.

On the one hand, this article espouses a good sentiment (you don’t have to be gifted to learn programming). On the other, it completely disregards the important idea that being able to do something is not the same as being able to do it well.

I can draw, but anyone who has seen me draw would agree that I’m pretty bad at it. I can draw just well enough to get my concepts across to other people. However, if I intended on becoming an artist for a living, I should probably learn about proportions, shading, composition, perspective, color theory, and be able to work with a range of mediums. Of course, there isn’t some big secret to learning these things. You just practice every day and study good artistic work, analyzing how it was made. Maybe you take some courses, or read some books that formally teach certain techniques. After thousands of invested hours, you will find that your drawing has radically improved, as shown again and again by progress comparison pictures (that one is after 2 years of practice).

The same holds true for programming. Anyone can learn programming. It requires nothing except a little dedication and time. But the article starts out by promising to ‘debunk’ the following quote (I’m not sure if it’s actually a real quote – they don’t attribute it to anybody):

You not only need to have talent, you also need to be passionate to be able to become a good programmer.

The article immediately ignores the fact that the ‘quote’ is talking about good programmers. Just like becoming a good artist requires artistic talent and a passion for learning and improving every day, good programmers are driven by the need to learn and improve their skills. Perhaps an argument can be made for “talent” being something you acquire as a result of practice, and thus you don’t need talent to start becoming good; you become good as you acquire more and more talent. This is a debate for the ages, but I would say that almost invariably a passion for a skill will result in an early baseline proficiency, which is often called “talent”. Innate talent may or may not exist, and it may or may not influence learning ability.

It doesn’t really matter though, because the article then goes on to equate “talent” and “passion” with being a genius. It constructs a strawman who has always known how to program and has never been ignorant about a single thing. This strawman, allegedly, causes severe anxiety to every other programmer, forcing them to study programming at the exclusion of all else. It quotes the creator of Django (after affirming that, yes, programmers also suffer from imposter syndrome):

Programming is just a bunch of skills that can be learned, it doesn’t require that much talent, and it’s not shameful to be a mediocre programmer.

Honestly, though, the fact of the matter is that being a good programmer is incredibly valuable. If your job is to write code, you should be able to do it well. You should write code that doesn’t waste other people’s time, that doesn’t break, that is maintainable and performant. You need to be proud of your craft. Of course, not every writer or musician or carpenter takes pride in their craft. We call these people hacks and they churn out deplorable fiction that only shallow people read, or uninteresting music, or houses that fall down in an earthquake and kill dozens of people.

So, unless you want to be responsible for incredibly costly and embarrassing software failures, you better be interested in becoming a good programmer if you plan on doing it for a career. But nobody starts out as a good programmer. People learn to be good programmers by having a passion for the craft, and by wanting to improve. If I look at older programmers and feel inferior by comparison, I know it’s not because they are a genius while I am only a humble human being. Their skill is a result of decades of self-improvement and experience creating software both good and bad.

I think it’s telling that the article only quotes programmers from web development. Web development is notorious for herds of code monkeys jumping from buzzword to buzzword, churning out code with barely-acceptable performance and immense technical debt. Each developer quote is followed by a paragraph that tears down the strawman that was erected earlier. At this point, the author has you cheering against the supposedly omnipresent and overpowering myth of the genius programmer — which, I might remind you, is much like the myth of the genius painter or genius writer; perhaps accepted by those with a fixed mindset, but dismissed by anybody with knowledge of how the craft functions. This sort of skill smokescreen is probably just a natural product of human behavior. In any case, it isn’t any stronger for programming than for art, writing, dance, or stunt-car driving.

The article really takes a turn for the worse in the second half, however. First, it effectively counters itself by quoting jokes from famous developers that prove the “genius programmer” myth doesn’t exist:

* One man’s crappy software is another man’s full time job. (Jessica Gaston)

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

* Software and cathedrals are much the same — first we build them, then we pray. (Sam Redwine)

The author LITERALLY ASKS: “If programmers all really had so much talent and passion, then why are these jokes so popular amongst programmers?”, as if to prove that he was being intellectually dishonest when he said back in the beginning “It’s as if people who write code had already decided that they were going to write code in the future by the time they were kids.”

But the absolute worst transgression the article makes is quoting Rasmus Lerdorf, creator of PHP. PHP is a server-side language. It is also one of the worst affronts to good software design in recent history. The reason it was the de facto server-side language before the recent Javascript explosion is that it can be readily picked up by people who don’t know what they are doing. Like you would expect from a language designed by someone who “hates programming” and used by people who don’t what they are doing, PHP is responsible for thousands of insecure, slow, buggy websites.

PHP’s shortcoming are amusingly enumerated in this famous post: PHP – a fractal of bad design. In the post, the following analogy is used to illustrate how PHP is bad:

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

And according to Rasmus Lerdorf, the creator of this language:

I’m not a real programmer. I throw together things until it works then I move on. The real programmers will say “Yeah it works but you’re leaking memory everywhere. Perhaps we should fix that.” I’ll just restart Apache every 10 requests.

It’s like the article is admitting that if you don’t take the time to learn good programming principles, you are going to be responsible for horrible systems that cause headaches five years down the line for the people maintaining them and that regularly allow hackers to access confidential personal information like patient information and social security numbers for millions of people.

So yes, if you aren’t planning on programming for a career, learning to program is fairly straightforward. It’s as easy as learning carpentry or glass-blowing. It might seem daunting, but invest a half dozen hours and you can have your foot solidly in the door.

But if you plan on building systems other people will rely on, you sure are hell better pick up some solid programming fundamentals. If you aren’t motivated to improve your skillset and become a better programmer, don’t bother learning at all. Don’t be the reason that the mobile web sucks, and don’t be the reason that 28 American soldiers died. Learn to be a good programmer.

Language Gamification

Gamification may be bullshit, but does that mean it might be just the tool to fight your own, personal brand of bullshit?

Screenshot of Duolingo

Learning foreign languages is hard. Really hard. Part of this has to do with complex neurological reasons, which can only be explained using words like neuroplasticity and monolinguals. Yes, some of the difficulty is hard-wired. But additionally, a part of you just doesn’t like learning foreign languages. It’s complicated and easy to forget, requires a lot of memorization, and you can still sound like an idiot after years of practice. Sometimes the linguistic variations are impossible to pronounce or hear, or the grammatical structures are completely foreign to your mental processes. So you make up bullshit: reasons to skip or skimp on practice, or give up altogether. Learning a foreign language is a constant battle against your lazier self.

Duolingo logo

But Duolingo changes the game, so to speak. It gamifies the process of learning a foreign language, adding daily goals, streaks of meeting your daily goal, unlocking mechanics, currency and purchasing, and total progress towards fluency. Now, it’s not a particularly good way of learning a language. In fact, it’s terrible at teaching. But really, teaching isn’t the point of Duolingo. It’s just a way of defeating your bullshit by replacing it with a more benign type of bullshit.

Duolingo assigns tangible, meaningless progression to the real, intangible progress of learning a language. Without Duolingo as a external, concrete arbiter that says “Yes you are getting better”, learning a language can feel hopeless because no matter how much you master it, there are always more words to learn, faster sentences to parse, and structures you don’t understand. Now, the “percent fluency” that Duolingo feeds you doesn’t necessarily correspond to any real gains, but it affirms that the hard mental work you put in today actually paid off in some continuing educational journey. And that affirmation is what makes you come back the next day to learn more.

Learning a Foreign Language

I have had the benefit of taking Japanese 1 this semester, and it is quite a humbling experience. Learning a language which has no romantic roots — a truly foreign language — lends a certain perspective that learning French or Latin does not.

However, it also seems to me that the teaching method is geared towards a very specific type of learning style. The class starts out by teaching a number of phrases which the students are to memorize, and meanwhile students also begin to learn one of the writing systems. It is not until a few weeks in that students finally learn some grammar (i.e. the thing that actually determines whether or not a communication system is a language), and even then it takes time to learn the exact mechanics behind the memorized phrases.

For instance, we learned how to ask how to say something in Japanese: (english word)wa nihongo de nanto iimasuka. Yet we are not told that nihongo means Japanese language (although it can be inferred), and we certainly aren’t told that ~go is a suffix, applied to the word nihon (Japan), which means the language of. In addition, we aren’t told that nan means what, ~wa is a topic particle (and we certainly aren’t told it’s spelled using は instead of わ, because hell, we don’t even know how to write at that point), or that to is a sort of quotation mark (if we are, it is only in passing and without context).

Insights can only be gleamed by comparing the response: (Japanese word)to iimasu. Now it becomes clear that ~ka is a question particle. So yes, nanto became (word)to, so ~to must be some sort of literal marker suffix. iimasu must be “say”, or thereabouts.

My point is that it is very hard for me to memorize phrases or words with no context. The teaching style is designed to help a certain type of learner. My learning style would benefit greatly from learning a variety of grammar and vocabulary separately, and letting my brain concoct the phrases from their base elements; when I speak, it flows logically, and my mind pronounces one morpheme at a time. Learning whole phrases with no context means I can’t break it down into morphemes, and so production of the sounds comes much harder.

Perhaps this will change after we get past the first few weeks, but I can’t help worrying that this sort of learn-specifics-then-learn-rules teaching style will continue.

A Solution for Difficulty Curves and Power Creep

Most games portray you as a hero of some sort. A common trope is for the hero to be either inexperienced at the beginning of the game, or lack his equipment. This gives a reason for why the hero does not just plow right up to the main baddie and kill him at the beginning. In any case, a lot of games suffer from a strangely shaped difficulty curve. The game starts out fairly easy as the player learns the ropes, then the enemies get harder. Finally, you max out your stats and the game begins to get easier again.

Granted, the best games suffer from this less, but a lot of games have trouble with this type of power creep. Spore is a prime example of a ridiculously easy endgame (the space stage was essentially a sandbox). Some developers solve this by making enemies more powerful as the player progresses. This can work in games where, for instance, the enemy starts to realize just how much of a threat you are. In open-world games like Skyrim, though, this makes little sense.

Yahtzee, of Zero Punctuation, mentioned in one of his Extra Punctuation an inkling of an idea for a game that is designed with this problem in mind. I have taken the liberty of gripping the nebulous concept by the horns and fleshing it out.

The game is based around the power suit you wear. It is a magnificent piece of High Technology. Unfortunately, this means that nobody is quite sure how it works. The machining of the piece is much too fine to replicate, in any case, which means any replacement parts have to come from other pieces of High Technology, which are few and far between.

At the start of the game you escape from the main fortress of the Bad Guys with some sort of Valuable Item (perhaps information). You raid the armory and steal the suit before plunging yourself deep into the wilderness around the citadel. You spend the game running from a cadre of pursuers, trying to make your way to the border. At every encounter with an enemy, it is up to you to protect your suit as much. Each blow is physically simulated and, depending on where you place armor, where the hit was, how hard it was, etc. a component on your suit has the potential of breaking. Parts also wear down over time.

The most critical part of the game is deciding how to keep your suit in working order. Some systems are critical, like the pneumatics that let you move (damage to arm parts may impair aiming speed, damage to legs may reduce speed or jump height, etc), and some are dispensable, like weapons. If a critical system receives a hit and becomes in critical danger of breaking down, you have to stop and either fix it with any spare parts you find, or scrap a non-critical system on your suit to get the essential parts.

This meta-game with the suit solves the problem of power creep. You are at maximum power at the beginning, but enemies are also at the greatest density. Slogging through the wilderness and fighting enemies wears your suit down, so by the end you are barely limping along. As time goes on, you have to choose which weapon or system to scrap for parts. This means that you get a sample of all abilities at the beginning, and can keep the ones that best suit your play style. One of Bioshock’s biggest problems was that there was no incentive to try new plasmids. I’m sure the majority of players just improved the starting set, because buying new powers was too much of a liability.

I like the idea of having the game being mostly free-world. You can choose the best path through the different types of terrain to avoid encounters. Cold environments, wet environments, and sandy environments all have different types of wear and tear on the suit. Roads are easy to traverse (meaning less food consumption and lower likelihood of suit failure) but are more likely to find troops on them. Towns and other population centers are more likely to hold supplies (food and maintenance items are critical for survival) and spare parts, but the citizens will raise the alarm if they see you, and there are likely to be troops in towns.

The catch is that any alarms you raise will alert the search parties to your general presence and means a higher chance of encountering troops. Same goes for any military engagements in which an enemy scout or survivor escapes. The game is part stealth (avoiding conflict), part tactics(managing the suit, choosing your world route), part combat (winning conflicts you get into). At the end, instead of a boss fight, you have a final battle at the border of the kingdom as the search parties converge on your position and a friendly militia comes down from the other side of the border to help you across.