Books: We need more So What, Now What and What For? and less just What
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. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
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.
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.
Not to go all Atwood on you, but Code Complete is a great "So What?" book for learning to be a software developer.
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).
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.
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.
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!
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
2. CLR with C# - Richter (for the geeks)
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.
I also really liked the two books Brad Mead mentioned too, both really helped me with these questions.
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.
Comments are closed.
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