Preface:

If you are a programmer who is not satisfied with drawing your own technical diagrams, check out this article.

When WRITING technical articles, I often get comments from readers asking what tools I use to draw. In fact, I think they probably asked the wrong question, because I have tried different drawing tools to draw good pictures, but in the end, it is not the tool that can draw good pictures.

Why?

Programmers write code. Why do they draw? Many programmers think that writing good code is good, but drawing good graphics is no good. Programmers become architects after every day easel composition, become the so-called PPT architect? These questions puzzled me a few years ago.

In an article titled “The Essence of Architecture in the Eyes of the Chief Architect… I mentioned an architect competency model (figure below). Based on my own experience, this competency model is quite suitable for the architect position.

Review images

A programmer works on many projects, writes code for many years and grows into an excellent programmer. As you can see from the capability chart above, a good programmer is far from being an architect in many other ways. We used to think that a programmer would naturally become an architect if he gained enough experience. However, architect is not a continuation of the natural growth of programmers. It is just that the work of architect is closer to programmer and technology than management, so we have the illusion of it. The constant cultivation and excellence of the “great programmer” territory will make you a technical expert in that vertical, which is the natural continuation of the programmer’s growth.

Thus, when a programmer is good enough to grow as an architect, he needs to look at other aspects of the capability model. In my opinion, mastering drawing techniques is helpful for abstract thinking, communication, balance and seeing through problems. As for multi-domain knowledge and technical foresight, it does seem that the correlation with drawing is not strong, but if multi-domain knowledge is not limited to procedural technology, drawing can be considered as a domain of knowledge.

We all use map software today, a country, a city, a neighborhood, and map software always shows the map in different abstract dimensions. For a complex software system, it also needs similar different abstract dimensions, the overall picture of the system, the association and interaction between different subsystems, the interfaces and calls between subsystems’ internal modules, and the processing flow of a certain key implementation point. An architect should be able to draw a clear picture of a system or parts of a system on these different dimensions of abstraction.

When important aspects of the system are described in different abstract dimensions, we can better discover and find the crux of the system. If solving a problem with a system is like going through a maze, do you dive in and try and find your way out, or do you look down at the maze in a higher dimension and find the best way to solve the problem? This is the manifestation of seeing one aspect of the essential domain through problems.

As the saying goes about communication, a picture is a truth, and no, a picture is worth a thousand words. Some programmers write a lot of technical documentation, and sometimes it’s not as clear as a clear architecture or interaction diagram. When you have an abstract, comprehensive, multidimensional presentation of the system, clear, accurate communication, and the essence of the problem, then the right and appropriate balance is not so difficult, right?

How to?

In the last video we looked at what benefits do you get from drawing a good picture, but in this video we’re going to look at how do you draw a good picture? What special drawing knowledge and skills are required to draw a clear and understandable illustration of the technical architecture or interaction flow? Also, does it take a lot of time to draw a good picture?

Over the past few years on how to draw flush out this subject I made many attempts and practice, to achieve efficiency (drawing shouldn’t take more than more than with words to describe the same content) and effect (legend expression effect should be better than text description) of the balance, gained in the process the following some basic practices of cognitive and feel good.

graphics

When I draw technical legends, I only use some basic graphics, such as rectangle, circle, triangle, diamond, bubble and arrow. Almost all drawing software comes with these basic graphics, so the dependence of tools is very low, but the selection efficiency is very high. Of course, in order to express the interaction with some famous external systems, these famous external systems may have their own famous Logo icon, and will directly use their Logo icon.

Here are some of the graphic elements I use to draw.

Review images

color

Sometimes the composition of the system is so complex that only basic graphics are not enough to represent all the different components of the system, and color is needed to distinguish them. So the next question is, what colors should I use? My answer is to use colors that most people find beautiful. What color do most people like? Of course I didn’t do any research. It was all my head. I think most people find the rainbow beautiful, so I usually use the seven colors of the rainbow plus two classic colors: black and white. So you have nine colors plus a few basic shapes, and you can combine dozens of graphic elements to represent different components, which is pretty much enough.

The seven colors of the rainbow include red, orange, yellow, green, cyan, blue and purple. Designing with the Mind in Mind, a book about color Designing, provides these guidelines for Designing with the Mind in Mind:

  • Use saturation, brightness, and hue to differentiate colors and ensure high contrast, as human vision is optimized for edge contrast.

  • Use unique colors, because colors that are easiest to distinguish include red, green, yellow, blue, white, and black.

  • Avoid color pairs that are indistinguishable to color blindness, such as dark red-black, dark red-dark green, blue-purple, and light green-white.

  • The use of cues other than color is friendly to people with color vision impairment and also enhances understandability.

  • Avoid strong opposing colors, such as red and black, yellow and black

So you see why the traffic lights are: red, yellow and green. Why Jobs chose these three colors as buttons for all application forms in The Mac OS X operating system is also in accordance with the principles of human visual cognition. Therefore, I prefer white background, black characters, black lines and color blocks: red, green, yellow and blue. Only when it is not enough, will I choose orange, blue and purple.

Of course there are different kinds of red, different kinds of green, which one do I use? Take a look at the figure below, which gives the RGB color matching values (don’t trust your eyes, the effect can vary on different monitors, as a programmer needs to be precise). Why that is, I’ll talk about that later.

Review images

aesthetic

In addition to basic graphics and color choices, another concern is aesthetic. The aesthetic has a lot to do with the final look, thanks to Jonathan Ive, apple’s chief designer, for bringing the general aesthetic into the flat era, so I actually just flattened the graphics, took away the dimensions, the shadows and everything, and it looked fine.

Review images

Geometry?

We talked about how, let’s move on to geometry. This “geometry” is not the geometry of mathematics, but once upon a time, what we thought was troublesome turned out to be so simple. How much does it cost to master drawing techniques? How much is it worth?

Three years ago, the technical diagram I drew (from a previous shared PPT) was like the following. I always felt bad and was not satisfied with it, but I didn’t know what was wrong and how to improve it. At the beginning, I used Viso to draw pictures. Later, I tried OmniGraffle, a professional drawing tool under Mac. I thought it was too complicated and then I found an online drawing website called Draw. IO. And then when I had to do some Slide presentations, I used the Mac Keynote (the equivalent of POWERPOINT in Win), and when I needed to draw the technical illustration, I thought it would be easiest to draw it directly in the Keynote, so I started to draw it in Keynote.

Review images

Earlier, when I wrote the color selection, I mentioned why I chose this red over some other red, and that’s actually the palette palette selection that Keynote provides by default on a white background. As a programmer providing a default parameter to a piece of software, it is generally thought that this parameter is probably optimal in most scenarios. So I tend to think that the default color blocks in Keynote are some of the best solid color options for this background, and I still feel good about it to my naked eye, which saves opening up a more advanced color parameter screen, and makes drawing more efficient and less costly. So as a guideline, redrawing the above technical illustration will look something like this. It will take no more time than drawing the above illustration, but it will feel much better.

Review images

So, learn to use a simple software, using simple graphics and color matching, in the most efficient circumstances to draw a good effect of the legend, is also very valuable. Of course, many programmers assume that only the code they write is valuable, but this ignores what most programmers agree is true: code is written for people. Programmers don’t think that a piece of code that runs on a machine and is hard to understand is good code, but drawing it helps you think about how the code is organized and presented.

This article only introduces a technique of drawing a simple technical legend, after all, we draw only for the pursuit of explaining a technology or showing a system, do not need to consider any extra artistic. Lowest cost, still good effect, in efficiency and effect to achieve the most cost-effective balance.

.

The nature and habits of programmers focus more on implementation than presentation, and sometimes the smell of wine is afraid of alley deep ah, let alone not necessarily Maotai.

Review images