All Stories published by Programming Philosophy on January 04, 2016
01
02
03
06
07
08
09
10
11
12
13
14
15
17
18
19
20
22
23
24
25
26
27
28
29
30
31

Eric Raymond’s 17 Unix Rules

I was re-reading The Art of Unix Programming and re-discovered some great ideas. Sharing with you:
 
 Rule of Modularity
 
 Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced…


Simplicity, Clarity, Generality

From the introduction to The Practice of Programming by Brian W. Kernighan and Rob Pike

Have you ever…
 
 wasted a lot of time coding the wrong algorithm?
 used a data structure that was too complicated?
 tested a program but missed an obvious…

Reactive Manifesto by Jonas Bonér

Prior issues have focused on some very old philosophies. Here is a brand new one:
 
 From the Reactive Manifesto
by Jonas Bonér
 
 Reactive Systems are:
 
 Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of…


21 Rules of Thumb for Shipping Great Software on Time

Roy reminded me of this great article this week. It’s long, but has some great content. If you want to get the bonus 2 and 1/2 rules, you can watch the video: 
 
 
 21 Rules of Thumb for Shipping Great Software on Time
 
 Jim McCarthy…


Engineering Culture at Facebook

This is a great post by Pierre Raynaud-Richard at Facebook about their Engineering Culture; specifically Code Ownership. There are a lot of important ideas in here and I encourage you to read it thoroughly.
 
 Here’s one of my favorite sections:
 
 The culture of the “code…


The Three Virtues

From http://threevirtues.com/
 
 According to Larry Wall, the original author of the Perl programming language, there are three great virtues of a programmer; Laziness, Impatience and Hubris
 
 Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes…


A Problem Solver’s Perspective

From Programming Pearls, 2nd Edition:

Good programmers are a little bit lazy: they sit back and wait for an insight rather than rushing forward with their first idea. That must, of course, be balanced with the initiative to code at the proper time