
Ask HN: How many monitors do you use while coding? - forrestbrazeal
Personally, I use two - a big one for my code editor and web browser, and my laptop screen for terminal windows, chat and other stuff. I know a lot of people use three, and some even more, but I find that it&#x27;s more distracting to work with three monitors than to switch between programs on the same screen. But that&#x27;s just me. What&#x27;s your optimal monitor setup, and why?
======
knolan
I tried using two 27" iMacs with the older one in target display mode and
found it a bit silly when you have virtual desktops (or spaces). Similar
experience back when I used Redhat as a postdoc, one was enough for me with a
laptop as a second machine for secondary tasks. This seems a common setup for
people in my field.

However my coding is admittedly pretty simple, mostly scientific tools for
data acquisition, processing and visualisation. I'm currently switching from
Matlab to Python/scipy and on my iMac and MBP I'm happy with a couple of
terminal windows and on the experimental rig taking the data, which runs Win7,
I have pycharm docked to half the screen which itself is mounted above an
optics bench so I have a nice standing setup.

So on total I code across four screens but each on different machines!

------
mnm1
1 40" 4k. I have the option of using my laptop screen and/or another 1440p
alongside it. I tried both and find the extra screens a distraction.

------
GrumpyNl
I have three screens but the two on the outside are doubles (extra width ) so
i use 5.

------
mdip
I use one. And most of the time it's the one on my laptop, which is 1080p. I
made the choice three years ago to do this _on purpose_.

The main reason I started handicapping myself with the single monitor was so
that I could write software without the need of my desk/office. I found that
when I was working at my desk, I'd need a break at set intervals to get
'unstuck'. While decompressing, I'd often start thinking about whatever
problem I was solving and I'd run back down to work on it, all the while
wishing I _wasn 't_ in my office.

So I started thinking about all of the reasons why I _didn 't_ use my laptop
screen. The main ones were (1) I couldn't _see_ as much code on my screen at
the same time which made both 'holding the amount of code needed to understand
the problem' and 'navigating code to the correct block I was studying' more
difficult and (2) when debugging, it was convenient to have the debugger
display on one screen and the application on the other. The first was a mostly
solvable problem and I ended up solving it by writing a Visual Studio
extension that highlighted common code points that I was often looking for
(constructors and factory methods). The second was becoming less and less of a
concern because I had begun taking unit testing _very_ seriously and this
resulted in a desire to 'write a test for it' over 'debug the code to see what
went wrong'.

Now that I've been doing that for three years, I will _never_ go back. When I
was working at home (which I did for a decade), I would just move rooms when I
felt 'stuck', allowing me to get a change of scenery, a brief break, and get
right back on working without feeling like I need to be 'out of my office'. I
can even pack up the laptop and head to a cafe if I feel the need, without
feeling like I'm handicapped by the single screen. But the more surprising
thing for me was that my coding practices improved. When I feel like I'm
having a hard time 'keeping all of that code in short-term memory', I
immediately see the lack of multiple monitors as a symptom of the problem with
the root cause being 'my code is probably not written ideally'. I refactor for
that. But most of the time I end up writing it correctly the first time
because I can't put it all up on various monitors to refer to while writing an
unnecessarily complex implementation.

This directly feeds into the second problem: I find that I very _rarely_ use
the capabilities of the debugger. My code is easy to unit test, so I write
tests every time for very nearly everything. When I encounter a failure, the
design of the application lends itself to identifying the troublesome point
and I can write a test to verify the problem (and later, verify the fix).

