Knowing 'How'(37signals.com)
37signals.com
Knowing 'How'
http://37signals.com/svn/posts/2968-knowing-how
5 comments
Sorry, I'm a little confused at this statement. That's not a problem with the approach, in fact it's exactly why such an approach should be preferred.
If anything you seem to be saying that you find being a mentor a p.i.t.a, which is perfectly valid but not really a part of this conversation.
If anything you seem to be saying that you find being a mentor a p.i.t.a, which is perfectly valid but not really a part of this conversation.
Nah, you've just misunderstood me - sorry if I wasn't very clear :) I agree that being able to address an individual's concerns is very important, and I certainly don't consider mentoring a pita. The original post just expressed the idea that you can't teach everything through lectures and so forth, and I was trying to provide a reason why that is so.
This article makes a false argument. It somehow seems to categorize programming as being different than other disciplines, and argues that programming needs "knowledge how". But this is really the case for virtually everything. What isn't best learned by practice? That's how you best learn math, plumbing, mowing the grass, writing, reading, circuit design, cooking, research, shooting free throws, etc...
In fact, everyone here knows about the popular 10,000 hours of deliberate practice rule. No one achieves competency through Matrix like osmosis -- not even programmers.
And I think what the author is missing when he/she goes to these conferences is that a conference session is a jumping off point. It's a place say, "I didn't realize you could animate that with that technique." And then you go home and try it and practice it. It's not about mastery at the conference, but awareness of something worth pursuing more.
In fact, everyone here knows about the popular 10,000 hours of deliberate practice rule. No one achieves competency through Matrix like osmosis -- not even programmers.
And I think what the author is missing when he/she goes to these conferences is that a conference session is a jumping off point. It's a place say, "I didn't realize you could animate that with that technique." And then you go home and try it and practice it. It's not about mastery at the conference, but awareness of something worth pursuing more.
I think you're modifying the argument yourself. I saw, at no point, where the author argued that programming, design, etc. are _different_ from other disciplines. It simply states that the author believes they are better learned by doing than by reading (to over-simplify it). I don't see where the author condemns any other method. I actually don't see any point at which you and the author are in disagreement.
He says, "I’ve long argued that UI design, programming, and product strategy should be learned apprentice-style with your hands and through experience, not through school and pedagogy."
There's a clear implication that there are other things that should be learned using some contrasting mechanism. And furthermore, the author, like many others, misses completely that school isn't meant to be OTJ training. If it were, more than half of your units wouldn't be 17th century female philosophers from Rwanda. To the extent that you directly study programming in school, it is almost all hands-on.
I am in agreement with the general thrust that people learn from experience. My point is that he opens this up with a somewhat false argument that in school you read things in a book and then you're done. That's not the case even at the worst schools (well maybe the worst). And then goes on to suggest that programming, UI design, and product strategy (whatever that is) is some how different. Here my point was that virtually every vocation in the world shares the trait that you need to practice the vocation. That's why there's actual cars in autoshops.
What a structured vocational education tries to do is to move you from topic to topic so that you cover the ground of a professional. This avoids the problem where as an apprentice you become really good at fixing this one particular bug, because that's the main job your mentor gets called out to do. Of course, you can move to a system where there are required skills you must exibit over your apprenticeship, but now you're just moving to structured education in a new cloth.
There's a clear implication that there are other things that should be learned using some contrasting mechanism. And furthermore, the author, like many others, misses completely that school isn't meant to be OTJ training. If it were, more than half of your units wouldn't be 17th century female philosophers from Rwanda. To the extent that you directly study programming in school, it is almost all hands-on.
I am in agreement with the general thrust that people learn from experience. My point is that he opens this up with a somewhat false argument that in school you read things in a book and then you're done. That's not the case even at the worst schools (well maybe the worst). And then goes on to suggest that programming, UI design, and product strategy (whatever that is) is some how different. Here my point was that virtually every vocation in the world shares the trait that you need to practice the vocation. That's why there's actual cars in autoshops.
What a structured vocational education tries to do is to move you from topic to topic so that you cover the ground of a professional. This avoids the problem where as an apprentice you become really good at fixing this one particular bug, because that's the main job your mentor gets called out to do. Of course, you can move to a system where there are required skills you must exibit over your apprenticeship, but now you're just moving to structured education in a new cloth.
That is unfortunately how many people learn. I have had my share of design graduates coming to a job interview claiming that they are really best at the conceptual stage. I have later found out that actually even design schools have been focusing on that area.
We are left with a whole new breed of people who are craftsmen but being taught to like they are academics.
We are left with a whole new breed of people who are craftsmen but being taught to like they are academics.
I'm returning to this a bit late. Sorry.
I still think you're reading an implication that is not actually being made, and subsequently getting huffy about it. I see no "clear implication" other than "this is not how those three things are most commonly learned currently". I cannot understand where it is that he is posing those three things against all other things.
I still think you're reading an implication that is not actually being made, and subsequently getting huffy about it. I see no "clear implication" other than "this is not how those three things are most commonly learned currently". I cannot understand where it is that he is posing those three things against all other things.
It's not "a clear implication that there are other things that should be learned using some contrasting mechanism." It's a recognition that "UI design, programming, and product strategy " is not learned in this way, and he argues that it should be.
Fair points all. What I read was that he'd prefer more hands-on (i.e. watch me do the craft) types of presentations, whether at school or academia, rather than didactic rules to follow or some other form. This is one type of instruction and I think it can be useful to see more of it. Nevertheless, I don't see a particular shortage of such how-tos and I think there's room for multiple types of instruction. As the author and commentators seem to agree: there is no replacement to practicing it to actually learn how to do something.
Perhaps he was simply being modest. "UI design, programming, and product strategy" are just the three specific subjects he has felt qualified to "long argue" about.
I don't know about modesty, but it's correct that I was limiting myself to subjects that I know about. We have a shortage of truly great software designers and coders. So I think it's important that we shore up our methods for passing on knowledge and experience in these areas. If we treat it like somebody else's job, or academia's job, then we won't see the improvements that we want to see in conference quality, applicants for our job openings and so on.
Ever since I have watched your videos and read your blog, I've learned more about UX/UI than ever before. I don't think people realize how hard it is to find good content when getting started in the field. You hear about a lot of big name designers and UX/UI guys and try to learn from their twitter/blog but no one teaches like you do. I really appreciate your philosophy on teaching and honestly can't express how grateful I am for the content you have shared. If we meet someday I am definitely going to buy you a beer :)
I tend to agree with this and don't buy the idea that college is necessary to give you a broad overview of a discipline.
Sure, if you learn only one method of doing something, you are not exposing yourself to other ways. But whats to stop you from finding out about these other ways.
This information is easier then ever to find. Surely the time for hand-me down curation (academia style) is approaching its end.
"When I go to conferences about design I see a lot of declarative knowledge."
It's because he went to design CONFERENCE, not design WORKSHOP. The nature of conference speech is so much different from workshop.
It's because he went to design CONFERENCE, not design WORKSHOP. The nature of conference speech is so much different from workshop.
The only differences between conference sessions and workshops are a) length and b) number of people in the room. How you use an hour in front of a room of people is up to you. Conference sessions don't have to be limited to bullets on a slide or purely declarative knowledge.
I'd hate to plod through some example that I could work through better on my own time.
At conferences I want to be exposed to new ideas that I can then go look up on my own. Just to pick an example at random, as someone who has never used Haskell, I'd much rather hear about "so, what the hell is a monad, really", rather than, say, someone sitting there showing me how to write hello world in Haskell.
At conferences I want to be exposed to new ideas that I can then go look up on my own. Just to pick an example at random, as someone who has never used Haskell, I'd much rather hear about "so, what the hell is a monad, really", rather than, say, someone sitting there showing me how to write hello world in Haskell.
The author has a point, but the post itself is pretty light and the discussion here seems to reflect that.
When I am training up junior programmers, I spend a lot of time explaining to them why I have chosen certain patterns in the code that they should use. Nevertheless, they invariably come back with 'yes, but why don't we do it this other way?" and then I have to explain to them the problems that that solution will lead to.