Block title
Block content

1만 시간의 법칙(Teach Yourself Programming in Ten Years) - 지난 2기를 돌아보며

Posted by postech_admin

2017년 한해 저희 Postechx 를 찾아 주신 모든 분들께 감사의 말씀을 드립니다.

 

그간 2기에 걸친  AIㆍ빅데이터ㆍIoT 인재양성 교육  온라인 기초과정 과  정보통신대학원 MOOC 프로그램 을 운영하면서 안타까웠던 점은 많은 분들이 강의 신청을 하시고, 일주일 이후에는 또 많은 분들이 수강을 포기 하셔서 이수율이 높지 않다는 점입니다.

 

혹시 “1만 시간의 법칙” 이란 말을 들어 보셨나요? 한동안 유행했던 말이니 아마도 한번 쯤은 들어 보셨을 거라 생각합니다.

 

여러분의 Coding과 ‘STEM' (Science, Technology, Engineering, Mathematics)과목에 대한 motivation 다시 불태우기 위해(?) peter norvig essay 공유하고자 합니다.

 

바야흐로 100 시대라고 하고, 평생 직장의 개념은 이제 이상 통용 되지 않는 이 때  여러분의 인생에 한번 10 정도 투자하는 수지 맞는 장사가 아닐까요?

 

아래의 에세이에서 peter norvig이 언급 하듯  인류의 지적 혹은 예술적 성취는  대부분 지난한 인고의 과정과 탄탄한 기본기에 대한 축적의 시간을 필요로 했습니다.

 

이제 조금은 우리들이 나도 모르게 집단적으로 공유하고 있는 chop-chop 빨리 빨리 조급함은 접어두고, 먼산 가듯이 저희 Postechx 함께 걸어 가면 어떨까요?

 

2018 3 3기를 시작으로 저희 Postechx 홈페이지 리뉴얼과 다양하고 좋은 강의를 준비하고 있습니다. 기대해 주세요!

 

항상 발전하는 POSTECHx 가 되도록 노력하겠습니다.

 

감사합니다.

Happy coding!

 

포항공과대학 정보통신대학원

POSTECHx운영팀 드림

 

 

                                              Teach Yourself    Programming in Ten Years

                                                                                                               by  Peter Norvig

 

 

Why is everyone in such a rush?

Walk into any bookstore, and you'll see how to Teach Yourself Java in 24 Hoursalongside endless variations offering to teach C, SQL, Ruby, Algorithms, and so on in a few days or hours. The Amazon advanced search for [title: teach, yourself, hours, since: 2000 and found 512 such books. Of the top ten, nine are programming books (the other is about bookkeeping). Similar results come from replacing "teach yourself" with "learn" or "hours" with "days."

The conclusion is that either people are in a big rush to learn about programming, or that programming is somehow fabulously easier to learn than anything else. Felleisen et al. give a nod to this trend in their book How to Design Programs, when they say "Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies." The Abtruse Goose comic also had their take.

Let's analyze what a title like Teach Yourself C++ in 24 Hours could mean:

  • Teach Yourself: In 24 hours you won't have time to write several significant programs, and learn from your successes and failures with them. You won't have time to work with an experienced programmer and understand what it is like to live in a C++ environment. In short, you won't have time to learn much. So the book can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing.

     

  • C++: In 24 hours you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Processing) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.

     

  • in 24 Hours: Unfortunately, this is not enough, as the next section shows.

Teach Yourself Programming in Ten Years

Researchers (Bloom (1985)Bryan & Harter (1899)Hayes (1989)Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967.

Malcolm Gladwell has popularized the idea, although he concentrates on 10,000 hours, not 10 years. Henri Cartier-Bresson (1908-2004) had another metric: "Your first 10,000 photographs are your worst." (He didn't anticipate that with digital cameras, some people can reach that mark in a week.) True expertise may take a lifetime: Samuel Johnson (1709-1784) said "Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price." And Chaucer (1340-1400) complained "the lyf so short, the craft so long to lerne." Hippocrates (c. 400BC) is known for the excerpt "ars longa, vita brevis", which is part of the longer quotation "Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile", which in English renders as "Life is short, [the] craft long, opportunity fleeting, experiment treacherous, judgment difficult." Of course, no single number can be the final answer: it doesn't seem reasonable to assume that all skills (e.g., programming, chess playing, checkers playing, and music playing) could all require exactly the same amount of time to master, nor that all people will take exactly the same amount of time. As Prof. K. Anders Ericsson puts it, "In most domains it's remarkable how much time even the most talented individuals need in order to reach the highest levels of performance. The 10,000 hour number just gives you a sense that we're talking years of 10 to 20 hours a week which those who some people would argue are the most innately talented individuals still need to get to the highest level."

So You Want to be a Programmer

Here's my recipe for programming success:

  • Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in your ten years/10,000 hours.

     

  • Program. The best kind of learning is learning by doing. To put it more technically, "the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve." (p. 366) and "the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors." (p. 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is an interesting reference for this viewpoint.

     

  • Talk with other programmers; read other programs. This is more important than any book or training course.

     

  • If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on your own or on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.

     

  • Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do (because they make you do it for them).

     

  • Work on projects after other programmers. Understand a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain them after you.

     

  • Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).

     

  • Remember that there is a "computer" in "computer science". Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk. (Answers here.)

     

  • Get involved in a language standardization effort. It could be the ANSI C++ committee, or it could be deciding if your local coding style will have 2 or 4 space indentation levels. Either way, you learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.

     

  • Have the good sense to get off the language standardization effort as quickly as possible.

With all that in mind, its questionable how far you can get just by book learning. Before my first child was born, I read all the How To books, and still felt like a clueless novice. 30 Months later, when my second child was due, did I go back to the books for a refresher? No. Instead, I relied on my personal experience, which turned out to be far more useful and reassuring to me than the thousands of pages written by experts.

Fred Brooks, in his essay No Silver Bullet identified a three-part plan for finding great software designers:

  1. Systematically identify top designers as early as possible.

     

  2. Assign a career mentor to be responsible for the development of the prospect and carefully keep a career file.

     

  3. Provide opportunities for growing designers to interact and stimulate each other.

     

This assumes that some people already have the qualities necessary for being a great designer; the job is to properly coax them along. Alan Perlis put it more succinctly: "Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers". Perlis is saying that the greats have some internal quality that transcends their training. But where does the quality come from? Is it innate? Or do they develop it through diligence? As Auguste Gusteau (the fictional chef in Ratatouille) puts it, "anyone can cook, but only the fearless can be great." I think of it more as willingness to devote a large portion of one's life to deliberative practice. But maybe fearless is a way to summarize that. Or, as Gusteau's critic, Anton Ego, says: "Not everyone can become a great artist, but a great artist can come from anywhere."

So go ahead and buy that Java/Ruby/Javascript/PHP book; you'll probably get some use out of it. But you won't change your life, or your real overall expertise as a programmer in 24 hours or 21 days. How about working hard to continually improve over 24 months? Well, now you're starting to get somewhere...

원문  : http://norvig.com/21-days.html  

 

 

 

                                            Teach Yourself    Programming in Ten Years

                                                                                                               by  Peter Norvig

 

 

 

다들 왜 그리 급한가?

아무 책방이든 상관없이 들어가서 보면, 24시간만에 자바(Java) 완성 이외에  C, SQL, Ruby, 알고리즘을 불과 몇시간 또는 몇일에 정복하기 같은 제목의 책들이 끝없이 나란히 진열된 것을 볼 것이다. Amazon.com에서 다음과 같은 고급(파워) 검색을 했었을때

출판일: 2000년 이후 / 제목: 몇일 (제목: 정복하기 또는 제목: 배우기)

결과가 무려 512개나 나왔다. 첫 아홉번째 혹은 열번째 검색 결과는  컴퓨터 관련 책 이었다 (다른 하나는 부기에 관한 것 이였다.) "배우기" 나 혹은 "시간" 혹은 "몇일"의 단어와 독학하기로 대체 했을 때도 아주 근접한 결과를 얻었다

 

이런 결과를 보고 결론 지을 수 있는 것은 컴퓨터를 배우려고 하는 사람들의 큰 붐이 있거나, 컴퓨터를 배우기는 그 어떤 것보다도 엄청 배우기 쉽다는 것이다. Felleisen et al.는 How to Design Programs라는 책에서  Bad programming이 쉬운 것이라 그들이 말한다면, 멍청이들도 비록 그들이 바보라도 그것을 단 21일 만에 배울 수 있을 것이다.라며 이러한 트렌드에 대해 동의하고 있다. The Abtruse Goose comic 이라는 카툰도 이에 동의하고 있다.(http://abstrusegoose.com/249)

 

24시간 만에 C++ 정복하기라는 제목의 뜻을 같이 분석해 보자:

  • 정복하기: 24시간 안에 규모 있는 프로그램을 쓸 시간이 없다 그리고 그 프로그램을 짜는데 성공 아니면 실패함으로의 경험을 통해 배우지 못한다. 경험 있는 프로그래머와 같이 일하고 그런 환경 속에서 일하는 것이 어떤 것 인가를 알 수 없다. 짧게 말해서 많은 것을 배울 시간이 없다. 그러므로 이런 책 내용들은 깊은 내용들은 물론 다루지 못 하거니와 표면상으로 이해 할 수 있는 내용들만 다룰 수 밖에 없다. Alexander 로마 교황이 말했듯이, 조금만 배우는 것은 위험한 것 이다.
  • C++: 3일안에 C++의 문법은 배울 수 있을지는 몰라도 (특별히 이미 비슷한 언어를 알고 있다면) 그 문법을 어떻게 제대로 쓰는지를 배울 수는 없다. 예를 들어, 당신이 Basic 프로그래머이라면 C++의 문법으로 Basic 스타일의 프로그램을 짤 수 있을지는 몰라도 C++이 어떤 과제 에는 좋지만 다른 어떤 과제에는 반대로 나쁜지 배울 수 없다. 내 취지는 무엇인가? Alan Perlis는 이렇게 말했다: "당신의 프로그래밍에 관한 생각 하는 부분에 영향을 미치지 않는 언어가 아니면 배울 가치가 없다." 당신이 업무 때문에, 현재 쓰는 도구와 연결해서 쓰기 위해 C++l(또는 더 현실적인 Visual Basic이나 JavaScript)를 약간 배웠다고 하자. 그러나 당신은 프로그래밍을 어떻게 하는 지를 배운 것이 아니라 업무를 어떻게 완수하는지를 배운 것이다.
  • 24시간 안에 : 다음 글에 설명하듯이 24시간 가지고는 터무니 없이 부족하다.

10년 안에 프로그래밍을 정복하기

체스, 음악 작곡, 미술, 피아노, 수영, 테니스, neuropsychology 연구, 위상 수학, 등, 여느 많고 다양한 분야에서 전문가가 되기 위해서는 보통 십년 정도가 걸린다고 연구자(Hayes와 Bloom)들은 말한다. 지름길은 없다. 4살때 부터 신동이라 불려진 Mozart도 세계적인 음악을 만들기까지 13년이 더 걸였다. Beatles는 1964년도에 Ed Sullivan쇼에 출연하고, 연속 #1 히트들로 단숨에 유명해 졌다. 하지만, 그들은 1957년도 부터 Liverpool과 Hamburg의 작은 클럽에서 활동을 시작했었고, 일찍부터 mass appeal이 있었지만, critical success는 1967년도에 Sgt. Pepper로 비로써 이루어냈다. Samuel Johnson는 10년보다 더 오래 걸린다고 생각했다: "탁월함은 일생의 노력과 노동에 의해서만 달성할 수 있다; 그것은 그 이하의 값으로 이룰 수 있는 것이 아니다." Chaucer는 "Life is short, [the] craft long, opportunity fleeting, experiment treacherous, judgment difficult"라고 호소했다.

여기서 프로그래밍을 정복하기 위한 나의 비법이 있다:

  • 먼저 프로그래밍에 흥미를 가지고, 재미로 조금만 해보라. 10년을 투자할 만큼 충분히 재미를 느끼는 것이란 걸 확인해라.
  •  
  • 다른 프로그래머들과 대화를 하라; 다른 프로그램들의 소스를 읽어보라. 이것은 어떠한 책을 통해   훈련하는 과정보다 더 중요하다.
  •  
  • 프로그래밍을 당장 시작하라. 최선의 학습방법은 하면서 배우는 것이다. 더 전문적으로 표현하자면, "특정 영역 에 개인의 성과를  극대화 하는 수준은 장시간 경험의 기능으로서 자동 적으로 달성하지 않는다. 그러나 성과의 수준은 개량하는 의도적인 노력의 결과 로서 높은 경험자들도 증가될 수 있다(p. 366)." "효과적인 학습은 개인에게 적당한 수준에 어렵고 분명한 업무, 유익한 피드백과 반복과 과실을 고칠 수 있는 기회를 요구한다." (p. 20-21) 인식의 실제: 매일 생활 속의 마음, 수학 및 문화는 이 관점에 관련된 재미있는 참고서다.
  •  
  • 원한다면, 대학에 4년을 (또는 대학원에 더) 투자하라. 학위는 자격증을 요구하는 직업에 취직 자격을 줄 것이다, 그리고 분야에 더 깊은 이해를 주지만, 학교에 관심이 없다면 (노력을 한다면) 직업을 통해서 비슷한 경험을 얻을 수 있다. 어찌됐든, 혼자서 책으로만 배우는 건 부족하다. "솔과 안료를 공부함으로 전문화가가 될 수 없듯이 아무나 컴퓨터 과학 교육으로만 전문프로그램어를 만들지 못한다."라고 Eric Raymond는 The New Hacker's Dictionary에서 이와 같이 말했다. 내가 이제까지 고용한 최고의 프로그래머중 한 명은 고졸 였다. 그는 좋은 소프트웨어를 많이 만들었고, 그의 고유 뉴스 그룹도 가지고 있으며, stock option으로 나보다 더  부자 임은 틀림없다.
  •  
  • 다른 프로그래머들과 같이 프로젝트들을 하라. 때론 프로젝트의 가장 실력 있는 프로그래머가 되고; 때론 프로젝트의 가장 실력 없는 프로그래머가 되라. 가장 실력 있는 프로그래머일땐 다른 사람들에게 비젼을 주고 그리고 사람들을 이끄는 능력을 시험하게 된다. 가장 실력 없는 프로그래머일때는 고수들이 하는 것들과 그들이 싫어하는 것들을 배울 수 있다 (왜냐면, 싫어하는 것들은 당신에게 시킨다).
  •  
  • 다른 프로그래머들이 시작한 프로젝트에 뒤늦게 동참하라. 다른 사람이 짠 프로그램을 이해하도록 몰두하라. 원래 프로그래머가 없었을 때 그 것을 이해하고 고치기 위해서 무엇이 요구되는지 보라. 당신의 프로그램을 다른 사람이 유지해야 할 때 보다 더 쉽게 관리 할 수 있도록 어떻게 당신의 프로그램들을 디자인해야 할까를 고민하라.
  •  
  • 최소 다섯가지 프로그래밍 언어를 학습하라. class abstractions (자바 또는 C++) 지원하는 언어, coroutines을 (Icon 또는 Scheme) 지원하는 언어, functional abstraction (Lisp 또는 ML) 지원하는 언어, syntactic abstraction (Lisp) 지원하는 언어, declarative specifications를 (Prolog또는 C++ 템플렛) 지원하는 언어, 그리고 parallelism을 (Sisal) 지원하는 언어를 한 개  학습하라.
  •  
  • "컴퓨터 과학"안에 " 컴퓨터"가 있는 것을 기억 하라. 당신의 컴퓨터가 한 명령을 실행할 때, 메모리에서 word를 가지고 올 때, 디스크에서 연속 word를 가지고 올 때, 디스크 안에 새로운 위치를 찾을 때 걸리는 시간과 속도를 파악하라 .
  •  
  • 언어 표준화 노력에 참여하라. ANSI C++ 위원회 일 수도 있거나, 당신의 현 코딩 스타일을 2칸 아니면 4칸 들여쓰기 할 것인가를 결정할 수도 있다. 다른 사람들이 한 언어의 어떤 것을 좋아하는지, 그들에게 그 것들이 얼마나 중요한 것인지, 어쩌면 왜 그것을 좋아 하는 지까지도 알게 될 것이다.
  •  
  • 가능한 한 빠르게 언어 규격화 노력에서 해방되는 좋은 느낌을 체험 해 보라.
  •  

위의 것들을 고려할 때, 책을 통한 학습으로만 어디까지 배울 수 있을까를 의심해볼 여지가 있다. 내 첫째 아이가 태어나기 전에, 찾을 수 있는 모든 How To 책들을 읽었지만, 그래도 초보자로 느껴졌다. 30달 후에, 둘째 아이가 태어 났을때 쯤, 난 예전에 읽었던 책들을 다시 들여다 봤을까? 아니다. 대신 나는 전문가가 쓴 천장의 페이지보다도 나에게 더 유용하고 자신감을 준 내 개인 경험에 의지했다.

Fred Brooks는, 그의 에세이 No Silver Bullets에서 굉장한 소프트웨어 디자이너들을 찾아주는 three-part계획을 정의 하였다.

  1. 체계적으로 가능한 한 빨리 최고 디자이너들을 확인 하십시요.
  2. 유력 후보자의 발달과 경력 파일을 책임질 경력 지도자를 선임하십시오.
  3. 성장하는 디자이너들이 서로 자극할 수 있는 기회들을 제공하십시오.

이것들은 이미 굉장한 디자이너가 되기 위해 필요한 자질들을 가지고 있다고 가정한다. 직업이 그들을 적당하게 coax할 것이다. Alan Perlis은 그 것을 명확하게 표현한다: "조각하는 방법은 누구나 에게 가르칠 수 있다: Michelangelo는 조각 방법을 못하는 방법을 가르쳐 주어야 할 것이다. 훌륭한 프로그래머들도 마찬가지다."

 

서점으로 가서 Java/Ruby/Javascript/PHP book 같은 책을 구입한다 한들 아마 약간의 도움은 되겠지만, 그것들이 여러분의 삶을 바꾸지는 못할 것이고 24시간이나 혹은 21일의 공부로 프로그래머로서, 전문가가 되지는 못할 것이다. 적어도 2년 정도 열심히 노력하였을 때, 약간 감이라도 잡을 수 있을지 모르지만…..

 

top