Skip to content

Instantly share code, notes, and snippets.

@dmohs
Last active January 16, 2019 22:10
Show Gist options
  • Save dmohs/fa16682ee191e635facf905706d26fb6 to your computer and use it in GitHub Desktop.
Save dmohs/fa16682ee191e635facf905706d26fb6 to your computer and use it in GitHub Desktop.
= Engineering Philosophy
David Mohs <dmohs@broadinstitute.org>
:toc: macro
== My Core Principles
* Choose technologies where the creators share your engineering philosophy.
* Treat developer usability with the same reverence as product usability.
* Every choice has tradeoffs. If I have a good understanding of the benefits, but not the drawbacks, I'm making a poorly-informed choice.
== Examples
* Tests are one tool for quality, and an expensive tool.
* To write a better shell script, start by throwing it out and using a mature language. Ruby is often a nice fit. I want to solve the problem at hand and provide a good user experience, not fight with how the language handles strings.
* Postgres over MySQL. The right features and documentation trumps specific performance characteristics. There will always be performance concerns and I can usually find workable solutions.
* Clojure or Lisp over everything else I've tried. Lisps are inherently simple in syntax, allowing me to focus on clarity, and judicious use of macros provides unmatched power for noise reduction.
* Anything but Python. I value anonymous functions and careful symbol scope, things this language appears to care little about.
* React preferably, but anything besides Angular. I'm happy that someone tried Angular's magic approach to re-rendering a page (and overriding with strategic NgZones when necessary), but it is time to mark that experiment as a failure and move on.
* Dynamic typing over static typing. For just about every statically-typed codebase I've read, "a system for serializing and deserializing objects" is an appropriate description. Unless that is indeed what I'm building, the code should self-describe its function, not its objects.footnote:[https://lispcast.com/clojure-and-types/] footnote:[https://www.youtube.com/watch?v=-6BsiVyC1kM]
* Event-based architectures are good for IO-bound applications. NodeJs is an event-based architecture. Your API is probably an IO-bound application.
'''
\*** For every single statement I've made above, I'm prepared to be proven wrong.

My Core Principles:

  • Choose technologies where the creators share your engineering philosophy.
  • Treat developer usability with the same reverence as product usability.
  • Every choice has tradeoffs. If I have a good understanding of the benefits, but not the drawbacks, I'm making a poorly-informed choice.

Examples:

  • Tests are one tool for quality, and an expensive tool.
  • To write a better shell script, start by throwing it out and using a mature language. Ruby is often a nice fit. I want to solve the problem at hand and provide a good user experience, not fight with how the language handles strings.
  • Postgres over MySQL. The right features and documentation trumps specific performance characteristics. There will always be performance concerns and I can usually find workable solutions.
  • Clojure or Lisp over everything else I've tried. Lisps are inherently simple in syntax, allowing me to focus on clarity, and judicious use of macros provides unmatched power for noise reduction.
  • Anything but Python. I value anonymous functions and careful symbol scope, things this language appears to care little about.
  • React preferably, but anything besides Angular. I'm happy that someone tried Angular's magic approach to re-rendering a page (and overriding with strategic NgZones when necessary), but it is time to mark that experiment as a failure and move on.
  • Dynamic typing over static typing. For just about every statically-typed codebase I've read, "a system for serializing and deserializing objects" is an appropriate description. Unless that is indeed what I'm building, the code should self-describe its function, not its objects [1] [2].
  • Event-based architectures are good for IO-bound applications. NodeJs is an event-based architecture. Your API is probably an IO-bound application.

*** For every single statement I've made above, I'm prepared to be proven wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment