[pmdulaney]

1. vi/vim/MacVim - it simply becomes second nature, without the laborious keystrokes of the "major competitor".

2. Command line stuff: grep, tr, awk, find, od.

3. Pencil and paper. Draw a picture.

"Never cut what you can unravel." - Joseph Joubert

[gregjor]

Exactly. Unix was the original programmer’s workbench and still is.

Programming should mostly happen between the ears. I do most of my work thinking and writing notes, diagrams, and pseudocode on paper.

[justinlloyd]

I cannot stress this enough to new programmers. Think before you code. When your hands are on the keyboard you should either be investigating an unknown system to figure out how it works, or you should be implementing that which you have already designed & built in your head.

If the code I am writing right now doesn't involve me poking at a system because I don't understand it and learning it, then at a guess, I would say I spend far more of my time thinking about the production code I will write than writing the actual production code. Hands on keyboard for hours at a time is a sure sign you're working on a problem you don't really understand. It took me decades to come to that realization because many companies measure productivity by "number of hours of your butt in a chair multiplied by lines of code written."

In my current role I am considered one of the most productive developers on the team. I am physically at the keyboard writing code or debugging code for maybe three hours a day.

[gregjor]

Measure twice, cut once is a good guideline.

I learned desk checking my code (and other people's code) early in my career when computer time was expensive and I had to wait to run my code. I still do a lot of desk checking. I find that process helps me understand the code and data structures better. After a while it becomes second nature, you can learn to "run" code in your head.