What are some traits/practices of experienced/good programmers that every beginner programmer should know?

As someone who teaches new programmers for a living, the majority of the issues with new learners is skipping these two steps: Understand the problem-  Many people who come to this field cruised through school with little difficulty.  I often catch them making assumptions and starting to write code before they've really thought things through. Diagram the problem- If you truly understand the problem, then drawing a visual diagram of its flow should be no problem.  I express to my students that it doesn't matter if you diagram it as a list of steps, a flowchart, or plain old English.  You must have a plan for solving the problem before you write code. After you've done this, you can start writing code. Name things well- If the name doesn't easily describe what it is you are attempting to do, then I believe that you don't understand the problem enough yet. Break pieces of the problem into small chunks- Methods should do one thing and do it well.  Classes should be comprised of data and method with high cohesion, which is to say they are strongly related.  For example, don't put print to screen logic in the same class that reads from a file, they are two different responsibilities and don't belong together. Try to finish code before you move on to new code- People that "bounce around" their code too much generally end up with a spaghetti mess.  If you need to move on, just return some fake data or a fake result so at least the code you wrote compiles and returns something useful.  The first step to getting out of a hole is to stop digging! If you don't know how something works, do a spike- Many new developers think that their current application is their playground.  If someone asks you to use a new component, and you need to experiment with it, just spin up a "spike" which is a temporary project that can be thrown away.  Exercise the component and get to know it then take what you learned and put it into your real project. When you get frustrated, that's your brain signalling it is ready to learn something.  So ask!

Three things: 1. Understand the requirement. Don't assume it's easy and jump in with the coding. Realise that code is the easy and fun bit (unless you're writing some API or something highly complex). Understanding the problem. Really understanding it (and agreeing it) is the hardest part of any development task. 2. Stop assuming the best case. The network will fail at some point, the filesystem will slow to a crawl sometime, DB space will run out, one of the messages you get will be corrupt (or maybe several thousand of them will be corrupt). How do you deal with it, so you don't end up in a mess? What s the worst that can happen? Try to anticipate it so it doesn't really ruin your day! 3. Don't try too hard for generic, reusable, perfect code (contra to what 'good' software design might be naively thought of). In most business-applications write to solve a problem. Keep it simple. Of course use design patterns and re-use where it makes sense, but don't code for the 'might need it one day' case. Complexity increases as does maintenance - if it's in the code, it needs testing, upgrading, documenting etc. etc. If you don't need it, don't write it. "Perfection is not when there's nothing left to add, it's when there's nothing left to take away". (The exception to this is writing an API or library. Most developers are not writing public libraries) Enjoy it! If you don't love it, do something else :)

Write code that's so clean, you are proud to let someone else work on it. Design before programming, not after. Stamp out coupling. Put all the logic for a decision in one place. Handle exceptions. If your program does not work on the first test, find the error by reading the program.  If cannot tell what source code does by reading it, call yourself a tester, not a programmer. If it doesn't work by the third test, you are doing something wrong. Use the debugger only as a last resort. Using the debugger means you don't know what your program is doing.

1) Keep your code as neat as possible: - Use comments generously. - Align properly - Don't use messy syntax. - Use good variable/function names. The neater your code, the easier it will be to debug and maintain later. 2) Work by hand to test the correctness of trivial parts of code; don't rely on testing by running: - When you are working with loops, the termination condition might be tricky at times: Whether you should use '<' or '<=', for instance. Don't rely on figuring this out by running the code, try to reason it out beforehand. - For if .. else constructs, make sure all possibilities are handled. When you have many loops and if..else blocks in a large program, it will be very hard to pinpoint the error if you plan to debug by running the code. 3) Use modularity and top-down approach to write complex code: For this, let us consider an example - suppose you want to make a game of carrom. The first and foremost step here is to make an elaborate design before writing a single line of code. Then, start top-down. The main function will look something like the following: int main() { initialise(); renderGraphics(); for (int currPlayer=0; boardNotEmpty(); currPlayer = (currPlayer+1)%numOfPlayers) { Move m = getMove(currPlayer); updateMove(m); } } (The variables need to be declared appropriately.) Now declare each function used in main, and write a comprehensive comment before the function definition specifying what 'main' expects the function to do. For example, the declaration of getMove will look something like the following: /* Takes a playerNo between 0 and 3 : 0 = bottom, 1 = right 2 = top 3 = left Returns the initial position of striker, the angle at which the striker is launched and the force with which it is launched, into a struct Move. */ Move getMove(int playerNo) { } The reference values for angle and force must have been decided during the design phase. Continue the process of breaking each function into simpler functions till you get very simple functions. Then start testing the correctness of functions bottom-up, because if you start with some function that is higher in the hierarchy, then you wont know which lower function is responsible for incorrect output.