The original link
Moore’s Law also works indirectly for software development, with half of all knowledge expiring every 18 months. Some of my previous articles are out of date, so today we’re going to talk about a topic that won’t get out of date so easily — what do the ‘big boys’ in the industry think? What does a structured body of knowledge look like?
But be warned, this article is not that serious. If you want to learn more about this subject, you should read a few classic books.
From thinking frameworks to basic principles to specific best practices
A few days ago, I studied the “10X programmer work method”, “THE way of R & D efficiency to break the situation”, the content itself is very high quality needless to say, and what inspired me is their content organization. Take the 10X Programmer Work Act, which is organized like this:
This design allows us to intuitively grasp the main context of the course.
Thinking frame is the starting point of things, used to examine the goal, grasp the direction; The basic principle is the core guiding thought under the thinking frame; Finally, the concrete practice is carried out under the guidance of basic principles. The relationship between these three will be explained later.
In my opinion, this is a structured knowledge system. This method can help you build your own body of knowledge, cognitive model, and guide your actions. I hope this article can also give you some inspiration.
Thinking framework
The top frame of thought tends to be philosophical questions, the same three questions security guards ask you:
- Who are you?
- From?
- Where to go?
And a similar WWH:
- According to? → Purpose, idea
- What? → Definition, concept, phenomenon or outcome
- How? → Specific operation methods and measures
The framework of 10X Programmer Work is as follows:
This is a frame of thought that your teachers have taught you since elementary school and kindergarten, without much explanation. So the question is, have you formed the habit of thinking like this?
This framework, simple as it is, can be useful throughout life.
It can be the basis of any action. For example, I used this pattern in my previous article, “How to Look at New Technologies” :
- What the hell is this?
- Solve what problem?
- How did it work out? Thought → process → realization
Or the next time a product manager gives you a requirement, using this framework, you can ask him:
- According to? Why do I need this for this function? What value does it bring to the user? Or what does it bring to the company? → no value, there is no meaning to do
- WHAT & HOW? What kind of users will use this feature, in what scenarios will they use it, and how will they use it? Is this the only way to implement this feature? Are there any other plans? → can measure the function of whether there is serious thinking, is not their YY, is not reasonable
If the product can’t answer, sorry, go back and wait for the notification.
Happened recently hiring (resume hit come Y2FybmV5NTIwQGhvdG1haWwuY29t), according to the above, I may review your ‘sex’ (ali dialect, hearsay) :
- What level do you think you are at? What are the shortcomings?
- What are your goals? What kind of team would you like to join?
- What are your plans?
OK, here’s a thought question: If your boss was drawing a pie, what would you say to him?
The principle of
Then there are the ‘principles’ guided by the thinking framework. These principles are more specific than a framework for thinking. They are domain-specific guidelines and can be more useful when dealing with a domain-specific problem.
For example, the 10X Programmer At Work has four principles:
Because it is a paid column, so I do not reveal the plot, can see its introduction.
Other examples are familiar, such as the SOLID principles of object-oriented design:
- S Single function principle: The concept that an object should have only one single function
- O Open closed principle: the concept that the software body should be open for extension, but closed for modification.
- L Richter’s substitution principle: the concept that an object in a program should be substitutable by its subclasses without changing the correctness of the program.
- I Interface isolation principle: The concept that multiple specific client interfaces are better than one general-purpose interface
- D Dependency inversion principle: holds that a method should conform to the concept of “relying on an abstraction rather than an instance”. Dependency injection is an implementation of this principle.
Make the person of the object, see these principles can be like a few treasures, the small white that just enters the door may compare hard to understand. They are the treasures of past generations of fire shadow’s will to burn fire, not through the baptism of the battlefield understanding may not be so profound.
One principle that has been useful to me in my programming career is DRY(Don’t Repeat Yourself), because it’s much more understandable or practical than SOLID or KISS.
The DRY principle simply means identifying your duplicate code, thinking about it, and refactoring it.
If you get into the habit of programming this way, you’ll find that your code will naturally be better structured and will probably conform to some of the above principles (in fact, they are already intersecting and communicating).
In other words, you develop a taste for programming through deliberate practice on the DRY principle.
There are many similar ideas/principles, such as Unix philosophy, Windows philosophy, and some algorithmic ideas:
The image above has two eggs:
-
One is the very practical ‘advice’ from Ken Thompson(coauthor of Unix and Go) : “When in doubt, do it.” Just do it.
The Unix philosophy in one word is KISS(Keep It Simple, Stupid). In the age of ‘build rockets for interviews, screw for work’, many people tend to go overboard, complicate things, write fancy code, and do fancy features. The ancient philosophy of Unix taught us that simple is good, and good is simple.
-
The second one is written by myself. Although I read this book in college, I only idolized it at that time, but when I read it again after many years, I found that all these principles were on the top of my heart. I suddenly felt that I should frame these ‘philosophies’ and read them day and night. This is also the inspiration for this article.
Are these principles difficult for you? In fact, not difficult, a few words can be clear.
If you’ve been around for years, you can get back to basics. If you’re a newbie, you should recite it (just kidding), frame it, hang it in your living room, wallpaper it, make it a mouse pad, print it on your thermos…
Specific best practices
More specifically, this is a best practice/design pattern based on practice and guided by principles. Can be used to guide the solution of specific domain problems.
Again, take the 10X Programmer Work Act as an example. Its final knowledge structure is as follows:
The most familiar example is the object-oriented Design Pattern, which is at this level of knowledge:
Design patterns are concrete practices guided by SOLID principles.
It’s not that we just need to learn thinking frameworks and guidelines. Best practices have to be learned deliberately. The three levels complement each other, thus forming a relatively stable knowledge system:
-
Best practices are the product of thinking frameworks and guiding principles. Internalization and sublimation cannot be achieved by merely mastering the best practice and staying on the surface without exploring its inner thought. What if you’re lucky enough to be in a new world where there are no best practices or design patterns?
-
Ideas and principles cannot be separated from practice.
Best practices are usually derived from other people’s practices, and what can be reused can be reused, right? Best practices, codes, are for us standing on the shoulders of giants, shortcuts that allow us to take fewer detours.
Because everyone’s scenarios are so different, and other people’s practices may not necessarily suit you, or you may be ahead of the world, thinking from above is a useful guide to creating best practices.
In addition, practice also deepens our understanding of the ideas at the top.
-
Practice and thought are mutually verified.
Later, when you read and study some courses, you can pay attention to their organizational structure, to some extent, can reflect the author’s level.
It’s all the same. It’s all the same.
So, if you could pick one sentence to frame, what would it be?
Don’t talk to me about self, people, and…
Pick a line that has taught you a lot in software development, frame it and tell yourself/posterity, what would you choose?
Let me give you some examples:
-
KISS
-
DRY
-
SOLID
-
SPOT
-
17 Principles of Unix Philosophy
-
Three virtues of a programmer: laziness, impatience, and arrogance.
From Perl author Larry Wall, with related explanation:
- Laziness is a quality that makes you work hard to avoid excessive energy expenditure, urges you to write energy-saving programs that others can take advantage of, and you write well-documented ways to avoid questions.
- Impatience is the kind of anger you feel when a computer is lazy. It will force you to write programs that exceed expectations, not just respond to requirements.
- Arrogant, supremely confident, writing (or maintaining) programs that others can’t find fault with.
– Larry Wall
I’m not kidding. It’s a virtue. If you have a few more of these programmers around, you don’t need 996.
-
Stay hungry, Stay foolish —— Steve Jobs
-
Talk is cheap. Show me the code —— Linus Torvalds
-
.
This article mentions & extends reading
Unix Programming Philosophy
10X Programmer at Work
Design Patterns
Still do not understand this eight algorithm thought, brush again many questions also useless!
Learn an algorithm, have threefold realm
What algorithms must a programmer know?
Talk is not cheap
10X Programmer at Work
How to Break the Ice in R&D Efficiency