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 shit 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 shitty 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 full of shit 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. For those of you not “in the know”, 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.

Advertisements

Like it? Share it:

Like this:

Personally I find that whenever my engineer brain switches on, my designer brain switches off. I have to step away from coding for a while in order to objectively make the best decisions about what to implement and how. When I let my engineer brain do the designing, I end up falling into age-old preconceptions about how things should be. This is especially true when it comes to UI design.

But is it the best idea to blindly follow UI conventions, either new or old? On the one hand, a familiar UI layout and universal UI idioms will make it easier for users to jump straight into your program. However, if those idioms aren’t well suited to your application, the user can quickly find themselves confused, frustrated, and lost. If the UI was unfamiliar but uniquely designed around your application, the users will be less confused because they have no expectations which can be unwittingly subverted.

Some bad features:

Confirmation emails which require you to click a link before you can do anything with your account. Confirmation emails that require a link to be clicked in 24 hours but which do not impede progress are much better.

An example of a good feature is the use of universal symbols for universal functions. Using a crazy new “save” icon is not a good subversion of conventional UI idioms. Another is exit confirmation; in a lot of cases, confirming whether you want to save before exiting is a great feature.

Here are two features which are not standard for applications with text-editing capability but which should be (I’ve only seen it in a handful of programs, of which Notepad++ is most prominent):

A “Rename” option under the File menu, which saves the file with a new name and removes the file with the old name. This saves the tiresome task of doing “Save As” and then deleting the file in the save window, or (God forbid) having to navigate to the file in your OS’s file browser and renaming the file there.

Special character (\t, \n) and Regex support in “Find and Replace” modes.

Like it? Share it:

Like this:

So I’ve recently been thinking that the whole idea of editing text files filled with code is outmoded. When I’m thinking about code, I certainly don’t think of it as a set of classes and functions laid out in a particular order. I think of it as a cloud of entities with properties and interactions flowing between them. Shouldn’t our experience of writing code reflect this?

We need to start rethinking our code-editing tools. A lot. Here is a simple example:

What else could we do? How about the ability to arbitrarily break off chunks of code and view them in parallel, even nesting this behavior to break long blocks of code into a string of chunks:

What if we let the flow of the documentation decide how a reader is introduced to the code base, instead of letting the flow of compiler-friendly source files decide it? Chunks of code are embedded within wiki-style documentation, and while you can follow the code back to its source, reading the documentation will eventually introduce you to the whole codebase in a human-friendly fashion.

The same code could even appear in multiple places (obviously updated when the source changes), and you could see all the places in the documentation where a particular chunk of code appears. This could bridge the gap between documentation and code; documentation will never grow stale, as updating code necessitates interaction with it. Similarly, updating documentation is the same process as writing code. When a standard changes or an SLA (service level agreement) is modified, the code changes too.

But why restrict ourselves to semi-linear, text-based documentation a la wikis? We tend to find UML diagrams extremely helpful for visualizing complex systems in code. What if we could build powerful, adaptable tools to translate between raw code, text-based documentation, and visual diagrams? Strictly binding them together might restrict you in the lowest levels of coding (much like, for example, using a high-level language restricts your ability to control memory allocation), but it opens up the new ability to make changes to a diagram and have most of the code rearrange and resolve itself before you. Then you step in to give a guiding hand, and adjust the text documentation, and voila! Best of all, this is more than a diagram-to-code tool; the diagram is a living thing. In fact, the diagrams, the documentation, and the codebase are synonymous. A change in one is a change in the others.

We’re getting to the point where it is much more useful to be able to dance across a codebase quickly than to be able to tweak and tune the minutiae of your code. Some allowances must be made for processing-intensive applications. Perhaps this system wouldn’t even be useful in those cases. But when you find yourself favoring adaptability and iteration speed over efficiency during development, and when you find yourself being hampered by the need to go between files, scroll through large swathes of code, or referring back and forth between code and documentation, maybe it’s time to rethink your coding paradigms.

There’s this really big problem when it comes to working on games (or really any sort of project that lies at the intersection of engineering and design). It has nothing to do with programming or design or testing or art or sound or anything else like that.

The problem is staying motivated. This is especially bad when you are working alone, but it can even happen in groups of 2 or 3 people. Beyond that, you can always find motivation in the stuff that other people are doing, because it comes from outside of your personal drive and creativity. But in small groups or solo projects, the game becomes your baby, and then you get tired of your baby.

Sometimes this happens when you work so long on one subset of features that they sort of blur together and become the totality of the project to you. You quickly get tired of this smaller sub-problem (especially tweaking and tweaking and tweaking), then get tired of the game without realizing there is other interesting work to be done.

Or maybe you realize that there is a lot of stuff to do on the project, but you’ve been working on it so long without much visible or marked improvement that you begin to despair. Maybe the project will never flower, you think. Maybe your efforts will never be used to the full extent they were designed for.

Wherever this loss of motivation comes from, there is one piece of advice I heard that really helps me. It boils down to this: if you keep wishing your game was awesome, make it awesome. Add in that feature you keep thinking about, but keep putting off because there is more important framework-laying to do. Or take some time off and mess around with that one technical gimmick (shader, hardware stuff, multi-threading, proc-gen, or what have you). When you feel yourself losing motivation, give yourself permission to go off and get it back. Don’t soldier on, because your project will inevitably end up on the dump heap with all the other projects you abandoned.

The only problem is, everyone (including myself) always says that adding eye-candy and little trinkets to your project prematurely is a Bad Idea. If you make your game cool by adding eye-candy, the wisdom goes, then your game is no longer cool because of the gameplay (you know, the point of a game). Arguments about whether gameplay is important not-withstanding, if adding a few bits of visual indulgence saves your game from succumbing to ennui, then by all means, add the cool things!

Like this:

Taking an introductory programming course this semester has been an interesting experience. Since I grasp the course material well, I’ve spent some time helping others with their work. As anyone who has taught math can attest, teaching even basic concepts requires you to understand the material far better than the student must. When it comes to programming, helping people is even more difficult because you can’t just tell them how to do it. You need to let them to figure it out on their own, otherwise they won’t have learned anything.

But leading someone along without explicitly telling them anything is really, REALLY difficult. Our professor is a master at this, and I respect him deeply because of it. A student will ask a question, and the professor will reply with an oblique statement that doesn’t seem to address the student’s question at all. Yet soon enough the student says “Oh! I get it!” and goes on their merry way. I try as hard as possible to emulate this method when I help those who are struggling, but it is nigh impossible to strike the correct balance. Help them too much, and they don’t learn. Help them too little, and they despair or begin to resent programming. And as much as I don’t like seeing it happen, many of the people in the class have come to resent programming.

This is as sad as a student resenting literature because of a bad English class experience, or resenting math because of a bad math teacher. Yet I don’t fully understand how to prevent it. If there was a good, standardized methodology for teaching difficult concepts without causing students to resent the field, I feel a lot of the problems in society today could be solved. Maybe that is just wishful thinking, though.

The second interesting observation from taking this class has come from observing a peer. The first language she learned was Python, and learning C++ this semester has caused some distress. There were many lamentations along the lines of “why is the computer so dumb?!” Of course, I found this hilarious because it mirrors a situation in the novel A Fire Upon the Deep. As the protagonists head towards the bottom of the Beyond, much of their advanced computer technology stops working, and they are forced to adopt more primitive methods. Needless to say, the characters who grew up with the advanced technology are indignant that they are forced to use such primitive technologies as a keyboard. Meanwhile, the character who grew up using primitive technology merely smiles.

In my mind, this helps clear up the argument of whether new students to the art of programming should be started on a high-level language, or a low-level language. Until such time as low-level programming is never needed except in rare circumstances, students should be started at a medium-to-low level. For example, it is easier to step up to Python from Java than it is to step down. I was originally of the mind that new students should start at a high-level as to learn common computing concepts without getting bogged down in obtuse technicalities and syntax, but getting a first-hand view of the results of such an approach has changed my mind.

Like this:

I’ve finally reached that breaking point where I am comfortable with the Unreal Engine. I may not have knowledge of every aspect, but I am finally understanding the basic axioms driving the inner workings, which allows me to intuitively understand where to look when I am stumped. The unfixable problems are falling away as my problem-solving abilities increase with respect to the environment. When you are utterly clueless about the engine, it can be difficult to know what kind of help to look for.

So in the past few weeks I began working on the project again. This time, I would build up an easy, lightweight framework from the UDK (rather than UT) packages — that is, I started out with much less pre-built functionality so that I could understand everything that was going on.

I succeeded. So far I’ve built a basic Pawn framework (Pawns are objects controlled by players or AI) with a custom crouch system and an Inventory Manager that better suits my needs. I’m also working on a Weapon system, although I haven’t implemented sounds, particle effects, etc. My HUD system is minimal, but so far that is all I need.

When I need to, I go to the UT packages and look at their implementations. However, the number of times I’ve copied and cut down code has decreased dramatically. Now I can write my own code with confidence that it does everything I want it to (note that although I am perfectly comfortable coding, it is more about knowing which function calls go where in the logic chain, and what to reference).

Note that I don’t have grenades, vehicles, sounds, shields, AI, other characters, or environments yet. However, I’m more comfortable having a small, solid base of functionality that I completely understand, rather than a thin spread of half-implemented, opaque features. Down one road lies abandonment, down the other lies slow but steady plodding to completion.

This has been a pet project of mine for a long time. I’ve taken a couple cracks at making one, but have failed miserably each time. My objective is to create a simulator that allows players to play battles with various armies, allowing them to refine their strategies before actually buying the models. However, I want a fairly flexible and modular rule system that enables alternate rulesets to be introduced (not only other official rule editions, but custom gametypes like racing) and of course custom armies. There are two inherent problems with creating a realistic simulator:

The number of exceptions to the rules is about as large as the number of rules. Many exceptions rely on human understanding of the rules, and get resolved intuitively. This is problematic when going for a procedural approach

The rules change. I started playing with 4th edition rules. My first attempt was during that phase. When I made my second attempt, the rules had moved onto 5th edition. Now they are in 6th edition. It’s a pain in my ass.

The two previous times I attempted to make a simulator, I programmed from the ground up. This time I’m thinking about using Unity3D. This makes sense in at least one regard: Line of Sight is contingent on precise model and terrain geometries. If I want the project to match my objectives, I need some sort of 3D system behind it.

I see a pretty clear path for development. The first step is to breakdown the rules into a clear procedural system. After I can see the possibilities that need to be encountered, I can figure out how to generalize that into as simple an architecture as possible. Then I can figure out how to implement that in Unity3D.

Unfortunately, every step of that is hard. I’m still stuck on that first step. First, I’m unaccustomed to the 6th edition ruleset. Second, the rulebook isn’t laid out optimally for my purposes. It works well for a beginner building up their understanding. The basics of each step is introduced, and then later modified with exceptions and special cases. I need an organizational somewhere between a flowchart and an outline.

So I have two things I need to do: map the rules, and learn C# for later use in Unity3D.