Bump zine 0.3.0 -> 0.8.0

Fix a lot of associated breakage
Fix broken rss.xml file as highlighted to me by Matthijs van der Wild
(thanks!)

1 files changed, 28 insertions, 0 deletions

diff --git a/content/posts/2022-02-11-philosophy-software-dev.smd b/content/posts/2022-02-11-philosophy-software-dev.smd
new file mode 100644
index 0000000..6319350
--- /dev/null
+++ b/content/posts/2022-02-11-philosophy-software-dev.smd
@@ -0,0 +1,28 @@
+---
+.title = "Book - Philosophy Of Software Design",
+.author = "Martin Ashby",
+.date = @date("2022-02-11T19:18:07Z"),
+.layout = "single.shtml",
+.custom = {"comments": true},
+---
+
+This is my short list of ideas I've taken away from reading [a Philosophy of Software Design](https://www.goodreads.com/en/book/show/39996759-a-philosophy-of-software-design) by John Ousterhout.
+
+* All the following advice is to be taken in moderation and with consideration for individual circumstance. Taking anything to it's logical extreme usually results in poor outcomes.
+* Complexity is the enemy of understanding.
+* 'Deep' interfaces are better than 'shallow' ones. Practically this means: keep your interfaces as simple as possible, and contain/handle the complexity in the implementation. Prime example was the linux/unix file system API.
+* Spend time on design. Consider alternatives, discuss them with colleagues.
+* Choose accurate, consistent names.
+* If a reviewer doesn't understand your code, it is not clear enough. Listen to them, and make it clearer somehow.
+
+I agreed very strongly with all of the above. The idea of 'deep' interfaces expresses something I have been previously unable to express succinctly, and I will try to apply this in my own code and reviews. I also think I will try this tip:
+
+* Write comments/documentation _first_, i.e. while you are designing. This helps to find high-level problems in the design, before you have already spent time coding it.
+
+I disagreed on some minor points:
+
+* in section 8.2, it is advised to avoid configuration parameters. They are an indication that your system isn't handling complexity, and shifting responsibility to the operators of the system. In general, I think it's much better to: 1. make everything configurable (within reason) and 2. provide sensible defaults for the most common cases. The author recommends auto-tuning parameters, however I think this is overkill in most cases, and also takes away control from the operator or user of the software.
+* In section 18.2, it is advised to always use the same type for variable declaration and allocation. The author gives the example of a local variable declared as a `java.util.List`, but instanciated as an `ArrayList`, and cites differing performance characteristics as a potential hazard for users of the variable. I think this example is poor; it sounds like premature optimization, and it risks users of the variable using implementation-specific methods and making it more difficult to e.g. change the type of the list later.
+* In section 19.3 the author asserts that unit tests have the greatest coverage, and are therefore the best tool for uncovering bugs. I think this is something where YMMV. It really depends on the quality of the unit tests, and the most typical sources of bugs in your application. I think (although I can't prove) that _most_ bugs are found in the interactions of multiple modules, and unit tests will not catch those as they are (by definition) only testing one module.
+
+I would recommend this book to pretty much all software developers at any level. I think everyone in software could find something to take away and use in their work, to the benefit of their projects (and colleagues!).