“Beautiful LEGO” review – inspiring and beautiful

Disclaimer: I received a free review copy from No Starch Press. The images I’m linking to do not come from the book itself; as I mention later in the review, the images in the book look better than the ones I am including in this review.

Beautiful LEGO, by Mike Doyle, asks the question “Can LEGO be art?” Given that Mr. Doyle is himself a LEGO artist, it’s no surprise that the answer presented in the work is a resounding yes. If you’re looking for an in-depth discussion of the subject with academic criticism, look somewhere else. If you’re already a fan, this book is an incredible collection of artistic talent, and one I recommend without reservation.

Contents

The book is divided into various themed sections, punctuated by interviews with the artists. The sections include

• Everyday Wonderful – Depicts everyday objects such as a Polaroid camera, the Nintendo Entertainment system, cameras, and telephones. These works are very realistic and not stylized.

• Attic Treasures – Works by Matt Armstrong, in the same vein as Everyday Wonderful, but focused more on older technologies such as Morse code, sewing machines, and telescope.

• CubeDudes™ – Angus Maclane creates famous characters and historical figures out of LEGO, with the heads at 45 degree angle (pointing towards you). These include Smokey the Bear, Abraham Lincoln, and Star Trek characters. Here we really start to see the art form come alive as more than just a representational medium. There is great style and care put into these small figures, instantly recognizable despite their size.

In all there are about 30 sections/interviews throughout the book. The usual suspects, such as cars, buildings, space ships, and mechs, are present, as well as less usual subjects, like Monty Python (Pythonscape) and mosaics.

Interviews

There are about 10 interviews with the artists, and they might be my favorite part of the book. The artists discuss how they got into using LEGO as an artistic medium as well as their design process.

Interview subjects include

• Ramón and Amador Alfaro Marcilla – two brothers who work together to create incredible sci-fi works, such as the chest burster from the movie Alien (p. 9). They also have the honor of having the most disturbing picture in the whole book, The Doll (p. 5).
• Jordan Schwartz – a professional LEGO designer working in Denmark.
• Nathan Sawaya – a builder who creates life-size sculptures, and who has an art show called “The Art of the Brick”.
• Mike Nieves – a builder who uses pieces I’ve never seen before, as well as using familar pieces in creative ways. For instance, Olaf the Bearded depicts a warrior with a long flowing beard. On closer inspection, the beard is an octopus figure.
• Arthur Gugick – a creator of incredibly detailed architectural creations, such as Big Ben and Salisbury Cathedral.
• Mike Doyle – the author of the book. Like Arthur Gugick, he creates large scale buildings. He is perhaps best known for his beautiful decaying Old Victorian mansions.
• Nannan Zhang – very short interview, but Mr. Zhang creates some of the darker pieces in the book, such as End of Days.
• Lino Martins – a builder best known for his series of car creations.
• Ian Heath – creates human characters with lots of personality, like Freddy Mercury and Stephen Hawking.

My favorite quote is from Lino Martins, whose work “Hidden Treasure – 1949 Buick Fastback” is shown below:

One LEGO piece, while an engineering marvel, is not very exciting on its own, but bins of thousands of pieces – that’s stored kinetic potential. That is a million works of art waiting to be made. That is life. And in the hands of another LEGO artist, the very same pieces can become a million things I have never fathomed myself. It’s like being in art school all over again. Even without a signature, our styles are diverse enough that we can tell one artist’s work from another. (p. 186)

Styles

I thought this comment on styles was hyperbole, but as I looked through the book a few times, I realized that it’s not. I started to recognize artists that appeared in multiple sections of the book. For instance, Tyler Clites packs a ton of personality into small spaces. “Sometimes It Sucks To Be a Ghost” (p. 105), shows a ghost being sucked into a vacuum cleaner, with toys strewn about the floor. Without reading the artist’s name, I guessed that another work, “Grandpa! You better not be using my loofah again!” (p.92) was by the same author.

The styles and scale of composition vary tremendously among the artists. Mike Doyle, for instance, creates enormous, intricate, realistic decaying Old Victorian mansions

Nathan Sawaya creates life size human sculptures, such as Frozen Figure (p. 48). Others create whimsical fantasy architecture on a medium scale, such a Sean and Steph Mayo’s Micro Fall’s Fortress (p. 142). MisaQa’s Little Town (p. 106-107) is even more microscopic.

At the most minimal level are Eric Constantino’s adorable Big Eyed LEGO Duck and Big Eyed LEGO Peacock, which are instantly recognizable yet weigh in at no more than a dozen pieces or so.

This book helped me appreciate the fact that there is real artistry and talent that goes into making very small scenes. It’s easy to appreciate the enormous scale of Nathan Sawaya and Mike Doyle’s work, but I am convinced that just as much skill goes into some of the smaller compositions featured in this book.

Quality

The production quality of this book is excellent. All of the pictures have had their backgrounds digitally erased and replaced with a pleasing gradient texture (look at the Mike Doyle pictures I linked to above to get a sense of what all the pictures look like). There are a few places where the photos submitted by the artist were clearly not high resolution enough to feature in the book, and they look very out of place. The two instances I found were “Mort” (p. 101) and “Pierre, Of Course” (p. 133). This is a minor nitpick of an otherwise excellent book. For some sample high-res images see MicroBots, or the page of horses.

Conclusion

I have read through this book about four times now, twice on my own, and twice with a 2- and 3-year-old on my lap. They would not let me put it down and were awe-struck on every page, oohing and awwing. As soon as I finished it once, they made me immediately start over again. It was wonderful to see such excitement and energy channeled towards these LEGO creations.

This book is a wonderful addition to my library, and I’m confident that anyone with a passing appreciation for LEGO will love it too.

Book Review: Unofficial LEGO Technic Builder’s Guide by Pawel “Sariel” Kmiec

Unofficial LEGO Technic Builder’s Guide by Pawel “Sariel” Kmiec, published by No Starch Press.

Disclaimer: I received a free copy of this book to review from O’Reilly.

I have a deep and abiding love for all things LEGO. Growing up, I assembled a few Technic sets but never really tried to make any creations on my own with that system. I received a great set last Christmas, the well-loved 8421 crane model.

I enjoyed the process of assembling it tremendously, as it had great small details like working doors on the cab and a brilliant modular design. I was eager to review this book because Technic interests me but I know so little about it.

Bottom line up front – this is one of the best, most informative books I have read. It exceeded my expectations in its breadth and depth of topics covered and its effective use of illustrations. It is divided into five sections – basics, mechanics, motors, advanced mechanics, and modeling.

I did not expect such a thorough explanation of all the physic and mechanical engineering principles that are necessary to make working models. The first Basics section covers such concepts as speed, torque, power, friction, traction, and backlash. The author proceeds to cover more specific concepts related to vehicles, such as drive trains, front wheel versus rear wheel drive, turning radius, and center of gravity. I was familiar with some of these terms but not others (for instance, “Backlash describes the gaps between mating components, such as two gears”).

Only after exhaustively covering these basic mechanical principles does the author tackle Technic specific elements, such as pins, axle holes, units of measure in the LEGO system, important ratios (for instance, 3 plates = 1 brick in height), and the difference between beams and bricks (studless vs studfull). This section was very interesting to me as it gives precise names to pieces that are hard to describe otherwise.

The second section of the book covers mechanics, with an in depth looks at gears, chains and pulleys, levers and linkages, pneumatics, and reinforcing models to avoid being pulled apart by the stresses of the system. Almost all of these concepts were new to me, with the exception of gear ratios. The author introduces real world mechanical devices/techniques (such as the Chebyshev linkage), describes what they are used for (converting rotational motion into a straight line), and includes a fully realized Technic version of each system. Some of the systems are laid out in multiple steps, while others have just a single image of the completed structure. Still images allow you to get a sense of how the systems work, but the author also includes links to videos of some of the systems, which are much easier for me to understand.

Chebyshev linkage figure

The third section of the book is an exhaustive look at all of the LEGO motors and their stats (torque + speed), as well as examples of what each is particularly well suited for (or not, as he has clear disdain for some of the models).

Advanced mechanics covers steering, suspensions, tracked vehicles, transmissions, and the use of adders and subtractors. I found this section particularly interesting because I’ve never bothered to take the time to understand how a real world car works. After reading through the explanations and mentally visualizing how the gears would turn in each example, I have a much better understanding of what happens when gears shift in a car, or how suspensions help to keep vehicles in contact with the ground (not just to provide a smoother ride and act as shock absorbers, which I erroneously thought).

The book concludes with a section on creating models, and the tradeoffs involved with using Technic to mimic real life objects. There is a natural trade off between form vs function, and the author encourages prospective builders to decide which one they’re willing to sacrifice before beginning to build. He discusses how to use blueprints to determine at which scale the model should be built, based on the fact that certain Technic elements are only available in a small range of sizes. For instance, if you’re modeling a car, you are limited by the size of the wheels – you could not build a 1/4 scale model, for instance, with off the shelf Technic components.

Conclusion

As I said up front, this book blew me away with the amount of technical details it presented in a clear, easy to comprehend format. I found the figures in the book absolutely crucial to my understanding; I estimate that there are at least 200 such figures. Some are photographs (usually of his finished creations), but most are high quality 3D renders. The author makes consistent use of color throughout a section, and details what the color scheme means (for instance, a red axle might always be the one that is connected to the motor, while a green one is on the output side of the equation). My one nitpick is that it’s very hard to make out some of the figures on a monochrome display (i.e. the Kindle), but I was able to consult the beautiful PDF version if I needed clarification.

This could have been a dry textbook, but instead it’s fun and eminently readable. The author’s quirky sense of humor manifests itself in some of the photographs, in which a hamster appears, ostensibly for scale. I’m inspired to try my hand at building my own Technic creations, and that’s about the highest compliment I can pay this book.

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.

Arduino Cookbook review

Some of you may have seen me post this on Twitter, but if not I’m linking here to my DZone book review of the Arduino Cookbook. Tl;dr version: I like it a lot. I’m looking forward to building some things with Arduino in the coming months.