To your repeated point: It's been my experience that better knowing what the code is doing leads to improving it. I am not a smart or clever person. I can only see one focal point at a time. But with enough time (and a trivial screen resolution) I feel that I can understand and improve on something as complex as the operating system running my computer, which is some very big software with parts of it (big and small) written in the early 80's on 80 character wide screens. This probably applies to everyone's operating system, so I'm just using it to juxtapose my next subject, which is the nightmare project (and I'm not making any of it up).

Looking back on the nightmare project almost makes me cry until I manage to suppress its memory. The difference between this project and my operating system is that my operating system is written by people who need to maintain software for a long time and, at some random point in the future, will need to rely on the maintainability of the code they wrote a lifetime ago. My nightmare project was not written with the project in mind, let alone the future of the project. Its problems were far removed from screen resolution. Its problem was the programmer. The programmer made it as painful as possible for me to understand what ze had written.

There was no abstraction and the code's entry point invoked every procedure the project directly in various loops. There was no difference represented between the software's big wheels and tiny gears. This made large scale changes difficult because dependent code had no typed contract, just access to buffers and primitives passed around in what was essentially a big main().

There was no cohesion of modules in the project and procedures just appeared together grouped seemingly at random and given names project1.x, project2.x, etc. Even if I had enough screen real estate to have the whole project's source open simultaneously, I would have been just as lost as when I was trying to wrap my head around a single file.

There was never a consideration for inversion of control and all the flow parameters were hard coded paths in giant conditional nests all throughout the project. That made simply guessing which code paths to analyze for a given input difficult.

Seeing more bad code doesn't make fixing it any easier and seeing more good code doesn't help me understand it any faster. When it comes to code, there are many factors influencing how productive I will be at working on it and screen resolution should be down there on the list, hopefully near the bottom.

"You may not realise this, but"

Was that necessary?

"committing those shortcuts to muscle memory makes using graphical applications just as fast, if not faster, than many tasks on the command line."

What's even better about the command line is that you can pipe input and output between applications. Chaining commands and remaining on the cli is faster for me than switching between applications and opening files. Most UIs have no way to define macros for commonly used procedures, whereas you can script anything cli-based.

"Do you also do all your performance profiling on the command line? Because that is a situation where visual data is very helpful, and a visual interface is in general more efficient and faster to navigate than the same on a command line."

I do. I lack the sensory to monitor more than a couple metrics at once. I prefer profiling data that can be captured and analyzed later.

user:	johndriscoll
created:	July 5, 2013
karma:	16
about:	Just a guy with a keyboard.