Things I Learned the Hard Way
Ich weiß nicht mehr genau wie ich eigentlich auf dieses Blog gestoßen bin, aber es enthält ein paar interessante Artikel. Insbesondere die Reihe Things I Learned the Hard Way finde ich nicht unspannend.
Programmierer
Ein Artikel dieser Reihe – Programmers are Tiny Gods – beschäftigt sich mit Programmierern, und wie man mit diesen umgehen sollte.
In Genesis, God creates things in a certain order. Why plants before animals? I dunno. It just seemed right to Him. (Don’t worry, it’s just a metaphor.)
Programmers are the same way. In any programming language, there will be many ways to solve a problem. The right way to do it is a personal decision, made by the programmer, just like in Genesis.
Programmers are the Gods of their tiny worlds. They create something out of nothing. In their command-line universe, they say when it’s sunny and when it rains. And the tiny universe complies.
Ich muss zugeben, dass ich den letzten Satz hier beim ersten Mal anders gelesen habe: And the tiny universe COMPILES. Außerdem will ich da zwei ganz wichtige Verhaltensgrundregeln wiederholen:
So if you’re working with a programmer, you have to treat him or her like a God. You have to pray. You cannot issue edicts. You have to come on bended knee.
if you give a programmer a problem with parameters, they’ll apply every bit of genius they have to solve it in the best possible way. If you tell them how to do it, you’ll suffer the wrath of an angry God.
Designer
Ein anderer Artikel dieser Reihe – What’s Your Suggestion? – beschäftigt sich mit Designern, und warum diese als Teammitglieder umständlich sein können:
If you spent any time in an art-related education, you’ve experienced critique sessions. For the uninitiated, a critique is when you put your hard work on a wall in front of your teacher and peers, and they all rip the living shit out of it.
Critique sessions are rarely about suggesting solutions. In fact, to suggest alternatives would be insulting. It’d be like someone telling Picasso to make all those brush strokes blend in more. Sure, it happens, but it’s not the point. A lot of the criticism in these sessions boils down to “this isn’t working for me. Push harder.”
That’s why most designers make awful team members. It’s why, when the biz dev guy says “this is how our startup is going to make money,” our first inclination is to tear down the idea. We’re in critique mode and that’s just what you do.
Das ist eine interessante Feststellung, die ich zumindest nicht widerlegen kann. Als Lösung schlägt er vor, dass Designer ihre Einstellung ändern müssen:
Fortunately the solution is simple: just force yourself to come up with an alternate solution.
It’s also become a great mental exercise. When I’m tempted to write that piss-all-over-it email, I think to myself, “so what’s the solution I want to see?” If I can’t come up with one, I won’t send the email. Better to be quiet and see how things progress than to be the negative blocker guy.
Das ist sicher nicht nur für Designer eine gute Idee, nur im Unterricht vielleicht nicht immer die ideale Lösung.