Strategies for novices that this novice keeps relearning
Mar 9, 2021 0:45:24 GMT -8
Post by Uncle Buddy on Mar 9, 2021 0:45:24 GMT -8
No matter how good any of this works part of the time, some of it it is going to be wrong at least some of the time. And no matter how wrong any of this might be for seasoned veteran programmers, it could still be a good idea, in general, for beginners. And none of this is written from the viewpoint of the interests of the person who wants code written fast so he can pay less money for it to be written. I wouldn't know anything about that.
I'll be adding to this list as things come up.
Notes to Self:
Don't try to fix broken code. Roll back to the code that was working, and use that as a basis for the next step.
Go one step at a time, testing after each change if possible.
Write repetitive code in complex situations instead of trying to parameterize as you go. When everything works, then go back and slim down the code by parameterizing the repetitive parts.
Read and understand the code before writing the next line. Guessing only works when you already know what to do.
The clearer your goal, the clearer your head.
Not everything that can be done should be done. If a solution is too clever, it might be hard to read, understand, maintain and extend.
Write code that will be easy for others to understand. In a short time your own code will be as hard for you to understand as if you'd never seen it before.
Most complex problems are best solved by simplifying the code, not making it more complex with added lines of code. If you patch complex code by making it more complex, the next problem that crops up will be even harder to solve.
Most hard problems are solved not when staring at the code, but when you walk away from the computer. This allows the main point to pierce the fog and clear the mind, replacing endless recycling of swarming details with an intuitive reduction of the problem to a goal and a few key ideas directly inspired by the goal.
You may still be learning so fast that the code you wrote a year ago is no longer worth extending. It may be easier to write that code over from scratch than to figure out how it worked and dumb down your current abilities enough to write new code that works with the old code. Depending on how bad the old code is, it might be a good idea to rewrite it without even looking at it. Refactoring is a great pleasure.
Often when I don't know what to do, it's because I'm thinking about step 4, but steps 1, 2, and 3 are standing in the way obscuring the road ahead. I know how to do steps 1, 2, and 3, but instead of doing them, I'm worrying about how to do step 4 when I get to it. But if I go ahead and do steps 1, 2 and 3, step 4 will often reveal itself.
Don't always work on the hard problems first, while ignoring easy problems because you already know what to do. Sometimes when I fix all the small problems, the big problem that I didn't understand mysteriously disappears.
This has happened so many times: a scary problem crops up and a little voice says, "Do this." I ignore the little voice for an hour or two (or a day or two). When I'm finally ready to give up, I go ahead and try that first idea that popped into my head. I mean, seriously give it a shot. And it was the right solution all along.
In short, keep it simple, read the code, and know what your goals are.
All Classes vs. All Functions vs. Moderation in all things
Don't join any religions. For example, OOP vs. Procedural. Use classes when they fit your needs best, but don't buy the OOP dogma whole hog. Use procedural coding when it fits your needs best, but don't be afraid to use classes when they help organize and encapsulate the code.
Regarding Python classes, don't be put off by the proliferation of self. Self is a good thing. Python classes are easy to use. On the other hand, when using them, don't use every possible opportunity to create an instance variable with self. Overusing instance variables to get easy access to a value works out the same as using global variables. Pretty soon you won't know how a value got to be, because it can be changed from too many different places. When it helps make the class easier to understand, keep using return values and nested functions, and keep passing arguments, instead of making every single changing value an instance variable.
The main purpose of a class is for repeated code, but another big advantage is that it provides an intermediate namespace domain between the function-level domain and the module-level domain. After trying to write code without any classes, I find that this intermediate domain is a huge benefit of classes that I'd now hate to be without.
Health Related
In light of the fact that staring at a computer locked into a chair hour after hour without letup doesn't improve your code (see above), it seems like a good idea to not ignore the fact that it doesn't improve your health either. So I have some guidelines for myself.
Stand up once every 5 to 10 minute and walk around a little bit.
Take a 5-minute break 2 or 3 times an hour.
Sleep at least 8 hours a day.
Don't snack. If you can't not snack, then don't eat sweetened or starchy processed foods.
I'd say "don't write code more than 12 hours a day" but some good rules will never be obeyed.
I'll be adding to this list as things come up.
Notes to Self:
Don't try to fix broken code. Roll back to the code that was working, and use that as a basis for the next step.
Go one step at a time, testing after each change if possible.
Write repetitive code in complex situations instead of trying to parameterize as you go. When everything works, then go back and slim down the code by parameterizing the repetitive parts.
Read and understand the code before writing the next line. Guessing only works when you already know what to do.
The clearer your goal, the clearer your head.
Not everything that can be done should be done. If a solution is too clever, it might be hard to read, understand, maintain and extend.
Write code that will be easy for others to understand. In a short time your own code will be as hard for you to understand as if you'd never seen it before.
Most complex problems are best solved by simplifying the code, not making it more complex with added lines of code. If you patch complex code by making it more complex, the next problem that crops up will be even harder to solve.
Most hard problems are solved not when staring at the code, but when you walk away from the computer. This allows the main point to pierce the fog and clear the mind, replacing endless recycling of swarming details with an intuitive reduction of the problem to a goal and a few key ideas directly inspired by the goal.
You may still be learning so fast that the code you wrote a year ago is no longer worth extending. It may be easier to write that code over from scratch than to figure out how it worked and dumb down your current abilities enough to write new code that works with the old code. Depending on how bad the old code is, it might be a good idea to rewrite it without even looking at it. Refactoring is a great pleasure.
Often when I don't know what to do, it's because I'm thinking about step 4, but steps 1, 2, and 3 are standing in the way obscuring the road ahead. I know how to do steps 1, 2, and 3, but instead of doing them, I'm worrying about how to do step 4 when I get to it. But if I go ahead and do steps 1, 2 and 3, step 4 will often reveal itself.
Don't always work on the hard problems first, while ignoring easy problems because you already know what to do. Sometimes when I fix all the small problems, the big problem that I didn't understand mysteriously disappears.
This has happened so many times: a scary problem crops up and a little voice says, "Do this." I ignore the little voice for an hour or two (or a day or two). When I'm finally ready to give up, I go ahead and try that first idea that popped into my head. I mean, seriously give it a shot. And it was the right solution all along.
In short, keep it simple, read the code, and know what your goals are.
All Classes vs. All Functions vs. Moderation in all things
Don't join any religions. For example, OOP vs. Procedural. Use classes when they fit your needs best, but don't buy the OOP dogma whole hog. Use procedural coding when it fits your needs best, but don't be afraid to use classes when they help organize and encapsulate the code.
Regarding Python classes, don't be put off by the proliferation of self. Self is a good thing. Python classes are easy to use. On the other hand, when using them, don't use every possible opportunity to create an instance variable with self. Overusing instance variables to get easy access to a value works out the same as using global variables. Pretty soon you won't know how a value got to be, because it can be changed from too many different places. When it helps make the class easier to understand, keep using return values and nested functions, and keep passing arguments, instead of making every single changing value an instance variable.
The main purpose of a class is for repeated code, but another big advantage is that it provides an intermediate namespace domain between the function-level domain and the module-level domain. After trying to write code without any classes, I find that this intermediate domain is a huge benefit of classes that I'd now hate to be without.
Health Related
In light of the fact that staring at a computer locked into a chair hour after hour without letup doesn't improve your code (see above), it seems like a good idea to not ignore the fact that it doesn't improve your health either. So I have some guidelines for myself.
Stand up once every 5 to 10 minute and walk around a little bit.
Take a 5-minute break 2 or 3 times an hour.
Sleep at least 8 hours a day.
Don't snack. If you can't not snack, then don't eat sweetened or starchy processed foods.
I'd say "don't write code more than 12 hours a day" but some good rules will never be obeyed.
