😮 You looked at the source!

Dimitris Zorbas

Code spells, smells and sourcery

About

100 Things a Software Architect Should Know

#abstract #programming

A very short list of things a software architect should know:

  1. The zeros
  2. The nils
  3. The ones
  4. The undefineds
  5. The infinity
  6. car and cdr
  7. Smells
  8. Echoes
  9. Roundtrips
  10. Daylight Savings
  11. Latencies
  12. Varieties of coffee
  13. Stockhausen
  14. How to authenticate
  15. How to authorise
  16. How to memoize
  17. Talk to ducks
  18. Write in Braille
  19. Admire hexagons
  20. Numbers > 41 and < 43
  21. Rigorous negotiations
  22. Remember that hope is not a strategy
  23. Carpal Tunnel Syndrome
  24. Prime factorisation
  25. Be polite to your users
  26. Be thankful to contributors
  27. The aesthetics of OpenBSD release songs
  28. What it means to be code complete
  29. Code is never completed
  30. The law of diminishing returns
  31. It really, doesn’t have to be crazy at work
  32. It’s not urgent because someone says so
  33. Not all operations can be reversed
  34. Be curious what the user thinks and feels
  35. Optimising safely
  36. How to sort and shuffle stuff
  37. Deploy - then forget - is not neglect
  38. Build systems, not apps
  39. Poetry is literate programming for human emotions
  40. Write user stories
  41. Unblock others
  42. Mentor the willing
  43. Practice open-source as much as recycling
  44. Be patient
  45. Store stuff in the most appropriate medium
  46. Send stuff over the most appropriate network protocol
  47. When code is fuel
  48. When code is mortar
  49. When code is brick
  50. Not everything is an object
  51. Talk to actors
  52. Try to solve the right problem
  53. Which problems can be solved by humans
  54. Which problems can be solved by computers
  55. Who Jeff Dean is and how he would solve your problem
  56. Code, leads to more code, not solutions
  57. To talk about killing children, discreetly in public
  58. Identify big stones
  59. Get plenty of rest
  60. Relays
  61. Be alarmed for 0days
  62. Plan capacity
  63. Prepare for disaster
  64. See the topologies in the starry night sky
  65. How does the user feel when the code is right
  66. Remember that Lego™️ is made from plastic
  67. How to draw shapes on a board
  68. How to tell if your colleague is struggling from burn out
  69. You also need timeouts
  70. Trust people to deliver based on their capabilities, not titles
  71. Listen to static
  72. Provide meaningful documentation for your software and systems
  73. Collect sea shells
  74. How to get rid of dust
  75. When to look for the shortest path
  76. How create a plan for more than 10 people to follow
  77. Text editor modes
  78. How to onboard a user to a journey
  79. New and shiny doesn’t mean useful
  80. Mentally filter noise
  81. Pick cherries
  82. Some lakes are made of data
  83. Identify the cathedrals and the bazaars in social groups
  84. The difference between an aquarium and the open sea
  85. Rowing, shipwrecks and coredumps
  86. Give up on dead projects
  87. The importance of workspace ergonomics
  88. Digest everflowing symmetries through numbers and words
  89. Treat the <body> with as much respect as the <head>
  90. Avoid dividing by zero, even if you’re a small practical horse
  91. Many different types of hashes
  92. Pomodoro is not just a sauce
  93. Avoid using the work “just”
  94. How to identify a GNU at the zoo
  95. Notice turnstiles and be curious about traffic signalling and flow
  96. When to benchmark
  97. When to test
  98. When to cheat
  99. To not trust clocks
  100. Identify system boundaries

Inspired by Michael Sorkin’s - 250 things an architect should know.