Posts Tagged productivity
I mentioned how eager status code analysis is awful. A policy that forces developers to put XmlDoc comments is a good example of that.
This is how I see it: as I think through how I want to implement something I create an interface (created off tests I just wrote). The code might look something like this…
Right off the bat, VS is already showing me squigglies on the code I just wrote. I hover over it and this is what I see:
Right now I can’t even compile the code, and I don’t feel like typing Xml comments because I’m still thinking through my design and implementation. Parts of this interface are likely to be changed very quick, and any sort of documentation will become useless.
Since I need to conform with this policy, I use GhostDoc to just spit out the comments:
At this point I don’t really care whether the auto-generate comments make sense or not; I’m just satisfying what’s required in this development environment setup so I can get my immediate work done.
Of course, now what used to take just under 10 lines of code cannot even fit on my screen anymore and it requires scrolling!! That’s unacceptable to me. I can’t quite function seeing so much clutter! Fortunately, I’ve found this NoComment extension, which gets those comments out of my sight:
Now I can actually focus on what’s really important. Later, when I’m done with my design and implementation, then, and only then, I can review those Xml Comments prior to committing the work to the central source control repository.
I like static code analysis.
I like how it reminds me how I can improve the code by applying certain refactoring patterns.
I like how it tells me how I can clean the code by using a new language feature I might not be aware of.
I like how it enforces a certain style and conventions on a codebase changed by several developers.
However, I have grown a special distate for static code analysis that’s run way too eagerly!
What do I mean by that? I do not like it when it’s run as I type the code. Done that way, it prevents me from finishing my thoughts. Many times I’m trying out ways to implement something, and I don’t like static analysis bugging me about things that aren’t important at that point in time. Treating those as errors make things even worse as the IDE shows red squigglies and distracts me.
I don’t like static analysis even when I compile the code. Why not? Because it gets in my way as I go through the Red-Green-Refactor process.
Static code analysis should run when we push the code to the central repository. At that point, check-in policies could block the commit if there are violations to the rules. Such analysis run any time before that is a productivity killer.
A whole decade ago (yikes, I’m getting old…) I wrote about how I was Organizing Windows and Multiple Monitors. I still use that approach when I’m working on a PC with dual monitors. The only thing that has changed is how I get it to work in Visual Studio 2017.
So, let me explain the steps I take.
I first set all the windows in VS according to how I want them when I’m focused on coding. In that case, I want to make full use of all my real state, which means, use my screens wisely. My dual-monitor setup look somewhat like this:
Once I found my perfect setup, I then export my settings by going to Tools -> Import and Export Settings…:
I then unselect all settings and select only General Settings -> Windows Layouts:
I export the settings to a dual-monitor.vssettings file on a c:\tools\settings folder.
Next, when working using a single monitor (which is usually the case when I’m in a conference room and projecting my screen), this is what my single-monitor setup looks like:
Once I’ve found my perfect setup for single monitor work, I export the windows layout settings to a single-monitor.vssettings file to my c:\tools\settings folder.
Now, whenever I want to switch between the different layouts, all I need to do is to import the settings accordingly.
But if you’re switching between layouts too often every day, then automate the process of importing settings!
It seems like VS 2017 has dropped support for Macros (seriously?). Fortunately, there’s a nifty extension out there called Visual Commander (I mentioned I was using it for Toggling Visual Studio CodeLens On/Off, remember?).
Once you’ve installed Visual Commander, you are welcome to download the commands I created to import single/dual monitor VS settings and import it into your Visual Commander setup. Once you’ve imported it, you can easily switch between layouts by using the commands under the VCmd menu:
The VCmd commands are simple macros that automate that simple process.
Also, if being two clicks away (or Alt+C + a few key strokes to access the menu option and hit Enter), you can set a shortcut in VS to access those commands! (See this other post if you need to learn how to do that).
I personally do NOT like sorting class members alphabetically. Once in a while I run into developers who prefer it sorted alphabetically, usually on the grounds of believing it’s easier to find things around that way. I disagree. Let me explain why…
Take the following class as an example:
Now here’s the same class with the members sorted alphabetically:
To me, the code in the first example is much easier to understand. Related properties are grouped together, and they’re listed in an order that makes sense.
If I do want to find something alphabetically, I can use the dropdown menu that lists all members that way:
Or, better yet, I can hit Alt+\, which is the Resharper shortcut to “Go to File Member…”:
Following my trend of hinding everything I don’t need on my environment, another default thing I get rid of is the Standard toolbar in Visual Studio:
The actions available in that toolbar which I use all day are Save All and Start Debugging, so I simply use the shortcuts Ctrl+Shift+S and F5, respectively. Why would I want that toolbar up there taking up screen real state? Yup, I don’t! I just get rid of it: right-click in that area and uncheck Standard:
Much better. One less thing I have no need to be seeing all the time!!
As I’ve mentioned before (here, here, and here, at least), I’m very specific as to how much stuff I want to see on my screen as I’m working with code. Visual Studio can be very cluttered depending on how we set it up; so much so that sometimes I feel like just open my cs files in Notepad!
One of the things I think get in my way is the feature CodeLens in VS. While it does provide good information and access to useful things, I hate it being on my face all the time! I rather it only show me the goodies when I need it.
One thing in that post that wasn’t clear is the name of the command I need to bind the shortcut to. I thought it’d be the name of the command I created in Visual Commander, but that wasn’t the case. Editing the command in Visual Commander, I noticed Command01 right before the name I gave to the command:
And that’s what I needed to look for in the Keyboard dialog in VS:
I’ve bound the command to the Shift+Alt+CL shortcut (for CodeLens).
Now, if I toggle the feature On, I see all of the extra stuff it shows me:
Otherwise, I get to focus only on the code (which is what I want 98% of the time!):
The less stuff there is mingled in the code, the easier it is for me to read and understand it.
My last post covered how I’ve been Organizing my Daily, Weekly, Monthly, Quarterly, Yearly activities. In this post I’ll go over how I organize and track my day.
I keep a note titled Daily Execution in Evernote. Every morning, I review my Daily, Weekly, Monthly, Quarterly, Yearly note to check what’s in the calendar for the day ahead of me. I look for things that have to happen at a set time (such as a meeting) as well as things that have to happen on this day, but not at a specific time.
This is a template of what my Daily Execution note looks like:
I try not to pollute this note with too much information. If I have a meeting, I create a note for that meeting, put all the details I need in there, and then just add a link to it on my Daily Execution note. If the meeting is a place I have to drive to, I’ll add the address to the note, so I can easily tap on it on my phone and pull up directions. If it’s a phone call, I put the phone number on the note, so I can simply tap on it on my phone.
This note is my single source of truth for my day. It needs to give me a clear idea as to what I need to do on this day, and it needs links to other notes with further information about those things.
I check this note several times all day long.
Many times I’m checking it on my phone, so I try to make it easy to look up information I need.
As the days go by, I jot down quick notes on things I just did. I use vJournal on my Mac or iPhone for that:
vJournal keeps a note in Evernote with timestamps for everything logged that day:
The iOS version of vJournal also adds location information to the note. I like that because sometimes I’m driving by some place and I see something I want to check out later (for instance, a stakepark I didn’t know of). Logging that info to vJournal allows me to easily find out when I saw the place and where it was so I can go back there later.
At the end of the day, I review my Daily Execution note, as well as the note created by vJournal. I verify what I had to do that got done and what didn’t get done, and create new tasks, calendar entries, etc, accordingly.
Once I’m done reviewing that information, a copy all of the content in my Daily Execution note, paste it at the bottom of my note created by vJournal, tag it with “daily log”, rename the note to follow the format YYYY-MM-DD (which allows me to quickly find my log for a specific day), and move the note into a Archive notebook.
For the records, I started using the approach of having a single Daily Execution note about two years ago. The approach of keeping a daily log I’ve started all the way back in 2010 (as of today, I have 2349 notes tagged “daily log”)!!
As far as keeping a daily log like that, I can’t tell you how helpful it has been. I’m often going back to it to help recompose my memory on things I’ve done, people I’ve met, places I’ve been, ideas I’ve had, etc.
I’ve been changing how I do these things slightly over the years, trying new things out, but the basic idea has been sticking around and it works well for me.