The Mistakes I Made As a Beginner Programmer

Never underestimate the importance of code quality. Look at coding as a way to communicate implementations. Your main job as a coder is to clearly communicate the implementations of any solutions that you are working on.

If you are not consistent with your indentation and capitalization, you should simply lose your license to code. 

Your job as a professional programmer is not to find a solution to the problem. It is to find the simplest solution to the problem.

Simple means the solution has to work correctly and perform adequately but still be simple enough to read, understand, and maintain.

Don't be attached to code because of how much effort you put into it. Bad code needs to be discarded if it isn't working. If you're not happy with a solution, you'll be stuck with it.

When it comes to writing programs, the right mentality is to fail early and fail often. The minute you begin doubting a solution, you should consider throwing it away and re-thinking the problem. 

• Unless you are using a bleeding-edge technology, when you run into a problem, chances are someone else ran into the same problem and found a solution for it. Save yourself some time and Google It First.
• Sometimes, Googling will reveal that what you think is a problem is really not, and what you need to do is not fix it but rather embrace it. 
• However, be careful what you Google for. Another sign of a newbie is copying and using others code as is without understanding it. 

The big idea here is that you want your code to have High Cohesion and Low Coupling, which is just a fancy term that means keep related code together (in a class) and reduce the dependencies between different classes.

Do not write code that you do not need today. Do not plan for the unknown future. Writing a feature because you think that you might need it in the future is simply wrong. 

Always write the minimum amount of code that you need today for the solution that you are implementing.

The most common data structure mistake is probably the use of lists instead of maps to manage a list of records. Using lists for scalar values is okay and often the better choice for large collections. 

Not using stacks when writing code that requires some form of Recursion, it is always tempting to use simple recursive functions. Using a stack structure is an alternative to using recursive functions, but it is usually hard to optimize recursive code.

Here are a few wrong practices that usually make the code a bigger mess than what it was (not a complete list): 

• If you Copy/Paste a code section to only change a line after that, you are simply Duplicating code.
• If you need to use a value in multiple places, that value belongs in a configuration file.
• When you can avoid Conditionals without sacrificing Readability, you should. The major problem with this is extending a function with a branch logic instead of introducing another function.

Most comments can be replaced with Better-Named elements in your code. If you are tempted to write a what comment to clarify the code, please do not point out the obvious. Remove comments like these if you have to deal with them.

Educate programmers who write comments about how bad they are. 

If you think you are an expert programmer, you are a newbie. If you are not writing tests in code, you are most likely testing your program manually.

There is nothing wrong with manually testing your code. However, you should manually test your code to figure out how to automatically test it. If you successfully test an interaction with your application, you should go back to your code editor and write code to automatically perform the exact same interaction the next time you add more code to the project.

If the author of that code is long gone or cannot remember it, research that code and try to understand everything about it. 

Only when you completely understand the code you get to form an opinion whether it is bad or good. Do not assume anything before that.

• I think the term “best practices” is actually harmful. It implies that no further research is needed. Here is the BEST practice ever. Do not question it!
• There are no best practices. There are probably good practices today and for this programming language.
• Some of what we previously identified as best practices in programming are labeled today as bad practices.

The good rule to remember about this is: if you cannot measure the suspected performance problem with the code, do not attempt to optimize it.

If you are optimizing before executing the code, chances are you are doing it prematurely. There is also a big chance that the optimization you are investing your time in is completely unnecessary.

Do not be that developer. Be one of the professional ones who put themselves in their end-users’ shoes. They imagine what the users of this particular feature need and how they might behave. 

They think about the ways to make the feature easy for the users to find and use, not about the easy way to make the feature exist in the application somehow without any thoughts about that feature’s discoverability and usability.

Everyone has their list of favorite tools to assist them in their programming-related activates. Some tools are great and some are bad but most tools are great for one particular thing and not so great for many others.

Relying on a tool’s popularity rather than how much it fits the problem is a sign of a true newbie.

An important aspect of a program is often the management of some form of data. The program will be the interface to add new records, delete old ones, and modify others.

Even the smallest bugs in a program’s code will result in an unpredictable state for the data it manages. This is especially true if all validations on the data are done entirely through the same buggy program.

Beginners might not immediately connect the dots when it comes to code-data relationships. 

In programming, some wheels are simply worth reinventing. Programming is not a well-defined domain. So many things change so fast and new requirements are introduced faster than any team can handle.

However, if you need a wheel, do not buy a whole new car and put the car that you are maintaining on top of that new car. Do not include a whole library just to use a function or two out of it. 

Coding newbies often look at code reviews as criticism. Look at every code review as a learning opportunity. 

You are a forever code Learner. You need to accept that.

Source control is not about just pushing your changes for others to have and build on. It is a lot bigger than that. Source control is about clear history. Code will be questioned and the history of the progress of that code will help answer some of the tough questions. This is why we care about commit messages. They are yet another channel to communicate your implementations and using them with small commits help future maintainers of your code figure out how the code reached the state that it is in right now.

Every variable we define represents a shared state. It holds data that can be changed by all elements in the same scope as that variable. 

The more global the scope is, the worse the span of this shared state. Try to keep new states contained in small scopes and make sure they do not leak upward.

You will often be in the zone and forget to take breaks. 

Take a lot of short breaks. Leave your chair and take a short walk. Come back to the code with fresh eyes.