Choosing a Computer Monitor

Computer monitors are difficult to choose because you need to pay attention to so many different features, and a few mis-features.

I played no part in my wife’s recent choice of a new monitor, and we both regret it. I stayed out because she didn’t ask for advice (I tend to give too much), and she didn’t ask because she didn’t know about the Rules of Monitor Selection.

Yes. There are Rules.

They are not, as I had assumed, common knowledge.

Allow me to let you in on the secret. Firstly, do not buy any monitor...

• With an external power supply. They are hard to replace when they wear out, and they add clutter.
• With a power input other than a standard PC power cord. Anything else is hard to replace.
• With display or power inputs perpendicular to the screen; they should enter straight up from below. When they stick out of the back, they add depth that won’t be accounted for in the published dimensions, and they add a twisting stress to the circuits inside from gravity pulling on the cords.
• Missing any input type you need right now, for obvious reasons.
• Without an HDMI input (DisplayPort if you prefer Macs). Your next computer will probably have this kind of output.
• Without a height adjustment. Your desk may not be the perfect height, but at least your monitor can be.
• With a resolution below 1920x1080 (aka full HD or 1080p) in either dimension. This is the current minimum standard. Remember when it was 800x600? It sucked, right? Same thing here. Don’t buy below the beast.

Completely avoid anything that matches those. Don't even look at them. They will try to seduce you with pretty pictures, but they're not worth the heartache the next morning.

Now to help you choose the best from what remains. A monitor is better if, in generally descending order, it...

• Has a DisplayPort input. This is the next most popular after HDMI. If your next computer doesn’t have HDMI, it will probably have DisplayPort.
• Has a pitch adjustment (tilt up/down). You can use the height and pitch adjustments to get rid of a reflection and keep the screen in a comfortable position.
• Has a swivel base (twist left/right), so when you turn the screen to let someone else see, you don't knock over your coffee.
• Includes a built in USB hub (bonus points for USB 3).
• Can rotate between portrait and landscape modes. This is most useful for coding or writing long documents.
• Is color calibrated, for graphical design.
• Does not have built-in speakers. They will be awful. This is a monitor, not a TV.

What about 4k monitors? Make sure your computer can support the higher resolution if you’re thinking about getting one of these. It needs either a DisplayPort output, or HDMI 2.0 or newer.

So what do I recommend? I have an ASUS PA249Q 24.1” 1920x1200 monitor. It has HDMI, DisplayPort, DVI, and D-SUB (aka VGA) inputs, no speakers, a standard PC power cord, all the various adjustments, a 4-port USB 3.0 hub, and multiple different color calibrations. It is easily the best monitor I have ever had, and I strongly recommend it. It can even do side-by-side and picture-in-picture.

Oh, and you should probably avoid Samsung. They tend to feel really cheap.

Note: As an Amazon associate, I may earn a commission from purchases made through links followed from this page.

Prototypes

If you’ve ever visited a Google office and used the bathroom (great way to begin, right?), you probably saw an episode of Testing on the Toilet (or possibly Learning on the Loo) posted at eye-level. This week I saw a post about prototypes. It said there is a simple rule to determine whether your project is a prototype: Whether it will live a short about of time, and then be deleted.

But that’s not an easy way to identify a prototype. “Why not?” you ask (well, probably not, but it fits my writing style). “It sounds simple!”

No, it’s not simple, because it requires you to see into the future. You need to know that your project will only live a couple weeks, and then go away. But how could you know that?

While working on a personal project (I am implementing the Raft consensus algorithm in Go), I discovered a much simpler test for whether a project is a prototype: If you cannot use test driven development, it is a prototype. Think about it for a moment. I’ll leave a break between the paragraphs.

Really, think about it...

When can you write the tests before the actual code? When you understand the solution, which means you have a plan.

When you’re ready to write an implementation.

When can’t you write the tests first? When you are exploring the problem, trying to understand what the solution might look like.

And guess what? If you try to write tests after writing an exploratory solution, the tests are going to suck. You’ve probably done it before. They cover the easy, obvious cases, but you still worry a little about some corner cases that were just too hard to reach. Maybe you were considerate enough to put todo comments on them, but a todo is not the same as a test.

My experience implementing Raft convinced me that I am writing a prototype. I will do it again when I finish, and I may do it again after that. This is how I learn; I write something that kinda works, and then I know enough to write it better. Eventually better is enough to be production code.