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.

Not Using the Right Data Structures

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.

Not Targeting the End-user Experience

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.

Planning for the Unknown

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.

Underestimating the Importance of Code Quality

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.

Not Questioning Existing 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.

Picking the First Solution

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.

23) Over-Using Shared State

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.

Having the Wrong Attitude Towards Code Reviews

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.

Not Writing Tests

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.

Not Picking the Right Tool for the Job

<ul><li>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!</li><li>There are no best practices. There are probably good practices today and for this programming language.</li><li>Some of what we previously identified as best practices in programming are labeled today as bad practices.</li></ul>

Obsessing About Best Practices

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.

Reinventing the Wheel

<ul><li>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.</li><li>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. </li><li>However, be careful what you Google for. Another sign of a newbie is copying and using others code as is without understanding it. </li></ul>

Not Googling

Here are a few wrong practices that usually make the code a bigger mess than what it was (not a complete list): <ul><li>If you Copy/Paste a code section to only change a line after that, you are simply Duplicating code.</li><li>If you need to use a value in multiple places, that value belongs in a configuration file.</li><li>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.</li></ul>

Making Existing Code Worse

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.

Not Taking Breaks

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.

Not Using Source Control

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.

Obsessing About Performance

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.

Writing Comments About the Obvious Things

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.

Not Quitting

Do not look for a perfect plan before jumping into writing code. Look for a good enough plan, something that you can use to get started. The truth is, your plan will change, but what it was good for is to force you into some structure that leads to more clarity in your code. Too much planning is simply a waste of your time.

Planning Too Much Before Writing Code

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.

Not Understanding that Code Problems Will Cause Data Problems

Writing quality programs is a process with a flow: Think. Research. Plan. Write. Validate. Modify.One of the biggest mistakes you can make as a beginner programmer is to start writing code right away without much thinking and researching. While this might work for a small stand-alone application, it has a big, negative effect on larger applications.Just like you need to think before saying anything you might regret, you need to think before you code anything you might regret. Coding is also a way to communicate your thoughts.

Writing Code Without Planning

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.

Not Using Encapsulation

Let me make one thing clear first. If you are a beginner programmer, this article is not meant to make you feel bad about the mistakes that you might be making but rather to make you aware of them…

Planning Too Much Before Writing Code

Similar ideas to Planning Too Much Before Writing Code

Rules of storytelling, according to Pixar

Doing It Badly

Disruption of Progress