Skip to content

Instantly share code, notes, and snippets.

@RasPhilCo
Last active May 16, 2016 17:49
Show Gist options
  • Save RasPhilCo/1b29837de1d8add7cf2143fcc9fb3997 to your computer and use it in GitHub Desktop.
Save RasPhilCo/1b29837de1d8add7cf2143fcc9fb3997 to your computer and use it in GitHub Desktop.

Larry Wall, Three Virtues --

There are three great virtues of a programmer:

  1. Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.
  2. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.
  3. Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.

Sandi Metz, Ruby Rouges podcast --

Four rules for developers:

  1. Classes can be no longer than one hundred lines of code.
  2. Methods can be no longer than five lines of code.
  3. Pass no more than four parameters into a method. Hash options are parameters.
  4. Controllers can instantiate only one object. Therefore, views can only know about one instance variable and views should only send messages to that object (@object.collaborator.value is not allowed).

“You should break these rules only if you have a good reason or your pair lets you.”

Avdi Grimm, Confident Ruby --

Four parts of a method:

  1. Collecting input
  2. Performing work
  3. Delivering output
  4. Handling failures

(There are two other categories that sometimes appear: "diagnostics", and "cleanup". But these are less common.)

Doug McIlroy, quoted in 'A Quarter Century of Unix' --

The Unix philosophy:

  1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
  2. Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
  3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
  4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment