How art made me a better Engineer
Being successful is having perspective. I wanted to not just be successful in my job, but successful in life. I realized that for the longest time, the only perspective I had was that of an engineer.
Perspective is knowledge. And understanding that perspective translates to empathy. The best way to understand and learn a perspective is to experience it. There's a lot of situations where this isn't feasible, but there's quite a lot where it is.
In the last year I've come to the realization that my life was consumed by distractions. Every activity I did was some sort of distraction. Video games was a distraction from my home. My phone was a distraction from the social culture around me. Television was a distraction from my world.
I imagine where I was versus where I wanted to be as being two planets. I wanted to leave the planet I was on and return to my home planet. But, all I had done so far is leave my current planet. I'm still floating in the space between the two.
The next phase in my route was to land back into my world.
I did this, by investing myself into activities and hobbies that force me into being present and gaining more perspectives.
- I had wanted to do photography for a long time, so I bought a nice camera (I realize I could have used my phone, but this is about getting away from my phone. The phone is too easy to get distracted by).
- When I was younger I started learning guitar and I wanted to restart that. I bought myself a guitar and started taking lessons.
- I've found illustrations always so emotion-inducing. I dusted off my iPad, bought an Apple Pencil and Procreate, and started learning to draw
All of these new hobbies took off, as long as I made a point to actually practice them. Then I started falling back to my old habits. I didn't want these, and so I started introducing techniques that I learned in Software Engineering and Data Engineering to "force" practice.
In being able to utilize a skillset from another "industry" (read: perspective), I realized that I could also utilize techniques I learned in reverse and apply them Engineering.
One of the first lessons I learned about Illustration, at least digital illustration, was regarding re-itoration. A lot of the videos I'd watch and articles I'd read would emphasize that your sketch or illustration will continually get re-itorated upon, and to not get too caught up in the details.
For example you may start a sketch and realize that you didn't add enough depth or perspective. You take what you like about the first version and start a new layer in which you add what you want to change. This has greatly improved my illustrations, as I'm spending less time "nuking" the illustration and starting over from scratch.
In software engineering, this is a really good philosphy too. This is where MVP comes into place. Thinking too much about infrastructure, or design, or complexity, and just generally getting too caught up in the details can stretch out a projects timeline drastically.
What I've started doing is identifying the problem I'm trying to solve in it's simplist form, and creating a solution as fast as I can to solve it. Then, I create a list of what I don't like and what I do like, and generate tasks from that list.
It may seem basic, but taking it step by step, slowing down, and establish clear goals is so nice for productivity. My projects have skyrocketed on featuresets and bug improvements from this methodology.
One of the most beneficial lessons I learned from photography is what I like to call "shotgunning". For context, when I first started taking pictures, I would set out with a goal/prompt. For example, one prompt might be "downtown", in which I try to encapsulate downtown in a set of photos.
The problem I quickly came to, regardless of prompt, was that I didn't take enough pictures. I spent way too much time looking for the right picture, and would come back home with not enough pictures, and definitely not enough that I liked.
What I gathered from this is to start "shotgunning", in which I don't limit myself to "thats not what I'm looking for". Just going around and start to shoot as many pictures as I can within a timelimit. This also had a side effect of creating strings of creativity, such as getting a picture of a specific subject really good, and continuing on shooting similar subjects.
The way I translated this to software engineering was like this: When you approach a difficult problem, shotgun the solution. Yes, this is identical to brainstorming, but you'd be surprised how many teams don't brainstorm well.
Software engineers are some of the most prideful people. Brainstorming can cause internal dilemnas with these people as they're nervous to spit ideas out in fear of diminishing their reputation.
For the sake of the solution, shotgunning as many ideas out as you can initially can be so beneficial for finding the best solution. Ultimately, it gathers a ton of solutions, some you may not have thought of, and you can start eliminating them one by one.
Let your brain shotgun!
I've learned the most from playing an instrument. Too many lessons to list in this article (maybe I'll make a parted series for this).
The biggest lesson I learned from learning the guitar is the importance of specializing, but understanding overarching concepts that reach outside of your specialization.
While learning the guitar, you learn how to play strings. Guitar's not the only stringed instrument, and its tought to immediately transition to violin for example, so you could loosely call guitar a specialization. But, while learning the guitar, you start to learn about music. Notes, chords, frequency, action, envelope, and other "musical words". Lots of these concepts transition to other instruments. And understanding those concepts is so important to be able to have more breadth has a musician.
The software engineering industry is full of specialists, especially in the web sector. React Developers, backend developers, Node developers, front end, fullstack, the list goes on and on. I've worked with them all, and what I would constantly run into, is that if you were outside of the engineers realm of specialization, they became a fish out of water.
I believe this comes from engineers not completely understanding the concepts of their specialization. Concepts that can transfer to other specializations, or allow them to swim better in unfamiliar waters.
Yes, software engineering is a little bit more nuanced than that. But, understanding concepts can ultimately make you a better engineer in general.
Understanding other perspectives that don't seem directly related to our core skillsets can so greatly improve our own skillsets. In addition, I truly believe that have more perspective makes us generally better-rounded individuals.