Highlight a Review of the Theme and Content of Communication Feedback

Key Points Recap: Review on the Theme of “Communication Feedback” #

Hello, I am Zheng Ye. Congratulations on completing another module of learning.

In the “Communication Feedback” module, I discussed with you some methods of dealing with people. However, this is not about traditional conversational skills. Instead, I hope you can overcome your psychological barriers, actively communicate with the real world, seek feedback, and continuously improve your ability to encode and decode information.

Key Review #

In this module, we have learned some best practices.

  • Kanban

    • A visual practice derived from Lean manufacturing.
    • Place tasks in stages.
    • Helps us discover problems.

  • Continuous Integration

    • The key to successful continuous integration is quick feedback.
    • Submit only after local checks pass.
    • Find effective ways of feedback, such as CI monitors.
    • Discipline of continuous integration.
      • Code can only be submitted when the CI server is in a green state.
      • When CI server detects an error, it should be fixed immediately.

  • Retrospective Meetings

    • A practice for software teams to review and reflect.
    • Enumerate focus points, prioritize them, discuss in depth, list action items, and assign responsibilities.

  • The 5 Whys

    • Another practice from Toyota.
    • Ask multiple questions along a main line.

In this module, we have also gained some important perspectives to improve our work.

  • Understanding Communication Feedback with Information Theory

  • Advanced Path for Writing Code

    • Write code that can run.
    • Write code that conforms to coding standards.
    • Write code that can be understood by people.
    • Write code using business language.

  • Meetings as a Heavyweight Communication Method

    • Reduce the number of attendees.
    • Have face-to-face communication with people.

  • Listening to the Voice of the User

    • Be your own user, and be your own user well.
    • Get close to the users.
    • If there are no users, create users.

  • Fail Fast

    • A principle of writing code.
    • Report errors as soon as they occur.

  • The Pyramid Principle

    • From central argument to sub-arguments, and then to supporting evidence.

Practical Guide #

In the “Communication and Feedback” module, I have also condensed each content into a practical guide sentence. Let’s review them together.

Additional Gains #

At the end of this module, I have also provided answers to some of the questions you may have encountered during your learning process. This will help you organize your thoughts and better understand the content you have learned:

  • Continuous Integration is a theme that can connect many practices together.

    • From Continuous Integration to a stable development branch, to frequent submissions, to small enough tasks, to task decomposition.
    • From Continuous Integration to checkability, to test protection network, to test coverage, to unit testing, to testable code, to software design.

  • Security check is a prerequisite for review meetings.

  • In terms of information acquisition, there is not much difference between domestic and foreign programmers. Expanding horizons and improving work habits are areas where domestic programmers urgently need to improve.

– “Answering Questions | Continuous Integration, a Theme that Connects Many Practices”

Selected Comments #

When it comes to regular review and identifying the root cause of the problem, students Xixi Fu and Kafka mentioned:

Regarding the review, Sun Taoran once said that if he had achieved anything, half of it should be attributed to the review. He proposed several steps for everyone to refer to. First, compare the gap between the actual results and the initial goals. Secondly, recreate the scene and review the various stages of the project. Then, analyze the gains and losses of each stage and find the causes of the problems. Finally, summarize the rules and turn them into their own skill accumulation, so that they can be avoided when encountered again.

Let me add one more point. The review materials should be documented in a knowledge base, so that both newcomers and those taking over the project can benefit from it and improve the organization’s capabilities. In addition, a good review requires an open culture, otherwise it may turn into blaming each other and lose its meaning.

In addition, students Xixi Fu and Kafka also shared methods to improve meeting efficiency:

Some other methods to improve meeting efficiency include preparing before the meeting, writing down your viewpoints, and sending them to the host. Also, using the Six Thinking Hats technique, discussing from similar thinking angles instead of everyone giving their opinions randomly. Furthermore, the host should control who can speak during each round and control the duration for each person. There are many methods, but in reality, there are always people who break the rules, especially when that person is the boss…

When discussing communication and feedback issues using information theory, student Yi integrated his knowledge and shared his experience:

Communication among different roles: overcoming contextual differences, decoding in sections, and detecting deviations early for feedback. Communication among the same role: same signals, varying decoding abilities, need a dominant person to control the breadth and depth of communication, stick to the main points and stop when appropriate. At this time, combining task decomposition with reverse sandbox deduction.

Regarding how to do a good review, student Like_jun mentioned:

The team should realize the importance of reviewing. - Let everyone deeply think about the problems encountered during the project operation. Only then can the review be done well.

When discussing knowledge output using the Pyramid Principle, student Y024 expanded on the basic principles of the Pyramid Principle, as follows:

The four basic principles of the Pyramid Principle are: “conclusion first” (expressing only one idea at a time and starting with it), “subordinating detail” (every idea at a higher level must summarize the ideas in the lower level), “grouping by similarity” (each group of ideas must belong to the same category), and “progressive logic” (ideas within each group must be arranged in logical order).

The first two characteristics are for the vertical structure, while the last two are for the horizontal structure. The above content is collected from Li Zhongqiu’s book “Structural Thinking”. Interested friends can take a look.

In addition, student Y024 also mentioned the exploration and attempts his team is making regarding meetings:

  1. One of the guiding principles of communication is that the fewer people, the better for synchronous communication (such as meetings). The more people involved, the better for asynchronous communication (such as email).

  2. Regarding meetings, let me share what we are currently exploring. - (a) Before each meeting, the meeting organizer creates a summary in a Shimo document using a “meeting record” template (we keep developing our own template): explaining the agenda and discussion topics in advance and notifying the attendees. During the meeting, the minutes are recorded in the same Shimo document to ensure that all notes and action plans are collected. If it is a related meeting, the last Shimo document related to it is used for additional content (to maintain consistency and completeness). - (b) Half-hour meetings are set to 25 minutes, and one-hour meetings are set to 50 minutes, leaving room for contingencies such as changing locations to ensure that no members are late for any meetings.

Regarding domain-driven design, student Xiaohaozi mentioned the importance of separating mutable and immutable items:

Domain-driven design is indeed a training to write appropriate code structures. Programmers tend to design code according to their own habits, that is, according to the logic of computer operation, which makes the code easily fall into an unmaintainable pit. It is important to communicate with users before starting to code, understand the concepts, processes, use cases, and special situations of the design. Another point I pay special attention to is the separation of mutable and immutable items, because our business scenarios require high scalability.

The more experienced programmers become, the more they can appreciate the importance of “getting close to customers”. Regarding this point, student David Mao mentioned:

I have been working in software testing for many years. I deeply realized the importance of listening to customers when I went to visit them with the sales team a few years ago. Customers focus on real needs, while many of the features thought up by product managers and developers are false needs.

Thank you for the wonderful comments from the students. In the next module, I will share with you the specific application of the principle “automation”.

Thank you for reading. If you find this article helpful, feel free to share it with your friends.