Archive for category Productivity

Multiple screens may NOT make you productive

Several people talk about how having multiple screens makes us more productive. But does it, really?

It’s not the number of screens that matters; it’s how you use them!

Let’s take my current setup as an example:

Those three active screens are the ones I use when doing most of my focused work. Let’s say this is how I use those screens:

Hey, we can see a Pomodoro Timer at the top-left on that picture, so this MUST be a very productive setup, right? I’m afraid not. Consider my current focus is software development work. Let me walk you through the points I’m indicating on the picture:

1. Dead space. Unused real estate. If I’m on my focused time, I should probably not be seeing my exciting track photos, which change every 20 minutes; maybe a solid color would help keep my focus;

2. An email client. My current focus is NOT “email processing”, I shouldn’t keep the distracting email client open like that;

3. A messaging app taking up an entire monitor. Does that conversation pertain to the current task I’m focusing on? If not, then this app should not be there;

4. That is the browser window showing me the software I’m building. That’s the result of my focused work. It can benefit from a little more real estate, no? To add insult to the injury, maybe I’d even have the developer tools open, all squished, docked inside that same window!

5. The IDE. The thing where I produce the result of my current task. The code I’m working on cannot be seen without scrolling horizontally!

So, do the multiple screens make me more productive if used that way? Most certainly not.

Here’s a better setup I believe makes me more productive:

Let me walk you through it:

1. My Pomodoro Timer. Time-boxed task. The time I have left helps me stay focused;

2. A place to drop in notes, screenshots, links, etc., related to the task I’m working on;

3. Any research or supporting material I’m currently using. In that browser window, I make sure to only have tabs related to the task at hand;

4. My IDE. That’s the screen I’m looking at most of the time, so it has to feel comfortable, relaxing, easy on the eyes (not a lot of information or things other than the current code I’m working on);

5. The software that I’m building, which is the result of the code in #4;

6. The Developer Tools (console, debugger, etc.);

7. The terminal (console) window, so I can quickly see if my current changes have broken my local build (also supported by what I may see on #6).

As it has been document on the internets since 2007, I am very specific about how I organize windows and multiple screens. I organize them based on the focused task at hand and I’m always looking for A) better ways to organize it, B) processes and tools to make it easier.

If I’m working in Visual Studio, I may use the Windows Layout feature. Working either on a PC or Mac, I find ways to move windows around by only using the keyboard.

If I’m on the road, away from my normal setup, carrying only my laptop and my iPad, I turn my iPad into an extra screen (here and here).

I’ve just heard about the FancyZones in the Windows 10 Power Toys this morning, and I’ll be looking into adding that to my toolbox as well.

Leave a comment

VS Code tip: a handy snippet for console.log

Whatever the IDE I’m currently using, I always end up creating a couple of handy snippets, such as the one I’ve shared on how to create a TODO template in VS Code. Here’s another handy one…

Say I’m troubleshooting some JavaScript/TypeScript code such as the one below:

Many times, I want to write out the contents of something to the console. Say, the contents of “this.week” in the example above. I’d end up writing something like this:

Except that it bothers me having to write this same kind of thing over and over again. Snippets to the rescue! I created the following snippet for me:

Now, all I have to do is to select the thing I want to print out (“this.week”), copy it into the clipboard, and then invoke the snippet in the code editor with “clogc” (as in “console.log clipboard”):

Like it? Share it with your team and friends!

Leave a comment

Thoughts on the Pomodoro Technique

It looks like I’ve been using the Pomodoro Technique for way over 10 years now (that’s how far back I’ve found references to it on my blog)!

Most people learn the basics of the technique and run with it: set a timer for 25 minutes and do some focused work, take a 5-minute break, rinse, and repeat. As I’ve coached a lot of people on the technique over the years, I realize I’ve taken it beyond the basics. I remember back when I first learned about it, I did take the time to go through a short book the technique’s creator had up on his website. While I can’t find that version of the book anymore, there seems to be an updated version available.

Here are my general (and I guess some specific) thoughts about my use of the Pomodoro Technique!

You need to stick with it to see it work

Like with any technique, this one won’t produce any results if you try it once and never actually get to practice it, meaning, make sure to do it right, consistently. How can anybody do it wrong? Easy: set the timer for 25 minutes, start doing the work, and 10 minutes into it, go check out that social network notification that popped up somewhere, get your attention derailed for 10 minutes, go back to the remaining 5 minutes of your “pomodoro”, realize you won’t be able to finish your task and affirm that the technique does not work. That’ll do it. I’ve seen it happen.

Be mindful of what you do in your 5-minute break

When taking the short 5-minute break in between pomodoros, do your best NOT to engage in activities that’d get your mind busy with something completely different from what you’re currently working on. A big context switch would be a longer ramp-up time when we start your next Pomodoro, and that is a problem if you were working on a task that spans multiple sessions.

For example, checking emails in that 5-minute break can be detrimental to your productivity. You may get involved with an email that ends up taking 10 minutes of your time, stealing away all the context for the task you were working on. Instead of checking emails in that 5-minute break, set aside a full Pomodoro session dedicated to processing emails.

In a work-from-home setup, I tend to do things like playing my guitar for those few minutes, go outside and take a couple of deep breaths, practice juggling, etc; some simple activities that allow me to live in the moment, give the brain a little rest, and then get right back at it

Task-sizing in Pomodoros

Whenever possible, I like sizing my tasks in terms of the “number of Pomodoro’s”. For example, if I’m working on a given User Story, I may size it like so:

  • Pairing with QA to discuss test cases for the story = 1 Pomodoro
  • Writing unit tests (only the given-when-thens at this point) = 1 Pomodoro
  • Implementing the tests and the initial test pass = 3 Pomodoros
  • Cleaning up tests and code = 1 Pomodoro
  • Test/Code peer review = 1 Pomodoro
  • Creating Pull Request and updating tracking system = 1 Pomodoro

Total: 8 pomodoros (4 hours)

Such breakdown allows me to better organize my day so to make sure I get the uninterrupted time I need to do the work. If I need to pair up with somebody else on the team, it also allows me to be considerate of the other person’s time and have it on the agenda for the day.

Do I always work like that? No, but whenever possible, yes!

Wait, pairing during a Pomodoro?

Yes, I’ve mentioned above that I do pair during Pomodoros. How does that work? Well, both I and the person I’m pairing with are fully focused on the task at hand. Neither of us is checking emails or looking at our phones. This works great for:

  • Pair programming
  • Design sessions
  • Code review

What if those around you don’t do Pomodoro?

I see people walking out of restrooms without washing their hands; that doesn’t prevent me from washing mine!

I use the Pomodoro Technique because it works well for me. As it always happens, people see my Pomodoro Timer and ask me about it. I always take the time to explain and coach them if they’re interested. Those who aren’t interested at least start to respect my focused time and won’t interrupt me when they see I have my timer running.

Be mindful of abandoned Pomodoros

When you’re interrupted, you MUST abandon your Pomodoro. When you do, keep track of it. Write down why you had to abandon it. At the end of the day, reflect upon it and see if there’s anything that can be done/changed so that such interruption won’t happen again. Maybe you had an internal interruption caused by a Facebook notification you saw in a tab on your browser you’ve left open, so you now decide to close all tabs with content that’s not related to the task at hand. Or maybe you had an external interruption, caused by a co-worker that walked up to your desk and started talking about last night’s game, so you now decide to politely ask that person not to interrupt when you have your “do not disturb” sign up, whatever that sign is.

I talk more about managing interruptions in a previous post.

Working in Pomodoros all-day

People often ask me, “do you work in Pomodoros all day?”. That’d be great, but unlikely. I have different meetings at different times of the day on different days of the week.

I normally look at the schedule for the current day and find the blocks of time where I can work in Pomodoros. Any available half-hour is a Pomodoro where I can do productive work. If I can only do one Pomodoro in a given time window, I’ll use that for tasks that would comfortably fit in (a 1-Pomodoro task, as opposed to 3). Maybe processing emails, for example. If I have a larger window, say two hours, than I plan on 4 pomodoros, which is a nice time for focused, deep-thinking work.

If you do something like that, consider blocking those times in your calendar so people won’t reel you into unplanned meetings (just add something to your calendar such as “Pomodoro slot”, “Focused tasks”, or something like that). Over time, people will learn to respect that. Of course, let people know it’s ok to interrupt you during that time if there’s a real urgent matter that needs your attention.

Do you mute the ticking sound of the timer?

The ticking sound of timers drives some people nuts! If I’m deep in thought, that sound actually helps me stay in the zone. Some people also say the sound helps to stay focused (“the clock is ticking… I need to get this done!”).

I also like being able to see the timer. Let’s say I’ve planned to work on a task for 1 Pomodoro. I’m 20 minutes in and I think I’m done with my task. I look at the timer and see there are 5 minutes left. Instead of either “calling it a Pomodoro” or jumping to the next thing, I use that time to review what I’ve done. At times, it works like my “mini-retro” within a task. Maybe I can identify some quick code cleanup opportunities. Maybe I can identify things that could have been done better, but that can’t be done in 5 minutes, so I just take good notes about it, with enough context, so that should I have the time to come back and address it, I can quickly get my mind and thought process back and get it done.

Do you use an app for that?

Yes, I do. I have considered getting an actual Pomodoro kitchen timer, but I’m sure co-workers wouldn’t like having the tic-tac in the office. So I use either an app or a website such as this one.

Now if you excuse me, I need to start my next Pomodoro. 🙂

Leave a comment

About Commenting Code

I’m often asked about comments in code: when to do it, how to do it, what to put, etc. I’ve recently run into Steve’s post about when to comment your code, left a comment (!) there, and we got to expand our conversation in his podcast/screencast (link at the bottom). I’ve decided to create this post to consolidate the links and info shared during the interview, to make it easy for folks to find the material.

I remembered writing blog posts a couple of times over the years and it’s interesting to see how my opinion on this subject has changed over time.

The first post goes all the way back to 2005, with me asking “can you plesae put some comment on that Regular Expression?”. 15 years later, I still ask my smart friends to get me the RegEx I need, along some comments as to what each piece does!

In 2007, I was big into using Xml Comments, GhostDoct, and Documentor… I’m not anymore, as documented 10 years later with my post “XmlDoc Comments: Auto Generate and Hide the Clutter”. In nutshell, if we’re documenting a public API, yes, by all means let’s put in that documentation, but making it count: commenting the GetCustomers endpoint with “Gets the customers” doesn’t add any value to the effort!

My practice of making comments stick out as a sore thumb posted in 2010 still stands in 2020: I still set up all of my IDEs in that manner and it still produces exactly the outcome as I intended.

When I do want to drop a quick TODO comments in code (watch/listen to the podcast interview when it’s up to know why I might do that), I have templates on my IDEs to automate that: ReSharper in Visual Studio, User Snippet in VS Code, Live Template in RubyMine.

In regards to code that’s commented out, like so:

We should be using a source control system; if we ever want that code back, we have a way to bring it back. So just remove it!

Still using the example above, notice that each if-block is preceeded by a comment. Is it really necessary? How about removing the comment and extracting the expression into a method that tells us the question being asked?

There’s also the “narrator-style” comment:

Narrating every single line of code is very annoying (by the way, I think I wrote the code above many moons ago). If the comments were written initially as a placeholder for the steps that needed to be implemented, let’s make sure to get rid of it when we’re done.

Last but not least, some people say (I’ve said it myself) that comments should document “why” the code was written in such manner. I’d propose a variaton to that: how about documenting the why with some good specs (or tests, if that’s how you prefer)?

Now, I’m not refering to tests that look like this:

Such test doesn’t tell us the “why”; it tells us the “how”. I mean this kind of test (now you’ll see why spec fits better):

Summing it up, this is how I prefer to “comment” code:

If I do have a real need to drop an actual comment in code (“why do we have this query in the code that has to potential to perform badly”), I’ll probably drop a quick comment, with a link out to the issue tracker, where I’ll put more context about why the code was left like that, and where a Product Owner can decide when it’s appropriate to address the situation.

Any comments? 🙂

And for audio-only version:

Leave a comment

Creating a TODO template in RubyMine

Here’s a quick tip on how to create a TODO template in RubyMine:

Go to Preferences, Editor, Live Templates, and add your “todo” template under “user” (replace “CL” with your own

Now when you type “todo” and hit Tab in the editor, you get your expanded snippet:

Leave a comment

Creating a TODO template in VS Code

A few years ago I posted about creating a TODO template in ReSharper. Now here’s a tip to do the same in VS Code!

Go to Preferences -> User Snippets:

Pick the language (JavaScript, TypeScript, etc…), and then type the following bit in the JSON:

Replace “CL” with your own initials.

Done! Now when you type “todo” you should see this in your editor…

And after hitting Enter you should see the snippet, with the cursor already placed when you need it to be:

Leave a comment

Improving Code User Group: May 6th meeting announced!

It has been a long time since I’ve given a public talk on productivity tips and tools, so I thought “Why not?!”, since this is a topic that most definitely fits into the purpose of the Improving Code User Group.

While I’ll be sharing mostly C#, ReSharper, Visual Studio, and VS Code, the content of this talk should be applicable to developers working with any language or IDE. Title and description of this meeting can be found at the bottom of this post.

The online meeting happens on May 6th, starting at 6pm. If you’re planning on attending, please RSVP by following this link. Knowing the likely number of attendees will help me decide which online meeting platform to use.

Hope to see you there!!

Navigating and Refactoring Code, and other Productivity Tips

Any decent IDE must have features to allow developers to navigate and work with code. In this session, I’ll share how I use ReSharper, Visual Studio, and VS Code. More importantly, I’ll share the reason and the thought process. Remember: it’s NOT about the tools!

Leave a comment

Managing Interruptions

Interruptions kill productivity in any work environment and it’s no different if you’re working from home or not. In this post I share some of the techniques I’ve been using for several years to help manage interruptions:

  • The Pomodoro Technique
  • Educate your environment
  • Replay what happened prior to the interruption

The Pomodoro Technique

Check out The Pomodoro Technique website in case you’ve never heard of it. Besides working in focused 25-minute blocks, the main thing I got out of this technique has been tracking interruptions and classifying them as:

  • Internal: have I stopped working on my task because I saw a social network or email notification? Or maybe because I opened the web browser to check one thing related to my task and ended up reading the news instead? Such interruptions are considered internal because I didn’t have self-control and focus to stay on target. That’s easily addressed by shutting off all notifications, at least during that focused time.
  • External: have I stopped working on my task because somebody walked up to my desk and started talking to me? Or maybe because I got pulled into some unplanned meeting? These are external interruptions brought to me. They can be addressed by educating your environment. More on it further down…

I can’t stress enough the importance of taking note of the interruptions, classifying them as internal or external, and finding ways to prevent them from happening again.

Educate the Environment

Let your environment (physical or virtual) know whether it’s ok to interrupt you or not.

  • Let people know that you’re in “do not disturb” mode: put up a flag, a post-it note, your headphones… whatever your token is, just let people know. Don’t forget to put it away when you are available (use the status feature if you’re working from home);
  • Let them know why, if necessary: Depending on the situation, when others know why you’re not available, they are likely to help to keep others from interrupting you;
  • Let them know what they should do if they need you: if they have an urgent situation, let them know to interrupt you by all means. If it’s not urgent, let them know to drop a note such as “I need 5 minutes of your time before 3pm today…”. They can leave a post-it note on your desk or a message in whatever communication channel has been clearly defined. Make sure to get back with them (this is essential for the system to work!).

This is what I have right outside my home-office…

Replay what happened prior to the interruption

A big problem with interruptions is that it takes us an average of 25 minutes to return to the original task. If my task is done on the computer, I’ve found ways to decrease the time it takes me to get back “in the zone”:

Take screenshots: I’ve been using TimeSnapper for a long time. I blogged about this 13 years ago! In nutshell, the tool takes screenshots every 5 seconds. If I get interrupted, I can use the tool to replay the screenshots and jumpstart my mind to put me back in the zone.

Git commits: I’ve also used my commits in Git to get back up to speed after an interruption. If I was heads-down working on a user story, implementing my tests, making them pass one by one, and committing after each step, I can then look at the commits to see the work I had done prior to the last interruption, which helps me get back in the right frame of mind.

Summing Up

If you take anything of this post, this should be it:

  1. Realize you’ve been interrupted;
  2. Determine whether it was an internal or external interruption;
  3. Isolate the source of the interruption;
  4. Put some system in place to prevent the same kind of interruption to happen again;
  5. Some interruptions can’t be prevented, so put a system in place to recover from it quickly.

Leave a comment

Slow Down, Mister!

Back in 2015, I used to have a morning routine that included working out at the gym. Since I get bored working out, I’d often be either listening to audiobooks and podcasts or watching TED talk videos on my iPad. Whenever there was something I wanted to either review or remember later, I’d take a quick note, such as this one: “Slow the #$@! down!

I wrote that note when watching Carl Honore’s “In Praise of Slowness” TED talk. I’ve been since saying that sentence in my mind, deliberately, at times when I realize I’m rushing through things.

Did Michael Jordan really say that?

I’ve either read or heard someplace that somebody asked Michael Jordan how he was able to read a game so well and react so fast to it, and his answer was something along the lines of having an ability to see everything going on around him as if it were in slow motion.

I haven’t been able to fact-check that, but I don’t care, since the idea makes a lot of sense to me: if anything is fast-paced, the best way to succeed at it is to see it in slow motion. But how do we do that without acquiring the powers that only fictional characters such The Flash possess?

How does he make his guitar sound like that?!

I still remember my thoughts when I first listened to Yngwie J. Malmsteen (Swedish Guitarist) when I was a teenager. At the time, I was happy I could play some of my favorite guitar solos found in the music of bands such as Iron Maiden and Metallica. I could learn their songs simply by listening to it.

Then, I start listening to an album by Yngwie and my face is melt; I simply could not understand how he could make his guitar sound like that. I mean, I couldn’t visualize how he was playing that. Certain passages sounded so fast, yet so smooth. I’d pick up my guitar and not have a clue where to start trying to learn one of his licks or solos. I had to see it to believe it. After seeing it, my brain could start processing what was happening.

At one point I got a copy of a VHS tape with his video lessons (holy grail!), and when he slowed down playing some of his licks, only then I believed I could actually learn how to play that (and I did, as we can see in some of my own music).

Practicing playing a guitar has to start slow, regardless of your level.

Motorcycle riding

Riding motorcycle at a race track can be daunting. Things come to you very fast when you’re going 150mph on a straight, or 100mph around a corner! When I started riding at the track in 2017, I did what most beginners do: looked down on the track, instead of further ahead. By the time I got to a corner, my brain didn’t have enough time to process the information and make quick decisions on all the things that I need to do in order to go through a corner properly.

Go slow to go fast”, they say. And that’s true. I needed to slow down to be able to learn fundamentals of track riding. Give time to the mind and body to internalize the actions. As time goes by, muscle memory is built, besides developing better visual skills; instead of looking where I’m going, I learn to look where I want to go next. The better I do that, the more time I give the brain to process everything, so it’s almost like things are coming at me in slow-motion.

Putting the mind and body through the process of slowing things down before trying to go fast makes me a better rider, so I do it as much as I can, which includes riding mini-bikes:

Fast-Thinkers and Improv

I’ve been blogging about my recent experiences in improv. At first, I thought improv would teach me how to think fast. As I focus on thinking fast, I end up stumbling into my own thoughts. That’s similar to blowing up corners at the race track because of not “seeing ahead”, or blowing up several notes in a guitar solo simply because I’m focusing on playing fast.

But then, I found this short video a few days ago, which changed my perspective on it:

“Backing up” in a scene seems equivalent to seeing things in slow-motion.

What did that driver just do?

I guess this has happened to you several times: you’re driving, minding your own business, when all of sudden, another driver pulls up right in front of you (driving out of a parking lot or something like that), startling you really bad.

That does happen to me at times, usually, when my mind has drifted away, as I’m thinking about a million things, except for the one impostant task at hand, which is to safely drive my car. In such situation, it is easy for other drivers to catch me off-guard.

That type of situation can be avoided by using “slow-motion” again. In this case, that means to be in the moment, aware of my surroundings. When fully-aware, predicting what other drivers are about to do becomes easier. We predict when a driver is ready to jump the gun and make a last-minute right-turn, or when a driver will cut you and others off, jumping lanes without using the blinkers, or when a driver will speed up to prevent you from merging into his or her lane. “Slow-motion” here doesn’t mean slowing down the speed of the car; instead, it means our mind can better assess the situation because we’re giving it space to process the information.

I’d like to point out that I believe I’m usually way more aware in traffic than other drivers because I also ride motorcycles (the lack of a “cage” makes one aware in the middle of crazy traffic and drivers).

Software Development: Productivity Tools

I’ve been using productivity tools such as ReSharper and Code Rush for a long time. At first, it was just cool to see how quickly I was able to navigate code, write it, change it. I now see it differently.

To the outside (other people), it looks like I can do those things really fast. Internally, though, doing those things fast allows me to think slowly. Because of the muscle memory built after practicing all those shortcuts, I spent less time figuring what and how I’ll do something, and spend more time thinking why I’m doing it.

In the same vein of giving the brain some room to think, I often take the time to do things the slow way; for example, I may go the command line and type a command character by character, instead of recalling and changing a previous command, or using an alias of some sort. I fall back to this approach when I feel I’m either rushing or unsure as to whether I’m going in the right direction (“If we are facing in the right direction, all we have to do is keep on walking.”).

Summing it up…

Slow Down!!

Leave a comment

Using Evernote Tabs and Tags

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…

  • Today
  • 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:

  1. Open a new tab (Command+T)
  2. 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.).

Leave a comment