2 articles in one day? To be fair, this one is less technical and more...feelsy.
I will preface this with 2 things: I'm a failed artist and a newbie coder. And yes, coding is art, but it is a different kind of art than the work I've done and I wanted to share some of my thoughts about it all. Maybe one day this will all change and I'll hate coding and not want it as a job, but as of right now I am enamored with it, and this will give some insight into why.
Isolation vs Collaboration
What I didn't know about coding before I got into it was how much people work there was. I will get into more details about it in other sections, but even if you jam with friends and try and gather inspiration, at the end of the day it's you and your canvas. It's rare that artists actually fully participate in each other's psychical work outside of mental stimulation. It's common to get critiqued and red lined, but in the end you are the only one working on your work of art. Asking someone to help you with part of it is seen as a failure on your part, even if they are better at it than you, and you might be able to make something even greater with both of your specific skills. With code, from what I understand, this kind of collaboration is encouraged and at times mandatory. I can say the comics industry probably has it closer, in that people are sketcher, liners, colorists, and work together to make an end product, and I find that kind of teamwork both fascinating and freeing. You are not as expected to be a...
Superstar vs Teamplayer
What is a superstar? That is the end goal of freelance illustration. You want to be a name, and you have a brand and a style that should be yours and yours alone. People come to you because of your look that only you can do and the easier someone can work in your style the harder time you're going to have. A coding guru on the other hand, is not someone who does one thing really well, but does a lot of things proficiently. While still mixed up with being a "wizard" who should be able to do everything themselves, their skills are most valued when they can integrate with another's style.
Style vs Adaptation
Cribbing someone else's style is the worst thing you can do as an illustrator, even if it's a great style of a master. Conforming to a coding style and directly learning and implementing from great code is just common sense here. I'm actually quite good at mimicry, but illustration is about being a super unique star, so that doesn't really help me there. Being able to add something to someone's art in their own style isn't as helpful as being able to add to working code in the proper guidelines. Open source encourages collaboration and adaptation, and the fact that most of this is free is absolutely amazing!
Reusability and Plagiarism
For illustration referencing from photos too closely is bad. Reusing backgrounds is bad. Reusing poses is bad. Using something already resolved for you is bad. This goes beyond bad for beginners, as in your will be disowned and not seen as very good if you lean on anything but rigid anatomical studies from your brain and life drawing, unless it fits in with your unique style, but it's still gotta flow. Someone already did what your trying to do with coding? Not only should you use it, they usually want you to use it and have given it freely. In fact it's probably already a npm package ready to install. Again, with the bad for beginners, you should always learn why something works, but when you've got it, what handy tools there are! Reusing code is efficient, and you can make it better along the way.
Big to Small vs Small to Big
Speaking of reusability, the way you build is also different. Each of them will require a bigger picture, but the way you build them is different. Flow comes first in art, and you must find the composition first. You might be in the mood to draw a fine bow on someone's head, but if you don't nail down the right look, shape, perspective or fluffiness you've got to redo it. After you've done that great bow, you can realize everything needs to move and now the bow needs to come from a different angle. This is why you work from big to small, because small details are only details and not an integral part of the bigger picture or feeling of a work. And remember, you can't just take that bow and stick it on another place, it's lazy to reuse things especially if they were not specifically crafted for this piece. On the other hand, I quite like React and it's components. Self encapsulating modules, I find myself copying over sass mixins that I reuse often and have a dedicated file for utility classes. The smaller pieces you use to build you code, the better it can be maintained, by not just you, but others as well. The hard work you put into the details can be measured in the end, wither it's readability, performance, or reusabilty.
Personal
Good art is what I do in my high periods, when I can envision a grand thing and work out a flow. Unfortunately, I am afflicted with mental illness so I have many low periods. As of this year, steady code is what I do in my low periods. It just suits that step of my life and lets me work on the small things without the torment of not being big enough. Each little cog is, or at least feels, important. So if I make little things, that's okay, because I can use them to make bigger things whenever I come back to my high periods.
For those of you who switched jobs (or passions) into programming from another career/hobby, how do you think those two compare? What fundamentals differ, and how do you see coding? Am I just too green?
Top comments (0)