Archive for July, 2017

My Morning Ritual

I’ve introduced morning rituals in my life a long time ago. These rituals change over time, based on whatever’s going on in my life, as well as what constraints I have, what resources, etc.

Currently, here’s what my morning ritual looks like (starting after hitting the snooze button a few times – a bad habbit I need to break! – and going to the bathroom):

  1. Stretch: I stretch my body, mostly using a foam roller like this one, to roll my legs and back and get things back into place;
  2. Water: After so many hours without drinking or eating anything, I like drinking about a glass of water so that my body can flush its system; 🙂
  3. Protein shake: I don’t feel like having a large breakfast in the morning, so I at least try to get some protein, which will help me not feel hungry way before lunch time;
  4. Meditate: I’ve blogged about how meditation is paying off. I’ve been meditating for 15 minutes for several months. I’m thinking about going up to 20 minutes soon. 
  5. Journaling: For many years I’ve been writing down things I’m grateful for. For the last several months I’ve been using the 5-Minute Journal, which just adds a little more structure to it;
  6. Watch to short inspirational video or listen to song that gets me going:  I may either watch a video off the QuickTalk YouTube playlist Short, or listen to a song off my Morning Songs playlist;
  7. Organize my day: I first review things that I know are going on that day and then set up my Daily Execution note, which drives my day;
    8. Quick email scan: this happens real quick! I barely skim over email subjects, specifically looking for anything that could somehow mess up with my plans for the day (set in #7). For instance, maybe a meeting got cancelled last minute, or something urgent has come up and I must include in my agenda for the day. 
  8. Go to work!

Seriously, I do NOT read emails in the morning. I ONLY go through subjects and see if there’s anything that could change my agenda for the day. I’ll only spend more time checking email once my main activies have been put in motion at work.

Also, I do NOT check any social network in the morning.

Important: I set my cellphone to “flight mode” when I go to bed, and I only set it back when doing step #8 above; that way, I don’t hear and dings for new messages in the middle of the night, and I don’t take the risk of seeing updates on my cell phone when I pick it up to run my meditation app, so I don’t get any interruption.

I’d like to add workout to my morning ritual, but I haven’t found a way to make that work with my current constraints. Anyway, as it is now, my morning ritual is helping me get ready for the day and get a sense of being productive since early in the morning.

Leave a comment

Why the Dark Background?

Once in a while I hear comments like “so, you’re one of those who like everything dark…”, as people look at how some environments are set on my computers. Those comments make me think about my reasoning behind that choice.

Of course, some people choose to go dark just to go with the flow (“That’s what the cool kids are doing…”). That’s not my case.

I’m getting old. This is what my screen used to look like when I started working with computers some 25 years ago:

The software I wrote used to look like this:

At some point, things started to light up and MS Windows brought white background to everything. As I worked with MS Visual FoxPro, and then Visual Studio, as far as I remember, white background was all we could use, so I got used to it, but I always felt it a little “too much” on the eyes.

Once Visual Studio allowed me to switch to a dark color scheme, I embraced it, and that’s how I’ve had it set for a long time:

I do the same thing with Gmail and any other tool that allows me to:

What about the other tools that don’t let me go dark? I don’t care, I just use them regardless. The important thing is that the tool where I spent most of my time is set to my liking.

And why do I prefer it dark? I do because it looks calmer as I read through the text.

Leave a comment

The Death of MS Paint and Producing Good Results

.I heard the other day that MS Paint is getting killed off, so I felt I needed to pay my tribute to it.

Before becoming MS Paint, that tool used to call Paintbrush.

Back in high school, my class was using Windows 3.1, and we were given a special homework assignment: drawing something (anything) in Paintbrush. I decided to try drawing this cover artwork of a Batman comic book (which was probably the current issue at the time). This is the original cover:

I spent about 4 hours on a Sunday afternoon and was satisfied with the result. When I showed it to the class, a lot of people thought I had cheated and scanned the cover. The professor trusted me from previous works I had turned in, but still, he told the class he’d know if I had cheated when he analyzed the digital BMP file. He was very impressed by this work, even more so considering I had used just a regular mouse to draw the thing.

Unfortunately, I’ve long lost the original file. Many years ago I found an old copy produced by an old dot-matrix printer, which I then scanned (ironic, I know!) and kept around. That’s what you see below:

Not bad, is it? I really hoped I had the original file, which definitely looked better than the scanned dot-matrix printed version.

Moral of the story: most of the time, we do NOT need fancy tools to achieve great results!

Leave a comment

What and How Much Do I See on the Screen?

It seems like there’s a recurring topic going on here: I’m very picky about how much stuff (and what stuff exactly) I see in my work area! (See list of posts related to that down below).

Several years ago I was trying out different DAW software (Digital Audio Workstation) to record my music. I’ve tried at least half a dozen of them. I’m NOT a recording engineer; all I wanted was something where I could press a big red button so I could start play my instruments and have it recorded.

Most DAWs I found failed that simple requirement as I was presented with extremelly convoluted user interfaces in which I simply could not figure out how I could plug my guitar and start recording it. I’m both a software developer and a musician, and still, I couldn’t figure out how to do this one simple thing!!

Such user interfaces made me feel stupid and I want to deal with them. I eventually found this one DAW that satisfied my needs as a hobbyist musician.

Simplicity is key for productivity, and that applies to setting up the development tools we work with, as well as the code we write. Polluted tools get in the way of reading code. Convoluted code gets in the way of understanding what it does.

Clean up your development environtment! Clean up your code! Clean it up!! 🙂

Some of my posts related to my take on optimizing what I see on my screen as a developer:

Leave a comment

Writing code is cheap. Understanding it, not so much.

Writing code is really cheap! There are three ways to do it, and you can use them all:

  1. Use a code generator (CodeSmith, T4, or your own);
  2. Use a micro code generator (templates in VS, Resharper, CodeRush,…);
  3. Take a touch typing course and get good at it!

Then comes the time we need to change the code. That’s the hard part, right? Well, not necessarily; there are tools that can help with that, too. If the change you need to make is to refactor the code, there are tools that do a wonderful job at that. The problem is understanding the code well enough so we can change it!

We spend little time writing code. We spend a LOT of time reading it. Doing things that can help us understand the code later on down the road is a must. Writing good tests is one of those things. Writing clean code is another.

The quicker you understand the code you’re facing, the more confident you’ll be making the right changes to it.

Code must be written with care. So must be tests. Tests provide a big help in understanding why certain code exists. Tests must be written in a way that they’re easy to understand.

When writing test setups (like setting up mocks and stubs, for examples), consider putting that logic behind a method that explains the intent behind that setup. This will help the reader quickly understand what’s going on, and it’s easy enough to jump into the details when appropriate.

The same goes for production code: consider putting expressions used in an if-block behind a method that describes the question being asked. In other words, instead of writing if (user.Age >= 13 || user.Age <= 19) {}, consider writing if (user.IsTeenager()) {}.

Leave a comment

What is the Difference Between TDD and BDD?

This is a question asked many times: What is the difference between Test-Driven Development (TDD) and Behavior-Driven Development (BDD).

In my mind, I’ve accepted the following explanation:

Doing TDD, I write the code I want to have;
Doing BDD: I describe the behavior I need to have

I use both approches together: I start writing my tests in terms of GWT (Given-When-Then), describing
the behavior I need to have, and as I implement those individual steps I write the code I want to have.

This is the simplified explanation that works in my own mind, and it has taken many years for it to take that shape. It may not work to others, but I’m sticking with it for the time being, at least until I find a better way to explain it.

I sense there’ll be more posts coming up expending on this subject. 🙂

Leave a comment

No GWT? No code!

As I mentioned in my post on Test Style: AAA or GWT, I’ve deliberately started thinking of everything in terms of GWT (Given-When-Then). So, when I’m beginning to write a new test, instead of writing this:

// Arrange
// Act
// Assert

I write this:

// Given
// When
// Then

Regardless of the style, though, if I can’t think of what should go in each one of those sections, I may have one of two problems:

  • I don’t have enough requirements, or
  • I don’t understand the requirements I have

I’ve gotten into the habit of thinking this way: No GWT, no code!

The reason for that is: if I either don’t have enough requirements or don’t understand the ones I have to a point where I can’t fill out my GWT sections, then I should NOT be writing any code. Whatever code I write is very likely to be thrown away, and unless I have a lot time in my hands to be simply toying with writing code, I should refuse to write any code and go find help to have a clear idea about what I’m supposed to implement.

Leave a comment