I believe in the discipline of mastering the best that other people have ever figured out. I don’t believe in just sitting down and trying to dream it all up yourself-Charlie Munger

There are lots of standards, approaches, best practices that great software developers have worked out and shared with the development world.

Principles such as DRY, KISS, YAGNI, S.O.L.I.D and design patterns to help developers create quality code.

There is a library of books written by brilliant developers sharing the experiences and approaches.

Yet despite all these resources there are some developers who not only ignore the best practices but actively dislike them. Many developers view unit tests, naming standards, code reviews as a waste of time.

Why wouldn’t you copy the same approach as not just the best developer you have met but the most experienced and potentially the best developers in the world?

I worked on a software project where there was one developer was a software engineer who had high standards and was always looking to improve the best practices of the software development team. Another developer who had worked on smaller projects, thought unit testing, devops, code reviews and other quality steps, was a waste of time.

The two developers would have long heated discussions about the approach we should use on the software project and neither would change their mind or listen to the other developer.

It made me wonder why some developers don’t believe software development best practices are any good and they resist them.

Small projects and experience

Successful approaches in small projects make it difficult to move away from in larger projects. The approach and quality that works on a small project will fail miserably in a large project.

Small projects have few developers and don’t last for long. The pain of technical debt, complexity and low-quality code don’t have time to appear. The only people who suffer from low quality code are the team supporting it and it’s not usually the same development team who created it.

On large projects with more developers and more time, low quality will cause chaos and problems.

If a developer has only worked on small projects then they could have had success not using best practices and don’t see the reason to start using them. This is like saying you can’t teach an old developer new tricks.

When hiring developers, I find out what standards and best practices, they believe in. In my experience is easier to teach a graduate to use standards and create high quality code. To ask a developer to unlearn poor practices and then learn new practices is difficult and often fails.

Reward and incentive

‘The iron rule of nature is: you get what you reward for. If you want ants to come, you put sugar on the floor.’ — Charlie Munger

There Is No Benefit or Incentive for Developers to Create Quality Code on Software Projects. Software development teams are led by managers, project managers and customers. Non-technical people simplify software development and want software to be created fast. They don’t think about maintenance or technical debt/complexity because these are long term considerations.

The measure used to monitor software development teams is speed of software created, not quality. Fast, low quality software is rewarded and quality is not a priority.

If you value low quality code the same as high quality code then low quality code will push out high quality.

Bad money drives out good money — Gresham’s law

The Gresham’s law of software development, developers will do what is easiest if the reward is the same. Gresham’s Law — Why Bad Developers Push out Good Developers

Creating software is misunderstood, quality is the fastest way to create software and smooth development with fewer error (Software development is a loser’s game). Non technical people focus on writing code/software as fast as possible and don’t care about quality. They encourage and reward fast development and low quality code.

If there is no reward for good code then no one is going to create it and developers won’t learn the best practices.

Companies get the developers their culture and career progression rewards.

Ignorance

You can’t apply best practices if you don’t know them. Many developers just focus on writing code and don’t spend time learning best practices or the fundamentals of software engineering.

These developers don’t know what they don’t know. Similar to learning from mistakes only once you acknowledge the mistake.

The other area of ignorance is when a developer is told to apply best practices, but they resist because they don’t understand the benefits of the best practice. Or the developer doesn’t believe in the benefits of the best practices.

Unless standards are enforced with code reviews and automated rules then developers won’t apply them. The world is full of software projects where there are standards written in a document, but no developer has read it and those standards are not enforced.

Professionalism

if you view software development as a career, you view improving your knowledge, learning new skills and understanding best practices as part of your professional approach to software development.

Software development is a skill and improving a skill takes practice and thinking. Knowledge has to be updated with changes happening.

Many developers are unprofessional, they don’t have a career plan, no plan to update their knowledge, skills or experience.

Amateurs think short term and create technical debt, professionals think long term and create quality

• Software Developers Need a Professionals Mindset or They End Up an Amateur
• Why Developers Need a Career Plan

Short-term approach

Abraham Lincoln's father had a short-term approach to life. He was a farmer in the wilds of America. His approach was to do just enough to survive. He would only clear enough of the farm to farm enough food for the family.

He survived but he guaranteed he would never get ahead. He sent Lincoln to one year of schooling and would complain whenever he saw Lincoln reading a book.

Lincoln left as soon as soon as he was 21, at the time you couldn’t leave before then because you were required to pay back the investment your parents had put into you.

Many developers use this same approach of copying solutions from the internet — Copy-and-Paste Developers Suffer From Fragile Knowledge. They get solutions for today but learn nothing. If anything changes, they cannot fix it.

It’s only by learning, improving that you make life easier for yourself in the future. The more skills, knowledge and experience you get, the more valuable you become.

Developers who don’t enjoy development want to do as little as possible and are not interested in progressing in their career but just getting through the day.

Software development is an infinite game, it’s a not a skill that can be mastered, there is always room for improvement.

Best practices, and poor practices get the same results initially

For the first few months, low quality code and high-quality code will follow a similar trajectory. A good development team creating high quality and a poor development team create low quality will create about the same amount of code for the first few months.

In the short term, progress will be similar and from the outside software, features and code will look similar.

If the software is small and can be finished in a few months, those involved can pat yourself on the back, mission complete.

Technical debt, complexity and other effects of low quality code have a delay before the pain is felt by the development team. Technical debt and complexity make it harder (and slower) to interact (understand, change or update) with code.

A simply way of thinking about complexity is the increase in related connected code. More code will be connected and poorly designed code is more connected. This makes understanding and changing code harder and causes more bugs.

The delay hides the cause of the problems and no one is sure who or what has caused the software to be harder to develop.

Most decisions made on software projects have a short term focus that causes long term problems. People trade initial speed for accuracy and quality.

Good and bad developers CV’s look similar and they can sound similar.

The Difference Between Junior Developers and Senior Developers

At a distance, senior and junior developers look similar. Close up, they couldn’t be more different.