These "maxims that every programmer should follow" come from Paradigms of Artificial Intelligence by Norvig:

  • use abstractions
  • be concise
  • use the provided tools
  • be clear
  • be consistent

Design principles from Programming Pearls by Jon Bentley:

  • work on the right problem
  • explore the design space of solutions
  • look at the data
  • use the back of the envelope
  • build prototypes
  • make trade-offs when you have to
  • keep it simple

Characteristics of good APIs from The Little Manual of API Design (pdf):

  • easy to learn and memorize
  • lead to readable code
  • hard to misuse
  • easy to extend
  • complete

The Unix philosophy as characterized by Mike Gancarz:

  • small is beautiful
  • make each program do one thing well
  • build a prototype as soon as possible
  • choose portability over efficiency
  • store data in flat text files
  • use software leverage to your advantage: i.e. composability and re-usability
  • use shell scripts
  • avoid captive user interfaces
  • make each program a filter

The causes of complexity per Out of the Tar Pit (pdf):

  • complexity breeds complexity: unencapsulated complexity makes client code complex
  • simplicity is hard: the simple solution is often not the first solution found
  • power corrupts: a complicated feature will be used when not needed

The Twelve-Factor App by Adam Wiggins:

  • one codebase tracked in revision control, many deploys
  • explicitly declare and isolate dependencies
  • store config in the environment
  • treat backing services as attached resources
  • strictly separate build and run stages
  • execute the app as one or more stateless processes
  • export services via port binding
  • scale out via the process model
  • maximize robustness with fast startup and graceful shutdown
  • keep development, staging, and production as similar as possible
  • treat logs as event streams
  • run admin/management tasks as one-off processes

Secure design rules from a five minute talk by Allen Short:

  • assume all input is an attack
  • the smaller the interface, the smaller the attack surface
  • the less code knows about, the less it can break: c.f. principle of least knowledge

Ten rules for safety critical C code by Gerard Holzmann:

  • no goto, setjmp, longjmp, or recursion
  • all loops must have fixed upper bound on number of iterations
  • no dynamic memory allocation after initialization
  • no more than 60 lines of code per function
  • average of 2 assertions per function
  • declare variables at smallest possible scope
  • functions must validate parameters; callers must check non-void return value
  • limit preprocessor to header includes and simple substitutions; substitutions must be syntactically complete; no token pasting {{##}}, variable number of arguments {{..., or recursive macro calls. Minimize use of conditional compilation.
  • no more than one level of dereferencing of pointers; do not hide pointer dereferencing with typedef or macros; no function pointers.
  • compile code from start of project with most strict setting and fix all warnings; use a state-of-the-art static analyzer daily

Numbers every computer engineer should know according to Jeff Dean:

  • L1 cache reference: 0.5ns: typical L1 cache size: 64k
  • branch mispredict: 5ns
  • L2 cache reference: 7ns: newer chips have L2 and L3 cache; sizes from 256k to 8M
  • mutex lock/unlock: 100ns
  • memory reference: 100ns
  • compress 1K bytes with Zippy: 10μs: gzip?
  • send 2K bytes over 1 Gbps network: 20μs
  • read 1 Mb sequentially from memory: 250μs
  • round trip within datacenter: 500μs
  • disk seek: 10ms 0.1ms for SSDs
  • read 1 Mb sequentially from network: 10ms
  • read 1 Mb sequentially from disk: 30ms: 6ms - 30ms for SSDs?
  • send packet CA->Netherlands->CA: 150ms

Rob Ewaschuk's Philosophy on Alerting:

  • alerts should be urgent, important, and actionable; demote issues which don't meet these criteria to daily or less frequent reports
  • alerts should detect symptoms end users care about; monitoring of potential causes should go into dashboards
  • alerts should verify availability, latency, and correctness
  • alerts should be tracked in a workflow system

Fog Creek on how to estimate software tasks:

  • design what will be built
  • break the project down into small tasks
  • have the person who will execute the task estimate the time it will take
  • allow time for interruptions
  • log development time and unanticipated tasks to inform future estimates

The principles of Lean Software Development:

  • eliminate waste
  • amplify learning: favor short development iterations; collect feedback after each iteration to inform the next
  • decide as late as possible
  • deliver as fast as possible
  • empower the team
  • build integrity in: use the customer to measure value; build components which work well together and can be re-used for other applications in the problem domain
  • see the whole

Talents of great managers as identified by Beck and Harter:

  • motivate all employees to take action; engage them with a compelling mission and vision
  • have assertiveness to drive outcomes and ability to overcome adversity and resistance
  • create culture of clear accountability
  • build relationships that create trust, open dialogue, and full transparency
  • make decisions based on productivity, not politics

The seven processes of The Rock Warrior's Way:

  • become self aware
  • see subtlety
  • accept responsibility
  • ask what you can give
  • commit with unbending intent
  • adopt a listening mindset
  • life is a journey, not a destination

Four principles from The Non-Designer's Design Book:

  • contrast: if they aren't the same, make them very different
  • repetition: reuse some aspect of the design throughout the entire work
  • alignment: nothing should be placed arbitrarily
  • proximity: items relating to each other should go together

Brutalist Web Design:

  • content is readable on all reasonable screens and devices
  • only hyperlinks and buttons respond to clicks
  • hyperlinks are underlined and buttons look like buttons
  • the back button works as expected
  • view content by scrolling
  • decoration when needed and no unrelated content

From the Joint Committee on Standards for Graphic Presentation:

  • arrange values so they increase from left to right or bottom to top; arrange time values so later dates are to the right of earlier dates
  • represent quantities with lengths instead of area or volume
  • include a zero line in the scale; use a horizontal break in the graph if necessary
  • for ratio measurements, emphasize the zero line; emphasize the 100 line when using percentages; do not emphasize first or last date line
  • when using logarithmic scale, first and last line should be a power of ten, assuming that is the base
  • use as few coordinate lines as possible, and make data lines distinct
  • give a complete title, and if necessary a subtitle
  • consider emphasizing the points representing the observations with a graphical symbol such as an X
  • if observations are at regular intervals, consider label the top side of the x-axis with the y-values
  • vertical tic values should be readable from below; horizontal tic values should be readable from the right
  • consider including the observation values in a table

Design Better Data Tables by Matthew Ström:

  • use lining figures instead of oldstyle figures. The latter have ascenders and descenders.
  • for better alignment, use tabular figures instead of proportional figures. If tabular figures are not available, use a monospace font.
  • right-align numbers. Left align-text. Align headers the same way as their data.
  • for better alignment, use the same number of digits for the fractional part of numbers
  • provide a title
  • make headers as short as possible
  • provide units in the first row and omit from subsequent rows

Amy Lowell's Rules of Imagism:

  • use the language of common speech
  • create new rhythms
  • allow free choice of subject
  • present an image
  • be hard and clear, never blurred or indefinite
  • concentration is the essence of poetry

The hacker ethic according to Steven Levy:

  • sharing
  • openness
  • decentralization
  • free access to computers
  • world improvement