What You Need To Know About Bad Developers: The Secrets They Keep
Software development needs wild west wizards!
Every day, cowboy developers create awful software in the software development field.
The big question is, how do awful programmers keep getting jobs?
No one would hire them if their work was poor or their talents were lacking.
There are two ways to developing a software design: one is to make it so simple that there are no obvious mistakes, and the other is to make it so complex that there are no obvious mistakes.
The first option is far harder. Hoare, C. A. R.
The software development industry seeks cowboy developers that work quickly and produce low-quality code.
Most managers and projects value speed over quality.
Gresham’s Law explains why bad developers dominate good developers and why developers write low-quality code.
Managers want cheaper developers who can offer lightning-fast code/software.
Companies are hired to create software, not to create high-quality software.
How do cowboy developers survive?
Cowboy developers are developers whose code and software are poor yet give the impression of being skilled.
They cut shortcuts; the job seems to be OK from a distance, but upon closer look, it is a low-quality mess.
Cowboy developers are like cowboy builders in that the quality of their work is only obvious after a while.
At first look, the work looks to be fine, but time exposes the truth about the quality of the job and the skill of the person who did it.
Only a long-time view shows which developers are outstanding and which are bad.
The Principle of the Cowboy Developer Gap
The Development world wants cowboys
Developers who deliver story points and no one monitors code quality look excellent on sprint reports.
Most projects value speed over quality.
There is no benefit or motivation for software developers to write high-quality code.
If poor code is rewarded the same as good code, the bad code will come out on top of the good code.
Why would developers spend extra time producing quality code if managers/projects are prepared to accept awful code?
Developers, like other people, will follow the route of the shortest distance and write the minimum amount of code.
Projects want cowboy developers to be rewarded for creating low-quality code.
Code bugs & technical debt
So much software complexity comes from trying to have one thing perform two things — Ryan Singer
Standards, best practices, and processes are developed by excellent software development teams.
These are enforced by code reviews since avoiding technical debt is easier than fixing it.
How can you hide errors and bad code? You make the code so complex that it is hard to code review.
Most senior developers don’t have much time for code reviews. The primary distraction will be a code review.
Complex code is difficult to understand and much more difficult to review rapidly.
The Progress Illusion
Cowboy developers make good progress at the beginning of a project because it is easy at the beginning.
Technical debt rises over time. Before technical debt slows down the development team, there is a delay.
For three months, a good development team and an awful development team both produced code/software at the same rate.
After 2 or 3 months, the awful development team will slow down due to technological debt.
Cowboy developers use agile development as a blunt force technique. Making a mistake in software supports users to tell you what's wrong, and then make changes that bring the program closer to the needed software.
Knowledge vs. skills vs. experience
Bad developers might be difficult to spot by looking at their CVs and speaking with them since they can sound just like skilled devs.
It’s simple to look updated. You can study some articles and gain a high degree of knowledge so that you know when and where to use specific technology.
In most cases, knowledge tells you what to do.
Development skills get better by performing something and practicing.
Like creating code, managing people, playing tennis, or playing an instrument.
You have to combine knowledge with practice. Practice helps to improve a skill by offering feedback and understanding what works and what doesn’t.
Bad developers have enough knowledge to look like they know what they’re doing, as well as the skills and knowledge to carry out it badly.
Learning from what works and what doesn’t (mistakes) is what experience is all about.
Experience gives people confidence since it is based on doing something similar before and avoiding past errors.
Surrounded by idiot
I try to figure out if I am a fool or an expert in an area.
It is not the person who is an idiot or an expert, but rather their knowledge, abilities, and experience.
An expert in one area and an overconfident idiot in another.
What are the facts (experience, some knowledge) on which the view is based if you take the opinion, reputation, and confidence?
I want to listen to experts, ask questions, and get advice when I am an idiot.
I wish to avoid and challenge other people’s opinions, thoughts, and judgments when they are fools.
This is dubbed as credibility by Ray Dalio. Is the guy trustworthy?
Have they ever done something like this before? Are they knowledgeable about this?
Cowboy developers rarely stop to think about their beliefs and views. It’s just another thing that would slow them down.
Leaving so soon? Why not leave a $1 coffee for my work?
