Pulling a rabbit out of a hat is great if you're a magician but almost completely useless if you are a software developer

When you don’t understand how code, software or services work, they seem powered by magic.

When you don’t understand why best practices are best practices, you haven’t mastered your profession. Software Developers Need a Professionals Mindset or They End Up an Amateur

Junior developers think they know what they are doing because they don’t realise the complexity and skill of software development. The Difference Between Junior Developers and Senior Developers

Developers should aim to build knowledge, skill and experience to help understand their environment, avoid mistakes and build software. If you take every opportunity to build knowledge and understanding you increase your chances of avoiding problems.

Developers who try to go fast, skip the learning will be faced with situations they don’t understand. When you don’t understand what to do, instead of relying on your skills, knowledge and ideas you are are left with trial, error and luck.

Junior developers haven’t had the opportunity to learn yet and regularly face situations they haven’t experienced. Experienced developers who choose not to learn, are choosing to be at junior developer level.

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

Turtles all the way down

Turtles all the way down, is based on the idea that the world is flat and resting on a large turtle. What is the turtle resting on you ask? it’s turtles all the way down, which continue indefinitely.

The linguist John R. Ross on Wiki also associates James with the phrase:

The following anecdote is told of William James. […] After a lecture on cosmology and the structure of the solar system, James was accosted by a little old lady.

“Your theory that the sun is the centre of the solar system, and the earth is a ball which rotates around it has a very convincing ring to it, Mr. James, but it’s wrong. I’ve got a better theory,” said the little old lady.

“And what is that, madam?” inquired James politely.

“That we live on a crust of earth which is on the back of a giant turtle.”

Not wishing to demolish this absurd little theory by bringing to bear the masses of scientific evidence he had at his command, James decided to gently dissuade his opponent by making her see some of the inadequacies of her position.

“If your theory is correct, madam,” he asked, “what does this turtle stand on?”

“You’re a very clever man, Mr. James, and that’s a very good question,” replied the little old lady, “but I have an answer to it. And it’s this: The first turtle stands on the back of a second, far larger, turtle, who stands directly under him.”

“But what does this second turtle stand on?” persisted James patiently.

To this, the little old lady crowed triumphantly,

“It’s no use, Mr. James — it’s turtles all the way down.”

— J. R. Ross, Constraints on Variables in Syntax, 1967

Developers who believe in a flat earth

Bad developers are like people who lived during the middle ages. They believe in magic. Their knowledge can not explain things that happen in the world, instead they assume those actions are magic.

They have decided it’s not worth the effort to understand best practices, software, services, etc. They put in minimal effort and understand things from a black box perspective and how they work.

This is choosing to operate with a black box mindset. Understand how things work through trial and error, not logic and reasoning.

They solve problems now; they learn to fix only the current issue. When a similar issue occurs, they have no additional knowledge because they do not understand.

Copy and paste developers

When you get a copy and paste solution, you get the solution without the understanding. It's the understanding that helps you in the future.

Good developers learn to understand, bad developers get the solution for now and skip the learning.

If you copy and paste a solution and skip the learning, you gain a brittle solution and knowledge. The brittle solution doesn’t bend when the environment changes, it breaks. The copy and paste developers don’t have the knowledge to adapt the solution or create a new one.

When you believe in magic, you paint yourself as the brave hero fighting dragons, demons and monsters. Many heroes get eaten because they are stupid enough to keep fighting dragons.

To believe in magic is to reject science, logic and the belief you can explain everything.

Dynamics 365 and C#

This lack of knowledge, understanding,experience is evident not only in bad developers but in developers put into roles that require skills they don’t have.

Managers believe developers are the same and are interchangeable. I see this with C# developers brought onto Dynamics projects. They don’t have Dynamics knowledge, make rookie mistakes, write code where there is out of the box functionality and get stuck.

They view Dynamics 365/Power Platform as a fixed thing they have to work with, not something they can configure and mould to do what they need.#

Why .NET-C# developers struggle with Dynamics 365 Development

Passive Thinking

It’s dangerous to think the world might attack you, you sacrifice control and are at the mercy of the environment.

Developers who believe in the will of god and magic let the development environment happen to them.

In the book The Biggest Bluff: How I Learned to Pay Attention, Take Control and Master the Odds: How I Learned to Pay Attention, Master Myself, and Win discusses how her mentor warned her about her language and thinking

“Erik will pull me aside in a big tournament and tell me he’s worried about my thinking. I’m describing things as happening to me rather than taking responsibility for my actions. If I don’t stop, I’m not long for this event.”— Maria Konnikova

Good developers understand how services, software, Devops and systems work. They understand how they work and the logic behind this. Good developers know there is a probability of technology break, then we need to prepare.

You can’t stop servers breaking, mistakes happening, environments blowing up or developers creating bugs. You can’t stop it but you can prepare, therefore we have

• DevOps
• Source control
• Code review
• Unit test

Technical Disasters don’t Catch good Developers Unprepared they understand their environment, what is in their control and prepare for what isn’t. It’s isn’t stopping bad things happening but understanding them so you are prepared and can recover quickly.

Rejection of best practices

Bad developers avoid best practices because learning them has no immediate benefit. Best practices around designing code, principles, Devops, unit testing all have long-term benefits.

In the short-term they have negative consequences because it takes longer to write quality code.

The best developers are curious, the value isn’t in just following the best practice, the value is understanding the best practice and why it’s a best practice.

Ignorant of ignorance

Bad developers don’t know they are bad developers and their opinion of their skills is greatly exaggerated.

To believe in magic when creating software, you do not believe in software engineering, best practices and logic. Bad developers don’t know what they don’t know. Not understanding the skills of software development helps them to assume they are talented developers.

Lack of knowledge

Bad developers have a mindset of doing as little and learning as little to get by. This is short-term thinking and these developers never get ahead.

Copy and paste solutions can stop working and cannot work when the environment changes.

Not learning the logic behind services, frameworks, process and software means it's difficult to bug fix and work out problems on their own. They view things as black boxes and powered by magic. The result is they get stuck, with none of their own ideas on how to fix the problem.

When you ask a bad developer how DevOps works, it’s built on an infinite layers of turtles and powered by lemon sherberts.

The Best Decisions in Software Development Have Long-Term Benefits Not Immediate Benefits