4 ms·

I find I am much more productive at home (1x 30" monitor + laptop display) then I am at work (1x 24" 1080 monitor + laptop display). The screen size absolutely

I find I am much more productive at home (1x 30" monitor + laptop display) then I am at work (1x 24" 1080 monitor + laptop display). The screen size absolutely makes a difference when you are working on a large project with lots of disparate pieces. When you jump between project-wide search, debugging, showing git diffs, and so on. This is especially true if you do graphics work and code. When you need to move graphics assets around your filesystem and into your IDE it's nice to have the room (i.e., not so many overlapping windows) so you don't spend time digging for assets, resizing assets, running scripts over assets. I consider myself very productive on just my laptop screen, but sometimes I postpone large architectural changes or heavy instruments based debugging sessions until I get home. There's less back-and-forth and a considerable speedup under certain workloads.

johndriscoll 13y ago
I do all these things in a terminal. I used not to. But once I started doing things the CLI-way, I never looked back and have yet to discover a tool offering even half the productivity gained from keeping my fingers firmly planted on the home row. However, if you are locked into using an environment where doing the things you've said requires mousing or multiple windows with tons of resolution, then you have my sympathies.
- interpol_p 13y ago
  While I do a lot on the terminal, not everything is faster there. Jumping between symbols in your IDE is not going to happen faster on the command line because it's a spatial operation. You've located the symbol visually, clicking it to jump to definition is far faster than keyboard-navigating to it, or even typing it. Merging is better with a dedicated merge tool than a command line merge. I have to resolve conflicts one to three times per day and I couldn't imagine a non-visual merge interface for complex files where manual edits from both sides are necessary. Being able to see it all at once helps. There is nothing quite as good as Xcode's instruments on the command line — providing easy to navigate visual representations of your performance and memory use, graphs and other metrics. Having the instruments panel on a second screen is incredibly useful, the extra screen real estate is of real value here. Having to keep switching on a single laptop display is a pain in the ass. Obviously there are many tasks that cannot be easily sped up on the terminal, saving slices out from Photoshop (when your designer hasn't done it properly). And then getting the resulting assets into your pipeline. This stuff is benefited by extra screen space. But the main benefit is being able to see more code at once. And it is especially helpful in large re-factoring operations or with extensive debugging / performance profiling. As I said, it depends on the type of work. I can code just fine on my laptop but I tend to prefer coding focused features, or fixing isolated bugs. I find the previously mentioned profiling and architectural changes are better suited to large screens where more code / graphs / visual assets can be seen at once. You simply can't do "all these things" in a terminal. You can do a hell of a lot, but sometimes you need visuals and sometimes you need space. When you can see more code you don't have to hold as much in your working memory, your eyes can flick back and forth over your code and it makes it easier to see the dependencies and realise what you need to change.
  - dllthomas 13y ago
    "Jumping between symbols in your IDE is not going to happen faster on the command line because it's a spatial operation. You've located the symbol visually, clicking it to jump to definition is far faster than keyboard-navigating to it, or even typing it." When the lab I worked in moved between buildings, we each broke down our work stations and set them up in the new spot. I went through a good week of getting work done before I noticed that I hadn't plugged in my mouse - I just never reached for it, because virtually everything happens with a thought when my hands are on the keyboard.
    - interpol_p 13y ago
      Most of the time when I'm coding I use the keyboard to jump to symbols. But when you are getting acquainted with a large codebase, reading through and clicking to jump to symbol can be a more efficient way to parse the code and understand its interdependencies. It may depend on what you use to position the cursor as well — I haven't used anything but a trackpad in the last five years, and even on that mostly I use gestures to navigate UI. Since the trackpad is almost part of the keyboard it feels very seamless to scroll/tap and type.
      - dllthomas 13y ago
        Yeah, I'm much more likely to bump a trackpad than reach for a mouse, even when the mouse gives me much more control (I always find trackpads a little finicky), just because of the distance. My hands don't need to actually go anywhere. Of course, I also bump the trackpad accidentally sometimes, but that's a separate issue...
  - dllthomas 13y ago
    "Merging is better with a dedicated merge tool than a command line merge. I have to resolve conflicts one to three times per day and I couldn't imagine a non-visual merge interface for complex files where manual edits from both sides are necessary. Being able to see it all at once helps." Being able to see it all at once absolutely helps, but on a big enough console you can see it all just fine. Vimdiff is great. A large monitor definitely adds value there, GUI or TUI.

johndriscoll 13y ago

I do all these things in a terminal. I used not to. But once I started doing things the CLI-way, I never looked back and have yet to discover a tool offering even half the productivity gained from keeping my fingers firmly planted on the home row. However, if you are locked into using an environment where doing the things you've said requires mousing or multiple windows with tons of resolution, then you have my sympathies.

interpol_p 13y ago
While I do a lot on the terminal, not everything is faster there. Jumping between symbols in your IDE is not going to happen faster on the command line because it's a spatial operation. You've located the symbol visually, clicking it to jump to definition is far faster than keyboard-navigating to it, or even typing it. Merging is better with a dedicated merge tool than a command line merge. I have to resolve conflicts one to three times per day and I couldn't imagine a non-visual merge interface for complex files where manual edits from both sides are necessary. Being able to see it all at once helps. There is nothing quite as good as Xcode's instruments on the command line — providing easy to navigate visual representations of your performance and memory use, graphs and other metrics. Having the instruments panel on a second screen is incredibly useful, the extra screen real estate is of real value here. Having to keep switching on a single laptop display is a pain in the ass. Obviously there are many tasks that cannot be easily sped up on the terminal, saving slices out from Photoshop (when your designer hasn't done it properly). And then getting the resulting assets into your pipeline. This stuff is benefited by extra screen space. But the main benefit is being able to see more code at once. And it is especially helpful in large re-factoring operations or with extensive debugging / performance profiling. As I said, it depends on the type of work. I can code just fine on my laptop but I tend to prefer coding focused features, or fixing isolated bugs. I find the previously mentioned profiling and architectural changes are better suited to large screens where more code / graphs / visual assets can be seen at once. You simply can't do "all these things" in a terminal. You can do a hell of a lot, but sometimes you need visuals and sometimes you need space. When you can see more code you don't have to hold as much in your working memory, your eyes can flick back and forth over your code and it makes it easier to see the dependencies and realise what you need to change.
- dllthomas 13y ago
  "Jumping between symbols in your IDE is not going to happen faster on the command line because it's a spatial operation. You've located the symbol visually, clicking it to jump to definition is far faster than keyboard-navigating to it, or even typing it." When the lab I worked in moved between buildings, we each broke down our work stations and set them up in the new spot. I went through a good week of getting work done before I noticed that I hadn't plugged in my mouse - I just never reached for it, because virtually everything happens with a thought when my hands are on the keyboard.
  - interpol_p 13y ago
    Most of the time when I'm coding I use the keyboard to jump to symbols. But when you are getting acquainted with a large codebase, reading through and clicking to jump to symbol can be a more efficient way to parse the code and understand its interdependencies. It may depend on what you use to position the cursor as well — I haven't used anything but a trackpad in the last five years, and even on that mostly I use gestures to navigate UI. Since the trackpad is almost part of the keyboard it feels very seamless to scroll/tap and type.
    - dllthomas 13y ago
      Yeah, I'm much more likely to bump a trackpad than reach for a mouse, even when the mouse gives me much more control (I always find trackpads a little finicky), just because of the distance. My hands don't need to actually go anywhere. Of course, I also bump the trackpad accidentally sometimes, but that's a separate issue...
- dllthomas 13y ago
  "Merging is better with a dedicated merge tool than a command line merge. I have to resolve conflicts one to three times per day and I couldn't imagine a non-visual merge interface for complex files where manual edits from both sides are necessary. Being able to see it all at once helps." Being able to see it all at once absolutely helps, but on a big enough console you can see it all just fine. Vimdiff is great. A large monitor definitely adds value there, GUI or TUI.