개발은 찍먹하고 끝낼게 아니기 때문에 -> 마라톤이 아니기 때문에
주변에서 멀어질것 같은 느낌이 든다. -> 타인과의 비교
과정 속에서는 그 격차가 크게 느껴진다.
멘토님은 결핍을 성장의 원동력으로 삼았다.
언젠가 지치는 일이 생겼다
돌이켜보니 큰차이라고 생각했던게 별로 큰 차이가 아니더라
만약 과거로 돌아간다면 지치지 않는 것에 포커스를 맞추려고 할 것 같다.
순간순간의 벌어짐을 너무 의식하지 말자.
공부를 어떻게 해야 빠르게 성장하지? -> 나에 대한 사용법, 생각들을 정리 : 내가 꾸준하게 공부할 수 있는 방법
Html css js 가 쉬울때, 다른 컨셉에 대한 공부를 한다던지, 발표를 한다던지, 블로그를 쓴다던지, 깜지 써본다던지
나에게 효과있는 방법들을 모색하기
이 얘기를 왜 하냐 -> 너무 지금 자신에 대한 책망을 안했으면 하는 바람에서
진짜 책망은 ~할걸 이라는 말이 계속 나올때 하자.
너무 자기에 대한 기대치가 높아지면 장기적인 학습에 악영향이 갈 수도 있다.
당근마켓은 현재…
백3프1 프1백2 정도의 밸런스
전체적으로 백엔드 수요가 많아서 백엔드를 많이 뽑는다.
작년-> 왠지 필요할것 같다… 지금->필요해야 뽑는다.
현실정 프3백3-> 프론트 사람들은 백엔드 찍먹, 기획, 기술적 고민등을 하고있다.
해커톤에 일가견이 있으시다.
https://speakerdeck.com/eastroots92/gdg-2022-hackathon-haekeoton-sayongseolmyeongseo
한해목표-> 해커톤 한해에 10개 참여해보기 해외도 갔다.
해커톤 키포인트
1.선택과 집중->시간이 없어서 완성을 못하고 끝나는 경우가 부지기수
성공 시나리오만 구현하기, 일부 데이터만 구현하기(a-z > a-c)
2.새로운 도전, 나중 생각하지 않기 -> 생각보다 시간이 없기 때문에 익숙한 것으로 진행
코드에 대한 고민은 사치
3.발표 아이디어에 임팩트 주기-> 기술적인 것보다 아이디어적인 부분에 집중을 하자
코드를 우아하게 짰는가 이런건 평가 x
4.코드는 같이 짜는것이다.
5.즐기기
커피챗 미리 고려하면 질, 효율 향상을 이룰 수 있다고 생각
새로운 사람이 입사 -> 이것저것 질문 (기대하는 부분, 필요로 하는 상황, 주로 어떤 고민을 하고있는지,
cto에게 질문 cto가 기술에 대한 고민을 현재 하고있다면, 뭔가 상황이 애매하다고 느낄 수 있다.)
회의 같은것도 마찬가지 -> 간단한 정리를 공유하면 효율 향상을 도모할 수 있다.
알고리즘 레벨을 어디까지 끌어올려야 하는지는 모르겠고, lv2는 수월하게 풀어야 하고
2-3정도 왔다갔다 하면서 풀면 준비는 되어있지 않을까
회사마다 주로 나오는 패턴을 조사하는게 도움이 된다.->정보력이 없다면 커뮤니티에 질문(오픈카톡, 링크드인, 커피챗(유료)등등)
cs지식이 실무에서 쓰이는 사례
대표적인거: 큐-> 이벤트 하다보면 자연스럽게 이벤트 루프 마이크로 태스크 큐
이벤트 로깅 시스템->신상정보 initializing->싱글톤 패턴
노션만들기-> 사이드바, 글쓰기, 제목 등등 -> 리덕스 쓰겠다 -> 옵저버 패턴
카카오톡 -> 프록시 패턴
효율이 중요하다면 실무에서 많이 쓰인다.
Hooks useState 등등 -> 콜백패턴, 큐
패턴을 알고있으면 깊이가 깊어진다.
팩토리얼 패턴
회사출근하고 루틴
자신만의 사이클을 만들려고 노력
출근하고 나서 집중하기 까지의 예열이 필요
- > 조금 집중력을 덜 요구하는 일들을 출근하고/밥먹고 처리
Ex)코드리뷰…
혼자서 컨트롤 가능한 일
- > 서버, 다른팀과의 연계는 개인이 핸들링하기 힘듦
- > 비동기로 일들을 처리
- > 응답이 오면 중요도에 따라 처리
회의를 대부분 몰아서 잡으려고 노력
- > 중간중간 비어있는 시간이 생기면 집중력 저하
핵심은 나 혼자서 할 수 있는 일들을 처리할 시간을 벌기 위해
불확실->확실한 이벤트로 바꾸려는 노력
아이디어의 시작
문제의 정의-> 동네 사람들을 가까워지게 하고 싶다.
- > 가까워 지려면 오프라인 만남이 최고
- > 그러려면 어떻게 오프라인 유도?
문제 발의-> 고민 -> 해결 -> 발의 -> 고민 ->해결->….
이 과정들을 머리를 맞대고,,,
비대면근무에 대한 생각
완전히 없어지진 않을 것 같은데 좀 줄어들 것 같다.
집에서 하면 -> 구분이 안돼서 -> 좀 늘어짐
오프/온 섞이면 커뮤니케이션 효율이 떨어진다고 생각
무조건 오프가 최고, 온이 최고는 아님
결국 상황에 따라 유연하게 대응하는 회사가 많아질 것 같다
현재 추세는 국내외 모두 출근으로
모두가 집중을 할거라는 보장이 없을 수 도 있다.
좀 치는 주니어 개발자란?
좋은개발자의 정의는 다 다르다:어려운 문제 푸는 개발자, 서비스를 잘풀어내는, 팀의 시너지 등등…
상황따라 좋은 개발자의 정의가 다를 수 있다.
하지만, 바뀌지 않는 확실한 부분은 https://github.com/jorgef/engineeringladders
Lv을 대충 보면 커리어가 대충 보임
Ex)뱅셀에 sde2정도 레벨 면접 : 주니어 정도의 등급/경험
위의 사이트에서 확인 가능
기술,영향,시스템,협업능력,처리 등등의 역량 고려
잘하는 개발자란 신입때 잘하는 주니어 개발자 : 아는건 안다, 모르는건 모른다, 어떻게든 해내려고 하는 자세(간단한 피쳐)
준니어 : 스스로 피처 쳐내기, 규모가 있는 플젝 가능, 주니어 인턴 컨트롤
리더 : 앱운영 전반적인 방향 제시
개발하다 스트레스 받으면
유튜브, 산책,
요즘은 멘토링, 지식전달
요는 개발과 별개의 행동을 하는것?
옛날에는 거창한 방법/취미가 있어야한다고 생각했는데 -> 고민 과정이 너무 스트레스
코드리뷰를 하는데에 중점
- 코드리뷰에 대한 목적이 명확해야 함, 서로가 얼라인 되어있으면 좋음
현재는 서로의 생각을 엿보며 공부하기 위한 목적이 크다
팀원끼리 서로 어떻게 리뷰 받았으면 좋겠는지 얘기를 해보면 좋다
멘토님은 본인의 관점에서 의도 개선 방향등을 물어보실 것 같다
- 좋은리뷰를 위해서는 좋은 질문이 필요 https://xyproblem.info
최대한 상황을 자세하게 설명해서 답변의 모호성을 제거
맥락, 목적, 의도를 잘 설명
코드리뷰는 감정이 드러나지 않음 -> ex) 만약 멘토님이 “코드 왜 이렇게 짜셨어요”라고 하면 좀 불안할 수 있다