Category: Computer

Vor einigen Wochen habe ich einen bemerkenswerten Artikel von Phillip Torrone gelesen, einem der Väter der DIY- und Open-Hardware-Bewegung.

Hier ist der Link.

Um die Wichtigkeit des Artikels zu betonen, sei er hier nochmals in voller Länge abgedruckt:

***

This week for my bi-weekly soapbox column, I thought I’d share some of my notes I’ve jotted down recently about making things, working with and supporting beginners. Lately, I’ve been thinking about how much fun it is when you’re a beginner at something as opposed to being an “expert.”

At some point, we all become experts at something. I really want to avoid being an expert in some things, only so I can continually look forward to learning more without the overhead of being an expert. Being an expert means your journey is somewhat over. I was going to call this column the “expert problem” but I hope you enjoy this semi stream of conscience collected over the last few weeks. Be sure to post up in the comments about your experiences with learning a new skill and how you keep motivated to keep learning more.

I thought I’d start with a favorite quote:

Begin at the beginning and go on till you come to the end; then stop.
— Alice in Wonderland

When you start out making something, you usually don’t end up where you thought you would. It’s usually some place better. A beginner can imagine more than an expert because a beginner doesn’t see constraints yet. Kids are the same way — they approach things with an open mind because they haven’t been told “you can’t do that” yet. Beginners aren’t billing someone for their time — it’s not a job, and time doesn’t matter. Beginners (and kids) usually have more time than money. Beginners aren’t collecting trophies (yet) — they’re exploring. If you don’t know the boundaries of something, for a brief time your ideas are boundless.

Maybe becoming experts in things is just in our destiny — we all specialize, growing old is unavoidable — but retaining things from our childhood is possible; it’s just a struggle sometimes. This is why a lot of us have safe places, like a workshop or an electronics bench, where we can protect them. If you’re a self-proclaimed expert in something, you’ll end up defending your work from other experts. The internet is an amplifier of this phenomenon. I think it’s important to have places where beginners can help each other, and the experts are there to not only share information, but share how they discovered things (sometimes the how is more important than the what). The best experts I know open the door, but you enter yourself.

Experts stay still; beginners are constantly moving. An expert can point out the difficulty in every project, while the beginner can only see possibilities (and later many ways to make mistakes). The reward for beginners is not the stuff they make, it’s the person they become because of the stuff they make and share. Beginners need to practice a lot; experts need to talk more than practice usually. Beginners do very simple things before they understand what they are doing, but they are simplistic. Experts struggle to make things simple because they want to put everything they know in something, to demonstrate their expertise.

Beginners share their mistakes; experts hide them. Knowledge is one of the few things that doesn’t diminish the more you share it. I probably read about 1,000 messages a day across mailing lists, forums, customer support emails, Google+, Twitter, and more. Beginners can celebrate failure while experts rarely admit it. For a beginner, all the obstacles, failures, and challenges are the path ahead. Beginners usually do not have any fear; they just make things — maybe it doesn’t work out, maybe it does — but they don’t have the same risk aversion experts tend to have.

Beginners get the satisfaction of solving many small problems that are wonderful milestones to keep motivated. Experts build bigger and for longer, so when something goes wrong it can really crash hard. The little problems a beginner solves are like weeds in a garden: you find them and use them for mulch — they’re fuel. Eventually you might have a manicured estate, but I think the small garden is more fun and approachable. More people can participate because the fence is lower, or not there at all.

Once you get enough experts together, that’s when the in-fighting usually starts. Even The Beatles fought with each other about who was the best. Experts start to see the tiniest differences between each other and (usually) fork their efforts. It might be over-phrasing or titles of efforts, what licenses they use or don’t use, who is more pure than someone else. Beginners don’t know enough to care about these things yet — it’s the freedom beginners enjoy, even if it’s just for a short while. Beginners tend to see what they have in common with each other; experts can only see the differences. Many experts don’t want to share their knowledge, and beginners don’t have anything to share yet other than encouragement and enthusiasm for other beginners. Experts like to defeat each other, often publicly; beginners conquer themselves and their own challenges, and the experience cannot be taken away by anyone. Beginners don’t have strong opinions — they can’t effectively bother each other yet.

Relating this specifically to electronics, projects with Arduino are now practically ubiquitous. If you are beginning in electronics, when something is always around beginners, like Arduino, interesting things can happen. Beginners bend things, break things, they do things that the experts couldn’t imagine — and that’s a good thing. Some of the most disruptive innovations came from people tinkering, not exactly knowing what they’re doing, and later becoming experts only to be usurped by a new crop of tinkerers. It’s an endless cycle of people doing weird things because “they didn’t know any better.”

Electronics is full of problems, but it’s also full of people overcoming those problems — those are fun people to be around. They’re convinced that if they try, they can figure it out. Over the years I’ve tried to collect all the stories people would write in to me from Hack-a-Day, MAKE, or Adafruit about how, in a short time, they went from not knowing anything about electronics to being able to make something they always wanted, and how they discovered they had the potential all along. All they had to do was listen to their own voice and not someone else telling them they couldn’t do it for one reason or another.

When you’re learning something about electronics, you usually don’t know what’s “enough” until you discover what’s “too much.” Beginners are filled with uncertainty on how things will turn out — that’s the fun part — the surprise, the unexpected, how knowledge is made. Experts have expectations. Beginners can adapt themselves because they’re not set in their ways yet; experts tend to be more rigid and demand the same of others. Experts value what they have; beginners value what they don’t have yet.

Beginners can take more risks than experts — they start with zero, so there’s nothing to lose. Experts worry that if they’re an expert in one thing, they’ll need to be an expert in other things, otherwise their expertise could be questioned. For experts a lot of things are easy because they’ve done it so many times. Experts become impatient (with themselves and with others); beginners are patient and brave, because they don’t yet know it will become easy. Experts have pride; beginners can’t deceive themselves so easily.

Starting out now with making things is fantastic. With 3D printers, laser cutters, Maker Faires, hackerspaces, Techshops, Instructables, open source hardware, it’s never been a better time. I’m sure every generation says that, but I really think it’s true. Starting out now, you get to explore more, faster, cheaper, and with more people. This is all new stuff too — it’s hard for anyone to be an expert yet. This happened with homebrew computers, and it happened with the web. In the maker world, we’re all still figuring a lot of this out. There’s still plenty of time before we’re all experts at one thing or another.

Some of the most talented and prolific people I know have dozens of interests and hobbies. When I ask them about this, the response is usually something like “I love to learn.” I think the new discoveries and joys of learning are the crux of this beginner thing I’ve been thinking about. Sure, when you’ve mastered something it’s valuable, but then part of your journey is over — you’ve arrived, and the trick is to find something you’ll always have a sense of wonder about. I think this is why scientists and artists, who are usually experts, love what they do: there is always something new ahead. It’s possible to be an expert but still retain the mind of a beginner. It’s hard, but the best experts can do it. In making things, in art, in science, in engineering, you can always be a beginner about something you’re doing — the fields are too vast to know it all.

Since I started with Lewis Carroll, I figured I’d end it here too:

Alice came to a fork in the road. “Which road do I take?” she asked.
“Where do you want to go?” responded the Cheshire cat.
“I don’t know,” Alice answered.
“Then,” said the cat, “it doesn’t matter.”
– Alice in Wonderland

Pointierte Einschätzung des grossen Meisters.

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into
Date: Thu, 29 Sep 2005 20:03:14 UTC
Message-ID: <fa.g0a33ji.m0e6ii@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.58.0509291247040.3308@g5.osdl.org>

On Thu, 29 Sep 2005, Arjan van de Ven wrote:
>
> a spec describes how the hw works... how we do the sw piece is up to
> us ;)

How we do the SW is indeed up to us, but I want to step in on your first
point.

Again.

A "spec" is close to useless. I have _never_ seen a spec that was both big
enough to be useful _and_ accurate.

And I have seen _lots_ of total crap work that was based on specs. It's
_the_ single worst way to write software, because it by definition means
that the software was written to match theory, not reality.

So there's two MAJOR reasons to avoid specs:

 - they're dangerously wrong. Reality is different, and anybody who thinks
   specs matter over reality should get out of kernel programming NOW.
   When reality and specs clash, the spec has zero meaning. Zilch. Nada.
   None.

   It's like real science: if you have a theory that doesn't match
   experiments, it doesn't matter _how_ much you like that theory. It's
   wrong. You can use it as an approximation, but you MUST keep in mind
   that it's an approximation.

 - specs have an inevitably tendency to try to introduce abstractions
   levels and wording and documentation policies that make sense for a
   written spec. Trying to implement actual code off the spec leads to the
   code looking and working like CRAP.

   The classic example of this is the OSI network model protocols. Classic
   spec-design, which had absolutely _zero_ relevance for the real world.
   We still talk about the seven layers model, because it's a convenient
   model for _discussion_, but that has absolutely zero to do with any
   real-life software engineering. In other words, it's a way to _talk_
   about things, not to implement them.

   And that's important. Specs are a basis for _talking_about_ things. But
   they are _not_ a basis for implementing software.

So please don't bother talking about specs. Real standards grow up
_despite_ specs, not thanks to them.

		Linus

Ich habe ein neues schönes grosses Problem gefunden, dessen ich mich den Rest meines Lebens werde erfreuen können. Einige der schillernsten Geistesriesen unserer Zeit zerbrechen sich seit Jahren die Köpfe über diesem Geheimnis, doch von einer Lösung ist man noch weit entfernt.
Die Frage lautet:

Nach welchen Regeln falten sich Proteine?

Proteine sind Sequenzen von Aminosäuren. Gleiche Aminosäurensequenzen falten sich zu gleichen Proteinstrukturen. Welchen Gesetzen folgt der Faltprozess? Man weiss, dass der gefaltete Endzustand ein globales Energieminimum einnimmt, aber ansonsten weiss man nicht viel. Man hat es mit raffinierten mathematischen Modellen versucht und ausufernden Simulationen, doch vermochte man lediglich einige Picosekunden der Proteinfaltung nachzuahmen, zu komplex sind die zugrunde liegenden Mechanismen.
Ich glaube, da muss ein furchtloser Ingenieur ran. Bisschen vereinfachen hie und da, abstrahieren, zurechtstutzen was nicht passt, basteln, nicht verstehen was man tut und doch irgendwo ankommen. Wenn die Theoretiker versagen, müssen die Praktiker in die Bresche springen.
Kleiner Ansporn: wer das Geheimnis lüftet, wird gefeiert bis nach Stockholm.