On Engineering, Design & Art
The process to make lots of things, like cars or software or bridges, involves a combination of design and engineering.
It seems that engineering concerns solving a specific and well-defined problem of implementation given constraints, while design is the process of transforming the very open-ended question of “How do I make a good X?” to the well-defined problem that engineering aims to solve. Design, in transforming the question, should answer what it means for X to be good and iteratively articulate that answer till it is precise enough to be attacked as a well-defined engineering problem.
Take the question, “How do I make a good chair?”; a designer might say “A good chair should be comfortable”, which is true but it isn’t enough. Saying that the chair should be comfortable is too imprecise of a spec to be implemented. The designer must draw the chair, and the drawing can be taken as a natural visual articulation of answering the initial question. Given that the drawing implies the scale, anatomy, and shape of the chair, a woodworker could figure out how to actually cut the wood and bind it into place.
Designing something with a functional purpose means that a huge part of “How do I make a good X” turns into “How do I make a good X do its job well?”. A car designer should make a car that does a good job of transporting people and a chair designer should make comfortable chairs. Design, for these things, becomes a question of thinking deeply about an object’s purpose and how it can do its job in an elegant and efficient way. “Form follows function” can be thought of as “design should follow purpose.”
If you’re thinking about how to make something do its job well, you’ll want to how its underlying mechanics work. A car designer that wants to design a fast car will want to know how cars can be fast and, more generally, how cars work. As function plays an increasingly large role in a design, it is increasingly important for that design to be informed by an object’s technical workings. It is from here, we get Paul Graham’s idea that good software designers should also be software engineers.
Art
So, what is art? Art, it appears to me, is the special case of making something that should fulfill a nonfunctional purpose. Its not that the things we call art can’t serve a functional purpose, but that their success as artworks is judged by their ability to serve some sort of intellectual, aesthetic, or emotional purpose. Paintings usually serve no practical purpose but might attempt to make you feel nostalgic or warm or shocked, to serve an emotional purpose. A beautifully crafted knife can be used to cut vegetables but may also serve an aesthetic purpose.
Art and function should not be thought of as entirely independent. While art tends not to be judged by how well it serves a functional purpose, striving to meet a functional purpose often makes something beautiful at the same time.
Artists ask what it means for something to be beautiful and then implement their answer; making art is, in some sense, design and engineering. In the case of photorealistic drawings, the artist decides beauty is realism and the majority of the effort goes into figuring out how to implement their idea of realism. In the case of modern art, the artist’s conception of beauty might be more developed and the work to implement their idea of beauty might be a minority of the difficulty that goes into creating the artwork. Art that forces you to ask the question “Will this be interesting?” or “What should go here?” is the sort of art that teaches you design. Art where you copy exactly teaches you the techniques of implementation and gives you a sense of taste but isn’t direct practice in design.
As makers, it’s good to be aware of all this. If you solve lots of programming problems, you’ll get good at software engineering but not software design. If you want to be able to implement some organization’s precise programming language specification, you’ll might not have much trouble. But if you want to make your own programming language, this won’t be enough. In high school, I didn’t know why the best software engineers weren’t just the best competitive programmers. I think the answer lies in this distinction: the best software engineers are not just the best problem solvers but also the best problem definers. On the opposite hand, a designer with no understanding of how something is built will be unable to take advantage of certain exploits and doom the project by not accounting for damning constraints.
Life Design
There’s a bigger analogy in the way you design your life. If you try designing the perfect life when you’re very young, you’ll probably fail because you don’t have taste to know what a good life is and you don’t know about the underlying mechanisms that make the world work.
You wouldn’t have had enough experience to definitively know whether a good life means one where you’re rich and famous (it isn’t) or one where you’re fulfilled and optimistic. Even if you can articulate what a good life for you would be (say becoming a great musician), you’ll likely be unable to figure out the best way to do it (should you start a rock band or master the violin?). That’s not to say you shouldn’t have a life plan, but that the design of your life should evolve as you develop your taste in what is worth pursuing and learn more about the world at large. Solving the engineering problem, in this case, means working hard at honing your skills and acheiving the goals you set.
I’m really glad I came across the idea of designing your life because it convinces me that it’s worthwhile to be both a designer and an engineer. You’ve got to explore and exploit. That’s the master algorithm.
Inspired by: http://www.paulgraham.com/hp.html
