반응형

 하나의 프로젝트가 시작되면 언젠가는 끝이 나는 것이 정상이다. 하지만, 좀처럼 끝을 내지 못하는 프로젝트들도 더러 보게 된다. 끝을 보지 못하는 다양한 이유가 있겠지만, 그중에서 가장 중요한 것이 무엇이라고 생각하는가? 개발자 관점에서 바라보면 답은 이미 나와있다. ‘프로그램을 잘 만들어야 한다.’ 얘기하기 쉬울 것이다. 하지만, 필자는 프로그램보다 더 우선시 되어야 하는 것이 있다고 생각을 한다. 그것은 데이터이다.  

 

데이터 하면 조금 막연한 것 아니냐 하겠지만, 개발자와 데이터는 매우 밀접한 관계가 있다.

지금부터 그 부분에 대해서 필자의 경험에 비추어서 얘기하고자 한다.

 

IT 경력이 늘어가면 갈수록 늘어가는 것들이 수없이 많다. 제일 먼저 쉽게 불어나서 빠질 생각을 못하는 살이다. 이건 야근을 너무 많이 한 탓이라고 열심히 일을 한 흔적이라 스스로 위로해 본다. 그다음으로 모든 사람이 공감하는 것 중 하나가 바로 늘어가는 실력이다. 실력은 연차에 비례하여 늘어가는 것은 아니지만 아무리 못하는 사람도 예전보다 더 잘하게 되는 것이 정답일 것이다. 여기서 난 벌써 5년 이상을 IT에 몸담았는데 늘어나는 것은 말뿐 실력이 늘어가는 것이 없어요 말을 한다면 그 사람에게 한가지 깊이 충고해 주고 싶다. “당신은 IT가 적성이 아니라고…” 냉정하게 보일지 모르지만 사실이다. 아무런 노력 없이 즐기며 흡혈귀 피를 빨아먹듯이 다른 사람의 공을 자기 것으로 돌리는 말재주만 가진 사람일 것이다. 어느 프로젝트에나 이런 인종들이 존재한다. 항상 프로젝트를 시작하기 전에 제발 저런 사람이 없기를 기도해 본다.

 

AP0A26.JPG필자가 뜬금없이 저런 얘기를 해서 의아해할지 모르지만, 개발자라면 어려움이 있거나 모르는 것이 있을 때마다 책을 보며 길을 돌파구를 찾게 된다. 하지만, 말로 모든 것을 처리하는 사람들과 얘기를 하거나 논쟁이 벌어지면 개발자가 아무리 뛰어나도 말로써는 당해낼 재간이 없을 것이다. 그러면 어떻게 하는 것이 맞을까? 생각해 보면 아무도 피해가지 못하는 것 중에 으뜸이 데이터이다. 겉으로 아무리 포장하고 감추더라도 데이터의 상태를 확인하면 쉽게 확인되기 때문이다.

 

어떤 프로젝트에서 말로는 달나라도 갔다 오는 사람과 논쟁이 벌어지는 시점이 되었다. 앞으로 3주 후에 프로젝트 Go Live를 결정하는 중요한 시점에서 마저 자신이 처리하는 부분에는 아무런 문제가 없다고 전체 회의 석상에서 자신 있게 말하는 모습을 보며 오만 가지 욕이란 욕들이 머릿속으로 떠오르고 있었다. 끝내기로 했던 납기를 지난 상황에서 지금까지 완성이 안된 것은 10%도 안 되고 충분히 일주일 동안에 처리할 수 있다고 다고 얘기를 하며 사람들을 설득하고 있었다. 약속이 지난 것을 프로그램의 완성도를 높이고 예외처리를 위해서 걸리는 시간이라고 둘러대며 모든 사람이 설득당하는 순간 한 명이 다음과 같이 제의를 했다. 지금 당장 돌려보자고 모든 것이 드러나는 시점에 너무도 당당하게 보여주며 순조롭게 넘어가는 것 같았다. 포장의 달인이라 그런지 정말 문제가 없어 보였으며 전날까지 아무것도 안되던 일을 정상적으로 작동하는 것이다. 놀랍고도 신기한 생각이 들었지만, 한순간 모든 것이 들통나고 말았다. 결정적인 계기가 된 것은 데이터를 직접 확인하는 순간 발견하게 되었다. 보여준 데이터의 절반이 강제로 프로그램에서 강제 하드 코딩으로 처리해서 겨우 나온 값이었던 것이다. 그가 이미 신뢰를 잃지 않았다면 확인도 안 하고 넘어갔을 것을 생각하면 이럴 때 정말 어처구니가 없구나 하는 생각을 하게 되었다.

 

프로그램은 거짓말을 해도 데이터는 거짓말을 못한다. 이 말은 진실이다.

 

개발자는 프로그램만 잘 만들면 끝난다는 생각을 하지 말자. 왜냐하면 개발자보다 데이터를 더 잘 알고 있는 사람은 없다고 본다. 우리는 원석을 다듬는 석공들처럼 가공하고 쓸만하고 보기 좋게 만들기 위해서 노력하며 그것을 통해서 답을 얻기 때문이다.

 

개발자로서 모든 문제를 프로그램에서 해결하고자 하는 사고방식은 너무도 위험한 결과를 가져온다. 아무리 급하더라도 데이터에 관심을 두어야 하며 데이터를 통해서 프로세스를 이해 하도록 하고 그때야 그것을 멋지게 포장하기 위해서 프로그램을 사용해야 함을 명심해야 한다.

 

어느 정도 말로써 자신의 의견을 표현하는 법도 배워야 한다. 하지만 개발자에게 있어서 자신의 의사를 정확하게 표현하는 방법으로 가장 좋은 것이 데이터이며, 우리가 사용하는 데이터 속에는 진실이 존재한다는 사실을 항상 명심해 주길 바란다. cess98@paran.com


반응형
< 출처 : http://www.idg.co.kr/newscenter/common/newCommonView.do?newsId=57714 >

 현재 미국에서 K 모사 일을 하고 있지만, 우리나라만의 새로운 운영체제를 발표한다는 소식을 듣고 관련 동영상과 문서를 보면서 필자도 모르게 아쉬운 마음을 감출 수 없었다. 특히, 많은이들이 공감하듯이 개발자의 이혼이야기며, 건강이야기를 자랑스럽게 이야기하는 부분에서 흥분하지 않을 수 없었다. 과연 이것은 회사의 경영진의 문제일까? 아니면, 개발자 자신의 문제일까? 필자는 무엇보다도 개발자의 자발적인 자기관리가 중요하다고 생각한다.

개발자가 반드시 관리를 해야 하는 부분을 안과 밖으로 나누어 설명할 수 있는데, 안이라고 하면 정신적인 것과 관련된 이야기이며 밖은 육체적인 것과 관련된 이야기다. 이 둘의 조화가 얼마나 중요한지 짚고 넘어가야 한다. 한번이라도 개발을 해보았던 사람들이라면 누구나 공감을 할 것이다. 아래와 같은 상황을 가정하고, 결과를 한번 상상해보자.

술김에 프로그램을 만들어 본 기억이 있는가?

어느 프로젝트에서 일이 너무도 힘들어서 홧김에 술을 마시고 코딩을 했다면, 그 당시에는 이것이 얼마나 잘못된 일인지 알지 못한다. 멀쩡한 정신에 프로그램을 만들어도 자신이 어디서 실수를 했는지 찾기는 그렇게 만만치 않은데, 하물며 술을 마시고 프로그램을 만들었다면 이건 진짜 대박이라고 하는 표현이 맞을 것이다. 술의 힘을 빌어 프로그램을 만들게 되면 당사자도 놀라울 정도로 척척 코딩이 이루어진다. 하지만 술이 깬 다음 날 자신이 만든 프로그램을 보게 되면 도무지 이해가 되지 않는 부분들을 발견하게 된다. 어디까지 만들고 어디까지 수정을 했는지 알 수가 없게 된다. 그러니 더더욱 혼자서 만드는 소스가 아닐 때에는 오히려 찾아서 원상복귀 시키는 것조차 어렵게 된다. 이런 얘기를 해서는 안 되겠지만 필자 역시도 경험이 있기에 그게 얼마나 위험한 상태인지 알기에 얘기를 하는 것이다.

아픈 상태에서 프로그램을 만들어본 기억이 있는가?

깊이 생각할 일도 아닌 것 같다. 가벼운 감기,몸살만 걸려도 정신이 몽롱하고 집중이 안 되어 도저히 프로그램 개발이 안되는 경우를 경력이 좀 되는 개발자라면 누구나 경험해 보았을 것이다. 일반적인 프로젝트에서는 그런 사람이 옆에 있으면 오히려 기존 프로그램마저 망칠까 봐 일찍 귀가를 시키는 경우를 종종 볼 수가 있다. 몽롱한 상태에서 아무리 개발을 해봐야 그건 그냥 시간 잡아먹기에 불과하며 상황을 오히려 악화시키는 불완전한 요소가 될 뿐이다.

그렇다면, 개발자 중에 개발 때문에 이혼까지 하고 자신이 아픈 줄도 모르고 개발을 한 사람이 있다는 사실은 결코 자랑해서는 안 되는 부분이지 않을까. 이혼까지 갔다면 도중에 맨정신으로 개발이 가능 했을까? 아픈 줄도 모르고 개발을 했다면 제대로 된 코딩이 가능 했을까? 잠도 못자고 개발을 했다면 새로운 영역의 개발인데 정말 제대로 된 프로그램이 만들어 졌을까? 하는 의문만 남게 만들었다. 어떤 의미로 얘기를 했는지는 이해는 되지만 결코 자랑할 부분이 아니라는 생각이 들며 진짜 너무 고생, 고생하며 개발한 개발자들을 한꺼번에 바보로 만들었다는 생각이 들었다.

개발자가 하나의 프로젝트를 끝까지 무사히 끝내고 싶다면 체력은 반드시 갖추고 있어야 한다. 보약을 먹든지 아니면 운동을 하든지 끝나는 그 순간까지 견딜 힘의 원천이 필요한 것이다. 정신적인 것도 역시 마찬가지라고 생각한다. 일주일 내내 오직 일에만 전념한다면 정말 중요한 시점에서 모든 것이 고갈되고 말 것이다. 주말에 휴식하는 것도 다음 일주일을 위한 배려이다. 하루 이틀 바짝 밤샘하며 일을 하는 것과는 다른 얘기이다. 장기 프로젝트 경우 개발자들 중에 보약을 먹으며 체력을 쌓거나, 운동을 하고 정신적인 스트레스를 운동으로 푸는 등, 자기만의 비법으로 장기전에 대비하는 경우를 쉽게 볼 수가 있다. 필자 역시도 체력적, 정신적인 면의 해결을 위해서 이젠 약보다는 운동에 힘쓰고 있다. 운동을 하면 살도 빠지고 맑은 정신을 오래 유지할 수 있도록 해주는 숙면도 제공하기에 적극 추천한다. ‘건강한 신체에 참신한 아이디어가 깃든다’는 상투적인 표현을 굳이 부연 설명할 필요는 없을 것이다. 육체적인 면만 강조하는 우를 범하지 말아야 한다. 모든 것은 조화에서 비롯된다.

그리고 이 말도 해주고 싶다. 하루 이틀 밤샘으로 끝날 일이 아니라면 무작정 자신을 혹사시키며 일한 것이 결코 자랑은 아니라는 것이다. 행복한 개발자가 되고 싶다면 자기관리는 스스로 해야만 한다. 제삼자가 해주는 것이 아니다. 개발자에게 균형있는 자기관리는 현재, 그리고 미래를 위한, 어쩌면 가장 중요한 투자이기 때문이다. cess98@paran.com


임철우님의 컬럼이 또 올라왔길래 읽다가 퍼오게 되었다.
국내 기업중 모기업에서 운영체제 개발 과정에 대한 에피소드 소개시에 나온 이야기를 나도 들었었다.
그 기업에서는 힘든 프로젝트이고 모든 팀원들이 모두 열심히 노력했다는 취지이겠지만
개발자들의 일은 단순히 작업시간에 비례하여 그 성과가 나오는 것은 아니라고 생각하기 때문이다.
위에서 언급한 것과 같이 아프거나 다른데 신경쓸일이 있거나 술에 취하거나 하는 경우는
일의 특성상 좋은 프로그램을 만들어 내는 것이 어려운 것이다.
기계적으로 처리할수 있는 단순공정이 아니기 때문이다.
개발은 근본적인 문제를 해결하는 활동이고 문제를 해결하려면 창의력이 필요하다고 한다.
소프트웨어 문제를 해결하는 활동은 어떤 활동보다도 아주 복잡한 과정임을 인정해야 한다.
관라자 측면에서는 이러한 특성에 대한 이해가 필요하리라 생각한다.
사람은 기계가 아니며 소프트웨어 개발은 기계가 할수 있는 단순 작업공정이 아님을 인지하고
소프트웨어 개발에 대한 특성을 고려하여 이에 대한 환경을 조성하고 관리해야 할것이다.
요즘 읽고 있는 "소프트웨어 크리에이티비티 2.0"  내용을 조금 인용하였다.
반응형
출처: http://www.idg.co.kr/newscenter/common/newCommonView.do?newsId=52482

임철우님의 컬럼입니다. 전에도 스크랩해서 다른 글을 포스팅한적이 있습니다.

시간을 내서 다시 찾아서 못읽었던 다른 컬럼을 읽고 또 포스팅 합니다.

요즘은 거의다 스크랩해서 올리게 되는거 같군요. 임철우님의 컬럼 시간내서 읽어보시길..

정말 좋은 글들이 많이 있습니다.  가슴에 와닿는 글들도 많고..

 

AP76F8.JPG해마다 이맘때면 시내 한복판에서 쉽게 구세군들을 만날 수가 있다. 그들이 왜 추운 거리에서 자그마한 정성을 모아 불우한 이웃을 돕자고 열심히 종을 치며 사랑의 모금을 하는지 생각해 볼 필요가 있다. 무엇인가 나눌 것이 있다는 것은 참 행복한 것이다. 어쩌면 손해를 본다는 생각이 들겠지만 조금만 다른 시각에서 바라보면 전혀 다른 행복이 보이기 시작할 것이다.

  

개발자라면 꾸준히 새로운 지식을 익힐 필요성을 느끼게 될 것이다. 필자가 처음 개발자로 입문을 했을 당시에는 지금처럼 인터넷이 활성화가 안 되어 있던 시절이었고 개발을 하다 막히는 부분이 있으면 하루고 이틀이고 밤을 새워가며 해결하기 위해 끊임없이 원인을 찾기 위해 노력을 해야만 했다.

 

한번은 문제가 해결될 기미도 안보이고 거의 포기 상태까지 이르렀을 때 같이 일하던 A선배가 비슷한 경험이 있다며 힌트를 주었고, 그로 말미암아 다른 관점에서 접근을 하게 되어 일을 기한에 맞추어 끝냈던 기억이 난다.

 

반면, 당시 실력은 월등히 좋았지만 옆에서 힘들어 하는 걸 뻔히 보면서도 도움을 주지 않았던 B라는 선배도 있었다. 그 이후에도 A선배는 뛰어난 실력은 아니어도 자신이 알고 있는 것을 정리해서 가끔 필자에게 알려 주었고, 덕분에 다양한 개발 팁을 배우게 되는 등 회사 생활을 하는데 많은 도움을 받았다. B선배의 경우는 어려운 일을 혼자서 다 처리했기에 역시 회사 생활을 하는데 도움을 받은 것은 사실이다.

 

하지만 A, B선배와는 서로 다른 회사로 옮기면서 확실하게 차이가 벌어지게 되었다. A선배와는 계속 연락하며 지내지만, B선배와는 연락을 하는 일이 전혀 없어진 것이다. A선배와는 왠지 모르는 인간적인 유대가 생겼고 B선배와는 그저 일 때문에 만난 사람이기에 더 이상 관계가 발전되기 힘들기 때문이다. 직장에서 만난 사람들과 오랫동안 서로 알고 지내는 일은 솔직히 좀처럼 쉽지 않다.

  

실력이 우선시 되는 사회인 것만은 사실이다. 하지만 독불장군처럼 알고 있고 기술을 나눌 줄 모르는 사람이라면 아마도 개발자로서 오랫동안 생활하기에는 어려움이 있을 것이다. 모든 지식을 혼자서 다 익힐 수는 없기 때문이다. 그리고 자기만 알고 있다고 생각하는 신기술 또한 알고 있는 사람이 있기에 자신도 알고 있는 것이고 그렇다면 언젠가는 다른 사람들 또한 알게 될 것이다. 어떤 사람이 그 기술을 공유하려고 할 때 "나도 알고 있는데…" 이런 말을 하게 된다면 한다면 오히려 욕을 먹을지도 모른다.

  

현재 거의 모든 프로젝트는 여러 사람이 톱니바퀴처럼 딱딱 맞아야 비로소 성공적인 프로젝트로 갈 수 있다. 내가 알고 상대가 모른다면 지식을 공유해야 하는 것이 개발자의 예의라고 생각한다. 기술의 공유에 있어서 지위가 높고 낮음은 없으며, 새로운 지식을 습득하게 되면 다른 사람들과의 공유는 필수이며, 알려주려고 하는 사람을 오히려 잘난 척 한다고 생각하는 사람이 있다면 그 사람은 남보다 발전이 늦을 것이며 그 사람은 왜 쉽게 갈 수 있는 길을 어렵게 돌아가려 하는지 생각해봐야 한다. 사전 정보를 가지고 시작하는 것과 모르고 시작하는 것은 천지차이다.

  

신기술이나 팁을 공유함으로써 자신에 돌아오는 것이 무엇인가? 그것은 사람이다. 바로 이것이 나누면 행복해지는 이유이다. 나를 인정해주고 어려움이 닥쳐도 함께 해줄 동료가 한 명이라도 있다면 개발자로서 성공한 거라고 생각한다. 이 글을 통해 내가 지금 힘들 때 정말 나를 도와줄 개발자가 몇이나 되고 연락 가능한 사람이 몇이나 되는지 돌아보는 계기가 되었으면 좋겠다.



반응형
<출처: http://www.idg.co.kr/newscenter/common/newCommonView.do?newsId=51617 >

임철우님의 행복한 개발자 칼럼입니다. 조금 날짜가 지난 글이긴 합니다만 읽다가 퍼왔습니다.

기타 다른 주옥같은 글들이 많이 있네요. 그리고 이번 글은 요즘 제가 많이 느끼고 있는 부분이기도 합니다.

참고로 '아키텍트 이야기'란 책에 이글과 비슷한 맥락의 글이 기억에 납니다.

프로그래머로서 개발자로서의 자만에 대한 질책(?)이 될수도 있을것 같습니다.

기술과 업무.. 많은 개발자들이 이것들 중에서 업무에 대해 좌시하는 경향이 있는지도 모르겠습니다.

므튼 시간날때 임철우님의 행복한 개발자 칼럼을 쭉 읽어 봐야 겠습니다.

행복한 개발자를 꿈꾸며~~ 오늘도 야근입니다.. 개발자의 결혼 적령기에 관한 글도 좋은것 같습니다.^^
  AP7E92.JPGTV에서 이런 광고를 본 기억이 난다. 모두가 “아니오”할 때 “네”라고 대답을 하고, 모두가 “네”라고 대답을 할 때 “아니오”라고 했던. 자신의 생각을 확실하게 정하고 주변에서 뭐라고 하든지 자신의 생각을 펼치라는 내용으로 기억된다. 개발자로 일을 하는 것도 다름이 없다.

 

개발자로 일을 하려면 ‘십 분의 일이 되는 것’을 염두에 두어야 한다. 여기서 십 분의 일이란, 십을 이루는 기초를 이야기 한다. 기초를 먼저 탄탄히 하라는 의미다. 왜 그런지 살펴보자. 먼저, 같이 일을 했던 신입 개발자들에 대해서 잠시 얘기를 해보는 것이 좋을 것 같다.

 

어느 날인가 신입으로 들어왔던 B라는 개발자가 같이 들어왔던 신입 사원들보다 자신이 뒤떨어지는 것 같아서 계속 개발자로 일하는 것에 대해서 고민을 하게 된다는 이야기를 꺼냈던 일이 있다. 이런 얘기는 신입이면 누구나 한번쯤은 경험하게 되는 일련의 과정이라는 생각이 든다. 혼자서 열심히 짜는 프로그램과 다른 사람들과 같이 만드는 프로그램의 차이에서 오는 고민일 것이다.

 

처음에 개발자로 입문한 사람들은 프로그램에 대한 자신감이 있기에 개발자로서의 사회생활을 시작하게 되었을 것이다. 하지만 그 자신감은 어디까지나 혼자만의 생각일 뿐. 자신의 지식은 전체를 파악하지 못하고 일부분이 전체인 것처럼 보는 장님이 코끼리 다리를 만져 보고 이것은 무엇이다 하는 격이다.

 

다시 B의 고민으로 돌아가보면, 필자는 한 프로젝트에서 A와 B 두 개발자에게 같은 일을 지시하고 결과를 기다리고 있었다. A는 빠르게 처리를 했고 일 처리 속도가 떨어지는 B는 A에게 새로운 일이 주어질 때까지 끝내지 못하고 혼자 남아서 늦게까지 일을 하게 됐다. 결국 둘은 점점 차이가 벌어져 A에게 B가 처리해야 할 일까지 하나 둘씩 넘어가게 되었다.

 

이런 업무상의 차이에 대한 고민을 호소하는 B에게 필자는 이런 얘기를 해 주었다.

 

“개발자에게 있어서 가장 중요하다고 생각하는 것은 업무에 대한 이해다. 업무 프로세스에 대한 이해도가 가장 중요하며 그것을 구현하는 기술력은 그 다음이다.”

 

지금은 비록 기술력이 부족해서 쉽게 일 처리를 못하더라도, 그건 시간이 지나면서 자신이 조금만 더 노력한다면 극복 가능한 문제다. 하지만 업무 프로세스의 이해 없이 단지 기술로만 승부하려 한다면 최소 이중삼중으로 수정 해야 하고, 이는 점점 불어나 결국에는 일이 재미가 없어지고, 현업들로부터 일을 잘한다는 소리를 듣지 못하게 된다.

 

“그럼 어떻게 하는 것이 올바른 방법일까?”하고 머뭇거리며 질문하는 B에게 이렇게 대답해 주었다.

 

“프로그램으로 어떻게 구현할 것인가 보다는 왜 이런 업무가 필요한지를 먼저 생각해야 한다.”

 

프로그램으로 모든 것이 구현 가능하다고 생각할지 모르지만 실제적으로 업무란 것은 A나 B선에서 끝나지 못하는 경우가 태반이며, 어느 정도 확장을 고려해 두어야 한다.

 

개발이 끝났다고 생각한 시점 이후에 어쩌면 A부터 Z까지의 경우의 수로 일이 커질지 모르는 상황에서 자기가 맡은 부분만 보려고 하면 안 된다. 업무에 대한 이해도가 높다면 얼마든지 말로도 충분히 해결할 수가 있다. 그러면 일 잘 한다는 얘기를 듣게 될 것이다.

 

프로그램 100라인을 들여서 코딩을 해야 되는 것을 단지 업무에 대한 이해도 덕분에 10라인의 코딩으로 마무리하는 것도 가능하며, 같은 100라인이라고 해도 요건에서 생각지도 못했던 에러에 대응해 처리도 가능하게 된다.

 

시간이 흘러 B는 다른 프로젝트를 하게 됐는데, 우연히 B와 같이 일하는 현업으로부터 B가 일을 잘한다는 소리를 듣고는 왠지 기분이 좋았다. 아직도 프로그램 코딩 실력은 부족하다고 하지만 계속 자기 개발을 해나가면 실력이 좋은 개발자가 될 것이다.

 

십 분의 일이란 앞서 언급했던 CF처럼 남들이 다 “아니오”라고 말할 때 “네”라고 말하기 위해서 갖추어야 할 최소한의 조건이라고 생각한다. 어떤 상황에 처했을 때 자신에게 필요한 것이 무엇이며 핵심과 전후 상황을 파악하는 능력이 말이다. 이런 능력은 태어날 때부터 선택 받아서 얻게 되는 것이 아니며, 경험과 훈련에 의해서 이루어진다. 어쩌면 이런 습관이 몸에 밴 개발자를 보게 된다면 사람들은 고집이 세며 아는 체(잔머리 굴리는 사람)를 많이 하는 사람으로 오해 할지도 모르겠다.

 

이렇게 되기 위해서는 무슨 말을 했을 때 그게 왜 그럴까? 그럼 어떻게 될까? 자신도 모르게 습관적으로 생각해야 된다. 자신의 생각이 맞으면 모든 것이 즐거워진다. 이게 극단적으로 발전하면 전혀 경험이 없는 일도 알고 있는 척하는 것이 가능하다. 주의할 점은 모르는 사실에 대해 답을 했을 때는 반드시 자신이 했던 말이 올바른 대답인지 찾아봐야 하고 틀린 답이었다면 다음에 반드시 그게 아니었네요 하고 솔직하게 대답하는 습관을 들여야 한다. 아니면 거짓말쟁이로 전락하게 되어 아무도 믿어주는 사람이 없게 될지도 모른다.

 

십 분의 일, 간단한 습관이지만 행복한 개발자가 되어가는 하나의 팁이다.



+ Recent posts