The Moth

Following on from the tips on how to setup your laptop for demos (with some great ones from you in the comments!), I thought I'd follow up with how to setup Visual Studio specifically.

Whilst the language I use below is prescriptive as always, please note that I am far from an authority so all I am doing here is sharing my views. I'll start with 2 that I know are controversial and then move on to a mixture of mainstream points with a couple tips that I suspect most of you have not come across before.

A) Don't change colours; don't use "themes". Use the default settings.
I've been in presentations where the presenter puts a lamp of code on the screen and I am trying to compile it in my head except all the stuff I am familiar with has changed: default colours of types, keywords, comments, strings and even code editor background! "Why would you ever do that to the audience? Why do you hate them so much?". To be clear, it is fine for you to "pimp your IDE" for working purposes. However, when showing dozens (if not hundreds or thousands) of other people a demo using Visual Studio, what is the lowest common denominator that you can assume about them? Answer: that they are familiar with the default settings of Visual Studio. Unless your goal is to prove how smart/artistic you are, instead of trying to make it as easy as possible for them to follow your code, please take heed.

B) Leave the 3rd party productivity addins at home.
In case you are not familiar with them, there are 3rd party enhancements to Visual Studio (such as resharper, coderush, codesmith, visualassist, [insert your favourite here], etc) that can truly increase your productivity multi-fold. However, recall from point A above that the majority of your audience will not be familiar with them. When we show code during a demo, all effort from the audience should be concentrated on understanding the API/pattern that you are explaining and not be distracted by seeing menus they are not familiar with and being confused by how you managed to accomplish something with a shortcut that they never heard of before. Unless, of course, you are actually an evangelist for those products and/or you need the productivity boost during your demo because you are coding it for the first time instead of having rehearsed what you are showing. Do you really want your attendees coming out of your session and talking about how they enjoyed learning about one of the said products, instead of walking out with the intended take away that you had in mind?

C) Use large enough fonts everywhere.
Don't wait for the audience member to shout out to you to enlarge your fonts. Go to Tools->Options->Fonts and Colors and change the "Text Editor" font to at least 14 (and for some rooms 16). In fact, when you reach the room you are presenting in, launch Visual Studio and go seat on the last row of chairs starring at the projector; can you read your code? Furthermore, change the font for things like Tooltips, the intellisense window and all the other "Tool Windows" (hint: look at the top combobox with the label of "Show settings for:").

D) Change your highlight colour for selected text.
This is my only rule that goes against A above. Simply put, if you leave your "highlight" as the automatic default of "Blue", your text is not visible to the audience – not sure why people don't get that. You are having the opposite effect of your goal when you highlighted that piece of code. So, as per the instructions of C above, find the "Selected Text" and change the "Item Background" to "Yellow". FYI in the past I used "Lime" but I have found that some projectors show lime darker than what it is on my screen, so I have switched back to yellow.

E) One docked tool window.
I've seen demos where the presenter had multiple docked windows on all sides. How much of the code in the editor is viewable at any given time at 1024x768 resolution at 120 DPI? Every demo you do will have different windowing requirements, but in my experience I have never needed more than one side for docked tool windows (for me that is on the right, but right or left is a mute point IMO). Of course, I'll bring out a tool window from the other side (on the left for me) and also from the bottom but they are set to auto hide so they get used quickly and then disappear. You may also be tempted to autohide all tool windows but in most demos I find it useful to have solution explorer always visible because attendees can easily glance at it during the demo to remind themselves of the big picture (instead of viewing just a single code file). Regardless, windows that are set to autohide but are never used during a demo should be closed/exited instead – what is the point of having tool window tabs(=clutter) in the IDE if they are not going to be used? TIP: for prebaked demos, you can layout all the tool windows (dock/autohide/close) and then save/close the solution and the next time you open it you'll find them all in the right place!

F) Two toolbar rows; for all documents.
Again, this has to do with space-saving and with clutter removal. You may be tempted to get rid of the toolbars completely but, not only that looks weird (recall the point on familiarity), but I actually use the toolbar for some actions instead of using keyboard shortcuts so I can make very obvious to the audience what it is I am doing. I doubt there is any demo that requires more than 1 row of toolbars, but in the interest of familiarity I leave the first toolbar appear as it does with default Visual Studio settings and then customise the 2nd row to match whatever my demo(s) require – so I always have 2, no more no less. You may find that when you switch between document types the toolbars "dance" around so you must make sure you preserve the height (i.e. the 2 toolbar rows). For example, you open a Windows Form in code view and you have 2 toolbars showing but when you switch to design view then one of them (annoyingly) disappears – it is down to you to enable another toolbar for design view too, so as to preserve the overall toolbar height when switching between documents.

G) Tab Size = Indent Size = 2 spaces.
There are religious arguments between developers as to whether the editor should be using spaces or tabs (for indentation). There are also disagreements on whether the correct number of spaces (or tab size) for an indent is 2 or 4. I have little interest in opening that debate and when you are developing at home, do as you please. For presentation purposes though, you must eliminate horizontal scrolling (I hope that is an axiom and hence I don't need to prove it) and given that you are running with large font at 1024x768 at 120 DPI, guess what is a low hanging fruit? That's right, make the Indent = 2 spaces and you've just saved yourself a ton of white space and with it unnecessary h-scrolling. You can make this change from Tools->Options->Text Editor->[Your language]->Tabs.

H) Remove namespace declarations.
This one is along similar lines to the previous item – saving horizontal scrolling and unnecessary white space. For most prebaked demos, there really is no reason to have a namespace (which gets generated by default in C# code files). So simply go and remove them all and save yourself another 2 horizontal columns per file e.g.

namespace MyNamespace   // delete this
{                      // delete this
  class MyClass
  {
  }
}                      // delete this

...and then hit Ctrl+K,Ctrl+D to reformat it all nicely.

I) Maximise, in more ways than one.
I kid you not; I have been in a session where the presenter did the whole show without ever maximising Visual Studio! I was this close (imagine me holding my thumb and index finger close together) to getting up on stage and hitting the maximise button of Visual Studio to occupy the whole screen. Besides that obvious advice, what helps with some of the goals of some of the items above is to maximise the code editor (Shift+Alt+Enter) at opportune moments, especially if you are going to spend a lot of time in one code file.

Epilogue
There are other things that I do in Visual Studio but I don't want to go through the entire alphabet here ;-). For example, I am such a strong believer in "including" as much of the audience as possible and not appearing biased, that when I first run up Visual Studio after installation, I select General Settings (instead of C# or Visual Basic).

Do you agree with all of the above? Do you vehemently disagree with some of it? How do you utilise Visual Studio for demos? I look forward to reading your comments below...