Development Practice
Created at 2016-06-19T06:33:31.000Z

This post will be updated constantly.

My Experience


    • abstraction (make a thing as "library") for single use
    • don't try to solve unseen/undefined problem
  • two kinds of abstraction

    • file separation (syntactic separation)
      • (ruby/rails) put ruby code in model to use in view
    • reusable library

  • "define a problem (find a problem)" vs. "solve a problem"

    • ex. optimize something (e.g. assets size, query)

  •, good tight code

    • ruby/rails: safer way of nil check kills readability
      • don't use arr.blank? when arr cannot be nil at the exact line

    • type system:
      • relation to "sub typing" ? (approximated to Any)
  • Testing for encouraging faster change

    • you can aggressively and safely change existing code as long as there's a test

  • Pair Programming:

    • in any cases, two pairs of eyes contributed to decreasing a gap between syntax and semantics
      • typo, naming
      • constant way of code review

    • three types:
      • junior/senior case (programming knowledge differs)
      • new-comer/long-lived (system/source code familiarity differs)
      • same level case
  • Not talk on chat if you can discuss face-to-face. after discussion, keep a log somewhere.

  • Rule of Representation (from Unix Philosopy):

    • from this point, we can say Haskell's rich custom data type has crucial advantages

Fold knowledge into data, so program logic can be stupid and robust.


the importance of evaluating your capability to deliver features against your capability to maintain your software and make it able to sustain more change in the future.

Adding an idea or a potential awesome feature to the backlog is way easier than designing, building, delivering, marketing & maintaining it. ... In the end managing software projects is all about deciding what to do and what not to do. Having a clear separation between what sounds like a good idea and what actually gets implemented is key.