원문보기

Joel on Software

점심시간  

Lunch

by Joel Spolsky

 
Thursday, April 28, 2011


 
매일 점심시간을 어떻게 보내십니까? 어디에서 식사를 하나요? 누구와 식사를 하세요? 

  전 매일 팀원들과 점심을 같이 하는데, 정말 멋진 일입니다. 팀의 일원으로 인하는데 매일 함께 점심을 하지 않는다면, 최선의 경우에도 외로움 뿐이죠. 

  많은 대형 IT기업들이 식당을 가지고 있습니다. 가격이 공짜이거나(Google) 저렴합니다(Microsoft). 이런 회사들 안에서 몇몇 팀들은 매일 함께 식사를 하려고 노력합니다. 하지만, 많은 팀들은 그렇지 않습니다. 여러분이 점심시간에 이런 회사들을 돌아다녀 본다면, 몇몇 큰 그룹과, 많은 사람들이 둘씩 함께 먹으며 약속된 "점심 미팅"을 하는 것을 볼 수 있을 것입니다. 하지만, 또한 나홀로 식사를 하는 적지 않은 수의 사람들을 보게 될 것입니다. 아마도 그들은 책을 보거나 그들의 E-mail을 보면서 식사를 할테고, 그렇게 슬퍼 보이지는 않겠지요. 아마도 그들은 점심을 가지고 자기 자리에서 먹기때문에 회사식당에 혼자 앉아 있지는 않을지도 모릅니다. 어쩌면 태생적으로 사람들을 싫어해서 혼자서 먹는 것을 좋아할지도 모릅니다. 또는, 그냥 그렇게 얘기하는 걸지도 모르죠. 

  구글과 마이크로소프트에서는, 회사식당이 너무 붐벼서 혼자 먹는 사람들이 다른 그룹에 끼어 앉아 먹을 수 밖에 없습니다. 종종, 그들이 끼어앉은 그룹의 사람들이 혼자 먹으러 온 사람들을 그들의 대화에 끼어주기 위하여 노력을 하기도 합니다. 보다 많이 보이는 광경은, 혼자 먹는 사람들이 문자 그대로 스마트폰을 가지고 Facebook에 몰두 하고 있는 모습을 보여주어 사회적 접촉을 피하고 싶다는 메세지를 보내는 것입니다. 죄송하게도, 전 여러분에 제 소개 하는 것을 좋아합니다만, 제 페이지를 업데이트하는 것이 너무 중요하네요. 

  어디에서 누구와 점심 식사를 같이 하는가는 제게는 보통사람들이 생각하는 것보다 아주 중요한 문제입니다. 분명하게, 심리학자들이 증언하고, 또 분명하게, 우리의 어린시절, 특히 학창시절, 그중에서도 중학생 시절을 되돌아보면, 어디에서 누구와 함께 식사를 하는 것은 아주아주 중요한 일입니다. 어느 파벌에 속하여 먹는가, 심지어 당신이 그냥 샌님 그룹(Nerd)의 일원이라도, 혼자 먹는 것보다는 훨씬 사람들이 좋아합니다. 혼자먹는 사람들과 괴짜(Geek)들에게는 사람들과 식당에서 함께 식사하는 것도 큰 스트레스 입니다. 

  여러분의 동료들과 함께 식사하는 일은, 제게는, 포기할 수 없는 중요한 일입니다. 이것이 우리가 작은 원탁에 나누어 앉기 보다, 긴 테이블에 함께 앉아 먹는 이유입니다. 이것이 신입이 우리회사에서 일을 시작할 때 식당 한 구석에 떨어져 않는 것이 허락되지 않는 이유입니다. 우리회사에 방문객이 올때면, 그들도 다른 모두와 함께 앉아 먹습니다. 

  심지어 Stack Exchange와 Fog Creek이 완전히 분리된 별개의 회사임에도 불구하고, 우리는 우리의 사무실이 한 건물에 있다는 장점을 이용하여 매일 함께 식사를 합니다. 저는 이런 기회가 있어서 매우 기쁩니다. 많은 사람들이 파벌을 만들어 함께 앉는 경우가 매일 늘어가더라도요. 

  Fog Creek과 Stack Exchange에 많은 사건사고들이 있었지만, 점심식사가 그중의 하나는 아닙니다. 10년전 마이클과 제가 다소 야심찬 "좋은 일터 만들기 (Great work place)" 계획을 만들었습니다. 회사의 첫 날 부터, 함께 식사를 하는 것은 인간미있고 인정이 넘치는 일터를 지향하는 우리의 핵심 가치가 되었습니다. 
 

2009/04/04 - [조엘 온 소프트웨어(번역)] - 조엘 온 스프트웨어 - 저자에 관하여 (Joel on Soft ware - About the Author : Joel Spolsky)


Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  유명 블로거 조엘 스폴스키 (Joel spolsky) - 저자에 관하여 (Joel on Soft ware - About the Author : Joel Spolsky) - 의 글에 따르면, S/W 개발자들의 공평한 고과를 매기는 것은 무척 어려울 뿐 더러, 일반적인 사람들에 비하여 더 똑똑한 이 사람들은 어떠한 기준을 제시해도 그 기준을 피해나갈 방법을 찾기 때문에, 차라리 고과를 매기지 않는 편이 좋다고 얘기를 합니다. 예를 들어,한주에 작성한 코드의 양을 기준으로 삼는다면 일부러 코드를 늘려서 짤 것이고, 수정한 버그 수를 기준으로 삼는다면 일부러 쉬운 버그들을 양산할 것미고, 반대로 만들어낸 버그의 수를 기준으로 삼는다면 테스트를 하느라 코드 작업이 진행되지 않는다는 거지요. 프로그래머를 평가하는 방법은 그들의 짠 코드를 직접 평가하는 수 밖에 없는데, 이는 주관적이고 절대적인 기준이지, 상대적이고 객관적인 기준을 만들 수는 없습니다. 오히려 많은 역효과가 있기 때문에, 조엘은 프로그래머들의 고과를 평가하지 말 것을 권하고 있습니다. 이와 관해서 제가 최근에 겪은 이야기를 써볼까 합니다.

  최악의 프로젝트가 막 끝났습니다. 기획과 경영 파트의 잘못된 추정과 진행으로 프로젝트가 최악으로 치달았습니다. 이로 인해서 코어팀은 6개월 가까이 잔업과 특근에 시달려야 했습니다. (시달렸다는 표현은, 월 100시간 정도 잔업과 토, 일요일 모두 출근했다는 뜻입니다.) 정말 최악이었죠. 프로젝트가 끝나기 두 달 전부터는 어플리케이션 팀도 마찬가지도 시달려야 했습니다. 어플리케이션 팀도 적지 않게 고생을 했습니다.

  어쨌든, 프로젝트는 끝이 났습니다. 그리고 수확의 계절이 되었습니다. 코어팀 리더는 목소리가 큰 분이셨는데 (Big mouth), 코어팀이 가장 고생을 한 것이 명백하니, 우리 애들이 좋은 고과를 받아야 한다고 주장을 하셨습니다. 이로 인해 다른 팀은 "보통" 고과 밖에는 받지 못했는데, 회사 정책이 각 등급의 배분에 제한을 두었기 때문입니다. 코어팀 리더의 주장은, 코어팀이 가장 많은 잔특근을 했기 때문에, 그들이 좋은 고과를 받을 자격이 있다는 것이었습니다. 이 주장은 옳은가요? 충분히 공평한 것입니까?

   이래서 반대합니다.  
 

  반대의견 1. 좋은 고과는 똑똑하고 빛나는 프로그래머들에게 가야합니다. 잔업시간은 좋은 프로그래머의 능력을 나타내는 지표가 될 수 없습니다.

  반대의견 2. 어떤 프로그래머가 코어팀에 배치가 되었습니다. 그는 잔업에 시달리게 되었습니다. 그리고 좋은 고과를 받았습니다. 그런데, 이 프로그래머가 코어팀에 배치된 것은 그가 원해서 된 것도 아니고, 그가 특별한 재능이 있어서도 아닙니다. 그냥 신입사원 배치 중 "우연히" 된 것입니다. 그렇다면, 다른 팀에 배치되어 "보통"의 고과를 받은 신입사원에게는 완전히(totally) 불공평한 일입니다.

  반대의견 3. 엄청난 좌절감(depression)이 코어 외 다른 팀들에 주어졌습니다. 그리고 이는 앞으로 팀을 관리하는데 엄청난 어려움이 됩니다. 다른 팀원들도 잔업에 시달린 것은 마찬가지 였습니다. 두 달간의 시달림도 결코 재미있는 일은 아니었습니다. 그리고, 그들은 그 보상도 받지 못했습니다. 이제, 새 프로젝트가 시작되었지만, 다른 팀원들은 잔업을 거부하게 되었습니다. 더 나아가, 그들은 관리자들로부터 모욕감을 느끼고 있습니다. 이제 관리자들은 어떻게 개발자들의 사기를 북돋을 수 있을까요?

   단순한 고과 문제가 아닌, 신뢰의 문제입니다.
 

  제가 무슨 얘기를 하는 것인지 이해가 되시나요? 이건 단순히 고과 평가에 관한 이야기가 아닙니다. 이건 개발자와 관리자(팀) 사이의 거대한 신뢰 문제에 관한 이야기 입니다. 그리고 신뢰는 멀리, 저멀리 날아가 버렸습니다.

  이것은 현재 진행형의 이야기 입니다. 끔찍한 잔업과 시달림은 관리자들 - 특히 빅 보스 (Big boss) - 에 의해서 만들어졌습니다. 그러므로, 문제를 해결하는 것도 관리자들 (역시 빅 보스)의 책임입니다. 어쩌면 모든 문제를 만든 것은 회사 조직 그 자체일지도 모릅니다.

  앞으로 어떻게 진행이 될까요? 글쎄요. 문제를 해결 할 수 있는 사람이 변하지 않으면, 계속 같은 이야기가 반복되겠지요. 아마도, 끊임없이 같은 이야기가 반복될 지 모릅니다. 그리고, 진짜 쓸만한 개발자는 아무도 안남게 되겠지요.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절



Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.


About the author.

I’m Joel Spolsky, founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make FogBugz, an enlightened project management system designed to help great teams develop brilliant software, and Fog Creek Copilot, which makes remote desktop access easy.


더 알고 싶으십니까?

  여러분은 조엘 온 스프트웨어를 읽고 계십니다. 조엘 온 소프트웨어는 수년에 걸쳐 소프트웨어 개발과 소프트웨어 개발팀 관리, 유저 인터페이스 설계, 성공적인 소프트웨어를  회사 운영하는 것, 그리고 목용탕의 고무오리에 관한 뛰어난 글들로 채워져 있습니다. 

저자에 관하여

  저는 Fog Creek Software의 공동 창업자, 조엘 스폴스키 (Joel Spolsky) 입니다. Fog Creek Software는 뉴욕 소재의 회사로,  프로그래머들을 잘 대우하면서도 여전히 높은 이익을 낼 수 있다는 것을 증명하고 있습니다. 프로그래머들은 개인 사무실과, 공짜 점심과 주당 40시간 근무를 보장 받습니다. 고객들은 소프트웨어에 만족했을 때만 지불하면 됩니다. 우리는 FogBugz - 대단한 개발팀이 뛰어난 소프트웨어를 만들 수 있도록 도와주는 진보된 프로젝트 관리 시스템 입니다 - 와 Fog Creek Copilot - 데스크탑 PC의 원격 조정을 쉽게 해주는 프로그램 입니다 - 을 만듭니다.


Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절



원문보기

Joel on Software

Solid State Disks

By: Joel Spolsky

  Friday, March 27, 2009


  FogBugz 개발자 중 한명이 컴파일이 너무 느리다고 (약 30초) 불만을 이야기 했습니다. 느린 컴파일 시간 때문에 복도에서의 칼싸움(Sword fights in the hallway) 이 너무 자주 일어난다는 겁니다. (이미지 참조 - http://xkcd.com/303/) 그는 제게 개발자를 몇주간 투입해서 병렬처리를 통해 컴파일 시간을 끌어올릴 방법을 찾는 것이 어떻겠냐고 제안했습니다. 우리는 모두 멀티 코어 CPU와 넉넉한 메모리를 갖고 있으니까요.

  
  저는 문제해결을 위해 비싸고 귀중한 개발자들의 시간을 투입하기 보다는, 먼저 돈을 써보는 것이 더 좋겠다고 생각했습니다. 그리고, 저는 인텔 X25-M SSD에 관한 아난드(Anand Lal Shimpi)의 최신 리뷰를 막 읽었을 때였습니다. 그래서 저는 여기있는 하드디스크 중 몇개를 SSD로 바꿔서 성능 개선에 도움이 되는지 실험을 해보기로 하였습니다.

  첫번째 실험은 FogBugz 월드 투어를 위해 구입했던 18개월된 구형 IBM Thinkpad X61 노트북을 업그레이드 하는 것이었습니다. NewEgg.com에서 160GB Intel X25-M 하드드라이브가 장착된 신모델을 760 달러에 구입했었습니다.

  여러분의 이전 하드 디스크를 메인 부트(Main boot) 하드 디스크를  새 하드디스크로 교체하는 하는 기술은 파티션, MBR, 그리고 데이터를 완전히 똑같이 새 하드로 복제하는 것입니다. 이 기능을 하는 프로그램이 몇가지 있습니다. 오픈 소스 어플리케이션인 Clonezilla가 있습니다만, 이건 여러분의 시간이 무가치할 때만 진짜 공짜 입니다.

  다른 인기있는 상용 프로그램들 중 제가 사용해본 두가지는 Symantec Norton Ghost 14Acronis Migrate Easy 7.0 입니다.

  Thinkpad에서 고스트와 미그레이트 모두 잘 동작하지 않았습니다. 제 생각에는 아마도 Thinkpad의 MBR에 뭔가 특이한 것이 있는 것 같습니다. 하드 드라이브를 복제하기 위해 시도할 때마다, 부팅이 안됬습니다. 하루하고도 반나절을 여러가지 방법으로 해보다가 날렸습니다. 심지어 우반투(Ubuntu) Live CD로 부팅해서 모든 파일을 복사하는 방법까지 해봤습니다만, 소용 없었습니다. (이 방법은 정상적으로 동작하지 않았습니다. 윈도우는 돌아가는 것처럼 보였지만, 많은 작은 부분들이 실제로는 깨져있었습니다.)

  결국, 저는 포기하고 모든걸 다시 설치할 수 밖에 없었습니다. 재미는 없었지만, 지금 전 더 크고 더 빠른 SSD를 장착한 새 노트북을 갖게 되었습니다.

  한가지 장비는 정말로 유용합니다. Thermaltake BlacX Docking Station 입니다. (이미지 참조) 이것은 2.5인치와 3.5인치 SATA 하드 디스크를 통째로(raw) 구울 (toaster)수 있습니다. 어떤 하드드라이브던지 위에 꽂고 USB 2.0으로 PC에 연결하면, 확실히, 여러분의 하드디스크는 연결된 것입니다. NewEgg.com에서 37달러에 살 수 있습니다.


  간단한 벤치마킹 테스트를 해보았습니다. 여기서 나오는 숫자들을 심각하게 받아들이지는 마십시요. 저는 많은 테스트를 해보지도 않았고, 모든 것을 정확하게 테스트하기는 매우 어렵습니다. 부팅 시간은 2:11 에서 0:34로 줄었습니다. 이 시간은 부팅에서 화이어폭스 브라우져로 (Firfox) Goole.com에 접속하는데 까지 걸린 시간입니다. 6개의 메이저 어플리케이션을 시작하는 시간은 20초에서 10초로 줄었습니다. 일반적으로, 프로그램을 구동하는 시간이 빨라지면 엄청나게 큰 차이를 만들어내며, 이것은 완전히 가치있는 일입니다. 이 작은 노트북은 이제 제가 사용해왔던 컴퓨터 중에서 가장 빠른 컴퓨터가 되었습니다.

  제 다음 실험은 메인 데스크탑(Desktop) Dell Optiplex 745를 업그레이드 하는 것입니다. 이번에는 Acronis Migrate Easy가 한번에 완벽하게 동작했습니다. 문자 그대로, 제가 한일은 하드 드라이브를 복제하고, 컴퓨터를 끄고, 새 하드로 바꿔달고, 끝이었습니다. 짜잔~

  갑자기, 모든 것이 빨라졌습니다. 부팅, 프로그램 시작, 심지어 아웃룩(Outlook)조차 1초 안에 사용할 수 있게 되었습니다. 이것은 정말로 대단한 업그레이드 였습니다.

  하지만... 컴파일 시간은, 음, 그리 많이 빨라지지 않았습니다. 컴파일 시간은 30초에서... 30초로 줄었습니다.

  우리가 사용하는 컴파일러는 싱글 쓰레드(single threaded)이고, 아마도 제 추측에는, CPU 관련된 작업이 IO 관련된 작업보다 훨씬 더 많은 것 같습니다. 뭐, 좋습니다. 우리는 아마도 모든 개발자의 데스크탑을 SSD로 업그레이드 할 것입니다. 왜냐하면 컴파일 외에 다른 모든 것을 팔팔하게(snappy) 만드는 것은 그들의 삶을 향상시킬 것이기 때문입니다. 하지만 여전히 컴파일러를 병렬화 하는데 개발자들의 시간을 들여야 한다는 압박은 남아있습니다.
(끝)

저자에 관하여
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


BLOG main image
일상, 프로그래밍, IT 그리고 직장생활, Dive, 여행 by 지그프리드

카테고리

Class List (402)
Studies (30)
Exercise & Quizz (10)
Term Project (0)
ECIM list (Help!) (10)
Issues & News (0)
Gossip about IT & Job (22)
Tools (2)
Think about the Justice (23)
Book Review (170)
조엘 온 소프트웨어(번역) (28)
Diary (87)
Vacations (9)
Clash of clans 클래시 오브.. (11)

글 보관함

달력

«   2021/06   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
Total : 328,743
Today : 13 Yesterday : 22