Before I knew that there was an actual term for it[0], I would get a blank piece of paper, pretend I was an esteemed professor teaching whatever it was I was trying to accomplish. I would "ask my students" questions and "hear their answers". Then I would "guide them to the correct path".

0 - https://en.wikipedia.org/wiki/Rubber_duck_debugging

I do this by starting an email to whichever programmer I would email for help with that problem.

Usually I don't want to leave any obvious stones unturned, so as I tell them I checked this thing and that thing, usually I discover a few more things to verify, and one of them leads me down the correct path.

This works about 80-90% of the time for me. I rarely need to send the email.

Writing programs...

Read the error message. In full. Google unknown terms, relevant phrases from the message. Don't fix the bug unless its cause is understood.

Thinking at the function level. Instead of thinking: view, controller, Service , database .

I write a function that does what I’m trying to accomplish, like image upload.

It’s a small part that can be reused in some bigger system.

Then make it work with a few constraints: file size, file type.

I also hardcode stuff

Be careful not to miss the forest for the trees. Thinking in higher level is as important as thinking at low level.

Code really badly, and feel no shame in that. Then after the sloppy code has been understood, you can start to iterate on it and polish it, making your code seem professional, but you know you started the project as a total noob.

Some call it "sketching". It's similar to how artists would trace a few lines for structure before filling it out.

Another common approach is prototyping, where you build something that will be disposed for the purpose of learning. So you really won't feel any shame because you have to throw it out anyway.

Another way I’ve seen this done is to start a new branch in git clearly labelled as “experiment/thing”

Which can be reviewed/ saved for later / deleted. Without any pressure.

Also “proof-of-concept” to help learn or figure out how something will work.

Helpful if you want to try something that isn’t directly linked to an open ticket/issue or even just an issue under discussion and not part of the main backlog.

- getting used to designing abstractions before coding

- laying out how I'm going to program before starting

- using TDD for most bug fixes and refactoring efforts

- learning how to steal the best parts of code from other people

- code reading everyday via PRs (my mental VM is pretty close to a real VM)

- learning algorithms and data structures (at least the basics, I'm no competitive programming pro)

- learning how to do code archaeology with git blame

Writing code constantly and with each new product, how do I get it out faster and in less pages? This has made me a better programmer. I aim to try and get projects done from 1 weekend to 1 month and not take too much longer than that.