As some of you know, in the early years of the 21st century, I wrote a book on C#.
Since then, I've had a number of people who are interested in writing a book themselves ask me about my experience, so I thought I'd spend some time to write something down.
So, you want to write a computer book...
There are many reasons that you might want to write a computer book - or some other kind of book, for that matter. Unfortunately, some of those reasons may not pan out the way you expected.
Here's a quick lesson on the economics of book publishing, in the computer world. I believe that this also applies generally to the rest of the technical world. I know little about writing non-technical books - even less than I know about writing technical books - but I know enough to know that what I'm about to write doesn't apply there at all.
Book royalties are calculated as a percentage of the wholesale price of a book, which is generally 50% of the cover price. In my understanding, royalties generally range between 10% and 15%, with the higher ones going to more established authors.
Let's say that you write a $40 book with 10% royalties, and it sells 10,000 copies (a pretty decent sales figure, from what I'm told). That means that your royalties are:
$40 / 2 * 0.1 * 10000 = $20,000
That's pre-tax, of course - you'll need to pay income tax on your royalties, and you may also have to pay social security tax on it. I allocate about 40% to that, leaving you with $12000.
Is that a good deal? Well, it's nothing to sneeze at, but you need to figure how much time you spent on it. On the first verson of my book, I estimated that I spent at least 400 hours. If that figure is accurate (I have some reason to suspect I underestimated...), that means that I made about $30 per hour ($50 per hour pre tax). That may or may not be a good deal for you.
Books are a good example of non-linear return for the effort. If you sell only 3000 books, you get about $10/hour for the work. If you write a classic like Code Complete and sell a lot of copies, the return could be much better.
Even if you're a bestseller, writing a book is not easy, so you won't get easy money out of it.
If your book is successful, you may get some fame out of it (perhaps "notorioty" is a better term). While it's an interesting experience to be "famous" for your work, fame doesn't feed the iguana, with one specific exception (see respect).
"Chicks dig computer book authors..."
You may rest assured that your author status is likely to have no noticeable effect in this area.
If you write a good book that is well-received, you will get the thanks and respect of others in the industry. While you can't spend this directly, being a "noted author" can open up opportunities on the employment side of things. Some consultants write books primarily to drive name recognition and respect so they can be more successful consulting.
Today at lunch I had one of my friends ask whether I had fun writing my book. It's a hard question to answer.
I do derive considerable enjoyment from writing something that explains a particular topic well, and there were a fair number of those, but there is a considerable amount of hard work. To the extent that hard work is enjoyable (sometimes it is and sometimes it isn't), it was overall a pleasureable experience.
It is a reasonable expectation that you should be well-versed in your topic before you write a book, but no matter what your level, you will learn lots of new things. Not only are there 1001 details that you need to understand thoroughly before you write a book, there's nothing like having to commit your thoughts to paper to make you realize that you either don't know the details or are unsure of the details. I had to do a lot of research, and that meant I came out the other end with a lot more deep knowledge than I had before.
So, despite having read the earlier part of this article, you still think you want to write a book. The question now becomes "are you qualified". There are two aspects of this that I think are important.
Can you write?
Or, to put it more succinctly, can you write well in a reasonable amount of time without driving yourself and the people around you crazy.
Before you can get a signed contract, you need to be able to demonstrate this to your publisher (unless you're a big name draw, and the publisher is willing to pay for editing and/or a ghostwriter).
To find out whether this is feasible for you, you need to do some writing, and then you need to have an audience read the writing and give you constructive feedback. Writing is a skill, and over time you should be able to develop techniques that work will with your target audience.
Good ways to practice:
Strangely, the most important of these - the last one - has the least to do with formal writing. But it's the most important, because to write a good book you need to have a deep understanding around what is hard (ie what is hard to understand, what is poorly documented, what is confusing, etc.) *and* you need to be able to explain things in ways that people understand.
Both of those are cheap and easy to accomplish in a newsgroup. There's also an important side benefit to be had with community involvement, which I'll touch on later.
Are you uniquely qualified?
I know nothing about building and configuring Beowolf clusters. While with a huge amount of effort, I'm confident I could learn enough to write a book about them, getting to that point is far more effort than I want to, and I can't even know if there are good books already out there until I invest a fair amount of effort.
So, you need to be uniquely qualified. That means one or more of the following:
That last one is really important. When C# first was released, all the publishers wanted to have C# books, and there were a number of "me too" books that weren't distinctive and didn't sell very well. But in most cases, their authors worked just as hard as the authors of the more successful books. You don't want to find yourself in that situation.
I should note that if your in the first group, you can safely ignore the first-mover consideration. You likely have enough unique insight - and likely, name recognition - that your book will sell even if it isn't first.
Do you have the time and the desire?
And more importantly, can your family/social life survive your book-writing effort?
So, you've done all this, but perhaps you aren't really sure whether you want to do it or not. If you're in this situation, the best thing to do is to pick a chapter of the book, and just write it. That won't take a huge amount of time, and if it's a successful experience, you'll have something you can shop around to various publishers.
Finding a Publisher
Do some research of the various publishers. Who has a line where your book would fit well? Is there a book from another publisher that you could compete against? Are there authors you can talk to about their experiences?
Narrow your choices, go to the publisher websites, and find their materials for new authors. And then contact somebody, and try to spend some time (on the phone or in person, ideally) talking about your book idea. If you go to conferences, publishers are often available to talk to there, and they may even buy you lunch.
Helping Your Book Sell
You should expect your publisher to do a reasonable amount of marketing around your book, but you can have a large effect on sales yourself. First, if you were already involved in the appropriate community, you may be able to get others to help you do a technical review of the book. This is great both for techical quality and to have somebody else make recommendations for you.
If it doesn't seem like a conflict of interest, add a line that says "Author, "413 ways to write dangerous code" (Sams)" to the end of your signature. If people like your responses in the group, you're more likely to get a sale. Just make sure never to point people to your book instead of answering their question - that's a sure way not to get a sale.
If you're going to co-author a book, you need to find somebody with a compatible writing style, compatible writing habits, and a compatible personality. You also need to decide how you will divide the royalties - is it 50/50, or is it pro-rated based on the number of pages or chapters. I haven't done this myself, but I do know of cases where there were a lot of bad feelings at the end.
Oh, and #1, you must have a compatible vision and viewpoint on how books should be structured.
For me, I find it really hard to write with somebody.
I hope this was useful. If there are areas you don't like, are unclear, or you still have questions, please let me know.
There are three common choices for field name conventions in C# code:
I label the third MFC-style because that's where I first encountered it.
In the past, I haven't expressed a strong opinion for any of these, and I've written some C# code that used style #1 and some that used style #3. I recent experience, however, has pushed me in one direction.
On Monday, I did two separate code reviews. One was for a C++ class that one of my teammates has written (we do code reviews on all of our code), and the second was on a C# sample written by a C# PM.
When I was reading the C# code, it was hard to follow in places, and it took me a while to realize that what I was missing being able to know instantly whether an identifier was a field, or whether it was a parameter or local.
So put me firmly in the MFC-style camp for naming. #2 is also a reasonable choice, but I think it feels to much like a compiler-defined construct for my taste. Thankfully, I'll have refactoring when I need to revisit my old C# code...
A question related to performance came up today on a mailing list that I'm on, and I stated that the right way to do things was to do performance work based on measurements (ie don't engage in speculative optimization).
Another list member wrote back and said, "I understand what you're saying, but isn't that at odds with what many books say about designing for performance?"
I wrote an answer, and decided that it would be a good thing to share. This is what I think about writing performant code -what do you think?
Yes, those two perspectives (design up front vs measure and tune) are somewhat at odds with each.
To do good performance optimization requires that you understand the performance bottlenecks of the system. There are two ways to understand that: intuition, or measurement.
A considerable amount of performance work is done on intuition. The problem with intuition is that it turns out to be a poor predictor - the performance bottleneck in most systems ends up being somewhere different than where you expect it to be. There may be exceptions to this - consultants who repeatedly implement a similar design for different customers, perhaps - but for most software, you just don't have a very good idea where the bottleneck is going to be.
While performance work is often enjoyable, it tends to be fairly time consuming. If you optimize an area that didn't need to be optimized (ie your image shows up in 0.05 seconds instead of 0.07 seconds), you are spending time that you could be using to implement/polish other features, work on the performance of areas that do matter, or finish early. And you're generally creating code that is harder to read and maintain.
So, that leaves measurement. The important dictum here is "measure early, measure often". "Measure early" may even mean writing some prototype code to validate some overall assumptions about the system - is it possible to pull data from the database quickly enough over the existing network to support what you need to do? How fast can DirectX render a frame?
Many software projects have time devoted to "performance tuning". This is a "good thing" if you spend the time on an ongoing basis, measuring and improving as necessary. It's a "bad thing" if you finish your implementation and then start looking at performance, as the kinds of changes that improving performance requires are generally the kinds that you don't want to be making in the endgame. I've seen lots of examples where you get to a point where you a) understand the perf issue and b) understand how to fix it, but can't because of where you are in the development cycle.
Using agile methods can help. If you have good unit tests, performance refactorings are less risky, and if you run on a short cycle, it's harder to put things off. But you need to develop a "performance culture" in the team so that they care about performance all the time.
Hope that makes sense.
Rory wrote a post entitled "Whole Brain Coding" a couple of days ago, in which he asserts that coding requires both the left and right halves of the brain, the left brain working on the sequential and analytical parts of the task, and the right brain working on the intuitive and holistic parts (reverse these if you live in the southern hemisphere...)
When things are going well and you're in the "flow", my guess is that you're seeing involvement of both sides of the brain, but I'm not sure that that's all there is to it (I'm not asserting that Rory said that). I did a few searches to try to see what research had been done into the "flow", but didn't come up with much. There is:
In the Zone: A Bio-Behavioristic Analysis of Csikszentmihalyi's Flow Experience
but I have a hard time parsing sentences like:
Primarily, the decision making process behind such behaviors as disparate as creative thinking, problem solving, or walking to the store are all dependent upon and influenced by somatic or neural activation variables that are mediated by abstract environmental contingencies.
I think that's saying, "The way we make decisions is dependent on what's going on around us", which makes me happy that I'm not a psychologist who has to read and write papers like that.
Understanding the Psychology of Programming
which is a light intro to the topic.
On the whole math vs. coding thing, though I have a math minor and enjoyed my math classes up through linear algebra and multivariable classes, I ended up in software for two reasons:
Last spring I had the opportunity to take a class single-day class named "Take Back Your Life - Using Microsoft Outlook to Get Organized and Stay Organized", taught by Sally McGhee. The class is no longer taught, but the bulk of the advice is now available to all in the book of the same name. I found the class very useful, and was interested to see how well it translated to a book.
The book is all about learning, applying, and customizing a system to help you manage information. I initially was going to walk though the sections of the book, but I think it will be more useful (and easier for me) if I cover the concepts that I found most thought-provoking.
Clear Your Mind
One of the exercises in the book is titled "clear your mind". In it, you just start adding tasks (everything is done in Outlook) that you need to do, be they work-related or personal. What I found - and I suspect most people find - is that you are carrying a pretty immense "to-do" list in your head, rather in a more useful location. There are two huge advantages to doing this. The first is that you no longer have to try to remember everything you need to do, and the second is that if eveything is written down, it's much much easier to decide the relative importance of what you're doing, and whether you need to get some things off of your plate.
Strategic Next Actions
I have a stereo cabinet door that I need to build, and it need to be built out of alder to match some other furniture in the room. So, I could add a task "build stereo cabinet door". The problem is that that's not a task, that's really an objective. There are dependencies that I need to address before I can do any woodworking. I need to buy the alder, but I have to find out who carries it before I do that, and I need to do a design. So, what I really need to do is define a "strategic next action", which is the action that I can take that doesn't have dependencies. In this case, I need to post to the microsoft-internal woodworking group to ask where I can buy alder.
Using strategic next actions is very powerful, as it breaks down an objective into a series of steps that need to be done to accomplish it. If you're going to get things done, they have to be things that you can actually do.
Most people have their own scheme for dealing with email, but if you're like most people, you have a lot of messages in your inbox. When I took the class, I had about 1700 email messages, though one of the other people had 4100.
If you've ever looked at your email, read 4 messages, and then just left them in your inbox, then you probably have a bunch of email just sitting in your inbox, but even with search utilities, that's a pretty bad place to keep it.
The approach in the book advocates an empty inbox. That's right, zero messages. This is one of the most radical messages in the book, but if you are willing to stick with the approach enough to apply it, you'll find you spend much less time re-reading email, and you'll have a much easier time finding the information you do need. In the book's workflow, messages are only looked at once, and either deleted, delegated, moved into tasks, or stored for future reference.
Getting to zero can be a very powerful accomplishment.
Your own Personal Reference System
A personal reference system is organized around your objectives, and uses the same reference system in Outlook, in My Documents, and in web browser favorites. Having one shared taxonomy based on objectives is very powerful.
If you get any volume of email at all, this book will help you.
If you're a manager / program manager, this book may save you.
At $20, it's a steal. But...
You have to be willing to try something new, *and* you have to be able to invest sufficient time in setting up the system. One of the advantages of doing this as a class is that you have a day set aside to devote to learning and applying the system. If you want to be successful at this, you have to carve out the same amount of time.
Apress has decided to make some of their back catalog available as free downloadable e-books. This includes Troelson's "COM and .NET Interoperability", a book I used to have until it went walkabout.
Andrew obviously doesn't get any revenue from this, so if you like his work, you might consider buying C# and the .NET Platform.
In the spring before C# was first disclosed, I ended up, through a curious juxtaposition of events, writing a book on C# named "A Programmer's Introduction to C#"
This probably rates second on the list of "cool things I got to do while I was on the C# team" (being on the language design team probably rates #1. Talking to customers at PDC in Orlando that year is a probable #3...)
When it came out, it was certainly one of the top two C# books around, since there were only two books. As we changed things in the language and runtime and I expanded my understanding, I worked on the second edition, which came out around Beta 2, and had a cover that proudly claimed "Based on Beta 2" (which may be covered up with a sticker on your version).
Time passed, other good C# books were written, and with my move into the PM role, I found I didn't have much motivation towards doing an update of the book, so it became dated.
This troubled me. Though there are certainly problems with my book, it was still a pretty good resource, and my lack of motivation meant that it might fade away totally. Except for the effort of my extremely patient publisher, Gary Cornell of Apress.
Gary enlisted Nick Wienholt, MVP and author of Maximizing .Net Performance to modify the book to address the Whidbey enhancements to the language. I'm pretty excited about this - I get some say in what gets changed in the book without putting in a lot of effort (books are huge time sinks).
George is a PM (and friend) who used to be on the C# team (among others) - like me - but (unlike me) left the company to do something different, which in his case involves making Africa a better place.
I'm not entirely confident, however, that this link will make the world a better place...
A few weeks ago, I was reading the Seattle Times, and what should I find, but an article about the Japanese bank, Polysics. They were described as having a sound reminiscent of Devo. That piqued my interest, as I've always been a fan of Devo, though not as much as my friend Jon (WA license plate "Spudboy").
So, I went to Amazon, and listened to some Polysics samples. I wasn't really impressed, but I did come across a review that said Devo fans should listen to "The Network". So, I listened to a couple of tracks, headed on over to half.com, and ordered a copy of Money Money 2020. It showed up earlier this week.
It's always a challenge to describe a band's sound, but it would be reasonable to describe The Network as a mix of Green Day and Devo. Not in a sonic sense, but in a literal sense - in one of the poorest-kept secrets, three of the members of the Network are Green Day, and purportedly the two other members (there is also a mysterious 6th member not listed on the album, but listed elsewhere) are ex-Devo members.
There are Green Day touches all over the album. With the exception of a few overlaid synths, "Spike" is a fairly typical Green Day song. "Roshambo" is also a very typical Green Day arrangement, though the instruments are not. And songs like "Spastic Society" are much more in the Devo realm.
For those of us who grew up in the 80's, there are a few nice references (and you should definitely read the manifesto). There's a "hungry like a wolf" reference, a "Luftballons" reference, and a number of 80's riffs that are very familiar but I can't quite place (can somebody please tell me where the riff on Right Hand-a-rama comes from?)
Overall, I think this is a pretty good album, and after a reflection, it's not surprising that they got together. The messages in "American Idiot" and "Freedom of Choice" are really pretty close. The melding of 'punk guitars' with new wave songs and lyrics works pretty well. If you are a Devo and Green Day fan, you will definitely like this. If you're a Devo fan, you will probably like it.
If you're a straight-ahead Green Day fan, listen to a few tracks first.
I don't recall anybody every asking the question, "What if Green Day were a new wave group?", but I'm glad that they decided to answer the question anyway.
Trivia - "Reto", which is the title of the second track, means "Net or Network" in Esperato. Which got me thinking...
"Devo" means "a duty" in Esperanto...
From right to left, Ford, Marvin, Trillian, and Zaphod. If you don't know what this is a picture of, then you can safely stop reading now.
I came across this via a link from Scoble, who linked to a Greg Hughes Post. While it's pretty likely that I'm going to see this movie, having looked at this and watched the trailer, I'm worried that Touchstone is going to take a groundbreaking book and make a very average movie.
So, did you see it yet?
No, I'm not talking about Marvin, though I'm pretty sure that a) he has to have a cylindrical leg to be consistent with LTEAE, and b) he shouldn't be white, but I can allow a little liberty to be taken (though it does look like somebody misread "Brain the size of a planet" as "Brain the *shape* of a planet").
Nor is it that the fact that the trailer looks like a trailer from "Independence Day".
Count the heads.
In my book, if you don't have two heads, you're not Zaphod Beeblebrox.
With the current level of CGI sophistication, it's feasible to do a movie in which a character has two heads. Which means Touchstone *chose* not to do so. That makes me guess that the movie will roughly follow the story without having the right feel.
I'll be overjoyed if I turn out to be wrong, but if I'm not, I'll take some solace that Douglas is not around to see it.
I've gotten asked a bunch of times about writing a book, so I decided to write a short article about it.
So you want to write a computer book?
If you have comments, please let me know. Useful/Not useful? What else does it need to cover?
Once again, a nice resource post from Brad:
Profilers for the CLR
Cyrus takes on Hungarian Notation
I've written a fair bit of code that both uses Hungarian, and code that doesn't use Hungarian. I think Hungarian works okay for C code, but when you get into the object oriented world, you can't really come up with prefixes that are both meaningful and short, so I currently prefer the .NET style of naming.
Some of the people on the C# Language Forum suggested that I post a link, since it's been quite a while.
This is a forum for discussing the C# Language itself.
I was going to call this "Pimp Your Pin", but decided on a more descriptive title.
A week or so ago, I spent a few hours installing some mods to my Twilight Zone.
The first one was the backboard decal. Easy to install, though the decal needed to be trimmed a bit to fit. A nice improvement to the look of the machine.
The next one was the door flasher kit. This replaces a feature that was cut to reduce the cost of the machine. An easy enough install, but frankly, it really doesn't make much of a difference.
Next was the gumballs, a set of 60 small plastic gumballs that fill in the outer clear part of the gumball machine. You can either take the gumball machine apart (a lot of work), or you can do it more simply, and squeeze them in the space between the between the outer shell and the inner section. To do this, you have to press them in really hard (ie so hard your thumbs hurt), but it's worth the effort. This is definitely a nice upgrade.
I also added a Gumball flasher from PinGizmos. This adds few white LEDs to light up the gumball machine when the load light is flashing. The mod requires a small mod to the plastic divider, easily accomplished with a diamond wheel in the Dremel. This is a good mod, and really adds something to the machine.
The biggest upgrade was a set of new speakers. If you've ever pulled factory speakers out of a car, you've already seen the quality of the stock speakers in the pinball. Williams pins actually have 3-way speaker systems, with a separate woofer, midrange, and tweeter. This set has a bigger woofer and upgraded mid and tweeter, and the sound difference is pretty impressive. Much better on the music, and the deep bass sounds actually make the pin vibrate.
Anders talks with the .NET Developer's Journal.
I just got back from my last day of skiing this season - "last day" because of the lack of snow.
When my daughter first started skiing, we stood around and watched her at her lesson. We didn't want to do that the next year, so we signed up for lessons at the same time, so we could all be in lessons at the same time.
Since then, we've done lessons every year. On the way, my wife and I have gone from from strong intermediates to the whatever the next level is (I hesitate to use the word "expert", which has lots of connotations. We ski blacks and some double blacks). Each year, I think that I'll reach the level where further instruction isn't really worth it, but like all the past years, I got a lot out of this year. The instructor who runs Olympic's race program got me to open up my stance a bit (ie keep my skis wider apart), which got my skis working more independently and enabled me to get more ankle angulation than I've had in the past. It lets me get a better edge during my carving, and "flow" much better.
The interesting thing that I've noticed is that there is a real reluctance among adults to take lessons. There are tons of intermediate skiers out there who are working really hard and not having that much fun, skiing the same 5 runs over and over. Not everybody has the ability or the desire to be a great skier, but I know that everybody could have more fun.
I think a lot of this has to do with people not wanting to look bad, or wanting to try something new. I don't understand that attitude, however. Sure, it's not fun to look bad, and it's hard to work around habits, but who wants to do the same thing year after year.
This is dated news by now, but since I missed it, you might have as well. It was decided back in December that Generics would be CLS-compliant for Whidbey.
This is very good news. While I fully expected customers to use generics in Whidbey regardless of whether it was included in the CLS, not having it in the CLS would have required that library designers who wanted to follow the rules would either have had to avoid using generics or provide both generic and non-generic constructs. Neither of those approaches are very good.
After a few years of constant attendance at TechEd, this year I'm going to be working back in Redmond.
But there will be other people there, and who knows? You might have an interesting experience...
I've had an HD-ready TV for about 3 years now, but I have no HD sources.
Initially, it was because for DirecTV, you could either have an HD receiver or you could have a DirectTiVo, but not both, and TiVo was far more important to me...
Then, when the HD DirecTiVo came out, I thought about buying it, but it's pretty pricey (~~ $1000), and it was unclear what attitude DirecTV had towards HD, so I decided to wait it out a bit. After about 6 months, I was going to buy...
Then Comcast started adding HD local channels, and they started testing a HD DVR in my area (though not TiVo based), about the same time the DirecTV said that they were planning on doing their own HD DVR (due sometime this summer). This made things fairly equivalent in my book.
Then I read this today, which opens the possibility that I could get a Comcast TiVo (though the non-TiVo HD PVR box that they're testing around here has gotten decent reviews). That would give me the opportunity to consolidate off of satellite, assuming the SD quality on Comcast is acceptable (last time I looked at their digital cable, it was pretty bad. Worse than what DirecTV gives you on the less-popular channels, and that isn't great either).
So, once again, I'm in stasis, but with any luck, it may resolve by this summer (that's probably too soon to get a Comcast TiVo HD PVR, though it depends upon what mods are required to the DirecTV version - they do use two different formats for their data).
Who makes sure that all the cows' wishes come true?
The Dairy Godmother
One of the cool things about the internet has always been the ability of people who are really into something to share their passion with others.
Today, I came across a link to Waterfalls of the Pacific Northwest.
What a cool site...
Back in 1984, I was in an algorithms class, using Sedgewick's excellent text entitled simply, "Algorithms" (which later spawned variants in other languages). I learned a lot from that class, but there were a few questions now answered in the text, and when I asked my prof, he said, "go read Knuth", and that led me to what many consider the best work on algorithms, and exposed me to all sorts of interesting ideas.
Donald Knuth recently gave an interview to NPR.