1부 소프트웨어 개발자로 입문하기 4장 기술을 발전시키는 방법 연습하라. 어떤 기술이든 발전시키려면 시간이 든다. 무엇이든 잘하려면 연습을 많이 해야 한다. 시간이 너오래 걸리는 것 같아도 답답해하지 마라. 특히 발전이 정체되고 있다고 느낄 때 조심해야 한다. 확실한 계획과 명확한 목표를 따라가는 한 기술은 분명발전할 것이다. 꾸준히 해나가는 데 의의가 있으니 그저 끈기 있게 정진하라. 2부 일자리 구하기 13장 이력서 만들기 좋은 광고가 최대한 짧은 시간에 구매로 이어지듯이 좋은 이력서도 최대한 짧은 시간 안에 면접으로 이어진다. 그러므로 이력서는 1페이지로 작성하라. 이 말은 이력서가 간결하게 핵심을 보여줘야 한다는 뜻이다. 14장 면접 절차 저는 능동적인 사람입니다. 해야 할 일이 무엇인지 스스로 ..

대부분의 기업은 민첩성을 최적화하지 않았다. 효율성을 높이는 데 있어 최저 비용을 최우선으로 놓았는데, 이렇게 하면 일종의 딜레마에 빠진다. 기업은 문화를 바꾸고, 관료제를 바꾸며, 조직을 변화시키고, 기술 아키텍처를 변화시키고 민첩하게 만들어야 한다. 나는 코닥과 블록버스터의 운명이 의도적이었다고는 생각하지 않는다. 오히려 그들은 적응하고자 노력했다고 본다. 그러나 오늘날 내가 이야기하는 많은 회사와 마찬가지로 변화는 정말로 어렵다. 한 가지 다행스러운 점은 이것이 불가능하지는 않다는 것이다. 기업 문화가 핵심이다. 재무상의 결과도 물론 자랑스럽지만, 회사 문화의 진화가 나에겐 가장 자랑스러웠다. 소프트웨어 릴리스는 화요일부터 목요일 밤까지 이뤄졌다. 다행히 그달에는 수백 건의 릴리스가 성공적으로 완료..

Rands in Repose 여러가지 좋은 이야기를 때로는 날카롭고 또 자세하게 쓴 점은 좋지만, 문화적인 맥락이 우리와 달라 유머나 반어법으로 쓴 부분들은 와 닿지 않거나 어색한 느낌이 들어서 좀 아쉽다. 번역자도 이런 점을 고려했는지 IT 개발자가 쓴 인간관리 이야기를 통해 문화적 배경 지식에 대한 정보를 추가했다고 알려주고 있지만, 이걸 같이 보는 게 불편할 수도 있고, 이런 설명을 통해서도 여전히 직접적으로 느껴지지 않는 부분들은 분명히 있을 거 같다. 이런 점만 극복할 수 있다면 오랜 기간 여러 번 이직을 거치며 경험을 쌓은 저자의 management 기술은 분명 배울 점이 많고 도움이 된다고 생각한다. leadership 훌륭한 경영자란 우리가 조직의 어느 위치에 있든 상관없이 대화를 해서 관..

저자가 java 전문가라 약간 치우친 경향도 있고, 또 기술적인 내용은 java에 관계된 게 대부분이나, 전반적인 부분은 기술이나 특정 언어와 무관하게 적용할 수 있는 이야기이고, 읽기 쉽게 쓰려고 노력한 점이 엿보인다. 표지에도 썼지만 신입으로 지원하거나 경력이라도 junior인 개발자들에게 적합한 책이다. 면접관들은 당신들을 뽑아주기 위한 사람이다. 회사에서 면접을 보는 이유는 그 분야에 사람이 필요하기 때문이다… 사람이 긴장하는 이유는 자기능력보다 잘보이려고, 잘하려고 하기 때문이다. 하지만, 긴장을 하게 되면 알고 있는 것도 제대로 대답을 못한다… 그 회사에 떨어지면 좀 어떤가? … 그래야 내가 부족한 것이 무엇인지 내가 얼마나 성장을 하고 있는지, 얼마나 가치를 인정받을 수 있는지를 무료로 컨설..

기본적 논지는 즉, 시스템을 설계하는 조직은..… 그 조직에서 사용하는 커뮤니케이션 경로를 복제한 설계를 할 수밖에 없다는 것이다. 우린 이 사실이 시스템 설계 관리에 커다란 영향을 미치는 것을 봐 왔다.우리는 조직 설계 구조와 관련된 한 기준을 발견했다. 설계를 위한 노력은 커뮤니케이션의 필요에 따라 조직화돼야 한다. Conway’s law 악보는 대규모 음악 앙상블 연주팀이 성공적인 연주를 하도록 돕지만, 공연과 연주의 세세한 부분까지 모든 것을 담고 있지는 않다. 시기, 장소, 연주자들의 조합에 맞게 앙상블 연주팀이 그 악보를 해석해 내야 한다. 이와 유사하게 일관적인 용어 사용과 협업 방식에 관한 동의는 좋은 소프트웨어 전달을 달성하는 데 큰 가치를 제공한다. 1부 전달 수단으로서의 팀 조직 구조..

소프트웨어가 하드웨어보다 더 저렴하고, 유연하고, 바꾸기 쉽다는 통념이 있다. 유감스럽게도 시스템의 물리적 작동 방식을 바꾸는 데 소프트웨어를 사용하는 일은 항상 간단하지만은 않다. 보잉 737 맥스 Boeing 737 MAX 여객기 추락 사고에서 346명이 사망 How the Boeing 737 Max Disaster Looks to a Software Developer — IEEE Spectrum 2020년 초 미국 아이오와주에서 치러진 민주당의 대선 예비선거는 시스템 장애로 집계 결과 발표가 지연 2010년에 있었던 스턱스넷stuxnet 웜 공격은 이란의 우라늄 농축 원심분리기를 파괴 2015년 12월에 우크라이나에서 일어난 대규모 정전 사태는 러시아에서 만들어진 악성코드 때문에 발생했지만, 러시아..

개발 세계에는 여러가지 개발 방법론이 많다. 가장 유명한 건 아무래도 TDD이겠지만, 최근 가장 각광받는 건 DDD라고 생각한다. 그 이유는 아마 세상의 수많은 software는 대부분 현실의 문제를 해결하기 위해 만들었을텐데, 그걸 해결하는 게 여전히 힘들기 때문이라고 생각한다. 현실의 문제를 해결하는 게 아직도 힘든 이유도 여러가지가 있겠지만, 그 중 하나는 비즈니스를 하는 사람들과 개발자들간의 간극에 있다. 개발자들은 요구 사항에 맞춰 서비스를 만들(었다고 생각하)지만, 비즈니스를 하는 사람들은 내가 요구한 게 아니라는, 이 업계가 탄생한 순간부터 발생했던 문제. 애자일 방법론도 사실 이 문제 때문에 나오지 않았던가. 동작하는 소프트웨어를 전달하기 위해서. DDD는 이런 간극을 좁히기 위한 고민의 ..

어떻게 보면 여러가지 도구를 다루고 또 애자일에 대한 이야기를 하면서 혼란스러울 수 있으나, 협업을 잘 하기 위해 필요한 것들을 이야기한다는 관점에서 바라보면 이해가 간다. 특히 조직의 변화를 이야기하는 부분은 참 공감도 가고 현재 경험을 하고 있는 내 입장에서는 고생했겠다는 생각이 든다. 굉장히 잘 정리된 건 아니지만, 그만큼 저자가 고생했던 걸 모아놨다는 걸 생각하면 모든 노하우를 정리하기도 어려웠을 거 같단 생각이 든다. 모든 조직에 딱 들어맞는 방법론은 없다. 각 조직에 어울리는 방법론이 있을 뿐이다. Home | Scrum Guides (1) 스크럼 정의 스크럼은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법을 활용하여 가치를 창출하도록 도와주는 경량 프레임워크다. 간단히 말해서 ..

서문 전체 비즈니스 가치 흐름에 걸쳐 팀이 일하는 방식을 바꿔야만 이를 달성할 수 있다고 말한다. (내가 현재 달성하고 싶어하는 가장 중요한 일 중 하나. 회사 business 기능의 모든 flow를 end to end로 flow diagram으로 표현해서 구조를 파악하고 서로 communication하는데 낭비가 없도록 하는 일) 옮긴이의 말 IT 조직은 애자일이나 데브옵스 등과 같이 프로젝트를 효율적으로 진행할 수 있는 도구를 익히고 이를 통해 의사소통합니다. 반면 소프트웨어에 대한 비즈니스 조직의 시각은 여전히 테일러리즘 방식에 머물러 있습니다. 이러한 차이가 디지털 변혁의 큰 장벽 중 하나입니다. 이는 IT 조직과 비즈니스 조직의 의사소통에 문제를 일으키고 디지털 변혁 실패의 원인이 됩니다. (내..

대다수 기업은 IT 기술에 대해 여전히 구시대적 마인드셋(사고방식)을 갖고 있다. IT 기술을 비즈니스의 핵심적인 원동력으로 보지 않고 단순한 필요 비용으로 여긴다. IT팀원을 비즈니스를 위해 일하는 사람으로, IT 부서의 관리자와 리더를 단순히 비즈니스를 지원하는 인력으로 여긴다. IT팀은 실제 고객과 단절되어 있으며, 회사에서는 제품을 직접 사용하는 사람이 아닌, 회사 내의 이해관계자들을 고객으로 여기도록 독려되는 것이 현실이다. (그래서 직접 경험해보니 “내부 고객"이란 말이 정말 싫어졌다. 거의 혐오할 정도) “리더십은 모든 사람의 내면에 위대함이 있음을 알아봐 주는 것이고, 리더의 임무는 그 위대함을 펼칠 수 있는 환경을 만들어 주는 것이다.” (요즘에 읽는 책들은 어디서나 빌 켐벨의 이야기가 ..