Not Taking Breaks

• 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...

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...

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 especial...

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 cod...

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 ...

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 ...

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.

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 imp...

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 eas...

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 u...

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 automatica...

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.

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.

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, yo...

• 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 pr...

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. Th...

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...

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...

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 ...

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.

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 c...