As I like to say, I do most of my programming before I touch a keyboard.
The single most powerful thing I do is ask questions and write down the answers. When I want to understand a system this is the fundamental step that cannot be skipped. How crucial it is that I understand the system will tell me how formal I need to be in my thinking. If it's a basic web application or a report I need to generate it's a simple, informal note. If we're talking about a critical system that's distributed and requires high-availability with hard limits on processing time and the consequence of getting things wrong is that businesses and people lose money/property? Then I'll bust out the mathematics and model things formally.
I've experimented as well with writing code on paper first. This doesn't work so well with procedural languages without some form of shorthand/formalism. It works much better with statically-typed functional programming languages. When using such languages I mostly need to reason about the types: the implementation is a matter of filling in the holes which can be done when I'm at the keyboard. The more I learn to "think in types," the better this works but I'm not super great at it yet.
Notebooks are where it all begins.
I also use notebooks to journal my work. I use the bullet journal system to keep track of my work. Keeping it on paper forces me to sit in front of it and physically remind myself of my tasks. It helps me stay focused on the day to day activities and not lose track of my longer-term goals. After using one long enough this way it becomes a chronicle of my work. Handy for performance review season. A great deal of programming work comes out of these journals.
Some folks prefer digital tools and that's fine and dandy. I'm just old school and prefer physicality. Paper and pen work on the level my brain works on and gives me a break from screen, keyboard, and constant stream of notifications. Room and freedom to think without interruptions is important and useful.
The single most powerful thing I do is ask questions and write down the answers. When I want to understand a system this is the fundamental step that cannot be skipped. How crucial it is that I understand the system will tell me how formal I need to be in my thinking. If it's a basic web application or a report I need to generate it's a simple, informal note. If we're talking about a critical system that's distributed and requires high-availability with hard limits on processing time and the consequence of getting things wrong is that businesses and people lose money/property? Then I'll bust out the mathematics and model things formally.
I've experimented as well with writing code on paper first. This doesn't work so well with procedural languages without some form of shorthand/formalism. It works much better with statically-typed functional programming languages. When using such languages I mostly need to reason about the types: the implementation is a matter of filling in the holes which can be done when I'm at the keyboard. The more I learn to "think in types," the better this works but I'm not super great at it yet.
Notebooks are where it all begins.
I also use notebooks to journal my work. I use the bullet journal system to keep track of my work. Keeping it on paper forces me to sit in front of it and physically remind myself of my tasks. It helps me stay focused on the day to day activities and not lose track of my longer-term goals. After using one long enough this way it becomes a chronicle of my work. Handy for performance review season. A great deal of programming work comes out of these journals.
Some folks prefer digital tools and that's fine and dandy. I'm just old school and prefer physicality. Paper and pen work on the level my brain works on and gives me a break from screen, keyboard, and constant stream of notifications. Room and freedom to think without interruptions is important and useful.