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:
- Stop reading bullet points!
- You heard me, stop reading these stupid bullet points!
- They're not helping, you know.
- They are often just fluffy platitudes.
- Still reading? I thought you'd get wise by now?
- It just shows how useless bullet points actually are ...
"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.
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, 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!
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.
"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.
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:
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.
"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).