Although the original title is this meaning, but the actual content of the article, actually trying to say is that the developer was defeated by the software, a little title party’s meaning, the title I can’t translate, otherwise feel might be controversial, but I think original article, the author puts forward many ideas are good, so want to translation handling, if the infringement of the rights of the authors, Please inform me to delete it
The original linkSoftware development is a loser’s game | by The Hosk | Medium
Good code may not save you, but bad code can kill you #HoskWisdom
I’m not saying developers have failed, but most software developers haven’t conquered software development, they’ve been conquered by software development.
Developers struggle because they don’t know what game they’re playing and what the best tactics are to use.
You need to know what a game software development is and use effective game techniques to play it.
In the process of writing code, it doesn’t matter if the code is wrong, because it will always be wrong. It’s important to be aware of when the code is wrong and to fix it in the simplest way possible.
Winners and losers
In his article Loser’s Game, Charles Ellis pointed out that professional tennis is a winner’s Game, and the key is to attack actively to get high scores, while amateur tennis uses a different strategy, that is, to control the lost points, and then wait for the opponent to make mistakes and lose more points, so that the opponent can lose the Game and become the winner.
“In professional tennis, about 80 per cent of the points are won; In amateur tennis, about 80 percent of the points are lost. In other words, professional tennis is a game of winners — the ultimate outcome is determined by the actions of the winners — while amateur tennis is a game of losers — the ultimate outcome is determined by the actions of the losers. The two games are completely different in their basic characteristics. They are the opposite.” — Charles Ellis
Same game, but with a completely different gameplay and strategy
“Professional tennis is called the winner’s game. Victory depends on being aggressive and scoring more points than your opponent, not as we’ll talk about in a minute, what professional tennis is all about is focusing on scoring more points than your opponent, winning by being aggressive and scoring more points. Amateur tennis is almost completely different. Amateur tennis rarely takes the initiative and is always focused on losing fewer points. In a game like this, the winner gets a high score because the opponent loses too many points.” — Charles Ellis
Software development of games
I have been in software development for nearly 20 years, and I have been involved in numerous software development projects. In my personal experience, 80% of developers are amateurs and 20% are professionals.
Why do I say that?
Here are some things amateur software developers don’t like to do:
- Development standards
- Unit testing
- Design patterns/SOLID principles
- Learn and set DevOps and ALM
- Optimize the packaging build
- code review
- Code analysis/solution review
If you want to work with colleagues on the development team, chances are you won’t do any of these things, since most of the developers on the team are also non-professionals.
“He gives the initiative to his opponent, puts himself in a passive situation, tries to control the points he loses, and waits for his opponent to make a mistake to win the game, because he is an amateur, [and probably hasn’t read the book], so he doesn’t know he is playing a passive game.” — Charles Ellis
Most developers underestimate the importance of writing good code and overestimate their ability to develop software at work. They write code thinking that writing code is easy and that it will work the first time.
amateur
If most developers are amateurs, we should treat software development like an amateur game, and we should focus on reducing the mistakes that amateurs make.
The goal of the amateur developer is to make the code work, and other activities slow the process down. The steps above are designed to write simple code and quickly locate bugs, so that we can keep the speed and quality as high as possible. ALM/Devops allows for rapid error-free deployment, which leads to rapid feedback.
The best way to improve the efficiency of writing code is to focus on the quality of the code and reduce the number of bugs that may occur, rather than write code at a brutally fast rate.
The larger the project/development team, the more expensive it is to fix bugs, errors, and errors. The team’s problems will delay a lot of people’s time, and the best way to stop losses is to implement the above.
I have participated in some projects, which were eventually killed by numerous bugs. Many problems found in the later period caused user loss, and there were operational risks when going online.
reverse
If we treat software development like a professional game, we’re not writing code that works, we’re spending our time avoiding bad code and bugs.
“For people like us, it’s amazing to try to be consistent and not make mistakes, instead of trying to be very smart.” — Charles Ellis
Amateur developers believe that writing code quickly is the fastest way to get to production. In effect, large methods and complex code create a code base that grows in complexity, with each additional line of code making it harder to develop. This approach only works on small projects where one or two developers work.
The cost of mistakes
The further you go from finding a bug to writing it down, the harder it gets to fix it. For example, if you find a bug in the production environment, first figure out what it does, then rewrite its logic, then fix the problem, then deploy tests in each environment, and finally in production.
If you find a bug while unit testing, you can fix it quickly, reducing the impact on other developers and testers.
We can add simple steps in the development process to catch bugs, in order to avoid bugs affect the user experience, this is more effective.
As we all know, most development teams are mostly amateurs, and it’s easy to get caught up in a passive situation, where the team spends more time waiting for bugs to appear and fixing them later than it would be reasonable to assume that the members are professional developers.
Success for developers isn’t about getting the code right the first time, it’s about constantly making the code better.
Or to quote Charles Ellis
“The professionals win points and the amateurs lose points.”
Recommended reading
- How we try to speed up IT projects and why it doesn’t work
- Development can be torturous
- Why experienced developers are worth the money
- Why Code Readability is important
- One simple tip to improve your development and project estimates
- Code should be the one version of the truth, don’t add comments
I finally summarize the author’s argument that the code quality is very important, and we must learn to take the initiative to go to consciously control the quality of the code, test, when I was in the early days to avoid problems, may be on our side, of course, work environment, or most of the work environment, we may have no time, either or overwhelmed, Or some other factors, so that we can’t do what the author said, but I think, personally, I think there are three levels of writing code,Make it work,Make it right,Make it better, and a lot of times the difference between us and a lot of big guys. Personally, The reason is that the big guy always wants to Make it right and Make it better, while most of us stop at “Make it work” and “Make it right”. Of course, I think everyone has different job requirements and their own pursuit. As long as they are happy and can accept the reality, Yes, I’m just sharing my own opinion and welcome to a reasonable discussion.