Tech-HR 2017 Conference

Successful Software Engineer(박종천)

HR System

Attract > Develop > Engage
  • Hiring : 채용
  • Performance Reviews : 평가
  • Titles (Engineering) : 직책(능력에 따른)
  • Rewards : 보상
  • Education : 교육
  • Benefits : 복지 (복지와 보상을 구분해야 한다)

Hiring

  • Resume, Cover Letter Review
  • Coding Test(Foundation Knowledge)
  • Engineering Interview(Skill Set)
  • Team Interview (Culture Fit)
    • Be Honest
    • Two-way communication
면접에서,
싫어하는 사람을 만들지 않고, 나를 좋아하는 사람을 만들어라.
  • Smart(Fast to Learn) : 빨리 배울 수 있는 만큼 똑똑한가
  • Diligent : 부지런한가
  • Good Will : 착한가

Titles

  • Assistant - Newbie
  • Association - Do assigned work
  • Mid level - Find and do work
  • Senior - Make a work for others
  • Lead - Superior knowledge or performance : 모르는 일을 해결할 수 있는 능력
  • Principal - Lead many projects together : 본인이 하지 않은 일에도 책임을 지는 능력

Education

skip

Performacne Reivew

  • Example: Software Engineer
    • Productivity
    • Professionalism (Reliability)
    • Teamwork (Communication)
    • Knowledge
    • Funcitonality (No Defect)
    • Implementaion (Good Code)
    • Design & Archtecture

리뷰를 통해 골고루 성장가능 하게 해준다.

삼인행 필유아사

One-on-One(1:1 면담)

  • Performance
  • Growth : 성장을 하는지, 공부하는 속도가 세상의 속도보다 느리면 위험하다.
  • Happniess

Growth

  • Individual Development Plan
    • Short-Term Goals
    • Development Goals
    • Planned Development Activities
    • Resource Needs
    • Manage Supoort Activities
  • Qesution : 10 years later -> 5 years (3 years에 한번씩은 점검해야 한다)
    • 10년후에도 회사가 있을 것 같은가?
    • 10년후에도 이 회사를 다닐 것인가?
    • 지금 쓰는 기술이 10년후에도 지금 기술을 사용할 것인가?

Development Rules

  • Potential vs. Capacity
    • Hit 80% of capacity steadily to increase potential.
    • 한계 이상의 일을 할 때 실패를 하고, 성장을 한다.
  • Fail early, fail often
  • Ownership vs. Expert
  • Father’s Lesson #1
    • 쉬운 일을 하면 끝이 없다.
    • 할수있는한 어려운 일을 선택하라.

Happiness

  • 일을 좋아하는가? 즐거운가?
  • 배움이 있는가?
  • 내가 하는 일이 비전에 관련있는가?

Engineer

  • Software Enginner
  • System Engineer
  • Database Engineer
  • Cloud Engineer

All Software Engineers

  • STEM
    • Science, Technology, Engineering and Mathematics
  • Required for all Industries
  • Top 10 Jobs in America

What ro Learn

  • Foundation

Ciritical Thinking

  • Why? Deep thinking?

Talent, Practice, Chance - 어떤 일을 잘하기 위해선

  • Write same program many times
  • Make it working, Make it right, Make it fast
  • Success without Capacity, Failure without Capacity
  • Capacity = Knowledge + Skill + Experience
  • Father’s Lession #2
    • 밤새서 공부해서 1등하면, 계속 밤새서 공부할 것 인가?
    • 꾸준히 끊기 있게 할 것인가?

Software Development

  • 개발자가 갖춰야할 9가지 기술

End

  • 배우고 성장하는 사람이 되라

주니어 개발자와 시니어 개발자의 차이(김범준)

Senior

  • 경험이 많은 개발자?
  • 10년 이상 경험을 가진 개발자 (X)
    • 1년의 경험을 10번 반복한 개발자
    • 단순히 연차가 많은 경험을 가진 개발자는 아니다.
  • 10년 동안 다양한 경험을 통해 성장한 개발자 (O)

1만 시간의 법칙?

  • 의도적 수련이 필요(Deliberate Practice)
    1. 학습을 하기 위한 목적
      • 일을 하기 위해서 코드를 짜는건 학습인가?
      • 온전히 학습하는 시간은 얼마나 되는가?
      • 코드리뷰를 하는 건 좋은 경우다.(온전히 학습을 하게 해준다, 비판적 사고)
    2. 적절한 피드백
      • 어떤 것?
      • 누가?
      • 누군가에게 피드백을 받을 수 있는 존재가 필요하다.
  • 스스로의 도전과제를 만들어라.(스스로 단련하라)
  • 스스로에게 패널티를 주어라.(스스로의 능력을 제약시키고, 원래의 퍼포먼스를 낼 수 있도록)

Senior

  • 실력이 뛰어난 개발자?
    • 실력이란? -> 일이 되게끔하는 사람

Junior

  • 시킨 일을 수행할 수 있는 사람
  Junior Senior
일의 단위 Tasks Project
기대 결과물 코드, 문서 등 실질적 성과
관리 일정 일정 + Risk
(언제 문제가 발생했었는지, 다양한 경험)

우아한형제들 기술조직

  • 코드 덩어리가 아닌 가치를 만들고 스스로의 가치를 높이며 일한다.
긍정적인 사람은 한계가 없고,
부정적인 사람은 한 게 없다.
-박용후

Senior

  • 일 잘하는 사람?
    • 시니어의 일이란? -> 개인 팀의 일과 성과

Junior

  • 자기가 한 일이 성과

Senior

  • 자신의 경험을 나눠줄 수 있고, 그를 통해 동료들을 변화시킬 수 있으며, 변화가 성과로 이어지게끔 하는 사람.

Senior

  1. 의도적 수련을 통한 발전에 익숙하고,
  2. 코드가 아닌 가치를 만들낼 수 있으며,
  3. 동료를 변화시키고 성과로 이어지게 함.

Q & A

회사 차원에서의 지원

  • Pair programming
  • Module shift
  • Freely editing code

이직

  • 현재가 싫어서 이직 하는 것은 좋지 않다. (이직을 위한 이직)
  • 밖에서 끌어당기는 요구와 맞는 이직이 바람직하다.

스타트업에서의 HR과 스타트업 조직문화론(안민호)

영문호칭 vs. 한글호칭

  • 수평문화에 대한 고민
  • 단순한 수평문화만을 위한 것을 아니다.
    • Communication
    • 빠른 의사 결정(Speed)
  • 영문호칭 -> 빠른 의사 결정

구성원의 오너십

  • 지분(현실적의로 힘듬)
  • 인센티브
  • 휴가제도
  • 스톡옵션
  • 중심가치 일치 -> 이게 갖추어져야 앞에 것들이 의미가 있다.

아름다운 이별의 방법

  • 아름다운 이별은 없다.
  • 채용 절차는 까다뤄야 한다.(구글, 제니퍼 소프트)

왜 창업하려고 하나요?

  • IDEA만 가지고 창업을 하면 실패한다.
  • 열심히 준비해야만 한다.
  • 빠르게 실패해야 한다.

대기업 vs. 스타트업

  • 대기업에서는 작은 부분을 깊게 할 수 있다.
  • 스타트업에서는 많은 부분을 하게된다.

CEO, CTO

  • 21세기 핵심 역량(문제 해결력, 유연성 및 적응성, 창의 및 혁신 능력)
  • 변화와 다양성에 유연해져야 한다.

왜 우리는 개발자에 집중하지 않는가?(이민석)

  • 소프트웨어 물들다.
  • 모든 회사는 [무엇인가]를 가장한 소프트웨어 회사
  • 소프트웨어는 업의 생산성이 아니라 업의 가치 그 자체
    • 도구 > 본질로의 변화

정작 개발자들은 어디에 집중할까?

  • 새로운 기술
  • 제품에 대한 결정권
  • 회사의 방향성
  • 현재 서비스의 개선
  • 다양한 프로젝트의 수행
  • 리모트 워크
  • 승진
  • 나만의 작업 공간
  • 정시 퇴근(미국은 대부분 정시퇴근이라 우선순위가 낮다.)

이직을 할 때 가장 중요한 것은?

  • 연봉
  • 일과 생활의 균형
  • 기업 문화(의사 결정 - Speed)
  • 훌륭한 동료
  • 회사에 중요한 일
  • 유연 근무
  • 기술 스택
  • 재택 근무
  • 회사 위치

주당, 업무 이외의 코딩 시간

  • 1~2 시간
  • 2~5 시간
  • 5~10 시간

지금도 이직을 생각하나?

  • 찾고있지는 않지만, 기회가 오면(60%)
  • 지금이 좋은(25%)
  • 이미 구직 활동 중(14%)

개발자에게 집중한다 함은

  • 연봉
  • 이직
  • 개인 프로젝트
  • 핵심 기술
  • 학습욕구
  • 개인 삶
  • 훌륭한 동료

개발자에게 집중은 회사가 해야한다.

  • 스프트웨어 회사는 현실은 위기
  • 개발자 당신들 잘못이 아니다.
  • Good Design > Scrum > Pair Programming > QA
  • 한풀이…
  • 개발자들이 떠나고 싶어하는…

Human Resource

  • 회식 하나로 모든 불만이 사라질 것이라고 생각한다.
  • 개발자를 관리의 대상으로 본다.
  • 개고생하고 회식 한번으로 해결된다고 생각한다.
  • 스타트업에는 그런 문화가 없다. HR이 없기 떄문이다.

HR은 마치 미스코리아 같다.

  • 엄청난 스크리닝을 통해 뽑는다.
  • 계속 있을 수 있는 환경을 주지 않는다.
  • 등급을 매긴다.
  • 상호 평가
  • 경쟁은 고래도 죽게한다.

HR의 역할

  • 개발자를 케어하고 위하는 조직이여야한다.

개발자 우리는,

  • 최고의 퍼포먼스를 내려면,
  • 퇴근하려고 할 때, 마음이 편해야 합니다.
    • 회사 일 잊고, 다른 것에 몰입할 수 있기 때문에,
  • 가끔은 노는 날에도 출근하고 싶어야 합니다.
    • 워낙 애인도 없지만,
    • 회사보다 재미있는 곳이 없기 때문에
  • 회사를 떠나기 싫어야 합니다.

언제부터 HR이 필요할까?

  • 1994 : 65
  • 1999 : 27
  • 2015 : 10~15
  • 2020 : ??

현재의 HR은?

  • 뽑는 일만,
  • 짜르는 일만 하고 있다.
  • 개발자에 집중하는 훈련을 받은 적이 없다.
  • 사장님이 하실 일은 누구를 실망시켜야할 지를 결정하는 일
  • CTO는 개발자를 어디에 집중시켜야 할지 결정해야한다.
  • 개발자는 개발에 집중해야한다.(HR이 하는 일을 나누어 받지 않아야 한다.)
  • 개발자에 대한 집중은 나머지들이 해야한다.

개발자 공부론(김창준)

  • 실력이란건 가만히 놔둔다고 느는 것이 아니다.
  • 학습방법은 방법마다 효과가 다르다.
  • 소프트웨어 개발은 야생학습이 필요하다.
    • 학교를 벗어났습에도 불구하고 학교에서 했던 방법을 추구한다.(학교학습)
      • 학습방법을 제한한다.
      • 학습 효율이 좋다. 단,
      • 불확실성이 높은 경우는 해당 방식이 통하지 않는다.
      • 파이썬 책을 공부하는 것과 파이썬을 학습하는 것은 동일하지 않다.
    • 마치 오디오를 사용할 때는 매뉴얼을 다 읽고 사용하지 않는다.
    • 하지만 공부할때는 야생학습을 사용하지 았고 학교학습처럼 한다.
      • 학교학습은 잘라서 공부한다.(분절학습)
      • 실제로는 융합해서 사용한다.
  • 야생학습은 어떻게 해야하는가?
    • 처음부터 의미있는 프로그램을 만들어야 한다.
    • 업무환경(실무)과 비슷한 프로그램을 수정하는 것도 좋다.
    • 교과서는 보조적으로 사용해야한다.
      • 교육학적으로 잘 설명된 책이 없다.
    • 실수를 만들어서 하는 것이 좋다. 실수는 좋다.
    • 학습의 주도자가 되어야 한다.
    • 공부 != 책 읽기
      • 공부 == 책 읽기는 편협한 학교스러운 생각
    • 만들고 싶은 프로그램에 맞추어 공부 순서를 정한다.(책 순서가 아니라)
    • 피드백이 필요하다.(자유투를 가리고 던지면 의미 없다.)
    • 무엇에 대해 피드백을 받는게 좋은 것인가가 중요하다.
    • 야생의 특징은 정답은 없다.

패널 토의 및 Q&A

  • 기초기술 vs. 응용기술
    • 어떤 언어를 배우는 것은 중요치 않다.
    • 언어에 대한 부심을 버리는 것이 좋다.
    • 기반 지식을 알고 있다면, 문제 해결에 도움이 될 수 있다.
  • 특정 언어가 경력의 시작이 되는 경우(자바, 스칼라…)
    • 처음 시작하는 언어는 관심도에 따라 하는게 경험이 될 것이다.
    • 신입은 개발 언어를 어떤 것을 했는지는 중요치 않다.
    • 직장생활을 전제로라면, 돈주는 사람이 원하는 것을 하라.
    • 내가 설득해서 바꾸지 못한다면 역량이 부족한 것이며, 그것이 아니라면 이직하라.
  • 알고리즘
    • 언어학에 라틴어 가설이 있다. 라틴어를 공부하면 모든 언어를 배울 수 있다.
    • 라틴어는 체계적이라 다른 언어를 배우는데 도움이 될 수 있다라는 가설이 있다.
    • 하지만 다른 언어를 배우는데 도움이 되지 않는다. 라틴어를 배우는데 도움이 될뿐이다.
    • 알고리즘도 마찬가지이다.
    • 알고리즘이 모든 프로그래밍에 도움이 된다는 것과는 다르다.
    • 알고리즘이 하는 일에 도움이된다면 하는 것이 좋지만, 환상을 가지지 말라.
  • 개발자들은 중요하다고 하는데 왜 대우는 받지 못하는가?
    • 대기업들도 파트너사에 공정하게 진행하고자 한다. 공공의 적이 아니다. 노력을 하고 있다.
    • IT들은 IT인들을 위하는 위한 단체가 없다.
    • 좋은 결과를 만들어 내지 못하기 때문이라고 생각한다.
      • 환경이 받쳐주지 못한다.
      • 좋은 환경을 찾기위해 발품을 팔았다.
      • 개발자들의 책임도 있지만, 개발자에게 그런 환경을 주지 못한 고용주가 문제다.
    • 회사에서 불만족스러운데, 나가지 못하는 상태가 더 위험한 상태라고 본다. 자신감을 가져라.
      • 회사를 나갈 용기와 환경을 바뀔 상황이 생긴다.
  • 미션을 해결하지 못한 부채감, 기술에 대한 부채감을 극복할 수 있는 조언
    • 개발자가 아니라, 실제 욕할 사람을 욕하라.
    • 개발을 잘할 사람을 PM을 시키는 것이 아니라, 무리한 요구를 막을 수 있는 PM을 시켜야 한다.
    • 그러지 못한 PM과 그런 PM을 임명한 회사가 잘못된 것이다.
    • 내가 한 것에 대한 근거를 만들어두어야 한다. 일일이 하나하나 기록하게 하고 추적하여, 방어할 수 있는 수치를 보여주여라.
      • 눈에 보이도록 만들어라.
      • 만족도는 객과적으로 보일 때 만족감을 느낀다.(ex. TDD)
      • 내가 하는 일에 대해서 눈으로 보이도록, 하는일, 직척도, 남은 일에 대해서 수치로 남겨라.
    • 전형적인 폭포수 방법이 문제다. 실제로 움직이는 제품을 기반으로 이야기한다. 애자일 방식으로 개발한다.
      • 눈에 보일 수 있는 공통적 지표를 만들 수 있다.
    • 개발에 대해서 만족하려면, 짧게 짧게 끝나야한다.
      • 만약 일주일 작업이라면, 태스크를 짝게 짝게 줄여서(반나절) 정도로 나눠서 진행해서 보여줘라.
    • 일을 하면서 에너지를 받고자 한다면, 휴식도 중요하지만, 진척(진전된 것이)이 보여야한다.
      • 내가 하는 일을 잘게 쪼개서 해야한다.
      • 완료가 많아야 한다.
      • 스스로 했다는 느낌이 많아야한다.
      • 쪼개는 기술이는다.
      • 이 부분은 내가 할 수 있는 것이다.
  • 비개발자들이 개발자들과 커뮤니케이션하고자 할 때 무엇이 필요한가?
    • 듣는 입장에서 말할 수 있는 사람이 더 발전할 수 있다.
    • 커뮤니케이션하는 목적(의도)을 분명하게하여 전달하여야 한다.
    • 명확한 의사전달이 필요하다.
    • 비개발들에게 소프트웨어를 경험하게 하는게 도움이 될 것이라고 생각한다.
    • 개발자를 위한 회사라면, 개발자에 언어에 대해 배워라.
  • 비개발자가 “개발자가 잘하는 사람인가”에 대한 판단은 어떻게 해야하는가?
    • 우리한테 전문성이 없는데, 우리가 어떻게 전문성을 가진 사람을 채용할 수 있는가?
      • 잘하는 것이 어떤 것인가에 대한 모형(모델)이 있어야한다.
      • 모형에서 판단 기준을 뽑아야 한다.
      • 윤리인 것을 꾸며내는 것은 쉽지만, 과거에 대한 것을 꾸며내는 것은 어렵다. 모델을 통해 이끌어내야 한다.

SmileCat

SmileCat
How do you define yourself?

[Openlayers] Render Event 정리

## 이벤트### [Map](http://openlayers.org/en/latest/apidoc/module-ol_Map-Map.html)| event | module | note || :--: | -- | -- || [postcompose](...… Continue reading