“Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself“ wasn’t the best written/edited book, but has some tasty bits scattered within the random acronyms. It reads like the storytellings of a retiring, experienced, software manager at a large corporation. Someone telling the inside story in a blunt, matter-of-fact approach. Personally, I like that style. It gets to the point without dancing around the subject. The only caveat with this book though, is that some of the advice is a little too specific to the author’s previous corporate environments. Still, if you’re stuck at an airport and this is what the local bookstore has, it’s not a bad choice.

A few quotes:

“Quality work is not done by mistake.”

“When developers are simultaneously assigned to several projects, they have split loyalties and their teammates cannot rely on them for support and assistance.”

“It is hard for someone to feel committed to a project when management is unwilling to make it their principal job.”

“Discipline, in fact, is what separates the experts from the amateurs in any professional field.”

“The team leader must motivate, coach, drive, and urge the members to perform to the best of their abilities.”

“If you don’t change the engineers’ working practices, you can change the organizational structure and all its procedures, but nothing much will really change. Thus, to have a substantial impact on an organization’s performance, you must change the way the engineers actually work.”

“Even when the result is a total business disaster, if the team provided a rewarding personal experience, the team members will view the project as a success.”

“When people say they are working harder, they actually mean they are working longer hours.”

“Designing, coding, reviewing, inspecting, and testing are intensely difficult tasks. To have any hope of producing quality products, we must occasionally take breaks.”

“Often, teams respond to this pressure by taking shortcuts, using poor methods, or gambling on a new (to them) language, tool, or technique.”

“Every day that you wait to act is a day that you can’t use to solve the problem.”

“The most important single asset a software engineer can have is a reputation for meeting commitments.”

“The most successful teams have energetic, enthusiastic, confident, and hard-driving leaders. If you don’t have the required energy and drive, figure out what to change so that you do. If you can’t see how to do that, either your team has a hopeless job or it needs a new leader.”

“A significant part of your leadership job is to keep the team’s goals clear and well defined and to ensure that every team member knows how his or her current tasks contribute to meeting that goal.”

“It is impossible to be an effective leader without being committed to a cause that animates you and motivates your followers.”

I finished reading “Coders at Work“ last night. In it, author Peter Seibel interviews 15 legendary programmers, discussing how they got started with computers, how they learned to program, how they read and debug code, etc. The interviews cover a wide range of opinions and approaches, and offers a fascinating look at “computer science” history.

The format of the book is a little unusual, in that it’s entirely interview transcripts. No analysis. No author-interpretation. Just recorded conversations. At first it’s a little surprising that one can publish a book like this; But then you get into the content and it’s wonderfully engaging. Analysis and interpretation would just get in the way of letting these folks talk. Reading direct quotes makes the content all the more exciting.

The book isn’t for everyone (obviously), but I rather enjoyed it. There’s some great stories about the history of our profession, and many topics raised that inspired additional research. (I went out and found a number of research papers referenced in the interviews, and bookmarked a lot of content for further exploration.) There’s also a fair amount on the history of different programming languages, and I have a fascination with programming languages, so it was a great fit.

A few take-away themes and ideas:

• While programming was no easy task in the early days, at least it was possible to fully-understand the hardware and all the software running it (as opposed to modern computers.) The modern computing environment presents very different challenges to present-day programmers, especially those new to the field.
• Even some of best use print statements.
• Passion and enthusiasm separate good programmers from great ones.
• In academia, you have time to think about the “best” solution, without the deadlines imposed on commercial developers.
• There’s certainly a component of “doing great work” that requires being in the right place at the right time — sometimes it’s just a matter of getting staffed on the right project.
• There’s some negativity towards C/C++ in here, mostly due to it’s negative impact on compiler and high-level language development. (i.e., one school of thought is that you give people a high-level language and make the compiler smart. The other is that you give people a low-level language and let them do the work. Unfortunately, humans aren’t so good at hand-writing code optimized for concurrency, but once you have a language that let’s them try, it’s hard to fund compiler research.)

Here’s a few of the quotes I highlighted while reading:

“One of the most important things for having a successful project is having people that have enough experience that they build the right thing. And barring that, if it’s something that you haven’t built before, that you don’t know how to do, then the next best thing you can do is to be flexible enough that if you build the wrong thing you can adjust.” — Peter Norvig

“…there are user-interface things where you just don’t know until you build it. You think this interaction will be great but then you show it to the user and half the users just can’t get it.” — Peter Norvig

“I get so much of a thrill bringing things to life that it doesn’t even matter if it’s wrong at first. The point is, that as soon as it comes to life it starts telling you what it is.” — Dan Ingalls

“…a complex algorithm requires complex code. And I’d much rather have a simple algorithm and simple code…” — Ken Thompson

“If you can really work hard and get some little piece of a big program to run twice as fast, then you could have gotten the whole program to run twice as fast if you had just waited a year or two.” — Ken Thompson

“if they’d have asked, ‘How did you fix the bug?’ my answer would have been, ‘I couldn’t understand the code well enough to figure out what it was doing, so I rewrote it.’” — Bernie Cosell

“You have to supplement what your job is asking you to do. If your job requires that you do a Tcl thing, just learning enough Tcl to build the interface for the job is barely adequate. The right thing is, that weekend start hacking up some Tcl things so that by Monday morning you’re pretty well versed in the mechanics of it.” — Bernie Cosell

“…computer-program source code is for people, not for computers. Computers don’t care.” — Bernie Cosell

“if you rewrite a hundred lines of code, you may well have fixed the one bug and introduced six new ones.” — Bernie Cosell

“I had two convictions, which actually served me well: that programs ought to make sense and there are very, very few inherently hard problems. Anything that looks really hard or tricky is probably more the product of the programmer not fully understanding what they needed to do” — Bernie Cosell

“You never, ever fix the bug in the place where you find it. My rule is, ‘If you knew then what you know now about the fact that this piece of code is broken, how would you have organized this piece of the routine?’” — Bernie Cosell

“Part of what I call the artistry of the computer program is how easy it is for future people to be able to change it without breaking it.” — Bernie Cosell

Here’s a PDF Version as well (which is a bit easier to read, IMO.)

…there’s no way it’s not a reference to the Fail Whale ;-)

Here it is on Amazon, BTW:
Billy Twitters and His Blue Whale Problem

I just finished reading “Even Faster Web Sites: Performance Best Practices for Web Developers“, by Steve Souders. It’s technical, and definitely for a limited audience, but it’s certainly relevant for web developers trying to squeeze a few extra milliseconds out of page render times with older browsers. (Yes, many of the techniques are just as applicable for modern browsers, but the performance competition between Firefox, Safari, and Chrome has the latest builds addressing, and solving, some of the common bottlenecks.)

What I liked best about the book were the tests and test results. Souders runs each browser through numerous test scenarios to demonstrate the (sometimes huge) impacts that small authoring decisions can make. (e.g., the surprising relationship between CSS files and inline JavaScript.) Souders also provides implementation details and decision trees for choosing and implementing as much asynchronous loading as possible.

All in all, it was a nice exploration of how different browser implementations approach page loading and painting, and how to exploit this knowledge for speed.

I was out on a business trip again last week, and took with me “Emergency: This Book Will Save Your Life“, by Neil Strauss. The book is a first-person account of Strauss’ transformation from a “soft”, urban writer, into a trained survivalist. It’s a wonderfully engaging story.

Here’s the link that put the book on my wishlist:
“How to Be Jason Bourne: Multiple Passports, Swiss Banking, and Crossing Borders”

Enjoy!

While it’s no fun being stuck in an airport, it turned out to be the perfect environment to read this book. The story follows a high school hacker as he fights the “Department of Homeland Security” to reclaim American civil liberties after anti-terror tactics are taken to a new level. Having the real DHS making announcements in the background about threat levels and unattended baggage, only makes the story more real.

The book targets a younger audience than myself, but it’s still enjoyable. Doctrow does a wonderful job keeping the story believable, and explaining the security implications of the technology we use on a daily basis. Given the theme of the book, I do hope he’s successful in reaching a wide audience and sparking a healthy debate about “national security”, privacy, and civil liberties.

Baby books (meaning books about childbirth and caring for newborns) range greatly in quality. I suggest you flip through some of them before purchasing; or even better, ask your friends with small children if they have any you can borrow.

Of the birthing and newborn books we have, the following stand out as useful:

• Baby 411, Third Edition: Clear Answers & Smart Advice for Your Baby’s First Year — A great reference. Easy to look stuff up; easy to read little sections at a time. The advice is rather redundant though, so you’ll get bored if you try reading cover-to-cover (which doesn’t seem to be what it was written for.) I know a few people with this book, and all have rated it highly.
• The Baby Owner’s Manual: Operating Instructions, Trouble-Shooting Tips, and Advice on First-Year Maintenance — It’s sort of a joke, but it’s the only book on caring for a baby that I’ve come across that seems to be written specifically for guys (and geeky guys at that.) An easy read, and very approachable. It was a nice way to get up-to-speed on a variety of topics — making it easier to then research things I wanted to know more details about.
• The Baby Sleep Solution: A Proven Program to Teach Your Baby to Sleep Twelve Hours a Night — Our little one is still too young to start sleep training, but this book came highly recommended. There’s some controversy around this book, but it’s interesting to hear this perspective.

In addition to these, we have a small collection of baby sign language books that I’m looking forward to digging through. We’re still a bit early for signing, but I’m fascinated by the idea that infants can learn to communicate through signing before they are able to talk.

It’s 400+ pages, but a rather easy read. The book covers a range of topics, including:

• The value of good design.
• Good design only happens when designers understand the context of use, and explore many possible solutions.
• Sketching allows designers (and potential customers) to explore ideas at low cost.
• Sharing sketches enables early feedback.
• Techniques for sketching interactivity.
• Sketching can involve computers, cameras, and smoke-and-mirrors provided that it remain quick, inexpensive, disposable, etc.
• There are many examples of quality sketching available in the archives of HCI history, and replicating these experiments is good practice for a budding interaction designer.

My opinions on the book are mixed. It definitely offers positive motivation for sketching — and some great stories to feed those “why are we drawing pictures instead of coding” conversations that come up all-to-often with clients unfamiliar with UX Design. However, the book does come across a little passive, yet arrogant at times, while making numerous references without context. This gives it a somewhat academic feel, reading more like a light-weight thesis than a typical design book. That said, if you work in UX Design, being familiar with the ideas in this book will go a long way toward helping your career.

While reading, I highlighted a few quotes, which I’ll list out below. I grabbed these not because they represent the theme of the book, per se, but because they had unique meaning to me, or something I’m working on. (For example, I’ve already used one of the quotes below in a presentation on the design process.)

Quotes:

“In order to design a tool, we must make our best efforts to understand the larger social and physical context within which it is intended to function.”

This is a classic UX/HCI principle of understanding the user and their context for interaction as a design constraint/criteria. It’s a basic requirement in designing a product/solution that delivers value to a customer.

This next quote is an interesting one for companies thinking that they can solve “design” simply by hiring a few designers:

“It does not matter if you already have the talent to save your company among your current employees. If you do not have the vision, will, and power at the highest level, then that talent is almost certain to remain as wasted as it is frustrated.”

Becoming a design company isn’t as easy as hiring designers (just like becoming an innovative company cannot happen simply by filling the ranks with a few smart people.) Companies can only lead the pack when these values go all the way to the top. Until that happens, organizational practices (and politics) will keep those talented stars from shaping the companies’ future.

This one’s fantastic (and the one I used in a presentation):

“Even if you do a brilliant job of building what you originally set out to build, if it is the wrong product, it still constitutes a failure.”

Meaning, that even if your company can execute a product vision perfectly (ie., you have great developers/craftsmen/etc.), you’re still wasting your time, and money, if you haven’t validated that your concepts will provide the market value you’re trying to achieve.

On the reason it’s important to share all ideas when brainstorming:

“…better idea[s] would never have come about were it not for the idea that it replaces.”

In other words, even bad ideas provide value via the thinking that occurs when we consider them.

On team dynamics and the work environment:

“A healthy team is made up of people who have the attitude that it is better to learn something new than to be right.”

“A design studio without ample space to pin up sketches, reference photos, clippings, and the like,… is as likely to be successful as an empty dance club.”

And finally, a reminder on why you never skip peer reviews:

“It is better to have your preliminary work critiqued by your colleagues while there is still time to do something about it — no matter how difficult the criticism might be — than to have the finished project torn apart by strangers in public.”