Critiques In Tech

In effort to catch up on posts I am thinking about (I still need to finish Techstars boulder, write up about the last NYTech Meetup which I will have to watch post the event, and read up on all the crazy news about ATT&T and mobile phones…and school), I thought I should start with one more basic post:

Would a critique system, or at least a more managed critique system, help the tech community?

Note: I’m an outsider.  I don’t actually go “hey look at my stuff” inside the tech community.  I do see the amount of networking events, email lists, and places to show your stuff.

This is very different than the traditional conception of an art/design critique.

Art/Design critiques in life tend to be more intimate affairs.  They are large discussions of the repercussions of the work one is doing, what it looks like, what it feels like, the thought process behind it.

Traditionally, people try to set them at a half hour long for talking (although it has been leveled that it may not be enough for full discussion and unpacking) and fifteen minutes for seeing (same critique).  The idea is to unlevel as many ideas out of what you see as possible.  One may be asked about anything from “aesthetic politics” to “why that color is there?” Oftentimes. process, or how you got to the work at hand , including early “practice” or “iterative” works are also up for display.  Sometimes those early works are even the work itself (I know, art people are funny that way.)

In contrast, coding seems also to  be about the mistake process.  However, it seems to be about going at the mistake process through the following methods:

1. alone
2. in the open source community, which may be massive, critiques are leveled from a very broad variety of sources
3. in a corporate environment, where you may be working on a team, yet it in the end, you are still working alone, you are not really explaining why you made the design decision to anyone in particular in the large corporate structure
4. In a small startup- where there are going to be critical design decisions handled by the team, otherwise known as your company, but the broader startup community has no clue what those decisions are and why they were made.  The end product, even if it is a buggy, beta end product, is all that is shown to the community.  The process is not up for discussion.
5. In small teams, usually in school.  These small teams are supposed to help you with your homework.  I have no idea if it actually works or not.  It never seems to come under discussion where I am at, mostly because of the department politics that I hear about.  Then you are told you have bad taste in code and have to relearn all over again.  It’s sort of like art school, except at the end of art school, you are supposed to still have decent taste, because you at least understand the theory of it all, sort of.

It passes me as strikingly unusual that when it comes to mistakes, to bugs, both the art/design process and coding tend to emphasize iteration, yet neither own up to the split between them about how to make better objects.

Part of this is the culture of one trains to learn.  Critique processes are after one takes “foundation;” classes, which vary from program to program (My program is a high theory program, and I took a lot of drawing classes, the theory classes where the foundational ones, not the drawing classes, for those curious.)  Usually, that means that people are going to be studying how to make art together in a group.  You are expected to come together and learn these skills, even in advanced classes.  There is no one to take care of group studios except for the students.  There is no one to be homework models but the students.  Students are very reliant on each other.  Then they have to judge each other.  This provides even more intimate scales of knowing why the art works, even to outsiders of the process.  You know if someone is not playing by the rules that the art and design establishment has determined.  Even if there are lots of theoretical splits, there is still only one unified body about what gives us art and decent art, we’re just bad at describing it.

Meanwhile there is a lot of crufty code out there.  And the code seems to get cruftier all the time.  Further, coders tend to make life scary by continually making new communities of coders.  Who may or may not be any good, with good or bad code. It isn’t necessarily clear when you start reading said code how it will all work out either.  There seems to be less pre-thought out “rules” by the entire body of the coding community of what makes something good, irrelevant of language.  It makes it hard to judge what’s what, and makes it hard for someone to jump from place to place.  Just a perception I’ve been noticing over the years with my own parents.  (It’s a process of slow abandonment instead.)  (Though I have been told you can tell when you see crappy code, because it is wiry and ugly).

I’m wondering, after rereading the famous Theory and Organization of the Bauhaus, and watching Tim Brown, if the missing answer is that we do need to bring an academy back into  the land of code and the land engineering.  That means bringing back the idea of small groups asking why and how questions to makers, like engineers.  It means at least starting with a concept of what a unified curriculum should be, and a unified anti-curriculum should be.  And it should be that is on it’s lowest levels, accessible to young children, as well as someone who abandons it, and picks it up later.  Considering that now I have this tendency to do things like ask  an engineer friend  the difference between community and family,in part because of my education as an art student, what would happen if you  applied the practical educational fallout of the Bauhaus to a bunch of engineers?  What would they gain from a curriculum that is to see, to feel, and to know intellectual?

Would we present startups as they are being made in small little groups, down to the code, in order to figure out the process of making?  Would the training be based off the idea of seeing, feeling, and intellectual knowledge?

Does Tech need to adopt the critique process as people learn, in its early teaching stages, in order to make its next leap, especially as the languages become higher level?  The questions that the technology will interact with will have nothing to do woth the actual code, and yet everything to do with the actual code.  How do you go approaching the maker and explaining this to them when that person first starts the process of making?

Should we bring art school to the engineers?

*Does anyone understand their HTML/Server Library?  I known I suck at coding, but server library scares me.  I just want to make a dollar bill change colors.  From data from the USDX, as a test case.

Related articles by Zemanta

• Book Review: Change by Design, by Tim Brown (core77.com)
• A call for “design thinking”: Tim Brown on TED.com (ted.com)