I've worked on a range of setups from dual screens, 120hz to little CRTs and laptop displays, and even a bit of graphing calculator and smartphone coding. My conclusion is that the difference depends mostly on the workflow, and what the workflow changes is mostly how much information you're scanning.
If you're scanning tons of text, all the time, across multiple windows, you need a lot of real estate, and in times of yore you would turn to printouts and spread them over your desk. A lot of modern dev goes in this direction because you're constantly looking up docs and the syntax is shaped towards "vertical with occasional wide lines and nesting" - an inefficient use of the screen area. Or you have multiple terminals running and want to see a lot of output from each. Or you have a mix of a graphical app, text views and docs. A second monitor absolutely does boost productivity for all these scenarios since it gives you more spatial spread and reduces access to a small headturn or a glance.
If you're writing dense code, with few external dependencies, you can have a single screen up and see pretty much everything you need to see. Embedded dev, short scripts and algorithms are more along these lines. Coding with only TTS(e.g. total blindness) reduces the amount you can scan to the rate of speech, and I believe that consideration should be favored in the interest of an inclusive coding environment. But I'm digressing a bit.
For a more objective ranking of concerns: pixel density ranks lower than refresh rates, brightness and color reproduction in my book. If the screen is lowish res with a decent pixel font that presents cleanly at a scale comfortable to the eye, and there's no "jank" in the interaction, it's lower stress overall than having smooth characters rendered in a choppy way with TN panel inverted colors, CRT flicker, or inappropriate scaling.
Book quality typography is mostly interesting for generating a complete aesthetic, while when doing computing tasks you are mostly concerned about the symbolic clarity, which for English text is reasonably achieved at the 9x14 monospace of CP437, and comfortably so if you double that. There's a reason why developers have voted en-masse to avoid proportional fonts, and it's not because we are nostalgic for typewriters.
And yet for some reason we have ended up with tools that blithely ignore the use-case and apply a generic text rendering method that supports all kinds of styling, which of course makes it slow.
> There's a reason why developers have voted en-masse to avoid proportional fonts, and it's not because we are nostalgic for typewriters.
This is sad in itself. Proportional fonts are vastly superior to type writer fonts in presenting code. The kerning even makes for better readability even if it comes at the expense of the ability to do ASCII art.
If you're scanning tons of text, all the time, across multiple windows, you need a lot of real estate, and in times of yore you would turn to printouts and spread them over your desk. A lot of modern dev goes in this direction because you're constantly looking up docs and the syntax is shaped towards "vertical with occasional wide lines and nesting" - an inefficient use of the screen area. Or you have multiple terminals running and want to see a lot of output from each. Or you have a mix of a graphical app, text views and docs. A second monitor absolutely does boost productivity for all these scenarios since it gives you more spatial spread and reduces access to a small headturn or a glance.
If you're writing dense code, with few external dependencies, you can have a single screen up and see pretty much everything you need to see. Embedded dev, short scripts and algorithms are more along these lines. Coding with only TTS(e.g. total blindness) reduces the amount you can scan to the rate of speech, and I believe that consideration should be favored in the interest of an inclusive coding environment. But I'm digressing a bit.
For a more objective ranking of concerns: pixel density ranks lower than refresh rates, brightness and color reproduction in my book. If the screen is lowish res with a decent pixel font that presents cleanly at a scale comfortable to the eye, and there's no "jank" in the interaction, it's lower stress overall than having smooth characters rendered in a choppy way with TN panel inverted colors, CRT flicker, or inappropriate scaling.
Book quality typography is mostly interesting for generating a complete aesthetic, while when doing computing tasks you are mostly concerned about the symbolic clarity, which for English text is reasonably achieved at the 9x14 monospace of CP437, and comfortably so if you double that. There's a reason why developers have voted en-masse to avoid proportional fonts, and it's not because we are nostalgic for typewriters.
And yet for some reason we have ended up with tools that blithely ignore the use-case and apply a generic text rendering method that supports all kinds of styling, which of course makes it slow.