Friday, March 12, 2010

Quotes from 97 Things Every Programmer Should Know

I thought it would be a collection of super-duper, mega wise unpalatable truth, but in reality it was the set of truisms, cliches and platitudes. In brief, I'm disappointed. There of course exists some interesting advices (<20), mostly applicable for very young developers.

Here are examples of the most useful:

Giles Colborne

When you get stuck, you look around. When users get stuck, they narrow their focus. [...] It becomes harder for them to see solutions elsewhere on the screen. It's one reason why help text is a poor solution to poor user interface design. If you must have instructions or help text, make sure to locate it right next to your problem areas. A user's narrow focus of attention is why tool tips are more useful than help menus.

[...] Spending an hour watching users is more informative than spending a day guessing what they want.

Filip van Laenen

  • Make sure code formatting is part of the build process, so that everybody runs it automatically every time they compile the code.
  • Use static code analysis tools to scan the code for unwanted antipatterns. If any are found, break the build.

Rajith Attapattu

Many incremental changes are better than one massive change. [...] It is no fun to see a hundred test failures after you make a change. This can lead to frustration and pressure that can in turn result in bad decisions. A couple of test failures at a time is easier to deal with, leading to a more manageable approach.

Mattias Karlsson

Be gentle during code reviews. Ensure that comments are constructive, not caustic.

[...] Code reviews will flow more easily if the team has coding conventions that are checked by tools. That way, code formatting will never be discussed during the code review meeting.

Jon Jagger

Deliberate practice means repetition. It means performing the task with the aim of increasing your mastery of one or more aspects of the task. It means repeating the repetition.

[...] Ask yourself, how much of your time do you spend developing someone else's product? How much developing yourself?

[...] Deliberate practice is about learning--learning that changes you, learning that changes your behavior.

Mike Lewis

Don't be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the lifecycle of your project.

Alan Griffiths

[...] the hard part [of the programming]--the thinking--is the least visible and least appreciated by the uninitiated.

Johannes Brodwall

When I start a new project from scratch, there are no [compiler] warnings, no clutter, no problems. But as the codebase grows, if I don't pay attention, the clutter, the cruft, the warnings, and the problems can start piling up. [...] If I leave the warnings, someone else will have to wade through what is relevant and what is not. Or more likely, that person will just ignore all the warnings, including the significant ones.

Warnings from your build are useful. You just need to get rid of the noise to start noticing them.

Dan Bergh Johnsson

Know your next commit. If you cannot finish, throw away your changes, then define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. Do not commit guesswork into your repository.

Daniel Lindner

You need to give your project a voice. [...] The idea of XFDs [Extreme Feedback Device] is to drive a physical device such as a lamp, a portable fountain, a toy robot, or even a USB rocket launcher, based on the results of the automatic analysis. Whenever your limits are broken, the device alters its state. In case of a lamp, it will light up, bright and obvious. You can't miss the message even if you're hurrying out the door to get home.

Jon Jagger

Lack of visible progress is synonymous with lack of progress. [...] It's best to develop software with plenty of regular visible evidence. Visibility gives confidence that progress is genuine and not an illusion, deliberate and not unintentional, repeatable and not accidental.

Linda Rising

[...] in all the years I've taught and worked side by side with programmers, it seems that most of them thought that since the problems they were struggling with were difficult, the solutions should be just as difficult for everyone.

Giles Colborne

Another way of avoiding formatting errors is to offer cues--for instance, with a label within the field showing the desired format ("DD/MM/YYYY").

[...] Cues are different from instructions: cues tend to be hints; instructions are verbose. Cues occur at the point of interaction; instructions appear before the point of interaction. Cues provide context; instructions dictate use. In general, instructions are ineffective at preventing error.

Uncle Bob

A professional programmer does not pass that responsibility off on others.

[Professionals] take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right.

Alex Miller

When I was first placed in a technical leadership role, I felt that my job was to protect my beautiful software from the ridiculous stream of demands coming from product managers and business analysts. I started most conversations seeing a request as something to defeat, not something to grant.

At some point, I had an epiphany that maybe there was a different way to work that merely involved shifting my perspective from starting at no to starting at yes. In fact, I've come to believe that starting from yes is actually an essential part of being a technical leader.

1 comment:

  1. Alexander

    I do envy you, who is obviously surrounded by excellent colleagues. My unfortunate experience is that even pretty senior developer I have worked with do not follow even half of the 97 truisms. Well, they might claim (when asked) they know them, but they do definitely not practice them, especially not in tough projects - when they are most needed.

    I am glad though that you found one of my pieces worthy of mentioning. Thanks

    Dan Bergh Johnsson