About Duffbert...

Duffbert's Random Musings is a blog where I talk about whatever happens to be running through my head at any given moment... I'm Thomas Duff, and you can find out more about me here...

Email Me!

Search This Site!

Custom Search

I'm published!

Co-author of the book IBM Lotus Sametime 8 Essentials: A User's Guide
SametimeBookCoverImage.jpg

Purchase on Amazon

Co-author of the book IBM Sametime 8.5.2 Administration Guide
SametimeAdminBookCoverImage.jpg

Purchase on Amazon

MiscLinks

Visitor Count...



View My Stats

« Book Review - Illusion by Frank Peretti | Main| Book Review - Squeezed: Rear-Ended by American Politics by J. C. Bourque »

Book Review - The Developer's Code - What Real Programmers Do by Ka Wai Cheung

Category Book Review Ka Wai Cheung The Developer's Code - What Real Programmers Do
The Developer's Code

I like books that gather a number of essays and thoughts about technology (in this case, software development) and bundle them in a single volume so I can contemplate what it is I do as a profession.  The Developer's Code - What Real Programmers Do by Ka Wai Cheung (published by Pragmatic Bookshelf) fits that description perfectly.  I've often said that one or two gems from a book like this can make it an excellent buy.  For me, this one met and surpassed that criteria.

None of the essays here (52 in total) are technical in nature.  You won't learn a new way to code algorithms or do systems architecture.  Instead, they delve into mind-sets and concepts on how to think about the work and how it's done.  An example would be the first two essays in the section on metaphors in software development.  Since we've equated software construction to building construction, we tend to over-plan a system and nail everything down before we write a single line of code.  But in reality, code is flexible and changeable, whereas bricks and mortar can't be easily "fixed" once it's put down.  The metaphor of "construction" means that we may over-plan before writing code (think waterfall vs. agile), thereby limiting our productivity.  Metaphors aren't bad, but you do need to be careful that it doesn't inadvertently create boundaries that don't exist.

I personally found the section on teaching fascinating.  Specifically, "Lie to Simplify" put words behind a problem I fall prey to on far too many occasions.  When trying to teach someone a new skill or feature, I want to tell them absolutely everything... all the edge cases, the minor oddities, and the obscure errors where things don't work as advertised.  The problem is that the student doesn't even understand the basic concepts, much less the esoterica.  Rather than dump everything on them at once, just lie. Tell them how things work in 95% of the situations. Don't even mention the exceptions... until they've mastered the basics.  Once they know that knowledge, you can fill in the blanks.  That single essay right there will change the way I convey information to others.

Since everyone comes from different backgrounds and experience levels, everyone will have different reactions to The Developer's Code.  But I think I'm safe in saying it's well worth reading, and you should easily find the two or three gems that will make your purchase a wise investment in yourself.

Contents:
Introduction: Who Is the 21st-Century Programmer?; Discovering the Lessons Firsthand; This Book Is About Us
Metaphor: Follow Metaphors with Care; Plan Enough, Then Build; Launch Is Just the First Release; The "Ivory Tower" Architect Is a Myth; Throw Away Your Old Code; Diversification Over Specialization; Metaphors Hide Better Ways of Working
Motivation: The Perks Are in the Work; Begin Where You Love to Begin; Be Imperfect; Stop Programming; Test Your Work First Thing in the Morning; Work Outside the Bedroom; First Impressions Are Just That; The Emotional Value of Launch; Find an Argument
Productivity: Just Say "No" to the Pet Project; Constrain All of Your Parameters; Cut the Detail Out of the Timeline; Improve Your Product in Two Ways Daily; Invest in a Good Work Environment; Keep a Personal To-Do List; Create "Off-Time" with Your Team; Work in Small, Autonomous Teams; Eliminate the "We" in Productivity
Complexity: Sniff Out Bad Complexity; The Simplicity Paradox; Complexity as a Game of Pickup Sticks; Keep Complexity Under the Surface; "Hard to Code" Might Mean "Hard to Use"; Know When to Refactor; Develop a Programming Cadence
Teaching: Teaching Is Unlike Coding; Beware the "Curse of Knowledge"; Teach with Obvious Examples; Lie to Simplify; Encourage Autonomous Thought
Clients: The Tough Client Is Ubiquitous; Demystify the Black Magic of Software; Define the Goals of Your Application; Be Enthusiastic and Opinionated; Be Forgiving and Personable; Value Is Much More Than Time; Respect Your Project Manager
Code: Write Code As a Last Resort; A Plug-in Happy Culture; Code Is the Ultimate Junior Developer; Separate Robot Work from Human Work; Generating Code at Its Core; The Case for Rolling Your Own
Pride: We Have a Marketing Problem; Lessons from the Cooking Industry
Bibliography

Disclosure:
Obtained From: Publisher
Payment: Free

Comments

Gravatar Image1 - "Plan Enough, Then Build". Exactly correct. How often, in the corporate world, were we asked to present a minutely-designed project as a total package, before approval to begin is given. Then, 6-8 months later (if you're lucky), the official assessment is "we've got to learn from our mistakes."

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)

Want to support this blog or just say thanks?

When you shop Amazon, start your shopping experience here.

When you do that, all your purchases during that session earn me an affiliate commission via the Amazon Affiliate program. You don't have to buy the book I linked you to (although I wouldn't complain!). Simply use that as your starting point.

Thanks!

Thomas "Duffbert" Duff

Ads of Relevance...

Monthly Archives