Depends on the situation in which you are programming. If you are in a big corp-y OO codebase, and you like that, then all the "Clean Code" and "SOLID principles" crap could help you. They are the amalgamation of people trying to cope with terrible "best practices" designed to make productivity numbers make sense when throwing people at code.
If what you really want to do is drive your own knowledge and skill, you need to practice the discipline of sitting down on your own for an hour a day and program something you find interesting. Take very small steps, ensuring that your program compiles and runs as expected after every change. Get something on the screen (and/or on your debugger watch window) as early as possible. Write the simplest code you can that does the thing you want to do, and put absolutely all programming methodologies, recommendations, and practices out of your mind. After each change, think about what the code is doing and what would be the simplest and most sensible thing to try next. If it that doesn't work, step back and try something else.
Don't worry about code "cleanliness" using this method. Pile the code on, and do not "pull" things out into separate functions until you actually are using the same thing in more than one place. Reuse is secondary to figuring out where everything goes at this point.
Don't worry about programming abstractions, focus your care on what the computer is actually going to do when it runs your code.
Don't worry about code "performance" as long as it is working well enough to prove the design you are expressing in code. After your design is fully realized, then you can go back and optimize.
Wait until the end to get OCD with the actual code. Like performance optimization, you have to have a written, working initial design first before trying to apply whatever code "aesthetics" and "beautification" organization you think it should have without confusing yourself.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Depends on the situation in which you are programming. If you are in a big corp-y OO codebase, and you like that, then all the "Clean Code" and "SOLID principles" crap could help you. They are the amalgamation of people trying to cope with terrible "best practices" designed to make productivity numbers make sense when throwing people at code.
If what you really want to do is drive your own knowledge and skill, you need to practice the discipline of sitting down on your own for an hour a day and program something you find interesting. Take very small steps, ensuring that your program compiles and runs as expected after every change. Get something on the screen (and/or on your debugger watch window) as early as possible. Write the simplest code you can that does the thing you want to do, and put absolutely all programming methodologies, recommendations, and practices out of your mind. After each change, think about what the code is doing and what would be the simplest and most sensible thing to try next. If it that doesn't work, step back and try something else.
Don't worry about code "cleanliness" using this method. Pile the code on, and do not "pull" things out into separate functions until you actually are using the same thing in more than one place. Reuse is secondary to figuring out where everything goes at this point.
Don't worry about programming abstractions, focus your care on what the computer is actually going to do when it runs your code.
Don't worry about code "performance" as long as it is working well enough to prove the design you are expressing in code. After your design is fully realized, then you can go back and optimize.
Wait until the end to get OCD with the actual code. Like performance optimization, you have to have a written, working initial design first before trying to apply whatever code "aesthetics" and "beautification" organization you think it should have without confusing yourself.