Lessons from art school
The process of making art is all about looking at things from different angles and seeing what other people might not see. To bring that into the world you need to capture a thought or insight quickly and accurately, and make it real - be it drawing/sculpting/writing or whatever. It’s easy to get stuck in a rut, struggle to make something really new or just wind up staring into space 2nd-guessing yourself. So at least at the schools I went to, instruction was all about learning practical techniques to observe the world, to explore, refine and above all keep creating and learning. Probably there were other things I was supposed to learn, but 30 years on these are the lessons that have stuck with me.
In some contexts these are not to be taken literally. Nowadays I mostly work on software. Looking at code in a mirror won’t help you. But hopefully the essence of the idea is there and you’ll find ways to accomplish the same thing in whatever form your work takes.
Seeing with fresh eyes
Step back from your work, try looking at it in the mirror to see it again for the “first time”.
Work with a long stick to force a distance between you and your work.
Step outside for a while, sneak a look over your shoulder as you walk away.
Work on something else. Sleep on it. Approach it as a new problem the next day. Lots of problems solve themselves as soon as you stop thinking about them.
Ask someone to explain your idea/solution/code to you, or describe the problem and ask them to repeat the problem back to you.
Seeing what is really there
Draw the negative space: don’t look at the outline of the thing, focus on the shape of the space around the thing.
Seeing the actual shape of things is surprisingly difficult as our minds offer up shortcuts and preconceptions instead.
Re-frame a problem in terms of what shouldn’t happen? Rather than think about what a thing should do, think about what needs to not change.
Try writing the documentation for your code before you write the code, or write failing tests that each expect the behavior you want to end up with.
Make sure you can tell a story about what success would be. “I’ll know I was successful when…” You define the hole your solution needs to fit into. Seeing where you need to end up casts a new light on what problem you actually need to solve, and maybe which parts aren’t really as important as you first thought.
And acknowledge that there may be more than one truth. Which truth are you trying to find? Which question do you need to answer?
Everyone move one space to your left
Rotate tasks: after some time, hand off your work/patch/task to a peer, and take work from a peer - picking up where they left off.
There’s so much going on here. It’s a lot easier to fix something that is wrong or incomplete than to create something from scratch. And seeing others’ process is instructive, even if we end up with the same solution, we each might take a different path to get there. That path is the paydirt here, once this one problem is solved, how you got there is the thing with lasting value.
It’s also useful to learn to let go of ownership of a thing - which often gets in the way of the larger goal. Perhaps its the sunken cost fallacy, or just a sense of investment in seeing it finished. It shouldn’t matter who finishes it if the goal was just to bring a thing into the world.
Our creations are a shared, collaborative effort. Passing incomplete work between peers - warts and all - is a great way to learn from each other.
Commit to destroying your work as soon as it is done.
Code is cheap, ideas are cheap. But time is valuable, so budget some of it for exploring early on when the correct solution isn’t locked in. If you’ve ever accidentally lost some work in progress, you’ve probably discovered that it didn’t take as long as you thought to rewrite it. That’s because the discovery process was not lost even if the final implementation was.
You can’t really see what is needed until you’ve tried to implement it. Your first pass is always throwaway so unblock yourself by writing code/making a sketch/etc you plan to delete.
Its freeing to work on something you know is temporary. It shifts the focus onto understanding the shape of the problem and exploring solutions, rather than concerns about what people might think, or how this solution might work for other future problems.
And there’s a thing in here about being precious about your output. “It is special because I worked on it.” It isn’t. If it gets taken away you will make another one and it will probably be better.
Plans change; its normal to sometimes have to throw things away we worked hard to create. We bring value to each new task. We can’t only measure ourselves against the work that ended up shipping - especially when those decisions are outside your control.
Always be a beginner
Dive into something you know nothing about - frequently.
The start of the learning curve is always the steepest. That’s where we learn most. So unless you are learning new things often, you slowly stop learning. And that’s not fun at all.
There’s a thing in here about humility. We can be simultaneously confident in our skills and experience as well as complete n00bs at some other thing. No-one can possibly know everything. Its good to regularly experience the vulnerability of starting out as a beginner.
The flip-side is discovering how much of your experience does end up being applicable. And that learning and problem-solving are skills by themselves. You can get better at each over time. Knowing you can tackle whatever comes up gives you the confidence to move forward even when you initially have no insight into how to fix a particular problem.
And beginners have fresh eyes so they are likely to spot problems others no longer see.
In conclusion
That’s it. At least in the kind of software I work on, formal training in software engineering and computer science isn’t strictly necessary. Yes, you’ll learn some useful things, but so to will other backgrounds provide lessons and habits that can inform and support your success working on software.
I’ve told these art school stories many times and wanted to give them form and a URL I can refer back to. Hopefully there was something useful here for you too. I’ve had these notes on file for almost 5 years and this is what survived the pruning and editing over that time. Some is common sense and advice I’ve seen in different forms from lots of different disciplines. Some is maybe challenging - in the context of doing work within a human society there other constraints on how we work and what we work on. Through the lens of working with real people on real projects, probably some of this sounds hopelessly naive, insensitive, or just irrelevant or wrong. I’m trying to focus on the making things and solving tangible problems here - and getting out of our own way to do the best we can with what is put in front of us.