Updated: Mar 23, 2021
Brent Eviston has a book coming out, and I'm looking forward to it. I think this book is the drawing method he has been showing on his Udemy course. His methodology makes sense, and you don't get lost when studying it.
The drawing method he teaches is described in five steps
1) Think about what is the biggest part.
2) Think about what the base of that biggest part is.
3) Think about how big the part you want to draw is.
4) Think about which part of the paper you want to draw it on.
5) After you have drawn it, think about what changes you need to make.
In the fifth step, making changes means referring to what you have already drawn and finding lines that can be improved upon. When you learn to draw in his way, you rarely use an eraser because you draw a thin line, and then you find a line that you can improve. The reason is that he draws a thin line, and then he draws a better line on top of it, bit by bit, with a darker line. In other words, you make mistakes early on, and from those mistakes, you make new and better lines. In a previous blog, I wrote about how drawing without using an eraser is the same process that we use in our projects and how we talk about what mistakes to make and at what stage.
And as I started to study programming again, because I was going to start blockchain, I realized that some things go hand in hand with programming. It's not mentioned, but there is something called simplification in the process of 1 to 3. Yesterday, I wrote about simplification and exaggeration, but before exaggeration, simplification is necessary. Every shape is simplified to one of three objects in a three-dimensional drawing: a sphere, a cylinder or a box. After drawing the arms and legs many more times, they become patterned in the brain, just as Fabian is writing about today.
I thought it was similar to design patterns, especially those used in object-oriented programming. One of the basic concepts of object-oriented programming is "trust the code that has been created in the past and don't code same ones again and again". In other words, "don't invent the wheel twice". In the drawing, if you make a design pattern of the process from 1 to 3, you will draw faster and faster.
I thought this idea of design patterns is similar to the business process of finding winning patterns.
I read the original version of this object-oriented design pattern book about 15 years ago. I read the original version of this book about 15 years ago, and a new version was released last year, so I think it's a very popular and long-lasting book. It is also an object-oriented approach that is still popular more than 15 years after the first edition was released. I've found it to be a very versatile concept, even outside of programming.