직업으로서의 개발자 직업으로서의 개발자

넷플릭스로 '이토록 친밀한 배신자'를 보았습니다. 꽤 재미있었습니다.대략의 줄거리는 프로파일러 아버지와, 아버지를 포함한 다른 경찰들에게 살인 용의자로 의심받는 딸 장하빈의 이야기입니다.범인을 추적하는 과정의 긴장감도 좋았지만,믿는다는 것은 무엇인지, 드라마 속 여러 등장인물들 각각의 입장에서 조금씩 다른 각도로 생각해 보게 되어 좋았습니다.등장인물들 모두가 저마다의 이유로 상대를 믿거나 믿지 못하고, 믿음이 틀릴 때도 있고, 의심이 맞을 때도 있었습니다. 드라마를 다 보고 나니 떠오른 궁금증은 제목의 의미였습니다.'이토록 친밀한 배신자'라는 제목이 무엇을 뜻하는지 이해하지 못한 채, 읽고 있던 소설 '양손에 토카레프'에서 우연찮게 그 의미에 대한 힌트를 얻게 되었습니다. 아니, 힌트라기보다는 답을 ..

이전글2024.11.15 - [DEV] - AI Agent concept AI Agent conceptAgentAI agent workflow가 올해 엄청난 AI 진전을 이끌 것이라고 생각합니다. 아마도 차세대 기초 모델보다 더 큰 진전이 있을 것입니다.-앤드류 응(Andrew Ng)기업의 대부분(82%)이 1~3년 내에developer-as-job.tistory.com2024.11.16 - [DEV] - AI agent frameworks AI agent frameworks이전글 - AI agent, CoT, ReAct에 대한 설명2024.11.15 - [DEV] - AI Agent concept AI Agent conceptAgentAI agent workflow가 올해 엄청난 AI 진전을 이끌 것이..

팀 매니저로서 테크리드들에게 프로젝트 계획 중 일부를 수립하도록 요청할 수 있으나, 아마도 그 작업 중 일부는 여러분이 직접 하게 될 가능성이 크다. 어떤 프로젝트를 맡을지, 진행하기로 한 프로젝트를 뒤로 미뤄야 할지를 결정해야 할 수도 있다. 애자일 방식으로 계획하고 반복되는 작업일지라도 언제 완료될 것인지 대략적인 추정을 해야 할 수도 있다.팀원들의 작업량을 성공적으로 관리하기 위해서는 팀의 리듬과 속도에 대해 충분히 이해할 필요가 있지만, 다행히도 도움이 될 만한 손쉬운 방법이 있다.프로젝트 관리에 관한 경험 법칙이 법칙 중 어느 것도 애자일 프로젝트 관리 방법을 대체하지 못한다.대부분의 팀에는 상위 수준인 장기적 목적과 이들 목적을 달성할 수 있는 단기 목표가 있다. 이것들을 실제 작은 단위로 계..

마이크로매니지먼트에서 가장 어려운 점은 그렇게 할 때와 하지 않아야 할 때를 구분해야 한다는 점.주니어 개발자는 구체적인 지시를 원한다. 가끔 세부 사항을 확인하고 지시해야 일을 더 잘한다. 하지만 습관처럼 또는 기본방식으로 마이크로 매니저를 사용하면 좋지 않은 결말을 맞게 될 수 있다.신뢰할 것인가 통제할 것인가 는 마이크로매니저에게 중요한 문제다. 업무가 제대로 처리될 거라 믿지 못하거나 당신이 정한 기준으로 결과물을 엄격하게 통제하려 할 때 마이크로매니지먼트를 하게 된다. 이런 상황은 뛰어난 개발자가 특히, 기술적으로 자부심이 강한 개발자가 팀장이 될 때 자주 일어난다.팀에서 당신의 가치가 당신이 잘하는 코딩에서 아직 잘 모르는 사람관리로 바뀌었다면, 팀원들을 자신의 분신처럼 다루고 싶을 수도 있다..

프로젝트 관리란 복잡한 최종 목표를 작은 일로 나누고, 이 일을 끝내기 위한 가장 효과적인 순서로 배치하고, 병행 처리할 일과 순차 처리할 일을 찾아내고, 프로젝트 진척 속도를 늦추거나 실패하도록 하는 것을 찾아서 제거하는 일.이는 불확실성을 해결하고, 미지의 것을 찾으려고 노력하며, 진행 과정에서 실수는 없는지, 최선을 다했지만 놓친 건 없는지를 알아채기 위해 하는 것. 다음은 프로젝트 관리에 도움이 되는 몇 가지 가이드라인.작업을 작게 나눈다.스프레드시트나 간트 차트 또는 무엇을 쓰든지 우선 큰 성과를 낼 수 있는 업무를 작은 업무로 나눈다.큰 단위의 작업에서 시작해 더 작은 단위로 나누고, 이를 더 작은 단위로 나누는 일을 반복.이 작업을 혼자 다 할 필요는 없다. 잘 이해되지 않는 부분은 잘 아는..

단일 책임 원칙(single responsibility principle) SRP클래스와 모듈은 하나의 책임 또는 기능만을 가지고 있어야 한다는 설계원칙거대하고 포괄적인 클래스를 설계하는 대신, 작은 단위와 단일 기능을 가진 클래스를 설계해야 한다.클래스에 비즈니스와 관련 없는 기능이 두 개 이상 포함되어 있으면 책임이 단일하지 않으므로, 단일 기능을 가진 여러 개의 작은 클래스로 분할되어야 한다고 생각할 수 있다. 예를 들어 어떤 클래스에 주문 관련 코드와 사용자 관련 코드가 모두 포함되어 있다면두 기능을 동일한 클래스에 넣는 것은 단일 책임 원칙에 위배된다.단일 책임 원칙을 충족하기 위해 이 클래스를 더 작게 세분화하여 단일 기능을 가진 두 개의 클래스로 분할해야 한다.클래스에 단일 책임이 있는지 판..