- Habits maketh engineer — collaboration
- Eight Habits of Expert Software Designers: An Illustrated Guide
- Habits I've Developed for Fast + Efficient Programming - Casey Primozic's Homepage
- 흔하지 않은 웹 개발자가 되는 방법
- 어썸데브블로그
- awesome-blogs: 한국에 있는 좋은 개발자들의 블로그들을 편리하게 구독할 수 있도록 하나의 주소로 묶어서 RSS 피드로 제공해줍니다
- SHIPSTREAMS - A list of makers shipping live
- 인디 개발자들이 서비스 릴리즈를 위해 프로그래밍하는걸 스트리밍
- 해당 스트리머들을 모아놓고, 그들이 제작, 빌드하는 사이드 프로젝트를 간략하게 소개
- 사이드프로젝트 개발부터 배포까지의 경험기 | Fernando 기술 블로그
- 개발자라면 무조건 해야 하는 '이것'?- 사이드프로젝트!
- 월 $500 이상 버는 사이드 프로젝트가 있나요? 2024 | GeekNews
- 분노 주도 개발(RDD)로 시작하는 사이드 프로젝트 | 요즘IT
- PyCon Korea 2025 발표 "RDD(Rage-Driven Development)" 정리, RSQUARE 데이터 엔지니어 김혜원. 프로그래밍의 본질은 문제 해결이므로 "개발해야 하는데…"는 "해결해야 하는데… 무엇을? 왜?"와 같고, 풀고 싶은 문제가 불분명하면 사이드 프로젝트가 시작도 지속도 어려움—사회문제에 대한 분노를 동력으로 만든 여성혐오 뉴스 아카이브 'Leave Her Alone' 프로젝트 경험과 지속 가능한 사이드 프로젝트·시빅 테크에 대한 배움
- Programmers: Before you turn 40, get a plan B
- How to increase your value as a developer
- TNF 10년, 블로그를 사랑한 물리학자 – 신정규 인터뷰
- 조대협의 블로그
- Moxie Marlinspike: The Coder Who Encrypted Your Texts
- 관리자급 개발자가 되기 위한 자세
- Year Of Programmers 개발자, 일 년간의 회고
- 독학으로 컴퓨터 배워 '아이폰 앱' 개발한 81세 할머니
- 내가 StackOverflow를 사용하는 방법
- 046.016 컴퓨터과학이 여는 세계
- 30년간 개발자로 살면서 배운 것 Lessons From A Lifetime Of Being A Programmer
- 가장 똑똑한 소프트웨어 엔지니어에게 배운 10가지 교훈 | 요즘IT
- 똑똑한 개발자와 현명한 개발자
- 11 Pieces Of Advice For Programmers | by Daan | Level Up Coding
- All the best engineering advice I stole from non-technical people | by Marianne Bellotti | Medium
- Advice From a Software Engineer With 8 Years of Experience | by Benoit Ruiz | Better Programming
- 21 lessons I wish I’d known earlier in my software engineering career. | by Harsh Makadia | Geek Culture | Medium
- 실리콘밸리 전설들의 수다: Masters of Scale
- 좋은 엔지니어링 기회 자체가 불평등하다
- 연차가 쌓일 수록 익숙해져야하는 5가지. 주니어이지만 주니어이고 싶지 않은 프론트엔드 5년차 개발자 | by FlyingSquirrel | Apr, 2023 | Medium
- Letter to a Junior Engineer
- 비전공 저연차 개발자가 할 수 있는 실수 | zero-base 비전공 저연차와는 사실 무관. 그냥 일을 잘 하기 위해 필요한 부분
- 프론트엔드 엔지니어 커리어 로드맵: 주니어를 위한 3가지 전문성 트랙
- 프론트엔드 엔지니어의 커리어 성장과 관련해서 여러 사람과 얘기해 보면서 생각 정리
- 로드맵에 대한 글이나 다이어그램이 꽤 있는데 이 글은 오랫동안 고민하고 공부한 티가 날 정도로 잘 정리
- 탁월한 엔지니어는 "좋은 코드를 짜고" "작업의 현재 가치를 극대화하고" "데이터 기반으로 의사결정을 하고" "동료의 효과적 의사결정을 도우며" "꾸준히 학습"한다
- 탁월한 프론트 엔지니어를 웹 특화, 제품 특화, 운영 특화로 나누어서 어떤 특징이 있고 어떤 역량이 필요한지를 정리
- 인프콘 2023 발표 1. 무엇이 탁월한 개발자를 만드는가
- 주니어 개발자를 위한 조언 · Present
- 주니어 개발자들이 읽으면 좋은 테크 아티클 모음
- 성장하는 엔지니어가 되는 법: 주니어편 | Novemberde's Blog
- Ask HN: 배울 수 있는 훌륭한 시니어 없이, 엔지니어로 어떻게 성장할 수 있을까요? | GeekNews
- AI가 없앤 주니어, 누가 미래의 시니어를 키우나 - CIO Korea
- AI 자동화로 주니어 채용이 줄면서 미래의 시니어를 키울 육성·멘토링 시스템이 위협받음. 주니어를 AI로 대체하기보다 AI로 성장을 가속해 숙련 엔지니어로 키워야 한다는 제언
- Everyone Is Hiring for Judgment. Nobody Is Making It Anymore. | The AI Corner
- 😰신입 채용 공고에 '10년차 판단력 필수'. 근데 그 판단력, 누가 만들어 주는데? | 원대로 | EO 플래닛
- PwC가 10억 건+ 채용 공고를 분석해 붙인 이름 '시니어화(seniorization)'—AI 노출이 큰 직종의 신입 공고가 예전엔 경력 10년쯤에 요구하던 역량(전략적 판단·이해관계자 관리)을 요구할 확률이 7배. Indeed Hiring Lab 기준 2026년 5월 미국 시니어 공고 전년 대비 +14.7%·신입 −7.5%(소프트웨어 공고 10개 중 7개가 시니어), Harvard 워킹페이퍼(28만 기업·6,600만 명)는 생성형 AI 도입 기업이 주니어 채용을 줄이고 시니어를 늘렸음을 확인, AI 노출 큰 직종의 20대 초반 취업자는 약 16% 상대 감소
- 핵심 논지—실행이 싸지면 가치는 판단으로 옮겨가는데, 판단력을 배우던 견습 현장(주니어가 초안 쓰고 상사가 고치는 걸 옆에서 보는 2~3년)이 바로 AI로 자동화된 자리라는 역설. 이 틈을 '조직 역량 부채(capability debt)'라 부름—기술 부채처럼 장부에 안 잡히다 어느 분기 청구서가 날아옴. 채용 필터는 좋아졌지만(Canva는 면접 질문을 '뭘 했냐'→'어떻게 알아냈냐'로, ElevenLabs는 연차 요건을 거의 폐기) 그 필터를 쓰는 회사들이 '다른 데서 주니어를 계속 길러주겠지'라는 말 없는 가정에 올라타 있다는 지적
- 대안은 신입 자리 재설계—초안은 덜, 검증은 더(미디어 에이전시 Brainlabs는 사내 아카데미를 AI 중심으로 개편해 신입 코호트를 19명→64명으로 237% 확대, 로펌들은 초안 작성 대신 모델 결과물 검증·워크플로 관리 쪽으로). 다만 eopla 해설이 짚는 닭-달걀 문제—틀린 걸 알아보려면 판단력이 필요한데 그건 반복 훈련으로 생기는 것이라 "달걀 낳던 닭부터 잡아먹은 형국". 원문에 Outskill 워크숍 유료 광고 포함
- 개발자 직군별 채용 트렌드 (2026년 9월)
- 채용 플랫폼 27곳의 개발 공고 1만여 건으로 본 주요 8개 직군의 기술 스택·AI 요구·경력 조건—AI 엔지니어가 직군 2위로 부상, 백엔드는 Java 57%, 크로스플랫폼은 Flutter가 React Native를 앞섬
- Stop Being a Junior
- (번역) 주니어가 되는 것을 그만두세요
- 회사에서 주니어라고 부르고 본인도 주니어라고 생각할 수 있지만
- 기술의 발전은 빠르기 때문에 새로운 기술에 대해서는 새로 시작한 사람이 더 빠른 시간안에 높은 수준까지 올라갈 수 있음
- 너무 나서는 건 좋지 않지만, 적극적으로 기회를 요청하고 동료들에게 예의를 갖춰서 더 많은 기회를 가져서 주니어라는 타이틀을 벗으라는 이야기
- 회사에서 주니어라고 부르고 본인도 주니어라고 생각할 수 있지만
- (번역) 주니어가 되는 것을 그만두세요
- 노마드 코더 Nomad Coders
- 꾸준히, 자유롭게, 즐겁게 - 한국 오픈 소스 개발자들 이야기
- ‘자극이 필요한’ 개발자를 위해 엄선한 국내 포트폴리오 & 개인 블로그 7선
- 왜 45세 정년이 될 수 밖에 없는가 (기술기업의 관점에서)
- Theory Z Teamism, Theory A Open Allocation
- NDC22 '게임업계 최초 정년퇴직자'가 말하는 커리어 관리
- An Old Hacker's Tips On Staying Employed - by Mad Ned - The Mad Ned Memo
- The One Who Kept VLC Free
- The Product-Minded Software Engineer 제목 그대로
- 좋은 엔지니어가 되기 위해 필요한 조건들 Starbucks Principle Enginner 오창호님
- 좋은 소프트웨어 엔지니어가 되려면? - Prev's Blog
- 누구나 원하는 개발자되기
- 코더 | Human-Computer Symbiosis 잘하는 개발자의 조건
- How To Be A GREAT Programmer - YouTube
- 배달의민족 CEO가 말하는 함께 일하고 싶은 개발자의 기준
- 일 잘 하는 개발자는 왜 비즈니스까지 신경쓸까? | Evans Library
- 일 잘 하는 개발자는 왜 비즈니스까지 신경쓸까? | 요즘IT
- 쉽게 살 수 있을까 ? :: 소프트웨어 개발자가 되기 위해 발을 내딛으신 분들에게
- 문제 해결 능력에 앞서 문제 정의 능력이 중요하다. - F-Lab
- 개발직군이 놓쳐서는 안될10가지 (Developer attitude) 개발외에 주의해야할 점
- Amazon을 이끄는 기술 구루 – Distinguished Engineers
- ‘Go to guy’: 회사에서 가장 인정 받는 인재
- 21 Bad Mistakes in My 21-Year Programming Career 짧고 간단하게 좋은 이야기를 많이 씀
- 100 of the Best Engineers, Developers, Coders, and Entrepreneurs to Follow Online
- 프로그래머는 왜 이리 까칠하게 행동할까?
- Maker's Schedule, Manager's Schedule
- Maker’s Schedule vs Manager’s Schedule | by Joon Won Lee | DelightRoom | Jan, 2023 | Medium
- 8년 간의 개발자 생활 회고 (1) | Hello, There
- 8년 간의 개발자 생활 회고 (2) | Hello, There
- 8년 간의 개발자 생활 회고 (3) | Hello, There
- Awesome-Profile-README-templates: A collection of awesome readme templates to display on your profile
- 4 Signs of an Inexperienced Developer | by Daan | Aug, 2020 | Level Up Coding
- 4 Ways to Earn Additional Income as a Programmer | by Daan | Level Up Coding
- 3 Mental Models for Coders | by Tyron Jung | Better Programming
- 인프런 - 주간 인프런 #22 여기 40년 경력의 개발자가 있다
- 서버 개발자는 무엇부터 학습 해야할까 - 프레임워크, Git, SQL, Linux? - YouTube
- The New Way to Learn - by Sahil Bloom - The Curiosity Chronicle
- 몸으로 배우기 프로그래밍 이야기는 아니지만 학습 방법에 대한 관점에 동의
- 개발자의 학습과 성장 · Present
- How To Learn Stuff Quickly
- 진짜 똑똑한 사람은 이렇게 공부합니다 - YouTube
- 성장하는 개발자가 되는 사고방식
- 개발자의 성장 가능성은 어떻게 측정 가능한가?. 간혹 신입 개발자를 채용한다는 회사의 이야기를 듣다보면, 나를… | by 조은, John Cho | Jul, 2022 | Medium
- 지속가능한 개발자 성장 스킬 5가지
- 일의 난이도 높이기 성장
- 인풋 말고 아웃풋
- 못하지 않는 개발자 되기 - 신입용 - YouTube
- 개발자로 살아남는 "진짜" 방법
- 쉽게 살 수 있을까 ? :: 개발자 성장에 대한 강연.
- 당신이 성장하지 못하는 이유 | 요즘IT 일찍 자주 실패하라
- 그 때 성장이라고 생각했던 것들 | JBEE.io
- The case against CS master’s degrees
- 2022 Workplace Learning Report | LinkedIn Learning
- AI가 모든 답을 아는데 왜 공부할까? 실리콘밸리를 사로잡은 드와케시의 학습 철학
- High School Dropout to OpenAI Researcher - Gabriel Petersson Interview (Extraordinary) - YouTube
- 고등학교 중퇴자가 OpenAI 연구 과학자가 되기까지: 가브리엘 페테르손의 성공 비결과 AI 학습 전략
- 고졸 출신이 OpenAI 연구원이 된 이야기 (정말 많이 공감되는 AI 시대 학습법) 스웨덴 시골 마을 고등학교 중퇴자가 어떻게 최고의 기업인 OpenAI, 그것도 Sora 팀의 연구원이 됐는지 가브리엘 피터슨이 직접 그 비결을 풀었습니다. AI 시대에 어떻게 변화해서 학습하고, 앞으론 어떻게 커리어를 쌓아야 하는지에 대한 "진짜 공략집"입니다.… | Jaeyun Henry Lee | 12 comments
- 최두옥 - 가장 빠르게 전문가가 되는 법, 딱 세줄. ㅤ 첫째, 구체적인 프로젝트를 정하고 끝까지 완성한다. 필요한... | Facebook
- How AI assistance impacts the formation of coding skills \ Anthropic
- How I use AI to learn engineering (anti brain rot studying) - YouTube
- 엔지니어링 개념을 시각화·CAD로 만들기, AI로 학습 자료 필터링·리소스 발견, 핵심 20% 파악. 프롬프트·템플릿·자료 공개. Aleks Gornik, 12분 42초.
- How To Become Dangerously Self-Educated With AI (for free) | Sandeep Swadia - YouTube
- MIT 출신 CEO의 AI 독학법, 직접 해보니 기초 없던 수학 A+ (With, 필요없는 것을 뺀 나만의 방식) | 평균밖성원 - YouTube
- 수도승 수련생→MIT→테크 CEO(한국어 영상에서 광고 사기·봇 탐지 보안사 White Ops CEO로 확인) Sandeep Swadia의 "university in a box". 세계 최고 대학 인턴 120명 중 AI를 하루 30분 쓰는 사람은 1/4, 인스타그램은 전원이라는 격차에서 출발. AI에게 5가지 역할—Advisor(목표·현재 수준·순서·버릴 것·배웠다는 증거의 5가지 결정을 AI가 나를 인터뷰해 정하게 하고 나만의 커리큘럼), Librarian(수천 자료 중 볼 가치 있는 소수만 선별), Tutor(이해의 정확한 빈틈을 찾는 심야 과외), Editor(칭찬 대신 결과물을 압박 검증), Roommate(혼자선 안 갈 분야로 끌어들여 새 관점). 조회수 125만+, 21분
- 평균밖성원: 위 방식으로 공부해 기초 없던 수학 과목 A+. 다만 역할 5개로 나누는 건 복잡—이제 에이전트가 말만 하면 알아서 판단하므로 자기 방식은 Grok·Gemini에 이해될 때까지 질문 → 대화 전체를 세컨 브레인 볼트에 연결된 Claude Code에 던져 나를 아는 맥락(생긴 맥락·원리·앞으로의 쓰임 중심)으로 정리 → 그 정리를 NotebookLM에 넣어 리포트·슬라이드·영상 개요로 입체적 이해(평평한 개념 나열을 구글 지식 그래프식 정보 위계로). 왜 한국에 퍼지지 않나—Bloom의 2 Sigma(과외받은 학생이 98%를 앞섬)를 이제 월 3만 원(대학생은 Gemini 1년 무료)으로 24시간 누릴 수 있는데, 교사 1명:학생 30명 시대의 순차 교육 규칙이 이유가 사라진 뒤에도 남은 '원숭이와 바나나' 관성, "인간은 전체를 기획하지 않는다"(사피엔스), 대가가 죽어야 학문이 발전한다는 논문—주류가 아니어도 맞다고 판단되면 새 방식을 시도하라
- How to keep enjoying programming in a world of LLMs | Manuel Bärenz (turion) - Haskell Discourse
- LLM 시대에도 프로그래밍을 계속 즐기는 법 | GeekNews
- LLM 시대에도 프로그래밍의 즐거움과 개발 주도권을 지키는 방법 | digitalbourgeois
- Haskell 프로그래머 Manuel Bärenz의 글(2026.9.18, 조회 5.3만·좋아요 71, "AI 도움 없이 100% 사람이 썼다"고 명시). AI 번아웃, 프로그래밍 실력은 없고 Claude 계정만 큰 사람에게 일자리를 잃을 불안, 내 코드 품질에 대한 실망이 있는 사람을 위해—Sean McMullen의 소설 「Souls in the Great Machine」처럼 개발자가 행위자에서 기계의 톱니로 격하되고, 명세를 받아 LLM에 때려 넣다 테크노봉건 영주가 토큰을 줄이면 우는 'spec-driven dystopia'를 거부. 핵심은 코드를 계속 내가 쓰는 것—전부 생성하게 두면 코딩 에이전트만 살 수 있는 'LLM 황무지'가 되고, 몇 주만 안 쓰면 직접 코딩으로 돌아오기 어렵고, LLM은 광고만큼 사람이 읽기 좋은 코드를 못 쓴다. 생산성은 코딩이 아닌 거의 모든 다른 일에서—장부 정리로서의 계획(도메인 전문가 대화를 todo로, 프런트매터 마크다운으로 추적, 중대 결정은 내게 묻게 하고 질문이 이해 안 되면 LLM이 맥락을 안 준 것), 조사(에이전트가 조사하는 동안 커피를 타거나 더 좋게는 검색엔진으로 병행 조사해 에이전트가 아는 건 나도 알기, 결과엔 출처 링크를 남기게 하고 이상한 제안엔 "어느 자료가 그렇게 말하나"를 물으면 50%는 스스로 오류 발견), 그리고 'You are the coder'—plan first then agent codes를 거부하고 함께 계획한 뒤 코딩은 내가(에이전트는 코드베이스 조사·수정 위치·함정·배경 자료 준비, "귀찮은 프로세스 없는 애자일"). 에이전트는 정리·소규모·저위험 리팩터링·FIXME·미유지보수 라이브러리 교체에만—흥미로운 케이스 3개를 쓰고 비슷한 7개를 맡기려 든다면 사실은 추상화(렌즈·Traversable)할 때이고, 호출 체인을 LLM이 찾아줘야만 한다면 코드베이스 조직이 나쁘다는 신호
- GAN의 생성기/판별기처럼 자동 리뷰 사이클 없이는 LLM 산출물을 받지도 읽지도 말 것—코드뿐 아니라 계획도(todo 7에서 만들 함수를 todo 2에서 리팩터링하는 식의 논리 구멍), 리뷰 에이전트가 더 찾을 게 없을 때가 '사람 눈에 보일 자격'이고 내 코드 리뷰에도 유용. "프런티어 모델을 과소활용한다"는 비판엔 "그게 논리적 결론"—환경 비용, 나보다 똑똑한 척하는 것에 신뢰를 쌓기 어렵고 코드 책임은 기계가 아닌 내 것, 고급 모델은 토큰을 많이 써 세션 안에 끝날지 불확실, 작은 모델로 되는 워크플로는 언젠가 오픈 웨이트로 갈아타 테크노봉건 영주 의존을 끊을 수 있음. 토큰 소진은 '적게 산 내 탓'이 아니라 서비스 장애—세션 토큰 한도는 불투명하고 예고 없이 바뀌므로 기차·비행기 오프라인처럼 대비해 모든 것을 유형의 산출물로 남기고 늘 직접 할 todo 목록을 확보. LLM 횡설수설은 정신 건강에 유해할 수 있으니 리뷰 에이전트가 다듬은 뒤에만 읽고 사람과 코드 얘기를 계속, 머리가 돌면 에이전트가 돌고 있어도 휴식. PR·이슈·커밋 메시지는 사람 사이의 소통—통째로 생성한 PR을 보내지 말고(실수로 보냈다 상대가 질린 경험) 생성 텍스트는 벤치마크 수치처럼 손으로 쓴 본문 뒤
<details>에. 결과는 LLM 없을 때보다 '아마 2배'—바이브 코더의 자랑보다 작지만 "밭에 공업용 화학약품을 퍼붓는" 대신 "순한 유기질 비료를 쓰는 정원사"가 더 지속 가능하다는 입장. 댓글—enobayram "LLM 횡설수설이 두뇌의 석면이 아니길", hasufell "AI 사용 패턴이 다른 엔지니어를 한 팀에 섞고 리뷰는 non-AI 사용자에게", tomjaguarpaw는 반대로 "LLM을 잃으면 어떻게 즐기나"였지만 글의 제안 대부분을 이미 따르고 있었다고
- 앨리스의 수다 라방 - YouTube
- 드림코딩 by 엘리 - YouTube
- Effective Engineer
- 개발자 부업, 어디까지 해봤니? - 코드쓰는사람
- 1. 우아한형제들 부검 - 왜 떠나는지
- 퇴사 부검 | 우아한형제들 기술블로그
- 2. 우아한형제들 부검 - 어디로 가는지
- 욕 안 먹는 개발자되기 · shiren the creator
- 1억 글로벌 서비스를 만들며 배운 것들 2 디자이너 이야기이지만 읽어볼만 함
- 신입 개발자로서 도움이 된 포스트/자료 모음
- 쏘카 안드로이드 팀 신입 개발자 미뇽의 입사기 - SOCAR Tech Blog
- 기업들이 신입개발자를 뽑지 않는 이유 – IT의 중심에서
- 신입 개발자가 알면 좋은 개발 외적인 개념
- Here’s Peter Norvig’s Advice to New Programmers. It Should Not Be Ignored | by Somnath Singh | Dec, 2021 | JavaScript in Plain English
- Why I prefer making useless stuff - Austin Z. Henley
- System Compleat. System Compleat. Singapore DBS 근무
- 왜 개발자는 잘못된 기술 선택을 밥 먹듯이 하나?
- How to drive away your best engineers. | padraigobrien.com
- 소프트웨어를 만들지 못하는 관리자 고용
- 과도한 관리자를 고용하고 계층 생성
- 가능한 많은 회의
- 고통스러운 소프트웨어 정의 과정
- 어려운 소프트웨어 딜리버리
- 엔지니어가 작업을 추정
- 아주 작은 팀
- 다른 팀에서 엔지니어를 빌림
- 방향성이 명확한 노력으로 나만의 색깔을 가진 사람이 되기 | Evans Library
- F-Lab이 생각하는 좋은 멘토의 모습 - F-Lab mentor
- 쿠팡 엔지니어링의 멘토십 프로그램. 직원의 성장을 돕는 사내 멘토십 프로그램을 소개합니다 | by 쿠팡 엔지니어링 | Coupang Engineering Blog | Oct, 2022 | Medium
- "혼자 성장하는 개발자는 없다" 멘토가 필요한 이유 | 요즘IT
- 인프런 수습 회고 개발팀이 개발만 하면 망한다
- Celebrating Grace Hopper and the Origins of Debugging | Bugsnag Blog
- How I’ve hit 10k subs on my tech YouTube channel | by Takuya Matsuyama | Dev as Life
- The Art of Debating: A Useful Skill for Software Developers
- Three Sales Mistakes Software Engineers Make sales라고 썼지만 사실 project에도 동일하게 적용할 수 있다
- 개발을 잘 하는 습관
- 잘하는 개발자가 되는 그라데이션 사고법 (추상화 계층과 데이터 흐름 이해하기)
- 협업을 잘하는 개발자가 되어보자 - 프로그래머가 아니라 문제 해결사가 되자!
- 당장 해볼 수 있는 4가지 방법 문제 해결형 개발자가 되려면
- 개발자가 문제 해결 과정에서 마주치는 어려움의 유형 3가지 - 재그지그의 개발 블로그
- Ten years against division of labor in software
- 18 Trends That Will Shape Our Careers in 2022
- Even the CEO of Amazon didn’t have a master plan for his career | LinkedIn 개발자는 아니지만
- Are We Really Engineers? • Hillel Wayne
- The developer's essential knowledge pyramid
- The Painfully Shy Developer's Guide to Networking for a Better Job (Without Being Creepy) 인맥구축
- 지금 연봉 10배가 오릅니다 : '네트워킹 드리븐'으로 일하기 일종의 인맥 이야기
- How to Be a 10x Software Engineer | by Michael Lin | Feb, 2022 | Medium
- 10배 이상 뛰어난 개발자가 되는 법 | 요즘IT
- 10x 엔지니어의 환상을 넘어서
- -10배 엔지니어가 되는 방법 | 요즘IT
- 영리한 개발자와 현명한 개발자의 차이점 | 요즘IT
- The Platform Engineer | By Varun Achar | Razorpay Engineering
- Product and Platform Engineers | Lee Robinson
- 엔지니어를 프론트엔드와 백엔드로 구분하는 것은 점점 의미가 없어지고 이제는 프로덕트 엔지니어와 플랫폼 엔지니어로 구분해야 한다고 주장하는 글
- 프로덕트 엔지니어
- 고객의 문제 해결 집중
- 고객의 피드백을 받고 반복하면서 제품 개선
- 고객 중심으로 생각하며 기술 선택은 목적을 달성하기 위한 수단으로 생각
- 플랫폼 엔지니어는 제품을 만드는 인프라에 집중해서 프로덕트 엔지니어 지원
- ㅈ형 인재가 되어라 - Prologue 모든 사람이 T자형 인재가 될 수는 없다
- ㅈ형 인재가 되어라 - 1편 대체 ㅈ형 인재란 무엇인가?
- ㅈ형 인재가 되어라 - 2편 내 회사의 가치사슬 공백을 찾아라
- ㅈ형 인재가 되어라 - 3편 똑똑한 질문을 하는 방법
- ㅈ형 인재가 되어라 - 4편 공부하는 기획자는 아는만큼 의심하고 질문한다
- Tips 개발자가 질문과 검색을 잘하는 법
- The XY Problem
- XY 문제 진짜 문제를 질문하지 않고, 해결책을 미리 가정하고 질문하는 것
- 내 질문에 답이 달리지 않는다면?
- 천재 파인만이 AI에 질문한다면? | 새로운 관점으로 이끄는 힘 | #지식채널e - YouTube
- 질문도 아키텍처다: CDN으로 배우는 개발자 소통법 | 요즘IT
- 남의 일을 끊임없이 공부해야하는 이유
- 남의 일을 끊임없이 공부해야하는 이유 – 스타트업 스토리 플랫폼 '플래텀(Platum)'
- Subject Matter Expert가 되어라 | zero-base
- FE로 취업하기 전에 알았으면 좋았을 것들 - 코드쓰는사람 제목과 다르게 개발자들에게 일반적으로 적용할 수 있는 이야기
- 2022 프로그래머스 개발자 설문조사 | 프로그래머스
- Developer Survey Results 2017
- Stack Overflow Developer Survey 2021
- Jamstack Community Survey Results 2022 | Jamstack
- What does the work-life balance of a Software Engineer look like? | by Phil from 4 day week | Medium
- complexity is the mind killer
- Thorsten Ball - Professional Programming: The First 10 Years
- 소프트웨어 개발자가 ‘소프트 스킬’ 쌓는 방법 :: Channy's Blog soft skill
- 27년차 실리콘밸리 개발자의 인생 이야기 한기용 1부 - YouTube
- 40대 중반이 돼서야 깨닫고 실천할 수 있게 된 것 한기용 2부 - YouTube
- 이런 얘기를 하면 화내는 사람도 있죠 한기용 3부 최종화 - YouTube
- 개발자 커리어, 무엇이든 물어봤더니 무엇이든 답해줌😎 | 개발자 커리어 클리닉 1편 - YouTube 한기용
- @지난주 목요일 한기용님 x oneononenote Firesidechat
- “좋은 커리어, 자신감에서 나온다”
- 27년차 실리콘밸리 개발자가 ‘10번의 이직’ 후 알게 된 것들
- Noninertial Frame
- 언제 이직할 회사를 고르면 좋을까?
- 2022 SILLY TALK | 한기용 그렙 USA CTO의 “풀타임으로 일했던 12개의 회사썰 모음ZIP” - YouTube
- 한기용 님 특강 @Viva Republica (Toss)
- 멘토링은 어떻게 더 잘하게 되나요? A5. 단순하다. 한만큼 는다. 멘토링을 스케일업 하기 위한 방법을 딱히 찾지는 못했다
- 한기용
- Review Tech Talk - 개발자의 성장 그리고 실리콘밸리 이야기 | Dev.Inn
- 구글 13년 차가 넥스트스텝으로 선택한 야놀자 | 원티드 개인의 이야기와 커리어 이야기가 섞여 있고 일반적인 이야기지만 좋음
- From A Dropout to A Core Contributor to Deno, Here’s The Story of My 10-year Programming Career | by bytefish | Frontend Canteen | Aug, 2022 | Medium
- 대학을 중퇴하고 10년 뒤에 Deno의 핵심 기여자가 된 justjavac (迷渡)의 이야기
- 대학 등록금을 내지 못해서 중퇴, 10,000시간의 법칙을 믿고 프로그래밍 공부를 하다가
- Ryan Dahl의 Node.js 발표를 그를 존경하게 되어 Node.js에 관해 공부
- 이후 Ryan이 Deno를 공개했을 때 관심을 가지고 관련 생태계에 도움이 될 프로젝트를 진행하고 VS Code 확장도 만든 끝에 Deno의 핵심 기여자로 합류
- 지금은 GitHub의 300여 개의 오픈소스 프로젝트를 공개해서 스타 수로 상위 10명 중의 한 명인 개발자
- "Education represents the past, ability represents the present, and learning ability represents the future."
- Developer Imposter Syndrome. Imposter Syndrome을 겪고 계신 많은 분께 이 글이… | by Whatsup | 레몬베이스 (Lemonbase) | Aug, 2022 | Medium
- Build Your Career on Dirty Work | Stay SaaSy
- 5 Signs That You're a Great Developer | JavaScript in Plain English
- 훌륭한 개발자의 5가지 특징 | 요즘IT
- 전설의 프로그래머 형님들의 '찐' 개발 훈수 - YouTube
- 버즈빌 개발자 JD의 개발 성장기 한 장 정리
- 신수정 KT 부사장
- 고급 프로그래머들은 인성 문제있어?
- 공학과 SW 개발의 정의
- 함께 일하고 싶은 사람 - 1. 업무 습관
- 함께 일하고 싶은 사람 - 2. 업무 습관 : 조금더 눈을 높여서
- 함께 일하고 싶은 사람 - 3. 경험들
- 함께 일하고 싶은 사람 - 4. 마음가짐
- 함께 일하고 싶은 사람 - 5. 여담 : 개인적인 팁, 성서
- 프로그래머로 산다는 것 - Google Slides socar CTO 류석문
- 프로그래머로산다는것 확장 - Google Slides socar CTO 류석문
- 리더의 생각(북 콘서트 발표자료).pptx - Google Slides 류석문
- 20 Things I've Learned in my 20 Years as a Software Engineer - Simple Thread
- 프로그래머의 경력을 말아먹는 12가지 방법
- I am a Software Developer: 12 Side Hustles Made me 12K last year | by Nil Lenon | Feb, 2023 | Medium
- How I became a machine learning practitioner
- 프로그래머의 동상이몽
- 넓고 얕게 알기 vs 좁고 깊게 알기 - 재그지그의 개발 블로그 generalist vs. specialist
- How to be a -10x Engineer
- 좋은 프로그래밍은 글쓰기와 닮아있다
- 개발자 양성, 어떻게 할 것인가?
- 19년 차 개발자가 실무에서 맞닥뜨린 기술 이슈들
- 클린코딩 하는데 구현을 못하는 개발자 - YouTube
- 커리어노트 108 커리어는 각자도생이다 : 네이버 블로그
- 8년차 개발자가 월 1억씩 벌게 된 이야기 side hustle
- MODUPOP 초거대 AI시대 대체불가 개발자로 살아가기 - YouTube
- 개발자는 이제 일하는 방식부터 재정의해야 합니다 | 요즘IT
- PyCon Korea 2025 AI 시대에 파이썬 개발자가 쌓아야 할 비파이썬적 소양들 - 오윤명 - YouTube
- AI 시대, 파이썬 개발자가 갖춰야 할 비파이썬적 소양들 문제 정의의 중요성
- 구글에서의 18년을 돌아보며 | GeekNews
- OKKY - 내가 창업을 한다면 어떻게 개발자의 연봉을 책정할 것인가: 비지니스 모델에 따라 다릅니다.
- The 3 budgets | Swizec Teller
- 기술 지식 홍수 속, 개발자는 무엇을 위해 기술을 습득해야 할까?
- 좋은 랜선사수가 없는 이유 (Feat. 유니콘) 개발자에 대한 이야기는 아니지만
- 함께 일하고 싶은 개발자 동료 특징 5가지. 2024년에 개발자로서 3년차를 맞이했다. 대학생 시절 창업을 하며… | by TaesungLee | Feb, 2024 | Medium
- Why Developers Keep Making Bad Technology Choices – Obsidian Scheduler
- 개발자에게 커뮤니케이션 스킬은 왜 중요할까?
- Communication for Developers: estimates, code reviews, and other hard problems by Voytek Pituła - YouTube
- Conventional Comments
- VidiGo Communication for Developers: estimates, code revi
-
- 개발 과정에서의 커뮤니케이션 전략
- 추정치 제공 시 양측에 동일한 의미를 전달하는 것이 중요, 이를 위해 상대방이 왜 그 숫자를 요구하는지 이해 필요
- 비즈니스와의 대화에서는 기술적인 용어를 사용하지 않고, 청중에 맞춰 말하는 것이 중요
- 코드 주석은 미래의 코드 리더에게 메시지를 전달하는 수단으로, 왜 그렇게 코드가 작성되었는지 설명 필요
- 구현 단계에서는 열린 채널을 통해 작업을 공유하여 다른 사람들과 협력할 기회를 늘리고, 모든 사람을 정보의 순환에 포함시키는 것이 중요
-
- 효율적인 커뮤니케이션과 팀워크 강화
- 스타트업이나 특정 프로젝트에서는 다양한 역할(개발자, 마케팅, 운영 등)이 협력 필요
- 효과적인 커뮤니케이션을 위해 도구를 활용하고, 명확한 목표를 가지고 리뷰어 찾아야 함
- 작업의 우선순위를 정하고, 필요한 경우 도움을 요청하는 것이 중요
-
- 성공적인 코드 리뷰와 일상 커뮤니케이션 전략
- 코드 리뷰 과정에서는 리뷰어 친화적인 접근 방식을 취하고, 명확한 설명과 함께 변경 사항 제시
- 일상 커뮤니케이션에서는 메시지의 목적과 필요성을 분명히 하고, 반복해서 정보를 제공하는 것이 중요
- 긍정적인 태도와 적절한 포맷팅은 의사소통의 효율성 향상
-
- 효과적인 커뮤니케이션 전략
- 효과적인 메시지 전달을 위해 핵심 단어 사용, 과장 금물, 명확한 목표 필요
- 회의는 비용이 많이 들고 불편할 수 있지만, 잘 진행되면 효과적
- 짧은 통화가 긴 메시지 교환보다 시간을 절약할 수 있으며, 대상을 명확히 하여 소음을 최소화 필요
-
- 글로벌 커뮤니케이션의 중요성
- 이모지 사용은 감정을 전달하는 데 도움이 될 수 있지만, 상황에 따라 적절한 사용 필요
- 커뮤니케이션은 문화에 따라 다르게 작동하므로, 글로벌 환경에서는 다양한 접근 방식 필요
- 간결함과 명료함은 문서 작성 및 메시지 전달에서 중요하며, 공개적으로 소통하는 것이 개인 메시지보다 바람직
-
- 개발자를 위한 커뮤니케이션: 견적, 코드 검토 및 기타 어려운 문제 작성자: Voytek Pituła | 완벽한 영상요약, 릴리스에이아이 | Lilys AI
- 2.🔢 효과적인 커뮤니케이션과 예측의 차이
- 평가의 목표는 두 측에게 동일한 의미를 가진 숫자를 제공하는 것
- 상황을 이해할 필요가 있고, 상대방이 원하는 것, 그들이 물을 이유를 이해하고 명확하게 커뮤니케이션하는 것이 중요
- 소통 방식에 신중함 필요, 예측과 약속 구분 필요
- 예측은 이론적이고 최선을 다하는 추측, 약속은 실제로 이행될 방법에 대한 약속
- 4.🔗 오픈 채널에서 협업하고 정보 공유하는 방법
- 조사 시 Jira, GitHub, Slack, 등 다양한 매체에 링크를 남기는 것이 유용하며, 이를 통해 협력하고 문제 해결이 용이
- 개방적으로 의사소통하며 정보를 공유하면서 다른 직원들이 해당 업무에 관심을 갖게되고 팀원들을 결속시킬 수 있으며, 효율적인 디버깅 가능
- '일 하는 방식이 팀 내 공유되어야 한다'고 강조, 리소스를 공유하고 효율적인 디버깅을 위해 개방적인 환경 조성 중요
- 7.💬비동기 커뮤니케이션 팁과 질문하기 전략 소개
- 비동기 커뮤니케이션 시 간결하게 요청 기록, 인사말만 보내지 말고 바로 본론에 들어가는 것이 중요
- 반복은 필요한데, 사람들이 잊거나 오해할 수 있기 때문에 반복이 중요하며, 설명은 명확하게 반복 필요
- 답변 받기 위해 메시지 작성 시 대상, 필요성, 시한을 명확하게 설명
- 첫번째로, 메시지의 대상을 정확히 파악하고 답변 가능성이 있는 사람에게 전달하거나 최선을 다하되, 경우에 따라 다른 사람을 소개할 수도 있음
- 8.💬효율적인 요청과 응답 방법, 그리고 커뮤니케이션의 중요성
- 간단한 설명과 요청 시점 설명을 통해 요청에 성공 확률 향상
- 답변을 원할 때는 안 답해도 되는 상황인지 고려하고, 예상 시간표를 제공하여 결정할 수 있게 함
- 의사 없이는 '괜찮아' 라 하거나 적절한 시간대 제안하여 대화 시작
- 필요 시 즉각 응답하여 진행 중임을 알림, 효율적인 커뮤니케이션과 양립하며 생산적인 일을 이뤄낼 수 있는 방법 고려
- 9.✒️메시지 작성 팁과 회의 효율성에 대한 조언
- 메시지를 쓸 때 TLDR요약을 맨 위에 넣고, 중요한 부분은 굵게 표시하여 길어도 메시지 파악이 쉽게
- 회의는 비싸고 불편하며 귀찮지만 효과적일 수 있음. 동기적 커뮤니케이션은 최악이 아니며, 10개 이상의 메시지가 오면 짧은 통화가 더 효율적일 수 있음
- 메시지를 작성할 때 명확한 대상을 지목하고, 긴 스레드에 새로운 사람을 불러들일 때는 상황을 요약하여 시간을 아끼고 모든 사람의 시간 존중
- 전화는 모든 시간에 메시지보다 나은 것은 아니며, 멀리서 일하는 조직에서는 컴퓨터에 오게 해서 스케줄을 어지럽히는 것을 피하고, 모든 상황에 적합한 균형 유지
- 10.💬커뮤니케이션 원칙: 타인의 이해, 메시지 확인, 대화 조정, 언어 능력, 간결함
- 상대방을 이해하는 것이 중요, 질문의 의도를 파악하고 메시지를 단순히 받아들이지 말고 상황에 맞게 해석 필요
- 메시지 이해를 확인, 대상이 내 의도를 올바르게 이해했는지 검증 필요. 관객에 맞게 발언하는 것도 중요
- 언어 능력은 의사소통에 중요, 간결함도 중요. 과한 언어적 표현은 이해 방해 가능성
- 문서 작성 시 간결함이 중요, 문서는 간결하고 가독성 필요
- 11.커뮤니케이션: 개방적이고 전략적이어야 함
- 개방적인 의사소통 중요. 직접 대화는 예외
- 글로벌적으로 효과적인 의사소통은 노력이 필요하나 모두에게 적용되지는 않음
- 의사소통은 문화에 따라 다르며, 이에 대한 고려 필요
- 이모티콘은 감정을 전달하는데 도움이 되지만 모두가 좋아하지는 않음
- 12.💬질문 유도 부재로 질문이 부족했던 토론, 개방적인 의사소통 중요
- 토론 중 질문 유도 부재로 참여자들은 질문을 하지 않았고, 이는 의사소통 문제로 이해할 수 있음
- 발표 중 질문을 받겠다고 말을 안 한 것은 프레젠테이션 흐름을 유지하고 마지막에 질문을 받겠다 라는 것을 깜빡했기 때문
- 리뷰어가 개발자보다 우월해 보이고 지시하는 상황에서는 개방적인 의사소통이 필요하며, 관리자나 리더십이 대응 필요
- 2.🔢 효과적인 커뮤니케이션과 예측의 차이
- Why Facebook doesn’t use Git
- 페이스북이 Git을 사용하지 않는 이유 | GeekNews
- 이 이야기는 "많은 주요 기술적 결정은 기술이 주도하는 것이 아니라 사람이 주도한다"는 점을 상기시킴
- 페이스북은 Mercurial이 Git보다 성능이 뛰어나서가 아니라, Mercurial 유지보수자들과의 협업이 더 개방적이었기 때문에 선택함
- 전체 엔지니어링 조직을 설득하는 과정에서 한 기술이 다른 기술보다 더 우수해서가 아니라 "사려 깊은 커뮤니케이션"이 중요했음
- "소통과 친절함"이 개발 도구 세계에서 중요한 가치임을 강조
- AI시대에 필요한 개발자, Product Engineer | 요즘IT
- 기획과 테스트가 사라진 세상, 풀스택빌더(FSB)의 등장 - 쉽고 재미있는 IT뉴스, 아웃스탠딩!
- 실리콘밸리에서 느낀 AI시대의 인재상
- Ideas are cheap, execution is cheaper | Dave Kiss
- The Art and Science of Thriving Developers: 7 Key Strategies by Dimitris Andreadis - YouTube
- VidiGo The Art and Science of Thriving Developers: 7 Key
- 성공하는 개발자의 예술과 과학: 디미트리스 안드레디스의 7가지 핵심 전략 | 완벽한 영상요약, 릴리스에이아이 | Lilys AI
- 행복을 위한 비결은 원하는 것을 아는 것과 그에 따라 행동하는 것
- 성공적인 개발자들도 동일한 원리를 가지며, 다가올 트렌드를 예측하고 그에 대비하여 일찍 준비하고 대응함으로써 성공
- 따라서 자신의 한 분야에서 두드러지기 위해서는 평범함에서 벗어나야 하며, 미래를 내다보고 그에 맞게 준비하여 성공에 이르기 위한 노력 필요
- 성공적인 개발자의 두드러진 특성 중 하나는 동기부여. 말로만 하는 게 아니라 행동으로 옮기는 능력 중요
- 새로운 프로젝트 시작이나 pull request 보내기 같은 행동이 중요하며, 상황에 던져져도 해결해 나가는 능력 또한 필요
- 본인이 어떤 가치를 추가할 수 있는지 항상 고민하고, 행동으로 이를 실현 필요
- 타인이 무엇을 해야 하는지 요구하는 것이 아니라, 자발적으로 행동하고 결과에 투자 필요
- 행복을 위한 비결은 원하는 것을 아는 것과 그에 따라 행동하는 것
- 개발자도 회사의 조직원이다
- 개발자도 회사의 조직원으로서 제품 개발과 매출 증대에 기여해야 하며, 기술적인 문제 해결에만 집중하는 것은 회사의 목표와 일치하지 않을 수 있음
- 창업가들은 비즈니스의 시각을 가지고 기술력을 발휘해야 하며, 비즈니스와 관련 없는 코딩과 기술에만 집착하는 사람들은 창업에 부적합
- 이동욱 on LinkedIn: 개발자도 회사의 조직원이다
- "개발자도 회사의 조직원이다" 를 보고
- Having Kids
- 유난한 도전과 도망: 어느 직장인의 부끄러운 회고
- 2015년 Toss에 13번째 직원으로 합류, 은행권 등과 수익모델을 만들기 위해 노력, 쉽지 않음에 조급함을 느끼고 퇴사, 그때의 상황/느낌을 설명한 글
- SI Q&A 세션 ① ‘네카라쿠배’ 아니어도 개발자로 성장하고 싶어요 | 요즘IT
- 10 lessons from 12 years at Google - by Addy Osmani
- Managing My Motivation, as a Solo Dev
- 6년간 앱 350개를 만들어 파이어를 달성한 1인 개발자
- 지금 프로그래밍을 하고 있는 당신은 누구인가 | Evans Library
- 엔지니어 영어 실력 어떻게 향상할까? | InfoGrab, DevOps 전문 기술 기업 | 인포그랩 | GitLab기반 DevSecOps 구축,컨설팅,교육,기술지원 서비스 제공
- How To Know When It's Time To Go
- The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024 - YouTube
- Daniel Terhorst-North, the originator of Behavior Driven Development (BDD), shares insights on the best programmer he knows
- The talk is divided into three parts: getting the job done, choosing the right tool, and caring about the team
- Terhorst-North emphasizes that the best programmers are made, not born, and their skills can be learned
- He encourages attendees to strive for greatness, discusses the importance of iterating and not being afraid to make mistakes, and highlights the value of focusing on the product rather than the code itself.
- 팀장이 되고서야 알게된 잘하는 개발자의 비밀 2024 DEVCON - 박미정 (공유용) - Google Slides
- 프로그래밍이 꼭 그런 것만을 말하지는 않습니다 | 요즘IT
- Kind Engineering: How To Engineer Kindness
- Mastering the Human Side of Engineering: Lessons from Apple, Palantir and Slack
- If you want to sharpen up your skills as a software engineer, read the following 10 articles
- The Best Programmers I Know | Matthias Endler
- Getting things "done" in large tech companies | sean goedecke
- The Python Paradox
- 50대 1인 개발자 살아남기 | GeekNews
- 개발자에게 컴퓨터 공학 지식은 언제나 중요합니다
- 고속도로에서 배우는 네트워크 원리 - TCP slow start, 14KB의 비밀, Qwik이 다른 점, 1KB가 만드는 차이
- DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474 - YouTube
- 한국 개발자, 역량 문제 아니다! 실리콘밸리 엔지니어와 다른 이것!! 우버 엔지니어로 부터 듣는다. - YouTube
- Welcoming The Next Generation of Programmers | Armin Ronacher's Thoughts and Writings
- Professional Skills for Software Engineers • Charles Humble & Trisha Gee - YouTube
- The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024 - YouTube
- What World Class Software Engineers Do That You Don't - YouTube
- Beyond Coding 250회 특집. 훌륭한 엔지니어는 최신 도구나 깨끗한 코드를 좇는 사람이 아니라 빨리 배우고, 단순하게 유지하고, 비즈니스를 이해하는 사람. 배움은 모든 도구·언어·플랫폼보다 오래 남는 유일한 스킬, 최고의 아키텍트는 지도 제작자보다 정찰병처럼 행동, "simple is complicated enough"가 규모에서 clean code 도그마를 이김, 10년 후를 예측하기보다 진화하는 시스템을 설계, AI 에이전트 시대에 주니어가 실제로 해야 할 일
- Being good isn’t enough | people, ideas, machines
- Ex-Stripe CTO on What Grew His Career, Hiring Without Leetcode, Coding as a Leader (Career Story) - YouTube
- Ex-Stripe CTO on What Grew His Career, Hiring Without Leetcode, Coding as a Leader (Career Story) | Lilys AI: Youtube, PDF, WebPage, Audio 어떤 자료든 완벽하게 요약 - Lilys AI
- Ex-Stripe CTO on What Grew His Career, Hiring Without Leetcode, Coding as a Leader (Career Story) - Google Docs
- 데이비드_싱글턴에게_배우는_구글,_스트라이프_리더십과_성장_비밀___엔지니어케이션_부터__행복한_팀의_역설_까지.m4a - Google Drive
- 이일민 - 어떤 사람들은 개발자가 단순히 코딩하는 사람이 아니라 문제 해결자(problem solver)라고 강조한다.... | Facebook
- Why I gave the world wide web away for free | Technology | The Guardian
- Redis를 바라보며: 우리는 정말 발명하는 개발자인가요? | day1swhan 블로그
- Redis 왜 쓰냐고 물으면 한 달 전 저는 "빠르니까요"라고 답했습니다 | 민혁 강 | LinkedIn
- 위 day1swhan 글을 읽고 Redis 코드를 파고든 뒤 쓴 글—바뀐 건 지식의 양이 아니라 결정을 보는 눈. single-thread는 한계가 아니라 락과 그 버그를 아예 안 만들려는 선택, memcached로 큐를 짜면 생기는 복잡도를 서버가 자료구조를 알기에 LPUSH 한 줄로 가져간 것, 메모리가 차면 조용히 버리지 않고 쓰기를 거절하는 default("위험은 시끄러워야 한다"), 지속성은 사용자에게 위임하되 Skiplist 확률값 1/4은 코드에 박아 둔 위임 기준. AI가 Redis 코드 200줄은 30초에 짜도 왜 single-thread인지·왜 1/4인지는 안 적는다는 결론
- Development gets better with Age | All Things Distributed
- AI 시대, 개발자의 역할은 '실행자'에서 '전략가'로 진화합니다.
- The Future of Software Development is Software Developers – Codemanship's Blog
- 개발자에게 가장 중요한 능력은 무엇일까요?
- Software engineers should be a little bit cynical
- 한글더빙 "당신은 AI의 승객입니까, 설계자입니까?" (하버드 CS50 명강의) - YouTube
- 개발자에게 ‘신뢰 쌓기’가 중요한 이유 | 요즘IT
- Stanford CS230 | Autumn 2025 | Lecture 9: Career Advice in AI - YouTube
- 개발자는 AI에게 대체될 것인가
- AI 코딩 시대, 더이상 성장하지 않는 개발자들 | evan-moon
- AI 코딩 시대, 성장이 멈추는 개발자의 뇌에서 일어나는 일 | GeekNews
- AI를 잘 쓰는 핵심은 출력물 품질을 판단·교정하는 능력인데, AI에 의존할수록 이 능력이 약화. Bjork의 '바람직한 어려움' 이론, 인출 연습 효과
- Why You Can't Explain What You Code | Thu Vu - YouTube
- AI가 학습에 미치는 영향 연구에서 출발해 "바이브 코딩"의 함정을 짚는 짧은 에세이 영상—돌아가는 코드를 얻었지만 왜 그렇게 동작하는지 설명할 수 없는 상태, LLM을 생각을 대신해 주면서 사고력을 잠식하는 "인지 바이러스"로 보는 관점, 통제권을 되찾는 방법, 그리고 "거의 맞는" 해답이 문제 해결 능력에 남기는 영향. 데이터·AI 교육 크리에이터의 강의 홍보 포함
- Agentic Coding is a Trap | Lars Faye
- AI 에이전트 감독에 필요한 코딩 능력 자체가 과잉 사용으로 위축되는 역설. AI를 계획·임시 도움 보조 역할로 격하하고 직접 코딩 유지 권장. 토큰 기반 서비스 벤더 락인·비용 리스크 경고
- 에이전트 코딩은 함정이다 (Agentic Coding is a Trap) | Flowkater Nugget
- 2026-05-11 요약. 핵심 명제—코딩 에이전트를 관리하는 데 필요한 비판적 사고가 AI 툴링 자체에 잠식된다는 자기 모순 시스템. 정량 가능한 4가지 트레이드오프: ①AI 비결정성을 완화하려는 주변 시스템 복잡도 ②광범위한 기술 퇴화 ③개인·팀 벤더 종속(Claude 장애 시 팀 마비) ④토큰 비용 변동성. "또 다른 추상화일 뿐" 반론에—FORTRAN·컴파일러 비판은 추측이었지만 이번엔 몇 년 만에 데이터가 나왔고, C++→Java 전환자나 AWS로 간 시스템 관리자는 이해를 잃지 않았다. "더 높은 모호성은 더 높은 추상화가 아니다"
- "이제 코딩은 AI가 한다, 사람은 오케스트레이터"라는 환상—감독의 역설 | Jaewoo Cho
- AI를 감독하려면 코딩을 할 줄 알아야 한다—Anthropic 자체 연구의 디버깅 능력 47% 급락, Simon Willison의 "멘탈 모델이 사라진다", LinkedIn 엔지니어링 디렉터의 "비판적 사고 작업엔 AI 금지" 지시. 전 CTO 경험: 코드를 못 읽으면 CTO일 수 없고 직접 짜보지 않으면 아키텍처를 설계할 수 없음. 스펙 주도 개발도 환상—스펙은 출발점이고 구현·아키텍처는 코드를 짜는 중간의 누적 컨텍스트에서 복리로 정해짐. 언어는 생각의 부분적 표상이라 그 빈틈을 AI가 확률 레버로 메우는 "가챠". Jeremy Howard: "생각을 컴퓨터에 아웃소싱하면 더 유능해지는 것을 멈춘다"
- The 3 Words That Secretly Drive Developer Productivity & Motivation - Yanina Ledovaya - GOTO 2025 - YouTube
- 개발자 생산성과 동기부여의 비밀: 자율성, 역량, 관계성 | LiveWiki
- JetBrains DX 리서치 팀리드의 자기결정이론(Self-Determination Theory) 적용. 자율성·역량·관계성 3요소가 개발자 생산성의 심리적 기반
- Developer Productivity at a Developer Productivity Startup • Robert-Jan "RJ" Huijsman • GOTO 2025 - YouTube
- Reboot.dev 창업 엔지니어 RJ가 8명 소수 팀으로 많은 일을 해내는 방법 공유(데이터 아닌 경험담). 두 축—마찰(friction)과 비결정성(non-determinism)을 줄이는 데 집중. 개발자 생산성을 만드는 startup이 스스로의 생산성을 높이며 얻은 교훈을 오픈소스 프레임워크 Reboot에 반영
- 404 – Developer Not Found: The Continuing Developer Evolution • Derek Bingham • YOW! 2025 - YouTube
- AWS Derek Bingham. 코딩 어시스턴트→AI 에이전트→자율 시스템으로의 개발자 진화. 프롬프트/컨텍스트 엔지니어링·컨텍스트 관리, 거짓 두려움, spec-driven development, 새 패러다임에서 개발자가 갖춰야 할 역량과 생존 전략
- 하용호 - AI 시대의 전문성 (인프런, 2026.6.11)
- Software developers are not okay | Baldur Bjarnason
- 소프트웨어 개발자들은 괜찮지 않다 | GeekNews
- "I'm leaving my tech job" 영상들과 그 댓글란에서 번아웃·해고·업계 이탈이 쌓이는 현상을 짚은 에세이(영상·오디오 버전 포함). AI를 반대했던 사람만 떠나는 게 아니라 "이것이 개발의 미래"라는 약속을 믿고 써 본 뒤 즐겁지 않고 해롭다고 느껴 떠나는 사람도 많다는 관찰
- 에이전트 개발은 전동 공구가 아니라 사정을 모르는 초급자에게 맡기는 것에 가까워 결과물과의 거리가 벌어지고 "내가 만들었다"는 감각과 몰입이 줄어듦. AI가 개발자를 완전히 대체하지 못해도 남은 인원이 AI 결과를 수습하며 같은 업무량을 감당하면 회사는 비용과 협상력에서 이득을 보고, 버티지 못해 먼저 그만두는 것조차 회사에 유리(퇴직 보상·미확정 주식 절감). AI 거품이 꺼져도 이 노동 구조는 남으니 개발자 정체성 밖의 미래도 생각해 보라는 결론
- ISMS-P 심사원 자격증 미리미리 노후 대비 해 놓자구요 😎 #개발자노후대비 - YouTube
- Religious Studies In Software Engineering | tom bh
- 종교학으로 바라본 소프트웨어 공학 | GeekNews
- 종교학을 전공하고 소프트웨어로 생계를 이어 온 저자의 에세이—이데올로기·정치·종교도 원하는 결과에 이르는 일련의 단계라는 점에서 프로그램과 닮았고, 프로그래밍은 컴퓨터만이 아니라 사람과 사회에 하는 일. Tillich의 "궁극적 관심"으로 종교를 보고, 정의하지 못한 대상을 엄밀하게 연구하는 훈련과 내부자/외부자 문제(개발자는 디지털 세계를 깊이 알지만 그 믿음과 권력에 참여하는 내부자—특이점이나 오픈소스 지지자도 편향 없는 관찰자가 아님)를 소프트웨어에 적용
- 분파가 자라 새 권위가 되듯 소프트웨어도 기존 구현과 새 해석 사이에서 갱신되고, 검증된 코드도 현실과 어긋날 수 있어 실제 사용·피드백으로 유효성을 확인해야 함. 프로그램의 핵심은 코드보다 개발자들이 공유하는 문제 이해(Conway의 법칙, Linux의 발전)—빅테크도 오픈소스도 신념이 권위로 굳는 과정에서 자유롭지 않고, 코드가 계속 실행돼도 변경 요구에 대응할 이해를 잃으면 프로그램은 이미 죽은 것
- Here Be Monsters: What Do You Still Need to Know When Agents Do the Work? | adrq.dev
- AI 에이전트가 코드를 작성해도 개발자는 무엇을 알아야 할까? | GeekNews
- "에이전트가 다 한다"는 낙관론과 "위임하면 유지보수 불가능한 코드가 나온다"는 회의론을 모두 거부—오늘의 시니어가 손으로 코드를 쓰며 배운 길은 회사가 수년의 수동 학습을 후원하지 않는 지금의 주니어에게 더는 유효하지 않고, 시스템 소유권은 모든 줄을 아는 것이 아니라 어느 입도(granularity)에서 이해하고 "괴물이 사는 곳"을 알아 뛰어들 수 있는지의 문제(레거시를 맡은 CTO처럼). 생성된 모든 줄을 읽는 것은 규모상 불가능하고 구현을 무시하는 것은 무책임—사례로 로직은 맞지만 복잡도 검사에 걸린 AI 생성 React 컴포넌트를 에이전트가 파일 분할로 고쳤을 때 유지보수자가 자기가 쓰지 않은 코드의 문제를 잡아낸 일
- 미래의 시스템 관리자를 받치는 세 기둥: ①기초(자료구조·알고리즘·네트워킹·동시성·분산 시스템)—점진적 성능 저하·간헐적 오류 같은 "조용한 실패"를 알아보는 도구 ②폭(breadth)—가르칠 수 없고 호기심과 경험으로 흡수하는 횡단 지식, 어느 도메인에 문제가 있을지·무엇을 조사할지 가늠 ③적시 깊이(just-in-time depth)—압박 속에서 어떤 문제든 파고들어 알아내는 의지와 능력, 그리고 언제 도움을 구하고 멈출지 아는 겸손. 스페셜리스트·제너럴리스트·T자형과 대비한 새 "오너" 유형. GeekNews 댓글: 내부 세부보다 경계·입출력(시퀀스·아키텍처 다이어그램)이 중요, LLM은 DB 정규화 결정을 자주 잘못하니 스키마 설계는 직접, 법적 책임은 사람에게 있으니 영속 포맷·API·프로토콜 같은 고영향 영역은 선별 심층 리뷰, 손으로 일하지 않으면서 어떻게 전문성을 유지하느냐가 근본 질문
- 소프트웨어 장인 CHAPTER 4 소프트웨어 장인의 태도
- 더북(TheBook): 소프트웨어 장인 1~4장만
- 더북(TheBook): 소프트 스킬 : 평범한 개발자의 비범한 인생 전략 71가지 26장만
- Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs by James Stanier
- Become an Effective Software Engineering Manager • James Stanier & Gergely Orosz • GOTO 2023 - YouTube
- Become an Effective Software Engineering Manager • James Stanier & Gergely Orosz - YouTube
- VidiGo Become an Effective Software Engineering Manager •
- 관리자로서의 성장과 철학
- 기술 분야에서 경력을 쌓아가는 과정에서 해고는 피할 수 없는 일일 수 있으며, 이는 개인의 통제 범위를 벗어난 일
- 관리자는 고품질의 업무를 수행하면서도 필요한 경우 개발자로서의 역할로 돌아갈 준비 필요
- 스토아 철학과 같은 철학적 접근을 통해 통제 가능한 것과 그렇지 않은 것을 구분하고 집중하는 것이 중요
- 효과적인 위임과 관계 구축
- 위임은 단순히 업무를 나누어 주는 것 이상으로, 매니저가 여전히 책임감을 가져야 하는 복잡한 과정
- 새로운 직원이나 상사와의 초기 만남에서 서로의 기대와 필요사항을 명확히 하여 성공적인 관계를 구축하는 것이 중요
- 계약 운동을 통해 서로에 대해 더 잘 알아가고 협력적으로 문제를 예방 가능
- 관리자로서의 성장과 철학
- Become an Effective Software Engineering Manager • James Stanier & Gergely Orosz | The fastest way to absorb knowledge | Lilys AI | Lilys AI
- VidiGo Become an Effective Software Engineering Manager •
- 23 Alternative Career Paths that Software Developers Can Grow Into
- The Software Engineering Job Ladder
- Creating a career ladder for engineers - Marco Rogers | #LeadDevNewYork - YouTube 개발자들의 커리어 사다리가 왜 중요하고 어떻게 운영하면 되는가
- The Software Engineering Career Ladder 📈 | by Martin Thoma | Geek Culture | Medium
- Engineering Ladders을 이용한 성장방향 찾기. 요즘 가장 크게 고민하고 있는 것 중에 하나는 “엔지니어의 성장이란… | by Kyung Jun Park | Jun, 2022 | Medium
- What I Learnt Becoming a Tech Lead - Tom Gamon
- 백발의 개발자가 되기 위한 커리어 패스
- Overview - Dropbox Engineering Career Framework
- 소프트웨어 엔지니어, QA 엔지니어, SRE, 머신러닝 엔지니어, 엔지니어링 매니저마다 각 레벨에서의 기대되는 역할과 핵심 책임 정리
- 드롭박스의 엔지니어링 커리어 프레임워크 | GeekNews
- Here's the latest version of our Engineering Career Framework - Dropbox
- Dropbox가 각 직무의 레벨과 각 레벨에서 요구되는 역할을 정의한 Dropbox Engineering Career Framework를 2년 전에 공개했는데 이번에 업데이트
- 기존 프레임워크가 크고 주목할 만한 성과에 평가와 승진이 치우쳐 있다는 인식이 있고 사내 설문조사 결과 각 역할의 Core Responsibilities가 수행 중인 업무를 반영하지 않는다고 25% 이상 대답하고 20%는 다음 단계로 가기 위해 뭘 해야 하는지 모르겠다고 대답
- 커리어 프레임워크는 승진을 위한 체크리스트가 아니라고 했지만 실제로 그렇게 쓰이고 있었기에 프레임워크의 명확성과 정확성을 개선
- Nobody Gets Promoted for Simplicity
- Introducing The Complete Computer Science Career Path
- Belonging to Amazon’s Principal Engineering Community | by Carlos Arguelles | Geek Culture | Nov, 2021 | Medium
- What does a Principal Software Engineer do? | by Bobi | Dev Genius
- Advice for New Principal Tech ICs (i.e., Notes to Myself) | Eugene Yan
- 이제 막 핵심 인재로 올라선 엔지니어들에게 주는 조언 | 안영회 번역, 요즘IT
- Amazon Principal Applied Scientist가 롤 모델들을 관찰하고 조언을 인용해 정리한 수석 IC 노트—①수석마다 스타일이 다르니(깊이 파기·수평 영향력·기술 선구자·복잡성 정리·조직 정렬) 강점에 맞는 것을 찾되 Amazon은 수석이 계속 hands-on이기를 원함 ②이전 역할에서 핵심이던 코딩은 이제 부수적—80% 코딩하더라도 설계 피드백·기술 가이드·장기 비전으로 모든 빌더가 더 잘 만들게 하는 것이 영향력 ③기술의 파트타임 PM, 사실은 제품·디자인·채용·재무·문화 모두의 파트타임 ④디렉터·VP를 넘나드는 범위라 소통·영향력·사람 연결이 핵심, 조직도를 고객에게 배송하지 말 것 ⑤옳은 것은 절반도 못 이김—설득하고 움직이게 하고 후원자를 찾아 마무리까지, "수석이 곧 위원회" ⑥조직이 아직 가치를 모르는 것을 가르치는 일(10개 문서 중 3개가 실행되면 훌륭한 성과) ⑦당신 없이는 일어나지 않을 일(관심×탁월함의 교차점)에 집중 ⑧일을 하는 것보다 점을 연결하는 것이 더 가치 있을 때 ⑨혼자 할 수 있는 양은 한계가 있으니 1~2명을 골라 키우고 "조직이 수석과 같은 결정을 내리게 되는 것"이 성공. 번역은 scientist·principal tech IC를 모두 '수석 엔지니어'로 통일하고 L7 등 국내 상황에 맞춘 의역 추가
- What Happens To Developers Who Never Go Into Management? | WBS CODING SCHOOL
- What happens to developers who never go into management? | by WBS CODING SCHOOL | Medium
- 37signals에는 다시 한 번 풀타임 관리자가 없습니다. (We once more have no full-time managers at 37signals) | Write the code. Change the world.
- IT 커리어를 '서서히 망치는' 11가지 함정 - CIO Korea
- The Other Kind of Staff Software Engineer - Earthly Blog
- The Secret to Finding Impactful Projects to Land a Staff-Plus Engineer Role - YouTube
- Why You Should Build a “Career Portfolio” (Not a “Career Path”)
- Curated paths for developers | pathify
- 한기용 - 성장하는 조직의 성장통 - 레벨링하기
- 한기용 - 승진, 커리어
- 인정받는 주니어, 시니어, 리더의 모습은? - YouTube
- Part 0 : 커리어 플래닝 가이드북 | G.. : 네이버블로그
- Part 1 : 커리어 플래닝 가이드북 | G.. : 네이버블로그
- Part 2 : 커리어 플래닝 가이드북 | G.. : 네이버블로그
- Part 3 : 커리어 플래닝 가이드북 | G.. : 네이버블로그
- 구글 시니어 개발자가 성장을 위해 선택한 길 | 요즘IT
- 토스ㅣSLASH 23 - 라운드테이블 : 토스 시니어 개발자가 말하는 커리어 패스 - YouTube
- 박성철
- (1) 박성철 - 종종 개발자가 구현 외에 요구 사항 수집/분석, 기획, 설계, 아키텍처 수립, 개발 환경 구축, 테스트,... | Facebook
- 리얼월드에서 프로그래머로 살아내기 | 요즘IT 다 좋은 내용이지만 '구글 엔지니어는 이렇게 일한다' 얘기에 특히 동감
- SK 플래닛 이사, 우아한형제들 이사, 컬리 전 CTO를 지내신 박성철님의 첫번째 이야기입니다. - YouTube
- 최낙현 - 다시, 소프트웨어 엔지니어 북콘서트 후기 | Facebook
- 2026.6.5 책만출판사 주최 박성철 저자 북콘서트. 이일민(화상)+이민석/Benjamin Byungboo Kim/김정/양수열 패널. AI가 코드를 작성하는 시대에 단순 구현 역할로는 경쟁력 부족, 문제 발견·정의·이해관계자 소통이 핵심. "코드는 싸졌지만, 소프트웨어는 여전히 비싸다"
- CS 007: Course Material (2022) | CS 007: Personal Finance for Engineers
- 개발자 주도적 성장 돕는 '커리어 프레임워크'란? | 요즘IT
- 그대들, 어떻게 공부할 것인가 - Google Slides
- 엔지니어링 레벨링은 누더기가 되었나?
- 실리콘밸리에서는 이제 꽤 일반적으로 된 것으로 알고 있는 엔지니어링 레벨링이 처음 알려지기 시작했을 때 꽤 많은 관심
- 국내 많은 스타트업이 이를 도입하고 오히려 불편함과 스트레스를 호소하는 것을 보고 고민을 적은 글
- 바라는 모습을 제시하지 못하거나 적절한 상황이 아니거나 매니저와 IC를 자유롭게 오가지 못하는 문제를 지적
- 실리콘밸리에서는 이제 꽤 일반적으로 된 것으로 알고 있는 엔지니어링 레벨링이 처음 알려지기 시작했을 때 꽤 많은 관심
- 개발자의 승진과 성장: 회사에서 인정받고 성공하는 전략
- AI시대에 60살까지 일하고 싶으면 '리더'해야 합니다ㅣ한기용의 나침반 - YouTube
- "Software Fundamentals Matter More Than Ever" — Matt Pocock - YouTube
- GN#355 잃어버린 기본기를 찾아서 | GeekNews
- AI 코딩 에이전트 시대에 오히려 소프트웨어 기본기가 더 중요해짐. Cursor/Claude가 만든 코드가 프로덕션에서 6-12개월 버틸 수 있는지, 팀원 변경 시 유지보수 가능한지에 대한 문제 제기
- If You Have Multiple Interests, Please Take Advantage of the Next 10 Years | Dan Koe - YouTube
- 36분 영상 83만 뷰, Dan Koe — 직업은 250년짜리 발명품, AI 시대에 남는 스킬 스택 3층 - YouTube
- 구독자 142만 작가 Dan Koe의 영상. AI를 거부하지도 전부 맡기지도 않는 세 번째 길—여러 관심사를 하나의 브랜드로 결합하는 전략과 AI 시대에 남는 스킬 스택(AgentOS 한국어 정리 영상 포함)
- career-ladders
- The Prosperous Software Consultant
- 콜드콜로 자문을 받고 싶을 때 '꿀팁 3가지' - 쉽고 재미있는 IT뉴스, 아웃스탠딩!
- 컨설턴트, 이렇게 쓰면 망한다··· CIO들의 3가지 실수 - CIO Korea
- 한기용 - 컨설팅 경험
- Netflix Engineering Director: Why Code Scales Systems, But Clarity Scales Orgs | InfoQ - YouTube
- Lessons from Building an Engineering Team | InfoQ
- 46분—코드는 시스템을 확장하지만 조직을 확장하는 것은 명료함이라는 Netflix 엔지니어링 디렉터의 교훈
- 90% of Engineering Leaders Scale Tech But Fail the Humans | InfoQ - YouTube
- Human Scalability | InfoQ
- 50분—기술은 확장하면서 사람의 확장에는 실패하는 엔지니어링 리더십 문제
- Why Engineering Culture Is Everything: Building Teams That Actually Work | InfoQ - YouTube
- Engineering Culture: Building Teams | InfoQ Podcast
- 24분—실제로 작동하는 팀을 만드는 엔지니어링 문화
- book
- 훌륭한 개발 문화의 이면(7) – 잉여력이냐 vs. 효율성이냐 개발자 경력 경로
- 팀 문화의 탄생 | 우아한형제들 기술블로그 정말 이대로 실행한다면 엄청나게 훌륭한 회사
- Habits of High-Functioning Teams
- The Pragmatic Engineer Test: 12 Questions on Engineering Culture - The Pragmatic Engineer 이직할 회사 선택 기준
- 개발자 경험(Dex)이 주목받는 시대 | 요즘IT Developer Experience
- ‘네카라쿠배’로 보는 개발자가 선호하는 문화 5가지 | 요즘IT
- The Religion of Speed – The Gospel According to Graybeard
- 속도의 종교 | GeekNews
- "빠르게 움직이기"가 실무적 필요를 넘어 진지함·야망의 증거이자 도덕적 위치가 되면서 신중한 검토가 추진력을 방해하는 태도로 취급되는 문화 비판. 진짜 속도는 업무·제약·의존성을 이해하고 명확히 결정한 뒤 실행할 때 나오는데, 많은 조직이 모호한 요구사항·미완의 결정을 속도로 포장—이해 단계를 서두르면 재작업으로 되돌아온다
- Signals & Levers • Elisabeth Hendrickson, Joel Tosi & Charles Humble • GOTO Book Club - YouTube
- 「Signals & Levers」 저자 Elisabeth Hendrickson의 63분 북클럽 대담—조직을 움직이는 신호와 지렛대
- 리더가 유능할수록 조직은 바보가 되었습니다 — 1명에서 1,000명까지, 권한 위임에 치른 수업료 | 김민기
- 위임을 두고 리더('아직 못 맡긴다')와 실무자('맡길 줄 모른다')가 동상이몽—맥락 공유가 실력보다 중요하고, 맥락은 사람을 타면 손실되니 검색 가능하게 만들라는 등 위임 실패로 배운 7가지
- No Meat Proxy — AI is a tool. You shouldn't be.
- Meat Proxy가 되지 마세요. 동료의 질문을 AI에 그대로 넣고 나온 답변을 복붙해서 답장하신 적이 있으신가요? | Dale Seo
- AI가 뱉은 결과물을 읽지도·이해하지도·검증하지도 않고 그대로 타인에게 넘기는 사람 = Meat Proxy('살로 된 중계기'). 에이전트가 짜준 코드를 안 읽고 PR 리뷰를 요청하는 행태에 대한 경고 선언 사이트
- "똑똑함은 이제 흔합니다" 젠슨 황이 말한 AI 시대 최고의 인재 | 우명훈 대표 세바시45 ep.109 | 세바시 강연 Sebasi Talk - YouTube
- 원대로 - 내 프롬프트 꽁꽁 숨기고 있는 당신, 그게 당신 연봉의 천장이다 | Facebook
- 삼성전자·SK하이닉스 등에서 18년간 리더십 교육을 한 『이타적 성장』 저자 우명훈의 40분 강연과 그 정리—"이기적인 분들은 좋은 평가가 나오기 쉽지 않다". ①자기계발과 이타적 성장의 차이는 '감시자'(클라이언트·동료 시선·데드라인)의 유무, 남의 문제를 풀러 뛰어들면 내 역량의 울타리를 넘게 됨 ②"밴드만 붙여주지 마라"—왜 다치는지 찾아 가드를 만드는 심층 동기화에는 호기심·애정·"그게 정말 문제 맞나요"라고 묻는 용기·전문성이 필요 ③다운턴에 찬밥이던 HBM 팀에 다른 팀이 자기 실패 데이터를 넘긴 SK하이닉스의 '원 팀' DNA가 지금 주가를 만들었다 ④Above/Below the Line—남 탓·셀프 독설이 아래로 끌어내리고, 잘 먹고 잘 자고 도움을 요청하는 용기가 위로 ⑤호구와 파트너 사이의 가드레일(진짜 필요한지·내가 할 수 있는지 먼저 묻고, 횟수를 정하고, 생색을 내라) ⑥AI 시대에 "내 프롬프트는 자산"이라며 안 나누는 사람은 자기 한계 안에서만 성장—핵심 인재에게 노하우를 후배에게 가르치게 했더니 6개월 뒤 전원 승진(가르치며 구조가 선명해지고 전문성의 반경이 넓어짐)
- 도널드 커누스 - 튜링상 수상자 시리즈, 지식함지
- Donald Knuth on work habits, problem solving, and happiness
- john-carmack-plan-archive/by_year/johnc_plan_1996.txt
- Leslie Lamport The Man Who Revolutionized Computer Science With Math - YouTube
- Margaret Hamilton 전설의 프로그래머 인류를 달에 보낼 수 있었던 마거릿 해밀턴의 코딩 능력
- Rob Pike's 5 Rules of Programming
- Ward Christensen, BBS inventor and architect of our online age, dies at age 78
- 스탠포드에서 빅테크로 조용히 퍼지는 개발자 생존법 | 미하일 에릭 - YouTube
- estudy | rlaope
- estudy: AI and engineering reinforcement learning for human | rlaope
- 소프트웨어를 공부하며 쌓은 기록을 "나의 지식의 숲"으로 모은 저장소—Essentials(엔지니어로 성장하기, YAGNI·리팩터링·의사결정, 일을 잘한다와 개발을 잘한다의 정의, AI 시대에서 살아남는 방법 등)와 Server 100여 편(KISS·YAGNI·DRY, 인증·인가, Clean Architecture, OAuth 2.0, SOLID, Netty 스레드 모델·메모리·EventLoop, Reactive, 캐시, Protocol Buffers, Kafka·Zookeeper 리밸런싱 등)
- 우리가 부르는 시니어 개발자는 누구인가? | 우아한형제들 기술블로그
- I Read 21 Articles About How to Become a Senior Developer So You Don't Have To
- What Happens When You Lack Senior Engineering Leadership
- Team Empowerment: When it is time for you Lead Dev to let go of responsibilities? by Blagoj Jovanov - YouTube
- Senior to a Lead software developer | by Daniel Anderson | The Startup | Medium
- 10 habits of Senior Software Developers (part 1) | by CBernardes | JavaScript In Plain English | Medium
- 10 habits of Senior Software Developers (part 2) | by CBernardes | JavaScript In Plain English | Medium
- The Things I Learned to Become a Senior Software Engineer | by Neil Kakkar | Better Programming | Sep, 2020 | Medium
- 5 Signs of a Senior Developer. Being a senior developer has to do with… | by Daan | Oct, 2020 | Level Up Coding
- The One and Only Factor That Will Make You a Senior Developer | by Travis Rodgers | The Startup | Medium
- An incomplete list of skills senior engineers need, beyond coding | by Camille Fournier | Jun, 2021 | Medium
- 시니어가 되기 위한 준비, 「개발 큐레이션」과 함께한 2021 - Dico
- 시니어가 들려주는 "내가 알고 있는 걸 당신도 알게 된다면 - YouTube
- 저도 시니어는 처음이라. 시니어 엔지니어는 무슨 일을 해야하나요? | by 조은, John Cho | Mar, 2022 | Medium
- The Things That I Saw Senior Software Engineers Do | by Michael Chi | Better Programming
- NDC22 언젠가 시니어가 될 주니어 프로그래머를 위한 강연
- 우아한형제들에서 시니어 개발자로 일하면 어떨까? – (1) 일 | 우아한형제들 기술블로그 |
- 중간관리자 혹은 시니어 개발자를 격려하라
-
- 업무를 전달하고 다시 확인을 할 필요가 없음 2. 주변 사람들을 도움
- 꼭 개발자가 아니어도 해당하는 이야기. 일반적이지만 좋은 정의라고 생각
-
- Transitioning into Tech: The Journey of a Senior Junior Developer by Ibrahim Dogrusoz - YouTube
- The Curse of the Senior Software Engineer - Dmitry Kudryavtsev
- Claude 3 Sonnet v1
- 직급에서 오랫동안 정체되면 다음 직업 탐색 시 어려움 발생
- 상위 직급으로 승진하기에는 경력이 부족
- 리더십 경험이 부족해 리더 직위로 가기 어려움
- 이런 현상을 "시니어 소프트웨어 엔지니어의 저주"라고 부름
- 저주 해결 방법
- 기업 문화에 동참하고 직급 체계를 중시
- 기업 문화를 벗어나 직급에 연연하지 않는 회사 찾기
- 프리랜서 또는 계약직으로 전환
- 직급에서 오랫동안 정체되면 다음 직업 탐색 시 어려움 발생
- Claude 3 Haiku v1
- 타이틀에 관심을 가지는 이유
- 임금 범위 정립
- 승진과 평가를 위해
- 승진하지 못하면 성과 개선 프로세스 대상이 되거나 해고 될 수 있음
- 다른 회사로 이직하는 것이 승진과 임금 인상의 방법이 될 수 있음
- 하지만 장기 근속자 중에서도 승진 없이 동일한 직위에 머무르는 경우가 있음
- "선임 소프트웨어 엔지니어의 저주"
- 개인 기여형(IC)에서 리더십으로의 전환이 중요한데, 선임 엔지니어 직급에 오래 머무르는 경우 문제가 발생
- 선임 엔지니어 직급 이상의 역할을 수행하기 위해서는 리더십 경험이 필요하지만, 오랜 기간 선임 직급에 머물러 있으면 리더십 경험이 부족해짐
- 이런 경우 새 직장을 찾을 때 선임 직급에 지원하기에는 과도한 경력을, 리더십 직급에 지원하기에는 경험이 부족하게 됨
- 저주를 피하는 방법
- 기업 내 승진 경로를 잘 이해하고 주기적인 승진을 받아야 함
- 그렇지 않다면 다른 회사로 이직하여 타이틀 및 임금 상승을 도모해야 함
- 또 다른 방법은 타이틀 및 경력 ladder에 관심이 없는 회사를 찾는 것
- 타이틀에 관심을 가지는 이유
- 시니어 개발자로서 오래 일하면서 승진에 전혀 관심 없었지만
- 시간이 지나 창업하려다가 다시 취업을 시도하다 보니 시니어로 채용하기엔 너무 높은 직급이거나 리더쉽으로 채용하기에는 경험이 부족한 상황 설명
- 본인의 가설이긴 하지만 맞다면 다른 사람들은 조심했으면 좋겠다고 이야기
- 승진 주기에 맞춰서 커리어를 관리하거나 빅테크식의 관리 방법을 쓰지 않는 회사를 찾는 해결책이 있다고 설명
- Claude 3 Sonnet v1
- 시니어 엔지니어가 만들면 빠른 이유 #1
- 시니어 엔지니어가 만들면 빠른 이유 #2
- How I plan my week as a Senior Engineer in Big Tech
- 25년차 시니어 엔지니어가 말하는 "내가 18살로 돌아간다면 꼭 하고 싶은 10가지"
- My Mentee Went From Junior -> Senior Engineer in less than 2 years. Here's how.
- The mentor used a weekly 1:1 meeting framework called C2-G2-R2 and created a growth plan to identify focus areas and actions for improvement
- Condition: How are you feeling? Green ✅, yellow
⚠️ , orange 🔶, red 🚨? - Challenges: What was difficult recently?
- Growth: What areas do you want to grow in more? How can I help?
- Goals: How are you tracking on your goals, either with me or your manager?
- Reflections: Is there anything you wish went better recently?
- Relationships: How are things with your manager and other people you’re working with?
- Condition: How are you feeling? Green ✅, yellow
- They also documented accomplishments in a format the manager cared about and connected this to conversations with the manager to work toward a promotion
- The mentor used a weekly 1:1 meeting framework called C2-G2-R2 and created a growth plan to identify focus areas and actions for improvement
- Why Senior Engineers Let Bad Projects Fail - Lalit Maganti
- Drunk Post: Things I've Learned as a Senior Engineer
- 시니어 엔지니어로서 배운 것들 (2021) | GeekNews
- 10년 경력 데이터 엔지니어. 기술 스택보다 각 분야 10~20가지 핵심 원칙이 중요, 커리어 성장 최고 방법은 이직
- path-to-senior-engineer-handbook: All the resources you need to get to Senior Engineer and beyond