Simon Sinek: How great leaders inspire action
싸이먼 시넥: 어떻게 훌륭한 리더들이 실제 행동(action)을 이끌어 내는 영향력(inspire)을 가질 수 있는가

사실 제목만 보면 좀 그렇죠... 18분 동안의 발표에서, 어떻게 훌륭한 리더들이 실제 행동(action)을 이끌어 낼 수 있는 영향력(inspire)을 가질 수 있는지 설명한다는 것 자체가 만병통치약을 파는 것과 같은 기분을 느끼게 한다. 하지만 자신의 정리된 논리와 몇 가지 실질적인 예를 들어 가면서 좋은 이야기들을 많이 하고 있다. 예를 들어, "무엇을 하는가? (What)" 보다는, "어떻게 하는가? (How)"에 더 무게를 두고, "어떻게 하는가? (How)"보다는 "왜 하는가? (Why)"가 더 중요하다는 이야기를 발표자가 만든 골든 써클(Golden Circle)이라는 그림으로 설명하고 있다.  이 부분에 대해서는 너무나 공감이 간다. 한 팀의 리더로서 팀원들에게 우리가 무엇을 해야 하는지 함께 공유하는 것도 꼭 필요하고 좋은 일이지만, 더 중요한 것은 우리가 왜 해야 하는지를 공유하고 공감을 이끌어내는 것이 훨씬 중요하다고 생각한다.

영상 중간쯤에서 다음과 같은 이야기를 듣는 순간 몇일전에 있었던 NHN 사건이 딱 떠올랐다.

If you hire people just because they can do a job, they’ll work for your money. But if you hire people who believe what you believe, they’ll work for you with blood and sweat and tears.

사람을 고용할 때, 단지 그 일을 할 수 있는 능력이 있는지만 보고 그 사람을 고용한다면, 그들은 돈을 위해 일을 할 것이다. 하지만 내가 믿고 있는 것을 공유하고 그러한 내 믿음을 이해하고 그것들을 함께 믿을 수 있는 사람을 찾을 수만 있다면, 그들은 자신들이 가진 모든 능력을 펼치며 열의를 가지고 땀흘려 일할 것이다.

(여기까지만 이야기했다면 그냥 좋은 이야기라고 생각하고 지나칠 수도 있지만, 실제 라이트 형제 일화를 예를 들어서 설명하고 있다. 더 자세한 이야기는 테드 영상을 참고하기 바란다.)

NHN 사건에 대한 자세한 이야기는 "한국에서 소프트웨어 개발자의 위치…" 포스팅을 참고하기 바란다. NHN의 리더들이 자신들이 믿고 있는 것들을 직원들에게 공유하고 그러한 믿음을 이해시킬려고 얼마나 많은 노력을 했는지 궁금하다.

또한 영상 중간에서 자신이 이야기 하는 골든 써클이 단지 자신의 의견만은 아니라는 이야기를 하면서 사람의 뇌에 대한 이야기를 한다. 골든 써클이 사람의 뇌와 동일한 구조를 가지고 있다는 것이다. 따라서 골든 써클은 심리학(Psychology)에 기반을 둔 의견이 아니라, 사람의 뇌의 구조인 생물학(Biology)에 기반을 두고 있다는 이야기이다. (* 테드 한글 자막에 문제가 있어 보인다. 한글 자막에서는 심리학도 생물학도 아니다라고 번역을 해 놓았는데, 그 문장을 보나 전체적인 이야기를 보나, 심리학이 아닌 생물학에 근거를 두고 있다고 이야기하는 것이 맞다.)

사람의 뇌(brain)를 횡단면(cross-section)으로 보면, 크게 3가지 부분으로 나눌 수 있다는 이야기를 하며, 이렇게 나누어진 부분들이 담당하는 것들이 자신이 이야기한 골든 써클과 일치한다는 이야기를 하고 있다. 뇌에서 제일 바깥부분에 있는 대뇌 신피질(neocortex)에서는 이성적인 것들, 합리적인 것들, 논리적인 생각들 그리고 언어를 담당하고 있는데, 이것들이 골든 써클의 가장 바깥부분에 있는 "무엇(What)"과 일맥상통한다는 것이다. 또한 뇌의 안쪽에 있는 대뇌 변연계(limbic)는 우리의 믿음이나 충성심 같은 감정(feeling)들을 담당하고 있는데, 이 부분은 골든 써클의 안쪽에 있는 두 부분, 즉 "어떻게(How)"와 "왜(Why)"와 일맥상통한다는 것이다.

이부분을 보면서 지난번에 읽은 뽀모도로 테크닉에 대한 책 "[Book] POMODORO TECHNIQUE ILLUSTRATED"이 생각났다. 이 책 18페이지를 보면, Chapter 2. Context => The Brain Stack에 대해서 설명하고 있다. 이 책의 저자는 뇌를 4부분으로 나누고 있다: 뇌간(brain stem), 대뇌 변연계(limbic system), 대뇌피질(cortex) 그리고 대뇌 전두엽(frontal lobe). 이 책에서 말하는 뇌의 구조와 담당하는 것들에 대해서는 다음 기회에 다시 한번 자세하게 이야기해 보도록 하겠다.

이미지 출처: Manifesto for Agile Software Development

애자일 개발(Agile Development)이라고 하면 웬지 큰 기업이 아닌 작은 기업에서만 받아들이고 적용할 것 같은 오해가 있다. 예를 들면, 마이크로소프트와 같은 큰 기업에서는 애자일을 사용하지 않을 것 같고, 작은 벤처로 시작한 구글과 같은 기업에서 웬지 많이 사용될 것 같은 생각이 든다. 하지만 마이크로소프트는 이미 애자일을 지원하는 개발툴까지 있다고 하면 믿을 수 있겠는가? 또한 애자일의 대표격인 스크럼(Scrum)의 아버지라고 불릴 수 있는 Jeff Sutherland가 마이크로소프트의 애자일 부분을 여러모로 도와주고 있는 것 같다. (스크럼은 1993년에 Jeff Sutherland와 Ken Schwaber에 의해서 만들어졌다.) 오늘은 마이크로소프트에서 지원하고 있는 애자일 분야에 대해서 아주 간단하게 이론적인 것들만 소개 하고자 한다. 사실 사용해보지를 않아서 MSDN(MicroSoft Developer Network: 마이크로소프트 개발자 네트워크)에서 제공하는 애자일 관련 문서들만 소개하려고 한다.

마이크로소프트 비주얼 스튜디오(Microsoft Visual Studio) 2010에서는 애플리케이션 수명 주기 관리(ALM: Application Life-cycle Management)의 소스 및 형상관리, 리포팅, 테스팅 등 모든 업무를 통합 지원하고 있다. (참고: http://www.microsoft.com/korea/press/pressroom/2010/04/04.aspx) 애플리케이션 수명 주기 관리에서도 프로젝트 계획과 추적(Visual Studio Application Lifecycle Management - Planning and Tracking Projects)에 대한 MSDN의 설명을 보면 성공하는 프로젝트들이 가지는 특징을 다음과 같이 소개하고 있다.

  이미지 출처: http://msdn.microsoft.com/en-us/library/dd286619.aspx

(* 사실 한글 문서도 지원하고 있고, 자동 번역이 아니라고 명시되어 있음에도 이해하기 어렵거나 오해를 불러올 수 있는 번역들이 있어서 직접 번역/의역을 했다.)

• 고객의 요구(the needs of the customers)에 따라 프로젝트가 나아가는 방향이 결정된다.
• 프로젝트를 완료하기 위한 상위 레벨의 계획(high-level plan)을 가지고 있다.
• 여러 번의 반복(several iterations)을 통해 제품을 개발하면서 진행 상황에 따라, 필요하다면 이미 가지고 있는 상위 레벨의 계획(high-level plan)도 프로젝트가 나아가는 방향에 따라 수정할 수 있다.
• 프로젝트에 변경 사항이 발생했을 때, 이러한 변경사항들을 잘 받아들일 수 있는 효율적인 툴들을 팀원들이 사용하고 있다.

또한 프로세스 가이드로 다음과 같은 3가지의 제품들을 지원하고 있다.

• Visual Studio Scrum 1.0
• MSF for Agile Software Development v5.0
• MSF for CMMI Process Improvement v5.0

역시 마이크로스프트 답게 스크럼, 애자일 그리고 CMMI까지 지원하고 있다. 각각의 제품들에 대한 자세한 사항들은 링크를 통해서 확인할 수 있다. 여기에서는 MSF for Agile Software Development v5.0에 대해서 좀 더 살펴보겠다. 링크를 클릭해서 들어가보자.

우선 다음과 같은 간단한 소개가 나온다.

Your team can apply agile practices more easily by using the process template for MSF for Agile Software Development v5.0 with Visual Studio Application Lifecycle Management (ALM). The template and this guidance will help you practice Scrum and apply agile engineering practices. These processes and practices come from Scrum, eXtreme Programming, and other agile methodologies, as Agile Principles and Values, by Jeff Sutherland describes.

비쥬얼 스튜디오 애플리케이션 수명 주기 관리 패키지에 포함되어 있는 MSF for Agile Software Development V5.0에서 제공하는 프로세스 템플릿을 사용하면 애자일 실천사항(agile practices)을 더 쉽고 간단하게 팀에 적용할 수 있다. 제공되는 템플릿과 이 가이드가 스크럼을 사용하고 애자일에서 말하는 여러가지 실천사항들을 적용하는데 큰 도움이 될 것이다.  여기에서 소개하고 있는 프로세스들과 실천사항들은, Jeff Sutherland가 이야기하는 애자일 원칙과 가치(Agile Principles and Values)에서 설명하는 것처럼 스크럼, 익스트림 프로그래밍(XP: eXtreme Programming)과 다른 여러 애자일 방법론(agile methodology)들에 그 뿌리를 두고 있다.

이 소개에 이어서 단순해 보이면서도 애자일 개발의 큰 그림을 볼 수 있고, 마이크로소프트가 애자일 개발 중에서도 어떤 부분을 중요시 여기는지를 볼 수 있는 다음과 같은 그림을 소개하고 있다.

또한 더 자세한 정보들은 다음과 같은 하위항목들을 통해서 설명하고 있다. 링크를 클릭하면 더 자세한 정보들을 볼 수 있다.

• 스크럼 - Scrum
• 공학적인 측면의 실천사항들 - Engineering Practices
• 산출물 (애자일) - Artifacts (Agile)
• 역할 분담 - Roles
• 미팅 (애자일) - Meeting (Agile)

각각의 링크를 클릭해서 정보들을 보면 알겠지만, 아주 자세한 실제적인 설명보다는 좀 더 개념에 치우친 간단한 설명들이 나온다. 하지만 그것만으로도 마이크로소프트가 어떻게 애자일을 생각하고 지원하고 있는지 이해할 수 있을 것이다. 기회가 된다면 MSF for Agile Software Development V5.0을 한번 사용해 보고 싶다. 어느 정도까지 지원을 하고 있는지...

각각에 대한 설명들은 관심있으신 분들은 들어가서 읽어보시기를 권한다. 다음에는 이 자세한 설명들 보다는 위에서도 잠깐 언급되었던, 스크럼의 아버지라고 불릴 수 있는 Jeff Sutherland가 쓴  애자일 원칙과 가치(Agile Principles and Values)에 대해서 알아보겠다. 아마 이 글이 마이크로소프트에서 애자일을 지원하는데 있어 근간을 이루지 않을까 싶다.

이해진 "편해서 네이버 왔다는 직원에 억장 무너져"

기사에서 언급하고 있는 NHN의 위기론이나 직원들을 독려 하고자 한 얘기까지는 이해가 가는데, (사실 어디까지가 진실인지는 모르겠지만) 몇 가지 부분에서 시대를 거슬러 가고 있는 것 같다.

NHN이 출근 시간을 오전 10시로 정한 것은 전날 야간 근무를 새벽까지 하는 직원들이 많았기 때문이다. 오랜 시간 사내에서 근무하는 직원들을 위해 최첨단 환기 시스템을 도입했고 100만원이 넘는 의자도 제공했다. 하지만 요즘은 오후 7시에 퇴근하고 다음날 오전 10시에 출근하는 직원들이 많다는 것이다. 이 의장은 “출근 시간을 늦추고 사무 환경을 개선한 것은 절박하고 치열하게 일하는 직원들을 위했던 것”이라며 “하지만 지금은 경쟁사와 비교했을 때 NHN은 노동 강도가 가장 약한 곳”이라고 비판했다.

예전에 NHN 관련 기사를 읽으며, 야근하는 직원들을 위한 배려로 의자도 좋은 것으로 바꾸어 주고 환기 시스템도 바꾸었다는 이야기는 들었다. 하지만 이제는 주객이 전도되는 느낌이다. 위 인터뷰가 사실이라면, 야근하는 직원들을 배려했다기 보다는, 직원들에게 회사에 대한 불평없이 야근을 더 많이 시키기 위해서 그런 혜택들을 주었다라는 느낌밖에 들지 않는다. 그럼 야근을 하는 직원들은 좋은 의자와 최첨단 환기 시스템을 사용할 수 있고, 야근을 안 하는 직원은 사용하면 안되는 것인가? 예전에 기사를 읽으면서 직원들을 배려하는 NHN이라는 회사와 회사 리더쉽들에게 가졌던 환상이 일순간에 무너지는 것 같다.

또한 한국 최고의 IT회사의 최고전략책임가라는 직책을 가지신 분이 아직까지도 소프트웨어 개발이라는 공장에서 부품 찍어내는 것과 동일하다는 생각을 하는 것 같아서 참 실망이다. 위 인터뷰를 어떻게 정리했는지, 실제로 이해진 이사가 했던 말은 무엇인지 모르겠지만, 인터뷰만 보자면 야근을 안 하기 때문에 NHN은 노동 강도가 가장 약한 곳이라는 논리를 펴고 있다. 역시 한국은 아직도 그냥 의자에 앉아서 오랜 시간을 때우기만 하면 일을 열심히 하고 잘 하는 직원이구나 라는 생각이 들었다. 10년전에 한국에서 3년간 일하면서 그런 문화때문에 참 많은 고민을 하고 왜 그런 문화가 정착되었을까 라는 의문을 많이 품었는데, 10년이 지난 오늘날에도 동일한 논리가 NHN의 최고전략책임가의 인터뷰에서 나왔다는 사실에 실망하지 않을 수 없다.

그렇다면 이해진 최고전략책임가가 하고 싶은 것들은 무엇일까?

그는 “요즘 NHN은 게임과 서비스 출시도 늦고 콘텐츠마저 ‘엣지(독창성)’가 없다는 이야기가 들린다”며 “매일 아침 구글, 애플 등 글로벌 정보기술(IT)기업들과 경쟁사들이 새로운 서비스를 내놓았다는 뉴스를 볼 때마다 스트레스를 받는다”고 말했다.

참 아이러니 하다. 게임과 서비스 출시가 늦고 콘텐츠의 독창성을 살려서 구글, 애플 등과 같은 글러벌 IT 기업들과 경쟁하고 싶은데, 그렇다면 그 방법이 바로 직원들이 야근을 많이하면 된다는 것인가? 정말 NHN 직원들이 야근만 많이 하면 NHN이 구글, 애플과 같은 기업들을 쫓아갈 수 있다고 생각하는 것일까?

이 의장은 “이용자의 요구를 악착같이 파악해 독하게 추진하는 기업이 결국 이겼다”며 “NHN에는 혁신이 더 이상 없고 독점적 지위로 경쟁사를 압도해 1등을 했다고 이야기하지만 IT산업 특성상 이용자를 배려하는 혁신 없이는 계속 1위를 지킬 수 없다”고 말했다.

이용자의 요구를 악착같이 파악해 독하게 추진하는 기업이 결국 이겼다고 하는데, 애플이나 구글같은 기업을 말하는 것일까? 구글의 검색기능이 애플의 아이폰이라는 제품이 이용자의 요구를 악착같이 파악해 독하게 추진했기 때문에 나온 결과물일까? 정말 애플과 구글의 리더들은 회사 직원들이 야근을 더 많이 하라고 여러가지 혜택들을 제공하고, 거기에 맞춰 모든 직원들이 야근에 야근을 거듭해서 혁신적인 결과물들을 얻은 것인지 묻고 싶다.

이 기사가 나온 이후로 많은 글들이 올라왔다. 다음의 글들도 읽어보시면 더 큰 숲을 볼 수 있을 것 같다.

내 경력에는 조기축구회 4년이 있다.

NHN 개발자들이 떠난 이유를 이해진 CSO는 정말 모를까?

NHN 개발자들은 왜 떠나는가?

NHN 내부 분위기가 기사화 되고 있다.

사실 소프트웨어 개발자로 일을 하다보면 야근을 하게 되는 경우도 많다. 이렇게 야근을 해서 좋은 제품을 만들고 새로운 혁신을 위한 아이디어가 나올 수도 있다. 하지만 이러한 정의의 역이 성립한다고 생각한다는 발상 자체가 이해가 안간다. 즉, 좋은 제품을 만들고 새로운 혁신을 위한 아이디어가 나오도록 야근을 해야 한다는 말은 어불성설이다. NHN의 성공신화의 바탕에 좋은 제품을 만들어내고 혁식을 위한 아이디어가 많이 나올 때 직원들이 많이 야근을 했을것이다. 부인할 수 없는 사실이지만, 왜 그 당시에 직원들이 야근을 많이 했는지에 대해서는 왜 관심을 가지지 않을까? 모든 일이 그렇지만 소프트웨어 개발도 사람과 사람이 함께 하는 일이다. 야근이라는 팩트 하나만을 보지 말고, 더 큰 숲을 본다면 이런 인터뷰가 신문에까지 나는 일은 막을 수 있지 않았을까 생각된다.

또한 이 사건으로 말하기의 중요성을 다시한번 실감하게 되었다. 사실 이해진 최고전략책임가도 이런 의미만을 가지고 사내강연을 하지는 않았을거라고 믿고 싶다. 자기가 전달하려는 주제가 오해를 불러일으키고 잘못된 방향으로 소개된것이 아닐까 싶다. 물론 야근도 훌륭한 제품을 만들어내는 데 도움이 되는하나의 요소가 될 수는 있다고 생각하고 동의한다. (물론 매일 매일 야근을 반복하는 것은 궁극적으로 제품의 질에 긍정적인 영향을 끼치지 않고, 부정적인 영향을 끼친다고 믿는다.) 자기의 생각과 의견을 대중들에게 제대로 그리고 정확하게 전달하는 것, 어느 분야의 어느 위치에 있든지 꼭 필요한 능력이 아닐까 싶다.

마지막으로 이 기사를 읽은 바로 그날, 우연히 보게된 하나의 동영상을 공유하면서 마무리를 하고 싶다.

날개없는 선풍기로 유명해진 Dyson이라는 회사의 사내 이벤트라고 한다. 가장 빠른 고카트(go-kart)를 만드는 사내 경진대회이다. 다만 회사에서 구할 수 있는 여분의 부품(using a few Dyson spare parts)들을 사용해서 만들 수 있고, 또한 동력에 해당하는 부분은 Dyson의 모터만(all the torque they could eke out from one of our handheld motors)을 사용해야 한다. 참여하고 구경하는 엔지니어들의 정말 즐겁고 행복한 모습이 보이지 않는가? 가장 빠른 고카트를 뽑는 대회인데도 불구하고, 자기가 만든 고카트를 타고 달리는 참가자의 희열을 느낄 수 있을 것 같다.

이런 회사의 마인드와 문화가 선풍기는 날개가 있어야 한다는 기존의 개념을 완전히 깨고, 날개 없는 선풍기를 만들어내는 원동력이 되지는 않았을까? Dyson의 리더진들은 왜 회사돈을 써 가며, 직원들의 시간을 뺏어가며 이런 사내 이벤트를 개최하는지 한국의 IT를 이끌어 가시는 분들이 한번쯤은 생각해 줬으면 한다.

Image source: http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/

When we decide how much we need to do test during TDD, we don't need to worry and spend a lot of times to decide the coverage and steps in detail. Let's see the Kent Beck's advice:

This is the kind of tuning you will be doing constantly with TDD. Are the teeny-tiny steps feeling restrictive? Take bigger steps. Are you feeling a little unsure? Take smaller steps. TDD is a steering process - a little this way, a little that way. There is no right step size, now and forever.

- Page 42

Image source: http://www.raynauds.org/index.php/2011/04/heated-steering-wheel-cover-news/

Page 46, Test-Driven Development by Example written by Kent Beck

Moreover, we need to abandon our habit even though we are excellent software engineers. Don't try to do everything by ourselves! Pass our works to computers or tools. That's why we have developed the computers and tools we are using.

In teaching TDD, I see this situation all the time - excellent software engineers spending 5 to 10 minutes reasoning about a question that the computer could answer in 15 seconds.

- Page 46

Page 47, Test-Driven Development by Example written by Kent Beck

I know that I show the message - "All code is guilty until proven innocent" above. However there is an exceptional case, as always. In page 47, Kent Beck is trying to do implement "toString()" method without a test! If there are understandable reasons, then you need to accept it.

Whoa! Code without a test? Can you do that? We could certainly have written a test for toString() before we code it. However,
-. We are about to see the results on the screen.
-.  Because toString() is used only for debug output, the risk of it failing is low.
-. We already have a red bar, and we'd prefer not to write a test when we have a red bar.
Exception noted.

- Page 47

Do not forget the principle and purpose! Our purpose is developing software, not the TDD itself!

Happy TDD!

Copy-and-paste reuse? The death of abstraction? The killer of clean design?

Not always...

The following cycle doesn't finished yet...

1. Write a test.
2. Make it compile.
3. Run it to see that it fails.
4. Make it run.

[Trying to do "copy-and-paste" here...]

5. Remove duplication.

The cycle is not complete. The first four steps of the cycle won't work without the fifth.

Don't be worry about doing "copy-and-paste", if the "copy-and-paste" is not a purpose, but a mid-step. Of course, it could be happened when we need to do "copy-and-paste". Please see the principle(essence), not superficial, why we would suggest not to use "copy-and-paste".

Focus on promising ourselves we wouldn't go home until the duplication was gone.

PRAGMATIC LIFE Serise

POMODORO TECHNIQUE ILLUSTRATED

" THE EASY WAY TO DO MORE IN LESS TIME "

Finally I have just finished reading this book. Here is "About this Book" from official page:

About this Book

You have so much you need to accomplish today. Your list is a mile long and you find yourself getting interrupted every other minute. You’d like to tell everyone to leave you alone, but most of the interruptions are coming from you! You think of a phone call you need to make or a web site you need to check and before you know it you’re answering email, checking Twitter, and finding a million other things to occupy your time.

You need to focus—-really focus.

The Pomodoro Technique puts you back in charge of your day. You’ll apply successful techniques from software engineering to identify what you should be doing today and to help you achieve your goals. Your mind won’t wander when it is fully engaged in short bursts of focused activity.

Learn to work less and accomplish more using nothing more than paper, pencil, and a simple kitchen timer.

Set the timer and start on your next Pomodoro. When the bell rings take a break. This personal approach to timeboxing is at the core of the Pomodoro technique and this book is filled with advice on how get started and how to tailor it to your own needs.

- from Pragmatic Bookshelf

Yes, it is not a programming book, but this was recommended by several famous programmer, e.g., Ron Jeffries.

Staffan gives us the theory and practice of Francesco Cirillos's Pomodoro Technique in an enjoyable package with wonderful illustrations. This is a delightful and useful book!

- Ron Jeffries, www.XProgramming.com

After all, it is a book regarding "Time Management". The sub-title, The easy way to to more in less time", shows the purpose of this book. The author introduces a lot of ideas about how we can work out effectively within our time provided. Most of them are quite interested and worthy to try and practice. However i don't think it is easy to put in practice in our real life.

Especially for programmers who are interested in Agile Software Development practice, they can easily find out that some ideas and practices are really similar to those practices from Agile side. It is not a book which is hard to understand, so if you are an Agile developer or interested in Agile, it is worthy to invest your time to read. You can broaden your knowledge, even though you don't follow those practices introduced.

I agree with and like the main theme in this book, concentration. I know that the concept of multi-tasking is a key area in computer science nowadays, and it gives remarkable benefits to our life. However I believe that the human being is not same as machine. So we need to consider a lot of things to maximize the benefit of multi-tasking. That's why I still believe that the most effective and efficient way to work is a concentration, for people. The author in this book also devotes first chapter on this with "One Activity at a Time" title.

Here is the Contents in chapter level:

Foreword by Francesco Cirillo

Foreword by Henrik Kniberg

1. One Activity at a Time

2. Context

3. Mechanics

4. Interruptions

5. Estimate

6. Adapt

7. Team

A. Process Map

B. Resources

C. Afterword

D. Bibliography

You can find out Full Table of Contents PDF file from here: http://media.pragprog.com/titles/snfocus/toc.pdf

It is very easy to read and acquire a knowledge from this book, because this book has the big illustration on every page (I love it! ) and it has been written by essay type. However it will be really hard to put the knowledge into practice! If you follow those ideas and practices accordingly, then I believe that you will be properly rewarded for the effort you made!

Don't forget that "Practice makes perfect!".

Research Experience: A Ticket to Graduate School

I totally agree with the author. If it is hard to get good admission offer from the school you want to go further, then the Research Assistant will be a good opportunity.

Engaging in research is a worthwhile experience, regardless of whether you choose to attend graduate school, because it provides you with the opportunity to think, organize information, and problem solve, and demonstrate your commitment, reliability, and capacity for research.

 However, there is a positive payoff from conducting research with faculty only if you perform competent work consistently. If you don't take the commitment seriously, are unreliable, or make repeated mistakes, your relationship with the faculty member will suffer (as will your recommendation).

Happy reading!