|
I think I've gradually developed something like deliberate practice as I go along, in that I increasingly approach greenfielding with an "idiomatic muscle memory solution" like "write approximately this style of loop", or "make approximately this data structure", and then start adjusting the outcome of that to fit the true nature of the problem, because that gets me through at least two iterations, while if I just sit at a blank page thinking, I produce code that is usually not really better and still needs adjustment. For some things architecture planning does help, but a great deal of it can be written as a pseudocode comment where i list the idioms i plan to use to address the problem. Often I do that, spot the flaws, and get in another iteration that way without having to go to the compiler. When I'm really stuck I go back to basic philosophy-of-truth reasoning and look for "a set of ideas that are coherent with each other" - one idea being the problem being solved, and the remainder being techniques to apply. Often this process reveals a need for research into unknowns, and hence another source of iterative feedback. And so if I were to codify all the types of common idioms as if they were scales - which I haven't done - I would be able to drill those, but I suspect that there's a lot of them that are different between different domains of programming, and that's a major source of expertise. Likewise my approach to naming has seen some iterative improvement, and it's definitely a thing I am training as I go. Names are like comments: you don't really want too many of them in your program, because they can obscure other information. Standardized variable names are great, and dense code is great when you can get it without sacrificing much readibility. I spent a little while evaluating what length of variable is sufficient to avoid collision and maintain readability while getting good density where needed: 1 letter - fine for local variables using detailed mathematics, where each variable is necessarily used in a dense, non-obvious way and it would be reasonable to have an explainer comment. 2 letters - hard to use well. As abbreviations they tend to collide too often to be recommended, and they are hard to recognize. 3 letters - a sweet spot for density and low collision rates, but still often unreadable. 4 letters - sufficient for most abbreviations and many full words. 5+ letters - at this point a majority of single words you would use will fit, and so you may as well consider this as "I am spelling out a whole word", with the next step up being multiple words and phrases, and at that point code density is the main tradeoff being made. A common naming idiom I practice is labelling array-like values such as min/max bounds numerically, e.g. an axis-aligned box defined with x0, x1, y0, y1. For a while I used "result" as the variable for all returned values, after seeing this idiom in Pascal. Then I realized that I could use "ans" (answer) instead and get much denser code in a lot of instances. It's little things like that, which add up to a pleasant, lower-friction experience. |