Scott Hanselman

Books: We need more So What, Now What and What For? and less just What

April 24, '08 Comments [23] Posted in ASP.NET | Musings
Sponsored By

Have you ever looked at a word you use and see every day, like the word "What," and suddenly start doubting yourself and wonder if it's spelled correctly? There you go. What. Is THAT how it's spelled? That doesn't look right. Why would such a simple thing suddenly be called into question?

Anyway, there's a glut of technical books out there, and I'm starting to realize that I take their style and their existence for granted. They usually describe what some product is and what it does.

I really enjoy books/blogs and writing that spend less time on the What and more time on the So What? and Now What? and What For? I'd like to see more books that put technologies into a larger context and less on just What.

It'd be interesting to take any book title and add one of these phrases to the end, like "Professional ASP.NET 2.0, So What?" or "Ruby on Rails, Now What?" or "SQL Server, What For?"

What For?

The Ruby Way does a good job explaining What Ruby is Good For. It answers the Why, to me at least, very well. It's the best book I've found that doesn't just teach Ruby syntax, but also Ruby idioms; it's mastering idiomatic structures that brings fluency in any language, human or computer.

Programming Pearls - I used this book while teaching my C# Class at OIT even though it had nothing to do with C# because it's just that good. It's a series of collected articles from Communications of the ACM. It helped me understand what a number of things were for. I better understand computer problem solving, what Math is for (its relationship to programing, which isn't always clear to everyone)

How to be a Programmer (free) by Robert Read - This is a fun, short read that is general enough that it makes sense in most languages. If you want a CS101 (or 201) practical refresher, this is a great book that answers mostly "how to" questions, but ultimately explains what a number of technique are for.

So What?

Dissecting a C# Application: Inside SharpDevelop is a fantastic book and one of my favorites because it's a story that's full of So What? answers. They talk about what they tried, what failed, what didn't and how they moved forward. The Reviews on Amazon aren't all favorable as one reviewer says this is "an extremely difficult book from which to learn" but if you learn, as I do, from reading source with explanations of design decisions, then this (slightly old, but still useful) book is worth your time.

Programming WPF by Chris Sells and Ian Griffiths (his blog is a technical joy) is great because the authors are always trying to answer these "so what" questions. Chris is like this in real life. "So What?" is, I think, his number one question as he takes little for granted. If you read Ian's blog, you know his knowledge is deep to the point of being obscene (that's a good thing) and when you put these two guys together you get a great book that answers, for me, WPF, So What?

Now What?

OK, after I've learned a technology, Now What? What's the next step in my learning and what should I do?

The Pragmatic Programmer by Andrew Hunt and Dave Thomas is a book that answers a lot of Now What questions for me. It shows a complete, pragmatic attitude towards the software development lifecycle. I wouldn't say it's complete in an Enterprise sense, but good for medium-size projects, and most of the general kinds of things you're going to bump into.

In May, my friend and long-time compatriot Patrick Cauldwell will release Code Leader: Using People, Tools, and Processes to Build Successful Software which I read, enjoyed and happily wrote a foreword for. This is a book based on Patrick's "This I believe: The Developer Edition" post of last year. He takes many different tools and processes and answers the Now What? question.

Making Things Happen by Scott Berkun is an update to The Art of Project Management and I now have both editions. Scott answers lots of the Now What questions in a comfortable, conversational tone with a deep focus on getting things done in software development. He helps with planning and execution.

Your Turn

This is a woefully short list. Perhaps I'm missing something, but other than actually doing it (and failing and trying again) there aren't a lot of books that describe how to build large, complete applications that support the entire software development lifecycle.

What books have you read that answer these So What, Now What, and What For questions?

Related Links

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Thursday, April 24, 2008 10:57:15 PM UTC
Sadly not updated since the first .NET framework, Bill Wagner's 50 Specific Ways to Improve Your C# is a great "What For" book that details why things should be done one way rather than another.

Essential .NET, Volume 1 by Don Box and Chris Sells is awesome as a "What For" title.

And my favorite "Now What" is probably Joshua Karievsky's Refactoring To Patterns which answers the important question: what do you do with all of these design patterns you've just memorized?

James
Thursday, April 24, 2008 10:57:47 PM UTC
Professional ASP.NET 3.5 :)
Todd
Thursday, April 24, 2008 11:01:18 PM UTC
I would add Everyday Scripting with Ruby: For Teams, Testers, and You by Brian Marick. He does a great job at answering the "What For?" question for Ruby. Good stuff.
Thursday, April 24, 2008 11:26:17 PM UTC
any good suggestion on jumpstart in c#?
Thursday, April 24, 2008 11:31:15 PM UTC
Great article, except it cost me time (to research all the books and authors mentioned) and money (at amazon to buy some of them!) :-) - Steve
Thursday, April 24, 2008 11:33:01 PM UTC
+ I've added another author to my list of blogs ... *sigh* so little time !
Thursday, April 24, 2008 11:35:14 PM UTC
Thank you Scott. It's always useful to hear what people are reading (and what they like).
Thursday, April 24, 2008 11:37:57 PM UTC
Amen...

I like the idea of Meta-books.. I'm thinking of a combo book -> Choose a domain then cover an implementation (in the author's chosen style) from UI all the way down to the persistent data store. Then do a series where the same Domain'/Context/Problem is solved with an alternate set of technologies (.Net vs Java vs Ruby).

One of these days when I get of my duff and learn enough I'd like to create a simple, semi-novel, sample app solved in the later way (.Net vs Java vs Ruby). Same UI end result - but with mixed implementation strategies and technologies.

Brad Mead
Thursday, April 24, 2008 11:45:29 PM UTC
The Alt.Net-r's turned me on to this:

Domain-Driven Design: Tackling Complexity in the Heart of Software and I typically read it with Design Patterns in C# at my side.

They are covering the "so what" and "what for" regarding advanced concepts for me.
Brad Mead
Friday, April 25, 2008 12:23:01 AM UTC
@Todd Professional ASP.Net 3.5 is definitely "just" a "What" / "How" book, it's not deep enough in any specific functional area to be more. Although, there are many "Whats" covered very well (in 2 languages no less, gotta make a book as heavy as a brick somehow =).

Not to go all Atwood on you, but Code Complete is a great "So What?" book for learning to be a software developer.
Friday, April 25, 2008 1:24:56 AM UTC
The Head First series by O'Reilly is particularly innovative in that it sacrifices the amount of code examples and long text descriptions in favor of answering the "what" questions in a visually stimulating way. In particular, I would single out Head First Design Patterns.

That raises another question for another time . . . why is it so hard to find a programming books that looks good as well as has quality content? Would color be such a bad thing? If book publishers are thinking "that's just for design types and not for geeks in technical fields", then they're mistaken. Pick up a copy of Science or Scientific American and you'll find excellent examples of intricate diagrams and carefully drawn charts that add value to the reading experience. (Disclosure: I purchased Chris Sells book 30 minutes before reading this blog and not only do I like the overall layout of the text, but it is also one of the few that does have a section of color).
John
Friday, April 25, 2008 2:10:17 AM UTC
"Software Estimation - Demystifying the Black Art" is a very worthwhile book. I wrote a review of it here. It has just a ton of common sense information on how to estimate software for different purposes, and more importantly, how to present an estimate in a way that the appropriate information is conveyed... as in providing ranges to denote the accuracy of your estimate.
Friday, April 25, 2008 6:20:27 AM UTC
I'd like to be the first to add Joe Armstrong's Programming Erlang.

I'm not sure whether it scores higher on the What For or the So What dimension, but it does a really good job of explaining Erlang in the context of also explaining what Concurrency-Oriented Programming is, why COP is important right now, and how to do COP well in Erlang.

A great language book for a language that's both different and useful, but much more than just a language book.
Friday, April 25, 2008 6:33:11 AM UTC
Just finished reading Refactoring Databases: Evolutionary Database Design by Ambler and Sadalage. The first five chapters cover the "Three Whats" and the rest of the book provides the technical refactoring patterns.

Recommended for anyone developing a new app with a new database and anyone working with an existing enterprise database accessed by many apps at various stages of development too.
Friday, April 25, 2008 7:26:24 AM UTC
Let me put my vote on Bill Wagner's Effective C# 50 Specific Ways to Improve Your C# -- too bad there's not an updated version. I tried to contact Bill, but I was never able to get a reply from him.

I find C# 3.0 In a Nutshell quite useful. I actually look there, and usually find the answer, before trying a search engine.

Here's my gripe with computer books, the ones I've picked up and tried to use:
1) Incomplete / Shallow - I can't tell you how many times I've found the topic in the book and then was left out in the cold; waste of paper.
2) Very little real-life examples, most seem to be catered for hello-world applications, even in super duper advanced books, yeah... thanks.
3) Where are the gotchas? Where's the guidance? I need to be told not to go down that path because X and Y, or if I decide to do so I may want to know what to look out for.

Sorry for being so negative, but if any book author reads this blog they need to hear this: If finding the information is faster on the web than from your book then please save some trees and don't publish.

Peter.

P.S. Does anybody know of book that explains common business patterns from a developer's point of view. For example how accounts work, debit, credit, invoicing, payments, how I should link them and why? Stuff that probably gets passed down as wisdom from senior developers, but can be very difficult to find for a newbie in the subject. Thanks!
Peter
Friday, April 25, 2008 10:37:59 AM UTC
Hi Scott,

I noticed that Ian has blogged about Nulls and Lifting Member Access
http://interact-sw.co.uk/iangblog/2008/04/13/member-lifting

and today my Microsoft Connect proposal to update the C# compiler has been rejected.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=306293

Is this pure coincidence or was Ian in the comittee to decide about the next features for the C# compiler but likes this idea personally?

Yours,
Alois Kraus
Friday, April 25, 2008 12:44:26 PM UTC
Matt
Friday, April 25, 2008 8:03:13 PM UTC
Working Effectively with Legacy Code by Michael Feathers is an amazing book that has prolly had the most effect on my practices since Code Complete.
Saturday, April 26, 2008 3:16:09 PM UTC
1. How to Solve it - Droomey (for the newbies)
2. CLR with C# - Richter (for the geeks)
Saturday, April 26, 2008 4:24:20 PM UTC
In a similar vein to "Dissecting a C# Application: Inside SharpDevelop", Ron Jeffries "Exteme Programming Adventures in C#" takes you through the process of building an application, using XP and TDD. If you're curious as to how developers use TDD to produce software, this is a great read.
Sunday, April 27, 2008 11:25:23 PM UTC
Great article,

You've pinned down that programmer's epiphany that seperates the coders from the developers...
Coming to the realisation that you can spend the rest of your life learning new technologies, but to advance as a developer you have to start asking why... I think a lot of people get trapped in the programming rut, and lose sight of the bigger picture.
Adam Langley
Tuesday, April 29, 2008 3:28:47 PM UTC
Perhaps I missed it, but no one mentioned Jimmy Nilsson's Applying Domain-Driven Design and Patterns. It has certainly scratched the itch for me that Scott is describing.
I also really liked the two books Brad Mead mentioned too, both really helped me with these questions.
Sunday, May 18, 2008 10:57:57 PM UTC
Scott,

You've put your finger on an important issue. The "now what?" issue faces just about every developer when they sit down to work on a new technology. And the overwhelming majority of books are only going to give you the "what"? The problem is borne out by the fact that you and your blog readers (who undoubtedly represent voracious consumers of tech books), can only come up with a short list of worthwhile books that go beyond the how-to.

So what's the problem? Are technical authors blind to the true need of developers? Not likely. When authors can write books on topics as obscure as... I don't know... using Haskell for embedded medical device OS's, and still make money, you would assume that some authors would address a much more common need.

But let's look the problem domain from the author's point of view. Say that an author wanted to write a book about the construction of an application -- what it's really like and how it really happens. All the gotchas, the difficulties, the triumphs, the compromises, etc. I'm talking here about a real application, not a contrived one made just for a book.

To be useful, that application would have to be open source. Any narrative that relied on an application couldn't say, "imagine code here". And the "whole picture" that the code base represents is vital. If you're a developer on a large, line-of-business application, it's doubtful that your company (or client) would be too interested in releasing its source code. Most businesses build applications to get a competitive advantage. Releasing that to the world, so that you can have a good book, doesn't make a lot of sense. Never mind the issue of fairness to the other people on your team. What credit do they get for the book?

Or maybe you have a great idea for an application that would be viable in the marketplace. Say that you're developing an application that would revolutionize the way chimneysweeps work. Chances are, when you have the option of making money off the lucrative chimneysweep market or just building that application to supplement your book, you're going to go for the commercial product.

So now your project is open source. I love the open source community. But working on a project like that is decidedly different from working on an application for a paying company or client. So some potentially valuable guidance is off the table for your book. Keep in mind that, in choosing an application, you have the opportunity to turn off another portion of your readership. Someone could say, "An application for chimneysweeps? How boring."

Regardless, your market will always be filtered down to the people interested in the particular technology that you use to build the companion application for your book. This is the starting point for the typical technical book. Potentially, anyone interested in C# could benefit from a compendium of its features. It's not likely you'll attract the Java, Ruby, OCaml, etc. crowd. But for the "now what" book, the audience dwindles further. Since it will be a certain type of application, you will start eliminating more parts of your audience. If it's a web application, you lose desktop developers. And, as we all know, there are many ways of achieving the same thing in application development. Say that you were building your application on the MVC pattern. There is a segment of your audience who either wouldn't care for that or would be actively repelled by it. They won't buy your book.

And finally, when you leave the how-to paradigm, more burden falls on the writing skill of the author. Even people who aren't interested in the craft of writing can do a credible job of listing features or talking about typical ways of applying them. In order for a "now what" book to succeed, the author would have to take on the more complex task of describing how decisions are made for software architecture, and why they are made. Real-world applications have a way of taking on complexity fast. It's a difficult job for the reader to expend the energy to grasp it (especially when he probably has his own complex applications at work to figure out) and it's a difficult job for author to present it in a way that is understandable and engaging. Then throw in the fact that, because technology changes so fast, the technology that was the subject of the book may be old news by the time it's done.

I'm not saying it's impossible, far from it. On your recommendation, I'm planning to check out "Dissecting a C# Application: Inside SharpDevelop", and I'm hoping it will be the kind of book I'm describing. Incidentally, I'm not surprised to see that the subject of the book was an open source project, and I'm not surprised to hear that some reviewers on Amazon objected to the way it was constructed.

But back to someone who's considering a "now what" book. Look at the risks. From a publisher's perspective, he knows that a book that gives you the "what" of the technology will have an audience, even if it's not masterfully done. Not so for a "so what" book. For the author, if he can't push a publisher into accepting that kind of proposal, he could decide to do it on his own. Because he has the ability and willingness to write this kind of book, he's going to be someone working in the industry, and extremely busy building and delivering projects. If he commits the time, writes the book on spec, then can't sell it, he's put a whole lot of blood, sweat and tears down a rat hole.

I heard an interview with Steve Mcconnell where he said that he wrote Code Complete during a "dead period" in his life. One where he had just finished a big project, then took a break from development and did not have family commitments and onerous bills to pay. We're all the better for it, but needless to say, that was a fortuitous coincidence. You can't count on that situation repeating often enough to fill our bookshelves with books of the same kind.

And if you're wondering why I've put so much thought into this, it's because I've always wanted "now what" books to be available. And consequently, I've wanted to write that kind of book. I make my living as a consultant delivering software, and it would be tough to put that career on hold long enough to pull that kind of thing off. I think I've finally thought of a way to make something similar happen, but I don't envision it being a commercial venture, for the reasons I listed above. We'll see. :)

Keep up the good work, Scott, with your blog, your podcast and your probing intellectual curiosity. It matters a lot.

Rob Collins
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.