임인택이 위키 항해를 하던중 xper seminar wiki에서 다음과 같은 글을 보았다.
{{|
Understandable .png ":-)")
As for the job market, Python isn't among the buzzwords that you'll find in
job descriptions most of the time. But software development isn't that much
about particular technologies, the important part is learning concepts. If
you learn Python, you won't be able to avoid learning (at least):
- Object Oriented Programming (OOP)
- Procedural Programming
There's a lot more concepts that you can learn while using Python, as you
advance a little more:
- Functional Programming
- Test Driven Development
- Dividing software into components
Ok, I'll try
Learn concepts, not tools. At least in the long run, this will make you
more attractive to employers who have a clue about what's important in the
software industry.
There are some more skills that are especially important:
- Team work: dividing up tasks. Defining the interfaces up front to avoid
- Communication/efficient problem solving: not trying yourself for days to
- Software reliability: that's a difficult one. IMO experience,
1 If you have some spare time you can learn that by joining an Open
Source project.
--
Gerhard Häring
OPUS GmbH München
Tel.: +49 89 - 889 49 7 - 32
http://www.opus-gmbh.net/
{{|
최근 파이썬 뉴스그룹에 "파이썬을 배우는 것이 가치가 있나"하는 질문을 올렸다. 다음은 거기에 올라온 답변 중 하나.
Raphael Ribeiro wrote: I wanna start learning some real programming language (I know now only
Visual Basic , but i don't find it interesting, sorry for the vb
programmers, but this is my opinion).
And I was reading some docs, which were talking about lots of programming
languages, I saw there Python, and took a look at some python sites. I
saw some snippets and read some docs and liked the language a lot. But I
don't know if this language is well-accepted in the market and if having
a good python knowledge would give me a good job.
job descriptions most of the time. But software development isn't that much
about particular technologies, the important part is learning concepts. If
you learn Python, you won't be able to avoid learning (at least):
- Procedural Programming
advance a little more:
- Test Driven Development
- Dividing software into components
I am only 17 and I'm only making plans, so if you have any suggestions
tell me.
more attractive to employers who have a clue about what's important in the
software industry.
solve a problem that could be solved a lot more efficiently by calling
the client or writing an email - I've had problems with this myself in
the past, I guess that's not an uncommon problem for developers.
the client or writing an email - I've had problems with this myself in
the past, I guess that's not an uncommon problem for developers.
concentration, unit tests, and always trying to improve on yourself help
you achieve it.
you achieve it.
Source project.
--
Gerhard Häring
OPUS GmbH München
Tel.: +49 89 - 889 49 7 - 32
http://www.opus-gmbh.net/
|}}
임인택은 1학년때에 수업시간에 보는 책을 어느정도 보았다고 생각하고 난 후, 형들한테 이런것을 많이 질문했던 기억이 난다.
임인택은 1학년때에 수업시간에 보는 책을 어느정도 보았다고 생각하고 난 후, 형들한테 이런것을 많이 질문했던 기억이 난다.
- 형, 이 책 다 보면 뭘 봐야 할까요?
- 이 언어 보고 난 다음에는 무얼 보아야 좋을까요?
지금 이 순간에 후배들이 같은 질문을 한다면 NotToolsButConcepts 라는 대답을 해주고 싶다(단, 언어도 하나의 툴이라고 가정할 경우). 1, 2년 후배를 받을 때까지는 잘 몰랐지만, 데블스캠프나 새내기가 참가하는 세미나를 찾아갈 때마다 매번 들리는 소리였다. - 이 언어 보고 난 다음에는 무얼 보아야 좋을까요?
툴이 아닌 개념 ¶
SICP를 책을 보면 예제 코드가 SchemeLanguage로 나온다. SchemeLanguage에 대해서는 잘 모르지만, 이 언어를 사용하면 개념 전달을 쉽게 할수 있어서인듯 싶다. 툴이야 몇번 쓰면 자동적으로 익혀지게 되지만(더군다나 요즈음에 나오는 툴들은 더하다) 하나의 개념, 패러다임을 자기 것으로 만드는 데에는 얼마나 오랜 시간이 걸리는가. (ToyProblems 때도, 간단한 문제를 가지고 여러 가지 방법으로 접근하였던 기억이 난다). 밥을 짓는 법을 안다면, 가스불로 만들던, 전기밥솥에 하던 상관이 없다.
예 ¶
- STL, Container, 등등이 아닌 GenericProgramming
- MFC, VB 등이 아닌 EventDrivenProgramming + 그외에 녹아있는 패러다임들.
- Java, C#이 아닌 OOP(ObjectOrientedProgramming),AOP(AspectOrientedProgramming)
- Goto 쓰지 마라! 가 아닌 GotoConsideredHarmful 같은 이야기
...
Thread ¶
1002 가 Windows Programming 을 오래 하다가 EventDrivenProgramming 의 개념을 나름대로 제대로 받아들였다는 느낌이 들었을때는 해당 플랫폼에서 1년 이상 작업했을 때 였다.(여기서 '받아들였다'는 실제 EventDriven Model로 디자인해서 구현해보는 정도) 사람들의 공부 스타일에 따라 차이가 있지만, 해당 개념에 대해 제대로 이해하기 위해선 구현레벨에서의 경험도 필요하다. 위의 '예' 에서 '아닌 - Not' 이란 단어대신 '넘어서 - Beyond' 라는 단어로 바꿔서 읽어보면 어떨까.
구현을 하는 사람은 늘 배경 개념들에 대해 사고해야 할것이며, 개념을 공부하는 사람은 구현 레벨에서의 코드와 결과물에 대해서 생각해보아야 할 것이다. 한쪽만으로의 치우침은 위험하다는 생각을 해본다. -- 1002
NeoCoin 은 이렇게만 생각했지만, 2년 전 즈음에 생각을 바꾸었다. 구지 영어로 비슷하게 표현하면 UseToolAndLearnConcepts 이랄까? 돌이켜 보면 이런 상황을 더 많이 접하였다. 언어를 떠나 같은 시기 동안에 같은 일에 대하여, 같은 도구를 사용하는데, 한달뒤의 사용 정도와 이해도가 다른 사람들을 자주 보게 된다. 도구의 사용 능력 차이가 재미와 맞물려서 도메인의 사용 폭의 이해도 역시 비슷하게 따라오는 모습을 느낄수 있었다. 멋진 도구에 감탄하고, 사용하려는 노력 반대로 멋지지 않은 도구에서 멋진 면을 찾아내고 사용하려는 노력 이둘은 근본적인 Concept을 배우는 것과 멀리 떨어진것은 아닌것 같다.
--NeoCoin
NotToolsButConcepts라는 말은 수사적인 표현으로 용납할만한 범위에 든다고 봅니다.
{{|
Teach them skepticism about tools, and explain how the state of the software development art (in terms of platforms, techniques, and paradigms) always runs slightly ahead of tool support, so those who aren't dependent on fancy tools have an advantage. --Glenn Vanderburg, see 
AgilityForStudents|}}
저는 이 페이지가 컴퓨터 과학 뿐만이 아니고 대학생들의 공부 전반과 관련된 문제라고 생각합니다. 대학에서 무엇을 배워야 하는가? 무엇을 배우려고 노력해야 하는가? 저는 그것이 도구이건, 개념이건 간에, 그것이 좀더 근본적이고, 그것을 만든 사람의 사유에 근접할 수 있는 것이고, 그것을 배우는 과정에서 자신의 사고 근육을 제대로 단련할 수 있는 것이어야 한다고 봅니다.오도할 위험을 안고 구체적인 예를 한가지 든다면, Sway라는 GUI 라이브러리를 공부할 때, 동시에 Sway를 만든 사람(그리고 그 사람의 아버지, ...)의 머리속과 사고과정을 들여다보고(관련 선구적 논문들을 찾아보고), 그것과 동기화해보고, 다시 그것에 대해 스스로 판단을 내려보는 노력을 하고, 이를 다시 간단하게 구현해서 실험해 보고 하는 것을 반복하는 것이 제가 봤을 때에, NotToolsButConcepts의 정신에 맞지 않나 하는 생각이 듭니다. 이것이 제가 배운 "제대로 학문하는 법"입니다. 남의 최종 결과물(artifact) 속에서만 계속 놀지 말고, 그가 그걸 만들어낸 문제의식과 과정을 내 몸으로 직접 체험해 보고 거기에 나 스스로 판단을 내려 보는 것입니다.
가족오락관에서 보면 여러명이 일렬로 서서, 맨 끝의 한 사람에게만 속담이나 사자 성어를 하나 보여주고, 그걸 몸짓으로 차례로 전달해서 마지막 사람이 맞추는 게임이 있습니다. 최초 몸짓을 하는 사람의 의도를 이해하지 않고 그 모션을 그대로 이용할 수는 있습니다. 하지만 그 내면적 의미를 꿰뚫고 있지 못하다면, 비록 아무리 잘 관찰을 했다고 해도 나는 분명 모션의 일부를 왜곡하거나 빠트린 채 전달을 하겠지요. 그러나 이용을 계속 하다보면 우연히(그러나 꽤 오랜 시간 후에) 그 의도를 깨칠 수도 있겠지요. 하지만 우리는 "의도적으로" 그 사람의 의도를 들여다 보려는 노력을 해야 합니다 -- 그 사람의 사고를 거슬러 올라가기도 하는 등 여러 방법을 동원해서 말이죠. 그렇게 되면 우리는 똑같은 사자 성어에 대해 훨씬 더 우아하고 더 단순하며 명료하게 다듬은 모션을, 혹은 전혀 다른 모션을 새로이 창조해서 다음 사람에게 전달할 수도 있지 않겠습니까?
--JuNe
See Also 무엇을공부할것인가
