Pezely's
Posits

Observations spanning nearly thirty years in the software business—
a blending of computer science, psychology and philosophy

  1. Conceptually, add or change only one thing at a time in a release, else confuse your customers or collaborators.
  2. Make rapid, iterative releases (a.k.a., "release early, release often").
  3. Many good writers advise show, don't tell, and so with software: construct enough to illustrate the most unique elements first as proof-of-concept
  4. Write the hardest parts first; some explain this as, "if you're going to fail, do it quickly," so you may then more intelligently begin again with wisdom gained from that experience or move on to what's next.
  5. The best program is one you don't have to write: put a shell script around an existing app, fork an existing library, delegate...
  6. Writing software is creating a universe with its own intrinsic nature, so respect that, explore it, and maybe you'll discover something new.
  7. There are people appropriate to start something new, to bring it to maturity, to be caregiver for its continued existence, but rarely is it the same group of people fulfilling each of those roles over time. Experience all of them to understand where your talents lend themselves best.
  8. Being entrepreneurial doesn't require you to be CEO; instead, everyone in an early stage upstart organization must equally understand efficiencies and trade-offs required to attain the next level, and that is the true wisdom of being entrepreneurial.
  9. You are continually, simultaneously both student and teacher– at the same moment.
  10. Anger or any other strong emotion is a signal that there's something in that situation you'd do well to stop and objectively learn.
  11. Openly share knowledge and ways of understanding, and discover that when you're the one in need, the right answer is easily available.
  12. If you weren't there, refrain from criticizing decisions or outcome, but do suggests paths for improvement in a nonjudgmental way.
  13. The difference between criticism versus critique is that the latter is actionable; always offer the constructive version.
  14. Nothing exists in isolation: technology, skills, business plans, people, etc., are so interconnected that you'd do well to consider this a law of nature, and enjoy discovering those connections!
  15. On ideas: Give it all you've got and more. Hold nothing back, then more will flow.
  16. Of body: be good to your body (the meat), and it'll be good to you. Take eye breaks. Remember to breathe. Minimize stimulants. Go for short walks periodically in addition to after lunch and in mid-afternoon.
  17. Just because it's new, doesn't mean it's better– just less accumulated entropy.
  18. As with natural languages, studying programming languages that are new to you improves versatility because each potentially offers something unique, a different way of expressing, and possibly emphasizing an area for which you would do well to focus.
  19. True genius is being humble enough to admit not knowing and the clarity of asking meaningful questions.
  20. Reinventing the wheel isn't necessarily bad, just usually excessive.
  21. But when reinventing that wheel, start with a fresh look at the physics too.
  22. Complexity may be shifted from one layer or component to another but never really goes away.
  23. Favor dataflow over workflow: like the architect/builder who paved paths between structures on a new college campus only after observing direction and width of wear patterns in the grass.
  24. Accommodating dataflow is like a waterwheel driving a mill on the riverbank and otherwise leaves majority of the environment undisturbed; whereas, enforcing workflow is like a dam which either requires significantly more effort to facilitate salmon returning to spawn or shortsightedly ignores its impact on anything else.
  25. Frameworks strictly enforce workflow and should be avoided unless your scenario exactly matches their predetermined patterns.
  26. On the other hand– like books at a lending library– software libraries may be used how you see fit: read the book backwards or read only one page; invoke functions in whatever sequence applies to your unique conditions.
  27. Frameworks may facilitate reaching 50% or even 70% completion very quickly but rarely attaining 90% with logarithmicly decreasing probability for anything more; however, functional libraries tend to accommodate recombining such that a little more investment during early stages greatly increases chances of reaching 100% and generally enables going far beyond initial criteria.
  28. When considering a rewrite or performance enhancement that might bring merely 2x or 5x improvement, make this the lowest priority because it might be a waste of time compared to waiting for next generation of equivalent hardware or upgrading to another architecture that offers wider concurrency, better parallelism and less contention.
  29. For performance improvements, focus only on those that would yield 10x, 100x or 1000x returns.
  30. Sure, you don't need to use Lisp (especially if you're the competition).
  31. Stick around long enough, and history becomes part of your past.
  32. Give yourself time to unplug: just be and allow your higher self to come through.
  33. "... Know when to leave."




The items above when applied within the context of designing software systems, build upon Dave Mills' maxims.