wandercoding.com

I just returned from a trip to Memphis to visit friends. We spent the first few days downtown at an excellent hotel, the Talbot Heirs Guesthouse. Downtown Memphis is very walkable and if you don’t feel like walking you can just take the Main Street Trolley. The people were friendly and accomodating just about everywhere we went.

The interesting thing about the town is that it has been up and down. At one time, downtown was vibrant, but underwent a decline beginning in the 1970s. There are numerous empty store fronts, deserted blocks, and panhandlers roaming the streets. But, there are many historic and beautiful buildings. There are rental properties advertising condominiums. And there are some fantastic restaurants. The famous Beale Street, home of the blues, is right downtown, along with the Gibson guitar factory, an NBA stadium, and a minor league baseball stadium.

Now, the question is: if you build it, will they come? There’s little difference between this and software. If you build a website, will people visit? Will you make money actually selling something or by advertising on your site? If you build software, will people buy it? How will you market it? Will you pay to advertise on web sites, in magazines, or at trade shows? Like anything else, things take time. Patience is important, but so is constant action to improve the likelihood of success. And once success has been achieved, never stop trying to improve. The competition will always be after you. Don’t have any competition? If you’re successful and have proven that there’s a market for what you’re doing, the competition will come.

I like reading other software blogs as much as writing my own. My big advantage so far, is that I don’t tell people how to write code (yet). Why is this an advantage? Because, so far, I’ve managed to avoid the wrath of the Perfect Programmer.

Who is the Perfect Programmer? He’s (or she’s) the one who responds to the blog posts with things like: Don’t let Jeff Atwood Lead Your Web Project or corrects silly bits of code on code postings, where the correctness of the code example doesn’t matter because it’s only for illustrative purposes.

Fortunately, in my career, I’ve only run into a few perfect programmers, who have commented on my code without tact. My code is far from perfect (even perfect programmers write crappy code), but most people who have commented on it have at least done so constructively. This brings us to my real point for this post.

Criticism is a dish best served warm (as opposed to revenge, which we all know should be served cold – it must taste like gazpacho). I’ve found it best to approach someone in a more questioning manner, asking someone to explain what they were trying to do first. After all, is it possible that you misunderstood the intent of the code or the design?

In a previous life, I worked with a guy who was a good coder, but could be a bit on the testy side. He had added a new feature to the API that was very useful, but would be difficult for users to interact with. A couple of people told him so and he became very frustrated with the criticism and insisted that it was perfect as is. I was asked to talk to him, so I went over to his desk and asked him to show me the new functionality. He told me about it and showed me the code that a user would have to write. There was one piece of information the user would have to supply that wasn’t obvious to me, and therefore users as well. I simply asked him to tell me about what the user would have to do to get this piece of information. Once he started to explain it, he stopped in mid-sentence. He said, “I can see how I can make this whole thing much simpler,” and he did. He changed the code and it was very clear and much simpler than the original. I had gotten him to criticize his own code.

Along the same lines, this is one reason why I always write comments and documentation on my classes. I find that once I start trying to explain what the code is supposed to do that I find out how convoluted I may have made it. Try thinking like a user when you design something. Try thinking like your colleague when you have an issue with their code. You’ll find that people will learn to trust you and accept suggestions more readily without getting defensive.

I’m not sure exactly when this started, but my recollection is that it began spreading in the late 1980’s. What am I talking about? I’m talking about a scourge that spread so quickly and has become so prevalent that it is practically inescapable in today’s world. I’m talking about redundant-speak.

It started small. People in meetings started saying things like “continue on” when continue would have done just fine. Then other people who presumably didn’t want to be left out must have come to the realization that they weren’t being clear enough if they didn’t say things twice in the same sentence. Memos suddenly needed to be “distributed around” and “circulated around”, when distributing or circulating them would have been sufficient.

With the price of words skyrocketing, it should be clear that we need to decrease down the amount of redundant speak (did you catch the one in this sentence?). Okay, so words aren’t really getting more expensive, but there’s still no need for the prevalence of this kind of talk. Communicating clearly and effectively isn’t difficult. Removing modifier words isn’t difficult, either. The first step is recognizing that there’s a redundancy in the first place. Next time you listen to someone speak, listen for a two word combination that describes one thing. If the description tells you two different things, then it’s fine. However, if the second word, or sometimes a supporting phrase, doesn’t add anything, then it’s redundant.

Once you recognize this kind of speech and writing, you can examine your own. Once you start removing the redundancies, your communication will be clearer and more direct. Try not to revert back to your previous behavior (did you catch “revert back” when “revert” will do?). Help remove redundant speak from the world until it’s totally abolished.

For a nice list of redundancies, check out: http://kcweb.nhmccd.edu/employee/jsamuels/redund.htm