Jan Meppe

Machine learning engineer in love with building digital products.

1 minute read

I return time and time and time again to John Oosterhout’s timeless advice.

Magic secrets:

  • Problem decomposition: Can we break up the system into modules or subproblems that can be solved relatively independently?
  • Working code is not enough, we must minimize system complexity. Complexity is caused by obscurity and dependencies. Test-Driven Design (TDD) does not guarantee good design over time.
  • Classes/modules/interfaces should be deep. Imagine a class as a rectangle. The total area is the benefit and the interface is the top side. Maximize the surface area given the smallest possible working interface. For example, UNIX file IO hides thousands of lines of code with 5 interface methods (open, close, read, write, lseek)
  • Define errors out of existence. Defining errors out of existence means changing the semantics to make the normal case handle do everything. This reduces system complexity. For example, Java.substring should return the intersection of your array and the bounds, not throw an exception. Unset in TCL should make a variable not exist (see, changing the semantics!). Only throw an error when you really can not carry out the contract.

From: https://www.youtube.com/watch?v=bmSAYlu0NcY

Subscribe

Comments

You May Also Enjoy