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:

https://www.weeklydevtips.com/episodes/code-comments-with-guest-claudio-lassala

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
initials!):

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