One of the simplest tricks I learnt while pairing was that while creating a new test class, open existing test, duplicate the existing template for tests, rename and then extract to new file.
Another simple example is don't type the left side of declaration, do the right side and then do local variable refactoring.
What are some of the simple tricks that once become muscle memory just save you a lot of time?
(Programming is not about speed of coding and programmers don't spend majority of time coding. Nevertheless, it is worth it to know some of the tricks so that you can become more efficient or just for knowing how others code.)
Probably the biggest thing that transformed my development process and increased my productivity the most was the day I kicked IDE's to the curb.
There are things in IDE's that always bothered me, and some "professional code editors" have them too. Like most of the garbage like closure completion, autocomplete, and so forth just gets in my way resulting in spending more time figuring out what the editor is trying to do or correcting what it did without even asking instead of just typing what I wanted in the first damned place! Or colour syntax highlighting being UTTERLY illegible trash for me... I wanted to have my code look that way I'd pop a 'sugar cube'.
But those are not what it was that changed my process making me more effective. It was the simple fact that IDE's LOVE to shove everything not just into one program, but also into one single window; and as someone who's been using multiple display systems since the 1980's... THAT'S JUST STUPID!
no joke, even in the '80's I'd plug in a MDA card next to a CGA/EGA/VGA so I could display debug output on the second screen.
Tabbed editing and shoving everything into one window is a colossal steps BACKWARDS when you have multiple displays -- or even just one widescreen display!
A lesson Microsoft clearly forgot with Metro crapplets in Windows 8, basically telling desktop users to go f** themselves.*
I didn't realize this right away about IDE's but ~20 years ago or so when I went to three full 21" 1600x1200 displays under Win98 it just kind of 'clicked'.
Also why I chuckled when linsux users started bragging about twinview as if it was some magical new capability that they STILL can't even handle properly.
The trick is to keep all your code in separate windows that are taller than they are wide (just like 90%+ of most code) so that you can display them side-by-side!
Rarely do you work on code where it's one single monolithic file. Your code will often reference or rely on other files where it is REALLY handy to look at them side-by-side. This is even MORE true in front-end web development where it helps to look at your HTML or server-side scripting side-by-side with your stylesheet(s) and client-side scripting.
When I'm doing web development I have my left display (24" 1920x1200) displaying PHP/HTML, CSS, and JS side-by-side at a third of screen width apiece. I have my right display (also 24" 1920x1200) set up with a terminal session, FTP client and usually a chat window or two for interacting with clients and other developers WHILE working. In the center display (27" 2560x1440 IPS) I run the browsers and various VM so I can quickly and easily swap between them for testing, as well as any graphical editor I'm using. This way I can compare things side-by-side, pull up online references or PDF copies of manuals while still looking at my code, etc, etc...
Working with compilers like GNAT, FPC, BCC, etc is no different. I have the main program and various sub-files open on the left, testing and browser/pdf for reference in the center, terminal session on the right where I call the compilers from the command line and monitor the output.
It's all on screen, at once, giving me a clear overview of the entire process. It means that since everything is separate I can pick and choose the best of each instead of having to put up with a specific weakness in any one aspect of an IDE.
... and honestly, I find console output a lot more clear and easier to work with for debugging than the integration most IDE's provide. Having the editor go to the line and character of the error is cute, but is ^H really so hard? Worse, usually the error message stuffed in the same window sucks down window real estate making less room to actually SHOW THE BLOODY CODE!
Really that's where IDE's, RAD's, and fancier editors started yanking my chain, was they keep adding panels and toolbars and sidebars and management trees and controls for hiding sections of code (the dumbest shit I've ever seen in dev) that just reduce the amount of useful window space (particularly in the vertical) for actually EDITING THE HUFFING CODE!!!
Which is why the biggest improvement to my workflow and productivity was telling IDE's, RAD's, and fancier editors to sod off.