레이블이 sw engineering인 게시물을 표시합니다. 모든 게시물 표시
레이블이 sw engineering인 게시물을 표시합니다. 모든 게시물 표시

[컴] 해외 유명 IT 기업 연봉


넷플릭스 연봉 / netflix 복지 / netflix salayr /

넷플릭스 연봉


대략 $300,000 달러/연






[컴] 딜로이트의 2018년 글로벌 CIO 설문 조사 결과

리딩그룹 / 디지털 리딩 / IT회사 / 선두기업

딜로이트의 2018년 글로벌 CIO 설문 조사 결과


디지털 선도 기업(digital vanguard organizations)은 2가지 차별화된 특징을 갖고 있다.
  1. 명확하게 정의된 디지털 전략 a clearly defined digital strategy 
  2. 신기술 활용과 디지털 역량 구축 작업을 IT 조직이 이끌도록 한다 an IT organization viewed by the business as a leader in harnessing emerging technologies and building digital capabilities.


  • 디지털 선도 기업은 글로벌 IT 기업 중 9.7%만이 해당한다.
  • 디지털 선도 기업의 디지털 리더가 다른 기업과 다른점 
    • 업무 우선순위priorities
    • 마음가짐mindsets
    • 문화적 특성cultural attributes


디지털 선도기업의 특징


  1. 성장에 대한 마음가짐Growth mindset
  2. 확대/축소적 관점
  3. 최고의 인재를 유입시키는 문화
    •  디지털 리더 조직의 절반 이상(55%)이 창의적이고 의욕을 고취하는 환경 덕분에 인재를 유지할 수 있었다고 답했다.
    • 조직 문화가 최고의 기술 인재를 유입, 유지, 참여시키는 데 핵심이라는 사실을 알고 있다.
    • 디지털 리더 조직의 절반 이상(55%)이 창의적이고 의욕을 고취하는 환경 덕분에 인재를 유지할 수 있었다고 답했다.
  4. 탄탄한 기술 기반
  5. 강력한 참여 계획





References


  1. '디지털 선도' 기업의 5가지 특징 - CIO Korea, 2019-05-09
  2. 5 ways leading organizations excel at digital | CIO, 2019-05-03

[컴][interview] 면접 실패 사례 - 회사 입장

인터뷰 / 인터뷰의 잘못 된 점 / interview / 고용 / 면접방법의 잘못 / 실패사례 / 아마존 프라임 에어 창업자 실패 / 데니얼 부시뮬러 / 고용을 잘못 한 사례 / 드론


인터뷰 실패 사례


개인적으로 이런 글들을 좋아한다. 우린는 사실 측정할 수 없는 것들을 측정하려 많은 노력을 한다. 그리고 그 측정방법이 옳았다는 것을 증명하기 위해 잘된 경우들만을 늘어놓는다.

하지만 경험 해 본 우리는 그것이 전적으로 옳지 않다는 것을 안다. 하지만 믿을 만한 근거를 제시하기가 쉽지 않다.

그런 의미에서 이런 글들이 많아져야만 우리는 더 나은 방법을 찾을 수 있다고 생각한다.

from: ref. 1, Robert Sweeney, Founder and CEO at Facet

I turned down Daniel Buchmueller for a job at Netflix. After a 60 minute interview I was on the fence, so I concluded that he "wasn't senior enough." He went to Amazon instead where he co-founded Amazon Prime Air (their drone delivery service) and was #2 on Fast Company's "Most Creative People" list. At some point, we programmers are going to have to admit that we really can't judge another programmers technical abilities in a 60 min interview. We end up hiring programmers that are good at interviewing, but not necessarily good at doing the job. And we miss out on engineers like Daniel.

해석

나는 넷플릭스에 있을 때 Daniel Buchmueller 를 채용하지 않았다. 1시간의 인터뷰를 한 후에도 나는 확신이 들지 않았다. 그래서 나는 그가 senior 에 적합하지 않다고 결론 내렸다.

그는 대신에 Amazon 에 갔고, 그는 Amazon Prime Air (그들의 드론 배달 서비스)를 공동설립 했고 Fast Company 의 "가장 창조적인 사람" 리스트에서 2위를 차지했다.

어떤 점에서 우리 프로그래머들은 우리가 다른 프로그래머들의 기술적인 역량을 60분의 면접후에 판단할 수 없다는 것을 인정해야만 한다.

우리는 "면접에서 좋아 보이지만 일을 잘하지는 않는 프로그래머들"을 고용하는 것을 관뒀다.   그리고 우리는 (여전히?) Daniel 같은 엔지니어를 놓친다.


Refrences

  1. Robert Sweeney on LinkedIn, 2019-05-03

[컴] 소프트웨어 팀장(Leader) 가 하지 말아야 하는 행위

PL업무 / sw 개발 / 프로젝트 리더

소프트웨어 팀장(Leader) 이 하지 말아야 하는 행위

‘팀 플레이’라는 안티패턴


  • 팀에 인원이 너무 많은 경우, 개발자들이 서로 반목하면서 동일한 코드를 업데이트하려 경쟁하게 된다.
    --> 검토할 코드가 많아지고, 그 누구도 코드를 일일이 검토해 통합하기 원하지 않게 된다.
  • 마이크로서비스 아키텍처를 구성하는 것은 개발자에게 숨쉴 공간을 준다. 독립적으로 자신이 맡은 코드 작업을 할 수 있다.

‘분할 관리’라는 안티패턴


  • 더 중앙에서 통제를 하고, 더 중앙에서 테스트를 하는 것이 필요하다.
  • 일부 개발자를 지정, 부분들이 가능한 원활하게 함께 작동할 수 있도록 통합을 지속적으로 모니터링하는 일을 맡긴다. 
  • 부분들이 함께 작동하도록 만드는 일은 부분들을 구현하는 것만큼 힘든 일이다. 
  • 개발자들을 동일한 방향으로 계속 유도하는 것 자체가 하나의 ‘일’이다.

‘비전을 따르라’는 안티패턴


  • 모든 개발자가 이런 상상 후, 단 몇 줄의 코드로 모든 기능을 구현하는 ‘초능력’에 대해 상상한다.
  • 계획 수립은 번거로운 일이다. 그러나 나중에 코드를 디버깅하는 것보다 빨리 할 수 있다. 때로는 다짜고짜 저지르기보다 그저 앉아 있는 게 나을 수 있다. 

‘교과서대로’라는 안티패턴


  • 스펙을 만드는 데 몇 달을 소비하고도, 모든 것이 거의 마무리되었을 때 새로운 각도나 문제를 발견하게 된다.
  • 유능한 관리자는 방법론을 선택한 후, 이 방법론이 실패할 가능성에 대비한다.
  • 어느 누구도 항상 성공할 수는 없다. 대비가 중요하다.  

‘프로세스 신뢰’라는 안티패턴


  • 창의성을 방해할까 두려워 세부 사항을 계속 추적하지 않으면 악성 결과가 초래될 수 있다.
  • 책임자는 항상 지연을 초래하는 많은 장벽, 장애물, 문제에 직면하게 된다. 책임자의 도전과제는 효율적으로 일어나는 일을 모니터링하고, 현명한 결정을 내리기에 충분한 정도로 세부사항을 계속 추적하는 방법을 찾는 것이다.
  • 소프트웨어 개발 매트릭스가 부정확할 수 있다.
  • 그러나 지나치게 많은 기대를 하지 않으면, 누가 무슨 일을 하고 있는지 추적할 수 있도록 도와준다.

‘측정하지 않은 것은 관리할 수 없음’이라는 안티패턴


  • 적합한 점수를 파악하는 것은 애초 문제를 해결하는 것만큼 어렵다.
  • 정말 지독한 팀은 더 정확한 평가를 위해 서로를 경쟁시키기도 한다. 이는 팀웍이나 협업에 도움이 되지 않는다.
  • 가장 큰 위험은 개발자들이 힘든 일이나 예측하기 어려운 일을 피하게 되는 것이다.
  • 분기말, 연말에 충분한 점수를 얻게 되지 못할까 우려하는 행태가 번기는 것이다.
  • 해결책은 이런 매트릭스를 지나치게 신뢰하지 않는 것이다. 점수를 추적 관리할 수는 있다. 그러나 이런 점수를 절대적인 척도로 간주해서는 안 된다.

'어리석은 일관성은 편협한 사람들의 망상’이라는 안티패턴


  • 코드에 어느 정도 일관성이 있을 때, 패턴과 시각적인 리듬의 예측성이 높을 때, 코드를 더 쉽게 판독할 수 있다.
  • ESLint 등을 이용하자.

‘기준이 구원자’라는 안티패턴


  • 실행 코드의 품질에 거의 영향을 주지 않는 기준을 강제하는 것은 좋지 않다. 
    • 필자생각: 코드의 일관성을 유지하는 것과의 균형을 잡는 것이 중요할 듯 하다.
  • 스페이스의 위치 같은 것은 사람을 위한 것이다. 사람들이 지나치게 많은 것을 주장하지 않도록 만드는 데 목적이 있다. 
  • 기준을 사용하고 싶다면, 적용하기 쉽고, 실제 유의미한 세부 사항만 신경 쓰도록 단순하게 만들어야 한다

‘스택 단순화’라는 안티패턴


  • 코드 기반의 ‘순정함’을 유지하면, 그 대가로 속도와 효율성을 잃게 된다. 
  • 사용자를 만족시킬 수 있다면, 코드 기반의 이탈을 어느 정도 용인하는 것이 합리적이다. 
  • 절충의 가치가 있는 때를 파악하는 것이 핵심이다.

‘개발자가 직접 도구를 선택’이라는 안티패턴


  • 나중에 문제가 발생한다. 코트린(Kotlin)을 좋아하는 개발자가 팀을 떠나고, PHP를 좋아하는 사람이 코드를 물려 받으면 이를 해독할 수가 없다.
  • 적합한 스킬을 가진 사람들로 팀을 구성해 유지하는 경우에도, 자바스크립트 개발자들은 스위프트(Swift)로 작성된 코드를 확인할 때 고생을 하게 된다.
  • 지나치게 개방적으로 모든 것을 수용해서는 안 된다.

‘성공의 열쇠는 동기 부여’라는 안티패턴


  • 동료가 한 장의 티켓을 여러 티켓으로 분리해야 한다고 주장하는 것을 보았다. 봉급에서 보상을 받기 위해서이다. 이 동료는 풀 리퀘스트, 지원 티켓, 애자일 매트릭스를 ‘조종’하는 데 있어 ‘달인’이었다.
    • 필자생각: 소프트웨어 개발에 경영을 위한 측정을 하겠다는 생각은 어리석다. 왜냐면 그것은 개발자 마음대로 쪼개고 늘리고 할 수 있는데다, 복잡도는 높다. 그래서 룰을 만들어도 쉽게 룰을 피해갈 수 있으며, 완벽한 룰을 만들면 할 수록 개발은 유연성을 잃고, 제대로 된 개발을 할 수 없게 되기 때문이다.
  • 개발자들에게 진짜 동기를 부여하는 것은 수수께끼 같은 난제이다. 
  • 개발자들은 흔히 자신만의 생각을 갖고 있으며, 누구보다 도구를 잘 이해한다. 
  • 우리가 할 수 있는 최선은 ‘파트너십’에 대한 의식을 불어넣고, 큰 그림을 이해하도록 만드는 것이다. 
  • 그런 후, 이들이 추상적인 목표를 여러 수 많은 깨끗한, 테스트가 완료된, 버그가 거의 없는 코드로 바꿔 놓도록 바래야 한다.

References


  1. SW 프로젝트를 산으로… 서툰 리더십 행태 11가지 - CIO Korea





[컴] 테크기업에게 무엇이 적합할까 Teams ? slack ?



테크기업에게 적합한 협업툴

ref. 1 에서 UC 는 microsoft teams 같은 tool 을 이야기 하는듯 하고, 협업툴(team collaboration tool)은 "슬랙" 같은 tool 을 이야기 한다.

테크기업에게 협업툴이 더 잘 맞을 것이라는 이야기가 있어서 가져와 봤다.

451 리서치(451 Research)의 수석 애널리스트 라울 카스타논 마르티네즈

마르티네즈는 "비즈니스 특성상 UC(Unified Communication, 통합 커뮤니케이션)보다 협업 솔루션이 더 잘 맞는 곳들도 있다. 스타트업이나 디지털 네이티브 기업들이 그 예다. 단순히 직원 가운데 IT 전문가 비율이 높아서만은 아니다. 지식 노동자의 비중이 높을수록, 그리고 엔지니어 및 개발자 직원 기반이 강세일수록 협업 솔루션이 더 적합하다. 이들의 커뮤니케이션 방식에 더 잘 맞기 때문이다. 이런 이유로 UC에서 협업 툴로 이전하는 기업들도 많을 것이라 생각한다"고 말했다.[ref. 1]

“There are some companies that because of the nature of their business, could be well suited for that,” Castañón Martínez said, such as startups or digital native companies. “Not just because they tend to be more tech-savvy or tech-oriented than other companies, but mainly because of the type of workers. If they have a higher percentage of knowledge workers, and they are in a stage where they might have a strong employee base of engineers and developers, it just makes sense because that is how they communicate. So, I think that we might see some shift in that sense.”

Teams Demo


Slack Demo



개인적인 의견

개인적으로 둘다 안사용하는 것보다는 좋다고 생각한다.

하지만 굳이 선택을 하라면, slack 쪽이 더 좋다. 확장성도 좋고, 사용성도 좋다. Teams 는 써보지 않았지만, demo 비디오로 봤을때 기존의 우리가 많이 사용하던 tool 이다. 그것의 장점은 정리가 잘 될 수 있다라고 생각하는데(물론 요새 많이 바뀌었긴 하지만)문제는 대다수의 사람들을 그 정리된 interface 에 맞추려 하는 것이다.

IT회사에서 일할때 대체로 사람들은 자료정리에 시간을 보내지 않는다. 그렇기에 당연히 slack 이 낫다. 하지만 하나의 단점이라면, 채팅으로 되어 있어 불필요한 대화들도 같이 들어가 있기에 추후에 자료를 정리하고 싶은 순간이 오기는 한다.


References

  1. 블로그 | 2019년 협업 소프트웨어 시장, '춘추전국시대가 온다' - CIO Korea
  2. Collaboration 2019: Teams, Slack and what’s coming | Computerworld

[컴][생각] 프로그래머의 초과근무

초과근무 /

프로그래머의 초과근무


Stack Overflow’s 2018 Developer Survey 에서 프로그래머들이 엄청나게 많은 양의 overtime 일을 하고 있다는 것이 드러났다. 그래서 관련되서 reddit 에 댓글들이 엄청달렸다.

reddit 에서 best 댓글은 아래와 같다.



프로그래머의 초과근무는 여러모로 좋지 않다. reddit 의 댓글에 있는 글들이 수많은 안좋은 이유를 알려준다.

프로그래머가 새로운것을 찾고, 학습하는 시간도 결국 프로그래머의 일하는 시간이지만, 안타깝게도 실제로 그것을 인정받기는 쉽지 않다.

그래서 나는 저 reddit 의 댓글에 찬성한다. 정말 이 한몸 불살라서 내가 돈을 많이 벌겠다는 의지가 아니라면, 정해진 시간만 일하라고 하고 싶다. 어차피 그 이외의 시간에도 풀리지 않았던 문제나 풀어야할 문제가 머리속에서 지워지지 않아서 자신도 모르는 사이에 일하게 될 테니 말이다.

References


  1. Stack Overflow’s 2018 Developer Survey reveals programmers are doing a mountain of overtime : programming

[컴] unit test 작성 범위는 ?

유닛테스트 작성방법 / 유닛테스트 작성 범위


Unit test 의 작성 범위

reddit 에 재밌는 글이 올라왔다.

대략의 내용은 "굳이 하지 않아도 되는 Unit Test 까지 만드느라고 시간을 낭비하고 있다." 정도일 듯 하다. 


우리가 unit test 를 필요로 하는 이유중 하나는 code가 추가되거나 변경될 때, 기존동작에 영향을 미치지 않는 것에 대한 확신을 가지기 위해서 이다.

개인적으로도 이 관점에서 우리가 만약 계속 확장되고, 다듬어져야 하는 project를 진행한다면 unit test 가 꼭 필요하다고 생각된다.

하지만 그렇다고 해서 모든 code 에 대한 검증을 할 필요는 없다. 그것은 시간이 너무 많이 소요되며, 크게 의미가 있지도 않다.

그럼 어떤 unit test 를 하지말아야 할까?


wrapper function 처럼 명확한 code 는 하지 않아도 된다.

위의 link 글에서도 이야기 하지만, 너무나 명확한 code는 굳이 unit test 를 작성할 필요가 없다.

위의 글에서는 아주 명확한 case 를 보여준다. 아무 일도 하지 않고, wrapper function 의 역할을 하는 method 가 예시로 나온다.


public method 에 대한 unit test 만으로 충분

원래 unit test 가 private method 에 대한 test 를 하지 않도록 되어 있지는 않다. 실제로 구글링을 해봐도 unit test 에서 private method 에 대한 test 방법들이 있다.

그래서 필자도 처음에는 특정 logic 에 대한 검증을 하기 위해 private method 라도 unit test 를 시행했다.

하지만 이런 경우 차라리 새롭게 public method 를 사용하도록 새로운 class 로 refactoring 을 하는 것이 맞는 듯 하다. 그리고 되도록 unit test 는 public method 선에서 처리하는 것이 좋은 듯 하다.

왜냐하면 private method 는 결국 public method 안에서 사용되며, private method 가 제대로 동작하지 않는다면 public method 또한 제대로 동작하지 않기 때문에 굳이 중복해서 test 를 행할 피요가 없기 때문이다.


그리고 우리가 public method 수준의 unit test 를 가지고 있어야, class 내부를 refactoring 하는 경우에 많은 private methods 들이 변경될 때 우리는 그것에 대한 unit test 를 없애고, 또 만들어야 하는 일을 하지 않아도 된다.

그러기에 우리는 public method 수준에서 unit test 를 충실하게 작성하면 충분할 것이라 생각한다.


mock up 이 필요한 경우등은 private method 를 test 해야 하는가?

그런데 간혹 외부 라이브러리 등의 문제등으로 mockup 등을 만들 수 없는 경우가 있을 수 있다. 이 경우 public method 를 검증하지 못할 수 있다. 그래서 private method 를 검증해야 할 것 같다. 하지만 만약 그런 경우의 private method 라면 새로운 class 로 만드는 것을 고려해 봐야 할 것이다. 아래 글들이 도움이 될 듯 하다.






[컴][툴] 협업툴



협업 툴 

  • 메신저를 중심으로 정리: slack, 잔디, 팀업
  • 한화면에서 편집하는 방식으로 정리 : 비캔버스
  • 마인드맵을 이용하는 정리 : 마인드 메스터
  • 카드형식의 정리 : 트렐로
  • 위키를 이용한 정리 : 컨플루언스


Demo 영상들



슬랙

  • 슬랙(Slack) 간단히 둘러보기 - YouTube
  • Slack을 3개월간 써본 단상, 2016-03-01 : 한글 검색이 상당히 문제가 있고 아울러 영어 검색도 딱히 좋지는 않다. 과거 대화록 검색에서 결국 원하던것을 찾지 못하여 스크롤로 찾은 적이 제법 있었으니, 검색은 사실상 포기하는게 나을수도 있다. (이건 Confluence나 JIRA 같은 경우에도 해당되는 문제이다)

잔디


  • 무료 :
    • 팀전체 5GB 저장용량
    • 검색 : 최근 메시지 15,000개
    • 팀 관리자 1명
    • 팀 멤버 최대 500명
  • 프리미엄 : 인당 월 5,000원
    • 멤버당 10GB 의 저장공간
    • 검색 제한없음
    • 관리자 무제한
    • 멤버 제한 없음
    • 방문교육
    • 고객지원
  • 엔터프라이즈 : 멤버당 9,000원

팀업 (이스트소프트)

타임라인 방식, 슬랙이나 잔디 같은 방신인듯.

  • 무료 :
    • 개인당 5GB 최대
    • 개별 업로드 용량 100MB 최대
    • 사용인원 최대 50명
    • 백업 (1차 백업)
  • 프리미엄 : 인당 월 5,000원
    • 팀별 1인당 30GB
    • 개별 업로드 최대 2GB
    • 3차 백업


콜라비

아직 신생업체, skip


비캔버스


트렐로


  • 무료
    • 무제한 보드, 리스트, 카드, 멤버, 체크리스트, 첨부파일
    • 보드당 1개의 Power-up
    • 첨부파일 1개의 최대용량 10MB
  • 비지니스 class : 인당 월 $9.99
    • 무제한 Power-up
    • 첨부 파일 최대 250MB
    • 팀의 보드들을 collections 을 이용해서 묶을수 있다.
    • public/private 보드들을 만들수 있는 이용자를 설정할 수 있다.




  • 개인 : 인당 월 $5.99
    • 무제한 마인드 맵
    • 파일/이미지 첨부
    • 이미지 / pdf 내보내기
    • 고급인쇄
    • 우선수위 고객지원
  • 프로: 인당 월 $9.99
    • 개인버전의 모든 기능
    • 여러사용자
    • 관리자 계정
    • 워드와 파워포인트문서로 내보내기
    • 프레젠테이션 내보내기
    • 사용자정의 맵 테마
    • 도메인로그인을 위한 G Suite
    • 사용자정의 서식
    • 통계 & 보고서


컨플루언스


  • 소규모 팀 : 월 $10 - 최대 사용자 10명
  • 성장하는 팀 : 월 $50 - 15 users / $100 - 25 users
  • 자체 서버 호스팅 : $10 결제 - 최대 10명 사용
    • 1년간 무료 유지보수

네이버 카페

  • 개인적으로 ui 가 불편하다.
  • 주제별로 엮기가 힘들다