Book review: “The LEGO Engineer” by Jeff Friesen

Affiliate link: https://amzn.to/3BN1S8o

Non-affiliate link: https://nostarch.com/lego-engineer

Disclaimer: I received a free pre-release review copy from No Starch Press.

I highly enjoyed The LEGO Engineer, by Jeff Friesen. The book consists of high level categories of engineering (Bridges and Tunnels, Trains and Beyond, Things That Float, Flying Machines, Amazing Buildings, Space Travel), with various examples of each category. These examples have detailed explanations of the mechanics behind them, as well as instructions for a LEGO model thereof. 

A large part of engineering is dealing with tradeoffs; there is rarely one perfect design, and this book does a great job of explaining the pros and cons of each design. For instance, with bridges the author gives the example that cantilever bridges can carry heavier loads with wide spans, but they’re complex to build and more expensive than simpler designs.

Each example flows logically from one to the next; generally the design that’s introduced builds upon or improves on the one that was just shown. For instance, the steam train is followed by diesel-electric (hybrid that seems virtually strictly superior to steam), which is followed by Shinkansen train (much lighter than diesel-electric because they get their electricity from overhead lines rather than heavy engines, allowing them to be more efficient). The examples also include dates of introduction or service, which gives a nice historical overview of the developments.

Each engineering example comes with a micro-scale (not precisely defined in this text, but in such a scale the typical minifigure would appear like a giant) model, parts list, and instructions. The parts list includes the exact piece numbers so that you can order them from a site like bricklink.com. The introduction to the book points out that if you don’t have the exact pieces, you can often make substitutions as long as the dimensions are the same (e.g. if you need a 2×1 piece, it doesn’t matter if you use the standard 2×1 or one with a brick texture); in cases where this isn’t true or it’s likely you’d get confused, the author helpfully calls out a warning. For instance, in the Cruise Ship, there is a non-standard jumper plate that would not behave the same way as the more common model; the two plates look identical from above and differ only in the bottom.

Here’s a screenshot of Bricklink.com illustrating the difference:

The models are generally of high quality and aesthetically pleasing. There are some clever parts uses, such as a feather to represent smoke:

Or a small technic gear element to represent the cutting head of a tunnel boring machine:

From just these two examples you can see the high-quality photos (or renders, I can’t really tell). The tunnel boring machine is a good example of micro-scale – whereas a typical LEGO car would be at least 4 studs wide, here a car is reduced to 1 stud wide and 2 long. When done successfully, it provides the ability to cover huge areas in small models.

Not every model works for me, particularly the Titanic model. Here is the finished product:

And a diagram of the Titanic from the previous page:

The distinctive elements are all present (4 smoke stacks, 2 antennae, color scheme), but in my opinion it is not a very good likeness. I believe the problem is in the proportions of the model. This model appears to be about 16 studs long and 2.5 studs wide, for a length/width ratio of 6.4. The real Titanic was proportionally much longer – approximately 882 feet by 92 feet, or length/width ratio of 9.6. 

Contrast this example with the International Space Station, which is much smaller in real life, yet much bigger as a LEGO model. This extra space allows the author to achieve a much more convincing likeness:

There are many helpful (non-LEGO) illustrations throughout the book; I found them consistently high quality. Here’s an example of how a submarine ballast tanks work in order to allow the ship to dive and later surface:

Perhaps the most interesting parts of the book to me were the examples of engineering challenges that were solved in unexpected ways, or cross-pollination across disciplines. For example, the Shinkansen train was initially shaped like a bullet, which caused problems exiting tunnels. Eiji Nakatsu developed a new nose shape inspired by the bill of the kingfisher bird; the text indicates this solved the tunnel problem and reduced air resistance substantially. Another example is that the hovercraft was invented by a radio engineer.

Overall, I think this book is a good purchase for anyone who is interested both in LEGO and engineering. The positives (logical sequencing, interesting engineering explanations with diagrams, by and large aesthetically pleasing LEGO models with detailed instructions) far outweigh the minor complaints I have (a few models which suffer from scale issues or otherwise don’t look convincingly like the thing they are trying to portray).

Book Review: Team Geek by Ben Collins-Sussman and Brian W. Fitzpatrick

Team Geek: A Software Developer’s Guide to Working Well with Others, by Ben Collins-Sussman, Brian W. Fitzpatrick

Disclaimers: I received a free copy of this book to review from O’Reilly. I work at Google, as do the authors, but this review reflects my views only and not necessarily those of Google.

One thing I have learned over my three years of professional software development is that you really are writing code for other people to read, not for the compiler. This dual nature of programming, the precise, exacting specifications that run on the computer, and the imprecise, ambiguous human factor, is fascinating to me. Ben Collins-Sussman and Brian W. Fitzpatrick, two of the engineers behind the SVN version control system, currently working at Google, have written Team Geek, a book that aims to impart lessons learned in creating better software through better people skills and teamwork.

Programmers tend to lionize the lone programmer, like Linus Torvalds of Linux fame. In some rare cases, geniuses do manage to accomplish incredible things on their own. But in most cases, great software is a collaborative effort performed by a team of people of varying skills, backgrounds, and communication styles. There are many books which help improve your technical proficiency, but this is one of the few I’ve encountered that addresses the importance of working effectively with teammates.

I won’t reiterate all of the content of the book but there are a few themes that occur throughout that I’d like to touch on.

The first is that it is crucial to spread the knowledge throughout the team rather than keeping it siloed in the heads of a few people. They whimsically refer to this as the “bus factor” – how many people would it take to be hit by a bus (or be otherwise incapacitated) before the project would fall apart?

One way of increasing this shared knowledge is through the use of communication channels that are easily archivable and searchable rather than through point to point communication. For instance, it is better to ask questions of the team via an IRC channel or mailing list than to ask someone directly, because that exchange can be easily found in the future. It also gives other team members visibility and input into the decision making process.

The culture of the team is also frequently discussed. In the previous example, archiving technical discussions would do no good if no one bothers to search and try to find answers by themselves prior to asking someone for the answer. The shared values of the team are crucial to its effectiveness.

Another main theme of the book is focus, or “saying no to all the distractions.” Part of an effective team, the authors say, is a manager who can shield engineers from the chaos inherent in the organization. This is a form of avoiding distractions at a high level – working on things which do not actually matter for your project. One relevant quote I’ve found in this regard is

There is nothing so useless as doing efficiently that which should not be done at all — Peter Drucker

One way the authors suggest to maintain focus is to decide on a mission statement. It might sound cheesy, but they offer a compelling argument as to its efficacy. They relate an example of how they used this technique on one of their projects and it became clear that many of the senior engineers had very different goals and ideas of what the product should do. Had they not forced the team to clearly specify what they were trying to accomplish and what the non-goals of the project were, there would have been significant wasted effort by people working at cross purposes. They use the analogy of a cart being pulled by different team members in different directions – by not working towards one goal, the cart will not move forward as quickly as it would if all were pulling together.

At a lower level, distractions abound as well. While programming, it takes significant concentration and effort to get engrossed in the task at hand and to ‘load’ the program structure into one’s head. Context switching is very bad for productivity because the cost of reloading this state is so high. Sometimes these context-switching distractions come from other team members, such as when someone interrupts to ask a question. The authors suggest that the team come up with a strategy for minimizing these disruptions, both to increase productivity and decrease frustration. For instance, in one team the authors led, any time Alice needs something from Bob, Alice would make her presence known, Bob would verbally acknowledge Bob but not stop what he was doing, finish what he was doing, and only then stop and talk to B.

While much of the book is generalizable to any sort of team environment, the authors do give some coding specific advice. There are discussions on handling code reviews effectively, dealing with people who constantly dig their heels in and criticize others’ technical solutions, and ways to avoid ego while coding.

Conclusion

I thoroughly enjoyed this book, reading it cover to cover over two legs of an international flight. Much of the advice in the book is common sense but there are also many specific, concrete ideas that I had never considered before. I would recommend this book without reservation to anyone working on a team that writes software.