훌륭한 프로그래머가 되기 위한 팁과 경험담 (15장.한권으로 읽는 컴퓨터 구조와 프로그래밍)

가치 제안

• 프로젝트에 참가할 때마다 염두에 둬야하는 질문이 있다.

내가 가치를 더하고 있는가? 생산성을 높이고 있는가?

• 다양한 기술을 잘 배워두면 스스로에게 가치를 더할 수 있다. 경험을 쌓는 방법으로는 사이드 프로젝트가 있다.

가치를 더하지 못하는 경우

상황: 경쟁 중인 표준이 14가지나 된다.

• 14개를 유스케이스를 아우르는 단일 표준을 만든다! -> 가치를 더함 !
• 실제 : 경쟁 중인 표준이 15개가 된다.

프로젝트에서 가치를 높일 수 있는 방법

• 리눅스의 make 명령어
• 패키지 빌드시 쓰이는 유틸리티

이를 보고 다른 프로그램들이 서로 호환되지 않는 make, cmake, dmake, imake 등을 만들었다.
이는 결좌적으로 실무 개발자들이 분야마다 갖가지 도구를 배워야 하는 상황으로 연결되었다. ㅠㅠ

• 최소 놀람의 규칙 rule of least astonishment

사용자 인터페이스나 소프트웨어가 가능한 한 사람들의 예상과 다른 결과를 내놓지 말아야 한다는 규칙

프로그래밍 환경

다른 사람과 함께 일하기 위한 조언

1. 기술적인 선호 - 빡센 토론, 상대에 대한 비난이 아니라 오린 더 나은 코드를 원한다.
2. 사회적인 친밀 - 감성이 중요하다.

초보 프로그래머도 경험을 얻는 방법

고용주가 찾는 '경험이 있는 프로' == 필요한 기술을 정확히 갖고 있는 후보자

그치만 이런 정의는 잘못된 경우가 많다.

1995년에 자바 5년차?? -> 당시에 자바를 만든 사람도 그정도는 못써봤다.

프로그래밍이 좋은점

해보지 않은 일도 해볼 수 있다는 일이다. 해보기 전에 그에 필요한 정확한 기술을 익히는게 중요한데, 어떻게 해야 '경험'을 잘 정의 할 수 있을까?

• 기본이 탄탄해야 한다
• 하나의 기술에 매몰 되어선 안된다.
  • 웹사이트를 만드는데만 익숙하다면 수술 로봇에 들어가는 소프트 웨어를 짜긴 어렵다
• 경험이란 여러분이 무엇을 할 수 있는지 무엇을 할 수 없는지를 아는 것이다.
  • '추정' 이란 방법이 이를 도와 줄 수 있다.

추정하는 방법 배우기

프로젝트 팀원이 할 수 있는 가장 파괴적인 일
==> 아무 경고 없이 결과물을 제때 내놓지 않는 일

경고가 없다는게 포인트이다. 항상 결과물을 제때 내놓는 사람은 없다.
하지만 갑자기 팀원들에게 기한을 맞추지 못하겠노라고
뒤늦게 알린다면 그에 바로 대응해 작업할 수 있는 사람은 거의 없다.

• 추정하는 방법

  • 작업을 시작하기 전에 그 작업이 얼마나 걸릴지 스스로의 추정을 적기
  • 항상 맞진 않겠지만 이런 과정이 추정을 점차 정확하게 한다.

• 상황 일지

  • 달성한 내용
  • 생겨난 문제
  • 다음 기록 까지 어떤 일을 할지 계획

추정과 상황일지를 사용해 실제 결괏값과 추정치를 비교하는 방법을 조정하자.

프로젝트 스케줄링

1. 프로젝트의 모든 요소를 목록으로 만든다
2. 이 요소마다가 예상 소요 시간을 적는다. (1시간 짜리 작업, 1일짜리 작업, 1주일 짜리 작업)
    * 대부분은 틀릴거지만, 평균을 내면 꽤 비슷해진다. 
3. 여기서 상황일지를 적으면, 어떤 작업이 추정보다 오래걸렸고, 어떤 요소가 추정보다 덜 걸렸는지 알게 된다. 

그치만 항상 프로젝트가 이렇게 흘러가진 않는다.
돈과 시간의 줄다리기 속에서 정확한 예측 보단, 때론 공격적인 숫자가 더 매력적이다.

의사 결정

"내가 그 기술을 좋아해서 그걸 하고 싶어요"

라고 말하기엔 우린 근거를 대라고 배웠다. 그래서 있는 근거 없는 근거를 대는 논쟁을 시작한다.
그냥 좋아한다고 말해도 된다. 그걸 싫어하는 누군가가 반론을 할 테니까..
문제는 반론을 듣는게 싫어서 되도 않는 이유를 가져다 붙이고 토론 자체를 막아버려선 안된다.

결론은 개인적인 선호와 기술적인 필요성을 분리해야 한다!

성향이 다른 사람들과 일하기

프로그래머의 성격 유형

사회적인 적응과 기술적인 기량 선호 그 사이 어딘가
리처드 스톨먼 ~ 데니스 리치(기술 그자체) 사이에 리누스 토발즈.. ㅋㅋㅋ
<소명, 성과의식> ~ <공감>
불타는 토론을 해도 ...

• 코드에 대한 지적이 자신에 대한 지적이 아님을 명심
• 그러나 "일마다 내가 하는 일에 대해 멍청하다고 하는 사람" 에겐 필요한 말을 해야한다

직장 내 (물리, 정신) 어떤 유형의 폭력도 해선 안되고 내가 그 피해자가 되는 것도 막아야한다.

좋은 프로그래머가 무엇일까?

시스템 프로그래머 |-| 어플리케이션 프로그래머 |-| 사용자
라이브러리(API) UI(API)
표준 입력이 표준 출력이 되기도하고, 이를 다시 표준 입력으로 사용할 수 있다.

무엇이 좋은 API 를 만들어 줄까?
유즈케이스(USECASE) 를 문서화하는 것
유즈 케이스란 어떤 작업을 완수하기 위해서 API를 사용하는 상황을 말한다.