*Too Big to Fail* by Andrew Ross Sorkin

Too Big to Fail gives a good view of how executives and managing directors live: on call 24 hours, breaking off family vacations to deal with company business, showing up hours late to meet your future son-in-law. 

True, rushing back to the office requires getting in a limo with your personal driver or, in one case, a helicopter.  True, the broken family vacation started at a 5-star exclusive island getaway, and they fly back on private jet.  True, you host your guests in your unbelievably large mansion, and when you arrive, you can regale them with unique stories about how you just got out of an all day meeting with the Secretary of the Treasury and the head of the Fed.


So, forget having a family life if you want to make it big in the financial industry, though you will have any comfort money can buy.  Most people would probably make that trade-off, but after reading this book, I realize I couldn't.

I developed even greater appreciation for the government workers heading the Treasury and the Fed.  These guys worked just as hard or harder, but without the perqs or big bonuses.  Of course, Paulson made hundreds of millions already, but why would he want the job?  At one point, he vomited in the trash can next to his desk, due to exhaustion and stress, then immediately got on a call to save AIG.  He and Geithner performed as incredibly tireless servants of the government; Geithner never worked on Wall Street, so he never made the huge bucks.  Meanwhile, the public scrutinized every move of theirs, and when they made mistakes, as surely they did, their critics ripped into them.  Again, I had to wonder about the benefits of the job, and who would want it?

Almost all of the execs and leaders impressed me with their stamina, quick minds (despite the pressure and the lack of sleep), and depth of knowledge.

*Uncommon* by Tony Dungy

Tony Dungy is one of those guys you can't help but root for.  First, he had he a Super Bowl taken away from on the verge of winning it at Tampa Bay, so you had to pull for him to win it at Indianapolis.  Then, a year after his son died, you had to pull for him to win it the next year when his team made it.

The underlying reason shines through in Uncommon.  NFL teams test and time potential draft picks, and then record codes about whether to draft each one.  A guy might be too slow or unskilled to get drafted.  Dungy may be the only one with a code DNDC -- "do not draft due to character".  This extends beyond trouble with the law or recklessness.  It includes work ethic and team orientation.  As Dungy mentions, they have lost out on some major talent due to this provision, but he firmly believes it was worth it. 

Uncommon is a motivational book, well-suited for sports team building at the high school or college level. 

*The 7 Habits of Highly Effective People*

This is an old book that everyone knows.  I was drawn to it by the title.  Effectiveness continues to be a top priority.  Habits indicates hard work, no shortcuts; I'm a believer in practice making perfect.  Highly, as opposed to Super or Awesomely, is understated and again indicates realistic goals.

Also, the title is much better than How to Win Friends and Influence People.  Apparently, we've learned to be slightly less obvious in our ambitions.

I particularly liked the section on being more proactive.  I mentioned in an earlier post that he has the best definition of proactive, one that actually means something.  I don't know if he coined "proactive" or "win-win", but he might have been the one to popularize them.  Now, those words have been so overused that they barely resonate.

Covey also has a strong smell of authenticity.  You really get the sense that he lives what he's preaching, that he would be living that way even if he knew he couldn't package it up and sell it, and gives the whole thing credence.

This book is particularly good for someone who is in a funk, or maybe between jobs, and needs some direction.  He offers practical ways to implement what he's saying, though I found the "private" / personal changes to be more interesting than the "public" / interpersonal one, perhaps because the interpersonal ones have been re-done and re-stated so many times since then.

Too much of a good thing

This description blew up all the ways I usually think about team culture:

Despite his forty-year police carer, [John Guido] was never part of the NYPD culture...  "The Irish thought the job was a calling," Guido liked to say to me.  "To me, it was just a job." ... the consummate outsider, he did not mingle with colleagues.  He refused to attend formal police functions like retirement dinners or testimonials staged by wealthy police buffs."

Sounds a someone you don't want on the team.  Not a team player!

But the reason he kept his distance was to avoid the sleazy side of the job.  By keeping himself clean, he eventually became Chief of Internal Affairs, and earned high distinction.

"There are many cultures in the New York City Police Department, but corruption is the strongest one," he said.

A group like the NYPD has the opposite problem of most organizations: too much sense of team and identity.  Corporations would kill for that kind of loyalty.  We usually think of a strong culture as being good, but in this case, Guido points out that it can easily work the other way.  They're so loyal to each other, even the clean ones won't report the dirty ones, sometimes known as the Blue Wall.  As a result, many of them succumb to the temptation of power.

In a job like the police, with its danger and also the dual role the "policed" play as both customer and problem, the cultural problem isn't generating camaraderie and team pride, but doing the opposite -- without killing the pride that you still want good police officers to have in their job.  After reading NYPD Confidential, it clearly isn't easy to do.

 

Talent is Overrated

Or so says Geoff Colvin.

If someone tells you, "I know the secret to super performance, and it's not talent," you know what the answer is, right? Hard work. Which is basically what this book says. He actually says it's 10 years of hard work to become an world-class performer.

He takes it a little further, explaining the necessity for "deliberate practice" as opposed to just regular practice. The difference is most obvious in activities with clear goals. It's free-throw shooting for hours instead of pick-up games. Repeatedly working through a knotty part of that concerto with deep concentration, not just breezing through easy pieces.

For software developers, I thought TDD would be a good analogy. TDD forces you to regularly think about testing your software, until you're writing good, modular software by second nature, and you can do it with increasingly complex applications.

To do effective "deliberate practice" in business professions, you often need a mentor -- someone who's better than you are -- to tell you, "This is one thing you should work on, and here's how you can do it." That focuses you on building the right skills.

He provided some good research about external and internal motivation. Basically, your intrinsic motivations will outweigh everything else. Managers have to figure out what that is for each person and how to arrange the work accordingly; motivation can't simply be bought.

Books like this can be useful as a reminder about how you want to spend your day, but since I had a good idea what he was going to say, I wouldn't normally have picked it up.

But, I saw some effusive praise on the back cover from people I admire: Daniel Pink, Herb Kelleher, a couple others. (Oh yeah, Donald Trump is there too.) Then I found out they're all cited in the book either as vanguards in the research he quotes, or as examples of outstanding performers --no wonder! In the end, the book is overrated.

Bruce Eckel, publishing revolutionary

According to my recollection, Bruce Eckel put out the first digital book for free at the same time he had a best-selling hard copy at the book store. I believe the free version played a big role in Thinking in Java selling so well. At my dot-com, everyone who learning java started with his book, being free, and then eventually most of us bought it.

He made his book not only free on-line, but downloadable as both pdf and html. He didn't try to ramp up website stats by making you read the html on his site.

I actually thought that Bruce's successful example would herald a new day when free digital versions of book would become more common. Trying to break through a cluttered market can be difficult, and offering a free version might be the answer.

That day never came. So Bruce remains an anomalous experiment. I'm glad it paid off for him.

Bruce's latest idea (part of this interview) is equally brilliant.

I hope to make [the latest version of Thinking in Java] a community effort, to be published electronically under the creative commons.

Not that we need intro to java books so much these days -- but all the more reason to embed it into the landscape permanently. Give it to the software community, who knows what it will turn into. At the least, it could become the final, definitive book on learning java as a beginner.

A truly radical and fitting end to a book that started radically as well.

Making Things Happen by Scott Berkun

I basically picked it up Scott Berkun's Making Things Happen because I enjoy Scott's blog, and some other writers had good things to say about the book. When I started reading I couldn't understand the hype. How did this get a second edition?

After a while, I realized the book shouldn't be read cover to cover. Or, rather, that's only part of its value.

It has a second use as a desk reference for all those problems that a project manager or team lead might run into, almost like an encyclopedia. He covers items big and small, over an extremely wide range, such as:

• What's the best way to run a meeting?
• What should you do if you've tried everything and you can't get someone to respond to your request?
• How can you improve your decision making?
• What's the best course of action if you're the new PM on a project and the Coder Who Knows Everything seems disrespectful of you?
• What options do you have if higher-ups require the team to follow processes that you disagree with or the team hates?
• Are work politics evil?

I particularly enjoyed Scott's war stories from his time working on Microsoft Explorer. He didn't really start rolling those out until a third into the book, and that may have contributed to my initial ambivalence about it.

In the end, the breadth of the material, delivered succinctly but with personality, impressed me. The book offers a comprehensive list of real-life issues and strategies.

New managers could read the whole thing and use it as an initial template, weeding out what doesn't work for them. More experienced managers can dip into it when needing guidance on a particularly thorny project.

Making It Happen is a practical guide for project success.

Best software dev books

I'm in the middle of reading Agile Software Development, and it has already cracked my top 5 favorite software development books of all time. A more detailed review will be forthcoming.

My five favorite software development books (with links to Amazon because the reviews can be helpful):

Code Complete by Steve McConnell
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
Effective Java by Joshua Block
Refactoring by Martin Fowler
Thinking in Java by Bruce Eckel

Also see this somewhat scientifically compiled list of the best software dev books of all time by Jurgen Appelo. Perhaps not surprisingly, three of mine show up in the top 10.

I see I have left off The Mythical Man-Month, which is a classic; very insightful and still highly relevant. That one probably would bump Thinking in Java, but I'm giving Eckel extra points for being a vanguard and publishing for free. I'm surprised more people have not followed this path -- and yes, I ended up buying a hard-copy. I haven't read five in the top ten.

Antipatterns by Philip Laplante

I loved the idea of this book. Knowing what you don't know, as a starting point, often helps you know more. True story: many years ago I considered writing a dictionary of what things aren't, an anti-dictionary. Some words are simply too big or too ambiguous to get boxed in. What is "life" for example?

Similarly, recognizing dysfunction can help you operate more functionally. This book tries to categorize the ways a manager or an organization can be dysfunctional.

One strong point of the book is that the list of antipatterns is pretty thorough. Most of them are instantly recognizable, especially if you've worked in a few companies. Some you recognize, but might not have thought of before as problems, like Warm Bodies -- people who should actually be let go, but just get passed around from one ill-fitting job to another.

The section I liked the best was "Identification". If you answer yes to the questions in this section, you may be facing this antipattern. Many times, these questions were not obvious, and helped illuminate the antipattern.

For example,

Everybody likes John — but no one can figure out what he actually does.

is a subtle way of identifying a Warm Body. I knew the antipattern, and have seen people like that, but never thought that the two might be connected (and of course they aren't always).

In addition, the writing was very accessible, and the authors allowed their personality to show, which always makes a book more enjoyable.

Noticeably lacking was what to do when confronted with one of these antipatterns. If you find yourself behaving this way, the advice almost always boiled down to "stop doing it." Not too helpful. Frequently, if you find someone else doing it, the advice was to "try to ignore it" or "schedule around it" or "sit back and laugh about it". Not too helpful.

An even bigger oversight was a lack of examples and explanations of why these behaviors occur, and what, if any, positives arise from them. They did a great job with Rising Upstart -- a young, very eager achiever -- recognizing that this is both a benefit and something that needs to be handled carefully. But most of the time, the antipatterns were treated as an illness that only ogres and irrational people would fall victim to. If these behaviors are rampant, there must be underlying causes.

For example, Mushroom Management -- the problem of managers keeping everyone in the dark (mushrooms grow in the dark) -- was rightfully decried as breeding suspicion, sucking down morale, and being ineffective. Still, some analysis about why managers do this would contribute to a richer understanding of how to deal with it.

One underlying cause is that more communication is not always better. In this depressed economic time, constant communication about the latest management thoughts on layoffs would be counter-productive. Management might be keeping their mouths shut because sensitive decisions are being made. Given that, what is the best way to handle the situation? That becomes a more meaningful discussion.

This book will be most useful to people starting their careers or those who are just beginning to think about moving into management. Many of the antipatterns can be avoided, and identification is half the battle. As an introduction to what not to do, this is a great start.

Emergent Design by Scott Bain

Emergent Design presents Scott Bain's vision for turning software development into a respected profession. Just as medicine became professionalized as physicians replaced witch doctors, he argues software development can go through a similar transformation. Bain then runs through some principles, patterns, practices, and processes that reduce the mystery and thus the high fallibility of software development.

The industry has been on an upward trend, in large part to increasing acceptance into new organizational and coding techniques, including many that he discusses here. According to the Standish Group, the percentage of projects considered "successful" grew from 16% in 1994 to over 33% today. This book seeks to continue the progress by democratizing the latest development tools and concepts and increasing their usage through all levels of software organizations.

As a result, Emergent Design is primarily useful for three types of readers:

• junior to mid-level coders who have coded a bit and want to take it to the next level. Mid-level coders who don't think much about design and extensibility should be the first ones in line. Coders just starting out should probably get a few "Learn Java in 21 Days" type books under their belt first in order to see the benefits.
  


• experienced coders in procedural or older languages making a move to an OO language, and want to do it the right way.
  


• technical managers who are responsible for hiring and/or architecture, and ultimately responsible for the quality of the product that comes out of their shop.

The book covers a wide range of topics. It primarily focuses on key concepts of good code, design patterns, and test-driven development. The discussion on key concepts, for example cohesion, is particularly useful for the many programmers who didn't start out as computer science graduates, or as a review. His explanations run deep without being dry. The writing style is excellently conversational. He comes across as a teacher with lots of patience.

Bain's strongest skill is creating very simple metaphors to illustrate his points. Though simple, the metaphors really strengthened his explanations of the design patterns. I'll never forget the difference between the Decorator and Strategy patterns thanks to his metaphors. In fact, these metaphors help identify when patterns should be used, because unlike other pattern books I've read, he talks about what the pattern looks like -- in real life and in non-OO code. As a result you can recognize the need for the pattern as you're working out the business problem, not as you're writing the code.

As a result of reading his book, I've started following Scott's blog. He posts only about once a month, but they're good posts and, as expected, full of good metaphors.