09 September, 2013

Learning to code from drowning

First, you drown (and get saved)

Simply put, I'm not a coder. I found this out the hard way with my first C program, called list. It tried to display a file to the screen, a la less(1) or more(1) but with a wrinkle. Of course, I decided I wouldn't look at any previous source code from either of those programs.

First off—although I didn't know it at the time—I did two things wrong. I learned a long time later that coders don't reinvent the wheel if an established codebase already exists. They simply credit, use, and move on. The second thing I did wrong? I didn't expose myself to how things were done properly. I came in as an almost completely new coder, barely knowing what a function was. One of the things that experienced coders have done is to examine as much good code as they can manage to without invading corporate secrets. I get the impression that they practically drown themselves in good code, hoping—or perhaps knowing—that some of the code will stick in their memories to use later on.

A function is always embedded in code. To be successful at this, each function has to do one job, and only one job. For code reuse to work, a typical function has to be used more than three times within a codebase. You have to know what job your program does. You also have to know how you divide up that job into functions. It might be stretching it to say that your “job” should only be decomposed into functions you already know how to write. If that were the case, then I would have never persisted with programming. However, you do have to know how to write good code. There's no sense in creating a C program that doesn't free any memory you allocate. There's no sense in trying to write your .NET without classes—it's practically impossible. And there's no point in trying to fight the programming language to do what you want to do. If you can't write the function you need to—either because you don't understand the programming language or the programming language won't allow you to—then you have two options. Learn the language inside out, or change languages. This isn't practical within the context of a single program, as you have to stick to one language for one program.

Now, you learn to swim

Of course, reading lots of good code isn't any use to you until you understand it—especially how it interacts with other code. Often, bugs aren't caused by poorly written code, but instead by poorly understood code. You wouldn't use a mini to transport your 5-bedroom house, but I swear that some programmers would try it.

Try another beach

Specialising purely in one language or another will make you really good—eventually—in that one language, but won't be very portable to other languages until you understand the programming concepts behind the code. It's usually a pretty good idea to at least become familiar with multiple languages, and even families of languages, as this can often make the difference between barely reaching the target or being the best tool for the job at hand. You may not see Haskell in your workplace if it's a Java shop, but knowing the concepts that led to Haskell may give you an edge in understanding. And if you spent your life learning assembler, then Smalltalk can seem like another planet.

No comments: