73

 

First this week's required reflection:

Rate the book "Software Engineering at Google"  1-best, to 5-poor 

1.01

Rate the book "Full Stack Development"   1-best, to 5-poor 

1.00

Why did you give those ratings?

Software Engineering at Google is a (not so?) common sense book on broad methodology aimed toward specification of massive group collaboration giving adages for best practice and methodology in collaboration with large software projects that span through time across many different developers in long term cycles. One adage we learned right off the bat was that lots of small additions that work are a million times easier to manage than bigger, longer, more encompassing additions merged less often. I personally have found this true in my own projects, when I was a kid I started off the wrong way, building enormous projects that went nowhere - but I learned quick, and got past that, realizing what this book is telling us, incremental working stages are much, much more effective.

What's neat is you can tell it's really true, because the principle is the same for mixing physical objects. Try and mix a large bowl of flower and a large bowl of water and watch it never work, ever, but mix a little flower and a little water until it's all mixed and - that works.

For all the tech and programming how-tos we read, it is inspiring to see that the human and natural process tendencies are known and studied and focused on in order to gain higher effectiveness in our world. If our society as a whole followed some of the principles this book illuminates, I think we would be better off as a society. People are funny, and this book has no problem discussing that and what to do about it in the best, most educated way, aiming toward the highest intent. It features many words of wisdom. One example: "...a little bit of empathy would have gone a long way toward keeping Jake happy in this situation" sounds like something I would say, in real-world terms, focused on real-world issues that actually affect work, whether we think they will or not.

The Leading at Scale chapter could add a section 'Always Be Done' corresponding to Agile methodology, to the sections with the titles labeling the adages offered "Always Be Deciding", "Always Be Leaving", and "Always Be Scaling." There is a sale-person adage, 'Always Be Closing' known as ABC, to me it means basically keep your eyes on the goal at all times and be steadily incrementing toward it. That's what originally made me associate my own programming realizations, after the programming messes I created when I was a kid, eventually I learned, instead of creating a heaping mess, "Always Be Done" (ABD!) which basically means something similar to Agile, just small incremental working feature additions, one by one, starting with a working Hello-World, or some working something. I just took off the 1/100th of a rating point for this book for making me think of 'Always Be Done' first, instead of the authors. The book is very readable and we should all be familiar with the broadly applicable principles it offers, even in other areas of life I think.

Full Stack Development with Spring Boot 2 and React: The cover is pretty clever. Looks colorful, don't press down though, it's sharper than it looks, if the angle shifted that would become obvious. The say don't judge a book by its cover, I always say the opposite, a book has one single chance to present itself, and the cover is how they do that, by showcasing the title and if they want, giving some insight toward the content, or at least some display of being a book cover. The content of this book is great and matches my metaphor, leading us in a practical way through practical examples while explaining the mechanics of the Spring Boot with React framework. Get the angle wrong and you'll see the sharp side, lots of dependencies, lots of error messages, and lots of code to understand before you can flow as you might a simpler paradigm. And the flip side to that is multi-fold, because you get the power of a vast amount of capabilities for your program while building a logically cohesive expandable, scalable design that will, instead of getting more and more confusing over time, become less and less confusing, especially as a cohesive whole.

The framework we are using isn't trivial, and neither is explaining it, so, choice of order and choice of exactly what to explain, when, makes all the difference. The lecture paired with the working example code we are given is even more valuable than the book, I think, because there is really nothing like starting with a running project and adding trace outputs until you actually understand the mechanisms in play. The book gives a solid explanation of the underpinnings of the functionality of the framework and with the working example code we are given we have a better chance understanding the system as a whole and in parts. Pairing the specifics with graphical output illustrations helps animate the book and inspire writing the examples given.

In the rest of my life I am devouring MIPS assembly as fast as I can for Architecture class, the next assignment in MIPS is to find primes, it should be very fun. The clay we got from Bita's grave is almost ready to start making stuff with, and I got some neat glazes to go on it. In photographing a minute spider crossing an enormous yard the first thing this morning I was able to instead catch a sequence of a hummingbird photos. I saw him come into frame, and just held perfectly still, but keeping pressing the camera-photo button, whatever it's called.