일하는 법

내가 맡은 일은 내가 끝까지 책임진다는 책임자 마인드

우선 실수가 없도록 꼼꼼하게 체크하는 건 기본, 프로젝트의 한 파트를 맡게 된 것라고 해도 진행상황이 어떤지 주기적으로 체크하고 추가할건 없는지 확인하면서 일을 마무리 될 때까지 신경써야 하니다.

보통은 일정을 맞추는 것에서 오류가 많이 나고, 앞으로 본인은 물론 다른 사람들의 일정관리를 해야 하는 경우도 많으니 특히 신경써야 합니다.

보고 전/업무 완료 전 내용 검토하기

논리없는 일의 진행을 막고, 감정적이 아니라 이성적으로 꼼꼼한 일처리를 하기 위해서는 검토가 가장 중요합니다. 모든 일에 타당성이 있어야 하기 때문에 중간 보고를 할 때나 업무를 마루리 하기 전에 최소 한 번은 검토를 해봐야 합니다.

만약 후배의 업무 보고를 받았는데 통과시킬 수 없는 보고서라면 무엇이 잘못된 건지 코멘트를 달아서 피드백을 주는 게 좋습니다.

말을 하기 전에 상대방 입장에서 생각하기

회사뿐만 아니라 사회생활을 하는 모든 청년들이 갖추길 바라는 태도입니다. 나는 별다른 뜻 없이 말한 것도 상대방에겐 고민과 혼란을 부르는 의미로 다가갈 수 있습니다. 회사에서 듣는 상사의 말은 더 그렇습니다. 그러니 혹시나 생길 불상사를 위해 내 말이 상대방에게 어떻게 다가갈 지 한번은 생각해봅니다.

업무 실수가 잦거나 지각 등의 기본적인 태도가 고쳐지지 않는다면, 당연히 쓴소리가 나겠지만 팩트만 가지고 얘기를 해야하고, 외모나 취향 등 업무에 1도 영향을 미치지 않는건 속으로만 생각합니다.

직장생활 중 실수가 가지는 의미

직장에서 실수가 많게 되면 회사의 중요한 업무적인 부분에 악 영향을 줄 수 있습니다. 그러한 실수가 공개적으로 비판을 받을 경우에는 개인에게 치명적인 약점이 될 수 있습니다. 중요한 보고를 실수로 빠뜨린다거나 기한을 지키지 못하는 것, 그리고 보고서에 오탈자가 많은 것 등

이러한 실수는 상사로 하여금 불안하게 하고 중요한 업무를 맡기지 않는 결과를 초래합니다. 그렇게 될 때 본인이 회사에서 인정받는데 커다란 걸림돌이 될 수 있습니다. 따라서 회사에서 성실히 생활하는 것도 중요하지만 잦은 실수를 하지 않아야 합니다.

실수가 많은 사람들의 공통적인 특징

성격적인 특징

성격적으로 꼼꼼하지 못해 실수가 많은 경우가 있습니다. 이러한 성격은 쉽게 고쳐지는 것이 아니기 때문에 자신만의 철저한 원칙을 잘 세워야 합니다. 메모/기록하고, 검토하고, 꼼꼼한 동료의 도움을 구하는 등 여러 가지 다양한 방법들을 시도하다 보면 어느새 자신의 실수가 줄어드는 것을 느낄 수 있습니다.

  • 하나의 태도가 습관으로 형성되어 오히려 자신의 실수를 통해서 더 좋은 습관을 형성할 수도 있습니다.

마음가짐의 문제

업무에 대한 열정이 부족한 경우입니다. 자신이 맡은 업무를 최선을 다해서 하기 보다는 회사에서 요구하는 부분만을 소극적으로 하는 경우입니다. 업무에 관심과 열정이 없다 보니 그로 인해 실수가 나오게 됩니다. 문제가 그러한 실수가 있다 하더라도 심각하게 여기지를 않고 지속적으로 실수를 범하게 됩니다.

따라서 우리는 마음가짐을 바로 해야 할 필요가 있습니다. 아무리 비중이 적고 사소한 부분이라도 직장의 업무에 최고의 열정과 혼을 다하는 자세로 일을 해야 합니다. 사소한 업무라 하여 늘 실수를 하게 되고 자신도 그러한 부분을 대수롭지 않게 생각한다면 회사도 중요한 업무는 더욱 맡기지 않고 스스로 도태될 것 입니다.

지나친 사생활 추구

업무 중에 지나치게 자신의 사생활에 집중할 때 이러한 문제가 발생할 수 있습니다. 회사에서 가정의 일을 계속해서 신경을 쓰고, 주식에 관심을 두고, 인터넷 서핑을 좋아하는 경우 등이 있습니다. 사람은 다른 곳에 마음을 쓰면 당연히 다른 부분은 자신의 마음에서 멀어지게 됩니다.

다른 마음을 품고 있으니 깔끔한 업무처리를 못하고 잦은 실수를 하게 됩니다. 따라서 회사에서는 회사의 일에 몰두를 해야 합니다. 업무시간에는 집중력을 발휘해야 합니다. 회사업무 외에는 사생활에 너무 지나친 관심을 가지지 않도록 자기관리를 해야 합니다.

업무실수의 현명한 대처법

지나친 욕심은 금물

업무상의 실수는 과도한 욕심으로 인해 발생하는 경우가 많습니다. 특히 자신의 권한 밖의 일에 지나친 의욕을 갖고, 능력 밖의 일에 매달릴 때 일어나기도 합니다. 자신의 권한 밖의 일을 결정했을 때 직장생활에서 가장 큰 피해를 볼 수 있습니다.

이럴 떄 상사의 꾸지람을 피하고자 보고를 하지 않거나 혼자서 끝까지 처리하려는 생각은 더욱 심각한 문제를 불러올 수도 있습니다. 나중에 자신의 실수가 밝혀지면 골칫거리라는 인식이 생길 수도 있고 앞으로의 회사생활에 악영향을 끼칠 수도 있습니다. 실수를 처리하는 것도 중요하지만, 무리하게 자신의 수준을 벗어나는 행동을 예방하는 것도 중요합니다.

이미 늦었다는 생각은 금물

보고는 최대한 빨리해야 합니다. 상사는 보고의 누락에 굉장히 민감합니다. 이미 늦었다는 생각으로 보고를 빠뜨리는 일이 없어야 합니다. 보고해야 할 순간을 놓쳤다고 해서 보고를 아예 하지 않는 무책임한 행동은 직장생활을 그만하려는 것과 다름이 없습니다. 직장에서는 보고에서 보고로 끝난다는 것을 명심해야 합니다.

실수가 생겼다면 상사가 다른 사람을 통해 그 사실을 알기 전에 신속하게 보고해야 합니다. 그 시점에는 눈앞이 캄캄하겠지만, 시간은 그 문제를 서서히 해결해 줄 것 입니다.

대면하기 두렵다는 생각은 금물

많은 직장인이 실수를 보고할 때 상사와 대면해야 하는 데 부담을 느낀다고 합니다. 그러므로 보고가 늦어지는 경우도 많습니다. 매도 먼저 맞는 것이 낫다고 마음을 단단히 먹고 먼저 보고하는 것이 좋습니다. 하지만 상사의 성격이 불같아서 조금 돌아가고 싶다면 이메일이나 메신저로 미리 보고하는 것도 방법입니다.

자초지종과 근거를 자세히 설명하고, 자신의 실수에 대한 내용도 간단하게 첨부하면 됩니다. 이메일이나 메신저로 실수에 대한 내용을 보내놓고 처리되기를 기다리는 것은 안됩니다. 상사가 내용을 인지한 것을 확인하면 직접 찾아가서 부연 설명을 해야 합니다. 이 방법은 상사가 혼자 생각할 시간을 주기 때문에 상황을 조금 유하게 만들 수 있습니다.

업무실수 만회하기

업무실수 신속하게 보고하기

평소와 다름없이 업무를 하던 중에 자신이 저지른 업무실수를 깨닫게 되었다면 그 시점에서 가장 현명한 대처법은 자신의 잘못에서 도망가기보단 신속하게 상사에게 업무보고를 하는 것 입니다. 업무 실수를 발견한 많은 직장인은 상사에게 혼날 것이 두려워 자기 선에서 해결 하려다 시기를 놓쳐 문제가 더 심각해지는 경우가 발생하기도 합니다.

스스로 처리할 수 있는 업무실수일 경우 실수를 해결하고 상사에게 실수와 해결 과정을 보고하는 것도 좋겠지만, 도저히 스스로 해결할 수 없는 업무실수라면 시간이 지체되기 전에 상사에게 보고하는 것이 업무실수를 만회하는 가장 좋은 방법입니다.

상사는 그 자리에 오르기까지 많은 업무 경험을 가지고 있어 합리적인 방법으로 실수를 수습할 가능성이 크기 때문입니다. 다장에는 실수에 대한 꾸지람과 비난이 쏟아지더라도 큰 문제가 발생하는 것을 막고, 그것을 해결하기 위해 노력하는 모습이 오히려 전화위복이 될 수 있음을 알아두면 좋습니다.

실수 인정하고 사과하기

업무실수에 대한 책임이 자신이라는 것이 확인된 시점에서, 변명을 늘어놓거나 책임으 회피한다면 오히려 업무실수 이상으로 큰 부정적인 인상을 상사와 동료들에게 심어줄 수 있습니다. 또한, 자신의 실수에 대한 문제 해결을 상사와 동료들이 함께한다는 점, 그리고 그 시점에서는 다른 동료들도 업무실수에 대해 비난하기보다는 그것을 해결하는데 집중하는 분위기라는 점을 인식하고 그들에게 진심으로 사과하는 자세가 필요합니다.

실제로 직장인이라면 누구나 자신이 실수를 저지를 수 있다는 생각을 하고 있기 때문에 동료가 업무실수를 저지른다 하다러도 그것을 강하게 비난하는 경우는 거의 없다고 할 수 있습니다. 하지만 자신의 업무실수로 동료들에게 잘못을 했다는 부분은 명백하므로 진심을 담아 자신의 실수를 인정하고 용서를 구하는 태도 역시 현명하게 업무실수를 만회하는 법이라고 할 수 있습니다.

해결방법 제안하기

많은 직장인은 자신의 업무실수를 확인한 시점에 두려움을 느껴 상황을 회피하려고 합니다. 특히 상사의 꾸지람과 비난은 누구나 쉽게 예상하기 때문에 실수에 대해 업무보고를 하지 못하는 경우도 많습니다. 따라서 업무실수를 보고할 때 그 실수를 해결할 방법을 함께 제안하면 좋습니다.

이와 같은 대처방법은 비록 업무처리에서 실수가 있었으나 실수를 만회할 방법을 고민하였고, 그결과 가장 합당한 해결법을 제안한다는 모습을 자연스럽게 보여줄 수 있으며 이를 통해 상사의 꾸지람과 비난을 조금 잦아들게 만들 수 있습니다. 하지만 실수에 대한 잘못이 사라지는 것이 아니므로 상사의 꾸지람이 이어진다면 진정으로 반성하는 모습을 보여줄 수 있어야 합니다. 직장생활에서는 업무실수를 하지 않는 것도 중요하지만, 실수를 했을 때 그것을 어떻게 인정하고 어떻게 해결해나가는지도 중요한 능력 중 하나입니다.

실수에 대한 두려움 극복하기

업무실수가 잘 마무리되었다 하더라도, 사람에 따라 자신이 저지른 업무실수 때문에 자괴감을 느끼거나 또다시 실수할까봐 두려움을 느끼기기도 합니다. 실제로 자신으 ㅣ실수로 다수의 사람이 피해를 보는 것을 경험으로 확인했다면 더더욱 실수에 대한 두려움이 커질 수 밖에 없습니다. 똑같은 실수를 반복하지 않도록 발전할 수 있어야 합니다. 실수 만회하기란 특별하지 않습니다. 단지 자신의 실수를 인정하고 진심으로 사과하며 그것을 해결하기 위해 앞장서는 것 뿐입니다.

문제가 발생했을 떄 빠르게 행동하기

아직 일에 익숙치 않은 신입사원들은 실수가 발생했을 때 당황하기 마련입니다. 우왕좌왕 하고 있을 시간 없이, 이럴 때는 빠른 행동력이 중요합니다. 우선 오류의 원인을 파악하여 해결해야 합니다. 해결책까지 빠르게 나오는 건 아직 무리인 상황이라면, 상사에게 상황과 원인을 설명하는 등 적절한 대처가 필요합니다.

중요한 건, 문제를 해결하겠다고 마음 급하게 함부로 나서면 오히려 문제를 키울 수 있으니 머리는 차갑게, 침착하게, 이성적으로 판단할 필요가 있다는 것을 기억합니다.

입사가 끝이 아니라 3년, 5년, 10년 뒤 내 모습을 상상합니다.

입사를 한 순간 나는 가장 부족한 상태의 신입사원이 됩니다. 앞으로 내가 어떻게 하느냐에 따라 내가 걸을길이 꽃길이 될 수도 있고, 가시밭길이 될 수도 있습니다. 몇 년 후 미래의 나는 지금의 나와는 다르게 멋진 개발자로 성장할 수 있도록 지금부터 열심히 상상하고 계획합니다.

신입의 특권은 질문입니다.

여러 선배 개발자 분들이 신입은 모르는게 당연한 것이라고 합니다. 선배 개발자 분들에 비해서 실력으로나 경험으로나 부족할 수 밖에 없습니다. 부족하기 때문에 모를 수 있고 실수할 수 있습니다 그럴 때는 혼자 끙끙 앓으며 고민하지 말고 선배 개발자님들에게 적극적으로 질문합니다. 차라리 빠르게 질문하는 편이 업무 효율을 높일 수 있고 실력을 키울 수 있습니다.

도전을 두려워하지 않습니다.

신입은 배우기 좋은 위치입니다. 사고치거나 실수해도 용서받을 수 있는 신분이 신입사원입니다. 다양한 도전을 하며 다양한 상황을 만들어 내고 그 상황을 해결하면서 성장할 수 있습니다. 물론 선배 개발자 분들에게 혼날 수 있지만, 혼나면서 발전하는 것이 신입입니다. 나중에 할 실수를 미리 경험하고 나중에는 그 경험을 발판 삼아 실수하지 않습니다.

배우고 느낀 것들을 기록하고 내가 했던 것을 아카이빙합니다.

사람은 망각의 동물입니다. 당장 일주일 전에 내가 특별한 일을 하지 않았다면 어떤 일을 했는지 기억을 떠올려보기 어렵습니다. 하지만 그날의 일기를 쓴다면 내가 일주일 전에 한 일을 1년이 지나도 기억할 수 있습니다. 내가 보고 배운 것 또한 마찬가지입니다. 아무리 배운 것이 인상 깊고 중요한 것이라고 하더라도 기록을 하지 않으면 언제가 잊을 수 있습니다. 배우고 느낀 것들을 기록하고 이후에 찾아서 볼 수 있도록 열심히 기록합니다.

트렌드는 항상 변화하니 끊임없이 배웁니다.

개발자는 끊임없이 공부를 해야 하는 직업입니다. 그래서 고인물이 많이 없는 직업입니다. 다르게 말하면 공부하지 않으면 도태되는 직업입니다. 기술이 발전하는 속도는 생각보다 많이 빠릅니다.

개발자는 매번 새로운 기술이 나오면 그 기술을 익히려 공부를 해야합니다. 새로 나온 기술이 기존의 기술보다 좋기 때문입니다. 지금 현재의 기술에 만족하고 공부를 그만둔다면 당장 5년 후의 내가 할 수 있는 일은 매우 적어질 것 입니다.

시키는 일만 하지 말고 내가 어떤 일을 하는 사람인지 정의해봅니다.

신입사원은 시키는 일만 할 수 밖에 없을 것입니다. 해야 하는 직무에 대해 잘 모르기 때문입니다. 하지만 언제까지나 시키는 일만을 할 수는 없습니다. 시키는 일에 대한 의의를 생각해보고 내가 맡은 역할에 대해 고민해 보면 언젠가는 내가 해야하는 일을 알아서 찾을 수 있게 될 것입니다.

같이 일하고 싶은 사람이 됩니다.

인성은 좋지만 일을 잘 못하는 사람과 팀원하기 vs 일은 잘하지만 인성이 안좋은 사람과 팀원하기

이 두 설문조사에서 더 많은 사람들이 전자의 경우를 선택했습니다. 물론 일을 할 때 잘하는 사람이면 더 좋지만, 좋은 인성을 갖추고 있다는 전제가 필요합니다.

작은 일에도 감사하고 배려합니다. 그리고 겸손해집니다. 감사할 줄 아는 사람이 되는 것 입니다. 그리고 내가 받은 크고 작은 도움을 다른 사람에게도 배풀며 살도록 노력합니다.

직무에 갇히지 말고 분야에 관심을 가집니다.

지금은 프론트앤드 혹은 백엔드와 같은 직무에 대해 따지겠지만, 성장하려면 분야에 대한 흥미를 찾아야합니다. 리더는 분야의 전체 시스템을 이해해야 하고 좋은 아키텍처를 설계하는 능력이 필요합니다. 그렇게 하기 위해서는 프론트엔드, 백엔드 가리지 않고 무엇이든 알아야 하고 분야에 대한 이해가 필요합니다.

회사에서 일만 많이 하지 말고 다양한 추억을 만듭니다.

회사에서 근무하는 8시간은 정말 긴 시간입니다. 이 8시간 동안 열심히 일만 한 기억뿐이라면 회사는 정말 재미없는 곳이 될 수 있습니다. 가끔은 동료들과 함께 취미생활을 하거나 맛집을 찾아 맛있는 음식을 먹어봅니다. 이런저런 추억을 만들며 회사를 행복한 장소로 생각할 수 있게 합니다.

꼼꼼하게 일하는 법
  • 일을 하기전에 계획을 세우고 한다.
  • 일의 순서를 정한다. 앞의 일이 끝날때까지 다음으로 넘어가지 않는다.
  • 메모를한다. 한두시간 후 해야할 일이라면 잊어버리기 쉽다.
  • 제대로 했더라도, 조금이라도 미심쩍더라도 두세번 다시 확인한다.
  • 글과 수치를 끝까지 읽는다.
자신의 역량을 객관적으로 파악하기

업무를 통하여 직장이나 사회에 공한하기 위해, 혹은 자신의 성장을 위해 그때 그때 자신의 역량을 파악해 두는 것이 매우 중요합니다. 실력을 과신하면 헛수고할 가능성이 커지고, 과소평가하여 위축되면 새로운 도전을 할 수 없습니다.

  • 나는 나를 파악할 수 없습니다. 희망사항이 포함되어 있을 수 있고, 우연히 잘 되었을 수도 있습니다. 또는 잘 못한다고 생각했던 것이 실제 경험해 보면 의외로 잘 되는 경우도 있을 수 있습니다.
  • 주위의 사람들 안에 있는 자신을 관찰합니다. 타인에 대해서는 자기 자신보다 더 잘 파악할 수 있으므로, 주위 사람들의 자신에 대한 말투와 태도를 살펴보고 이를 받아들입니다. 가끔 이해할 수 없는 말투와 행동을 당하는 경우가 있습니다. 하지만 계속되는 지적에 위화감을 느낀다면, 나 자신에 대해 스스로 판단했던 것들이 틀렸을지도 모릅니다.
    • 나는 꼼꼼한 사람이라고 생각하지만 타인에게 사소한 실수를 계속 지적 받는다면 검토를 대강했다거나 검토 요점을 이해 못했을지 모릅니다.
    • 타인은 당신이 알지 못하는 당신의 성향도 알고 있을 수 있습니다.
  • 자신의 능력을 한정하지 않습니다. 잘 못한다고 생각했던 일도 막상 해보면 생각보다 잘하는 경우가 있습니다.
    • 잘 못한다고 생각하면 더욱 주의 깊게 일하므로 스피드는 떨어지지만 정확하게 일 처리를 하게 됩니다.
    • 잘한다고 생각했던 것도 사실은 좋아할 뿐 스킬이 부족한 경우도 있습니다.
    • 자신에게 맞고 맞지 않는 판단은 우선 도전해보고 나서도 충분합니다. 선입관에 사로잡히면 능력의 폭이 좁아지게 되는 경우도 있습니다.
  • 일을 잘하는 사람을 관찰합니다. 나 자신을 이해하고 능력을 높이고 싶다면 일을 잘하는 사람의 행동을 관찰합니다. 그리고 비슷한 일을 맡는 경우 비교해 봅니다. 그 사람의 어떤 점이 뛰어난지, 어떻게 했기 때문에 뛰어난지를 생각해보면 자신의 부족한 점을 알 수 있습니다.
벼락치기는 학교에서만

충분한 검토를 거치지 않고 급하게 처리하는 일은 반드시 크고 작은 실수와 문제를 남깁니다. 이는 개인뿐만 아니라 팀과 회사에도 타격을 줍니다. 개인 신상에도 치명적임은 두말할 필요 없습니다. 상사에게 게으른 문제아로 찍히는 것도, 안일한 사람으로 소문날 수도 있습니다.

촉박하게 주어진 일 때문에 갑자기 야근하거나 주말에 출근할 때도 있습니다. 이는 어쩔 수 없는 일반적인 경우입니다. 문제는 빨래 거리를 모으듯 한동안 일을 모았다 급하게 쳐내는 유형입니다. 시간에 쫒겨 급하게 처리한 일은 차근차근 절차를 밟으며 진행한 업무와 비교해볼 때 완성도가 떨어져 누구에게도 만족스럽지 못한 결과를 가져올 확률이 높습니다.

이런 식의 일 처리는 안일한 마음으로 일관하는 평소 습관에서 비롯되는 경우가 많습니다. 늘 약속 시간에 쫒겨 허둥지둥 나가는 사람이 있는가 하면 미리 도착해 여유 있게 상대를 기다리는 이들도 있습니다. 일도 마찬가지로, 모든 일이 그렇듯 늘 허둥지둥 마감 시간에 쫒겨 급하게 마무리되는 결과물에는 기대감도 신뢰도도 떨어질 수 밖에 없습니다.

좋은 계획과 실행은 어려운 만큼 성공할 확률이 높고, 기약 없이 미루는 일로는 결코 기대했던 결과나 의미 있는 성과를 이룰 수 없습니다. 상사가 누누이 강조하는 중요한 일을 자꾸 미루는 부하 직원을 상사는 결코 신뢰하지 않습니다. 두배로 생각하고 두 배로 노력하는 것이 가진 것 없는 사람이 성공하는 비결이라고 합니다. 이로서 상사가 안겨주는, 성장할 수 있는 기회를 절대 놓치지 않습니다.

  • 상사가 진척도를 물을 때,
  • 듣기 전에 수시로 중간 보고합니다.
  • 상사 취향에 맞춰 점수 따는 기회로 삼는다.

몸을 항상 건강하게

운동을 열심히

개발자는 앉아서 화면을 보는 시간이 정말 많습니다. 그로 인해 거북목, 허리디스크 등 다양한 척추질환이 생길 수 있습니다. 이를 방지하기 위해 운동을 해야 합니다. 운동을 해서 근육을 키우면 허리, 어깨 등 받혀주는 힘을 증가시켜 척추에 가해지는 무리를 줄일 수 있습니다.

허리를 펴고

잘못된 자세는 척추와 관절의 통증 및 질환의 주요원인이 된다고 합니다. 의자에 앉을 때는 등을 의자에 기대어 허리에 가중되는 부담을 의자에 나누어줍니다. 먼저 엉덩이를 의자 등받이에 닿을 정도로 깊숙하게 넣어 앉고, 허리는 등받이에 대고 꼿꼿하게 세웁니다. 이때 구부린 무릎의 각도는 90도를 유지하도록 하고, 무릎 높이는 엉덩이보다 약간 높게 합니다. 또한, 발바닥은 바닥 전체가 완전히 닿게 합니다. 의자 높이는 자신의 키에 맞게 조절해 앉도록 합니다.

프로그래밍에서

더 열심히보다는 더 현명하게

[ ] 훌륭한 프로그래머 되는 법 (Becoming a Better Programmer)

  • 문제를 해결할 때 하나의 방법에 몰입하는 것은 위험하다. 목표를 달성하기에 더 쉽고 직접적인 방법이 많습니다. 시간낭비할 필요 없습니다.
  • 생산적인 프로그래머가 되기 위해서는, 더 열심히 하기보다 더 현명하게 일하는 방법을 터득해야 합니다. 다음은 그 방법입니다.
    • 이미 라이브러리가 있거나 어딘가의 코드를 재할용 할 수 있다면 적극적으로 이요합니다. 또 다시 작업하는 것은 시간낭비입니다.
    • 다른 사람이 거들어줄 수 있거나 훨씬 잘할 수 있다면, 부탁하는 것이 좋습니다.
    • 해야만 하는것만 해야합니다. 프로토타이핑때 테스트 코드를 작성하거나 필요없는 코드에 리팩토링 하는 것은 시간낭비입니다.
    • 여러 설계 방안 가운데 어떤것을 선택해야 할지 모르겠을때는 최선책을 고르기위해 시간낭비 하지 않습니다. 일정 시간 타이머를 맞추고 해당 시간에 한가지 방법만을 고려해 봅니다.
    • 작업 목록의 우선순위를 정하고 가장 중요한 일부터 진행합니다.
    • 정말 필요한 일을 합니다. 목표가 자동차를 만드는 것이라면 소나타면 충분합니다. 롤스로이드를 만들려 노력하지 않습니다.
    • 작업은 한번에 하나씩만 수행합니다.
    • 코드는 작고 간결하게 유지합니다. 그래야 유지보수하기 편합니다.
    • 문제를 미루고 쌓아두지 않습니다. 문제가 작을때 해결해야 편합니다. 일이 눈덩이만큼 쌓일 경우에 처리하기 곤란해질 수 있습니다.
    • 자동화합니다. 자동화는 시간을 상당부분 절약해줍니다.
    • 의사소통합니다. 적절한 질문을 하는 방법을 배우는 것이 좋습니다.
    • 지쳐 나가떨어지지 않습니다. 번아웃 이후에는 다시 돌아오기 힙듭니다.
    • 강력한 도구를 찾습니다. 업무 흐름에 가속성을 더해줄 것입니다.

끝나야 끝나는 것

[ ] 훌륭한 프로그래머 되는 법 (Becoming a Better Programmer)

  • 일이 끝났다는 것을 알기 위해서는 완료 상태란 어떤 것인지, 그리고 완료 상태에 얼마나 가까운지를 현실적으로 파악하는 것입니다. 완료 상태를 모르면 필요 이상의 일을 진행하거나, 이를 완결 짓지 못하고 나중에 다시 일을 해야 하는 경우가 생깁니다. 완료 상태가 무엇인지 아는것이 무엇보다 중요합니다.
  • Step1 분해하기
    • 완료 상태를 정의하기 위한 첫 번째 단계는 작업 내용을 정확히 파악하는 것입니다. 크고 복잡한 업무를 맡았다면 일을 시작하기 전에 더 작고 이해할 만한 부분으로 일을 나눕니다. 이는 더 정확하게 진행 상황을 판단할 수 있습니다.
    • 분해 작업이 어렵다 하더라도 이를 미루면 안됩니다. 초기에 분해 작업을 수행하지 않으면 막바지에 이른 상황에서 집중하지 못한 상태로 수행하게 될 것입니다.
  • Step2 완료 정의하기
    • 완료 상태를 정의해야 합니다. 즉 성공 상태가, 완결된 소프트웨어가 어떤 모습인지를 알아야 합니다. 그래야 작업을 더 많이 하거나, 덜하는 경우를 없앨 수 있습니다.
    • 무엇이 성공인지 파악하기 전까지는 코딩 작업을 시작해서는 안됩니다. 모르겠다면 완료 상태가 무엇인지 정의하는 것이 첫번째 업무입니다.
    • 코딩 작성이 완료 되었다면 작동함을 증명하기 위해서 테스트 코드를 꼭 작성합니다. 이는 일이 정상적으로 끝났음을 증명하는 것 입니다.
  • Step3 그냥 실행하라
    • 완료 지점까지만 작업합니다. 필요한 것보다 많을 일을 하지 않습니다.
    • 코드가 충분하다면 그만 멈춥니다. 코드가 완벽하지 않아도 좋습니다. 코드가 잘못된 방향으로 되었더라면 결국에는 리팩토링을 할 수 있습니다. 미리 하는 것은 노력낭비일 수 있습니다.

교훈 얻기

[ ] 훌륭한 프로그래머 되는 법 (Becoming a Better Programmer)

  • 개발자는 혼자가 아닙니다. 주변의 동료 및 개발자를 충분히 이용합니다.
  • 자신을 감시합니다. 자신의 코딩이 잘못되는 것을 항상 살펴보고 조심해야 합니다. 이를 위해 동료를 이용해야 합니다. 자신이 누군가에게 의무감을 갖도록 합니다.
  • 산을 올라가기 전 우선 한 발짝 물러서서 경로를 계획해야 합니다. 마찬가지로 작업을 진행하기 전에 경로를 계획해야 합니다. 문제에 접근해본 첫 번째 길이 가장 최선의 방법일 경우는 드뭅니다. 적어도 한가지 이상의 접근법을 고려해 본 뒤 일에 착수합니다.

코드작성이란

변수의 활용

Variable

변수는 관련 기호 일므과 쌍을 이루는 추상적인 저장 위치, 간단하게 값을 담아두는 공간입니다. 이 변수는 지역변수, 전역변수, 매개변수 또는 맴버 변수, 클래스 변수일 수도 있습니다. 혹은 외부변수일 수도 있습니다.

  • 메모리등의 자원관리, 다른 변수와의 충돌을 고려하여 생각해야 합니다.
  • 사용하는 영역을 고려하여 지역변수인지 전역변수인지 정해야 합니다.
  • 해당하는 값의 특성에 맞게 변수의 범위를 정할 수 있습니다.
graph LR Variable--지정된 영역에서만 사용할 수 있는-->LocalVariable Variable--모든 영역에서 사용할 수 있는-->GlobalVariable LocalVariable--함수내에서 정적으로 할당된다면-->StaticVariable GlobalVariable--다른 모듈에서 사용할 수 있는-->StaticVariable LocalVariable--함수를 호출될 때 전달되는-->Parameter Variable--클래스에서 멤버 필드에 있는-->MemberVariable MemberVariable--개별 인스턴스로 존재하면-->InstanceVariable MemberVariable--모든 인스턴스에서 공유하면-->ClassVariable
Scope Describe
Local 지역변수는 일정한 또는 지정된 지역에서만 사용할 수 있는 특정한 변수를 의미합니다.
지역 변수는 변수가 선언된 블록 내에서만 유효하며, 블록이 종료되면 메모리에서 사라집니다.
Global 전역변수는 함수의 외부에서 선언된 모든 영역에서 사용할 수 있는 변수를 말합니다.
전역변수는 프로그램의 어디에서나 접근할 수 있으며, 프로그램이 종료되어야만 메모리에서 사라집니다.
Parameter 매개변수는 결과값을 얻기 위해 입력값으로 주어지는 변수로 지역변수입니다.
Static 정적으로 할당되는 변수이며, 프로그래밍 실행 전반에 걸쳐 변수의 수명이 유지됩니다.
C언어에서 정적 변수란 static 키워드로 선언한 변수를 의미합니다.
Scope Describe
Member 멤버 변수 또는 멤버 필드는 특정 객체와 연결된 변수의 하나입니다.
해당 변수의 모든 메소드에서 접근이 가능합니다.
Instance 각각의 인스턴스화된 클래스의 객체가 별도의 사본이나 인스턴스를 가지고 있는 변수입니다.
Class 클래스의 인스턴스가 얼마나 많이 존재하는지에 관계 없이, 하나의 사본이 존재하는 클래스에 정의된 변수입니다.

경험을 기록

의존성 전파를 항상 조심하자

하나의 변경사항에 대해 여러개를 고쳐야 한다면 이는 의존성을 관리하지 못한 것 입니다. 많은 변경은 충돌과 시간 낭비를 가져오므로, 가능한 단순하게 하는 것이 좋습니다.

  • 싱글톤의 의존성이 복잡해지는 문제, SVN을 이용하고, 코드 머지가 안될 떄, 싱글톤을 이용해 작성하면, 두 개발자가 새로운 변경사항에 대해 싱글톤 클래스를 변경했을 때, 커밋시 해당 싱글톤 클래스가 충돌하게 됩니다.
A를 B비스무리하게 설명해 B를 만들었다면, B는 쓸모없는 것이다. A를 만들어 줘야 한다.

다음과 같은 상황을 가정해봅니다.

  1. 기획서 대로 했습니다.
  2. 사수는 기획서가 맞다고 했습니다.
  3. 이사님은 이상하다고 했다.

완성된 프로그램을 사용할 사람은 일반인입니다. 따라서 일반인의 관점이 중요합니다. 이때 잘못되었다고 하는 이유를 파악해야합니다.

기획서에 의한 프로그램이 잘못된건지, 기안서가 잘못된건지를 명확히 파악해야합니다. 기획서가 이상하다고 하는 부분이 짚어졌다면, 회사의 니즈를 파악해 니즈에 맞춰서 만들어야합니다.

대답하기

부정확할 때는 바로 대답하지 말고, 정리된 다음에 대답하도록 합니다.

시간관리

  • 선검색의 중요성

이론 공부후 아는걸 쓰도록 하자. 시간낭비다. 엄청난 삽질이다.

안정적으로 시간안에 만드는 것은 계획의 5배를 잡도록 하자. 그래야 공부도 할 수 있다.

글로 명확하게 적어서 해야하지만, 결과를 보면서도 만들어야 하기 때문에, 적절한 균형이 중요하다. 코드에서 버그를 찾을려 하니 못찾는건가?.. 맞는거 같네.

협헙하기

  • 협업시, 의도가 파악되지 않을 때는 수정하지 않습니다. 또한 의도가 파악되더라도 물어본 후 수정합니다.
  • 중간에 들어간 프로젝트의 경우, 함부로 수정하지 않고 확실하게 파악 후 물어본 다음에 수정합니다.

프로젝트를 진행할 때

검증이 확실하지 않으면

검증이 확실하지 않으면 연결된 다른 모든것들이 불확실해져, 처음부터 다시 검증해야 되는 상황이 올 수 있습니다. 이를 최소화 하기위해, 한개씩 확실하게, 그리고 나눠서 테스트할 수 있는 환경을 갖춰야 합니다.

수식까지 확실하게

수식이 들어가는 코드를 만들 때, 수식을 확실하게 하지 않고 막연하게 접근하면 수식을 지웠다 다시 적는 반복을 많이하게 됩니다. 수식에서 막히는 것이 아니라면, 수식을 작성하고 이를 보고 작성하는 방식으로 만들어야합니다.