Yuchen > Recent Status Updates

Two interesting points

1. how to delegate, in page 60: delegate but monitor, not meddling.
2. handle interrupts:ask people to batch questions, manager should force the active interrupter to make an active decision about whether an issue can wait.

Part 1 is so shallow. The factory metaphor is very simple and it hardly ever applied to the real engineering day to day life. The real only one thing I remembered is to build more type of indicators: leading indicator, linearity indicator, trend indicators (stagger chart).

Part 1 is so shallow. The factory metaphor is very simple and it hardly ever applied to the real engineering day to day life. The real only one thing I remembered is to build more type of indicators: leading indicator, linearity indicator, trend indicators (stagger chart).

Breakthrough #3: simulating is a bit hard to follow and the explanation becomes a bit dense. Overall it is interesting still:

1. the neocortex inspire the generative model
2. model-based reinforcement learning and aPFC: aPFC solves the hard search problem, it is unclear how aPFC chooses a subset of choices
3. No dishwashing robot yet because we don't yet understand how motor cortex works

Chapter 25 is the most interesting and I enjoyed it a lot.

At the end of the book, the author emphasized that all software architecture is a trade-off, also any architecture decision are not binary and fall into a spectrum of trade-offs.

Overall the last few chapters are also barely readable.

The last part of the book is barely readable. The problem is that the author has placed the software architect outside of the developer team, and then spent Chapter 21, 22, 23, 24 to describe how they can work together. From my work expereice, these engineers are from the same team and they usually work together.

I found the these chapter hard to follow.

Part 2 is not very informative, except chapter 15.

Chapter 9 barely scratched the surface of the distributed system. Recently I've read Database Internals's Chapter 8, which done a much better job to describe all problems in less words.

Then the authors started to list all possible architectures. A lot of very shallow discussions, and I only learned a few interesting bit in Chapter 15.

The first part of the book was hard to follow. It is because the the authors spent a lot of time to explain what's a design and architecture, and the reader can be easily lost in the terminology introduced by the book, name a few examples

1. architectural quanta
2. "fitness function"

I found the book scratching the surface on a lot of aspects, and giving very basic example (ordering system, which is too shallow)

The first part of the book was hard to follow. It is because the the authors spent a lot of time to explain what's a design and architecture, and the reader can be easily lost in the terminology introduced by the book, name a few examples

1. architectural quanta
2. "fitness function"

I found the book scratching the surface on a lot of aspects, and giving very basic example (ordering system, which is too shallow)