Sleep Your Way to a Better You

Did you get enough sleep last night?  If you're a typical American worker, the odds are you didn't.  Our culture tends to promote sleep deprivation as a badge of honor.  The heroic act of burning the midnight oil makes us really, truly productive... or does it?

I recently read the book Rework, which questions our culture’s devaluation of sleep.  The book challenges several conventional ideas about being productive, but the parts on sleep hit close to home for me. 

The authors point out that we're less creative when we're tired.  This causes several problems.  We often just slog through mundane tasks if we're bushed.  Also, we fail to have insights or epiphanies as we perform our tasks.  The most productive workers aren't 10 times as fast as everyone else.  They don't work 10 times as long.  Often they're the ones that come up with creative solutions that take 1/10th the time. 

Overall I found Rework fairly entertaining.  It’s a quick read and full of tips about staying innovative, productive, and awake at work.

Book Recommendation: The Mythical Man-Month

I end up reading a lot of software engineering books for my classes at PSU’s OMSE program.  “The Mythical Man-Month” is the first assigned book in the curriculum, and for good reason.  It’s one of the seminal texts on the topic of software project management, and offers several insightful ideas.

About The Author

Fred Brooks worked for IBM in the 50’s and 60’s as a manager for their OS/360 operating system.  He’s very articulate and uses plenty of humor and interesting historical references in his writing.   Here are a few of the book’s highlights:   

Brooks’s Law

Fred’s quote "adding manpower to a late software project makes it later” became known as Brook’s Law.  He argues that just as nine women can’t make a baby in one month, additional developers don’t necessarily help you release software sooner.  This is caused by the communication and training required when adding new team members.

No Silver Bullet

Brooks asserts that there is no magical tool or methodology that will provide software engineers a 10 fold productivity gain.  He separates the essential difficulties of producing software (e.g. Complexity, Difficult to Visualize) from the “accidental” difficulties (Lack of Tools, Clunky Languages).  It’s a good concept to keep in mind with the next development fad comes along offering to solve all of your problems. 

Conceptual Integrity

The book emphasizes the importance of preserving the conceptual integrity of the system, especially on large projects.  Brooks makes the case for a single architect (or small group of architects) creating the design of the overall product.  He offers some good tips on how the people working on the big picture should interact with the engineers implementing the design.

Why Would I Read This Book?

I’m a big fan of history and think there’s much to be learned from the successes and failures of past generations.  Although this book discusses some ancient programming practices that we (thankfully) don’t have to deal with today, I think it’s a great read for anyone concerned with delivering a software product on time and under budget.