The thing is, as an engineer, especially a full-stack engineer, you often have to deal with the reality that one person has to take care of many things.

Any project will become more and more complex, detailed and large over time. This is especially true in programming where pure intelligence is concentrated.

○ Background

Recently, there is a popular word in the circle: “shit mountain”. It may sound inelegant, but it is a vivid metaphor for a project with various drawbacks such as complexity, obscurity and disorganization as development progresses.

This is the kind of project that no developer wants to touch or change. As the name suggests, avoid it.

The only solution to the mountain of shit is to start from scratch and start a new project (even if the new project may grow into a new mountain of shit).

Mature developers usually have a certain level of code cleanliness and can do their best to avoid the “shit mountain” fate. However, when the size of the project grows, even people who are obsessed with cleanliness will be dizzy by all kinds of logic.

Whether it is a beginner or a senior developer, I believe that many people have such experience. On the first day I wrote the code myself, and on the second day I read it again, I began to feel dizzy, and on the third day I had difficulty understanding it. After sitting for a week, I had no idea what I was writing. If you leave it for more than half a month, you may not even want to touch it.

Often, even during a meal, the logical operation in my mind is completely disrupted.

It has to do with the way programmers work. Intellectual output requires the brain to engage in deep thinking, and high quality and efficient output requires intense concentration. In this state, the perception of the outside world and time is diminished, a condition known as “self-absorption” (see flow theory).

Most of our daily lives don’t require this kind of near – to – the – end mental dive, but a programmer’s job requires a brain to get into gear quickly.

But getting in the zone is not enough. The goal of deep thinking is to write logic in code, and the problem is: where does the logic come from, and how can you quickly assimilate it into your brain?

Where does “logic” come from?

First, development doesn’t happen all at once, in weeks or decades. And humans forget, and programs written today, especially complex algorithms, can get dumbfounded after a while. This requires us to be able to reload/pick up the previous logic and state in the document or code.

In teamwork, you need to understand what other people’s code means. In personal development, you need to know what you wrote before.

Behind the code, or documentation, is the logic.

Accurate understanding is the basic requirement, and the real production and development is a project, the pursuit of high efficiency requires rapid and accurate understanding.

If you think of your brain as a computer, to get into a deep state quickly, you need to have a good cache, fast reads and writes, and a lot of capacity.

Because deep thinking involves so many branches of logic at once, the brain can be overloaded.

As we all know, the read and write speed and capacity of the computer cache directly determine the performance. The same is true of the human brain.

From the perspective of “logic” cohesion, we can simply think of programming as the work of the preceding logic, plus its own output, output to the subsequent use. Just like building a house, learn about the previous states and add new ones for the future to build on.

But the so-called bricks and tiles here, embodied as code, is essentially logic. Also known as “moving bricks”, moving bricks produced in your own or someone else’s brain.

What determines the read/write speed?

The speed of reading and writing is actually the speed of understanding.

In the face of documents and codes, first understand the literal meaning, thoroughly digest and absorb it, then transform it into abstract logic, then process and produce the logic, then transform it into codes and documents, and then output it to future self or other team collaborators.

As a simple illustration, the further down you go, the more energy and brainpower you use up across layers.

That’s why “shit mountain” is so obnoxious, because it’s trying to absorb a bunch of incomprehensible, convoluted code. It is not easy to read, and the logic is not smooth, not clear, not coherent, and the operation efficiency is low. Very unfriendly to programmers looking for an intracranial orgasm.

So there are always programmers who call each other’s code “shit.” That’s what they’re talking about.

Elegant code always feels like a breeze.

There are several time-tested ways to improve comprehension, such as good code writing style, clean interface design, and so on. Common methodologies include hump naming.

Also, write documentation and comments that explain what a key line of code does.

Standard formats, common rules, and systematic language can help reduce the cost of understanding.

③ The objective environment in which developers work

Objectively speaking, the state of “understanding” itself is closely related to various circumstances.

Recently there was an obvious discovery. When the project was large, I programmed myself for two hours, with one hour spent understanding and recalling the code I had written before. When it comes to the core coding process, it takes less than half an hour at most. As the number of codes increases, there is a positive correlation between the difficulty of understanding and the time required.

Not to mention, for the vast majority of developers, it’s often disrupted by outside noise or light or trivial things. It takes a lot of energy to get into the zone, only to be called off to do other things, and to jump repeatedly in the middle of deep thinking.

I suddenly understood why I had seen the author recommend reading “The Self-improvement of An Actor” in a professional book. The process of a programmer entering the logical world is like that of an actor entering the emotional world. Try calling out an actor as soon as he gets into character. It will be very difficult to get back into character.

In the same way as programmers, constant interruptions can be spiritually destructive.

That’s why almost all programmers are so productive late at night, because there are so few blocks of uninterrupted, quiet time to work and be completely immersed in the process of coding.

One day a week when you can completely focus on a few key issues is bliss for any developer.

(So love the programmer, and don’t freak him out.)

Since the environment is not so controllable, we return to logic itself from the most essential point of view of how humans understand the problem.

④ “Logical visualization”

While the wheels are self-built and coded as elegantly as possible, it’s hard not to get stuck again with some complications. Cognitive psychology tells us that humans understand images much faster than text. So using images to describe logic is a very effective way.

To sum up a lot of background and current conditions, this naturally leads to a concept: logical visualization.

Common flowcharts, for example, are one of them.

Fortunately, with the long development of engineering, some methodologies and effective logic tools have been developed. The most famous one, which is used by almost all professionals, is UML (Unified Modeling Language).

Modeling, it should be noted, does not refer to the construction of spatial models at the physical level, but can refer to the construction of entities in any design or concept, which can be called modeling. Mathematical models, computational models, software models, and so on.

UML is a language, which means it has a systematic methodology for describing problems. And the concrete carrier form that carries this language is graph. In another word, icon.

This Bridges the gap between logic, visualization, and production requirements.

UML is a required course in many universities.

The generalized UML can refer to all process logic and flow. But now, it must be inseparable from the product of an object-oriented design method.

This brings us to its disadvantages. It is also where I personally encounter the chicken ribs in the current development process.

⑤ Some of the UML is at a loss

First, UML is a document-driven modeling language

I believe that when it comes to document-driven, the first response must be the waterfall model. With the rapid iteration of product requirements and the rise of agile development, UML, a formal and old-fashioned way of development, cannot respond to changing requirements. It has even become a stumbling block to the development schedule.

The most traditional engineering mindset, modeling first and developing from the model later, has fallen behind. Therefore, at present, its driving effect is gradually weakened, and I personally prefer to use it as an inductive sorting tool for software implementation logic.

Second, UML is object-oriented

Although we want to tidy up the logical structure, the core idea of use-case diagrams, sequence diagrams, swim-lane diagrams, class diagrams, and various other diagrams is to treat the operation as the behavior and interaction of objects.

With an object-oriented approach, it is difficult to render the process-oriented part. However, the process-oriented thinking of pure flow chart description is too fine and granular, and UML seems to be too top-level to find a suitable way to describe objects and processes.

For example, I want to describe the nesting of a function implementation. There is no such thing as a “function diagram” in UML, and there is no need to lay out nesting relationships completely in flowcharts.

Integrated ides today have many tools for plotting backward code, such as the Show Diagram in PyCharm, the CallGraph in Profile, and the PyCallGraph based on Graphviz.

Although you can automate the generation of class diagrams or function diagrams or call relationships to a certain extent. However, the three always have their own shortages, such as no interface IO, or no parameter description, or granularity is not controllable, and very limited functionality. In short, each one feels short weight.

If all the details of CS are abstracted into a model to describe, it actually looks like the following:

Three big pieces: an input, an output, a processing module in the middle

Any function or algorithm or module is built according to this model.

In fact, this way of connecting logical nodes, describing functional structures, is effective and even efficient.

⑥ Some enlightenment of hardware development

If you’re familiar with or have heard of Unreal Engine, Blender, or Da Vinci, the way they operate is node logic. Input at one end, output at the other, and various iterations are strung together to achieve the final result, even with a hint of the recent craze for low code.

But if you look closely at this picture, you’ll see that this pattern is something you’ve seen before.

Yes, that’s right. In order to visualize the logic more easily, I went to Quartus II, which draws circuit diagrams.

Unexpectedly, hardware development methods are very useful in software development.

In hardware development, inputs and outputs are often represented by pins, and more generally, for ease of understanding and good practice: inputs are represented on the left, outputs are represented on the right.

And how the hardware accessories that the graphics represent are implemented internally are encapsulated.

In addition, the use of modular collocation, also perfect to meet the code reuse, reduce repeated labor. Whichever way you look at it, this visualization is perfect for our needs.

Thus, we found a way to solve the shortcomings of UML and flow chart, which is also an efficient way of logical visualization.

⑦ Advanced use of DRAWIo

Now that the theoretical tool has been found, what to draw it with?

  • IBM’s Rational Rose, while well versed in UML, was too old and did not run on many of the new systems.

  • Quartus II only focuses on hardware design, but has no way to start with classes, functions, interfaces and processes at the software level.

  • Pure drawing software such as Adobe Photoshop or Illustrator is too broad.

After trying out countless tools, I recommend drawio, an open source process drawing tool.

Built-in integration of many areas of graphic elements, and even can draw product interfaces, prototypes, UI and so on.

It is XML-based and SVG homologous, which means it can run on the Web. You can also export to any format you want.

One native advantage of being based on XML is that you can customize graphics.

In practice, if some special graphics or graphics ICONS that fit my personal habits do not exist, I can choose custom graphics and save them as my own graphics library.

Its syntax format is also very easy to understand, the core of the three components:


  • represents the connection point


  • Draw the icon background layer (easy to make shadow styles, etc.)


  • Draw the foreground layer (e.g. text description, graph, etc.)

* For example

A function icon for matrix multiplication is designed. The left side represents the input of two matrices and the right side outputs the result

The style is shown as follows:

The code behind it is simple:

<shape aspect="variable" h="60" name="Inverter 2" strokewidth="inherit" w="100">
  <connections>
    <constraint name="in" perimeter="0" x="0" y="0.33333" />
    <constraint name="in" perimeter="0" x="0" y="0.66666" />
    <constraint name="out" perimeter="0" x="1" y="0.5" />
  </connections>
  <background>
    <path>
      <move x="0" y="20" />
      <line x="20" y="20" />
      <move x="0" y="40" />
      <line x="20" y="40" />
    </path>
  </background>
  <foreground>
    <fillstroke />
    <path>
      <move x="77" y="30" />
      <line x="97" y="30" />
    </path>
    <fillstroke />
    <path>
      <move x="80" y="30" />
      <line x="20" y="60" />
      <line x="20" y="0" />
      <close />
    </path>
    <fillstroke />
    <fontcolor color="#FFFFFF" />
    <text align="left" str="m1:dict" valign="bottom" x="22" y="22" />
    <text align="left" str="m2:dict" valign="bottom" x="22" y="42" />
    <text align="left" str="m_result:dict" valign="bottom" x="80" y="28" />
  </foreground>
</shape>
Copy the code

Specific custom method can directly see the official document: www.diagrams.net/doc/faq/sha…

The structure of a software like building blocks or puzzles, it is very convenient to grasp the current development progress and logical nodes at a glance. Clearly see the logic, if it is a mess, but also very clear what is called “shit mountain” (not).

To sum up, as a personal experience method, I would like to share with you, hoping to help those in need.

Or if there is a better way, welcome to discuss.

Happy New Year to everyone ❤