<< Previous | Home | Next >>

개발자와 나이

"It’s official : developers get better with age. And scarcer."이라는 아티클이 레딧에서 다시 회자되고 있어 소개합니다.

아티클의 내용은, StackOverflow에서 개발자들의 Q&A 데이터를 분석 한 것으로, 개발자수는 27세를 정점으로 그 후 6,7년마다 절반으로 그 수가 줄어들지만, 높은 평가를 얻게 된다는 것.

Q&A 사이트여서 그런지, “높은 평가”라는 질문에 좋은 답변을 많이 했다는 것으로 40대의 답변자가 20대의 두배 정도 많았다고 합니다.

그리고 분석 데이터에 의하면 답변의 질은 나이와는 큰 차이가 없고, 단지 고연령 개발자는 많은 질문에 대답하고 있기 때문에, 높은 평가를 얻고 있다고 결론을 내렸다네요.

저도 비슷한 생각이 있는게, 기술 커뮤니티나 페북 그룹, 뉴스그룹 등에서 연장자분들이 아니더라도 눈팅이 아닌 댓글을 통해 답변을 성심성의껏 다는분들이 계신데 그분들이 정말 내공자라 생각이 듭니다.

그냥 '왜'라고 묻는 것이 항상 최선의 전략은 아니다

좋은 제품을 만드는데 있어서 본질을 파고드는 데 좋은 사례가 바로 '왜?'라는 질문을 자신과 이해당사자들과의 토론에서 끊임없이 하는 것이다. 하지만 건성의 '왜'로 핵심을 파지않고 그저 내용의 이해만을 도울 수 있는 왜는 지양해야 된다는 좋은 아티클 'ASKING WHY IS NOT ALWAYS THE BEST STRATEGY'이 있어 내용을 요약해 봅니다.

제품을 만들 때 ‘왜’라는 질문을 반복하는 것은 본질적인 문제에 도달할 수 있는 좋은 방법이지만, HubSpot 제품 디자이너 Daniel Ritzenthaler는 맹목적인 ‘왜’를 반복하는 것은 오히려 생산적이지 않다고 한다.

제품에 좋은 가치를 부여하는 생산적인 ‘왜’를 묻는데에는 3가지 레이어를 인식할 필요가 있다.
  • 첫 번째는 편리성 레이어. 여기는 있는 이 기능을 사용하여 실제로 무엇을 하려고 하는지를 묻는 레이어.
  • 두 번째는 유용성 레이어. 여기는 있는 이 기능을 사용하면 어떤 결과를 얻을 수 있는지를 묻는 레이어.
  • 세 번째는 바람직함의 레이어. 이것이 목적을 달성 한 후에, 다른 것들과의 차별점이 무엇인지를 묻는 레이어.
이 3가지의 ‘왜’라는 레이어를 염두해서 제품을 생각한다면 시간과 결과물에서 좋은 가치를 심을 수 있다고 한다.

관점의 변화

  • 문제 해결형 (problem solving) ⇒ 문제 제기형 (problem finding)
  • 프로세스로서의 디자인 (design as process) ⇒ 중재 (수단)으로 디자인 (design as medium)
  • 답을 제공 (provides answers) ⇒ 의문을 제기 (ask questions)
  • 산업에 대한 봉사 (in the service of industry) ⇒ 사회에 대한 봉사 (in the service of society)
  • 현재 세계를 위해 (for how the world is) ⇒ 앞으로 가능한 세계를 위해 (for how the world could be)
  • 과학 소설 (science fiction) ⇒ 사회적 소설 (social fiction)
  • 미래 (futures) ⇒ 현실과 병행하여 존재하는 세계 (parallel worlds)
  • 적응 (applications) ⇒ 시사점 (implications)
  • 생산을 위한 디자인 (design for productions) ⇒ 토론을위한 디자인 (design for debate)
  • 컨셉 디자인 (concept design) ⇒ 개념적인 디자인 (conceptual design)
  • 소비자 (consumer) ⇒ 시민 (citizen)
  • 사용자 (user) ⇒ 사람 (person), (human)
  • 구입하기 (makes us buy) ⇒ 생각하기 (makes us think)

권위와 가치

Square의 CEO인 Jack Dorsey가 재미난 글을 올렸네요. 회사생활을 하면서 우리도 이런 비슷한 유혹을 많이 받게 되죠? 아래는 Jack Dorsey가 Medium에 올린 글입니다.

회사 생활을 하다보면 사람들이 아이디어를 제시할 때 권위있는 사람들을 이름을 빌려서(혹은 유명한 포스트나 뉴스 기사 등도 포함) 자신의 아이디어에 설득력을 보강하려한다는 것을 많이 발견하게 됩니다.

누군가의 이름을 빌려서 아이디어를 팔 때는 아래 두가지의 일이 일어난다네요.
  1. 당신의 권위가 떨어진다.
  2. 그 아이디어의 가치가 떨어진다.
간단하다: 당신이 이야기(의견이나 아이디어)의 논지를 남에게 설득시키기 위해서 타인의 이름과 권위를 이용한다면, 당신이 한 의견의 가치는 떨어진다.(당신 스스로가 이야기를 믿지 않고 있을 수도 있다) 당신이 정말 그 일이 옳다고 믿는다면, 스스로가 만들어서 그것을 증명하는데 초점을 맞추어야 한다. 권위는 가치를 제시할 때 나오는 것이지 타인의 권위를 등에 엎는 것으로 자신의 생각에 대한 가치가 부여되는 것은 아니다.

우리는 "John이 이렇게 하라고 해요. 이것이 우리의 방식이에요."라는 결론에 이르게하는 토론이 아니라, 우리가 당연하게 생각했던 것들을 다시 생각하고 대담하고 말도 안되는 아이디어에 대해 열정적으로 토론하기를 원한다. 후자의 방식이라면 Agile하고 혁신성을 유지할 수 있지만, 전자는 시대에 뒤떨어지게 된다.
Tags :

README가 대문자인 이유

README 파일은 해당 디렉토리나 아카입의 소프트웨어에 대한 정보를 기술하는 파일이다. 그런데 왜 대문자로 구성되어 있는지 확인해 보니...

위키에 그 사례가 실려져 있었다.

It is traditionally written in upper case so that on case-preserving environments using an ASCIIbetical ordering, the name will appear near the beginning of a directory listing (since upper-case letters sort before lower-case letters in ASCIIbetical ordering).

ASCII 코드 순으로 정렬되는 환경을 채택한 곳에서는 README 파일이 제일 앞에 보이게 하기 위해서 전통적으로 대문자를 쓰게 된다.
그래서 맥에서 LANG=C이나 LC_COLLATE=C 환경에서 ls -l를 실행해 보니,
$ ls -l
total 7656
-rw-r--r--   1 pepsi  staff    16317 Jul 23  2013 README.md
drwxr-xr-x  11 pepsi  staff      374 Jul 27  2013 bin
-rw-r--r--   1 pepsi  staff     1316 Jul 23  2013 build.xml

ASCII 문자 코드 순으로 README가 맨 먼저 보여지게 된다. 결국, README의 대문자 관습이 존재 의미를 더욱 부각시켜 주는 거 같다.
Tags :

왜 일이 예상대로 끝나지 않는가?

Why is not end as expected things?

1. 시간을 낭비하고 있는건 아닌지.
시간이 있을 때 그때 그때 스스로 찾아서 완결해 가야 하는데, 마감이 임박하지(빠듯하지) 않으면 동기 부여가 안된다. 초반에 느슨하게 하다가 막판에 불지르다가 일정과 품질에 악영향을 준다.

2. 인터럽트 되는 일을 우선시 한건 아닌지.
일을 하게 되면 항상 생기게 마련이 일의 집중도를 떨어뜨리는 인터럽트이다. 이것 때문에 지금 하는 일이 밀려나고 나중에 다시 시작할 땐 업무 전환 비용이 생긴다. 이럴 땐 장유유서, 상명하달의 문화가 큰 적이 된다.

3. 딜레이는 다른 딜레이를 낳는다.
하는 일을 완결하지 못하면 다음 일에도 영향이 생긴다. 여기엔 능력 부족이 큰 기여를 한다.

4. 완벽한 성과를 내려고 한다.
완벽한 성과를 내려면 준비 과정의 비중을 많이 두게 된다. 그리고 진행중에는 적당한 룰 없이 이리 재고 저리 재고하다보면 그러한 업무태도가 결국 시간을 먹는 하마가 된다.
Tags :

사이드 프로젝트의 효용성 그리고 중요성


기업에서 개인 자신에 이르기까지 직원들이나 개인 스스로 자신의 잉여 시간을 잘 활용하는 방법에 대해 고민을 많이 하고 있습니다. 그 중에 하나로 사이드 프로젝트를 활용하는 사례가 많이 도출되고 있어 좀 정리를 해 봤습니다.

생각에 그치지 않고 그것을 실현해가는 습관을 길러주는 사이드 프로젝트, 개인에게 사이드 프로젝트 하나쯤은 지속적으로 유지하면 더 커진 나를 발견할 수 있다고 생각합니다.

그리고 먼저 지속적으로 유지해 보세요. 뭔가 달라질 것 같아 보이지 않으세요? ^^

왜 사이드 프로젝특 좋은가?

사이드 프로젝트라함은 자신의 메인 잡은 그대로 유지를 하고 자기가 좋아하고, 하고 싶은 아이디어, 기술을 통해 부가적으로 프로젝트를 만들어서 시간이 날때마다 실현하는 것을 말한다.

스타트업에서는 "Fail Fast"(빨리 실패하기), "MVP"(최소한의 핵심적 가치를 투입)를 모토로, 빨리 시장에 내놓고 고객의 피드백으로 개선해 가는 방식을 중요한 비즈니스 사이클로 인식되고 있지만, 이와 다른 관점에서 대두되고 있는 것이 바로 Succeeding Slowly(느린 성공)이라는 개념이다. 그리고 이 느린 성공에 어울릴법한 형태가 바로 사이드 프로젝트가 아닌가 해서 언급하고자 한다.

"Why Side Projects matter(왜 사이드 프로젝트가 중요한가)?"라는 아티클에서 보듯이 자신의 본업으로 살아가면 먹고 살수는 있지만, 사이드 프로젝트는 자신을 크게 성장할 수도 있고, 가능성이 큰 아이디어를 실현하는 기쁨, 길게 보고 꾸준한 노력을 통해 나중에 큰 성공을 가질 수 있다는 희망, 자신이 즐거워하는 것들, 가슴을 두근거리게 만드는 작업을 한다는 건 개인적으로 커다란 동기부여와 축복이 아닐 수 없다. 그리고 거시서 자신에게 보이지 않았던 창조성을 찾을 수도 있고 또 그것을 발휘할 수도 있게 해준다.

그래서 본업은 "Fail Fast"(빠른 실패)를, 사이드 프로젝트는 "Succeeding Slowly"(느린 성공)의 관점을 지향하다보면 본업이나 사이드 잡중에서 성공을 맛볼 기회가 커지지 않을까?

또한, 3M의 Jefferson도 사이드 프로젝트의 유용성에 대해 "Success on the Side - The American, A Magazine Ideas"라는 아티클을 썼다. 그 내용 중에 키포인트만 요약해 보면..
혁신은 천재가 고민한 끝에 나온 좋은 아이디어로 만드는게 향상 제품이 되는 건 아니다 :
  • 아이디어는 예기치 않은 곳에서 나온다.
  • 아이디어는 머리로 생각하고 발견되는 것이 아니라, 실제로 뭔가를 만들고 이행하는 중에 나오는 것이다.
  • 중요한 것은 모든 직원의 전체적인 힘, 특히 고객에 가까운 직원의 힘이 중요하다.
라는 말로 사이드 프로젝트의 타당성을 강조하고 있다.

사이드 프로젝트의 성공 사례

"Start Something : The Power of Side Projects(사이드 프로젝트의 힘)"에서 보면 지금은 없어졌는지 모르겠지만, Google의 20%룰에 의해 gmail, news, adsense가 태어났고, Twitter, Instagram, Uber, StumbleUpon 등이 사이드 프로젝트에서 출발해 성공을 이룬 서비스들이다. 또한, 셀로판 테이프(Scotch Tape)를 Richard Drew라는 사원이 개발한 것도 3M이 추구한 "15-percent-time rule"에 의해 이루어졌다고 한다.

모든 시간과 정렬을 본업에 집중해도 경쟁력이 생길까 말까하는 시각도 있을 수 있지만, 잉여 관점에서 프로젝트는 자율성이 보장되고, 다양성이 보장되는 환경에서 스치듯 지나가는 아이디어를 긴 시간을 두고 갈고 닦게 되면 또다른 성공 사례의 가능성도 내포되어 있다고 볼 수 있어 설득력이 있는 방법인 것 같다. 그리고 개발자의 경우 자기가 좋아하는 분야의 기술력 향상을 이룰 수 있는 도구도 될 수 있어 꾸준이만 한다면 마이너스가 되는 전략은 아니라고 본다.

개발자의 사이드 프로젝트 진행 사례 소개

jQuery를 만든 John Resig이 사이드 프로젝트를 통해 메일 코딩하는 습관의 중요하다는 내용의 글 "Write Code Every Day"를 썼다.

그 중에서 자기가 습관화시키는 데 따르고자 했던 룰과 코딩을 습관화하면서 얻은 흥미로운 것들을 몇가지를 여기서 소개하고 사이드 프로젝트를 진행하거나 하고자 하는 분들에게 도움을 주고자 한다.

John Resig이 사이드 프로젝트를 하면서 발생했던 문제들: 주중엔 코딩을 많이 할 수 없어서 주말에 몰아서 하곤 했는데 완성도나 업무의 연결성 등에 문제가 있었고, 주말에 약속이 없다는 것도 보장을 못하고, 기본적으로 해야한다는 스트레스가 컸다고 한다. 그래서 이렇게는 안되겠다고 생각해 Jennifer Dewalt의 사례를 보고 자신만의 코딩을 습관화하기 위한 룰을 만들었다.
  1. 매일 코드를 작성해야 한다. 문서나, 블로그 기사, 혹은 다른 것들을 작성하는 것은 내가 코드 작성하고 난 뒤 여유가 있을 때 작성한다.
  2. 작성한 코드는 유용해야 한다. 들여 쓰기나 코드의 외형 수정은 작성된 코드에 포함하지 않는다. 가능하면 리팩토링도 포함하지 않는다.(이 모든 일은 하루 동안의 일이 아닐때만 허용되는 것이다).
  3. 모든 코드는 자정전에 써야 한다.
  4. 코드는 오픈 소스로 Github에 올여야 한다.
이 룰을 모두가 따라야한다는 것은 아니지만 이 룰을 통해 John Resig은 코드 습관화에 성공할 수 있었고 20주 연속으로 진행했고 유지하고 있다고 한다. 또, 좋은 변화도 생겼다도 하니 추천하는 바이다.

그럼 John Resig이 이 룰을 통해 코드 습관화를 하면서 일어난 코드 작성의 변화나 삶과 인생에 흥미로운 현상들이 생겼다고 해 여기에 몇가지 소개를 한다.

최소 실행가능한 코드. 나는 적어도 하루에 30분은 코딩에 투자를 했다.(의미있는 코드를 짧은 시간에 쓰기는 어렵다. 특히 전날 어디까지 했는지 생각하는 것도 어렵다) 주중의 일부는 약간만 코딩만 했고(1시간보다 작지만), 주말에는 때때로 하루 종일 코드를 짤 수 있었다.

습관화된 코딩. Github에 나타내는 코딩 이력 차트를 신경쓰지 않는다는 것이 좋다. 이런 시도(외부 시선을 평가하는 것)를 없애는 것이 제일이다 : 당신 자신을 위해, 당신 인생에서 무엇을 했는가 하는 것이 중요한 변화이지, 당신이 한 일을 누구에게 인정 받기위한 것을 중요한 것은 아니다. 다이어트나 운동도 같은 형태라고 말할 수 있지만, 자기 스스로를 개선하지 않으면, 진정으로 성공할 수 없다.

불안과의 사투. 이 실험을 시작하기전에 완성도는 "적절하게" 타협하거나, 진척도는 "충분한 지"에 관해 매우 불안한 느낌을 종종 가졌다.(자신의 사이드 프로젝트 납기는 없기 때문에, 이 둘을 상대적으로 계량화하기는 어려워서) 진척도를 느끼는 감각은 실제 진행하는 것만큼이나 중요하다는 걸 깨달았다. 이것은 놀라운 발견이었다. 매일 지속적으로 작업을 진행했을 때(습관화 했을 때), 불안 따위는 녹아 없어져 버리기 시작했다. 나는 내가 한 일의 양에 평온한 기분을 느꼈고, 광적으로 어떤 일을 완료하기 위해 고압적인 욕망을 가지지 않아도 됐다.

주말 작업. 주말에 작업을 완료하는 것은 절대적으로 중요한 것이었다.(자신의 중요한 사이드 프로젝트 코드를 완료하는 유일한 시간이었다) 지금은 그다지 중요하지 않게 되었지만, 그것은 좋은 것이다. 나는 주말에 일주일 동안 달성해야 할 기대치를 쌓았지만, 결국 실망감만 안겨줬다. 내가 원하는 일 모두를 끝낼 수 있었던 적은 거의 없었고, 내 작업을 완료하기 위해 내가 즐거워하던 다른 일정을 취소하는 지경에 이르기도 했다. (딤섬을 먹고, 미술관을 방문하거나 공원에 가거나 내 파트너와 시간을 보내는 등) 내 사이드 프로젝트는 생활을 배제해 버릴만큼 중요한 것이 아니라는 것을 강하게 느낀다.

백그라운드 처리. 매일 자신의 사이드 프로젝트의 코드를 작성하는데 있어서 한가지 재미있는 부작용은 자신의 현재의 작업이 항상 머릿속의 뒤편에서 구동되고 있다는 것이다. 산책하러 나가거나 샤워를 하거나 무언가 뇌를 사용하지 않는 활동을 하고 있을 때면 언제든지 코딩하려고 내용을 생각하고 있기 때문에, 문제를 해결하는 좋은 방법이 발견되기도 한다. 이것은 일주일에 한번 이라든지, 격주로 코드를 작성하는 경우에는 일어나지 않는다. 대신에 그 시간을 다른 작업을 생각하는데 소비되거나 자신의 사이드 프로젝트 작업이 완료되지 않은 것을 넘어 혼란 상태로 바꿔놓기도 한다.

컨텍스트 스위치(업무 전환). 자신의 사이드 프로젝트 작업을 재개하려고 할 때, 컨텍스트 스위치 즉, 업무 전환 비용이 생겨 버린다. 불행히도, 일주일 내내 다른 프로젝트를 진행한 후 자신의 사이드 프로젝트를 다시 생각하는 것은 매우 어렵다. 매일 작업하는 것은 업무에 대한 기억 간격이 짧아지므로, 무엇을하고 있었는지 쉽게 기억할 수 있게 된다.

업무 균형. 이러한 변화중에 가장 중요한 부분중에 하나는 일/삶/자신의 사이드 프로젝트의 균형의 취하는 방법을 배운 것이다. 내 사이드 프로젝트에 매일 하면서 알게 된 것은 내 시간의 균형을 더 잘 잡아야 한다는 것이다. 저녁에 외출해서 밤 늦게까지 돌아 오지 않았을 경우 일정을 짠다면, 다음날 일찍 일어나서 나의 주요 업무인 Khan Academy를 하기 전에 내 자신의 사이드 프로젝트의 목표한 것을 완료할 필요가 있다. 게다가 자신의 사이드 프로젝트 작업이 아직 완료되지 않았다면 밤늦게 나갔을 경우 당신은 서둘러 집으로 돌아가 나머지를 완성해야 한다(대신 하루가 빠져나갈 수 있다). 나는 취미에 시간도 줄어 들었지만, 그것은 살아가는 데 필요한 합리적인 트레이드오프라고 스스로에게 타이르고 있다.

외부의 인식. 이러한 습관은 외부적으로 커뮤니케이션하는데 많은 도움이 되었다. 내 파트너는 내가 매일 코드를 완료해야 하는 것을 이해해 주었고 이들 활동 때문에 일정을 맞춰 주기도 했다. 그 덕분에 "그래, 나가자/영화를 보자. (나가도 좋지만) 나중에 코드를 쓰면 되잖아"라고 편하게 말할 수 있게 되었고, 그리고 이해와 고려도 얻을 수 있었다.

얼마나 코드를 썼어? 지난 몇 개월 동안 써온 코드의 양은 스스로도 믿기 어려울 정도다. 나는 2개의 웹 사이트를 만들었고 몇 가지 프레임 워크를 재작성했고, 새로운 노드 모듈은 셀수 없을 정도 많이 만들었다. 또 내가 잊어버릴만큼 많은 코드를 만들었다. 몇 주 전의 작업이 이제 먼 기억처럼 보인다. 그래서 내가 완료한 일의 양으로 도 만족해 했다.

John Resig의 코딩 습관화가 중요하다는 경험담이나 룰은 참 마음에 와 닿는다. 사이드 프로젝트가 모든것을 해결해주는 은총알은 아니다. 다만 잉여력을 성과로 만들어 내기 위한 좋은 방법 중에 하나라는 생각만은 든다. 그리고 개발자의 전문성을 높이는 가장 효과적인 방법이 업무 외적 분야에서 의도적인 수련의 질과 양을 높이고 증가시키는 것이라고 한다. 그 예가 바로 사이트 프로젝트인 것이다.

저도 주로 주중에는 리서치하고 주말에 세미 프로젝트를 하곤 하는데 이런 방법은 개인적으로도 자기자신을 담글질하는 데 아주 좋은 방법이라고 생각해서 몇자 적어봤습니다.

끝으로, 여러분들도 사이드 프로젝트로 개인적으로나 회사적으로 대박 나시길..