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
- 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
Ciritical 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
End
주니어 개발자와 시니어 개발자의 차이(김범준)
Senior
- 경험이 많은 개발자?
- 10년 이상 경험을 가진 개발자 (X)
- 1년의 경험을 10번 반복한 개발자
- 단순히 연차가 많은 경험을 가진 개발자는 아니다.
- 10년 동안 다양한 경험을 통해 성장한 개발자 (O)
1만 시간의 법칙?
- 의도적 수련이 필요(Deliberate Practice)
- 학습을 하기 위한 목적
- 일을 하기 위해서 코드를 짜는건 학습인가?
- 온전히 학습하는 시간은 얼마나 되는가?
- 코드리뷰를 하는 건 좋은 경우다.(온전히 학습을 하게 해준다, 비판적 사고)
- 적절한 피드백
- 어떤 것?
- 누가?
- 누군가에게 피드백을 받을 수 있는 존재가 필요하다.
- 스스로의 도전과제를 만들어라.(스스로 단련하라)
- 스스로에게 패널티를 주어라.(스스로의 능력을 제약시키고, 원래의 퍼포먼스를 낼 수 있도록)
Senior
Junior
|
Junior |
Senior |
| 일의 단위 |
Tasks |
Project |
| 기대 결과물 |
코드, 문서 등 |
실질적 성과 |
| 관리 |
일정 |
일정 + Risk
(언제 문제가 발생했었는지, 다양한 경험) |
우아한형제들 기술조직
- 코드 덩어리가 아닌
가치를 만들고 스스로의 가치를 높이며 일한다.
긍정적인 사람은 한계가 없고,
부정적인 사람은 한 게 없다.
-박용후
Senior
Junior
Senior
- 자신의 경험을 나눠줄 수 있고, 그를 통해 동료들을 변화시킬 수 있으며, 변화가 성과로 이어지게끔 하는 사람.
Senior
- 의도적 수련을 통한 발전에 익숙하고,
- 코드가 아닌
가치를 만들낼 수 있으며,
- 동료를 변화시키고 성과로 이어지게 함.
Q & A
회사 차원에서의 지원
- Pair programming
- Module shift
- Freely editing code
이직
- 현재가 싫어서 이직 하는 것은 좋지 않다. (이직을 위한 이직)
- 밖에서 끌어당기는 요구와 맞는 이직이 바람직하다.
스타트업에서의 HR과 스타트업 조직문화론(안민호)
영문호칭 vs. 한글호칭
- 수평문화에 대한 고민
- 단순한 수평문화만을 위한 것을 아니다.
- Communication
- 빠른 의사 결정(Speed)
- 영문호칭 -> 빠른 의사 결정
구성원의 오너십
- 지분(현실적의로 힘듬)
- 인센티브
- 휴가제도
- 스톡옵션
- 중심가치 일치 -> 이게 갖추어져야 앞에 것들이 의미가 있다.
아름다운 이별의 방법
- 아름다운 이별은 없다.
- 채용 절차는 까다뤄야 한다.(구글, 제니퍼 소프트)
왜 창업하려고 하나요?
- IDEA만 가지고 창업을 하면 실패한다.
- 열심히 준비해야만 한다.
- 빠르게 실패해야 한다.
대기업 vs. 스타트업
- 대기업에서는 작은 부분을 깊게 할 수 있다.
- 스타트업에서는 많은 부분을 하게된다.
CEO, CTO
- 21세기 핵심 역량(문제 해결력, 유연성 및 적응성, 창의 및 혁신 능력)
- 변화와 다양성에 유연해져야 한다.
왜 우리는 개발자에 집중하지 않는가?(이민석)
- 소프트웨어 물들다.
- 모든 회사는
[무엇인가]를 가장한 소프트웨어 회사
- 소프트웨어는 업의 생산성이 아니라
업의 가치 그 자체
정작 개발자들은 어디에 집중할까?
- 새로운 기술
- 제품에 대한 결정권
- 회사의 방향성
- 현재 서비스의 개선
- 다양한 프로젝트의 수행
- 리모트 워크
- 승진
- 나만의 작업 공간
- 정시 퇴근(미국은 대부분 정시퇴근이라 우선순위가 낮다.)
이직을 할 때 가장 중요한 것은?
- 연봉
- 일과 생활의 균형
- 기업 문화(의사 결정 - Speed)
- 훌륭한 동료
- 회사에 중요한 일
- 유연 근무
- 기술 스택
- 재택 근무
- 회사 위치
주당, 업무 이외의 코딩 시간
지금도 이직을 생각하나?
- 찾고있지는 않지만, 기회가 오면(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)
- 내가 하는 일에 대해서 눈으로 보이도록, 하는일, 직척도, 남은 일에 대해서 수치로 남겨라.
- 전형적인 폭포수 방법이 문제다. 실제로 움직이는 제품을 기반으로 이야기한다. 애자일 방식으로 개발한다.
- 눈에 보일 수 있는 공통적 지표를 만들 수 있다.
- 개발에 대해서 만족하려면, 짧게 짧게 끝나야한다.
- 만약 일주일 작업이라면, 태스크를 짝게 짝게 줄여서(반나절) 정도로 나눠서 진행해서 보여줘라.
- 일을 하면서 에너지를 받고자 한다면, 휴식도 중요하지만, 진척(진전된 것이)이 보여야한다.
- 내가 하는 일을 잘게 쪼개서 해야한다.
- 완료가 많아야 한다.
- 스스로 했다는 느낌이 많아야한다.
- 쪼개는 기술이는다.
- 이 부분은 내가 할 수 있는 것이다.
- 비개발자들이 개발자들과 커뮤니케이션하고자 할 때 무엇이 필요한가?
- 듣는 입장에서 말할 수 있는 사람이 더 발전할 수 있다.
- 커뮤니케이션하는 목적(의도)을 분명하게하여 전달하여야 한다.
- 명확한 의사전달이 필요하다.
- 비개발들에게 소프트웨어를 경험하게 하는게 도움이 될 것이라고 생각한다.
- 개발자를 위한 회사라면, 개발자에 언어에 대해 배워라.
- 비개발자가 “개발자가 잘하는 사람인가”에 대한 판단은 어떻게 해야하는가?
- 우리한테 전문성이 없는데, 우리가 어떻게 전문성을 가진 사람을 채용할 수 있는가?
- 잘하는 것이 어떤 것인가에 대한 모형(모델)이 있어야한다.
- 모형에서 판단 기준을 뽑아야 한다.
- 윤리인 것을 꾸며내는 것은 쉽지만, 과거에 대한 것을 꾸며내는 것은 어렵다. 모델을 통해 이끌어내야 한다.