Comments by "Christian Baune" (@programaths) on "Creator of Go on Software Complexity | Rob Pike | Prime Reacts" video.

  1. Code in a stupid way, and your program will survive longer ^^ In implementing form validation, I coded the whole thing, assuming I would have two magic functions. One is to retrieve a field from whatever structure was passed to it, and the other is to retrieve a value from whatever design was passed to it. So, relatively easy to do the validation using those functions. Then I created those two first-order functions to grab fields/values from the right place. When the same functionality was required in an Angular application, only those two functions were to be remade. I tried explaining that to the other developer, who insisted on changing the "core." I don't do Angular (I did AngularJS), but in the end, I did those two functions myself. The guy still didn't wrap his head around it. Later, we had to update the core, copying one JS file. He had the same issue; he didn't understand it was just a copy-paste...Took a few times before he became confident. I even asked my boss if I could take over that part entirely because going into a call to copy a file is...painful. In another application, I created an intermediate representation. My boss thought it was a waste of resources, but that intermediate format is more suited for processing. A small upfront cost for a lot of downward efficiency! I had to implement a new feature, and thanks to the intermediate format, it took a day instead of a week ^^ And I am the first to say comments are usually band smell (as a QAM, I used comments as a mean to quickly find code that belongs to a function), but most of them read like "do not attempt to simplify" or "bug in library, force reloading data". Now there is a considerable drawback, people not used to that way of programming are stumped because it's not a big block of code where you can read from top to bottom. In the middle of the code, you have a call to a function coming from the parameters, so you've to see how it's called to see the body of that function in context...except that you don't have to because you're supposed to work at a different level of abstraction. So, it makes stuff way simpler as you just have to assume the function does what it says it does. And that's the beauty; in the end, you concentrate on a very generic algorithm, which is relatively easy. Then you fill in the gap, which is relatively easy too. Then you end up with something complex but totally digestible if you don't freak out. On top of that, the JVM loves smaller methods. (No JIT if bigger than 8k, and I saw strategies much bigger than that ^^) I have 15 years of professional development, 25 years with hobby. (You can look up "Navigateur à onglets gérant ses favoris et qui peut se dupliquer (==>capture)" for an example)
    1