Saturday, September 13, 2008

7 Fabulous Ways to Great Programming

This post is for all of you coding surfers that have ever anonymously filled in "TL;DR".

So you wanna be a great programmer, do ya? All you have to do is follow these seven easy bullet points:

  1. Stop reading bullet points!
  2. You heard me, stop reading these stupid bullet points!
  3. They're not helping, you know.
  4. They are often just fluffy platitudes.
  5. Still reading? I thought you'd get wise by now?
  6. It just shows how useless bullet points actually are ...
"Crap, he tricked me", you're thinking? I did so on purpose, but only because I really do want you to be a better programmer, I'm not kidding.

"Get on with it", your inner voice is screaming, adding in "just give me the highlites, the bullet points, the summary, dude. I don't need the rest of your stupid rant."

The problem -- in bullet points -- is:
  • bullet points only convey "summary" information.
  • bullet points are forgettable.
  • bullet points are junk food, a kinda McIdea that neither teaches nor satisfies.
Honestly, you can't learn anything significant from bullet points. It's just not possible. If you're lucky, they'll remind you of something you learned earlier and bring it back to the surface, but you're not going to achieve knowledge from something like Cole's notes (google it). These things may help you if you've already had exposure, but they just ain't got the knowledge in them.

If you want the knowledge then you have to get the knowledge, otherwise you know nothing.

Ways to do that:
  • Spend hundreds of years writing every possible type of program.
  • Apprentice with an experienced programmer.
  • Read, read, read and read.
  • Take courses, then read.
  • More reading.
"Well, I don't want to waste my precious time reading someone else's long rambling crud!", your might be screaming by now. Hell, even spending the 30 secs to type "TL;DR" might be excruciatingly painful.

Well, too bad. So sad, sorry and all of that. You foolishly picked a rather incomplete occupation; programming and software development are barely out of their diapers. We just haven't had centuries to distill the knowledge out of the experience, yet.

Some day, perhaps, but until then we're all struggling with trying to find a voice to share our experiences. Sometimes that provides good solid reading, but sometimes it only comes off as a rant or a ramble, with hidden buried gems piled deep in the subtext.

But, and here's the BIG point:
  • There is real knowledge buried in the subtext.
  • You can't learn that knowledge unless you read the full text.
  • It can't be summarized.
  • It's not even necessary the main point.
  • Skimming the text misses its real value!
Some stuff is subtle and easily missed. If the author knew how to really express it, it probably would have been written that way. But it's impossible to squish all of the knowledge into summary. That's why its called a summary.

A little knowledge is a dangerous thing. Always has been, always will be. If you sort of know how to drive a car, and you mostly follow some of those "rules" about silly things like lanes and stop signs and such, you're not going to last long. You're just a roving accident waiting to happen.

And oh, if that knowledge, has been even further diluted into a list of platitudes, ack! Seven reasons for "anything" is probably useless to you. It is probably useless to most people, unless it is just acting as a reminder for known ideas. Really. For starters:
  • Platitudes say nothing, but sound good.
  • They are easily forgotten.
  • They fill you up on junk knowledge, when you should have been learning.
A bad food diet is an obvious fail, so is a bad intellectual one.

"Still, people could distill their crap into 3 easily readable paragraphs, dude." you're insisting.

Possibly, but most bloggers are amateurs, we barely have time in our lives to write this stuff. Half the time we don't even really know what it all means. Not, as you might guess, the explicit text of what is being said, but what it really means in the bigger sense, the holistic view. There is so much buried, hidden between the lines, just waiting to get a voice. Particularly in a field like Computer Science were it is still not fully understood, huge amounts of important knowledge get buried in people's direct experiences. It is hard to fully express that understanding.

In a strange sense, we can only communicate what we explicitly know, but often times the topics are implicit. Sometimes when I am writing, for example, I'll dig at something deeper, but other than just bouncing around it, I don't really have the vocabulary, yet, to express what I am trying to say.

Some of my later works, are just continuations or follow-ups of my earlier writings, each time they are getting a little closer to the real underlying truth.

Pretty much if you read most of the serious essayist bloggers you'll find the same thing. Learning to express something unknown is a truly creative act, a spontaneous one. Of course just repeating well-known platitudes isn't, but then isn't that why they are platitudes in the first place?

Blogging as a medium is a direct way to access a mass amount of early information. It has not been comfortably packaged into neat theories and pretty textbooks. It might be the predecessor of some well structured understanding, but only if you're willing to wait for it to drift into the main stream. In an industry like software development, where so much of what we do is based on intuition and guessing, getting any addition comprehension is a major assistance.

"Fine, so long blogs are often interesting, but badly packaged information; I've got masses of dysfunctional code that I've written that needs urgent fixing. I just don't have time to dig for gems." you moan, adding it "and it has nothing to do with my bugs anyways!".

Initially I said:
  • I want to people to be better programmers.
  • bullet points suck!
  • real knowledge is buried in the subtext.
Like many bloggers, I write because I want to share my knowledge and experiences, but it's not nearly as altruistic as it sounds. Programming mistakes are making my life miserable. The current state of our industry is embarrassing. I would have hoped that programming had progressed a little further as I got older, but so much of our current code base is just awful. Damned awful, really. And I keep getting stuck trying to add something useful on top of an ever increasing mess. Sadly, most of the problems stem from messy inconsistent behaviors in the code, a problem that is getting worse, not better.

We could wait for an understanding to trickle down upon us from academia. Some day, there will be cohesive theories and processes that support reliably building complex systems. Someone will eventually discover a better way of coding. But, that process is slow, and at its current rate things are not likely to improve until well after I have finished my career, possibly my lifetime.

Another alternative is to reach out to the industry, and hopefully explore the issues in a way that we all come to learn how to build better code. There are pockets of excellence in programming, but they certainly are not the state of the industry.

The single largest problem with software comes from its inconsistency. It is a dog's breakfast of inoperative ways of handling data, often half finished, and poorly extended. It is a big mess that we are deliberately making bigger.

"Sure, but not my stuff. It just has a few bugs, that's all" you chime.

Here's the rub (as Shakespeare might have said, according to Cole's notes): The single greatest, most important, significant all-powerful encompassing, awesome, extreme, critical, supreme points about programming are:
  • Focus!
  • Self-discipline.
  • Consistency.
You'll never meet a great programmer that doesn't have all three. They are mandatory. They often have other qualities, but none of the highly skilled programmers can survive without these basic attributes.

If they're out there telling you otherwise, you know they're just blowing smoke. It's simple:
  • good programmers write good code.
  • good code is neat and simple.
  • good code is consistent.
A huge mess of code is just that, a huge mess, not good code. There might be some great ideas buried in the design, but unless it is well implemented it is not good. Programming is about the output, if it is messy or flaky that defines the quality of the work.

"So what the hell does this cranky nonsense of yours have to do with my code?" you start to ponder.

Here is the easy bit. Very simple. This entry, as the title indicated was about fabulous ways to great programming. The most important of these is the ability to focus for long periods. If you are finding that reading large blog entries is far too taxing, then you are having problems focusing. If you can't get through several pages, then how can you expect to get through five years working on the same massive code base? Serious development is a huge amount of work. A month of HTML is fun, but light-weight coding isn't the same as having written something big and serious.

The problems, the real ones, take a long time to sort out and are complex to build. Inherent in this, is a tremendous amount of focus and consistency. To survive, year after year, you need to be self-disciplined. These attributes are all intertwined.

If you're flailing at the keyboard, or waiting for your boss to "make you" refactor that mess you spazzed into the machine last month, then focus or self-discipline could be the problem.

In point of fact, if every long blog article is automatically "TL;DR" by default, this ADD driven approach is bound to spill over into the other parts of your career. If you can't focus for longer than a few minutes, there is no way your code is going to be "great". Just ain't happening. Programming isn't a multi-tasking opportunity; you sit down for long periods at a time, heavily focused on the work. If you cannot do this, your code may be a hell of lot of other things, some of which may end up entertaining people on WTF, but it unlikely to ever be great, and probably not even good.

Consistency is a mandatory property of good code. Focus and self-discipline are the ways to get it there. Bouncing around on the net, reading only short platitudes and bullet points indicates a possible inability to focus. Leaving comments such as "TL;DF" says more about the reader than I think they would care to admit.

The way to better coding is to spend more time trying to learn. Experience is a way to refine knowledge, but you need to acquire it first, or else you will just wander around in the dark forever. Beyond the standard texts, which are far from complete, the new and often critical knowledge these days is buried in long blog discussions. An apprenticeship would be better, but experience leaves our industry fast, and many people misgauge their own abilities.

Certainly any increase in focus and concentration will filter back into your coding practices. If you keep it up, the things you write will be cleaner and better structured, giving you a fighting chance to remain a programmer for longer than just a few years. Good work comes from good habits. Great work comes from really understanding all of the details and nuances of what you are doing. It is several levels beyond just being able to get it to compile.

For all those that skipped most of the above text, just a quick summery:
  • bullet points rock!
  • great careers are opening up in marketing.
  • happiness is a bigger hard-drive.
  • the clothes make the man (or woman).

6 comments:

  1. I guess you haven't written a book!

    ReplyDelete
  2. "In point of fact, if this whole article is "TL;DR" then there is no way your code is going to be "great". "

    I'm sure plenty of good coders have never read your page. Get over yourself. While I normally enjoy your posts, this one was rather egotistical.

    ReplyDelete
  3. Eek, it's not supposed to be about me, it's supposed to be about ANY long written posts.

    I was playing with my writing style, trying to get it to be a bit light and edgy, but I'm getting the feeling this post didn't work too well :-)

    I'm not a very good writer, nor (hopefully) do I pretend to be. I actually started blogging to learn how to write.

    The point I was trying to make (badly) was that if you're going around typing "TL;DR" into a whole lot of blog posts -- a popular habit these days -- then you are saying a lot more about yourself then you realize.


    Paul.

    ReplyDelete
  4. I think that this post was better than the others, at least better to read. The problem is that long posts are not automatically worth reading, and it takes longer to find that out.

    In some other posts of yours someplace I thought 'where is this supposed to lead to', and stopped reading. This one I read in one sitting. I suppose it has to do with the presence of a teaser. Also it helps if there is a coherent surface story along with the deep undercurrents. :-)

    ReplyDelete
  5. Hi Andreas,

    Thanks for the comments. I'll still experimenting with my writing style, I figure at the current rate I'll get it down in just a few hundred years or less :-)

    This post was actually my second pass, I gutted the original a lot because people were finding it too much. Sounds like this edit was a big improvement :-)

    Paul.

    ReplyDelete

Thanks for the Feedback!