Hack hack hack...

An open journal-- some of it written for you, but most of it is for me.

Lessons From 97 Things Every Programmer Should Know

The boy scout rule (p.16)

  • “Always leave a campground cleaner than you found it.”
    • “Always check in a module a little cleaner than when you checked it out.”

Don’t repeat yourself (p.60)

  • Duplication is waste

  • Repetition in process calls for automation

  • Repetition in logic calls for abstraction

  • A matter of principle: once and only once principle

Know your next commit (p.94)

  • Understanding your commit in the greater user story scope is valuable, but stay focused on your specific goal.

  • Define a task that would constitute a productive step.

Learn to estimate (p.100)

  • An estimate is an approximate calculation or judgment of the value, number, quantity, or extent of something.

  • A target is a statement of a desirable business objective.

  • A commitment is a promise to deliver specified functionality as a certain level of quality by a certain date or event.

Make interfaces easy to use correctly and hard to use incorrectly (p.110)

  • A.K.A. defensive design

  • Making interfaces hard to use incorrectly requires two things: first, you must anticipate errors users might make and find ways to prevent them. Second, you must observe how an interface is misused during early release and modify it to prevent such errors.

Missing opportunities for polymorphism (p.118)

  • Polymorphism, taken from Greek, means many (poly) forms (morph). In the context of programming, polymorphism refers to many forms of a particular class of objects or method.

The professional programmer (p.134)

  • pros are responsible for their own career

  • pros take responsibility for the code they write

  • pros are team players

  • pros do not tolerate big bug lists

  • pros do not make a mess.

Put down the mouse and step away from the keyboard (p.138)

  • Focus is good, but to get through a problem we often have to walk away from the problem.

  • While you are coding, the logical part of the brain is active and the creative side is shut out. It can’t present anything to you until the logical side takes a break.

Read code (p.140)

  • Write code so that it is readable for others. Read other people’s code.

Read the humanities (p.142)

  • Coding is about communicating with others through experience. Understand metaphors and how to express your thoughts to others in terms they can understand.

Resist the temptation of the singleton pattern (p.146)

  • the singleton pattern is a design pattern that restricts the instantiation of a class to one object.

The single responsibility principle (p.152)

  • Gather together things that change for the same reason, and separate those things that change for different reasons.

  • Good system design means that we separate the system into components that can be independently deployed. Independent deployment means that if we change one component, we do not have to redeploy any of the others.

Two heads are better than one (p.170)

  • Pair programming is more productive for learning and long term enjoyment of the profession.

Ubuntu coding for your friends (p.174)

  • “A person is a person through (other) persons.”

  • So it follows, “a developer is a developer through other developers.”

  • “Code is code through other code.”

  • The quality of the code I write affects the quality of the code you write.

  • Zen is about the individual. Ubuntu is about the Zen a group of people. Very, very rarely do we create code for ourselves alone.

Unix tools > IDEs (p.176)

WET dilutes performance bottlenecks (p.182)

  • WET (write every time) the antithesis of DRY

Write code as if you had to support it for the rest of your life (p.186)

  • The code your wrote many years ago still influences your career. People form opinions of you based on the code they see.

Write tests for people (p.190)

  • Good tests act as documentation for the code they are testing.

You gotta care about the code (p.192)

  • The difference between good and bad programmers is attitude.

  • The code to hell is paved with good intentions. To be an excellent programmer, you need to rise above good intentions, and actually care about the code.