경력

실패는 나침반이다

이미지 출처 : https://www.yes24.com/Product/Goods/125116480 언급된 도서 Sometimes you win, sometimes you learn 아주 작은 습관의 힘’(Atomic Habits) 결정적 순간의 대화 감상 2024.05.05 긴 호흡으로 경력을 돌아보고 내다보라는 격려를 책에서 받았습니다. 인상 깊은 단락 p8 밑으로 떨어지는 경험을 해봐야 감사하는 마음으로 다시 올라갈 힘이 생긴다. 인간 관계는 수단이 아닌 목적이어야 한다고, 실패는 나침반이라고 나 자신에게 전해주고 싶다. p20 하지만 후반기(3년)에는 시장에서 야후가 구글에 밀리면서 회사 내부가 정치적으로 변해갔다.

늙은 웹 기획자

감상 2023.05.05 기획자에 대한 이해를 넓히려고 읽은 책이다. 예상보다는 저자의 개인적인 감정과 단상이 중심인 책이였다. 저자가 근 20년 경력이라고 하니 나와 비슷한 연차일듯하다. 내가 저자와 성향이나 하는 일은 다르지만 회사 경력의 후반부에서 어떤 지향점을 가져야할지를 생각해보는데에는 의미가 있었다. 개발자를 대하기 어려워하는 내용을 보면서 주변에 더 친절해져야겠다는 생각이 들었다. 저자의 바램대로 책이 출판되었으니 저자가 우울함에서 조금 더 벗어났으면 좋겠다. 인상 깊은 단락 p14 하지만 우리 팀의 막내는 개발자다. 개발자는 건드리면 안 된다.

오늘도 개발자가 안된다고 말했다

이미지 출처 : http://www.yes24.com/product/goods/97919905 감상 2022-09-16 개발자가 기획자/디자이너의 직무를 이해하기에도 좋은 책이다. 인상 깊은 단락 p48 반면 목적지를 아는 사공들이 탄 배는 노 없이 맨손으로 젓게 되더라도 조금씩 목적지에 가까워진다. p55 기획의 정의 어떤 대상에 대해 그 대상의 변화를 가져올 목적을 확인하고, 그 목적을 성취하는 데에 가장 적합한 행동을 설계하는 것 p85 이때 기획자들이 많이 하는 실수 중 하나가 화면 설계서를 개발 요청서로 생각하는 것이다. 그러나 화면 설계서는 개발 진행 시에 발생할 수 있는 이슈나 정책 보완점을 미리 고려하고 문제 발생 시에 다른 우회 방안을 찾는 등 협업자들의 의견을 수렴하고 개선하는 커뮤니케이션을 위한 문서다.

개발자로 살아남기

이미지 출처 : http://www.yes24.com/product/goods/105645204 정리 핵심키워드 정리 엔지니어링 역량 : 성장하는 10년 개발에 대한 기본 지식 : 언어, 도구, 비판적 사고(Critical thinking) 제품 디자인 : A/B Testing, 데이터 주도개발, 도그푸딩 등 개발 주기 지식 : 애자일 매니지먼트 역량 : 리딩하면서 일하는 10년 프로젝트 리드 : 계획 세우기, 역할 나누기, 시간 아끼기, 문제 해결, 우선 순위 테크니컬 리드 : How to를 고민, 모르는 일을 쪼개기 피플 매니징 : 성향 파악하기, 면담, 성과 평가, 행복 만들기, 성장시키기 프로세스 관리 : 프로세스 정립, 시스템 도입 등 비즈니스 역량 : 서포트하는 10년 채용 : 채용 목표와 원칙 세우기, 프로세스 운용 사업 만들기 : 성장 전략, 수익화, 팀빌딩 비전과 조직 문화 만들기 시간관리 목표,계획,실천,측정 싸이클 우선 순위 관리 이메일, 회의 최적화, 휴식 인상 깊은 단락 프롤로그 p12 저는 농담으로 디렉터를 정의하며 이런 표현을 씁니다.

테크니컬 리더

테크니컬 리더: 혁신, 동기부여, 조직화를 통한 문제 해결 리더십 관련 자료 https://www.slideshare.net/mrbin95/ss-16004929

생계형 개발자 SI에서 살아남기

감상 2020.06.30 ( ‘SI에서 비지니스는 쿼리에 있어야 합니다.’ 등 70, 81, 82, 85페이지를 읽고 소감) ‘ArrayList 가 thread safe 하기 때문에'라고 적어놓은 것이 우선 흥미롭다. ‘ArrayList'의 JavaDoc을 보면 그렇지 않다는 것을 바로 알 수 있기 때문이다. ‘Note that this implementation is not synchronized.’ 라는 문구가 굵은 글씨도 강조되어 있다. 저자가 그런것은 관심을 둘 필요가 없다는것을 강조하기 위해 위와 같이 정확하지 않게 기술한 것일수도 있겠다. 암튼 SQL에 최대한 많은 로직을 두고, Java단에는 Map만 넘기는 개발스타일이 SI에서 선호되는 이유는 다음과 같다고 나는 생각한다.

개발 7년차, 매니저 1일차

감상 2020.04.18 멘티 개발자, TL, 매니저 등 단계별로 신경을 써야 할 일들을 이 책에서 체계적으로 정리했다고 느껴집니다. 미국 IT 업계를 배경으로 하고 있지만 국내 IT회사에 다니는 분들도 공감이 갈만한 지점이 많습니다. 1On1 미팅을 강조하고 있다는 점도 인상적입니다. 2020.06.30 ‘실리콘밸리의 팀장들’ , ‘개발7년차, 매니저 1일차’, ‘슬랙’ 을 읽고 느낀 점 다른 사람과 협업을 하는 모든 개발자는 ‘관리'의 영역에 있는 일을 신경써야 한다. 관리 업무에서 가장 중요한 지점은 ‘명확한 피드백'을 전달하는 것이고, 때로는 불편한 피드백을 주어야 하는 경우도 있다.

실리콘밸리의 팀장들

감상 구글/애플에서 관리자를 경험을 하고, 애플대학교에서 ‘애플경영법'을 강의했던 킴스콧이 쓴 책. ‘조직 내에서 건설적이지만 불편할 수도 있는 피드백을 어떻게 잘 주고 받을 것인가?‘가 이 책의 핵심 화두이다. 중간중간 나오는 쉐릴 샌버그, 에릭슈미츠, 스티브잡스 같은 거물들의 일화들도 흥미롭다. 인상 깊은 단락 33 (‘최고의 상사는 감정노동의 달인’ 단락) 사람들은 상사가 느끼는 ‘감정 노동'을 과소평가하며, 대개 서비사람들은 상사가 느끼는 ‘감정 노동'을 과소평가하며, 대개 서비스나 의료 산업에 종사하는 사람들, 예를 들면 정신과 의사나 간호사, 웨이터 항공 승무원이 느끼는 일로 치부한다.

실리콘밸리 견문록

인상 깊은 단락 p42 옆자리 증후군 (the next-bench syndrome) 이라는 단어의 유래도 HP다. 옆자리 동료에게 도움이 될 만한 기술이라면 개발할 가치가 있다는 뜻이다. 휴렛이 어느날 거대한 계산기를 보며 주머니에 들어가는 휴대용 계산기가 있으면 좋겠다는 아이디어를 낸다. 마케팅 부서에서 그런 계산기는 10배나 비쌀텐데 누가 사겠냐고 묻자, 휴렛은 가니느 살 거라며 개발을 시작한다. 거기에서 휴대용 전자 계산기 시장이 생겨났다. p87 신규 직원 한명당 평균 350만원 정도다. 이해를 돕기 위해 비교를 해보자면, 구인활동에 쓰는 비용이 직원 한 명을 훈련하는 비용의 세 배에 이른다고 한다.

프로그래머로 산다는 것

감상 저자 중 네 분이 지인이라 반가웠다. (유석문 님, 황상철 님, 이상민 님, 김성박 님) p203 만약 여러분들이 신입사원이라면, 3~5년차 이내의 IT 회사에 있는 개발 직군의 직원이라면 개발을 하라. 뒤도 돌아 보지 말고, 주변을 둘러보지 말고 개발을 하라. p212 IT 회사는 머리로 일하는 회사다. 머리를 지속적으로 사용하는 데에는 한계도 있고, 만약 지속해서 개발만 하다 보면 악성 코드가 양성되기 마련이다. 8시간 동안 일한 사람과 12시간 동안 일한 사람 중 누가 더 집중적으로 일할까?

프로그래머 그 다음 이야기

감상 2014/03/07 임백준님, 이주연님의 뛰어난 글솜씨, 나와 같은 회사를 다니셨던 박재성님의 공감할만한 이야기 덕분에 재미있게 읽었다. 6명의 저자 중 4명이 기술사라서 다양한 진로의 경험을 전달하지 못한 점이 아쉽다. 기술사 시험에 합격하기 위해 얼마나 많은 노력을 했는지 이야기하는 내용이 몇 번 반복되고, 100여자루의 다쓴 볼펜 사진이 두 번이나 나온다. (이춘식님이 147쪽에, 신재용님이 300쪽에) 인상깊은 부분 p133 프로그래머가 프로그램을 실제로 코딩하는데 드는 시간은 얼마나 될까? 1985년 Fairly의 조사에 의하면 프로그래밍 작성에 13% 정도만 소요된다고 한다.

소프트웨어 아키텍트가 알아야할 97가지 이야기

인상 깊은 단락 6쪽 기교로써 단지 대화에 익숙해지는 것만으로는 충분하지 않습니다. 존경심을 가지고 사람을 대하는 것을 배우고, 사람에 대한 성급한 판단을 버리는 것을 배우는 것이 영리한 아키텍트가 유능한 아키텍트로 변하는 핵심 기술 중 하나입니다. 38쪽 좋은 아키텍트는 사례르 통해 팀을 이끌어야 합니다. 아키텍트는 네트워크를 설치하고 빌드 프로세스를 설정하는 것에서부터 단위 테스트를 작성하고 벤치마킹을 수행하는 것까지 자신의 팀 내 어떠한 역할도 수행할수 있어야 합니다. … 훌륭한 아키텍트는 문제를 찾아내어 팀을 소집하고, 희생자를 지적해내지 않고, 무엇이 문제인지 설명하고, 정교한 대안이나 해결책을 제시할 수 있어야 합니다.

시지프스를 다시 생각하다

시지프스를 다시 생각하다 : 어느 개발자의 직장 생활에 대한 보고서 인상 깊은 단락 p86 3M이 식스시그마를 도입하자 가시적인 지표는 개선되었지만 매출에서 신제품이 차지하는 비율이 줄어들었음.

프로그래머의 길, 멘토에게 묻다

감상 개인적인 성장을 위해서 팀이나 고객을 이용하려 하기보다 공동체의 다양한 관심사를 기꺼이 더 우선시하는 것은, 장인 정신에 바탕한 접근 방식의 특징적인 면 중 하나이다” 개발자로서의 명예욕구가 큰 사람이 팀과 잘 조화를 이루지 못하는 경우를 보기도해서, 눈에 띄는 문구 인상 깊은 부분 p67 시간이 지남에 따라 이런 벤더 테스트 코드는 라이브러리를 최신 버전으로 업그레이드 했을 때 시스템에 문제를 발생시키는지 검사하는 용도로도 쓸 수 있다. p71 http://erlangish.blogspot.com/2007/05/shape-of-your-mind.html 의 내용 프로그래밍 언어가 미치는 영향성.