Jenny and I are really proud to announce that the second edition of our bestselling C# learning book, Head First C#, went to press! We worked really hard on it, and we’re very happy with how it came out.

Are you looking for the easiest way to become a great C# programmer? If want to get productive fast with C#, .NET and Visual Studio 2010, then this is the book you’re looking for. We show you how to learn C# by building over 100 different projects—including lots of games!—and solving dozens of puzzles.

Head First C# is a complete learning experience for programming with C#, the .NET Framework, and the Visual Studio IDE. Built for your brain, this book covers C# and .NET 4.0 and Visual Studio 2010, and teaches everything from inheritance to serialization.

But don’t take our word for it! Download the free Head First C# eBook [PDF], which includes the first three chapters, complete. Or have a look at this typing game project [PDF] from chapter 4 to get a preview of the kinds of projects you’ll build throughout the book.

So check out Head First C# today, and see what the buzz is all about! Available now from O’Reilly, and wherever fine books are sold.

“I teach Project Management for for a project management firm and its clients. Using Head First PMP exclusively as the course material, my students have an 84% first time passing rate for the PMP and CAPM. This is by far the very best and most complete book for anyone looking to improve their project management skills and pass the PMP exam.”

—Rocket Williams, PMP, MCITP, MCT
Director of Business Development and Project Management Processes
AdaQuest, Inc.

Jenny and I just put the finishing touches on the second edition of Head First PMP, and it should be out in bookstores as soon as it comes off the presses. We’ve brought it completely up to date to provide 100% coverage of the new version of the PMP exam. It was definitely a lot of work — and in case I haven’t mentioned it lately, I’m lucky to have a coauthor who’s as committed, hard-working, and quality-oriented as Jenny! You can download Head First PMP, 2nd Edition today as an O’Reilly Rough Cut PDF (see the end of this post for details).

I’m really impressed with all the changes that PMI put into the PMBOK® Guide, 4th Edition (which is what the PMP exam is based on). When we first wrote Head First PMP, there were a few concepts and ideas in the third edition that Jenny and I found a little challenging to explain in a straightforward way that’s easy to understand. When we read the new PMBOK Guide for the first time, I was happy to see that they’d improved some of the more cumbersome concepts that people had a really tough time understanding — like the difference between a scope statement and a preliminary scope statement, for example. Now that the preliminary scope statement’s gone, scope management makes a lot more sense.

And there are new additions that made me really happy. It was great to see a whole new process dedicated to collecting requirements. If you’ve read my Requirements posts, you know how important I think requirements management is to making sure your projects are successful. I’ve believed for a very long time that project managers — especially for software projects — have a responsibility, even an obligation, to make sure the whole team understands the project’s requirements. That’s why we put a whole chapter on requirements in our first book! So the Collect Requirements process is a really welcome edition to the PMBOK Guide.

There was another really interesting addition: the addition of iterative project phases. I think it’s really useful that the project management world has increasingly embraced iterative project development, especially in software. Personally, I attribute this, at least in part, to the fact that Agile development has soared in popularity over the last few years. The fact that project managers are being trained to work with teams working iteratively is a really good development, and it’s great to see that being reflected on the PMP exam.

Also, it was nice to see that the Manage Stakeholders process got a new name: it’s now the Manage Stakeholder Expectations process. I always thought it seemed a little… unrealistic? yes, that’s a good word — it always seemed a little unrealistic to think that a project manager could actually manage stakeholders on a real project. But managing their expectations is something that every project manager needs to do in order to keep a project running.

There are lots of other PMBOK® Guide changes, big and small, and we’ve put months of painstaking effort into tracking down each one and making sure the book is completely up to date. And we put together a phenomenal review team to help us ensure that Head First PMP, 2nd edition has 100% coverage of the new version of the PMP exam based on the PMBOK® Guide, 4th Edition.

Oh, one more thing. I wanted to take a minute and thank all of the people who’ve been writing to us and asking when the new edition of the book is coming out. I’m sorry I couldn’t write back to each of you individually; we’ve been working really hard to make sure the new edition is as accurate and easy to use as possible, and we just didn’t have time to answer all of your e-mails. But we definitely heard you, and want you to know that we think the second edition is even better than the first! And, as always, if you’ve got questions about project management or difficult PMP topics, definitely send them to us. We get a lot of questions and e-mails, and don’t always have time to answer each one, but we do love Q&A and if it’s a good question we’ll try to write a good answer!

You can download Head First PMP, 2nd Edition today as an O’Reilly Rough Cut. They’ve got a great deal where you can get the online rough cut PDF today when you pre-order the book! Or you can just pre-order the book and get 35% off.

Forbes picked up our Beautiful Teams interview with Tim O’Reilly and published it as an article called The Secrets of Great Teamwork.When Jenny and I talked to Tim, he had some intriguing things to say about what makes people work together. There’s plenty of good stuff in the interview, but one bit that really sticks in my mind is this excerpt:

Andrew: Do you think it’s possible to have a great team that doesn’t have a great leader? That has more of a collective leadership?

Tim: Yes, it is possible. But here’s the thing. Take Apache, because I think Apache is a great example of that. Tim Berners-Lee laid down the blueprint. He said, “I’ve created this idea for this hypertext server, this hypertext client.” And the genius of Apache was in embracing the constraints. I still remember back in the mid-’90s, this moment where Netscape had added this, Microsoft had added that, and everyone was saying, “Apache seems to be standing still. They aren’t adding all these features. They aren’t keeping up!” And the guys at Apache said, “Yup. What we do is a hypertext server, and we have this nice extension mechanism where people who want to do something else can add it on.”

And that goes back to that architecture of participation. They didn’t build this big, conglomerate, complex application. They kept to a pure vision. The vision did actually come from a visionary leader; it just wasn’t part of Apache. Apache came from a group of people who were abandoned by the NCSA server team when they all went to found Netscape. And there were a bunch of customers, so they said, “We have to maintain this, and keep it going.” What was wonderful about that kind of team was that they accepted the constraints that were laid down by the design of the system. They didn’t try to show off their ego or their creativity.

I think a lot of the work done by the IETF (the Internet Engineering Task Force) in the early years did the same thing. There were some wonderful principles laid down, and people really honored them. If you read some of John Postel’s stuff in the TCP RFC about the robustness principle, it sounds like something out of the Bible, for Christ’s sake! “Be conservative in what you do; be liberal in what you accept from others.” Literally, that’s what it says.

The point is that if you have the system architected right, you have a better chance of success for teams. You don’t want teams that are dependent on a single vision or leader, because if you loseWeight Exercise your leader, the whole team goes “pop.”

Something that came up over and over again throughout our many interviews and stories is the connection between teamwork and architecture.  I think Tim hit on exactly the right example with Apache, but there are a lot of other examples throughout the book. Peter Glück had some really interesting things about how the architecture restrictions of NASA projects affected the teams (and especially the practices they used). And Auke Jilderda talked about the “use-use-reuse” model for designing reusable code, and how it impacts teams. I have to be honest: before working on Beautiful Teams, I definitely didn’t make such a close connection between how great (or lousy) teamwork affects architecture.

You can read the entire interview — which, incidentally, is one of my favorites in the book! — on O’Reilly FYI.

Beautiful Teams is finally on its way to the printer!

For those of you who have been wondering why our blog posts slowed to a trickle over the last six months, now you know. Jenny and I have been working pretty steadily on Beautiful Teams, and we’re both really happy with how it came out.

Here’s a — well, it’s not really a sneak preview. It’s more like the promo copy we came up with for the back cover:

What’s it like to work on a great software development team facing an impossible problem? How do you build an effective team? Can a group of people who don’t get along still build good software? How does a team leader keep everyone on track when the stakes are high and the schedule is tight?

Beautiful Teams takes you behind the scenes with some of the most interesting teams in software engineering history. You’ll learn from veteran team leaders’ successes and failures, told through a series of engaging personal stories — and interviews — by leading programmers, architects, project managers, and thought leaders.

Looking back over the project, I’m pretty amazed at how much I learned about how teams work — from an incredible group of people, many of whom I’ve admired and looked up to for most of my career. Here are just a few:

• Scott Berkun wrote a great essay called “Why Ugly Teams Win” — and he did an incredibly insightful interview with Steve McConnell where they talked about the kinds of practices that make teams work
• Barry Boehm — and his longtime colleague, Maria Penedo — wrote a fascinating story about one of the first software process improvement projects ever
• Grady Booch talked to us about how he creates a better team culture
• Karl Wiegers, whose books gave me my first grounding in software requirements enginering, wrote a wonderful story about one of his early experiences with using use cases on a project
• Cory Doctorow — and, mind you, I think I’ve actually got a paper copy of Boing Boing lying around somewhere! — contributed a story about a team of IP activists
• Scott Ambler talked to us about the kinds of obstacles teams face, and how he works to get past them

And that’s just the beginning.We have over thirty contributions from people all around the software industry (and a few very insightful ones from people who aren’t in our industry at all!).

Now that I’ve got a little time to post again, I’m sure I’ll be telling you more about the lessons I learned, not just from actually writing and editing the book, but from the wealth of knowledge and experience all of our contributors shared with us. I’ve already started applying that newfound knowledge to my own teams and projects.

Oh, one more thing — my favorite part of the project! Not a single one of our contributors asked to be paid. Instead, they donated their time and considerable expertise to this project. Instead, we’re contributing royalties from the book to PlayPumps International, a truly wonderful charity that digs wells and installs pumps to deliver clean drinking water to rural schools and villages in sub-Saharan Africa.

Happy Kids on a PlayPump Roundabout

One reason I love PlayPumps is that it’s more than a charity — in a way, it’s a major civil engineering organization in its own right. And PlayPumps does what they do in a unique way: by driving the pumps with merry-go-rounds or roundabouts, which the children in the village play on. Not only does this give them clean water, it also frees up women, who in many villages have to literally spend
their entire day fetching water, often from polluted sources. We had the privilege of interviewing Trevor Field, the founder of PlayPumps, not just because he does great work, but because he does it through great innovation, engineering, and teamwork. That interview is one of my favorite chapters in the book.

Okay, so I hope I was able to write this post without turning it into too much of a marketing piece. Stay tuned, and with a little luck you’ll see much more frequent updates now that the book’s out the door.

We’ve gotten more than a few e-mails from readers wondering where we went. First of all, don’t worry – Jenny and I are still around! We’ve just been working overtime on our latest book, Beautiful Teams (here’s the Amazon page for it). It’s coming out well, and we’re really excited about it.

Beautiful Teams is a new kind of book for us, because it’s the first time we’ve done more editing than writing. We brought in a great team of guest writers and thinkers, people we really respect and whose work we’ve been big fans of over the years: Scott Berkun, Karl Wiegers, Karl Fogel, Johanna Rothman, Barry Boehm, Steve McConnell, Grady Booch, James Grenning, Cory Doctorow and a whole lot more. A good portion of the book will be stories from their careers, which was a big departure for us: it was as much about creative writing (helping our authors make the stories fun to read) as it was about software engineering. And in addition to the stories, Jenny and I have been doing interviews with some of these great thinkers, and I’m extremely happy about how they’re coming out. We’ve put a lot of effort into finding people who are thoughtful and knowledgeable, but also really good at talking about what they do and how they think. All in all, it should be a very unique and fun to read book.

Oh, there’s one more thing I want to tell you about the project – actually, my favorite part about it. We’re donating almost all of the royalties to PlayPumps International, a truly wonderful charity that digs wells to deliver clean drinking water to rural schools and villages in sub-Saharan Africa. If you haven’t heard of them, take five minutes and watch this piece that Frontline did on them.

I’m sure we’ll give you plenty more details about it as time goes on. In the meantime, hopefully we’ll be able to post a little more here for you!

Jenny and I are at the tail end of our fourth book, Beautiful Teams, and it’s really coming out well. We’ve put together a team of authors who’ve got some really fascinating stories about building software. Each of them has written a really compelling story from his or her past career. We’ve got people writing about all sorts of industries, and running into (and, in most cases, overcoming) a lot of different kinds of problems. All together, the collection is starting to paint a picture of what it’s like working in software.

One thing that I thought would be hard about this project was the coaching. These are software people, after all, not creative writing people. We have a few veteran authors on the team, but we also have a lot of people who hadn’t really done a lot of writing. And the authors themselves, in a lot of cases, were just as apprehensive as we were. It seemed like most of the people we worked with knew they had a good story to tell, but were worried about whether or not they could really tell it well enough.

It turned out that we didn’t have anything to worry about. I was very impressed with how well everyone “got it”. We put a lot of effort into selecting people who had a good story to tell, and it only took a small amount of guidance to help the authors tell them. Even people who hadn’t really done a lot of writing before really took the time to flesh out the characters, give us all the conflict, and really draw out the stories to make them fun to read.

Another thing that Jenny and I really wanted to do with Beautiful Teams was to put storytelling ahead of teaching. There are plenty of books that will teach you about building software. And we knew that there would be a lot of good lessons about software in the book. But our goal wasn’t a book that you could pick up and suddenly do your job better. The goal was to put you in the shoes of someone who’d been there before. Or, even better, we wanted to put you in the shoes of someone who was in a really interesting situation. Or a really bad, or even unimaginable, situation. We wanted to show you teams that were great to work on, and teams that, despite being awful, managed to muddle through. Or didn’t.

We’d never done anything like this project before, and we when we started it, we weren’t sure if we’d end up with engaging stories, or if we’d just get people writing about their boring projects from work. We were lucky. It turns out that on most memorable software projects, there’s some interesting drama: a bad boss, a deceitful or weird coworker, a serious and last-minute crisis that needs to be dealt with, a loud and unreasonable client. And it’s those very things which made the projects interesting that make the stories interesting to read.

At the beginning of the project, I was worried that people who wrote good software might not necessarily be good authors. But they really took to telling their stories. A lot of the authors told us that it was actually cathartic to get their stories on paper, and most of them really seemed to enjoy doing the project.

To me, the best part of the project is the fact we’re having royalties from the book donated to PlayPumps International. It’s a great charity that came up with a novel way to provide clean drinking water to rural villages and schools in South Africa. If you haven’t heard of them, I highly recommend watching this Frontline segment about them.

I’ll post again once the project is done with details about the stories. (We’re still getting the last ones in, so it’ll have to be a surprise for now!)

Remember back in January, when Tim O’Reilly blogged about great Bookscan numbers for Head First C#?

Well, Bookscan numbers don’t always match what you see on Amazon.com. Our intrepid little book has been clawing its way up the Amazon.com sales ranks. It was in the #2 position on the C# bestseller list for the last month. But when I checked a few minutes ago, it was at the top of the list!

This is a huge deal for us — it’s definitely a high-water mark for the book. And what’s really cool is that Head First C# is picking up steam. Its Amazon sales rank was under 500 all day yesterday, which means that it was one of the top 500 books sold by Amazon.com. (Not the top 500 tech books — the top 500 books.) Typically, books sell the most in the first few months, and Head First C# had a strong start out of the gate. But one of our friends at O’Reilly let us know a few days ago that we’re selling better than ever (when you discount the backorders that had to be filled, which always skew the first month’s results).

And Head First PMP is picking up steam, too! It’s been holding onto the #2 spot for PMP exam prep books, and it’s really been gaining over the last few months.

Now, Jenny and I aren’t all about sales. But we are all about helping people learn, and we see these numbers as a real win.

Check out this post on the Head First C# forum. One of our readers, Styrkar, wrote a really neat program that takes any text and turns it into a nifty little animation. He did it as a way to extend the Space Invaders Lab to make a cool animation for the “Game Over” text.

Okay, I just want to say how cool that is. When we wrote Head First C#, one of our goals was to give readers a starting point for their creativity. I figured we’d see a few little modifications to the programs in the book. But seeing stuff like this… well, it’s just really amazing to me. Not only is this a cool program, but the code is really good. It’s readable, efficient, and easy to follow. And it’s even well-encapsulated — it’s good object oriented design! I really hope Styrkar gets the rest of the lab finished — I can’t wait to see how it comes out.

Well, we didn’t see this coming. Check out what Tim O’Reilly says in his latest blog post:

I was probably most surprised when I saw Programming WCF Services on our list of top performing books for the year. If you’re steeped in open source, you might never have heard of Windows Communications Foundation, Microsoft’s approach to building SOA applications on Windows. And you might not care. But you’d be making a mistake. Don’t count Microsoft out of the Web services game yet! They still have a brilliant, passionate developer community, and as a company have tremendous resources, persistence, and talent. And now that they have real competition, I expect them to reinvent themselves. (For that matter, Head First C# was the top selling programming language title in Bookscan last week, except for “Javascript: The Definitive Guide”. And C# continues to gain significantly on Java in terms of book sales.)

Wait, what? Let me repeat that for you. Except for a book on Javascript, Head First C# was the top selling programming language title in Bookscan last week. That’s pretty amazing to me, because we only released it at the end of November, so word of mouth hasn’t even gotten a chance to spread yet.

We took a few risks with Head First C# — we took an approach that was somewhat different than any other programming book I’ve seen. I’ve learned at least a dozen and a half programming languages over the years, and I followed the same pattern every time: I thought of a project that I wanted to do, then I figured out how to do the project using the new language. (Like back in 1994 or so, when I wanted to learn Perl and also learn about web servers, so I built a web server in Perl.) But I’m definitely not unique in this approach: pretty much every good programmer I know takes the same approach to learning a new language or technology.

Which is why I thought it was so weird that I couldn’t even find a language learning book that asked you to solve programming problems. I’ve seen a lot of “hands-on” work, where you follow step-by-step instructions to type in code to get a certain result. And certainly, an enterprising person can definitely learn that way. (If they couldn’t, nobody would buy programming books!) And certainly, we have a lot of that in Head First C#. But I just don’t think that’s enough.

I guess I have a hidden agenda here. I’ve led a lot of programming teams over the years. In 2006 and 2007, I spent a lot of time working with a consulting company, and one thing you learn working with consulting teams is that you need to work with a lot of different people. Often, you’ll have at least one very junior member on a team. And what I’ve found is that a lot of really junior developers have the capacity to be good programmers, but don’t have any experience independently solving programming projects on our own. So I decided early on that one goal of Head First C# would be to give people that experience. I wanted to teach them how to solve programming problems, rather than just follow step-by-step instructions. In essence, I wanted to create programmers who I’d be happy to have on my team in the future. (Does that sound too self-serving? I hope not!)

So when Jenny and I started working on Head First C#, it took us a few chapters to figure out exactly how to do that. It was interesting going back to the beginning of the book after we finished, to do a second pass and incorporate comments from our (really great, and really patient) tech reviewers. It really did take us about five or six chapters to work out a good way of assigning problems. We ended up co-opting the “Exercise” element that you’ll find in the other Head First books. The Lose Weight Exercises in the other Head First books were generally pencil-and-paper oriented, although I think I remember a few step-by-step programming ones as well. That’s definitely the approach we took in Head First PMP, and it worked really well.

But with Head First C#, we took the “Exercise” element in a totally different direction. We basically used the Lose Weight Exercise to give a programming assignment, where we’d give a problem to solve. We’d include a screenshot, define some classes, maybe give a little of the code, and then leave it up to the reader to build working software. It was lucky that I spent so much of my career writing specifications, because I think we really had to push our writing skills to the limit. It’s far too easy to write an Lose Weight Exercise that’s ambiguous or hard to follow… and as we found out during the tech review, it’s really demoralizing to run across a poorly-written Lose Weight Exercise. And we had to be clear that there’s no single, “correct” solution to the exericse: if it works, then you got it right. I’d be surprised if a single reader comes up with exactly the same solution that we did on any of the projects in the last third of the book.

I hope that interactive approach is what’s paying off. Word of mouth is just starting to get out, and I’m really happy to say that it seems to be positive.

One of my favorite things about Head First C# is that Jenny and I ask our readers to do a whole lot of coding. When we started doing research for the book, one thing that really struck me about other books to help you learn C# was that I couldn’t find any book that actually asked its readers to write much code. There were one or two that we saw which had some written Lose Weight Exercises. And that’s great for a textbook, but I don’t know any programmer who learned to program with a pencil and paper. If you want to be a good programmer, you need to write a lot of code. Coding is a skill, and like any other skill it takes practice. And there are a lot of concepts that just don’t “click” until you write software that uses them.

I know that when I need to learn a new language, the first thing I do is come up with a project for myself. Like when I needed to learn Perl back in 1994 or so. I also wanted to learn about how web servers worked (they were newfangled and mysterious at the time), so I wrote a simple web server in Perl. (It turns out that it only takes about 50 lines of Perl to write a very simple HTTP/0.9 web server… probably a lot fewer, if you’re an insane Perl optimizng type.) So we decided from the beginning to make sure Head First C# has plenty of opportunities for our readers to write code. Which meant coming up with projects… a lot of projects.

Which turned out to be harder than it sounds. The instructions for the project needed to be completely self-explanatory. It’s not like an Agile project, where the programmer can talk to the customers and the software can go through several iterations. No, every project needed a complete specification, one that the reader could understand completely and build exactly the software we asked for.

And that’s where video games came in really handy.

When you ask someone to write, say, a business application, you need to explain all of the details of the business. And you need to explain why the program is needed, especially if the programmer doesn’t really have any background in that business. If a programmer doesn’t understand the reason or rationale for a particular feature, then it’s almost certain that he’ll build something other than what you’re asking for. (That’s why I always like including a rationale section when I write use cases. It prevents a lot of problems later in the project.)

Video games come “pre-loaded” with their own rationale. Nobody ever needs to ask why you’d write a video game — you do it because they’re fun. Everyone already knows why you’re writing it. It’s not hard to make a video game intuitive. One easy way to do it is to model it after a game that already exists. We have one Lose Weight Exercise where the reader builds a Go Fish! game, where the player plays against two computer opponents. One project is Hide and Seek — the player searches through a virtual house to find an opponent who hid in a random place. We’ve got a dungeon game, a Whack-a-Mole game, and my personal favorite (and the final project in the book), Space Invaders.

There are plenty of other sorts of projects, too. Our goal was to get the readers coding from the very beginning, and keep them writing code through the whole thing. We designed the projects to be satisfying and fun. And we’ve already gotten feedback from readers who definitely enjoyed them.

Head First C# Labs — The Contest

We’re running a little contest for our readers. We’ve included three labs in the book where the readers build larger projects. We give them a lot of design, but we don’t actually give them the code for the solutions (like we do for all of the smaller projects). Eventually, we want to post executables for the labs. But we don’t want to post our own — we want to post executables that our readers came up with! So we’re running a contest to see which readers can send in executables first. The first person to send us working code for the lab will have their executable posted on the website as the official solution, and we’ll send them some sweet O’Reilly swag, too.  Here’s the contest page — we’re looking forward to seeing what our readers come up with!

UPDATE: This contest is closed, but check out the Head First C# forum for a new challenge with prizes!