Scott Hanselman

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

Professional ASP.NET 3.5 :)

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.

any good suggestion on jumpstart in c#?

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

+ I've added another author to my list of blogs ... *sigh* so little time !

Thank you Scott. It's always useful to hear what people are reading (and what they like).

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.

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.

@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.

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).

"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.

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.

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.

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!

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

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.

1. How to Solve it - Droomey (for the newbies)
2. CLR with C# - Richter (for the geeks)

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.

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.

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.

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.