So no matter if in soccer or in Python there are some principles you should follow to become successful. Of course, they don’t always fit 100% to every game and to every style of coding, but they can serve as a good reference point. But we should definetly take a look at them. We start with the Zen of Python.
The Zen of Python is a collection of 19 “guiding principles” for writing computer programs that influence the design of the Pythonprogramming language – Wikipedia.
Here we go:
- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
- Complex is better than complicated.
- Flat is better than nested.
- Sparse is better than dense.
- Readability counts.
- Special cases aren’t special enough to break the rules.
- Although practicality beats purity.
- Errors should never pass silently.
- Unless explicitly silenced.
- In the face of ambiguity, refuse the temptation to guess.
- There should be one—and preferably only one—obvious way to do it.
- Although that way may not be obvious at first unless you’re Dutch.
- Now is better than never.
- Although never is often better than right now.
- If the implementation is hard to explain, it’s a bad idea.
- If the implementation is easy to explain, it may be a good idea.
- Namespaces are one honking great idea—let’s do more of those!
I admit that they appear a bit too clever at the beginning, but they are important, so keep in mind to refer to them again and again during your work.
Do those concepts fit for soccer as well? Lets try:
- No, playing beautiful but losing every game is the last thing you should do in soccer.
- Yes, being explicit in Python means being concrete and specific instead of abstract and general. It also means not to hide the behavior of a function. In soccer the coach should explicitly tell you what to do and not give misunderstandable instructions too.
- Yes, playing simple when you can is a good idea.
- Yes, although complex and complicated sound alike, they do not mean the same in this context. It is okay to build very complex applications, as long as the need for it is reasonable. So in soccer you should play complex only if you need to as well.
- Yes, flat usually refers to how data is organized, but can also refer to things like if statements. Nested “ifs” are where you check one if, then inside that, check another if, etc. instead just check both variables. Same in soccer: flat play, high win.
- No, code that is spread out over multiple lines is often easier to read than dense one-liners. I can’t see a connection to soccer here.
- No, nobody cares about readability in soccer.
- Yes, don’t break the rules in soccer even if the game goes crazy.
- Yes, walking the line between number 8 and 9 becomes easier with experience. And in time, you’ll not only learn the rules, but also learn when to break them. I mean in soccer sometimes it is fair to operate on the edge you know. Imagine Diego Maradonna would have tell everybody that his goal with the hand against England 1986 during the world cup shouldn’t count. He was experienced enough to just keep silent, because he knew the positive implications.
- Yes, it’s better for a program to
fail fastand crash than to silence the error and continue running the program. The bugs that inevitably happen later on will be harder to debug since they are far removed from the original cause. In soccer that means better see and face the weaknesses of your team during the preparation phase then in the season.
- Yes, you can always choose to explicitly ignore the errors your programs cause, just be sure you are making the conscious choice to do so. Same in soccer. If you igonore something make sure you won’t regret it in the future. E.g. don’t ignore to train both feet, because there will be situations, where you have to shoot with the weaker one.
- Yes, if your code isn’t working, there is a reason and only careful, critical thinking will solve it. Same in soccer. If you loose 10 games in a row there seems to be a real challenge. Don’t just go in the 11th game and hope this time you are going to win without analyzing and solving the problems of the other games.
- No, in soccer you have many ways to score a goal and to win a game but they aren’t always obvious and unique.
- No, this line is a joke. Guido van Rossum, the creator and BDFL (Benevolent Dictator for Life) of Python, is Dutch. However, not even this aphorism prevented Python from incorporating three different ways of formatting strings. As a german I can’t comment anything realted to Dutch soccer here :-P.
- Yes, like Nike would say: Just do it.
- Yes, it’s almost certainly better to wait for your program to finish than to have it finish too early with incorrect results. So don’t go to a championsleague game unless you are not well enough prepaired as the result will not be good then.
- No, if a coach wants to implement a complex tactic it may need some time until the players internalise it but thats okay.
- No, thats not always right, sometimes you need a more complex system e.g. to play against Barcelona and to restrict their game and Leo Messi especially.
- No, as great as they are, namespaces should be made only to prevent naming conflicts, and not to add needless categorization. I don’t see a connection to soccer here.
Note: Some explanations of the principles come from https://inventwithpython.com/blog/2018/08/17/the-zen-of-python-explained/.