Workstation Hack: Visual Studio on 2 monitors

Having two monitors is an obvious improvement to any development workstation, but are there tricks for really effectively using all that extra acreage? I learned a great strategy from a co-worker for a two-monitor setup for Microsoft Visual Studio.

Hack Summary
Maximize the editor on one screen, and pull out all the floating windows (Solution Explorer, Error List, etc.) onto the second screen—which is great until you want to look at your database or your wiki or your work-in-progress app while also typing code. (If you're typing in the editor, Visual Studio is in front, which means all those little windows are in front of any other app you want to look at while coding.) The solution is to set up some shortcut keys that switch you from "Sprawl across two screens" mode to "Pull everything into one screen, dock the little windows, and make the second monitor available for other stuff" mode, and back.

Export Two Sets of Window Settings
You can save Visual Studio settings (such as window layout) to a file, and later import that settings file. For this hack, we'll export two settings files (one for two-screen, sprawl mode; one for one-screen, compact mode). Then, we can switch from one mode to the other by importing the appropriate settings file.

Get your windows how you like them in one-screen mode. For example, my Solution Explorer is a docked pane on the right, unpinned so that it auto-hides; and so on, for the handy windows I want at my fingertips. So, set those up.

Go to Tools > Import and Export Settings... > select the radio button for Export > click Next > uncheck All Settings > expand General Settings > check Window Layouts > click Next. Name the file (e.g., OneScreen.vssettings) and give it a location. Click Finish.

Now set up your windows in two-screen mode. Unhide a window by hovering over it, pin it, right-click on its title bar, and pick Floating. Drag it where you want. This is the artistic phase.

As above, export those settings, with a different name (e.g., TwoScreens.vssettings).

Create Two Switcher Macros
Add a macro module in the Macros IDE (Tools > Macros > Macros IDE), and create two macros, one to import each settings file. Here's my module, called WindowsSettingsSwitcher, which gets my settings files from C:\VSSettings\.

Imports System.IO
Imports EnvDTE
Imports EnvDTE80
Imports System.Diagnostics

Public Module WindowsSettingsSwitcher
    Public Sub SwitchToWinLayoutTwoScreens()
        DTE.ExecuteCommand("Tools.ImportandExportSettings", "-import:C:\VSSettings\TwoScreens.vssettings")
    End Sub

    Public Sub SwitchToWinLayoutOneScreen()
        DTE.ExecuteCommand("Tools.ImportandExportSettings", "-import:C:\VSSettings\OneScreen.vssettings")
    End Sub
End Module

You can test the macros from the Macro Explorer by double-clicking their names.

Assign Shortcut Keys to the Macros
Create some shortcuts that execute those macros. Tools > Options > expand Environment > click Keyboard. In the "Show commands containing" box, enter some text that will find your macros, e.g., "switchtowin" if you used my names above. Highlight a macro, put your cursor in the "Press shortcut keys" box, and type your shortcut. (Mine are Ctrl+Alt+1 for one-screen, and Ctrl+Alt+2 for two-screen, since those weren't in use by anything else.) I left the "Use new shortcut in" set to "Global." Click OK.

At this point, you can use your shortcut keys to switch modes. I added them to my View menu, too, mostly to give me a visual reminder of the shortcuts.

Add Switcher Commands to the View Menu
Tools > Customize > Commands tab > select the "Macros" category. Click and drag your macro from the Commands list in the dialog up to your toolbar. When you hover over View, the View menu will appear, showing the insertion point for your new command. Drop it in place. Right-click on the command in its new location, click on the Name box, and edit that down to something helpful (e.g., "OneScreen"). Repeat to add the other macro. Close the Customize dialog.


With this hack, you can keep lots of useful Visual Studio bits visible (liberating you from relying on the mouse to hover over auto-hiding windows, and maximizing your editor window), but stow them away quickly when you need the second screen for something else.

So how 'bout you? What are your workstation hacks?

Change your organization, or...

So here's the thing about being in a place that makes you depressed: You're too depressed to make the changes necessary to get out of the place. It can seem insurmountable. In eerily coincidental-sounding but utterly unrelated news (*cough*), I have a new job! You will certainly already know this if you've had occasion to see me bouncing off the walls lately. While some of my friends are content in their jobs, many are not, so I'll share my self-help program, in the hopes that it might console and inspire those who are wishing for a change.

I had been in the old job for 8 years, so even thinking about a change was scary. Here's what I did.

Believe.
You deserve a job that makes you happy.

Really, you do. You probably have a list of reasons why you need to stay at the place you're at, but look critically at those reasons. Put yourself into a five-year-old's mindset and ask "Why? …Why? …Why?" about each one. The reasons on my list, when I started doing some fact-checking out in the real world, turned out to be myths.

Throw rocks at that old adage, "…that's why they call it 'work.'" Pfft, whatever. If you're reading my blog, I'll assume you're a knowledge worker, and probably a programmer, and someone who likes to think about new ways of doing things. Lucky us, there are many lucrative careers for people who like to think. For me, writing software is like play—heck, it is something I do for play—so I didn't need to find a different line of work, just a different job that let me write software. You don't need to suffer to put bread on your table.

Network.
Get out there, walk amongst the people. If you're really sunk in the doldrums, this is probably the most tempting one to blow off, but here are some benefits: meet people with similar interests and challenges; dispel myths about the job market; find inspiration, in people who like their jobs, in people with passion; meet job prospects; become known for your ideas and contributions.

Networking and professional venues I find helpful: door64, AgileAustin, AgileATX, GeekAustin, Austin .NET User Group, classes, and my blog. Yeah, yeah, and LinkedIn.

Define the goal.
I developed a really clear list about what I wanted in an employer. Honed it, you might say. Took it out during meetings and quietly polished it. But this was helpful, because it gave me a concise list of interview questions to ask of my potential employers. The ultimate filter question, the one at the top of the list that immediately let me know whether it was even worth continuing, goes like this: "Do you like your job?"

Look for a yes. There are a ton of answers that are not yeses. I know, because I had years of delivering them myself. "It presents me with a lot of challenges. I get to work with people from all over the world, and I'm part of a great team." Yeah, but that wasn't a yes. I want to work in a place where it's possible to like your job.

Keep it positive.
No matter how bad it is, if you come off as a complainer, you will sour job prospects. Be diplomatic, and steer the conversation to what you're working towards, what you look for in the future.

Seek support.
To keep the gushing to a minimum, I'll simply say: My husband rocks. You've probably got someone, too, whether a sweetie or a best friend, a pen pal or your mom or your dog, someone who knows that you're awesome. This is a good time to trust that person (or dog), to let him or her know that you're embarking on something intimidating and you'd like encouragement through the journey. It helps to have a belayer.

Believe in yourself.
At my lowest, I believed that I had no useful, marketable skills; all I was good at was politicking my way through my employer's byzantine bureaucracy. I had to break out of that if I was going to even begin the process of moving elsewhere. (Or of getting a promotion, for that matter.) I got a big sheet of newsprint and a box of goofy-big crayons, I went into a room by myself and closed the door, and I brainstormed. Crazy, wild, unrelated ideas about what I do, what I'm capable of, and what I am that is awesome. I wrote a lot of things on that paper, and many of them showed up on the next draft of my résumé.

Improve.
And then I thought about what I wanted my résumé to look like. Or, more specifically, what skills I would need in order to get the kind of job I would enjoy. I made a curriculum: books to read, topics to research, and projects to implement. Tuesday is homework night, for writing code. Here's the trick to making this palatable: Every time I worked on a curriculum item, I complimented myself on taking another step towards that new job. When you're in a hole, the very act of climbing up makes you see the sky. That's where I'm going, and I'm making progress towards it. Yay, me.

So there's an overview of how I improved my lot in life. The hardest part was overcoming inertia and getting started. Well, that, and persevering through to the goal. ;-) If you're happy where you are, don't forget to look around and appreciate that from time to time. Every job has its annoyances and challenges I imagine, but it is possible to find one where you feel fulfilled and appreciated, where your skills are useful, and where the challenges are fun. You deserve a job you enjoy.

Lurking Under that Resistance

Some of the topics at the AgileAustin Open Space revolved around a theme. Is Agile appropriate for critical systems (medical, life-supporting software)? Can we use Agile when we have a fixed timeline and a finite budget? Will Agile work when our software supports an always-on manufacturing floor? What about when developing strategic software, breaking new business ground? Are there times when Agile is not appropriate?

I believe the conveners are primarily asking these questions as proxies. They're at the conference because they believe in Agile, but they've been asked these questions by stakeholders they need to convince. So they're looking for help in crafting their arguments.

In my experience, resistance to Agile derives from an underlying fear. That fear tends to take some mix of two forms: "I've invested my career in getting good at one way of doing things, and you want to make me obsolete," and "My rear is on the line for a lot of money. I'm not interested in risking my rear while you experiment with your touchy-feely methodology. Just deliver."

When trying to convince someone, first sussing out his concerns and then pitching your argument to address them will make you most effective.

For the fear of obsolescence, convey that, while some ways of doing things may no longer be needed, the person is still valued, and he has skills and experiences that will help the team make the transition. Give that person a clear role, an obvious place of value, and his fears and therefore resistance should relax.

To those who are inherently change-averse, you can still work to improve the feeling of safety, to make the change more palatable. There are some folks, however, whom Agile doesn't suit. Let them find jobs as SOX auditors or something.

For those who seek assurances that this crazy experiment will deliver, on time and on budget, I take two tacks. I show them burndown charts, and explain how you can clearly see, "Does this trend line look like it's going to hit the finish line when you want it to?" Burndowns are very communicative graphics; they're a great tool. Second, I ask permission to try it for a month. Just, give me two sprints. Worst case, you've lost a month, which you would have spent writing half of a Business Requirements Document. Best case, you might have a few high-value, ready-to-ship features. That's a pretty good risk-to-return ratio.

Understand what fears are hiding behind their resistance. Address those fears (usually without making direct mention of them; fear tends to turn defensive if you point out a perceived weakness). Talk in their language, using their own levers, to present your case (e.g., talk numbers to a finance person). Finally, ask for something reasonable: "You don't have to do this forever, just let us try it for a bit, and then you can decide whether to continue or adjust."