Archive for category Productivity
I have posted many times about my extensive usage of Evernote: I’ve just broken the 25k-note mark! I organize my notes by using a good mix of notebooks and tags. But going beyond that, I also organize certain notes based on when I need. For example, there are times when I need notes…
- This Week
- This Month
- This Year
When I’m doing my period review (daily, weekly, monthly, yearly), I tag notes as per my temporal needs as listed above (i.e., “today”, “week”, “month”, “year”). I then use Evernote’s feature to have multiple tabs open:
On the Mac version of Evernote, I do the following:
- Open a new tab (Command+T)
- Filter on the given tag (Command+J to search for the tag)
For example, when I do my weekly review and planning for the upcoming week, I create one note for each meeting I have coming up, and then I tag those notes with “week”. That way, it’s easy for me to find those notes and drop in comments or any other information I’ll be needing in those meetings.
Another tip: depending on how I’m working on my notes at a given point in time, I also leverage the option to open a “new window” in Evernote. That way, I have one window with tabs for the different periods I’m organizing, and another window for anything else (sometimes with tabs for different projects, people, places, etc.).
I’ve first heard of having a “pre-game routine” in this post by James Clear, and have used to technique a couple of times. This week, I’ve decided to try it out as a “code writing warm-up”. 🙂
The idea is to write a little bit of code for a couple of minutes just to get my mind in that mode. I also decided to stack pair this new habit with either learning or getting better at something I see room for improvement. In my case, that’s ES6.
I’m relatively new to ES6 and am still educating my brain to get used to reading and writing it. I enjoyed using RubyKoans back when I was learning some Ruby, so I figured I could try something similar for ES6.
I’ve found this collection of ES6 Katas; before starting any sort of coding in my workday, I spend 5-10 minutes doing these Katas. I’m digging it!
If there’s anything I do all the time, I try to either find or create a shortcut so I can do it using only the keyboard. Moving windows around is one of those things (maximize, minimize, dock to different parts of the screen, move to different monitors, etc.).
On the PC, I use the combination WinKey+(up/down/left/right arrows). For instance, say I’m working with Notepad like this:
If I want it maximized, I hit the Windows Key + Up Arrow:
If I want it restored back to its original state, just hit Windows Key + Down Arrow.
If I need it docked to either the right or left side of the screen, I hit Windows Key + Left/Right Arrow:
If I want to move the window moved to another monitor, just keep hitting Windows Key Left/Right Arrow until the window makes it to the other monitor (once it gets there, I usually hit Windows Key + Up Arrow so it gets maximized).
On the Mac, I use the SizeUp app, which gives me even more options to manage windows on my screen:
I use these shortcuts all day long!!
As it turns out, I just realized the post where I talk about switching windows layouts in Visual Studio 2017 was dead on arrival. Well, the tips I gave regarding exporting/importing settings and using VCmd to automate some of that is still relevant and useful.
However, for switching windows layouts, somewhere between VS 2013 and 2017 the tool finally introduced something to make that easier:
Regardless of the approach, please consider using your screen real state wisely. I see a lot of developers fighting VS with its several windows all crammed into one screen, while the other screen has either MS-Outlook or a web browser open at all times showing all sorts of useless things that can only steal away productivity and focus.
There are times, however, when I’m doing temporary work at a client’s machine and I don’t want to use my personal SnagIt license, so I use the next best thing: Jing (also by TechSmith). It’s free, and it has several of the main features I use all the time in SnagIt.
Jing has a quick access feature that sits at the top of my screen:
I select the window or area I want to capture, perform some basic annotation, and then either put it on the clipboard (usually to paste it on Evernote) or upload it to screencast.com (free service from TechSmith) so I can easily share the image through a link with other people:
That’s it: simple free tool that I use a lot everyday and makes me more productive. Win-win.
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.