Hacker News Reader

Comment by elviejo | Hacker News Reader

1. Touch typing. You must be able to type as fast as you think. So that there are no barriers between your brain and the code. [0][1]

2. Alan Kay says: "if you want to be a better programmer, play more violin." The idea being that playing an instrument improves our brain

3. Write tests for ever open source project you encounter: unit tests, property tests.

4. Write specs using TLA+

[O] some people say that typing speed doesn't matter, because the slow part is thinking about the code. Those people are wrong.

[1] see the essay: "We are typists first, programmers second" https://blog.codinghorror.com/we-are-typists-first-programme...

View on HN

> [O] some people say that typing speed doesn't matter, because the slow part is thinking about the code. Those people are wrong.

Care to elaborate? There are people who cannot type (like physically) and yet they are programmers. Also, programming is all about mental gymnastics. Only accidentally (we are in the year 2022) we need to take our hands out of our pockets and type our solutions in an editor.

The elaboration is on the second link: "We are typists first, programmers second" https://blog.codinghorror.com/we-are-typists-first-programme...

By Jeff Atwood, cofounder of stackoverflow.

The reason why I stayed with VIM as my editor is that it's very efficient at doing repetitive tasks that otherwise would block my thoughts for a long while.

When you are refactoring a codebase, when you need to rename things inside a block, when you need to match function signatures, when you need to change a bunch of statements or expressions inside a block ... that's where VIM and emacs shine.

Additionally I'd recommend to learn about fuzzing and the ideas behind it, because it teaches you to write more defensive code and will teach you to never use these "quick return" style branches ever again.

>> will teach you to never use these "quick return" style branches ever again

Care to elaborate? Im not sure if I understand but I thought quick return from function was quite goode strategy for defensive coding? Or many You are taking about something else (I do not know fuzzing - can You point to some link with good explaination that would sell this concept to me?)

Reply on news.ycombinator.com