To each his own, I guess. In my case, I find advantages to both so much that I routinely switch between them. My main workstation is connected to a 55" Vizio H

To each his own, I guess. In my case, I find advantages to both so much that I routinely switch between them. My main workstation is connected to a 55" Vizio HDTV (a model that supports Chroma 4:4:4 and represents text of various colors very well) that I picked up last year during a post-Thanksgiving sale. While I love it, I do the lionshare of my development using a 1080p display connected to a laptop. Is the 4K screen superior? Absolutely -- in almost every way -- except for portability. I made the switch from multiple 1080p monitors to a single laptop monitor a few years ago and ditched the multiple monitors for the single 4K (which had a total resolution about equal to my multi-monitor arrangement). The transition was tricky at first, though, and coupled with a visual studio extension that aided in navigation/visual identification of important code points (something I wrote for myself), I found downgrading to the 1080p single display to take far less time to get used to than I expected. The one drawback turned out to be a positive thing in the long run: by not being able to see so much code on-screen at all times, it forced me to write code more carefully. Where I could have gotten away with not splitting a class up into smaller pieces, before, because I could see the whole thing on-screen, I couldn't do that any longer and continue to be productive writing code. Sticking with small methods that "do one thing" and small classes that have a single purpose is a best practice and it's one I was pretty religious about before, however, there are times when it's necessary to "get the code out the door" and corners get cut, mostly out of a false-sense that writing it dirty will be faster[0]. There's one place where the 4K screen is vastly superior, though -- debugging. You can get your code, the locals/watch and the application visible in one screen. This, too, turned out to be a double-edged sword. It was easy to skip seemingly unimportant unit tests when I knew my debugging environment was pristine. But the reality (for me at least) is that the moment I have to hop into the debugger and check locals/watch to see what's going on, I can expect to waste an hour fixing a problem 80% of the time. Here's the thing, though, writing tests to cover my code rarely takes more than an hour or two but the simple act of doing so causes me to rethink the problem from a testing standpoint. I'll often find the bug before I've ever run the test to validate that it passes -- and about 1/3 of the time, that bug was subtle. Less often, but still frequent, I'll discover during the act of writing the test that the code could be refactored in a more logical manner, which results in better code. These facts mean I write tests regardless of having a great debugging environment, and I'm obsessive about it -- covering code that seems obvious[1] -- so I end up rarely needing the benefits that a 4K screen offers. Being handicapped by the smaller screen on my laptop does come with advantages beyond just those introduced by the constrained environment. I'm not tethered to a room or location to code. Sometimes walking away or changing my physical environment ends up allowing me to avoid an actual "break" -- just moving from the office to the kitchen (when I worked at home) or from my desk to the office-kitchen couch (now that I'm an office dweller) causes enough of a shift to get me thinking correctly again. All of that aside, one area where the 4K screen shines is anything to do with multimedia, 3D and image editing. Being able to do detail work, zoomed in on a screen that accurately reproduces color -- and at a cost that's a fraction of 4K monitors -- is simply fantastic. I also find the brightness of the 4K TV I purchased to be excellent -- the IPS monitors that I own tend to default to a brightness setting that is almost excessive (yes, adjustable, I know). I purchased a TV that was evenly backlit and once I got everything configured properly, I don't mess with it. The size and amount of light it outputs is pleasant; it's large enough that I can use it with the lights turned off in my office (if I have a headache) and it keeps the room reasonably lit while not blasting so much light out of the display as to be obnoxious. Despite not being IPS, being large and me sitting a couple of feet from it, I didn't notice any issues with edges looking dimmer due to the angle -- though I mostly ignore the edges because I rarely have anything maximized on that screen. It's just not necessary when you have all of that realestate -- you tend to simply move less important things off to an edge and put what you're working on in the middle in a smallish window. [0] And it sometimes is in the short-run, but if that code has any importance to the program, you pay for it. [1] I'm not "Test Driven" -- I write tests "second" because I started writing code quite a bit before "Unit Testing" was a common practice and I find the act of doing "Tests First" to feel backward. Writing tests afterward seems to have the same benefits as doing it the other way around, though it sometimes drives code changes. I've been doing it this way for too long to switch and be as productive as I am. But I cover everything -- I once wrote tests to cover a configuration lookup class that was basically a bunch of retrievals from a dictionary. A coworker chided me for it until I informed him that I found four bugs (and the best part is that said coworker was the one who wrote the buggy code). Because of the way the configuration routine worked -- cascading from a set of values in the database with fallbacks to values in a file and then finally constant values, all of which would always be set correctly from top to bottom in our development environment, the issues I unearthed would have easily gone unnoticed until a customer discovered them.