Tag Archives: Tips

Tips for Writing a Programming Book

In this article, I want to go through the process of writing a book, to give others who are thinking of writing a general idea of what kinds of things you will need to do. This is the article I wish I had read before starting out. Some of this will be applicable to fiction writing, but there are better resources if that’s what you’re interested in. I can only share what I personally know.

Before-You-Start Checklist

Here’s a short list-based summary of many of the things I’ll discuss in this article. These are all things to think about before you start writing and throughout the process:

  1. Do you have enough material for a book? Write out an outline to make sure. Iterate over it until it’s quite detailed.
  2. Quash self-doubt! If no one else has written this book, then it’s up to you!
  3. Do you want or need to go with self-publishing?
  4. Who will be your editor? (You do need one.)
  5. Should you do a print edition? What’s the market for that?
  6. When are you going to make the time to write?
  7. Do you have a place you can write uninterrupted?
  8. Will your family support the time commitment?
  9. Does your day job have a moonlighting policy? Follow it!
  10. Don’t use DRM!
  11. Familiarize yourself with the various publishers’ processes. Do some dry runs. Figure out what’s going to work and what’s not.
  12. How are you going to market your book? Get started on laying the groundwork for that early. Start tweeting and blogging in anticipation.
  13. When marketing your book, remember to Always Be Providing Value.
  14. Price sanely and fairly. Chances are that in unless you’re fulfilling a unique, high-in-demand niche, you’re not going to make a lot of money, certainly not enough to quit your day job. Optimize for the number of sales, and be competitive with others in your genre. The satisfaction of producing something meaningful and sharing your knowledge with others is worth the effort you are putting in.

Writing a book is not easy. Just because you know stuff does not mean you can write a book about it. But it is a prerequisite. I’m the author of two non-fiction computer programming books. The first, C# 4 How-To was published in March 2010 by Sams. My most recent book is Writing High-Performance .NET Code. This was self-published, for reasons I’ll get to later.

After the experience of writing my first book, I promised myself and whoever would listen that I would never write another book. The process was too grueling for the payoff. The money just isn’t there. Sure, you do get some, but if you have a well-paying full-time job, it’s a drop in the bucket. You should not write books for riches–chances are you won’t get them.

The rest of this article is part advice, part journal. Get out of this what you will.

Inspiration

At my day job in Bing, I’ve spent the last few years becoming something of an expert in the area of .NET performance. I wrote a very significant part of the Bing query-processing stack in .NET and performance is obviously a vital consideration in everything it does. I had the benefit of an amazing mentor (see my book’s acknowledgements [PDF]) for a number of years, and the experience we gained as a team was considerable. Many of the bits of knowledge we had to apply were things that were not available via Internet search, or if they were, lacked so much context that it was worse than useless.

One day, at a dinner with my brother-in-law, we got to talking tech and our work projects in generalities, and he casually mentioned that I should write a book about these performance lessons. This wasn’t the first time the thought had come to me, but this time I actually thought it through for a while. I mulled on it for a few weeks before writing out a simple outline, at which point I knew that I had enough material for a book.

I wasn’t sure how long it would take, or what my coworkers would think, so I kept it to myself and close family.

Doubts

Everyone has self-doubt. I certainly did. Through much of the writing process, I constantly wondered to myself whether I should be the person writing this book. I am not on the CLR team; I work on a specialized project; I’m fairly young compared to the experts I look up to: who am *I* to be writing a book on .NET Performance? Et cetera.

There is a fairly common psychological condition called Imposter Syndrome, which explains these doubts. Basically, most people at one point or another feel like a fraud in their success.

The fact is, I realized, that someone ought to have written a book like I was, and that someone might as well be me. As long as I got good editing, feedback, and technical help, there was no reason I could not produce a very high-quality textbook on .NET performance, despite my worries.

So I pressed ahead.

Another doubt was the scope of the book. My knowledge is heavily weighted towards vanilla servers, pure-.NET. No WCF, ASP.Net, WPF, etc. I am familiar with those, but they’re not my bread-and-butter, so to speak. Would people read a performance book that didn’t cover the trendy buzzwords?

I decided that they would. There was no book that covered the fundamentals of .NET performance engineering in the way I was going to. This was an important niche, and it was actually an advantage to not cover the higher-layer technologies. It gave the book laser-like focus, and allowed it to explain the fundamental techniques in a way that a widely scoped manual would lose. There was no book that explained the fundamental costs and benefits of using .NET from a performance point of view, regardless of code library.

It was like a really good cook book that would teach you fundamental cooking techniques, but the book would not have thousands of recipes. Once you had the techniques, you could apply them on any recipe from other books.

Why Self-Publishing

I probably could have gotten a publisher if I had asked. I had already published a book via Sams, and while it wasn’t a best-seller, I did earn back my advance and a little more. However, royalty rates truly are abysmal. 10% of the wholesale price is fairly typical. Wholesale is usually 50% of the cover price. So for a $40 book, you can expect to earn about $2 per copy, less on an eBook. The advantage of having a publisher is that they will get you into physical stores, which is where I saw most of my sales for my first book. However, that was 5 years ago. The market has changed dramatically in that time. Amazon is the king of book selling, by a LONG shot.

So I went with self-publishing for a number of reasons:

  • I could earn much higher royalties, even if I priced the book much lower.
  • I knew someone who could be technical editor.
  • I have a couple of editors in the family who could help with grammar and style.
  • I had experience and so knew basically what kinds of formatting I would need, what parts of the book I would need–all the technical details.
  • I was willing to do all of the pre-publication grunt work myself.
  • I have an artist in the family who could do a cover for me. Heck, even if I didn’t, I know Photoshop. I could probably whip up something better than most of the bland covers that seem de riguer for programming books these days. Admittedly, my sister did a much better job on the cover than I could have.

Self-publishing has definitely paid off for me. Benefits I’ve noticed:

  • A bigger sense of accomplishment. I didn’t just write the book. I managed it from beginning to end. I made it a business.
  • I feel much more in control of my own product. I can update it at will. I have more direct contact with many readers on Twitter and other places.
  • I’m not going to quit my day job anytime soon, but in the first three months of my book being out, I made more money than in all 4 years my previous book was on the market.

Writing

The hardest part of any large project is just getting started. The first thing I did was flesh out my draft outline to list all of the chapters I thought I would have, then within those chapters, individual topics.

Then I just started writing. I don’t remember if I started with the Introduction or Chapter 1, but I did start more-or-less at the beginning. At the start, I did not concern myself with grammatical correctness, precise descriptions, or even necessarily getting all the details I wanted. I just tried to get all of the ideas onto the page. As I thought of related ideas, I would write them into my outline, or later in the document itself with a TODO prefix and an explanation of what I was thinking.

I pretty much wrote the whole book linearly like this. Not perfectly, of course. I jumped around a bit as necessary. Sometimes, sections belonged in a different order, or in a different chapter entirely. When I got to a part where I knew I needed a code sample, sometimes I just wouldn’t be in the mood to work on code or the debugger, so I would put a TODO in the chapter with an explanation of what the code needed to do. Then I moved onto writing something else.

One of the things I had to decide fairly early on was my writing style. Was it going to be “folksy” or “clinical”? How much like a textbook did I want it to read? My natural style is fairly informal. I started writing the book just like I write a blog entry, but I realized, especially later during editing, that while this is mostly ok, you do need to tighten up the writing a little bit. Some things just require more clarity or a precise explanation.

Another important decision I made early on was to take a stand, be opinionated in what I recommend. So much programming documentation is clinical and does not take a firm stand on what you should do in a given situation. I wanted to make sure my own personal voice rang through the text.

This isn’t just about the language and grammar being used–it applies especially to the content. In a blog entry, if you don’t want to explain a piece of prerequisite knowledge, you can just link to an existing source somewhere on the Internet. Book readers do not want that. If there’s something they need to know, you need to provide it to them (within reason of course–it’s fair to state knowledge assumptions up front).

The increased need for formality also forces you to really get your facts right. There is nothing like teaching others to really get you to learn the material well. This is true for EVERYTHING, but especially if you’re writing a book. There is a huge difference between knowing in your head how something works, and being able to write it down in a coherent way. Of all the chapters in my book that I knew I had to get right, Chapter 2 – Garbage Collection is the one that needed to be the most perfected. I knew garbage collection details pretty well. I have nearly weekly interaction with the people responsible for maintaining and developing it, but it was still surprising how many nit-picky details I needed to tweak after going through the content with the owner of the GC.

I did not have daily or weekly writing goals at first, but as I got towards the end, I did start challenging myself to writing a thousand words per writing session. This can actually be pretty tough when you realize you need to do more research, or write a code sample. Those take time. My only goal was the rough timeline. I knew I wanted to publish in the summer of 2014, so I planned out what had to be done by when, and gave myself about two months for editing and finalization.

Resist the urge to pad your text. This is really easy to do in a programming text. Just throw some more code on the page, add some extra topics, and you can create pages out of thin air! Don’t do this! Yes, find good, relevant content that should be in your book, but only add it with the right motivation. It’s unlikely your outline will contain everything that needs to be in the book—you will certainly forget something. Do research, brainstorming, take a step away from the project, ask your technical editor what’s missing, etc. Add content for good reasons that fit the scope of your book and leave it at that.

Tools

I used Word 2013 for the entire process. This has its pros and cons.

Pros:

  • Advanced formatting abilities. (It’s not perfect for advanced layout requirements, but for a book like mine, it was sufficient.)
  • Great for producing a print-ready PDF.
  • Great collaboration abilities, especially via OneDrive and Office Online.
  • Ability to edit anywhere I was, on any computer.

Cons:

  • eBooks support very limited formatting. In particular, the Amazon Kindle conversion was a nightmare. I had to remove a LOT of formatting. (Tables and multiple fonts per paragraph are the two big ones that come to mind.)
  • When it came time for the EPUB conversion, which is used for every online retailer except Amazon, it required an entire day to clean up the HTML from the conversion process. I had to fix a lot of styles and makes tons of tweaks. To the point where it is now easier to make corrections in multiple documents rather than make them in the master document and then redo the conversions.

I stored the book on OneDrive while I was actively working on it, which allowed me to edit anywhere I was. When it came time to collaborate with editors, this made it very easy to share with others who could add comments directly in the document. I made weekly, sometimes daily, backups to another drive at home, which was further backed up by Carbonite.

For screenshots, I used the built-in Windows utility Snipping Tool. This mostly worked, but you have to keep in mind that print is 300 DPI, while most screens are 96 DPI, which means the images are smaller than you think. In some cases, I used Photoshop Elements to increase the size of and resample small images to make them suitable for printing.

For code samples, I used Visual Studio 2012 Ultimate. I used Subversion on my local Synology NAS to store my code samples. Once the book was done, I also added all graphics, manuscripts, and all other book artifacts as well. The Synology has a publicly accessible DNS that I could use from my laptop away from home.

For eBook editing, I used Calibre, which has both library management and eBook editing tools.

When it came time to upload to online retailers, I first ran EPUBCHECK on the final EPUB files to ensure they passed with 0 errors.

Time Scheduling

Given that I have a full-time job and a family with a small daughter, as well as other commitments (including a musical, where I was playing in the orchestra), finding time to work on the book was a problem. My wife and I instituted a “night off” every week to work on personal projects—after dinner, we have no more responsibilities for the rest of the night. We don’t have to help with dishes, bath time, reading stories, or interacting at all. I utilized my night for working on the book. I say goodnight, kiss and hug my daughter, and then I can isolate myself in the house or go somewhere else. The time was 100% my own. Typically this amounted to about 4 hours. For the rest of the week, I would be lucky to get an hour or two a night. But the 4 hour block really helped–it was enough time that I could focus on big issues.

Towards the end, perhaps the last month and a half, one night a week wasn’t sufficient either. There was so much to do that I had to start taking most of all my Saturdays to work on the book or I would never get done.

In the end, the book took about 10 months, start to end, and that was mostly working nights and weekends. And the book isn’t even that long! Don’t underestimate how much work it is.

Setting

For writing, by far the best place for me to work was somewhere outside the home that had some kind of ambient noise. I worked at the local library, Starbucks, and even McDonald’s a couple of times (they were open later than the others). There is something about the noise level that can help you concentrate more than being at home. If you have to work at home, you can try any number of ambient noise tracks on YouTube.

The times where I did work at home, I usually put in headphones and listened to classical music.

For code and debugging samples, it was much easier to just do that at home where I have two large screens.

Editing

I am lucky. I knew someone who would be a great technical editor. He was on the CLR team before joining my team and he became a great mentor. I asked if he would be my technical editor, and he readily agreed. This meant that my technical content was in good hands. He wouldn’t let anything egregious slip by.

Since I also had a relationship with people on the CLR team, I asked some of them to proofread smaller portions of the book, in particular Chapter 2, which I consider the most important part.

Once I was done with the first draft, I gave the whole thing to my TE. After he had it for a few weeks, we got together in person and walked through a major portion of the manuscript. I came away with about three pages of notes. Everything from minor technical errors, need for a source, a better wording, to a better way of summarizing content in the chapters and at the end of the book. Not all of them were big changes, but some were. A couple involved major restructuring. This was about a month worth of work.

For grammar, style, and formatting, I asked my wife and father to review. My wife is an amazing editor. She has worked at a couple of jobs that required very precise abilities in analyzing documents, so she was the perfect person for this job. I also asked my dad to take a look as well, and between them I got a lot of good feedback.

To allow them to edit, I shared the document with them via OneDrive and asked them to only leave comments—not change the body text. Once I resolved their comment, I deleted it.

One other thing I did was a bit a crazy. I turned on ALL of Word’s grammar suggestions and analyzed the final manuscript. Don’t do this unless you like pain. If you do like pain, then go to Options | Proofing | When correcting spelling and grammar in Word | Settings…, which brings up this window:

image

Turn on the settings you want and prepare to be nitpicked to death. I turned it off after a while, but it was helpful, and helped forestall some comments from my wife.

One of the most common things that was corrected by my editors was the use of contractions. If you look in the final book text, you will find very, very few contractions. Contractions are a very informal way of writing. Fine for a blog entry, but in a book, they do stand out a bit. I only left them in when they sounded better.

There are dozens of nitpicky details you have to take care of. It’s hard to think of them all right now, but I strongly suggest you look at another book in the same genre you’re thinking of writing and analyze all aspects of it, especially the parts that aren’t just paragraphs of text. Things like:

  • Heading Capitalization.
  • Number of heading levels.
  • Structure of lists. Sentences or not? Periods at the end or not? My rule was that each list had to be internally consistent, but not necessarily consistent with other lists. Catching all of these can be hard.
  • Sentences that are too long, too short, oddly phrased, confusing, etc.
  • Colloquialisms.

A lot of this stuff you will be absolutely blind to. You MUST have another person help you find a lot of it. It’s also helpful if that person is familiar with the genre or is at least well-read and understands the language very well. Don’t ask your buddy who reads < 1 book a year to proofread.

Formatting

If you’re writing a book that is guaranteed to never be printed, then your primary concern with formatting should be how little of it you can get away with. Use one or two fonts. Use as few header styles as possible. There are plenty of formatting guides out there. One that I read and was very helpful was Mark Coker’s Smashwords Style Guide.

Right up until the first week of publication, I was planning on keeping this eBook-only. As soon as I told people it was available, though, some people asked about a print edition, and I realized I would need to do that.

Formatting for print is significantly more work. I wanted a number of things:

  • Bold, obvious styles for chapter titles, section headers, and more. Some of this includes underlining.
  • Graphics with captions throughout the book.
  • Different font and background shading for code samples.
  • Different font for code elements cited in paragraphs.
  • Appropriate white space after tables, code samples, section titles.
  • Appropriate white space before section titles.
  • Special callouts and borders for anecdotes and tips.
  • Page numbers, with alternating sides for even/odd.
  • Page headers consisting of the chapter number and title.
  • Chapters always start on the right side (I had originally planned on some graphics that bled to the edge, but this would require a more expensive printing option, so I abandoned it)

Word was great for all of this. If you’re not familiar with these features, it can take a bit to make it work, and it probably doesn’t have the power of a true desktop publishing application, but it worked great for me.

There are a lot more things I could have done. Take a look at another programming book and check out the advanced formatting and features they include. Most of it is unnecessary, but it can add a certain flair.

Cover Design

I knew almost from the beginning that I wanted the cover to have gears on it (see the introduction to the book for an explanation why), and have a very distinctive look. Most programming books are very bland. I wanted mine to stand out and still be professional-looking.

I am fortunate to have an artist sister, Claire Watson, who was willing to do some Photoshop work for me. She has a great eye for design, and after I told her my general ideas, gave her some sample stock photos, she produced no less than 30 variations of multiple cover designs. The one I ultimately chose was a variation of her very first design, and I love it.

You can find artwork and jewelry by my sister Claire at http://www.bluekittycreations.co.uk/.

Code Samples

I used Visual Studio 2012 Ultimate for the code samples. I could have used the 2013 version, but decided 2012 was a safer bet for minimum hassle for the majority of readers.

There were a few challenges with code samples:

  • Keeping them extremely short while still demonstrating the point I’m trying to convey.
  • Line length, especially on an eBook is an issue. Small screens and limited resolution play havoc with code formatting. If you’re on a really small or old device like an iPhone or original Kindle, then sorry, I did not bother trying to format for your device—it doesn’t even make sense at that point. I optimized for devices like the Kindle Fire and better.

Moonlighting Policy

Before I completed the book, I checked and double-checked the current moonlighting policy of Microsoft, which does allow me to write and publish books without prior approval. The only thing that can get me in trouble is revealing proprietary information, and I was very careful about this, especially when talking about .NET and GC internals (I had the GC owner review the whole chapter, and she did ask me to remove some small details that are prone to change in the future). So no worries here about publishing.

Prepping for Publish

If you thought you were done when the manuscript was complete, edited, and finalized, then you are in for a surprise. Depending on how complicated your manuscript is, you still have days worth of work ahead of you, so plan accordingly.

At some point I set a hard deadline for myself: July 12. That was the day it was going to go live on at least Amazon.com. The weeks before that, I basically worked every night and all weekend to complete as much of the final edits that I could and get final feedback from my editors, both technical and grammar. Then I took off work on Thursday and Friday to work on the eBook conversion. I knew this was going to be a chore, but I had no idea how grueling it would be. I understand now the value that professional publishers, editors, typesetters, etc. have. I decided to do the Amazon Kindle conversion first. For this, I just needed to upload the Word document to Amazon and their system would check it and provide a list of errors to me. I could also proofread it on various Kindle simulators, which would attempt to show me what it would look like. This was very helpful.

The single biggest problem from this process was that paragraphs with different fonts in them did not render properly. I used different font styles for code keywords within body text and this was throwing off the whole system. So I had to go fix a bunch of styles in a copy of my manuscript. I didn’t want to modify the original document because I knew that I would want those different styles for EPUB and print.

I also quickly realized that tables, despite being supported in all eBook formats will not work except for the most trivial of tables. It just doesn’t look good. This was too bad, because I had spent quite a while converting some bullets to tables. I spent a few hours converting back.

It was invaluable going through the book on the various Kindle simulators. I got to see a lot of things that just didn’t work on a small screen. It’s always a challenge putting a well-formatted book into an eBook, especially one with tons of code samples. Some Kindles displayed the shaded backgrounds, others didn’t. None will use different fonts, so you don’t get the benefits of uniform spacing for code samples. All of this I just let slide–I figure if you’re reading a coding book on a Kindle, you kind of know what you’re getting. I didn’t even bother proofreading (beyond curiosity) on the older Kindles or iPhone Kindle App. You deserve what you get if you try it. Sorry.

By Friday night, I hit the Publish button on Amazon KDP. A few hours later, it was up for sale.

On Saturday, I went through the EPUB conversion process. This went a bit faster than the Kindle process, but was still a little bit labor intensive. I used Calibre to convert the Word document to EPUB format, which is really just a ZIP file containing HTML, styles, and images. Then I used in the Calibre eBook editor to modify the HTML as necessary to fix up styles and formatting inconsistencies. This took a few hours and required a bit of hand-editing of styles and individual locations throughout each chapter.

Once all of that was done, the EPUB could be uploaded to all of the retailers besides Amazon.

By the end of Saturday, I was published on all major eBook platforms.

On Monday when I announced it to my work colleagues, a bunch of people said they wanted a print edition, which up until this point, I was not sure I was going to do. But given that response, I instantly realized that a dead tree version of a programming book is still in-demand. It’s the code samples—some people just prefer a physical book for code.

So I spent the next week getting it ready for publication via CreateSpace. Basically, this was just ensuring that all of the formatting I wanted (see above) was present and correct. My first proof copy actually had some bad fonts for most of the code samples–I had selected Courier New, and it just didn’t look as good as Consolas, so that was the major fix before publication.

I ordered a single proof copy, made the font change (and a few other minor fixes as well), and then hit the publish button. Within a day or so it was on Amazon for sale. A couple of days after that, it was matched up with the existing Kindle book so people could easily see both editions. (The matching process is normally automatic, but if it doesn’t happen for you, you can contact KDP support and let them know the ISBN/ASIN numbers and they can match them up for you.)

A note on DRM (Digital Rights Management): Avoid it. Unfortunately, your book is going to be hacked, stolen, put on Pirate Bay, whatever, anyway. DRM only punishes the law-abiding consumer. Just don’t, and make peace with the fact that people will steal things. If you sell to organizations, then it is fair to ask them to pay for multiple copies for multiple people, but don’t try to enforce this. It’s a losing battle and isn’t going to help your bottom line much anyway.

Pricing

By the end of Friday, I had the Kindle ready to go. I just had to decide on markets and pricing. I went with $9.99 because that’s the maximum price you’re allowed to do on KDP and still get a 70% royalty rate. This was actually disappointing to me. For me, the sweet spot in pricing would have been around $15. This is competitive with existing programming eBooks while being slightly cheaper. I had a fear that if I priced it too low, I wouldn’t have credibility compared to more expensive offerings. I don’t worry about this now. The book has taken off and gotten enough reviews that it can stand on its own, and the price now only helps.

For the print edition, I set the price much more in line with current offerings (slightly cheaper, of course). I also made EU prices similar to other books in those markets, but I have since changed them to be tied to US price and the exchange rate. This makes my book VERY competitive in those markets, and it has definitely netted me more sales.

Marketing

I tried to have a comprehensive marketing plan, but I don’t know how well I followed it. There were so many things to do that a lot of things just fell through the cracks for weeks. However, when you self-publish, time doesn’t really matter. Yes, more sales in a short period of time can lead to follow-on sales as the book will get featured in some places, especially on Amazon, but in the long run, you can try lots of things and let your book’s demand naturally grow.

Here is a short summary of what I did:

  • Reddit – I had no idea how much good this would do for me, but it really did. I didn’t just post a link to my book and beg people to buy it—that’s guaranteed to fail on any social media site, but especially on Reddit. Instead, I discussed my own background and motivation for the book. Just those facts contained enough interesting tidbits that people wanted to know more. My biggest single-day spike in sales came from that thread. Plus it led to a lot of interesting discussion. The point here is that I tried to provide value external to my book.
  • Twitter – I was never a big Twitter user, and I’m still not, but I decided to make some efforts and reach out to people, participate in discussions, comment on tech news, share personal tidbits, and more. Yes, I plug my book, especially retweeting other people’s comments, but I don’t make my Twitter feed exclusively book plugs—that’s annoying. Remember, try to provide value.
  • Free Samples – The book’s site contains a PDF of the book up through Chapter 1. People can see the full Table of Contents and get a feel for what’s in the book, without me giving it all away. I believe a free sample is critical. I even went further, releasing the entirety of Chapter 5 (Class Design and General Coding) as an article on CodeProject. It won Best C# Article for August and is ranked as one of the Top 5 articles posted on the site.
  • More articles on CodeProject, such as this one about object allocation. That article starts with something that’s in the book, but I provide a lot more information and examples that are not in the book. This article won Best C# Article of September. (Sadly, I didn’t have an article for October, but I’ll work on another one soon.)
  • Letters to influential bloggers and podcasters. I knew this was a long shot. They probably get product and media pitches all the time, right? But a few did respond. Some written reviews will hopefully show up on some influential blogs. I was a guest on the fabulous .NET podcast, .NET Rocks in episode 1041. My book was also mentioned in This Week on Channel 9.
  • Facebook Page – an easy way for people to follow updates on the book, reviews, articles, blog entries. It’s not a super busy page, but it’s a useful central place for making announcements.
  • Ads – I tried advertisements on Google, Bing, Facebook, and Twitter, with very limited effect. I mostly tried out of curiosity, and shut down these experiments fairly quickly after it was clear they weren’t doing much.
  • Letters to family and friends – I sent an email about my book to literally everyone in my address book, not asking them to buy it, but to forward to programmer friends or colleagues of theirs.
  • Ask for reviews – I’m not shy about it. Anybody who I know read it and loved it, I will ask them to leave a review on Amazon. These make a difference. I hear from a lot of people on Twitter, and I’ll give them a few weeks or so, and then ask them to write a review. I never tell people to leave a five star review or give any other guidance. More reviews the better.
  • Book’s website – Where to get all information about the book, a complete retail location listing, a place to buy the PDF or EPUB directly from me, errata page, download the book’s source code samples, and more. This site is important.
  • Posters – I printed 50 copies of a small poster of my book and put it up on every floor of my building and two others near me. I’m not sure what effect this had. Probably not worth it.
  • GoodReads – I made sure my book was in GoodReads, with the right cover, editions, descriptions, etc. You can add all of this yourself.
  • Blogging – I started blogging again, before the book came out. This provides another outlet for providing extra value as well as places to mention the book.

Remember to go beyond just “Please buy my book” – Always Be Providing Value.

In the end, the buzz from the podcasts, and other online reviews that have popped up have definitely helped, but most people are finding this book just through searching Amazon. My book comes up when you search for “.NET Performance” and that’s probably the most effective thing for lasting sales performance.

Sales Results

I put my book up for sale literally everywhere I could: Kindle, CreateSpace (for print), Kobo, Nook, Smashwords, Google Play, Apple iBooks, and my own site in EPUB and PDF. Smashwords, in turn, distributes to other retailers. I wanted it available everywhere, and it mostly is. Through CreateSpace’s extended distribution network, it even goes to some physical stores I believe–I know I’ve seen some fairly decent-sized orders for that network.

But looking at the numbers, it’s interesting just how much Amazon dominates the field here. Here are the percentages:

image

If you add Kindle and Print (both primarily on Amazon), that’s nearly 90% of all my sales coming from Amazon. The next-best thing is the PDF from the book’s site. You might be tempted then to only publish on Amazon, but I think this is a mistake in the long run. Even though the percentages are small, I do get sales from the other channels. There is a psychological benefit as well—many people are happy just to see that it’s available everywhere, even if they buy from one of the usual places.

Also, don’t forget the international market. Nearly all of my sales via my own website are from overseas customers who can’t easily use one of the big eBook retailers. By providing an EPUB and PDF to them, they can use the document however they need.

Contact

If you have any questions about this whole process, please just let me know either in the comments or on Twitter.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

An easy stack layout panel for WinForms

This is a simple, but useful tip. Users of WPF are spoiled. They have all sorts of layout options. Those of us still working in WinForms have FlowLayoutPanel and TableLayoutPanel. That’s it. WPF has those and more.

For my current project, I needed a panel to layout controls vertically. The TableLayoutPanel can be awkward to work with, at least for what I need it to. At first glance, the FlowLayoutPanel looks it won’t work, since it produces something like this:

FlowLayoutTable_1

That’s with changing the FlowDirection to TopDown and putting AutoScroll to true.

But what I want is this:

image

To achieve this layout, merely set all the following properties on a FlowLayoutPanel:

  • AutoScroll = True
  • FlowDirection = TopDown
  • WrapContents = False

et voilà, Instant stack panel.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

On the importance of ignoring your problems

I’ve been having a great time at Microsoft over the last couple of months, but the ramp to full productivity is very steep. Recently, I’ve been working on an important improvement to some monitoring software, which requires a fairly good understanding of part of the system. It can be a little overwhelming trying to design something to handle all the nuances involved. Add to that the time crunch, and things get a little interesting. Last night, I ran into a little wall where I was uncertain about how to proceed. This kind of situation is always a little precarious. I was worried because today and tomorrow I have full-day training and won’t be able to dedicate a lot of time to solving this problem.

Half way through the training, while discussing something tangentially related to my problems, I realized the technical solution to the specific issue I was facing.

Sometimes you just need to ignore the problem for a while, and come back to it from a different angle.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

Converting OLE_COLOR to System.Drawing.Color

I’ve been working on a project using Visual Studio Tools for Office 2008 (VSTO) and at one point I needed to get the colors for categories in Outlook 2007. There are actually 3 colors, and they are returned as uint’s–why the .Net wrappers don’t convert to colors for you, I don’t know (to avoid linking to System.Drawing?).

The important thing is to convert them into the friendly System.Drawing.Color objects I know and love. For this task, there exists a handy ColorTranslator class. There is a FromOle method that does the exact chore you need. Here’s a sample of my code:

 

   1: private void GetCategoryColors()
   2: {
   3:     foreach (OutlookLib.Category category in
   4:         Application.ActiveExplorer().Session.Categories)
   5:     {
   6:         CategoryColor color = new CategoryColor(
   7:             ColorTranslator.FromOle((Int32)category.CategoryGradientTopColor),
   8:             ColorTranslator.FromOle((Int32)category.CategoryGradientBottomColor),
   9:             ColorTranslator.FromOle((Int32)category.CategoryBorderColor));
  10:         _categoryCollection[category.Name] = color;
  11:     }
  12: }

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

My Interview Experience at Microsoft

(If the thought of reading more than 4,500 words makes you hyperventilate, please go instead to my summary)

Please also read my Clarification on Why Study for an Interview

Like this? Please check out my latest book, Writing High-Performance .NET Code.

My Microsoft Background

Before I go into the specifics of the interview experience, I want to explain my background with Microsoft.

When I was just starting college, I got into an online community called DevHood. It was a student-focused .Net community where you could share tutorials, tips, code, and ask questions. Loosely associated with this were monthly .Net user group meetings on campus. My friend Ammon was the Microsoft student ambassador leading these meetings. By the time I’d graduated I was one of the leaders on DevHood (I’ve since dropped a few places–the site is now mostly inactive), and a strong desire to some day work for Microsoft was born. That desire has been occasionally reinforced by various MS events that I’ve been to, people I’ve spoken to, and blogs I’ve read.

Around the time I graduated I made it into an “interview” situation with Microsoft in the career center. I failed miserably. It was the first-ever interview I’d ever done with anybody, I didn’t prepare (at all), I was nervous (to the point of becoming very hot and sweating), and for some reason I thought I wanted to be a PM. Yeah….they never called me back. But it was a learning experience.

My freshman year in college is also the year I moved from using Borland C++ to using Visual C++ 6. I was also an early adopter of .Net and have generally been a fan of Microsoft. (You could maybe call me a fanboy, but I don’t think I’m completely one-sided. I consider myself pragmatic. Apple is just as good in many things as Microsoft, but I am really annoyed at the press it gets and the Apple fanboys. I think the biggest differences in OS X and Windows for most non-technical end-users are aesthetic.-Ed: please see clarifying comments below)

The effect of Google

I interviewed with Google last year, a process which I documented. Thank goodness–that experience really prepared me for this, though there were some big differences. For one, I don’t think I wanted the Google job. It was fun, nice to do, gave me a good experience, but in he end I wasn’t that disappointed. Microsoft was different. I wanted it and I prepared accordingly.

A month of e-mails and phone calls

It’s been a few months since this process started, so some of the details of timing or exact discussions may be off, but the overall story is correct.

A few months ago, I was contacted by a staffing firm that works directly with Microsoft to fill positions in various teams. I quickly responded, expressing my interest. The staffing agent who initially contacted me referred me to her boss, who was an extremely nice lady who works out of her home. She did initial questions like what kinds of things I’m interested in, can I relocate, etc. Mostly, she told me about the team that she is looking for: Live Search. She also acted as the buffer between me and Microsoft. She referred me to a Microsoft staffing person who also worked specifically with the Live Search group.

The Microsoft staffer talked to me first on the phone, about my projects, goals, Microsoft, the Live Search team, and how interested I was. He then setup a phone screen with the development lead of the team I was interviewing for, which was to take place about a week later. This phone call was postponed because of a meeting at Microsoft, and I actually did it a few days later than planned. No big deal for me, though it was a little hectic because family was visiting and I didn’t want to discuss my interviewing with them at this point.

Phone Screen

I prepared for the phone screen by writing questions for the interviewer, preparing standard HR-type questions and answers, and figuring out what I wanted to say about myself (overall), my interests, projects, current job, why I want to leave, why I want to work for Microsoft, and anything else I could think of. I also researched the team a little (I didn’t know which specific team it would be at this point, so this was mostly learning the major components of the Live Search group). I did not practice writing much code at this point.

The actual phone screen was easier than I thought, up to the end. We started with a little chit-chat, then he asked me about my current projects at GeoEye. He did go into technical details, but not too much. He asked me about my opinion on testing and other software engineering practices. I discussed unit testing and the efforts I had made to impose best practices in my current team. I was pretty emphatic in my description of software engineering practices, since I had seen such dramatic benefits in my work. We had a pretty good discussion about this sort of stuff and I felt like I was being taken seriously because of my experience. We also talked about working in teams.

After 30 minutes or so, he asked, almost apologetically, if I had time to do a coding exercise. Of course, I said yes. Oops. I didn’t do so well. With him on the phone, I e-mailed him my code at regular intervals. I took about an hour to hack out a recursive solution to a problem which I had actually never solved before. I think I panicked and not having immediate feedback I went down the wrong path for a while. I also should have thought of the design of the problem in terms of data structures, rather than just think of a vague code solution and go for it. I learned a lot from this exercise.

Even with that, he said, “I’m going to recommend you come in for an in-person interview. The coding was a little weak, to be honest, but I think you have great potential.”

He also specifically recommended reading Programming Pearls by Jon Bentley. This book was on my to-read list, so I gave it priority and ordered it, along with Programming Interviews Exposed: Secrets to Landing Your Next Job.

Preparation

My preparation for this interview was intense. I went through as many problems as I could think of. With Programming Interviews Exposed, I read 2-3 chapters at a time, making sure I understood each problem and the answers thoroughly. Then I went back and solved each problem on paper, without cheating and looking at the answers. Most problems I could have done without reading the chapter beforehand, but a few were new to me so the book helped a lot. It also helped show how many problems can be solved with creative application of basic CS principles. It also has good advice for handling salary negotiation and other non-technical aspects of the process.

Programming Pearls was even more helpful for formulating a mental framework for solving problems. I cannot recommend it enough. The material is much more deep than Programming Interviews Exposed and it will force you to think a lot more. I read the entire book and did as many problems in each chapter as I could. Most of them are thinking questions and not necessarily coding questions.

I also found and downloaded every list of programming questions I could find:

I did problems almost every night until I started to feel burned out. I solved every problem on those lists, other than some of the database/hardware/irrelevant questions. Whatever you do, don’t give in to temptation to look at the answers until you’re hurting with the effort of solving them. Memorizing the answers isn’t enough–you really do need to understand them, whether you figure it out yourself or look them up.

On the plane trip out, I reread Programming Pearls and did the problems again, making sure I understood nuances that I hadn’t noticed the first time around.

The Trip

About a week after my phone screen, I was contacted by a travel specialist who organized my trip. I was asked to provide some basic information, such as 5 dates when I could interview. I was nervous about this since I didn’t really want to ask for more days off from work, but I just went ahead and hoped it worked out. Once the date was established (nearly 3 weeks in the future), I was sent some documents on Microsoft’s online careers site. Logging in with my Live ID account, I filled out forms specifying my travel preferences, chose travel dates and times (I picked early the morning before, a Sunday, and to leave the morning after the interview). I also chose a rental car since I didn’t want to rely on a taxi. Microsoft makes all of the arrangements for you once you fill out this form.

On July 27, my wife took me to the airport for the direct flight to Seattle. It was a 5-hour trip, during which I re-read the entire Programming Pearls book. I had an aisle seat. At Seattle, I picked up the rental car from Avis–an SUVish Ford. Redmond is about a 30 minute trip up the highway and thankfully it was easy to get there. I had printed directions before I left home. I did drive right by the hotel without realizing it, and had to circle around–they’re a little back from the road, and the single sign was facing the opposite direction.

After I checked in, I went out almost immediately to find Microsoft. It was right across the street. I needed to find building 19, which is about a 5 minute trip. I then went to Azteca, a Mexican restaurant near the hotel. It was good food–too much, but very good. Microsoft pays for your food–keep your receipts. When I checked into the hotel, they told me that I could get any food from the little shop or order in and Microsoft will pay for it. I didn’t make as much use of it as I could have. I didn’t want to binge on junk on the theory that a healthy body is a healthy mind.

After eating lunch, I went back to the hotel to study for the rest of the afternoon. I went through the rest of the list of problems I had printed out. I was so exhausted by the evening, being 3 hours behind my home time zone. I had some chips and juice for dinner, and went to bed at 8. I knew it was early, but I thought I could sleep for 12 hours. Nope. I woke up at 3:30 am the next morning. Oops.

I got up, read a bit, exercised until I was bored, took a long, long shower, ate a big breakfast, and reviewed a few other coding questions. At 9:15 I gave up and left the room. My appointment was with the staffing representative at 10:00. I was there at 9:20. One thing I noticed–lots and lots of diversity. People from all over the world walking around. I reviewed a few things some more and went into building 19 at 9:40.

I got my name badge at reception and then sat down, eventually moving over to the Microsoft Surface that they had set up. The Surface is an awesome piece of machinery. There are a number of demo apps which are a ton of fun to play with. There were games, a piano, and some graphical visualizations that all interacted with multiple fingers at a time. They also have a number of PCs and an X-Box 360, which had a couple of people playing Rock Band on it.

A little after 10, my representative came out to meet me. He said he only had 30 minutes to talk, but I think we talked for almost an hour. We discussed fairly typical HR-type things. He went over some numbers related to Microsoft, then leadership of the teams from Live Search on down to the team I would be interviewing for. He discussed benefits, and then explained the day’s events. He gave me a piece of paper with an interview schedule that went through the 2-3pm slot. He said, “I can’t tell you who comes after this. If you do well, the last interviewer will take you to the next person. If you don’t do so well, they’ll take you back here and we’ll talk about it.” Yikes.

When we were done, he escorted me outside to a waiting Prius, part of their shuttle fleet that anyone can use to go among the various parts of the campus. I was headed to building 88.

The Day of Interviews

This is the part where I’m sure I’m going to disappoint some people because I’m not going to tell you the specific problems they asked me. I don’t think that’s fair, and there wouldn’t be much point anyway. I may tell you a rough description just to give you an idea.

Each interview followed a similar pattern: discuss your work, tell me about [software engineering topic] and your experience with it, now let’s do a coding problem. Sometimes I did a problem quickly and they made the problem more complicated, or gave me a completely separate one. I was not asked riddle-type questions. I was not asked dumb, typical HR-type questions (“What’s your biggest weakness?”).

Between every interview they will talk to each other and they will send e-mails to the other people in the interview loop. Yes, they’re talking about you behind your back. And yes, they will tailor future questions to cover areas missed by previous interviewers, or to follow up on a weakness. Also, not every interviewer is on the team you’re interviewing for. I liked this because it gave me an opportunity to learn more about other groups.

In the first interview, the coding problem was to generate a well-known data set. I first considered how to generate the nth iteration of the dataset, but she quickly steered me to solving iterations 1-n (which is much easier). I went over the algorithm in my head and out loud, before writing any code. Then I wrote the simplest, naive code that I could think of. I immediately saw some inefficiencies and worked to address them. She prodded me slightly to the answer she was looking for (I would have gotten there).

The first interviewer was also my lunch escort. We went to a cafeteria in a nearby building. I got a salad–not trusting my stomach for too much more. The food is not free, but it seems pretty cheap (coming from DC). The drinks are free. I got water. During lunch, I spent most of the time asking her questions about what she does, working at Microsoft, and the Redmond area.

After lunch, she took me back to the lobby to wait for the next interview. I took the opportunity to use the restroom and look at the art (there is original art everywhere). I liked the boat made from junk.

The interview after lunch was with the same person who gave me the phone screen–the dev lead for the team. He asked me if I had looked at the project they work on, and as soon as I said I had, he asked me what I thought they could do better, or features to implement. I was prepared with some intelligent things I noticed (which luckily coincided with some of the things he had first noticed when he joined the team). We talked for a bit about software engineering, testing, and task “chunk” size–i.e., how big of a task am I comfortable accepting at a time. This was an interesting topic which I hadn’t really considered before, but after a little time understanding the question I used my experience to give an honest answer.

He gave me two coding problems. Actually, before that he had asked me if I had ever done a certain problem and I answered that I had. So he gave me another one–a geometry/graphics-related question (not too deep). I had seen the problem before when taking computer graphics in college, and I knew the form of the answer. I just had to write specific code. Then I had to explain as many test cases as I could for the function. That problem didn’t take too long so he gave me another–a function to score a round in a certain game (one that I hadn’t played for a long, long time). He explained the rules, I explained them back as I understood them, and then I verbally sketched an algorithm to solve it. I wrote the naive code, fixed some algorithm mistakes and inefficiencies and I was done. I think I did well on this.

Then he took me to my next interview, which was the dreaded 2-3pm one. The same pattern ensued. This was a maze problem, and though I struggled a little solving it, I had immediately known that depth-first search was the way to tackle it, which was what he was looking for.

And…what happened next? Was I done? Do I get to continue until 5pm or am I done?

He took me to the next interview. :)

The next one might possibly have been my favorite. The guy I talked to had a lot of patent cubes, so I asked him about those and what his previous projects were. He then asked me a very interesting conceptual/coding problem about how to design a filter for the Live Search engine. We talked through it, and I came to a decent solution, which I then had to code. Definitely the most interesting problem of the day.

Then on to the next…it’s 5pm now. They’re offering me food, but I’m politely declining because I just don’t eat in high stress situations like this. That might be bad, but it worked for me.

A little bit of talk about software engineering practices, working in a team, etc. Then he gave me an array-summation problem. I was very familiar with this problem and explained that I knew a naive way, but that it wouldn’t work in all cases (i.e., bad input). He asked me to explain the problems, which I did. It was more like a discussion. He then gave me a tree-related problem, which I solved very quickly because I had practiced the exact problem before. Then he made it harder. He gave me a hint which at first confused me, but once I understood what he meant, I grasped the solution.

It’s now 6pm. I was sure I’d be done. There are fewer people in the halls now. The day is over.

He takes me to the next interview.

This is with the boss. The dev lead’s boss. I’m unsure of his exact title, but he was in charge of the team I was interviewing for and one other.

We talked for 45 minutes without a hint of coding. This was a wide-ranging discussion about everything from MS benefits to housing to traffic to the future of the team, the impact of Yahoo, comparison to Google, and culture at Microsoft. I gained a lot of insight and appreciation for what they’re doing. At one point he started talking salaries and benefits, and I got extremely excited and I had to fight to keep a smile off my face (hey, I don’t want to look like a dork too early). I was thinking that they were definitely going to make me an offer. Then he said other things which made me come back to reality. Finally, jokingly, almost reluctantly, he said he may be obligated to give me a coding problem, so let’s do a quick one.

Looking back, this should have been the easiest problem of the day, but I just got off track and missed the (now, painfully-) obvious solution. It was a problem about finding the nearest object in a geographic region. I cringed when he suggested the golden hint to me, and my thought was DUH. Maybe it was too late and I was tired.

Finally, at about 7:30pm I was done. He called the shuttle dispatch and walked me out, where we chatted for a few minutes before I insisted he didn’t have to wait with me.

Aftermath

I drove to the hotel and called my wife. I was elated. I knew I hadn’t been perfect, but I had just gone through a 9.5 hr interview. That couldn’t be bad. I thought for sure I was going to get an offer.

I ordered some Thai food from a delivery service, which I ate starting at 9pm. I watched a little TV, then went to sleep. I woke up at 4am the next morning to head to the airport for an early flight home. It had been a very long day.

The next day I talked to the staffing guy (the one who had started my interview day) about the experience. He was very…confusing? not sure how to describe my interaction with him. He told me that they were very happy with me and I did very well, and yet some of the feedback indicated slightly weaker coding than someone else they were interviewing. He needed to hear back from the team about the other person before a final decision was made.

Needless to say, this was not what I wanted to hear. I was pretty upset about it so my wife and I indulged in a little night out dinner to assuage the disappointment. I was sure I was not going to get the offer.

Two days later, I was at work when I got an e-mail from him. They are going to make me an offer! I quickly left the room (I share it with a co-worker) and called my wife. She was ecstatic. I was ecstatic. I was not expecting it, after the previous conversation. Looking back (and considering other conversations), I wonder if he was trying to gauge my dedication and desire for the job. My other, more cynical, thought was that he was trying to prep me to take a lower salary or not negotiate as hard because I must have “just squeaked by.” Maybe it’s just to make victory all the more sweeter. Most likely he was on the level, but I do wonder… it just seemed odd.

That night when he called, I was feeling pretty miserable because I think I was food poisoned that day–I was feeling horrible–vision was literally shaking–very scary. But I kept it together and we talked benefits, salary, relocation, and the next steps. We did the “what-salary-do-you-want/what-is-your-offer” dance, which I lost of course. Does anyone get an offer without stating their expectations first? In any case, the formal offer was worked out over the next few days. I was on vacation in Utah when I got it (all electronic). It was acceptable and I am now going to be a Microsoft employee in September!

Random Thoughts

I’m going to go work on a team that is a direct competitor to Google, and they are a very significant challenge. Microsoft has a lot to do to catch up to Google, but there is something exhilarating about working for the underdog. Even once the technology is better than Google’s, there is significant mind share that needs to be won. We all have our work cut out for us.

This is completely subjective and I’m biased, but I thought the people I interacted with at Microsoft were nicer than at Google. Maybe it’s because I did better, maybe it was my attitude, or maybe I was lucky with the people I spoke to.

When I drove up to the Microsoft campus the first day, it felt right.

There’s a lot to do in the next month–prepare the move, finish up stuff at work, prepare to buy a house, gear myself up for a difficult, demanding, but rewarding job–it will be a lot of work, but hopefully fun at the same time.

Tips

My tips for the Google interview experience apply here. In addition:

  1. Be enthusiastic. I got the distinct impression that they value this highly. Demonstrate it with your projects, your interests, your conversation, and even your tone of voice. That last is a hard one for me, especially over the phone. I’m enthusiastic, but I definitely have a hard time showing it verbally.
  2. Practice, practice, practice. Spend a lot of time practicing with pen and paper. Write out every search algorithm by heart. About half the problems they asked me are in the two books I recommended above. But beware that they’re going to expect you to go beyond those problems. Consider these problems as refreshers in basic computer science, not a primer to help you get the job.
  3. Know your computer science. If you don’t understand serious computer science, memorizing answers to lists of problems isn’t going to help you. Understand recursive and iterative solutions to common problems. Know data structures, big-O, and common algorithms. Know what methods and data structures can be used to solve which problems. You probably won’t be asked about advanced data structures or techniques–you just need to understand the basic ones really well.
  4. Know the team. Research as much as you can. In my case, I knew what the project was and I could actually use it and come up with suggestions. This may not always be possible. If not, learn about the larger organization that you can get information for.
  5. Have lots of intelligent questions. Many questions I asked to most people. Here is a sample: Favorite thing about working at Microsoft, Least favorite thing; My specific role. How big the team will be grown, impact of external events, comparison to competitors, strategy, where will the team be in the future, what’s your commute like, work-life balance, what do you work on (since not everybody you talk to is on the same project), what is your specific role, what other projects have you worked on at/outside of Microsoft, why did you move to this team, and lots more. The important thing is to be genuinely interested. If you are, then coming up with questions on the fly is easy, and you will have a natural discussion rather than reading a script. I moved from “script” to “natural” through the day as I became more comfortable.
  6. You must know what you’re talking about. This allows you to have nice conversations instead of feeling like you’re being quizzed. You’ll feel more like a peer, and hopefully so will they. You’ll already belong. Also, you can’t fake this so don’t try.
  7. The interviewers at Microsoft seemed much more willing to give me instant feedback than Google was. I could ask them what they thought of my code and they gave me honest feedback. I appreciated this.
  8. The book I read on the way home was The Neutronium Alchemist by Peter F. Hamilton. It’s the sequel to The Reality Dysfunction. Highly recommended for sci-fi fans.

Redmond, here I come.

Related links:


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

Virtual PC 2007 Tips and Tricks

 

This release of Virtual PC 2007 SP1 provides updates to existing features and introduces support for the following:

  • Windows Vista with Service Pack 1 (SP1) Business, Ultimate, and Enterprise operating systems as a host operating system

  • Windows Vista with SP1 Business, Ultimate, and Enterprise as a guest operating system

  • Windows Server 2008 Standard as a guest operating system

  • Windows XP with Service Pack 3 as both a guest and host operating system

  • Read The Virtual PC Guy’s Weblog
  • If you need, say, two virtual machines, one with Windows Vista and one with Windows Vista SP1, install Vista onto a new machine, then copy the machine files and install SP1 on one copy–much faster than installing Vista twice.
  • Need a screen shot of what’s in the virtual machine? Look at the Edit menu and choose “Select All” then “Copy”–a bitmap of the VM window will be on the clipboard. (This is how I got the capture of my BASIC graphics output from a previous post).

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

Opening Visual Studio solutions from Explorer in Vista

You’ve installed Visual Studio 2005 on Vista and dutifully changed it to run as administrator, like you’re supposed to. And then…

Problem: Visual Studio 2005 solutions no longer open when you double-click them in Windows Vista. In fact, when you double-click nothing happens.

Solution: Change them to open with Visual Studio 2005 directly instead of the vslauncher.exe (which opens up the solution with the correct version of Visual Studio if you have more than one).

Caveat: Only makes sense if  you use only Visual Studio 2005.

How-to:

  1. Right-click on a solution file.
  2. Choose “Open With…”
  3. Choose “Browse…”
  4. Browse to file “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe” (or wherever you installed Visual Studio)
  5. Click “Open” button
  6. Check “Always use the selected program to open this kind of file”

openwith

Now your solutions will load Visual Studio, bring up the UAC prompt, and it all works great.

Found via here and here.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

How to work an 8-hour day

One of the things I decided when I started working was that I was not going to be one of those guys who worked 12 hours a day for a company (if I ever become an entrepreneur, all bets are off since I’m working for myself). So far, I’ve been pretty successful, and I’ve noticed a few things that may help others. Some of these are more observations than practices.

1. Understand reality: Work Load

The first thing to realize is that the amount of work to do will always exceed the time available. This is why effective management is important. If you are being ineffectively managed, it may be difficult to force a change in some of the following areas.

Just because there is always more work to do, this is no reason to kill yourself trying to get it all done. Or even overexert yourself (except in rare instances). Don’t misunderstand: I’m not saying you have an excuse to slack. Giving all of your time and attention to your employer/projects/job is the baseline here. I am saying that just because you have a lot of work is not a valid reason to work 12 hour days.

Unless you enjoy it…in which case you’re reading the wrong article. If you’re a workaholic, sacrificing your health, family, and free time to get ahead, knock yourself out. You can stop reading now.

There are always special circumstances, though. If you operate in an environment that runs 24/7 services and Something Bad happens–well, then you need to fix it if takes you 24 hours. Hopefully, you’ll get corresponding time off in return. If it’s the last week before release of a project and a major bug comes up–get it done.

I’m talking about normal days, normal work.

If you are working 12 hour days and you don’t like it, then change. No excuses. Change the job or change jobs.

2. Don’t waste time

I knew someone who always complained about having so much work to do, working 60-70 hour weeks, always been pressured, etc. I know he did have quite a bit of pressure to do a number of things, but I eventually stopped feeling empathy for him because I constantly saw him talking to so many people (friends, not direct co-workers) during work.

If you’re so busy working long hours, why do you waste so much time? Why is it that the people who complain loudest about being overworked mostly create the situation themselves?

Don’t wander the halls looking for distractions–chances are you’ll find them.

There is a balance to strike here between enjoyable work environment, having friends, being part of a team, and actually getting things done. There is also something to be said for the difficulty of concentrating on challenging topics for a long time at a stretch. Breaks are definitely needed.

There are trade offs to everything. If you spend an hour or two every day reading blogs instead of working on your projects, you’ll pay for it in time later. If this is a trade off you’re willing to make, so be it, but make sure you understand your priorities and the consequences of your decisions.

I know someone else who used 100 words to say something when 4 would do. This made meetings long, tortuous affairs (unless strong ground-rules were created, endorsed, and enforced). Even simple questions were avoided because nobody wanted to sit there and endure a longer-than necessary answer about the history of the universe. Don’t waste people’s times, and don’t stand for people wasting yours.

Be wise, what can I say more?

3. Don’t micro-manage

The topic of micro-management is something that could take up other blog posts and books dedicated to the subject, but I just want to focus on aspects of it related to time.

This is an inverse of wasting time on trivialities. I once had another boss who spent unbelievable amounts of time responding to every trivial e-mail (and he insisted on being CC’d on every topic of course) and he also complained about working extremely long weeks. And he worked all weekend. He checked on the status of things constantly and was usually the first to spot potential problems. (There were other reasons for this, too: he was usually a main point-of-contact for customers and he had more domain knowledge of everything we were doing). He was very, very smart and usually not wrong, but he did spend a lot of time doing things that were arguably someone else’s job. We never felt invested in these aspects of work, though, because he just did them.

If you find yourself with your fingers in every aspect of your organization, you have a problem, and need to take some time out for consideration:

  • Why do you feel the need to be connected to everything going on? Is it because you have to feel in control, or do you not trust others to do a good job?
  • Do you not trust your employees? If not, why not? Do they really do a bad job?
  • If they do a bad job, why? Are they fundamentally lazy, unqualified, dumb? If so, why are they still working there? Why are you paying them and doing their job anyway?
  • Would better training help?
  • Maybe expectations aren’t clear. Instead of you picking up the slack, review the expectations you have for them and go over deficiencies. Make them responsible and give them ownership. Don’t undermine their jobs by taking it away. Check on them in the future to make sure things are improved, but don’t involve yourself day-to-day.
  • Is it necessary to involve yourself in every discussion or can you just ignore until it reaches a level you need to get into? Resist the urge to comment on things you weren’t asked about.

If nothing else, micro-management always breeds resentment.

 

4. Set boundaries

I have tried to make it clear to my bosses over the years that when I’m working on a task, I am not to be bothered on a whim. When I’m concentrating, don’t bug me. This is a somewhat loose rule for me, because it really depends on what I’m working on. However, it is more true than not.

The context switching that can happen with interruptions is dangerous for productivity. Eric Gunnerson wrote about “flow state” years ago. Flow state is a zone you get in where your brain is completely engaged–you’re firing on all cylinders, fully committed and involved–pick your metaphor. It’s hard to get into and easy to leave.

I have a nice pair of Bose QuietComfort 2 Noise Cancelling Headphones. These are essential for me now. The whole topic of listening to music while programming is a separate one, with some debate, but I find it usually beneficial. Sometimes I put them on to block sound without listening to music. This also minimizes casual interruptions. I rarely listen to music while trying to create a new solution for something–only when I’m coding something I understand.

Also make sure to enforce a work/life boundary. I have made it clear in my job that I am not be called unless it’s an emergency that needs to be fixed RIGHT NOW. I ignore IMs and e-mails (unless I’m in the mood to answer something, or it’s trivial, or I know it would make somebody happy to know the answer to). If there’s a critical problem, I’ll get a phone call.

I also communicate vacations and just how far out of reach of civilization I will be well ahead of time.

5. Limit Meetings

There is an abundance of resources out there for effective meeting management. I’m more in favor of limiting the occurrences of meetings in the first place. How well you can do this depends a lot on your organization and the projects you’re working on.

Pointless meetings are a waste of everyone’s time. They can be demoralizing, energy-sucking vortexes. Recovering from a bad meeting can take further attention away from actually getting things done.

In my case, we have mercifully few meetings–only when the entire team needs to give input, we need to brainstorm about a tricky problem, or general status updates (yearly or quarterly).

Much of what goes on in meetings can be substituted by effective individual planning, e-mail, issue tracking, or planning better in the first place.

6. Know your tasks

Spinning your wheels is death. Don’t be wasting your time unconsciously (If I’m going to waste time, I’d rather do it consciously with Desktop Tower Defense).

If you’re stuck on a task, get help, change gears, do something else. Make sure you have a process to detect when you and others are stuck so that you don’t waste time.

Always know what you’re supposed to be working on. In addition to have issue-tracking software, make sure priorities are communicated clearly and often. Once you finish something, you should know what the next task is, whether  you do it then or not. Whenever I have a problem of knowing my priorities, I ask my manager. It’s his responsibility to know and set them. I don’t have to worry about it.

There is usually a list of “nice-to-haves” that you can work on once high-priority stuff is done. Don’t let that list get lost, but track it the same way you do regular issues.

7. Effective Information Management

This means all sorts of data: e-mail, documents, data, scheduling, task lists. Simplify, automate, streamline. I won’t go into specific techniques–you can find them elsewhere.

Just a few simple points that I use:

  • Don’t read what you don’t need to
  • Don’t respond when you don’t need to
  • File away or delete ASAP

It’s easy to get buried in information these days–and consequently it’s easy to think it’s at all important. Don’t fall into that trap.

8. External Motivations

A little obvious, this one, but important to ponder. None of this will work if you don’t have strong outside motivations. You have to really enjoy being outside of work–and I don’t think the satisfaction of doing nothing is enough. You’ll get bored of that eventually. Sitting in front of a TV every night “unwinding” for three hours is not a motivational experience (quite the opposite, usually).

Hobbies, projects, sports, exercise, cooking, family, church, books, culture, service are all part of life and should be enjoyed.

I usually schedule my evenings to some degree–whether it’s working out,  moving ahead on personal programming projects, building my latest LEGO model, watching a movie with Leticia, or reading a book–I’ve got a long list of things I enjoy doing. If I don’t follow the schedule exactly, or can’t fit everything in, I don’t sweat it–as long as I’m enjoying myself, that’s what matters.

Work isn’t everything–in fact, it isn’t even the greatest part of anything. Be well-rounded.

* Exceptions

Unfortunately, not every job can be forced into a neat 8-hour work day. My wife, for example, works for a news wire service. She works 8-hour days most of the time, but quite often she ends up staying late to take care of things. Unfortunately, when your job depends so much on other people, it can be a bit hard to plan days, and it’s very possible that work comes up right when you leave, or there is too much work to fit in in a day. However, this is unsustainable in the long run. Either more efficient processes have to be introduced, the work load decreased, or more people hired.

A word or two about politeness as well: it’s difficult in some environments to enforce better behaviors without being considered rude, grouchy, or holier-than-thou. Sometimes firmness has to give way to politeness. The carrot usually works better than the stick anyway in the long term.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

GetTextExtent vs. DrawText (with DT_CALCRECT)

Working on an MFC app that has just been converted to Unicode (finally!), I noticed that one button (which is created dynamically) is too small to fit the text in Korean (and Russian and a few other languages).

The code was calling something like:

CSize sz = m_btAdjustColors.GetDC()->GetTextExtent(sCaption);

It seems correct, but these script languages are throwing it for a loop–the measured size is much smaller than it should be. The GetTextExtent documentation doesn’t shed any explicit light on this subject, but may hint at it.

The solution? DrawText. There is a flag you can pass to tell it to calculate the rectangle needed instead of drawing.

CRect rect(0,0,0,0);
m_btAdjustColors.GetDC()->DrawText(sCaption, &rect, DT_CALCRECT);

It’s important to initialize the rectangle to zeroes because, as the docs say, it only modifies the right and bottom members of the rectangle.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at: