반응형
반응형
프로그래밍에서 인지 편향

http://www.mimul.com/pebble/default/2018/01/05/1515145860439.html?utm_medium=social&utm_source=gaerae.com&utm_campaign=%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%8A%A4%EB%9F%BD%EB%8B%A4

개발자로서써, 우리는 생산성을 방해하는 다양한 문제에 대해 잘 알고 있다. 하지만, 우리는 큰 관점에서 생각하는 것을 놓치는 경우가 종종 있다.

어떤 것은 인지하기 힘든 미세한 것일수도, 어떤건 큰 영향을 주는 것일수도, 여러분이 잘 처리 할 수 있는 것일수도, 잘 못할 수도 있는 것들이 존재한다. 이러한 모든 요소가 하나로 결합되어 일종의 내부 피드백 루프를 형성하여 생산성 저하, 버그 및 큰 좌절로 이어질 수 있다.

이들 한, 두가지의 영향을 최소화 할 수 있다면 그 주기(나쁜 사이클)를 깨고 나머지 것들을 무력화시킬수도 있다. 여기에서는 프로그래밍할 때 여러분들이 알아야 할 5가지 인지 편향에 대해 이야기해 본다.


과도한 가치 폄하(Hyperbolic Discounting)

나중의 더 큰 보수 대신에 지금 당장의 이익을 우선시 하는 것.

여러분중에 테스트 코드 작성을 연기 한 적이 있나요? Vim 사용중에, 화살표 키를 사용하여 커서를 이동시킨적이 있나요? 축하해요. 여러분은 과도한 가치 폄하를 보여준 것이에요. 당장의 이득에 눈이 멀어 화살표 키를 사용한다는 것은 올바른 구문을 찾기 위해서 정확한 라인으로 이동하는 과정에는 큰 고통(긴 시간)을 초래한다. 당장 익숙하지 않는 HJKL을 익힌다면 원하는 곳으로 빨리 갈 수 있어 미래의 이익은 훨씬 높아진다. 결과적으로, 당신은 많은 시간을 절약하게 된다.

이케아 효과 (IKEA Effect)

문제에 대한 자신의 해결책은 과대 평가하는 반면, 다른 솔루션을 과소 평가하는 것.

이케아 효과는 소비자가 직접 조립해서 만든 제품을 훨씬 고 평가(더 많은 가치를 줄 것이라는)하는 경향이 있는데, 이것 또한 인지 편향이다. 우리는 문제에 대한 자신의 해결책을 과대 평가하는 경향이 있고, 반면에 다른 해결책은 과소 평가하는 경향이 있다. 만약, 당신이 멋지고 독창적인 도구가 아닌 그저 그런 사내 도구를 사용하여 회사에 일한 적이 있다면, 내가 무슨 말을 하고 싶은 것인지 알 것이다. 

어설픈 최적화 (Premature Optimization)

필요한 것을 이해하기도 전에 최적화하는 것.

자명하다. 엔진을 고치지 않고 낡은 자동차를 빨리 달라게 하는데에 공기 역학적 스포일러 날개를 추가하는 것은 전혀 도움이 되지 않는다. 가장 좋은 예로 실험에 목표를 둔 코드에 성능적으로 완벽한 코드를 작성하는 것이다. 

계획 오류 (Planning Fallacy)

작업을 완료하는 데 필요한 시간을 낙관적으로 예상하는 것

계획 오류(Planning Fallacy)는 대부분의 사람에 관련된 이야기다. 그것이 우리든, 프로젝트 매니저든, 제품을 사용하는 고객이든 실제로 언제 작업이 끝날지에 대해 낙관적인 경향이 있다. 이것은 아래 격언이 잘 설명해 준다 : 코드의 첫 90%가 개발 시간의 첫 90%를 차지하고, 코드의 나머지 10%가 또 다른 90%의 개발 시간을 차지한다. 즉, 총 180%를 소요하게 되는 의미로, 당초 예상한 기간보다 훨씬 초과하는 경향을 표현한 것이다. (90 대 90의 법칙) 

최신 편향(Recency Bias)

과거에 일어난 일보다 최근의 사건에 높은 가치를 두는 것. 최신 경험을 더 가치있다고 생각하는 것.

최신 편향(Recency Bias)은 문제를 해결해야 할 때 자주 마주치곤 한다. 우리는 비슷한 문제를 해결했기 때문에 그 해결책을 사용하자. 명심하자. 동일한 디자인 패턴을 반복해서 사용하는 자신을 발견하지 않았냐? 그렇다면, 당신은 같은 시각으로 다른 문제를 들여다보고 있는지도 모른다. 우리는 바이어스(편견)를 완전히 제거할 수는 없다. 그러나, 편견이 우리에게 어떻게 영향을 미치고 있는지를 앎으로써 그것이 야기하는 문제를 완화시킬 수는 있다. 


...
반응형
반응형
How to be a Programmer: A Short, Comprehensive, and Personal Summary

프로그래머가 되는 방법: 짧고 폭넓고 개인적인 요약.

 

 

1. 도입
2. 초보자
2.1. 개인적 기능들
2.1.1. 디버그 배우기
2.1.2. 문제 공간을 나눠서 디버그 하는 방법
2.1.3. 오류를 제거하는 방법
2.1.4. 로그를 이용해서 디버그 하는 방법
2.1.5. 성능 문제를 이해하는 방법
2.1.6. 성능 문제를 해결하는 방법
2.1.7. 반복문을 최적화하는 방법
2.1.8. I/O 비용을 다루는 방법
2.1.9. 메모리를 관리하는 방법
2.1.10. 가끔씩 생기는 버그를 다루는 방법
2.1.11. 설계 기능을 익히는 방법
2.1.12. 실험을 수행하는 방법
2.2. 팀의 기능들
2.2.1. 시간 추정이 중요한 이유
2.2.2. 프로그래밍 시간을 추정하는 방법
2.2.3. 정보를 찾는 방법
2.2.4. 사람들을 정보의 원천으로 활용하는 방법
2.2.5. 현명하게 문서화하는 방법
2.2.6. 형편없는 코드를 가지고 작업하기
2.2.7. 소스 코드 제어 시스템을 이용하는 방법
2.2.8. 단위별 검사를 하는 방법
2.2.9. 막힐 때는 잠깐 쉬어라
2.2.10. 집에 갈 시간을 인지하는 방법
2.2.11. 까다로운 사람들과 상대하는 방법
3. 중급자
3.1. 개인적 기능들
3.1.1. 의욕을 계속 유지하는 방법
3.1.2. 널리 신뢰받는 방법
3.1.3. 시간과 공간 사이에서 균형을 잡는 방법
3.1.4. 압박 검사를 하는 방법
3.1.5. 간결성과 추상성의 균형을 잡는 방법
3.1.6. 새로운 기능을 배우는 방법
3.1.7. 타자 연습
3.1.8. 통합 검사를 하는 방법
3.1.9. 의사소통을 위한 용어들
3.2. 팀의 기능들
3.2.1. 개발 시간을 관리하는 방법
3.2.2. 타사 소프트웨어의 위험 부담을 관리하는 방법
3.2.3. 컨설턴트를 관리하는 방법
3.2.4. 딱 적당하게 회의하는 방법
3.2.5. 무리 없이 정직하게 반대 의견을 내는 방법
3.3. 판단 능력
3.3.1. 개발 시간에 맞춰 품질을 조절하는 방법
3.3.2. 소프트웨어 시스템의 의존성을 관리하는 방법
3.3.3. 소프트웨어의 완성도를 판단하는 방법
3.3.4. 구입과 개발 사이에서 결정하는 방법
3.3.5. 전문가로 성장하는 방법
3.3.6. 면접 대상자를 평가하는 방법
3.3.7. 화려한 전산 과학을 적용할 때를 아는 방법
3.3.8. 비기술자들과 이야기하는 방법
4. 상급자
4.1. 기술적 판단 능력
4.1.1. 어려운 것과 불가능한 것을 구분하는 방법
4.1.2. 내장 언어를 활용하는 방법
4.1.3. 언어의 선택
4.2. 현명하게 타협하기
4.2.1. 작업 일정의 압박과 싸우는 방법
4.2.2. 사용자를 이해하는 방법
4.2.3. 진급하는 방법
4.3. 팀을 위해 일하기
4.3.1. 재능을 개발하는 방법
4.3.2. 일할 과제를 선택하는 방법
4.3.3. 팀 동료들이 최대한 능력을 발휘하게 하는 방법
4.3.4. 문제를 나누는 방법
4.3.5. 따분한 과제를 다루는 방법
4.3.6. 프로젝트를 위한 지원을 얻는 방법
4.3.7. 시스템이 자라게 하는 방법
4.3.8. 대화를 잘 하는 방법
4.3.9. 사람들에게 듣고 싶어 하지 않는 말을 하는 방법
4.3.10. 관리상의 신화들을 다루는 방법
4.3.11. 조직의 일시적 혼돈 상태를 다루는 방법
5. 참고 문헌
5.1. 
5.2. 웹 사이트
6. 역사 (2003년 5월 현재) / History (As Of May, 2003)
6.1. 피드백 및 확장 요청 / Request for Feedback or Extension
6.2. 원본 / Original Version
6.3. 원저자의 경력 / Original Author's Bio

 

.

반응형
반응형

프로그래머에게 필요한 5가지 덕목

         
프로그래머에게 필요한 5가지 덕목

1. 모든 걸 잘 하는 게 아닌 걸 인정하자

아무리 난다 긴다 하는 프로그래머도 모든 걸 잘 할 수는 없습니다. 어떤 프로그래머도 모든걸 경험할 수 없습니다. 이걸 모두가 인정하는게 가장 중요합니다. 기획자와 프로그래머 사이에 미묘한 긴장감이 흐르면 기획자는 “내가 만든 기획들은 다른 회사에서 이미 했던거야, 그러니 너는 나에게 반박할 수 없을 걸?”이라는 생각을 가지고 접근하게 됩니다.

가끔 프로그래머에게 와서 이거 되냐고 묻죠. 된다고 얘기하면 그 때 된다고 하지 않았냐며 기획에 넣었다 그러죠. 그런데, 된다. 한다. 할 것이다. 이게 다 같은 얘긴가요? 아닙니다. 이런 문제가 일어나는 이유는 팀웍에 문제가 있기 때문입니다. 그래서 인정해야 합니다. 너와 나, 우리 모두 모든 걸 잘하는 게 아님을.

 

2. 자존심을 세우는 건 좋지만, 쓸데 없는 자존심은 버리자

프로그래머들의 성향은 자존심이 센 경우가 많습니다. 전문직종 사람들이 다들 그렇죠. 이는 본인이 하는 일에 대한 프라이드이기도 하고 자신의 두뇌에 대한 프라이드이기도 한데, 그렇게 나쁜 것만은 아닙니다. 프라이드가 적은 사람은 그만큼 책임감도 적기 때문입니다.

하지만, 내가 해본 것과 해보지 않은 것, 할 수 있는 것과 할 수 없는 것, 빨리 할 수 있는 것과 빨리 할 수 없는 것은 냉철하게 판단해야 합니다. 그래서 “난 이 기간 동안 이걸 만들 수 없다.”고 말할 수 있어야 합니다.

 

3. 기획단계부터 참여하자

이 말을 잘 이해해야 합니다. 기획에 감 놔라, 배 놔라 하라는게 아닙니다. 기획단계에서부터 서로 대화를 하라는 겁니다. 무엇을 만들기로 했으면 어떻게 해야 쉽고 빠르게 만들수 있는지 서로 대화를 해서 내가 선택한것처럼 기획자가 선택할수 있게 되면 더할나위 없이 좋겠죠. 이는 서로에게 좋은 기회일 겁니다.

 

4. 폭넓은 지식을 쌓자

프로그래머가 너무 기술만 파면 다른 파트와 대화가 안 됩니다. 폭넓은 지식을 쌓을수 있도록 노력해야 됩니다. 그래야 기획도 할 수 있고, 기획자랑 대화도 할 수 있고, 나중에는 사업도 할 수 있습니다.

 

5. 같은 프로그래머끼리 괴롭히지 말자

“내가 만들면 3일이면 되는데 저거 만드는데 뭐 이렇게 오래걸려?” 이런 말을 입에 달고 사는 사람들이 있습니다. 어떤 미국에 좋은 학교를 나온친구가 자기가 하면 일주일이면 된다고 했습니다. 그래서 그 사람에게 일을 시켰죠. 그런데 못했어요. 한 달 넘게 걸렸을 겁니다. 그 친구가 프로그래밍 실력이 없어서 못한건 아니에요. 상대 업체가 메뉴얼을 줬는데 준데로 만들어도 안됐거든요.

모든일이 각자 다 사정이 있습니다. 위와 같은 말은 절대 해선 안됩니다.

 

 

보너스, 기획자에게 부탁하고 싶은 말

 

1. 막 던지지 말자

300명이 참여한 프로젝트와 비교하지 마세요. 특히… “엑셀처럼 만들어 주세요”, “포토샵은 되던데”, “네이트온에 있는 기능은 다 있으면 됩니다”

… 이런 말은 일진 애들이 빵셔틀한테 500원 주고 2만원 어치 사온 다음 거스름돈 가져와라는 말과 같습니다.

 

2. 프로그래머의 개인 취향과 특성을 존중하자

저는 게임회사를 다니고 있습니다. 제가 본 바로는, 아티스트들에 대해서는 취향과 경험을 존중해 줍니다. 물론 경영진 앞에서는 이런 것들이 무시되기 십상이기 때문에 나름의 고충이 있지요. 그런데 프로그래머는 더 심합니다. 프로그래머들의 장단점, 취향 따위는 아예 고려가 되지 않습니다.

기획자는 다른 회사의 제품을 벤치마킹을 해서 기획을 합니다. 그리고 프로그래머에게 기획서를 주죠. 그럼 프로그래머는 연구도 하고 삽질도 하면서 프로젝트를 진행시킵니다. 당연히 야근은 필수고 과정 자체도 만족스럽지 못하며 프로그램을 완성시켜도 질이 좋지 않습니다.

 

3. 프로그래머는 시다바리가 아닙니다

우리나라는 서비스 기획자가 최고입니다. 이 나라에 있는 대부분의 회사가 그렇게 생겼습니다. 하지만 해외에서는 프로그래머가 주도하는 회사도 많습니다. 글로벌 기업의 경우에는 더욱 그렇고요. 건축현장에서도 설계자와 현장에서 일하시는분과의 마찰이 있고, 의상디자이너와 현장직 아주머니와의 마찰이 있습니다. 그래도 이 분들은 다들 전공이 그쪽입니다. 반면 소프트웨어, 웹 기획자는 전산 전공이 아니죠.

때문에 디테일한 부분에서 프로그래머가 더 많이 아는 영역이 많습니다. 많은 기획자 분들이 따라오려 노력하지만, 그 차이는 쉽지 않습니다. 그렇다면 당연히 프로그래머를 파트너로 대해야겠지요?

 

원문: 모영철 프로그램 철학 / 편집: 리승환


반응형
반응형


 

프로그래머가 되는 방법: 짧고 폭넓고 개인적인 요약.

 

http://wiki.kldp.org/wiki.php/HowToBeAProgrammer#s-3.2.1

 

 

목차

Contents

[-]
1 도입
2 초보자
2.1 개인적 기능들
2.1.1 디버그 배우기
2.1.2 문제 공간을 나눠서 디버그 하는 방법
2.1.3 오류를 제거하는 방법
2.1.4 로그를 이용해서 디버그 하는 방법
2.1.5 성능 문제를 이해하는 방법
2.1.6 성능 문제를 해결하는 방법
2.1.7 반복문을 최적화하는 방법
2.1.8 I/O 비용을 다루는 방법
2.1.9 메모리를 관리하는 방법
2.1.10 가끔씩 생기는 버그를 다루는 방법
2.1.11 설계 기능을 익히는 방법
2.1.12 실험을 수행하는 방법
2.2 팀의 기능들
2.2.1 시간 추정이 중요한 이유
2.2.2 프로그래밍 시간을 추정하는 방법
2.2.3 정보를 찾는 방법
2.2.4 사람들을 정보의 원천으로 활용하는 방법
2.2.5 현명하게 문서화하는 방법
2.2.6 형편없는 코드를 가지고 작업하기
2.2.7 소스 코드 제어 시스템을 이용하는 방법
2.2.8 단위별 검사를 하는 방법
2.2.9 막힐 때는 잠깐 쉬어라
2.2.10 집에 갈 시간을 인지하는 방법
2.2.11 까다로운 사람들과 상대하는 방법
3 중급자
3.1 개인적 기능들
3.1.1 의욕을 계속 유지하는 방법
3.1.2 널리 신뢰받는 방법
3.1.3 시간과 공간 사이에서 균형을 잡는 방법
3.1.4 압박 검사를 하는 방법
3.1.5 간결성과 추상성의 균형을 잡는 방법
3.1.6 새로운 기능을 배우는 방법
3.1.7 타자 연습
3.1.8 통합 검사를 하는 방법
3.1.9 의사소통을 위한 용어들
3.2 팀의 기능들
3.2.1 개발 시간을 관리하는 방법
3.2.2 타사 소프트웨어의 위험 부담을 관리하는 방법
3.2.3 컨설턴트를 관리하는 방법
3.2.4 딱 적당하게 회의하는 방법
3.2.5 무리 없이 정직하게 반대 의견을 내는 방법
3.3 판단 능력
3.3.1 개발 시간에 맞춰 품질을 조절하는 방법
3.3.2 소프트웨어 시스템의 의존성을 관리하는 방법
3.3.3 소프트웨어의 완성도를 판단하는 방법
3.3.4 구입과 개발 사이에서 결정하는 방법
3.3.5 전문가로 성장하는 방법
3.3.6 면접 대상자를 평가하는 방법
3.3.7 화려한 전산 과학을 적용할 때를 아는 방법
3.3.8 비기술자들과 이야기하는 방법
4 상급자
4.1 기술적 판단 능력
4.1.1 어려운 것과 불가능한 것을 구분하는 방법
4.1.2 내장 언어를 활용하는 방법
4.1.3 언어의 선택
4.2 현명하게 타협하기
4.2.1 작업 일정의 압박과 싸우는 방법
4.2.2 사용자를 이해하는 방법
4.2.3 진급하는 방법
4.3 팀을 위해 일하기
4.3.1 재능을 개발하는 방법
4.3.2 일할 과제를 선택하는 방법
4.3.3 팀 동료들이 최대한 능력을 발휘하게 하는 방법
4.3.4 문제를 나누는 방법
4.3.5 따분한 과제를 다루는 방법
4.3.6 프로젝트를 위한 지원을 얻는 방법
4.3.7 시스템이 자라게 하는 방법
4.3.8 대화를 잘 하는 방법
4.3.9 사람들에게 듣고 싶어 하지 않는 말을 하는 방법
4.3.10 관리상의 신화들을 다루는 방법
4.3.11 조직의 일시적 혼돈 상태를 다루는 방법
5 참고 문헌
5.1 책
5.2 웹 사이트
6 역사 (2003년 5월 현재) / History (As Of May, 2003)
6.1 피드백 및 확장 요청 / Request for Feedback or Extension
6.2 원본 / Original Version
6.3 원저자의 경력 / Original Author's Bio


 

반응형
반응형

"프로그래머가 되고 싶은데 수학을 못해요"라는 질문에 대한 답...

제가 수학성적을 60점에서 100점으로 올린방법은 아래 링크에 있습니다.
http://kblog.popekim.com/2012/05/60-1...

 

 

반응형
반응형

좋은 프로그래머가 되는 24가지 방법

http://techit.co.kr/9411


1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생 지속하기 어려운 일이다. 지금 환경이 있는 열정도 꺾어버릴 만큼 열악하다면 심각하게 변화를 생각해야 한다.


2. 프로그래밍 기초 원리를 이해해야 한다. 원리를 모르면 근본적인 해결능력이 떨어지고 수준 높은 개발을 하기 어렵다.


3. 문제 해결 능력을 키워야 한다. 개발자의 가장 중요한 핵심 역량이다.


4. 창의적인 사람이 되라. 대부분의 좋은 해결책은 창의력에서 나온다.


5. 다른 사람의 소스코드를 이해할 수 있는 능력을 키워야 한다. 다른 사람의 소스코드에서 많은 것을 배울 수 있다.


6. 수학을 잘 해야 한다. 수학을 못하면 값싼 쉬운 개발 밖에 못한다. 수학에 관심을 가지고 재미를 느껴보는 것도 한 방법이다.


7. 좋은 커뮤니케이션 스킬을 갖도록 노력해야 한다. 프로그래밍은 컴퓨터와 얘기하는 것이 아니고 사람들과 얘기하는 것이다.


8. 협업 능력을 키워라. 다른 사람과 일을 나눠서 할 수 있어야 내 몸값이 비싸진다. 혼자 일하는 것만 잘하면 평생 혼자 일해야 한다.


9. 논쟁(debate) 능력을 키워야 한다. 고급 개발자가 될 수록 토론하는 일이 늘어날 것이며, 좋은 토론이 좋은 소프트웨어를 만든다.


10. OOP를 완전히 이해해야 한다. OOP는 좋은 Architecture의 핵심이고, 협업능력을 키울 수 있게 해준다.


11. 남이 이해할 수 있는 문서를 작성할 수 있어야 한다. 문서 작성은 평생 따라다니는 중요한 업무이다. 문서작성을 못하는 개발자는 값싼 개발밖에 못한다.


12. 적어도 한가지의 개발언어는 완전히 마스터를 해야 한다. 마스터한 개발언어로는 어떠한 문제도 풀 수 있어야 한다. 모든 개발언어는 원리가 비슷하므로 다른 개발언어도 쉽게 배울 수 있다.


13. 적어도 한가지의 스크립트 언어를 구사할 수 있어야 한다. 간단한 툴은 쉽게 만들어 쓸 수 있다. 스크립트 언어로 쉽게 할 수 있는 일을 C언어로 작성하고 있다면 당장 Python을 공부해라.


14. 비즈니스를 이해해야 한다. 훌륭한 아키텍트가 될 것이다. 좋은 Architect는 비즈니스 전략에서 나온다. 비즈니스에 관심이 없다면 당장 돌아가는 Software는 만들 수 있어도 좋은 Architecture는 못 만든다.


15. 주변에 나보다 훨씬 뛰어난 프로그래머를 둬라. 끊임 없이 배울 수 있다. 주위의 뛰어난 개발자를 경쟁상대라고 생각하지 말고 스승으로 생각해라. 그도 나를 스승으로 생각할 것이다.


16. 끊임 없이 새로운 기술을 익혀라. 전쟁에서 쓸 무기가 많아질 것이다. 몇 가지 소수의 익숙한 기술만 고집하면 도태될 수 있다.


17. 습관적으로 주석을 달아야 한다. 주석은 남을 위해서 다는 것이 아니고 프로그래밍의 일부이다. 주석이 없어도 이해가 가능한 코드를 작성하는 것이 좋지만 그래도 주석은 꼭 필요하고 Doxygen등의 주석을 꼭 이용해라.


18. 남이 이해하기 쉬운 코드를 작성해야 한다. 나중에 내 발목을 잡지 않을 것이다. 내가 좀더 위로 올라가기 위해서는 아래가 자유로워야 한다.


19. 리뷰와 친해져야 한다. 평생 리뷰를 하며 사는 것이 프로그래머의 인생이다. 리뷰를 하지 않으면 발전하기 어렵다. 리뷰는 지금 프로젝트의 문제도 해결해줄 뿐만 아니라 내 프로그래머 인생의 가장 좋은 스승이다.


20. 건강을 유지해라. 건강을 잃으면 실력이고 뭐고 다 필요 없다. 야근도 좋지만 좋은 음식을 먹고 꾸준히 운동도 하자.


21. 좋은 의자를 사라. 건강을 지켜주고 효율을 높여준다. 프로그래머에게 의자는 침대보다 오래 머무르는 곳이다. 비싸고 좋은 의자일수록 좋다.


22. 인생을 즐길 줄 알아야 한다. 프로그래머로 오래 지속하고 싶으면 인생 자체를 즐기는 다양한 방법을 익혀야 한다.


23. 소프트웨어 공학을 익혀라. 주먹구구식 개발에서 벗어나게 해주고 프로그래밍이 더 이상 노동이 아니고 즐겁게 개발을 하게 해준다. 스펙과 설계문서를 작성하고 좋은 개발시스템하에서 적절한 프로세스를 적용해서 개발하는 것이 가장 빠르게 소프트웨어를 개발할 수 있는 방법이라는 것을 경험하고 깨달아야 한다.


24. 높은 연봉을 받을 수 있도록 꾸준히 노력하라. 위의 23가지 방법들을 따라 한다면 저절로 연봉이 높아질 것이다.좋은 프로그래머가 되기 위해서는 주변의 환경도 중요하지만 본인의 의지나 습관도 매우 중요하다. 주어진 환경에 수동적으로 적응하기 보다는 좋은 프로그래머가 되기 위한 자신만의 방법들을 만들어 나가면 좋겠다.



반응형

+ Recent posts