Code with fewer comments will have fewer bad comments.

Yes, and less is more.

Quality is better than quantity. If you have a 5000-word treatise in your comment block, it is probably full of inaccurate and outdated statements. Plus if it takes 5000 words to explain your ideas, then your ideas are too complicated and you should try a simpler approach.

Thus, code with too many comments needs to be simplified.

Do not use doubles or floats for dollar amounts.

Fractions of a penny are not a real thing and lead to difficult bugs.

The two most common practices for monetary values are:

  • Storing everything as pennies, and then remembering to convert to dollars on display. This can also be tricky when doing calculations, as you need to always remember that these are penny values.
  • Use a Money class. This uses the Value Object pattern to restrict what kind of values a Money object can have. It also forces all calculations to be made with more purposeful intent.

Learn and improve after failure.

If you never fail, are you really trying?

Failure is an essential part of the learning process. It means you’re trying new things and that you want to be better. Rarely do people get everything right on the first try. Usually, it takes a lot of practice.

When you fail, it’s not enough to say you’ll try harder next time. Instead, determine the root cause of the failure. Why did you fail? What went wrong? To get better, you must first understand. Blindly trying, again and again, is highly inefficient.

You need to change and improve your processes to avoid each particular failure you experience. In the future, you will still fail, but hopefully, due to a different cause.

Examine each failure closely. Were there any warning signs? Can you react to these warnings signs better in the future?

Learn how to prioritize.

If everything is a crisis, there is no crisis.

Not everything can be the top priority. Not everything can be urgent. And certainly, you can’t expedite everything.

You have to choose. It’s critical to do the important things first. That means you must set priorities.

If everything has the same priority, you won’t know what to work on next. It’s equivalent to having no priorities at all.

Ideally, there will be a prioritization list. You should have an ordered list of jobs that need work. The team can then easily refer to that list when they are ready to work on the next thing.

Also, avoid multitasking. It’s not the right answer either.

Don’t create “poltergeist” classes.

They’re useless.

These classes have no responsibility and just call methods in other classes.

You can usually replace these classes with calls to the delegate class directly.

Sometimes, developers implement these classes in anticipation of a future need for a more complex structure. This technique is not a good practice. Don’t write code in anticipation of possible future needs. Code for today, to meet the current requirement, to pass the tests.

See also “YAGNI.”

Don’t use exceptions for flow control.

That’s not what they’re for.

An exception should represent unexpected behavior. It should be something like an error condition, a fault, or something seriously broken.

Use other structures for standard flow control. Try the “if” statement, or a “case” statement, or polymorphism.

Exceptions act like GOTO statements and make spaghetti code that is hard to follow. Don’t make life hard on yourself. Don’t make things difficult for the people who come after you and have to maintain your code. Avoid using exceptions for flow control.

Don’t rely solely on quantitative statistics.

It will simply lead to people gaming the system.

When analyzing developer performance, it would be best to use statistics as an additional source of information. As such, statistics are extremely valuable. Charts and graphs, measures of confidence, trends, correlations – all great stuff.

Statistics cannot be the sole measure of the team’s performance. If it is, people will start working to satisfy the statistic instead of creating business value.

There are many examples of statistics that people have used in the past. Some people have looked at the lines of code created. Then people started adding more inane comments, newlines, unnecessary tests, and dummy code.

Another idea was to look at the number of commits. But then, people started making more and more smaller commits, even of things that aren’t any actual improvement.

As Scrum gained in popularity, people tried tracking the number of story points. Companies hired scrummasters to make the team more Agile and increase Velocity. But then the content of a story point was reduced, giving the appearance of improvement, even if it was all an illusion.

Someone else watched Office Space and decided that hours spent in the office would be a good metric. But then people spent half their days surfing the web, reading Facebook, and looking for a new job.

In each case, depending solely on a statistic led to the abuse of the statistic.

Mind the 7 P’s.

“Proper planning and preparation prevents piss poor performance.” – British military adage.

I can’t emphasize this enough: plan ahead.

No, really, plan ahead.

Our industry is full of miserable projects that are going every which way but right. The developers are flying by the seat of their pants instead of taking the time to make a plan. Don’t be these guys.

More senior developers understand the value of planning. That’s why they often become application architects. A team operating with a good plan in place will accomplish their goals more quickly. They will also have less rework to do.