반응형
반응형

Online Typing Practice for Programmers

https://www.speedcoder.net/

 

Typing Practice for Programmers | SpeedCoder

 

www.speedcoder.net

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

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...

 

 

반응형

+ Recent posts