Table of contents
오늘 한일
백준 DP: 타일 채우기, 파도반 수열
타일 채우기는 26일날 해결을 못해서 오늘 다시 풀어봤다. 두번째 도전인데도 점화식을 세우질 못해서 다른 사람의 풀이를 참고했는데, 풀이마저도 조금 어렵다. 각 단계마다 2개의 고유 조합이 있는 것은 알겠는데, n - 4, n - 6 등 모든 단계와의 조합을 고려해야 한다는 것이 이해되지 않았다.
작은 문제로 쪼개서 풀이를 해준 블로그 포스팅이 있었다. 처음에는 이 풀이도 이해되지 않았으나, 계속 읽어보니 어느 순간 이해가 가더라.
파도반 수열 문제는 문제에서 나온 예시만으로도 점화식을 세울 수 있다. 굉장히 쉬운 편에 속하는 문제인 듯.
이력서 피드백 반영
소프트웨어는 특정 문제를 해결하기 위해 존재한다. 회사에서 수주하는 프로젝트도 마찬가지다. 이력서를 읽는 사람의 입장에서 이 프로젝트가 어떤 프로젝트인지, 왜 시작되었는지를 알 수 있어야 한다. 고로 각 항목은 프로젝트 소개, 프로젝트 계기(기존 업무의 문제점) 혹은 목표를 설명하는 것으로부터 시작한다.
프로젝트 소개를 끝냈다면, 기술적인 관점에서 본인이 기여한 부분을 설명해야 한다. 문제를 해결하기 위해 혹은 프로젝트를 수행하기 위해, 무엇을 개발했고 어떻게 개발했는지에 대한 내용이 필요하다. 예를 들어 개발환경 설정, 서버 구축, 모니터링 환경 구축 등을 수행했다면 이러한 환경을 어떻게 구축했는지 설명해야 한다.
웹 개발자라면 어떤 화면이나 어떤 기능을 개발했고 어떻게 개발했는지에 대해서도 설명해야 한다. 개발하면서 업무의 대부분이 SQL 작성이었다면 쿼리를 구현한 방법을 포함해야 한다.
프로젝트에 참여하면서 경험했던 어려움과 이를 해결하기 위해 노력한 부분이 포함되면 더 좋다. 우리는 개발자이므로 커뮤니케이션적인 어려움보다는 기술적인 어려움에 대한 내용을 포함시키는 것이 이상적이다.
이제 사용자의 피드백과 구체적인 성과를 제시할 차례다. 사용자가 이 소프트웨어를 사용하면서 어떤 장단점을 느꼈는지 알 수 있어야 한다. 그리고 이를 증명할 근거로 구체적인 성과를 제시해야 한다.
마지막으로 이 프로젝트를 통해 기술적으로 배운 점과 느낀 점을 설명해야 한다. 반드시 본인이 느낀 점을 사실에 기반하여 작성해야 한다.
다음은 부가적인 피드백이다.
- 한 문장에 머릿속에 있는 걸 다 쓰지 말아라.
- 여러 문장으로 쭉쭉 적으면 된다.
- 중복이 없고 단순해야 한다.
- 처음엔 최대한 모든 내용을 적는다.
- 나중에 정리하면 됨
- 어려운 점은 어려운 점만 모아놓는 것이 좋다.
- 굳이 사수가 없는 환경이 어려웠다는 점을 알려줄 필요는 없지 않나?
- 이런 어려움을 통해서 어떻게 해결했고 무엇을 배웠다가 중요
- 기술적인 어려움이라면 모르겠음
- 결론은 개발자 관점에서 체계적으로
- 서론 본론 결론의 구조가 자연스럽게 이어지도록
이 내용을 기반으로 각 항목을 다시 작성하는 중이다. 키워드를 마인드맵처럼 나열해놓고 참고해가면서 작성하려고 한다.
오늘 느낀점
클린코드와 관련된 포스팅들을 읽다보면 글쓰기와 코딩이 비슷하다는 이야기가 많다. 이전까지는 독자에 상관없이 포스팅을 작성해서 잘 몰랐다. 그런데 독자를 의식해야하는 이력서를 작성하다보니, 많은 부분이 비슷하다는 것을 느낄 수 있었다. 특히 '중복이 없고 단순해야 한다는 관점'에서 비슷한 것 같다. 글쓰기나 코딩이나 중복이 심하면 내용이 길어지고 복잡해진다. 분야를 막론하고 더 좋은 기술자가 되기 위한 첫 걸음은 중복을 제거하는 것이라고 생각한다.
내일 할일
- 백준 DP 2문제 풀이
- 이력서 피드백 반영