Back To Basics
Back To BasicsAfter PairProgramming for nearly a year, I have some recommendations for programmers about the basics.... much of it for myself.
1. Learn to type faster.
No matter how fast you type, you can always learn to type a little faster, and it is almost impossible to type faster than your pair can read. Your pair will appreciate it. You can get a typing tutor program fairly cheap (although I don't know of one optimized for programmers.... I still have a hard time sometimes with those characters over the number keys....)
A couple of times I have actually encountered senior software developers with over 10 years of experience, who hunt-and-peck! It doesn't seem to bother them, but for pair programming it is somewhat painful. You could also go around life hopping on one foot, but why would you want to? Why not learn to use all the appendages you've got that are appropriate for the task?
Agreed. This can really be a red flag sometimes. I have had the misfortune of working with two horribly inept programmers. One, having 10+ years of experience was a slow two-finger typist whos editor of choice was notepad (I never could find out why). I thought that was bad until meeting the second. He was a developer-cum-manager-cum-developer again. Loved to tell "war stories" about the good old days, coding battles he and his band of merry men had won. He didn't hunt and peck, but had a unique typing style of his own, which could manage about 10wpm on a good day. But the best part was that after his stint as a manager he had become obsessive about documentation (or it was older than that). He wrote all his docs in MSWord, and didn't like continually switching back and forth from Word to an editor. So, yup, you guessed it: he decided to write code in word. I'm sure there are competent people out there who can't really type... but thanks to these two I cringe whenever I see it, visions of the-code-review-from-hell flashing through my mind.
2. Code Comprehension.
Maybe it's because the Internet and Open Source are new-fangled things, but most programmers just aren't in the habit of looking around at other people's code unless they absolutely have to. It's not much fun, I'll admit, but it teaches a great skill.
When I first downloaded the JDK 1.0 in November '95, I perused their source code. What an eye-opener! I no longer care where you put your curly braces. Just get the indentation right. I think this rule of thumb is pretty good: if you care where the curly braces go, you haven't read enough code.
3. Learn your tools.
All the features you think you'll ever need. For example, if you think you'll ever be telnetted into a Unix box, wanting to edit a file, learn the basic commands of vi. Okay?
But don't shortchange your toolbox. A good carpenter can get by on a hammer and saw, but no good carpenter would really want to. Don't just learn vi.
4. Practice symbol naming and renaming.
You can really reduce code clarity by misnaming something slightly. Worse, programmers tend to do it too quickly, because every symbol you stop to name is a little speed bump.
Be painfully aware that you can never get it exactly right. If it were possible to express every concept in 40 characters or less, mixed case, no punctuation, then Wiki pages could get by with just titles. Do add comments when you fail to come up with a good name.
Hopefully refactoring browsers will become ubiquitous enough that renaming symbols to more appropriate names will be much easier in the future.
5. Play games that enhance the mental skills that you use during programming.
(I probably should take a little of my own advice here, because I can't think of any way that playing Quake3 helps me program better.)
However, I find that:
6. Read! Read! Read!
Authors often have years of experience to share, that they acquired at great cost. And you can get chunks of their hard-earned knowledge in a fraction of the time at a fraction of the cost! What a deal! Are you going to rely on just your own experience, as so many programmers do? If you're on the Wiki reading this page, this is probably preaching to the choir. But... ask your coworkers what they read for self-improvement. If they don't (don't be surprised) just make some suggestions.
7. Social skills can come in handy, even to a lowly coder.
Now, I don't advocate getting all political, at least not without being all ethical. But a well-honed ability to listen and see other peoples' points of view, and an ability to be polite and tactful, will make your life easier. Sometimes I think that some of the developers I've met went into computer science because they figured, "Hmm, what career can I follow where I can succeed by my cleverness alone, and my lack of people skills won't matter a bit?" Sorry, it's probably easier to just pick up some social skills.
8. Reflect.
This industry focuses on the how's, not the why's, and I think many people just stop asking why, and do not develop a deep understanding of software topics. I've been to 2 XPUniverse conferences now, and it seems to me that one thing that separates the gurus from those who are merely very good at their jobs is that the gurus reflect on what they've done. Take some time and reflect -- per day, per week, per iteration, per project.
That's just the basics....
One more word of advice: If you're laid off, SharpenTheSaw. If you're not laid off, SharpenTheSaw as much as you can.
EditText of this page
(last edited December 21, 2014)
or FindPage with title or text search