Coding Horror

One of the quickest ways to increase your productivity on the computer is to go commando: stop using the mouse. When you stop relying on the mouse for everything, you're forced to learn the keyboard shortcuts. Jeremy Miller calls this the first step to coding faster. I agree.

Keyboard shortcuts are almost always more efficient than using the mouse to point and click your way around the computer – but you'll never learn them if you keep leaning on your trusty mouse to do all the work. Stop for a moment, resist taking the easy way out with the mouse, and force yourself to learn at least one new keyboard shortcut per day. Yes, it's a tiny bit of extra work. But it will pay off down the road: you'll spend less time mousing around, and more time getting things done.

I'm not anti-mouse by any means. I remember when mice were new; I'd never want to go back to the bad old days of keyboard-only interfaces. But most people I've observed using the computer these days rely almost exclusively on the mouse, to the detriment of their overall computer experience. Here are a few examples of how even the simplest keyboard shortcuts can make your daily routine easier:

1. Logging in with the keyboard, using Tab and Enter
2. Going to a website using Alt+D and Ctrl+Enter
3. Searching using Ctrl+E then Enter
4. Editing text and moving your cursor with basic textbox shortcuts

That's just the tip of the iceberg. Most applications have tons of useful keyboard shortcuts; you just have to put down your mouse long enough to discover a few of them. It's a shame more applications don't go out of their way to make keyboard shortcuts more discoverable. At the very least, I'd like to see Office 2007 type behavior where, as you press the keyboard accelerator key, all the possible keyboard shortcuts "light up".

Unfortunately, navigating through websites is nearly impossible without a mouse, due to the highly mouse-centric nature of HTML. I've given up on trying. But it is possible, if you're a die-hard. Unless you enjoy pressing the tab key umpteen million times, you'll definitely want to check out Jon Galloway's mouseless computing recommendations, wherein he conquers the HTML keyboard challenge.

For best computing results, try to use your mouse and your keyboard to the fullest. But to do that, you've got to actively wean yourself off the mouse. Try going commando every now and then. It will be awkward and painful at first. You'll be sorely tempted to switch back to your old faithful mouse to get things done. Resist this urge! I guarantee whatever you're trying to do is possible – and ultimately quicker – if you persist with the keyboard.

Alex Papadimoulis originally invited me to be a guest editor at The Daily WTF nearly six months ago. I was honored and accepted immediately. Since then, The Daily WTF has been rechristened Worse Than Failure.

I'm a big fan of Alex and WTF; his blog is fantastic, and WTF went from being a brilliant, hilarious germ of an idea to a staple of many developer's daily reading lists.

It's ironic, then, that what I wrote ended up being a direct criticism of The Daily WTF. It's almost like I've fallen into the Spolsky rut; invite me to speak at your big important Java conference, and I'll create a session that tells you why you're all idiots for using Java. Or, perhaps I was channeling Groucho Marx. One of his most famous jokes goes something like this: I sent the club a wire stating, please accept my resignation. I don't want to belong to any club that will accept me as a member.

I give Alex tremendous credit for finally posting my entry, even though it never quite fit the WTF format. I hope it doesn't feel too much like a public service announcement, but it's something I absolutely had to get off my chest. It's a topic Dennis Forbes has struggled with as well:

This is a repeating theme: On the one side are the great programmers, and on the other are the people endlessly bound to give TheDailyWTF source material.

Do people really think such a schism exists? Is the impression that great developers are infallible, never creating any bad code at all, ever? Are bad programmers just stumbling from one WTF to another?

Of course not.

I fear the output of any developer who claimed that they've never written bad code. I would fear them because they're either bald-faced liars – believing that simply saying it repeatedly will somehow convince others into this fiction – or they're completely blind to their own weaknesses.

Every developer in the real world has had bad days, brain faults, or bad interpretations of new languages, environments or libraries. It's simply a given of the profession.

I have no problem at all with the entertainment value of WTF. Laughing at Rube Goldberg code is therapeutic, even educational. But whether the code in question is catastrophically stupid or just plain ill-advised, we have to do something about it. Until we do, we are implicitly perpetuating the painful, costly cycle of bad coders writing bad code, ad infinitum. And that hurts all of us.

Reprogramming WTF code isn't enough. We need to reprogram the developers producing the WTF code. With my guest article, I was trying to inspire readers to take on the burden of reprogramming bad developers, rather than passively waiting for the bad developers to come to their senses on their own. That strategy never works.

I can absolutely guarantee that the kinds of developers who could benefit most from reading WTF simply do not – and never will – read the WTF website. Individually, personally, we have to do more to reach out to these developers: mentoring, apprenticeship, user groups, peer pressure, code reviews, etcetera. Do whatever you can, whatever makes sense to you, but do something. Pitch in so the next poor sap won't have to deal with WTF code, or at the very least, can benefit from slightly less crazy WTF code in the future.

I know it's asking a lot. It's tempting to get your daily fix of drive-by amusement and move on. But I believe it's our collective duty to leave the profession of software engineering better than we found it. There's so much we can do, and WTF is merely a starting point.

A few recent articles have highlighted the disproportionate contribution Playstation 3 consoles are making to the Folding@Home effort. The OS statistics page for Folding@Home tells the tale:

There are a couple caveats to bear in mind when reading this chart:

1. The measurement of FLOPS isn't an exact science. It would be more accurate to compare actual work units returned, but I don't see any way to do that from the folding statistics page.
2. Current PC and Mac / PPC contributors span the entire gamut of CPUs released in the last seven years.
3. Folding does cost money, in the form of electricity. Superior clients offer efficiency: bang per watt. You could make a compelling argument that certain clients with low efficiency aren't worth the cost of the electricity they're using. For reference, a PS3 and a gaming-class PC both use about 200 watts of power under load.

The Playstation 3 is indeed dominating the charts; as of this writing, the PS3 is responsible for a whopping 72 percent of the computing power in the entire Folding@Home project.

UPDATE: as of 3/26/2007, the F@H network has arbitrarily halved the TFLOPS score for the PS3.

It's only a matter of time-- a few weeks at most-- before the PS3 constitutes more than 95 percent of the computing power in the entire Folding@Home network. This doesn't surprise me in the least. The Playstation 3 can harness the considerable power of its specialized Cell CPU to crunch work units far more efficiently than any general purpose CPU ever could.

If you look closely at the chart, you'll see even more powerful evidence of the dominance of specialized processors.

GPU clients run on modern, high-end video cards. The GPU on these video cards is even more specialized than the Cell processor in the PS3.

The GPU client is limited to the current high-end ATI X1800 and X1900 video cards at the moment, which are already a generation behind NVIDIA's newest 8800 series. Even so, the GPU clients are almost 2.5 times faster than the PS3. Of course, this performance differential is more than balanced by the fact that PS3 is an easily obtainible (albeit somewhat expensive) consumer item; it's trivially easy to add one to the Folding@Home network, whereas the Folding@Home GPU client is quite immature, and few users have the necessary high-end ATI video cards to use it.

But the real lesson of this chart lies in the OS X / Intel data point. Intel-based Macs are, by definition, based on only the newest Intel processors-- Core Duo or better. Even so, it's an utter blowout:

With these kinds of performance ratios-- and I expect the performance gap to widen every year-- there's almost no point in adding general purpose CPUs to the folding network any more. It's a waste of time, effort, and electricity.

For folding and other distributed computing efforts, it's the death of the general purpose CPU as we know it.

Presented, in no particular order, for your reading pleasure: my top 6 list of programming top 10 lists. To keep this entry concise, I've only quoted a brief summary of each item. If any of these sound interesting to you, I encourage you to click through and read the original author's thoughts in more detail.

Jerry Weinberg: The 10 Commandments of Egoless Programming

1. Understand and accept that you will make mistakes.
2. You are not your code.
3. No matter how much "karate" you know, someone else will always know more.
4. Don't rewrite code without consultation.
5. Treat people who know less than you with respect, deference, and patience.
6. The only constant in the world is change.
7. The only true authority stems from knowledge, not from position.
8. Fight for what you believe, but gracefully accept defeat.
9. Don't be "the guy in the room."
10. Critique code instead of people -- be kind to the coder, not to the code.

Dare Obasanjo: Top 10 Signs Your Software Project is Doomed

1. Trying to do too much in the first version.
2. Taking a major dependency on unproven technology.
3. Competing with an existing internal project that is either a cash cow or has powerful backers.
4. The team is understaffed.
5. "Complex problems require complex solutions".
6. Schedule Chicken
7. Scope Creep
8. Second System Syndrome
9. No Entrance Strategy.
10. Tackling a problem you don't know how to solve.

Omar Shahine: Top 10 Tips for Working at Microsoft (or Anywhere Else)

1. Process is no substitute for thinking.
2. Get out of your office.
3. Use your product (the one your customers will).
4. Fix things that are broken rather than complain about them being broken. Actions speak better than your complaining.
5. Make hard problem look easy. Don't make easy problems look hard.
6. Use the right communication tool for the job.
7. Learn to make mistakes.
8. Keep things simple.
9. Add value all the time.
10. Use their product.

Michael McDonough: The Top 10 Things They Never Taught Me in Design School

1. Talent is one-third of the success equation.
2. 95 percent of any creative profession is shit work.
3. If everything is equally important, then nothing is very important.
4. Don't over-think a problem.
5. Start with what you know; then remove the unknowns.
6. Don't forget your goal.
7. When you throw your weight around, you usually fall off balance.
8. The road to hell is paved with good intentions; or, no good deed goes unpunished.
9. It all comes down to output.
10. The rest of the world counts.

Andres Taylor: Top 10 Things Ten Years of Professional Software Development Has Taught Me

1. Object orientation is much harder than you think.
2. The difficult part of software development is communication.
3. Learn to say no.
4. If everything is equally important, then nothing is important.
5. Don't over-think a problem.
6. Dive really deep into something, but don't get hung up.
7. Learn about the other parts of the software development machine.
8. Your colleagues are your best teachers.
9. It all comes down to working software.
10. Some people are assholes.

Steve Yegge: 10 Great Books

1. The Pragmatic Programmer: From Journeyman to Master
2. Refactoring: Improving the Design of Existing Code
3. Design Patterns
4. Concurrent Programming in Java(TM): Design Principles and Pattern (2nd Edition)
5. Mastering Regular Expressions, 2nd Edition
6. The Algorithm Design Manual
7. The C Programming Language, Second Edition
8. The Little Schemer
9. Compilers
10. WikiWikiWeb

You may wonder why I included a top 10 list from someone who is clearly a designer and not a programmer. I agree with Joey deVilla:

Software development is a kissing cousin of engineering (if not an engineering discipline itself), and blends creativity with math and science. That's why I find that a lot of advice to creative types is also applicable to software developers.

You may also want to contrast and compare my recommended reading list with Steve Yegge's. And yes, there is a reason Refactoring and Design Patterns aren't on my list, just as I'm sure there's a reason Code Complete is not on Steve's list.

I've seen a lot of painfully bad IT web comics in my day, but I'm happy to say that Bug Bash, by Hans Bjordahl, is not one of them.

This particular strip is one of my favorites because it hits so close to home. Software developers truly believe, in their heart of hearts, that they are typical users. Be sure to check out the sequel strip, How Good Software Goes Bad, Part II, and while you're at it, the rest of the bug bash archives.