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.

.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!

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:

• Writing code is cheap. Understanding it, not so much.
• Toggling Visual Studio CodeLens On/Off
• SpecFlow: My preference for the step definition style
• The “private” keyword in C#: I get rid of it!
• Fun with C#: Cleaning up dense code with Dictionary and ForEach
• Fun with C#: Object and Collection initializers

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()) {}.