[ETC] 코딩을 잘하는 사람들의 특징

세상에는 코딩을 잘하는 사람들이 참 많다. 그중에서는 얼마 배우지도 않았는데 이해력이 남들보다 훨씬 빠른 사람들, 흔히들 코딩에 재능이 있다고 하는 사람들도 있다. 나는 코딩을 잘하는 사람들을 열심히 관찰하고 따라 해보려 노력하고 있다. 오늘은 내가 지금까지 그들을 관찰하며 느꼈던 코딩을 잘하는 방법에 대해 이야기해보려 한다.

 

개발자

 

혼자서 해결하는 능력

프로그래밍이란 끊임없이 오류와 마주치고 그 오류를 해결하는 과정의 연속이다. 이 오류들을 혼자서 해결할 수 있느냐 없느냐에서 실력이 갈린다. 가끔 『모르면 물어봐야지』라는 생각을 가진 개발자들이 있다. 나는 이 생각에는 동의하지 않는다. 이러한 생각은 사람을 의존적으로 만들어 문제를 스스로 해결할 수 있는 능력의 발전을 막기 때문이다. 영화를 제대로 보려면 중간중간 스킵 하지 않고 처음부터 끝까지 다 보아야 한다. 중간중간 내용이 영화의 결말을 이해하는데 중요한 단서가 되기 때문이다. 코딩도 그렇다. 중간중간 문제 해결을 위해 여러 가지 방법을 시도하는 것 자체가 자신의 실력의 밑거름이 된다. 또 기어코 그 문제를 해결했을 때 얻는 깨달음도 더욱 크고 기억에도 오래 남는다. 문제 해결을 위한 여러 가지 시도 없이 능력 있는 사람들에게 도움부터 받는다면 영화를 처음부터 보지 않고 결말만 보는 것과 같다. 이렇게 되면 왜 이런 현상이 발생되었고 어떻게 해결했는지 잘 설명을 해준다 한들 와닿지도 않을뿐더러 설명을 들어도 제대로 이해하지 못한다. 결국에는 또 다른 문제가 생겼을 때 또다시 도움을 요청해야 하는 악순환에 빠지게 된다. 의존적인 사람은 결코 좋은 개발자가 될 수 없다.

 

스스로 하는 습관

코딩에 재능이 있는 사람들은 뭐든지 스스로 해결하려고 노력하는 습관을 가진 사람들이다. 그들은 일상에서마저 스스로 하는 습관을 가지고 있다. 그것이 어떤 것이든, 사소한 것 하나라도 혼자서 문제 해결을 위해 탐구한다. 컴퓨터가 고장 나더라도 AS 센터에 맡기기보다는 혼자 고쳐보려고 애를 쓴다. 이렇게 스스로 하는 습관이 쌓여 뭐든지 잘하는 사람을 만든다. 스스로 하는 습관을 가진 사람들은 뭐든지 빨리 배운다. 빨리 배운다는 것은 개발자의 역량을 판별하는데 매우 중요한 요소이다.

 

빨리 배우는 능력

하루하루 다이내믹하게 바뀌는 IT업계에서 빨리 배운다는 것은 매우 큰 의미가 있다. 기업에서도 점점 잘하는 사람보다 빨리 배울 수 있는 사람을 선호하는 추세이다. 최근 취업시장에서 알고리즘 능력이 중요도가 높아지는 이유가 여기에 있다. 종종 여기저기 움직이며 신기술을 배우는 개발자들이 있다. 마치 그 신기술을 알아야만 더 좋은 개발자가 될 것이라 생각한다. 하지만 나는 이것이 비효율적인 공부 방법이라고 생각한다. 하루하루 수많은 신기술이 쏟아져 나오는 IT 업계에서 그 신기술 중에 훗날 어떤 것이 살아남을지 알 수 없으며 사람은 망각의 동물이라 신기술을 배웠다 한들 써먹을 곳이 없으면 빠르게 머릿속에서 잊어버리게 되기 때문이다. 우리는 신기술이 필요로 할 때 필요한 것만 빠르게 습득할 수 있는 빨리 배우는 사람이 되어야 한다.

 

많이 해보는 것

코딩은 학문이 아니라 기술이다. 학문은 책으로 공부하는 것이지만 기술은 직접 해보고 배워야 한다. 코딩을 수영에 비유할 수 있을 것 같다. 수영은 책으로만 배워서는 결코 실력이 늘 수 없다. 수영장에 가서 팔도 저어보고 다리도 저어보고 해야 실력이는다. 코딩도 마찬가지다. 코딩 실력을 늘리고 싶다면 코드를 계속 짜봐야 한다. 수영실력이 물에 뜨는 원리를 깨닫는 순간 실력이 급격히 느는 것처럼 코딩도 특정 원리만 깨닫게 되면 실력이 부쩍는다. 코딩을 잘하려면 많이 해보아야 한다.

 

경험이 많은 사람

코딩을 많이 하면 경험이 쌓인다. 직장인이 되고 가장 밑에서 선배들을 보는 순간 확실히 느낀다. 경력이 올라갈수록 실력도 정비례한다는 것을 말이다. 개발자에 있어 경험은 매우 중요하다. 나 역시 누군가 나에게 이 기능이 되는지, 이 방법이 되는지 물어볼 때면 내 경험에 기인하여 대답한다. 내가 해본 적이 있다면 그것은 되는 것이고 아니라면 확신 없는 대답을 할 수밖에 없다. 경험이 많이 쌓이다보면 이 기능을 추가하는데 몇시간, 몇일이라는 추상적인 소요시간도 대충 알 수 있게 된다. 이렇듯 경험은 판단의 확실한 근거가 된다. 우리는 다양한 경험을 해보아야 한다. 개발자들의 이직이 필요한 이유도 여기에 있다. 다양한 경험이 필요한 개발자의 인생에 있어 이직이란 새로운 경험을 해볼 수 있는 기회가 될 수 있기 때문이다. 새로운 경험을 할 기회가 있다면 어릴수록 좋다. 우리의 두뇌도 나이를 먹는다. 어릴 적 배우는 영어와 지금 배우는 영어의 배우는 속도가 차이나듯 나이 든 사람이 새로운 경험을 하는 것과 젊은 사람이 새로운 경험을 하는 것은 배움의 효율이 다르기 때문이다.

댓글(28)

  • 2019.12.31 06:53 신고

    코딩은 학문이 아니라 기술이다. 실제로 행동해 봐야 알 수 있다는 말이군요!! 컴맹 탈출, 기계치 탈출하는 한해가 되어야 하는데....도움 받고 갑니다.^^

  • 2019.12.31 11:43 신고

    앞으로도 열심히 코딩공부 해야겠어요~

  • 2019.12.31 13:27 신고

    좋은 말씀이네요! 더 열심히 습관을 길러야겠어요 :)

    • 2019.12.31 13:59 신고

      좋은 습관을 가지고 있으면 평소에도 계속 발전하고 있는거와 마찬가지니까요. 습관이 정말 중요한것 같아요.

  • 의견1
    2019.12.31 13:32

    좋은 글들은 많은데...
    제일 중요한건 주석좀 잘 달아라
    주석은 자신이 참고해야 할때 필요할 수 있지만
    다음 개발자에 대한 의사소통 중 하나이다

    지식은 아끼는 만큼 한계가 되고 베푸는 만큼 더한 지식으로 남는다

    • ㅇㅇ
      2020.02.06 14:35

      처음 학부생때만 해도 주석을 잘 달라고 들어왔는데 무조건 주석다는게 답은 아니더군요.
      잘 작성한 코드는 굳이 주석이 필요없이 이름이나 순서만으로도 잘 읽히고 잘 이해가 되도록 작성되어 있을 수 있고, 오히려 주석이 나중에 레거시 코드에서 수정을 방해하는 요소로 남아있는 경우가 많더군요(의미 불명, 주석과 메서드 매칭안됨 등)
      정말 '잘' 달것이 아니면 주석은 안 달도록 코드를 짜는 것도 좋다고 생각합니다.

  • 1001
    2019.12.31 14:56

    저는 덧붙여서 단순히 구현에 목적을 두는 것이 아닌 보다 저렴하고 효율적인 방식으로 구현하려고 노력하는 것도 중요하다고 봅니다. 프로그램의 질적 향상은 물론, 본인의 능력 향상에도 아주 도움이 됩니다. 단지 러닝커브가 있을뿐 습득 후 속도 향상은 당연한 것이죠.

  • 20년차..
    2019.12.31 16:33

    1번과 2번은.. 성장할 시간을 주지않고 성과만 바라는 현재 개발환경에서 불가능하네요..
    수많은 시행착오를 격어야만 하는 방법인데 초,중급.. 심지어 고급개발자들에게도 해당하는 사항인데도 아웃풋이 느리면 손 느리다고 구박하죠.
    어느 회사나 경력자에 완성형만을 원하기에 5~6년차가 될때까지는 주말과 휴식이 없는 인간을 포기하고 공부해야만 가능한데.. 막상 베껴서 개발한 결과물과 아름답고 고오급스러운 작품을 구별하고 알아줄 능력자도 별로 없다는게 현실.. 이지요.

  • 2019.12.31 18:49 신고

    피드에 새로운 글이 올라와서 왔는데 좋은 글을 남겨 주셨네요.(^_^)
    저도 작업하면서 모르는건
    코딩팩토리님의 블로그에서 많은 도움을 받았습니다. 정말 감사합니다.
    2020년에도 잘부탁드립니다~

    • 2020.01.02 10:13 신고

      감사합니다. 도움이 되었다니 다행입니다. 2020년에도 열심히 한번 해볼게요!

  • 감사합니다
    2019.12.31 21:01

    모바일 개발 부분 주니어 개발자입니다. 좋은말씀 감사합니다. 공감되는 내용들이 많네요

  • 10년차
    2020.01.01 09:37

    이제 10년차밖에 되지 않았지만....
    스스로하는게 중요하긴 하지만 배울수 있으면 배우는 것이 좋겠지요. 시간을 절약한다면 다른 곳에 더 투자를 할 수 있으니.. 너무 의존적이 것도 좋지 않지만 너무 혼자하려는 것도 좋지 않습니다. 시야가 좁아집니다.

    • 2020.01.02 10:10 신고

      네 일적인 부분에서 보면 너무 혼자하는것도 좋지 않은것 같아요 회사는 공부하는곳이 아니라 결과물을 만들어 내는 곳이니까요

  • 2020.01.01 11:33 신고

    잔잔한 글 공감하고 갑니다^^

  • 선냉이
    2020.01.01 12:59

    같이 일하다 보면 문제 하나를 가지고 오랜 시간을 보내는 개발자가 있는데, 어느 피엠님이 말했던 기억이 나네요. 20~30분 고민해도 안되는 것은 안되는 것이다. 그럴땐 주위에 도움을 요청하라고 하시더라구요. 문제해결 능력 배양도 좋지만 또한 생산성의 문제이기도 합니다. 결국 스킬 향상과 아웃풋간의 균형 감각이 중요하다고 생각되네요

  • 파이팅야
    2020.01.01 16:47

    매일 스크럼시 고민꺼리를 애기하고 서로 도움 받은적이 있는데 이게 아주 좋았죠. 개발/설계/코딩/테스트/배포 등등 이슈사항 나올곳은 많고 매일 나올수 있죠

  • 2020.01.02 13:00 신고

    다시한번 제 자신을 되돌아보게 되는 글이네요.
    좋은글 감사합니다.

  • 익명
    2020.01.02 23:33

    비밀댓글입니다

  • 유나
    2020.03.29 22:18

    좋은 글이네요 ㅎ 하지만 혼자서 하는 것도 좋지만, 또한 뛰어난 사람 옆에서 보고 배우는 것도 좋은것 같아요. 솔직히 말하면 구글링, 책찾아 보기, 레퍼런스 찾아보기 등등 혼자서 하는 것처럼 보이지만 그 문제에 대한 전문가나 내가 겪은 문제를 앞서서 겪은 사람들이 남긴 도움의 손길을 받는 경우가 많으니까요.

  • 카우치코딩
    2020.08.28 02:32

    현업 개발자들이 1:1 멘토링해주는 서비스도 있어요! 참고하세요 🙂
    https://couchcoding.kr

  • 나그네1
    2020.09.03 08:38

    자료 찾던 중 좋은 글을 보고 흔적남기고 갑니다 ^^
    제가 후배들에게 항상 이야기 해주는 내용이 추가 되면 더 좋겠단 생각에 남겨봅니다.

    "프로그램을 만들기 전에 사용자가 되어라."

    아무리 다양한 기능과 퍼포먼스를 자랑하는 프로그램도 사용자가 불편하면 무용지물이라고 생각하기에
    후배들에게 오더를 주기전엔 항상 현업에 보내서 관련 업무를 배우고 가능하다면
    직접 체험(예를들면 기존 수기 작성이었다면 무엇을 어떻게 써야 하는지와 같은)까지 해보고 오라고 한 후에 오더를 줍니다.

    제가 열심히 개발 의도와 방향과 목표를 설명해도 결국 결과물은 제가 생각하던거와 다르던 후배도
    업무를 배우고 난 뒤 제 설명을 사용자의 입장에서 듣고, 개발자의 입장에서 듣고 난 결과물은 아주 만족스러웠습니다.

    쓸데없이 글이 길어졌네요.
    그럼 슬기로운 회사생활들 하시길 ^^

  • 10년차
    2020.11.06 03:06

    많은 부분 공감이 가는 글입니다. 잘 읽었습니다.

  • linux함수싫어
    2021.01.28 15:45

    제 기준 코딩잘알 : 주석 꼬박꼬박 잘 쓰는 사람, 반복적인 코딩은 거의 항상 반복문으로 묶어서 불필요한 라인 줄이고 코딩 정리 잘되어있는 사람, 자신이 업무한 내용 정리노트에다가 적어서 보관하는사람, 변수 이름 체계적으로 잘 붙이는 사람.
    코딩 잘하는사람도 제목 센스가 있어야 똑똑하다고 생각이 듬 확실히 사람이 달라보임

  • 참고
    2021.12.28 02:34

    나무를 보지말고 숲을 보길 바랍니다. 사실 숲속에서 숲을 본다는 것은 말이 안되고... 나무를 보고 숲을 이해?할수 있어야 하겠지요. 코딩이 목적이 아니라 무엇을 할것인가가 중요하고, 무엇을 위한 것인가가 더 중요하고, ... 더 중요한것은 결국 이러한 것들이 나와 가족을 위한 것인가? 생각해봐야할듯... 짧은 인생입니다. 시간배분 잘하시길...

Designed by JB FACTORY