professional programming

목차

• 전문 프로그래밍 -이 목록에 대한
  • 원리
  • 이 목록에 기여합니다
  • 읽어야 할 책
  • 읽어야 할 기사
  • 기타 일반 자료 및 리소스 목록
    • 다른 목록
    • 서적
    • 조항
    • 공리
    • 행동
  • 주제
    • 알고리즘 및 데이터 구조
    • API 설계 및 개발
    • 태도, 습관, 사고 방식
      • 지연
    • 인증/승인
    • 오토메이션
    • 모범 사례
    • 소프트웨어 엔지니어링 및 무작위를 넘어서
    • 편견
    • 사업
    • 은닉처
    • 경력 성장
      • 다음/첫 번째 기회를 선택하십시오
      • 직원 Eng에 가십시오
    • 문자 세트
    • 체스
    • 구름
    • 코드 리뷰
    • 코딩 및 코드 품질
    • 의사소통
    • 컴파일러
    • 구성
    • 연속 통합 (CI)
    • 데이터베이스
      • NOSQL
      • 포스트 그레스
    • 데이터 형식
    • 데이터 과학/데이터 엔지니어링
    • 디버깅
    • 디자인 (Visual, UX, UI, 타이포그래피)
    • 디자인 (OO 모델링, 아키텍처, 패턴, 패턴 방지 등)
      • 설계 : 데이터베이스 스키마
      • 디자인 : 패턴
      • 디자인 : 단순성
    • 개발 환경 및 도구
    • 도커
    • 선적 서류 비치
    • dotfiles
    • 편집자 & IDE
      • 정력
    • 이메일
    • 엔지니어링 관리
    • 수업 과정
    • 실험
    • 기능적 프로그래밍 (FP)
    • 게임 개발
    • 제도법
    • 하드웨어
    • http
    • 기분
    • 사고 대응 (OnCall, Alerting, Outages, Firefighting, Postmortem)
      • 검시
    • 인터넷
    • 인터뷰
    • Kubernetes
    • 대형 언어 모델 (LLM)
    • 학습 및 암기
    • 라이센스 (법률)
    • Linux (시스템 관리)
    • 로우 코드/노 코드
    • 저수준, 어셈블리
    • 기계 학습/AI
    • 수학
    • 마케팅
    • 회로망
    • 관찰 가능성 (모니터링, 로깅, 예외 처리)
      • 벌채 반출
      • 오류/예외 처리
      • 메트릭
      • 모니터링
    • 오픈 소스
    • 운영 체제 (OS)
    • 과도한 엔지니어링
    • 성능
    • 개인 지식 관리 (PKM)
    • 개인 생산성
    • 관점
    • 은둔
    • 문제 해결
    • 소프트웨어 엔지니어를위한 제품 관리
    • 프로젝트 관리
    • 프로그래밍 언어
      • 파이썬
      • 자바 스크립트
      • 쓰레기 수집
    • 프로그래밍 패러다임
    • 대중 연설 (발표)
    • 독서
    • 리팩토링
    • 리그 즈
    • 출시 및 배포
      • 버전 작성
      • 점검 목록
      • 특징 플래그
      • 생산 테스트
    • 신뢰할 수 있음
      • 탄력성
    • 찾다
    • 보안
    • 쉘 (명령 줄)
    • SQL
    • 시스템 관리
    • 시스템 아키텍처
      • 건축 패턴
      • 마이크로 서비스/단일 분할
    • 확장 성
    • 사이트 안정성 엔지니어링 (SRE)
    • 기술 부채
    • 테스트
    • 도구
    • 유형 시스템
    • 타이포그래피
    • 버전 제어 (GIT)
    • 업무 윤리, 생산성 및 업무/생활 균형
    • 웹 개발
    • 쓰기 (커뮤니케이션, 블로깅)
  • 프레젠테이션을위한 자원 및 영감
  • 최신 유지
  • 개념
  • 내 다른 목록

전문 프로그래밍 -이 목록에 대한

나무를 자르기 위해 6 시간을 주시면 처음 네 번을 도끼를 선명하게 할 것입니다. (아브라함 링컨)

프로그래머를위한 풀 스택 리소스 모음.

이 페이지의 목표는 당신을보다 능숙한 개발자로 만드는 것입니다. 내가 진정으로 영감을 주거나 시대를 초월한 고전이 된 자료 만 찾을 수 있습니다.

원리

• 이 페이지는 포괄적이지 않습니다. 나는 그것을 가볍게 유지하려고 노력하고 있으며 너무 압도적이지 않습니다.
• 기사 선택은 의견이 있습니다.
• 나는 반드시 해당 리소스의 모든 단일 하나에 작성된 모든 단일 라인에 동의하거나 보증하지는 않습니다. 저자에게도 마찬가지입니다. 나는 그 저자들이 말한 모든 것을 보증하지 않습니다.

항목 :

• ? : 리소스 목록
• : 책
• ? : 비디오/영화 추출/영화/토크
• ? : 슬라이드/프레젠테이션
• ️ : 읽어야합니다
• ? : 종이

이 목록에 기여합니다

기여할 PR을 열어주십시오!

나는 모든 것을 추가하지 않을 것입니다 : 위에서 언급했듯이, 나는 목록을 간결하게 유지하려고 노력하고 있습니다.

읽어야 할 책

나는이 책들이 엄청나게 고무적인 것을 발견했다.

• 실용적인 프로그래머 : Journeyman에서 마스터로 : 실습 프로그래밍에 대해 읽은 가장 고무적이고 유용한 책.
• 코드 완료 : 소프트웨어 구성의 실질적인 핸드북 : 실용적인 프로그래머에 좋은 추가로 코드에 대해 이야기하는 데 필요한 프레임 워크를 제공합니다.
• 릴리스! :이 책은 코드를 넘어 제작 준비 소프트웨어를 구축하기위한 모범 사례를 제공합니다. 그것은 당신에게 약 3 년 동안 실제 경험을 줄 것입니다.
• 확장 성 규칙 : 웹 사이트 스케일링을위한 50 원칙
• Linux 프로그래밍 인터페이스 : Linux 및 Unix 시스템 프로그래밍 핸드북 : Linux에 대해 알아야 할 거의 모든 것을 가르치지 않고이 책은 소프트웨어의 진화 방식과 간단하고 우아한 인터페이스의 가치에 대한 통찰력을 제공합니다.
• 컴퓨터 프로그램의 구조 및 해석 (무료) : 컴퓨터 과학에서 가장 영향력있는 교과서 중 하나 (MIT에서 작성 및 사용) SICP는 CS 교육에 영향을 미쳤습니다. 바이트는 "직업에 정말로 관심이있는 전문 프로그래머에게"SICP를 추천했습니다.

다음을 포함하여 사용할 수있는 몇 가지 무료 책이 있습니다.

• 전문 소프트웨어 개발 :이 페이지의 아주 완벽하고 좋은 동반자. 무료 장은 주로 소프트웨어 개발 프로세스와 같은 소프트웨어 개발 프로세스와 같은 설계, 테스트, 코드 작성 등에 중점을두고 있으며 기술 자체는 그리 많지 않습니다.
• ? VHF/프리 프로그래밍 북
• ? eBookFoundation/무료 프로그래밍 책

읽어야 할 기사

• 새로운 소프트웨어 엔지니어를위한 실용적인 조언
• 선임 엔지니어가되었습니다
• 소프트웨어 개발에서 배운 교훈 : 수년간의 어려운 교훈을주는 기사 중 하나는 하나의 짧은 기사에서 모두. 읽어야합니다.
• 내가 어려운 방법을 배운 것
  • 먼저 사양을 한 다음 코드입니다
  • 테스트는 더 나은 API를 만듭니다
  • 미래의 사고는 미래의 쓰레기입니다
  • 문서화는 미래의 자아에 대한 연애 편지입니다
  • 때로는 응용 프로그램이 아무것도하지 않는 것보다 충돌하는 것이 낫습니다.
  • 화물 컬트를 이해하고 멀리하십시오
  • "일자리를위한 올바른 도구"는 의제를 추진하는 것입니다.
  • 기본 기능 프로그래밍을 배우십시오
  • 항상 날짜와 함께 시간 존을 사용하십시오
  • 항상 UTF-8을 사용하십시오
  • 라이브러리를 만듭니다
  • 모니터링하는 법을 배우십시오
  • 명시 적은 암시적인 것보다 낫습니다
  • 회사는 전문가를 찾고 일반인을 더 오래 유지합니다
  • 사용자 데이터를 처리하는 가장 안전한 방법은이를 캡처하지 않는 것입니다.
  • 멈출 시간이되면 멈출 시간입니다
  • 코드 사용에 대한 책임이 있습니다
  • 그렇지 않을 때는 "완료"라고 말하지 마십시오
  • 사람들이 당신에게 어떻게 반응하는지주의를 기울이십시오
  • 미세한 공격을 조심하십시오
  • "내가 모르는 것들"의 목록을 유지하십시오.
• 당신이 좋은 프로그래머라는 징후 (여기의 모든 것이 훌륭하지는 않습니다. 포인트 중 일부는 비생산적입니다)
  • 먼저 실험하는 본능
  • 코드 및 디자인에서 감정적 분리
  • 깨지지 않은 것을 고치고 싶어합니다
  • 이해할 수없는 것에 매료되었습니다
  • 가르치도록 강요 받았다
  • 부패 할 수없는 인내
  • 완벽의 파괴적인 추구
  • 플랫폼의 백과 사전 파악
  • 코드로 생각합니다
  • 로마에있을 때는 로마인처럼됩니다
  • 자신의 도구를 만듭니다
  • 계층 구조에 무관심합니다
  • 실패에 흥분합니다
  • 상황에 무관심합니다
  • 헌신을위한 충동을 대체합니다
  • 경험에 의해 주도됩니다
• 7 절대적인 진실 나는 주니어 개발자로서 우리를 배우지 못했습니다
  • 경력 초기에 1 년 안에 지원 팀에서 10 배를 더 배울 수 있습니다.
  • 모든 회사에는 문제가 있으며 모든 회사에는 기술 부채가 있습니다.
  • 실제 경험이 부족한 주제에 대해 지나치게 의견을 제시하는 것은 매우 거만합니다.
  • 많은 회의는 실제 시나리오보다는 개념의 증거를 다룹니다.
  • 유산을 다루는 것은 완전히 정상입니다.
  • 아키텍처는 nitpicking보다 더 중요합니다.
  • 적절한 경우 문서를 통한 자동화에 중점을 둡니다.
  • 기술 부채를 갖는 것은 건강합니다.
  • 선임 엔지니어는 프로그래밍 외에도 많은 기술을 개발해야합니다.
  • 우리는 여전히 일부 지역에서 여전히 주니어입니다.
• 좋은 소프트웨어를 구축하는 방법
  • 기본 엔지니어링 관행에 대한 높은 수준의 요약.
  • 나쁜 소프트웨어의 근본 원인은 특정 엔지니어링 선택과 관련이 없으며 개발 프로젝트 관리 방식과 관련이 없습니다.
  • 플라톤 적으로 좋은 공학과 같은 것은 없습니다. 그것은 당신의 요구와 당신이 겪는 실제 문제에 달려 있습니다.
  • 소프트웨어는 정적 제품이 아니라 개발 팀의 집단적 이해의 살아있는 표현으로 취급되어야합니다.
  • 소프트웨어 프로젝트는 너무 작기 때문에 거의 실패하지 않습니다. 그들은 너무 커서 실패합니다.
  • 문제 진술로 가장 한 관료적 목표를 조심하십시오. 우리의 최종 목표가 시민의 삶을 더 좋게 만드는 것이라면, 우리는 그들의 삶을 악화시키는 것들을 명시 적으로 인정해야합니다.
  • 소프트웨어 구축은 실패를 피하는 것이 아닙니다. 좋은 것을 구축하는 데 필요한 정보를 얻기 위해 가능한 한 빨리 전략적으로 실패하는 것입니다.
• -10x 엔지니어가되는 방법
  • 10 명의 엔지니어의 출력을 무효화하십시오.
  • 기술 토론에서 10 명의 엔지니어를 인질로 잡으십시오.
  • 클라우드 비용으로 10 주간의 임금을 낭비합니다.
  • 나쁜 아키텍처에서 400 시간의 엔지니어링을 낭비합니다.
  • 400 시간의 버그 심사가 발생합니다.

기타 일반 자료 및 리소스 목록

다른 목록

• Liuchong/Awesome-Roadmaps : 선별 된 로드맵 목록.

서적

• 사기꾼의 핸드북 - $ 30. 저자로부터 : "CS 학위가 없습니까? 나도 그렇지 않습니다. 그래서 제가이 책을 썼습니다."
• 컴퓨터 과학 책

조항

• MR-MIG/EveryProgrammer-Should-know : 모든 소프트웨어 개발자가 알아야 할 (대부분) 기술적 인 것들.
• 유명한 소프트웨어 개발 법칙
• 아마존 빌더 도서관
  • 이 트위터 스레드에는 최고의 기사 목록이 있습니다.
• KDELDYCKE/AWESOME-FALSEHOM : 허위 프로그래머는 믿습니다
• 지옥/프로그래밍-토크
• Techyaks : 대화 목록
• 프로그래밍에 대한 생각을 바꾼 대화
• 모든 컴퓨터 과학 전공이 알아야 할 것
• Kamranahmedse/Developer-Roadmap
• mtdvio/Everyprogrammer-Should-Should-know : 모든 소프트웨어 개발자가 알아야 할 (대부분) 기술적 인 것들.
• 전문 소프트웨어 엔지니어에 대한 Mike Acton의 기대
• 그들이 소프트웨어 엔지니어링에 대해 가르치지 않은 것들
  • 도메인 지식은 코딩 기술보다 중요합니다
  • 코드는 보조입니다. 비즈니스 가치가 첫 번째입니다.
  • 당신은 대부분 불확실성으로 일합니다
• 우리는 단기 능력을 과대 평가하지만 장기 능력을 과소 평가합니다.
  • 전문화는 곤충을위한 것입니다.
• 기술 경력에서 불공정 한 이점을 원하십니까? 다른 역할을위한 내용을 소비합니다
  • 현대 기술 회사에서는 교차 기능 이해가 중요합니다
  • 중요성과 다른 역할을 과소 평가하지 않도록 도와줍니다.
  • 그 역할에있는 사람들과의 상호 작용에 전략을 세우는 데 도움이됩니다.
• 10 년 안에 자신에게 프로그래밍을 가르치십시오

공리

• 교훈 - 요소
  • 데이터는 코드보다 낫습니다.
  • 정확성은 성능보다 중요합니다.
  • 결정 론적 비트가 휴리스틱입니다.
  • 단순성의 백 라인은 20 줄의 복잡성보다 낫습니다.
  • 당신의 추상화가 유출되는 경우, 그것은 우주의 일부 법에 의한 것이 아닙니다. 당신은 단지 추상화를 빨아들입니다. 일반적으로 추상화를 좁게 지정하지 않았습니다.
  • 그 안에있는 악마를 깨우는 것을 두려워하기 위해 코드 섹션을 바꾸지 않으면 두려움에 살고 있습니다. 당신이 쓴 코드의 작은 부분의 편안한 범위에 머물러 있거나 잘 알고 있다면, 당신은 전설적인 코드를 작성하지 않을 것입니다. 모든 코드는 인간이 작성했으며 인간이 마스터 할 수 있습니다.
  • 무언가를하는 올바른 방법과 잘못된 방법이 있다면 올바른 방법으로하십시오. 코딩에는 놀라운 징계가 필요합니다.
  • 정답을 얻는 가장 좋은 방법은 잘못된 방식으로 시도하는 것입니다.
  • 연습은 상황이 좋거나 나쁘다는 것을 알려줍니다. 이론은 이유를 알려줍니다.
  • 문제를 해결할 자격이없는 것은 문제를 해결하지 않을 이유가 아닙니다.
  • 사용중인 시스템을 이해하지 못하면 제어하지 않습니다. 아무도 시스템을 이해하지 못하면 시스템이 제어됩니다.
• 임베디드 경험 규칙
• 내 인생을 바꾼 50 가지 아이디어
• 10,000 시간의 프로그래밍에 대한 반사
• 20 년 동안 소프트웨어 엔지니어로서 배운 20 가지

행동

• Google Tech Dev 가이드
• CS 교육의 실종 된 학기, MIT. 쉘, 편집자, 데이터 랭글 링, GIT, 디버깅 및 프로파일 링, 메타 프로그래밍, 보안 및 암호화에 대한 강의가 포함됩니다.
• 모험적인 자기 학습자, Neil Sainsbury를위한 수학
• Jwasham/Coding-Interview-University : 소프트웨어 엔지니어가되기위한 완전한 컴퓨터 과학 연구 계획.
• 자신에게 컴퓨터 과학을 가르치십시오 : 최고의 CS 리소스의 의견이 많은 세트.
• Ossu/Computer-Science : 컴퓨터 과학의 무료 교육 교육!

주제

알고리즘 및 데이터 구조

• CLRS를 읽으십시오. OCW에서 코스를보고 다운로드 할 수 있습니다. 최신 과정도 있습니다.
• 또는 알고리즘 디자인 매뉴얼
• Project Euler에 대한 알고리즘을 사용해보십시오
• CS 61B 스프링 2023

기타 리소스 :

• 알고리즘, Jeff Erickson

솔직히 말하면 알고리즘은 꽤 건조한 주제 일 수 있습니다. 이 Quora 질문은 다음을 포함하여 더 재미있는 학습 대안을 나열합니다.

• 그로킹 알고리즘
• 필수 알고리즘
• 데이터 구조 시각화
• ? 15 6 분 안에 알고리즘을 분류합니다
• 해싱
• 알고리즘 시각화
• B- 트리 및 데이터베이스 인덱스

예제 구현 :

• Trekhleb/JavaScript-Algorithms : JavaScript에서 구현 된 알고리즘 및 데이터 구조
• 알고리즘

분산 시스템의 알고리즘 :

• 뗏목 합의 알고리즘

API 설계 및 개발

일반적인 휴식 내용 :

• 건축 스타일 및 네트워크 기반 소프트웨어 아키텍처 설계, Roy Fielding (REST의 발명가)
• RESTFUL HTTP+JSON API를 구축하는 데 유용한 리소스 모음.
• REST API 디자인, 스택 오버플로 블로그에 대한 모범 사례
• 방해받지 않은 휴식 : 완벽한 API 설계에 대한 안내서 : RESTFUL API 디자인에 관한 매우 완전한 책.

예제 지침 :

• Microsoft의 REST API 지침
• Zalando RESTFUL API 및 이벤트 체계 지침
• Google의 API 디자인 가이드 : 디자인 네트워크 API를위한 일반 안내서.
• AIP-1 : AIP 목적 및 지침
  • AIP는 API 개발을위한 높은 수준의 간결한 문서를 제공하는 설계 문서 인 API 개선 제안을 나타냅니다.

보다 구체적인 주제 :

• 키가 아닌 링크를 사용하여 API, Martin Nally, Google의 관계를 나타내는 이유
  • "외국 키 대신 링크를 사용하여 API에서 관계를 표현하면 클라이언트가 API를 사용하기 위해 알아야 할 정보의 양을 줄이고 클라이언트와 서버가 서로 연결되는 방식을 줄입니다."
• Webhooks가 아닌 나에게 /이벤트를 줘
  • 이벤트는 WebHook 소비자가 WebHook 구독의 위치를 ​​재생하거나 재설정 할 수 있도록하는 등 필요한 WebHook 기능을 잠금 해제 할 수 있습니다.
• JSON 패치의 전력 잠금 해제

태도, 습관, 사고 방식

• 마스터 링 프로그래밍, 켄트 벡.
• 능숙한 프로그래머의 특성
• 프로그래밍의 TAO : 프로그래밍에 관한 일련의 비유 세트.
• 소유권을 갖는 것은 원하는 것을 얻는 가장 효과적인 방법입니다.
• 더 나은 개발자가 될 시간을 찾습니다
• 하루 10 분 : Alex Allain이 매일 10 분을 쓰면서 200 시간 이내에 책을 썼던 방법.
• 소프트웨어 엔지니어의 관리 및 수유 (또는 엔지니어가 심술 궂은 이유)
  • 소프트웨어, 제품 관리자, 디자이너 및 소프트웨어 엔지니어의 삼중주에서 엔지니어만이 창조적 인 마음을 끄고 생산해야합니다.
  • 엔지니어와 제품 관리자 모두 제품 사양 또는 요구 사항이 IKEA의 가구 매뉴얼과 동일하다고 생각하는 경향이 있습니다.
  • 이것은 엔지니어들을 괴상하게 만드는 가장 큰 것 중 하나입니다. 끊임없이 우선 순위를 변화시킵니다.
  • 많은 엔지니어들이 제품 관리자가 마음을 바꾸 었다고 불평하지만 시간 추정치에 거의 아무도 설명하지 않을 것입니다.
  • 컴퓨터 과학 프로그램은 업계에서 직면 할 작업을 준비하는 것이 아닙니다.
  • 사용될 수있는 것보다 더 많은 엔지니어가 있으면 엔지니어링 시간은 개발과 계획, 동기화 및 조정으로 멀어집니다.
  • 창의적인 과정에 엔지니어를 참여시킵니다
  • 엔지니어들에게 창의력을 발휘할 수있는 기회를 제공하십시오.
  • 쉬는 시간을 장려하십시오.
  • 코드를하자
  • 감사의 감사
• 제품을 생각하는 소프트웨어 엔지니어 인 Gergely Orosz
  • 훌륭한 제품 엔지니어는 최소한의 사랑스러운 제품에 올바른 깊이가 필요하다는 것을 알고 있습니다.
  • 제품을 생각하는 엔지니어는 가장자리 케이스를 신속하게 매핑하고 작업을 줄이는 방법을 생각합니다. 종종 엔지니어링 작업이 필요없는 솔루션을 가져옵니다.
  • 사용자 연구 및 고객 지원에 참여하십시오
  • 낙서 된 제품 제안을 테이블에 가져옵니다
  • 제품/엔지니어링 트레이드 오프를 제공합니다
• 40 년 후 40 개 교훈, Steve Schlafman
  • 가장 중요한 일을 진전시키려면 실망 할 사람을 결정해야합니다. 불가피합니다.
  • 당신이 할 수있는 최고의 투자는 자신의 교육입니다. 학습을 멈추지 마십시오. 당신이 할 수있는 두 번째로 최고의 투자는 정통적이고 의미있는 상호 작용을 통해 네트워크를 구축하는 것입니다. 그것은 당신이 아는 것과 당신이 아는 사람입니다.
  • 당신은 당신이 요구하지 않는 것을 얻지 못하거나 적극적으로 찾는 것을 결코 얻지 못할 것입니다. 가라!
  • 터널 끝의 빛에 관한 것이 아닙니다. 터널입니다. 매일 나타나서 과정을 즐기십시오.
  • 위대한 팀원은 항상 조직과 그 목적을 자신의 자기 이익보다 앞서 있습니다.
  • 당신의 반점을 선택하십시오. 우리는 시간이 제한되어 있으며 뇌는 그렇게 많이 처리 할 수 ​​있습니다. 초점이 핵심입니다. 현명하게 선택하십시오.
  • 모든 사람은 무언가로 어려움을 겪고있을 것입니다. 친절하십시오. 도움이됩니다.
• 코딩, 자아 및 관심에
  • 초보자의 마음은 절대 지식이 무한하다는 사실을 받아들입니다. 따라서 점수를 유지하는 것은 시간 낭비입니다.
  • 숙달은 지식의 축적이 아니라 단순히 운동량의 축적입니다.
  • 자아의 산만 함을 다루는 것은 문제 해결 과정을 좋아하는 것을 가르쳐주었습니다. 학습 과정을 사랑하고 존중하도록 가르쳐주었습니다. 결과적으로 나는 더 생산적입니다. 나는 덜 불안합니다. 나는 더 나은 팀원입니다. 나는 더 나은 친구이자 더 나은 사상가입니다.
• 고정 대 성장 : 우리의 삶을 형성하는 두 가지 기본 사고 방식
• 훌륭한 소프트웨어 엔지니어는 어떻게 생겼습니까?
• 좋은 수면, 좋은 학습, 좋은 삶
• ? Steve Jobs : 도움을 요청하지 않으면 멀지 않을 것입니다.
• 프로그래밍 견적
• 친절하십시오
  • 친절한 것은 근본적으로 주변 사람들에게 당신의 영향에 대한 책임을지는 것입니다.
  • 그것은 당신이 그들의 감정을 염두에두고 당신의 존재가 그들에게 영향을 미치는 방식을 배려해야합니다.
• 워렌 버핏은이 단순한 습관이 다른 사람들과 성공한 사람들을 분리한다고 말합니다.
  • 성공한 사람들과 실제로 성공한 사람들의 차이점은 실제로 성공한 사람들이 거의 모든 것에 대해 거부하지 않는다는 것입니다.
• 운이 좋은 방법?
• 프로그래머는 무능력 축하를 중단해야합니다
  • 프로그래밍의 마법은 주로 당신이 아직 모르는 것입니다.
  • 당신이 당신의 경력을 프로그래밍하려고한다면, 당신이 숙달을 향한 길을 가고 있지 않아야한다고 생각하는 것은 좋지 않습니다.
• 속도 제한이 없습니다
• 동기 부여를 기다리지 말고 운동량을 위해 행동하십시오
  • 작은 작업으로 시작하십시오. 그런 다음 운동량을 타십시오.
• 가장 중요한 코딩 습관
  • 가장 중요한 코딩 습관
  • 매일 스트레칭
  • 정기적으로 휴식을 취하십시오
  • 밤 늦게 코딩하지 마십시오
  • 코딩 환경을 개선하십시오
• 다른 모든 조언 에세이를 읽은 새로운 소프트웨어 개발자에 대한 조언
• 마이크로 서비스는 문제가되지 않습니다. 무능한 사람들이 있습니다

Imposter Syndrome은 과소 평가되었습니다. 많은 대화가 Imposter 증후군을 극복하기 위해 진행됩니다. 나는 자기 주방성을 받아들이고 매일 자신을 의심한다고 말합니다. 매년 많은 지식이 만료되는 빠르게 움직이는 산업에서, 주변의 가장 주니어 사람들조차도 당신이 가지고 있지 않은 기술을 끊임없이 요리합니다. 당신은 초보자의 결단력 (그리고 심지어 두려움조차도)을 적용하여 경쟁력을 유지합니다. 이 런닝 머신의 거꾸로 된 것은 모든 엔지니어가 그 위에 있다는 것입니다. 단지 당신이 사기꾼이기 때문에 다른 사람들이 당신보다 더 가치가 있다는 것을 의미하지는 않습니다. 당신은 자신을 옹호하고, 위험을 감수하고, 일이 잘 될 때 등을 가볍게 두드리고, 문제 해결에 대한 실적을 만들기 시작하면서 기술과 적응성을 신뢰해야합니다. 그냥 실수하지 마십시오. 당신은 당신이 해결 한 마지막 문제만큼 좋은 것입니다.

Dan Heller, 소프트웨어 경력 구축

나는 이미 내 글의 우물을 비우는 법을 이미 배웠지 만, 우물의 깊은 부분에 여전히 무언가가 있었을 때 항상 멈추고 밤에 그것을 먹이를주는 스프링에서 리필하도록했습니다. - 어니스트 헤밍웨이

• Grug Brained Developer : 자기 인식 프로그래머의 습관. 프로그래밍의 tao와 마찬가지로 스타일이 다릅니다.

좋은 판단은 경험에서 비롯됩니다. 경험은 나쁜 판단에서 비롯됩니다.

지연

• 뉴스는 당신에게 나쁘다 - 그리고 그것을 읽는 것을 포기하는 것은 당신을 더 행복하게 만들 것입니다, Guardian
  • 뉴스가 오도합니다
  • 뉴스는 관련이 없습니다
  • 뉴스에는 설명적인 힘이 없습니다
  • 뉴스는 신체에 독성이 있습니다
  • 뉴스는인지 오류를 증가시킵니다
  • 뉴스는 사고를 억제합니다
  • 뉴스는 마약처럼 작동합니다
  • 뉴스는 시간을 낭비합니다
  • 뉴스는 우리를 수동적으로 만듭니다
  • 뉴스는 창의성을 죽입니다

인증/승인

• 마이크로 서비스 세계에서의 승인
• 승인 논리 : 규칙은 시간이 지남에 따라 진화하기 때문에 어렵습니다.
• Copenhagen Book은 웹 응용 프로그램에서 인증 구현에 대한 일반적인 지침을 제공합니다.

오토메이션

• 자동화는 Ultron이 아닌 Iron Man과 같아야합니다

모범 사례

• 소프트웨어 엔지니어링 관행

소프트웨어 엔지니어링 및 무작위를 넘어서

• 소프트웨어 엔지니어가 목공을 좋아하는 이유

편견

편견은 채용에만 적용되지 않습니다. 예를 들어, 기본 속성 편향은 오래 전에 작성된 누군가의 코드를 완전히 다른 맥락에서 비판 할 때도 적용됩니다.

• 인지 바이어스 치트 시트. #hiring

사업

• 개발자에 대한 지불 101
• 수제 청구 시스템의 4 가지 가장 큰 문제
• ? 자신의 청구 시스템 구축의 14 가지 고통

은닉처

• 캐싱 도전과 전략, Amazon Builders Library

경력 성장

• 고위급 개발의 결합 된 삼각형은 선임 엔지니어를 정의하는 방법을 조사합니다.
• 엔지니어로서의 성장 원칙 인 Dan Heller.
• 자신을 프로그래머라고 부르지 마십시오. Patrick McKenzie.
• 엔지니어링 관리자가됩니다
• 내가 25 세에했던 경력 조언
  • 경력은 스프린트가 아닌 마라톤입니다
  • 대부분의 성공은 새로운 일이 아니라 반복에서 비롯됩니다
  • 일이 정말로 너무 위대했다면 부자들은 모든 사람들이 일자리를 가질 것입니다.
  • 경영진은 사물이 아니라 사람들에 관한 것입니다
  • 진정으로 다른 사람들의 말을 듣습니다
  • 직원은 유한 한 정서적 능력을 가진 사람들이라는 것을 인식하십시오
  • 자신의 나이를 사람들과 네트워크하지 마십시오
  • 작업 이유 때문에 개인 윤리를 희생하지 마십시오
  • 실패는 학습임을 인식합니다
• 내가 어렸을 때 내가 주었으면 좋겠어 커리어 조언
  • 장기 계획에 너무 집중하지 마십시오.
  • 좋은 사상가를 찾고 가장 존경하는 사람을 콜드 콜하십시오.
  • 전체 수명 동안 생산성에 높은 가치를 지정하십시오.
  • 당신의 최우선 과제가 아닌 것을 과도하게 최적화하지 마십시오.
  • 많이 읽고 주변 사람들이 읽지 않는 것을 읽으십시오.
  • 해결의 우선 순위를 정하는 문제에 대해 진지하게 반영하십시오.
  • 더 많은 역사를 읽으십시오.
• 좋은 개발자들이 불행, 로브 월링으로 홍보되는 이유. 또는 왜 경영진이 당신을위한 것이 아닐 수도 있습니다.
• 세계에서 가장 시급한 문제를 해결하는 데 도움이되는 경력 사용 안내서
• 선임 엔지니어의 직업은 무엇입니까? 당신은 단순한 개인 기고자 이상이어야합니다.
• 코딩 Bootcamp 졸업생부터 분산 데이터베이스 구축까지
  • 블로그 게시물이 아닌 책 (및 논문)을 읽으십시오
  • 경력 궤적에 대해 책임을 져야합니다
• ? 잘 둥근 엔지니어는 훌륭한 책 권장 사항을 많이 포함합니다.
  • 패러다임 Polyglot (다른 언어 및 패러다임 배우기)
  • 데이터베이스 Polyglot
  • 프로토콜 폴리 글 로트 (바람직하게는 TCP/IP 및 HTTP)
  • 빌드 툴링, 포장 및 배포 능력
  • 디버깅, 관찰 가능성
  • 배포, 인프라 및 개발자
  • 소프트웨어 아키텍처 및 스케일링
  • 장난감 컴파일러, 통역사 및 파서를 작성하는 기능
  • 장난감 게임을 작성하는 능력
  • 알고리즘 분석을 이해하는 능력
• 일부 경력 조언, Will Larson.
  • 당신이 얻는 조언은 세계가 어떻게 작동하는지에 대한 정확한 진술이 아니라 자신의 경험을 종합하려는 누군가의 시도입니다.
  • 명성의 저수지를 구축하십시오.
  • 어떤 사람들은 너무 능숙한 무언가에 능숙하여 현재의 역할에서 대체 할 수 없어서 더 흥미로운 후보자라도 자신의 역할에 갇히게됩니다.
  • 훌륭한 관계는 당신이가는 곳마다 당신을 따라갈 것입니다. 나쁜 것들도.
  • 경력 초기에 다양한 종류의 회사에서 일하고 가능한 한 다른 제품에서 일하십시오.
• 사악한 팁 : "쉬운"것들을 피하십시오
• 궁극적 인 코드 카타
• 선임 소프트웨어 엔지니어의 특성 : 영향, 인식, 가시성, 영향, 멘토링
• 소프트웨어 엔지니어링 - 부드러운 부품
  • 비판적으로 생각하고 합리적 인 주장을 공식화하십시오
  • 기본을 마스터하십시오
  • 사용자에 집중하면 다른 모든 것이 따를 것입니다
  • 배우는 방법을 배우십시오
• 소프트웨어 엔지니어로서의 성장을 소유하는 방법
• 40 년 프로그래머
  • 더 좋아질수록 다른 사람들처럼 덜 보입니다.
  • 당신은 기본 사항을 수행하여 깊은 원칙을 배웁니다
  • 다른 분야를보고 다른 분야에서 배우십시오
  • 생산성 팁에주의하십시오
• 선임 엔지니어들은 미래에 살고 있습니다
• 당신의 경력지도는 어떻게 생겼습니까?
• 아마존에서 성공하는 방법 (또는 그 문제에 대한 다른 대기업)

선임 엔지니어 소개 :

• 거짓 주니어 개발자들은 선배가되는 것에 대해 믿습니다

다음/첫 번째 기회를 선택하십시오

• 경력 결정 - Elad Gil -Elad 블로그

직원 Eng에 가십시오

• 나는 5 년 만에 Faang 직원 엔지니어가되었습니다. 이것들은 제가 그 과정에서 배운 14 개 교훈입니다.
  • 소프트웨어 엔지니어링은 단순히 코딩이 아닙니다. 실제로 코딩은 그것의 작은 부분입니다.
  • 파이프 라인 작업
  • 피드백에 열려 있고 듣습니다. 진지하게, 듣습니다.
  • 훌륭한 피드백은 찾기가 어렵습니다. 그것을 소중히여십시오.
  • 수평선을 주시하십시오 (둘 다가 아님).
  • 중요한 것이 무엇인지 알아 내고 나머지는 놓아 두십시오.
  • 비교는 정말 기쁨의 도둑입니다.
  • 멘토링은 아름다운 것입니다.
  • 좋은 날은 일반적으로 단지“일어나는”것이 아닙니다.
  • 조언과지도는 바로 그 것입니다. 그들은 규칙이 아닙니다.
• 직원 플러스 엔지니어링 역할에 도달하기위한 가이드, Will Larson
  • 눈에 띄고 있습니다
  • 직원 플러스 엔지니어링에 대한 추가 리소스

문자 세트

• 모든 소프트웨어 개발자는 절대적으로 절대적으로, 유니 코드 및 문자 세트에 대해 긍정적으로 알아야합니다 (변명 없음!)
• 모든 소프트웨어 개발자가 2023 년 유니 코드에 대해 알아야하는 절대 최소 (여전히 변명은 없습니다!)

체스

(예 - 체스는 자체 섹션을 얻습니다 :)

• Chessprogramming Wiki
• 체스가 압축됩니다

구름

• Open-Guides/OG-Aws : AWS에 대한 실용 가이드

코드 리뷰

• 코드 검토 방법, Google의 엔지니어링 연습 문서.
• 커미트 후 리뷰 : 개발자 속도를 높이는 흥미로운 아이디어 (일부 경고가 있습니다).
• 코드 리뷰어가 당신과 사랑에 빠지게하는 방법
  • 먼저 자신의 코드를 검토하십시오
  • 명확한 변화주의 설명을 작성하십시오
  • 쉬운 물건을 자동화하십시오
  • 코드 자체로 질문에 답하십시오
  • 범위가 좁습니다
  • 기능적 및 비 기능적 변경
  • 비판에 은혜롭게 대응합니다
  • 누락 된 정보를 예술적으로 요청하십시오
  • 검토 자에게 모든 관계를 수여하십시오
  • 검토 라운드 사이의 지연을 최소화하십시오
• 인간처럼 코드 리뷰를하는 방법
• HN : 코드를 어떻게 검토합니까? : 흥미로운 아이디어로 가득 찬 hackernews에 대한 훌륭한 토론.
• 코드 리뷰의 Maslow의 피라미드
  • 같은 주제에 대한 다른 하나 : 코드 검토 피라미드
• 원격 팀의 코드 검토 : 매우 완전한 규칙 세트.
• 기본적으로 코드 검토가 없습니다
  • 협약에 대한 책임

코딩 및 코드 품질

• 삭제하기 쉽고 확장하기 쉽지 않은 코드 작성
• Egoless 프로그래밍의 십계명
• CLEAN CODE : Agile Software Creftsmanship의 핸드북, Robert C. Martin. 수많은 유용한 모범 사례를 설명합니다. 조금 길다. 깨끗한 코드 치트 시트도 있습니다.
• 소프트웨어 장인 정신에 관한 것
  • 우리는 쓰레기를 쓰는 데 지쳤습니다.
  • 우리는 나중에 물건을 청소하는 것에 대해 어리석은 오래된 거짓말을 받아들이지 않을 것입니다.
  • 우리는 빠른 의미가 더러워진다는 주장을 믿지 않을 것입니다.
  • 우리는 누군가가 비전문가로 행동하도록 강요하지 않을 것입니다.
• 부울 변수 이름 지정에 대한 팁
  • 부울 변수와 "is"또는 "has"와 함께 함수 이름을 접두하는 규칙이 있습니다.
  • 복수의 경우에도 항상 사용하려고 시도하십시오 ( isEachUserLoggedIn areUsersLoggedIn 또는 isUsersLoggedIn 보다 낫습니다).
  • 사용자 정의 접두사를 피하십시오 ( isPaidFor wasPaidFor 보다 낫습니다)
  • 부정적인 것을 피하십시오 ( isEnabled isDisabled 보다 낫습니다)
• 인재 할 수없는 코드를 작성하는 방법
• kettanaito/naming-cheatsheet : : 변수 이름 지정에 대한 포괄적 인 언어 공유 지침. A/HC/LC 패턴의 홈.
• ? 품질 엔지니어링 가이드

의사소통

글쓰기 섹션도 참조하십시오

• 개발자로서 효과적으로 의사 소통하는 방법
  • 짧은, 중간 및 장기 글쓰기를위한 많은 구체적인 조언과 예제
• 프로그래밍 중에 무엇을 시각화합니까?

컴파일러

• 컴파일러 라이터 리소스 페이지
• Kanaka/Mal : Mal- Lisp를 만듭니다

구성

• 구성 파일에 대한 JSON의 단점, Martin Tournoij.
  • 주석을 추가 할 수 없습니다
  • 과도한 견적 및 구문 노이즈
  • 로직을 제어하기 위해 DC (선언 구성)를 사용하는 것은 종종 좋은 생각이 아닙니다.
• 당신의 구성이 빨다? 실제 프로그래밍 언어를 사용해보십시오
  • 대부분의 최신 구성 형식이 빨라집니다
  • 실제 프로그래밍 언어를 사용하십시오

연속 통합 (CI)

• 지속적인 통합, martinfowler.com

데이터베이스

SQL 섹션도 참조하십시오.

• 캡 정리에 대한 평범한 영어 소개
• Pacelc 정리 : "분산 컴퓨터 시스템에서 네트워크 파티셔닝 (P)의 경우 가용성 (a)와 일관성 (c) (캡 정리에 따라)을 선택해야하지만 시스템이 시스템이있을 때에도 (E)를 선택해야합니다. 파티션이 없을 때 정상적으로 실행 중이며 대기 시간 (L)과 일관성 (C) 중에서 선택해야합니다. "
• 제로 다운 타임 데이터베이스 마이그레이션 (코드 예제는 레일을 사용하고 있지만 모든 프로그래밍 언어에 적합합니다).
• 최신 스토리지 시스템의 알고리즘, ACM 큐
• 간단한 데이터베이스를 구축합시다
• 데이터베이스 시스템의 읽기, 5 판
• 데이터베이스 유형 비교 : 데이터베이스 유형이 다른 요구를 충족하도록 진화하는 방법
• 관계형 데이터베이스는 어떻게 작동합니까?
• 인덱스, 루크를 사용하십시오
• 코스 소개 - 개발자를위한 MySQL, PlanetScale
• 쿼리 엔진 작동 방식
• 아마도 당신이 아마도 sqlite |를 사용해야 하는가 서사시 웹 개발자

NOSQL

• NOSQL 패턴
• NOSQL 데이터베이스 : 설문 조사 및 의사 결정 지침
• DynamoDB 문서에는 몇 가지 훌륭한 페이지가 있습니다.
  • 일관성을 읽으십시오
  • SQL에서 NOSQL로
  • DynamoDB 용 NOSQL 디자인
• Redis는 설명했다

포스트 그레스

• 대량의 PostgreSQL에 대한 안전한 작업 (이것은 PostgreSQL이지만 다른 DBS에도 적합합니다).
• Postgres의 거래 격리
• PostgreSQL 연습
• Postgres 작업 치트 시트
• Postgres 만 사용하십시오
• Postgres로 충분합니다
• Postgres : 이것을하지 마십시오
• 기본 키로 PostgreSQL 및 UUID

데이터 형식

• 허위 프로그래머는 전화 번호, Google의 libphonenumber 에 대해 믿습니다.
• 자동 완성 규칙 : 자동 완성 필드에 대한 거친 사양
• 허위 프로그래머는 주소에 대해 믿습니다
• 허위 프로그래머는 이름에 대해 믿습니다
• KDELDYCKE/AWESOME-FALSEHOM : 허위 프로그래머는 믿습니다
• UUID, ulids 및 문자열 표현을 이해합니다
• 허위 프로그래머는 거짓 목록에 대해 믿습니다
• Australia/Lord_howe는 가장 이상한 시간대입니다

데이터 과학/데이터 엔지니어링

• Dirty Dozen : 온라인 통제 실험에서 12 개의 일반적인 메트릭 해석 함정
• DataStackTV/Data-Engineer-Roadmap : 데이터 엔지니어가되는 로드맵
• 멋진 데이터 엔지니어링 학습 경로
• 현대 데이터 인프라를위한 새로운 아키텍처
• 모 놀리 식 데이터 호수를 넘어 분산 데이터 메쉬로 이동하는 방법
  • Data Lake 아키텍처를 기반으로 한 데이터 플랫폼에는 일반적인 실패 모드가 있으며 규모가 저렴한 약속으로 이어집니다.
  • 도메인을 일등석 문제로 고려하고 플랫폼 사고를 적용하여 셀프 서비스 데이터 인프라를 만들고 데이터를 제품으로 취급해야합니다.
• mlops
• Uber의 빅 데이터 플랫폼 : 미세한 대기 시간이있는 100 개 이상의 페타 바이트
• SQL은 데이터 변환 로직의 기본 선택 여야합니다.

디버깅

이 문서의 사고 응답 섹션도 참조하십시오

• 고무 오리 문제 해결
• 고무 오리
• 다섯 날
• 다섯 가지가 있습니다
  • 실제 문제는 기술이 템플릿의 일부가되면 스스로를 나타냅니다.
  • 액션 항목은 근본 원인에서 매우 먼 것일 수 있습니다.
• 무한한 방법은 다섯 whys 방법을 비판하고 사건에서 가장 많이 배울 수있는 다른 질문 세트를 옹호합니다.
  • 참조 : 인적 오류 : 모델 및 관리
  • "5 개의 이유의 문제는 작업이 어떻게 이루어지고 이벤트가 발생하는지에 대한 선형적이고 단순한 설명으로 터널로 분비된다는 것입니다."
  • "인간 오류는 결론이 아니라 출발점이됩니다." (Dekker, 2009)
  • "우리가 '어떻게?'를 물을 때, 우리는 이야기를 요구합니다."
  • "결정과 행동에 관해서는, 우리는 누군가가 자신이 한 일을하는 것이 어떻게 의미가 있는지 알고 싶어합니다."
  • 각 "왜"단계에서는 추가 조사를 위해 하나의 답변 만 선택됩니다. "어떻게"묻는 것은 더 넓은 탐험을 장려합니다.
  • "사고 조사에서 대부분의 다른 인간의 노력에서와 같이, 우리는 당신이 무엇을 찾아 내고, 당신의 찾기 또는 wylfiwyf 원칙에 빠지는 것입니다. 이것은 우리가 무엇인지에 대한 가정이 있다는 사실을 간단하게 인식합니다. (당신이 무엇을 볼 수 있는지), 우리가 실제로 찾은 것을 결정할 것입니다 (무엇을 찾는 지) " (Hollnagel, 2009, p. 85) (Wylfiwyf 그림 참조)
  • "A final reason why a 'root cause' may be selected is that it is politically acceptable as the identified cause. Other events or explanations may be excluded or not examined in depth because they raise issues that are embarrassing to the organization or its contractors or are politically unacceptable." (Nancy Leveson, Engineering a Safer World, p. 20)
  • Bounded rationality: rational individuals will select a decision that is satisfactory rather than optimal
  • The article provide concrete ways and questions to solicit stories from people, which will yield better insights.
    • What were you expecting to happen?
    • If you had to describe the situation to your colleague at that point, what would you have told?
    • Did this situation fit a standard scenario?
    • What were you trying to achieve?Were there multiple goals at the same time?Was there time pressure or other limitations on what you could do?
    • See template here
• Linux Performance Analysis in 60,000 Milliseconds
• Post-Mortems at HubSpot: What I Learned From 250 Whys
• Debugging zine, Julian Evans
• If you understand a bug, you can fix it
• The Thirty Minute Rule: if anyone gets stuck on something for more than 30 minutes, they should ask for help
• How to create a Minimal, Reproducible Example , Stack Overflow
• Some ways to get better at debugging, Julia Evans
  • Learn the codebase
  • Learn the system (eg, HTTP stack, database transactions)
  • Learn your tools (eg, strace , tcpdump )
  • Learn strategies (eg, writing code to reproduce, adding logging, taking a break)
  • Get experience: according to a study, "experts simply formed more correct hypotheses and were more efficient at finding the fault."
• What exactly is the 'Saff Squeeze' method of finding a bug?
  • A systematic technique for deleting both test code and non-test code from a failing test until the test and code are small enough to understand.
• tcpdump is amazing, Julia Evans
• What we talk about when we talk about 'root cause'

Design (visual, UX, UI, typography)

I highly recommend reading The Non-Designer's Design Book. This is a pretty short book that will give you some very actionable design advices.

• If you're working on data, Edward Tufte's The Visual Display of Quantitative Information is considered a classic.
• The Universal Principles of Design will give you enough vocabulary and concepts to describe design challenges into words.
• Book recommendations from HackerNews
• ?Design for Non-Designers

Articles :

• 10 Usability Heuristics Every Designer Should Know
  • Visibility of System Status
  • The Match Between The System And The Real World
  • Every system should have a clear emergency exit
  • Don't forget that people spend 90% of their time interacting with other apps
  • Recognition Rather Than Recall (recognition = shallow form of retrieval from memory, eg a familiar person, recall = deeper retrieval)
  • ”Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery
  • Help Users Recognize, Diagnose, And Recover From Errors
• How to pick more beautiful colors for your data visualizations
• Visual design rules you can safely follow every time

Typograhy: see "Typography" section

자원:

• ? bradtraversy/design-resources-for-developers: design and UI resources from stock photos, web templates, CSS frameworks, UI libraries, tools...

Design (OO modeling, architecture, patterns, anti-patterns, etc.)

Here's a list of good books:

• Design Patterns: Elements of Reusable Object-Oriented Software: dubbed "the gang of four", this is almost a required reading for any developer. A lot of those are a bit overkill for Python (because everything is an object, and dynamic typing), but the main idea (composition is better than inheritance) definitely is a good philosophy.
  • And their nefarious nemesis Resign Patterns
• Patterns of Enterprise Application Architecture: learn about how database are used in real world applications. Mike Bayer's SQLAlchemy has been heavily influenced by this book.
• Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans
• Clean Architecture, Robert C. Martin. Uncle Bob proposes an architecture that leverages the Single Responsibility Principle to its fullest. A great way to start a new codebase. Also checkout the clean architecture cheatsheet and this article.
• Game Programming Patterns: a book about design, sequencing, behavioral patterns and much more by Robert Nystrom explained through the medium of game programming. The book is also free to read online here.

One of the absolute references on architecture is Martin Fowler: checkout his Software Architecture Guide.

조항:

• O'Reilly's How to make mistakes in Python
• Education of a Programmer: a developer's thoughts after 35 years in the industry. There's a particularly good section about design & complexity (see "the end to end argument", "layering and componentization").
• Domain-driven design, Wikipedia.
• On the Spectrum of Abstraction ?, Cheng Lou
• The “Bug-O” Notation, Dan Abramov
• Antipatterns
• Inheritance vs. composition: a concrete example in Python. Another slightly longer one here. One last one, in Python 3.
• Composition Instead Of Inheritance
• Complexity and Strategy: interesting perspective on complexity and flexibility with really good examples (eg Google Apps Suite vs. Microsoft Office).
• The Architecture of Open Source Applications
• The Robustness Principle Reconsidered
  • Jon Postel: "Be conservative in what you do, be liberal in what you accept from others." (RFC 793)
  • Two general problem areas are impacted by the Robustness Principle: orderly interoperability and security.
• Basics of the Unix Philosophy, Eric S Raymond
• Eight Habits of Expert Software Designers: An Illustrated Guide

You can use an eraser on the drafting table or a sledge hammer on the construction site. (Frank Lloyd Wright)

자원:

• ? Design Principles

Design: database schema

• A humble guide to database schema design, Mike Alche
  • Use at least third normal form
  • Create a last line of defense with constraints
  • Never store full addresses in a single field
  • Never store firstname and lastname in the same field
  • Establish conventions for table and field names.

Design: patterns

• KeystoneInterface, Martin Fowler.
  • Build all the back-end code, integrate, but don't build the user-interface
• 101 Design Patterns & Tips for Developers
• Python Design Patterns: For Sleek And Fashionable Code: a pretty simple introduction to common design patterns (Facade, Adapter, Decorator). A more complete list of design patterns implementation in Python on Github.
• SourceMaking's Design Patterns seems to be a good web resource too.
• Anti-If: The missing patterns

Design: simplicity

• Simple Made Easy ?, Rich Hickey. This is an incredibly inspiring talk redefining simplicity, ease and complexity, and showing that solutions that look easy may actually harm your design.

Dev environment & tools

• ? Awesome Dev Env

도구

• Glances: An eye on your system
• HTTPie: a CLI, cURL-like tool for humans
• jq: command-line JSON processor
• tmux: terminal multiplexer
• htop: an interactive process viewer for Linux
• htop explained
• socat
• Visual guide to SSH tunnels
• casey/just: a command runner written in Rust (claims to be better than Makefile)
• Gazr: an opinionated way to define your Makefile

Article about tools:

• The return of fancy tools
  • Simple tools make you think a little more
  • Drucker: "I'm not writing it down to remember it later, I'm writing it down to remember it now."
  • Frictionless note-taking produces notes, but it doesn't produce memory.

도커

See also the Python-specific section in charlax/python-education.

• Best Practices Around Production Ready Web Apps with Docker Compose
  • Avoiding 2 Compose Files for Dev and Prod with an Override File
  • Reducing Service Duplication with Aliases and Anchors
  • Defining your HEALTHCHECK in Docker Compose not your Dockerfile
  • Making the most of environment variables
  • Using Multi-stage builds to optimize image size
  • Running your container as a non-root user
• Docker Best Practices for Python Developers
  • Use multi-stage builds
  • Pay close attention to the order of your Dockerfile commands to leverage layer caching
  • Smaller Docker images are more modular and secure (watch out for Alpine though)
  • Minimize the number of layers ( RUN , COPY , ADD )
  • Use unprivileged containers
  • Prefer COPY over ADD
  • Cache python packages to the docker host
  • Prefer array over string syntax
  • Understand the difference between ENTRYPOINT and CMD
  • Include a HEALTHCHECK instruction
  • Whenever possible, avoid using the latest tag.
  • Don't store secrets in images
  • Use a .dockerignore file (include **/.git , etc.)
  • Lint and Scan Your Dockerfiles and Images (eg with hadolint )
  • Log to stdout or stderr
• Docker Containers Security

선적 서류 비치

• Documentation-Driven Development
• Writing automated tests for your documentation: this should be required, IMO. Testing code samples in your documentation ensures they never get outdated.
• ? Documentation is king, Kenneth Reitz
• Keep a Changelog
• Architectural Decision Records (ADR): a way to document architecture decision.
• Documenting Architecture Decisions
• joelparkerhenderson/architecture-decision-record: examples and templates for ADR.
  • And a CLI tool: npryce/adr-tools
• The documentation system
• Checklist for checklists
• Best practices for writing code comments
• Always be quitting
  • Document your knowledge
  • Train your replacement
  • 대리자
  • By being disposable, you free yourself to work on high-impact projects.
• Write documentation first. Then build.
• Diátaxis: a systematic approach to technical documentation authoring
  • There are four modes: tutorials, how-to guides, technical reference and explanation
  • The docs goes into a lot of details about each model.
• ARCHITECTURE.md
• Two open source projects with great documentation (esbuild and redis)

The palest ink is more reliable than the most powerful memory. -- Chinese proverb

Dotfiles

• ? Awesome dotfiles: lots of great dotfiles.
• My dotfiles

조항

• Setting Up a Mac Dev Machine From Zero to Hero With Dotfiles

Editors & IDE

• Sublime Text essential plugins and resources
• Bram Moolenaar (Vim author), Seven habits of effective text editing (presentation). This is about Vim but it contains good lessons about why investing time in learning how to be productive with your text editors pays off.
• VScode is one of the most popular text editors as of writing.
  • Visual Studio Code Can Do That?, Smashing Magazine.
• Coding with Character

정력

• ? vim-awesome
• ? Vimcasts
• ️ Is Vim Really Not For You? A Beginner Guide
  • The first part of a series of 6 articles with lots of detailed and practical tips for using Vim efficiently.
  • A Vim Guide for Advanced Users: more advanced shortcuts and commands
• Learning the vi and Vim Editors
• Practical Vim, Drew Neil
• Learn Vimscript the Hard Way
• VimGolf: nice challenges to learn Vim
• Vim anti-patterns
• Learn Vim For the Last Time: A Tutorial and Primer
• Vim Cheat Sheet & Quick Reference
• History and effective use of Vim
• Moving Blazingly Fast With The Core Vim Motions
• micahkepe/vimtutor-sequel: Vimtutor Sequel - Advanced Vim Tutor Lessons
• Vim Racer - An Online Game for VIM Navigation

Feel free to check my vim configuration and my vim cheatsheet.

Other editors:

• Use GNU Emacs

이메일

• Email explained from first principles
• ? Transactional Email Best Practices

Engineering management

Checkout my list of management resources.

수업 과정

The best way to learn is to learn by doing.

• build-your-own-x: compilation of well-written, step-by-step guides for re-creating our favorite technologies from scratch
  • Richard Feynman: "what I cannot create, I do not understand"
• The elevator programming game
• Challenging projects every programmer should try, Austin Z. Henley
• Challenging projects every programmer should try: text editor, space invaders, compiler (Tiny Basic), mini OS, spreadsheet, video game console emulator.
• More challenging projects every programmer should try: ray tracer, key-value store web API, web browser, stock trading bot.
• Let's Build a Regex Engine
• Write a time-series database engine from scratch
• 7 GUIs to build to learn fundamental UI programming skills
• A list of programming playgrounds, Julia Evans
• Write more "useless" software

관행:

• CodinGame
• Codewars
• 운동주의

Experimentation

• 8 annoying A/B testing mistakes every engineer should know

Functional programming (FP)

• Goodbye, Object Oriented Programming
• Functional Programming & Haskell ?: some good reasons to learn FP!
• Functional Programming Fundamentals: short introduction to FP and its advantages.
• OO vs FP, Robert C. Martin, The Clean Code Blog. A pretty interesting take on the differences between OOP and FP from an expert in OOP.
  • OO is not about state. Objects are bags of functions, not bags of data.
  • Functional Programs, like OO Programs, are composed of functions that operate on data.
  • FP imposes discipline upon assignment.
  • OO imposes discipline on function pointers.
  • The principles of software design still apply, regardless of your programming style. The fact that you've decided to use a language that doesn't have an assignment operator does not mean that you can ignore the Single Responsibility Principle.
• Parse, don't validate
  • Use a data structure that makes illegal states unrepresentable
  • Push the burden of proof upward as far as possible, but no further
  • Let your datatypes inform your code, don't let your code control your datatypes
  • Don't be afraid to parse data in multiple passes
  • Avoid denormalized representations of data, especially if it's mutable
  • Use abstract datatypes to make validators “look like” parsers
• ? 기능적 프로그래밍
• Monads in 15 minutes
• hemanth/functional-programming-jargon: jargon from the functional programming world in simple terms
• The definitive guide to learning functional programming, Exercism

Games development

• Introduction · Joys of Small Game Development

제도법

• Text Rendering Hates You

하드웨어

• NandGame: build a computer from scratch.
• What Every Programmer Should Know About SSDs
• How To Make A CPU - A Simple Picture Based Explanation

http

• Choosing an HTTP Status Code — Stop Making It Hard
• HTTPWTF
• 10 Surprising Things You Didn't Know About HTTP
• The HTTP crash course nobody asked for

기분

• The Jeff Dean Facts
  • Compilers don't warn Jeff Dean. Jeff Dean warns compilers.
  • Unsatisfied with constant time, Jeff Dean created the world's first O(1/N) algorithm.
  • Jeff Dean mines bitcoins. In his head.
• The Daily WTF: Curious Perversions in Information Technology

Incident response (oncall, alerting, outages, firefighting, postmortem)

Also see this section on my list of management resources, "Incident response".

Also see the Debugging section in this doc.

• Incident Response at Heroku
  • Described the Incident Commander role, inspired by natural disaster incident response.
  • Also in presentation: Incident Response Patterns: What we have learned at PagerDuty - Speaker Deck
• The Google SRE book's chapter about oncall
• Writing Runbook Documentation When You're An SRE
  • Playbooks “reduce stress, the mean time to repair (MTTR), and the risk of human error.”
  • Using a template can be beneficial because starting from a blank document is incredibly hard.
  • The Curse of Knowledge is a cognitive bias that occurs when someone is communicating with others and unknowingly assumes the level of knowledge of the people they are communicating with.
  • Make your content easy to glance over.
  • If a script is longer than a single line, treat it like code, and check it into a repository to be source control and potentially tested.
• Incident Review and Postmortem Best Practices, Gergely Orosz
• Computer Security Incident Handling Guide, NIST
• Incident Management Resources, Carnegie Mellon University
• Sterile flight deck rule, Wikipedia
• Shamir Secret Sharing It's 3am.
• Site Reliability Engineering and the Art of Improvisation has lots of good training ideas
  • Walkthroughs of observability toolsets
  • Decision requirements table building
  • Team knowledge elicitation
  • Asking the question, “Why do we have on-call?”
  • Spin the Wheel of Expertise!

Alerting:

• My Philosophy On Alerting
  • Pages should be urgent, important, actionable, and real.
  • Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring.
  • Symptoms are a better way to capture more problems more comprehensively and robustly with less effort.
  • Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes.
  • The further up your serving stack you go, the more distinct problems you catch in a single rule. But don't go so far you can't sufficiently distinguish what's going on.
  • If you want a quiet oncall rotation, it's imperative to have a system for dealing with things that need timely response, but are not imminently critical.
  • This classical article has now become a chapter in Google's SRE book.
• ? The Paradox of Alerts: why deleting 90% of your paging alerts can make your systems better, and how to craft an on-call rotation that engineers are happy to join.

검시

• A great example of a postmortem from Gitlab (01/31/2017) for an outage during which an engineer's action caused the irremediable loss of 6 hours of data.
• Blameless PostMortems and a Just Culture
• A list of postmortems on Github
• Google's SRE book, Postmortem chapter is excellent and includes many examples.
• Human error models and management
  • High reliability organisations — which have less than their fair share of accidents — recognise that human variability is a force to harness in averting errors, but they work hard to focus that variability and are constantly preoccupied with the possibility of failure

"Let's plan for a future where we're all as stupid as we are today."

– Dan Milstein

Example outline for a postmortem:

• Executive Summary
  • 영향
  • Root cause
• 영향
  • Number of impacted users
  • Lost revenue
  • 지속
  • Team impact
• 타임 라인
  • 발각
  • 해결
• Root cause analysis
  • Eg with 5 whys method
• Lessons learned
  • Things that went well
  • Things that went poorly
• Action items (include direct links to task tracking tool)
  • Tasks to improve prevention (including training)
  • Tasks to improve detection (including monitoring and alerting)
  • Tasks to improve mitigation (including emergency response)

인터넷

• How Does the Internet Work?
• How the web works
• Advice to young web developers

Interviewing

Note: this is about you as an interviewee, not as an interviewer. To check out my list of resources for interviewers, go to my engineering-management repository.

• System design interview for IT company
• Technical Interview Megarepo: study materials for SE/CS technical interviews
• How to Win the Coding Interview
• I spent 3 months applying to jobs after a coding bootcamp. Here's what I learned.
• Top 10 algorithms in Interview Questions
• Interactive Python coding interview challenges
• Tech Interview Handbook
• A complete computer science study plan to become a software engineer
• Interview advice that got me offers from Google, Microsoft, and Stripe
• A framework for grading your performance on programming interview problems
• Preparing for the Systems Design and Coding Interview, Gergely Orosz
• What I Learned from Doing 60+ Technical Interviews in 30 Days
• System Design Interview Guide for Senior Engineers, interviewing.io

Questions you should ask:

• Questions to ask your interviewer
• Questions to ask the company during your interview
• Interviewing the Interviewer: Questions to Uncover a Company's True Culture
• Twipped/InterviewThis: questions to ask prospective employers
• tBaxter/questions-for-employers: A big collection of useful questions to ask potential employers.

재개하다:

• The Red Flags on Your Resume
• What we look for in a resume
  • We look for demonstrated expertise, not keywords
  • We look for people who get things done
  • We look for unique perspectives
  • We care about impact, not meaningless metrics
• Why you shouldn't list certifications on LinkedIn

See also the exercises section in this document.

Kubernetes

• OWASP/www-project-kubernetes-top-ten
• Kubernetes Tutorial for Beginners: Basic Concepts

Large Language Model (LLM)

• What Is ChatGPT Doing… and Why Does It Work?, Stephen Wolfram
• Embeddings: What they are and why they matter

Learning & memorizing

Learn how to learn!

• How I Rewired My Brain to Become Fluent in Math: subtitled the building blocks of understanding are memorization and repetition .
• One Sure-Fire Way to Improve Your Coding: reading code!
• Tips for learning programming
• You can increase your intelligence: 5 ways to maximize your cognitive potential: forgive the clickbait title, it's actually a good article.
• How to ask good questions, Julia Evans.
• Stop Learning Frameworks
• Learning How to Learn: powerful mental tools to help you master tough subjects
• Why books don't work, Andy Matuschak.
  • "As a medium, books are surprisingly bad at conveying knowledge, and readers mostly don't realize it."
  • "In learning sciences, we call this model “transmissionism.” It's the notion that knowledge can be directly transmitted from teacher to student, like transcribing text from one page onto another. If only!"
  • "By re-testing yourself on material you've learned over expanding intervals, you can cheaply and reliably commit huge volumes of information to long-term memory."
• Strategies, Tips, and Tricks for Anki: those advices work for any tool actually
  • Add images. Our brains are wired visually, so this helps retention.
  • Don't add things you don't understand.
  • Don't add cards memorizing entire lists.
  • Write it out. For wrong answers, I'll write it on paper. The act of writing is meditative. I really enjoy this.
  • Keep on asking yourself why? why does this work? why does it work this way? Force yourself to understand the root of a topic.
  • Cornell Method: when reading a topic, write out questions on the margins to quiz yourself.
  • Pretend you have to teach it
  • Use mnemonics phrases like PEMDAS for lists and other hard-to-remember topics.
  • Delete cards that don't make sense or you don't want to remember anymore.
• Effective learning: Twenty rules of formulating knowledge
  • Build upon the basics
  • Stick to the minimum information principle: the material you learn must be formulated in as simple way as it is
  • Cloze deletion is easy and effective: Kaleida's mission was to create a ... It finally produced one, called Script X. But it took three years
  • Graphic deletion is as good as cloze deletion
  • Avoid sets
  • Avoid enumerations
  • Combat interference - even the simplest items can be completely intractable if they are similar to other items. Use examples, context cues, vivid illustrations, refer to emotions, and to your personal life
  • Personalize and provide examples - personalization might be the most effective way of building upon other memories. Your personal life is a gold mine of facts and events to refer to. As long as you build a collection for yourself, use personalization richly to build upon well established memories
  • Provide sources - sources help you manage the learning process, updating your knowledge, judging its reliability, or importance
  • Prioritize - effective learning is all about prioritizing.
• How to Remember Anything You Really Want to Remember, Backed by Science
  • Quiz yourself
  • Summarize and share with someone else.
  • Connect what you just learned to experiences you previously had.
• How To Remember Anything Forever-ish: a comic about learning
• Get better at programming by learning how things work
• How to teach yourself hard things
• Building Your Own Personal Learning Curriculum
• Always do Extra
  • Extra is finishing those two screens, but then researching a new library for form validation that might reduce the boilerplate code.
  • Extra must be balanced against Normal Work.
  • Extra must be aligned with your Normal Work.
• Against 3X Speed
  • Lectures are most effective when they're only a component of the classroom experience
  • Learning is about spaced repetition, not binge-reading books
• The Problems with Deliberate Practice
• Why Tacit Knowledge is More Important Than Deliberate Practice
• In Praise of Memorization
  • You can't reason accurately without knowledge
  • Memorizing organized your knowledge
  • It stays with you
• Celebrate tiny learning milestones, Julia Evans.
  • Keep a brag document
  • You can do a lot "by accident"
  • Fixing a bug can be milestone
• Why writing by hand is still the best way to retain information, StackOverflow
• ? Making Badass Developers - Kathy Sierra (Serious Pony) keynote
• How to study (with lots of cartoons from Calvin & Hobbes!)
  • Manage your time
  • Take notes in class & rewrite them at home
  • Study hard subjects first & study in a quiet place
  • Read actively & slowly, before & after class
  • Do your homework
  • Study for exams
  • Take Exams
  • Do research & write essays
  • Do I really have to do all this?
  • Are there other websites that give study hints?
• 10 Things Software Developers Should Learn about Learning
• ? Things I Learned the Hard Way, Bryan Cantrill

About flashcards:

• Augmenting Long-term Memory
• How to write good prompts: using spaced repetition to create understanding - also includes lots of insightful research papers.
• Effective learning: Twenty rules of formulating knowledge
• Rules for Designing Precise Anki Cards
• Fernando Borretti, Effective Spaced Repetition
• Anki-fy Your Life gets into why it makes sense to invest in your memory.

About Zettelkasten and PKM (personal knowledge management): see Personal knowledge management

Richard Feynman's Learning Strategy:

1. Step 1: Continually ask "Why?”
2. Step 2: When you learn something, learn it to where you can explain it to a child.
3. Step 3: Instead of arbitrarily memorizing things, look for the explanation that makes it obvious.

Most people overestimate what they can do in 1 year and underestimate what they can do in a decade. – Bill Gates

Frankly, though, I think most people can learn a lot more than they think they can. They sell themselves short without trying. One bit of advice: it is important to view knowledge as sort of a semantic tree — make sure you understand the fundamental principles, ie the trunk and big branches, before you get into the details/leaves or there is nothing for them to hang on 에게. - 엘론 머스크

"Experience is something you don't get until just after you need it." ― Steven Wright

Tell me and I forget. Teach me and I remember. Involve me and I learn. – Benjamin Franklin

Education is the kindling of a flame, not the filling of a vessel. – Socrates

That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. – Ralph Waldo Emerson

A wise man can learn more from a foolish question than a fool can learn from a wise answer. – Bruce Lee

A lecture has been well described as the process whereby the notes of the teacher become the notes of the student without passing through the mind of either. — Mortimer Adler

Fools learn from experience. I prefer to learn from the experience of others. — Bismark

Licenses (legal)

• Software Licenses in Plain English

Linux (system management)

• Welcome to Linux command line for you and me!
• Linux Performance, Brendan Gregg

Low-code/no-code

• How Levels.fyi scaled to millions of users with Google Sheets as a backend

Low-level, assembly

• Back to Basics, Joel Spolsky. Explains why learning low level programming is important.
  • I think that some of the biggest mistakes people make even at the highest architectural levels come from having a weak or broken understanding of a few simple things at the very lowest levels.
• What's in a Linux executable?
• The Elements of Computing Systems: building a modern computer from first principles (nand2tetris).
• Old pattern powering modern tech
• Demystifying bitwise operations, a gentle C tutorial
• Understanding the Power of Bitwise Operators. No math needed
• Memory Allocation (an interactive article)
• Why does 0.1 + 0.2 = 0.30000000000000004?, Julia Evans (about floating point)
• Putting the "You" in CPU
• x86-64 Assembly Language Programming with Ubuntu

Machine learning/AI

• Transformers from Scratch

수학

• ? Statistics for Hackers

마케팅

• goabstract/Marketing-for-Engineers

회로망

• The Great Confusion About URIs
  • A URI is a string of characters that identifies a resource. Its syntax is <scheme>:<authority><path>?<query>#<fragment> , where only <scheme> and <path> are mandatory. URL and URN are URIs.
  • A URL is a string of characters that identifies a resource located on a computer network. Its syntax depends on its scheme. Eg mailto:[email protected] .
  • A URN is a string of characters that uniquely identifies a resource. Its syntax is urn:<namespace identifier>:<namespace specific string> . Eg urn:isbn:9780062301239
• Everything you need to know about DNS
• Examples of Great URL Design
• Four Cool URLs - Alex Pounds' Blog

Observability (monitoring, logging, exception handling)

See also: Site Reliability Engineering (SRE)

벌채 반출

• Do not log dwells on some logging antipatterns.
  • Logging does not make much sense in monitoring and error tracking. Use better tools instead: error and business monitorings with alerts, versioning, event sourcing.
  • Logging adds significant complexity to your architecture. And it requires more testing. Use architecture patterns that will make logging an explicit part of your contracts
  • Logging is a whole infrastructure subsystem on its own. And quite a complex one. You will have to maintain it or to outsource this job to existing logging services
• Lies My Parents Told Me (About Logs)
  • Logs are cheap
  • I can run it better myself
  • Leveled logging is a great way to separate information
  • Logs are basically the same as events
  • A standard logging format is good enough
• Logging - OWASP Cheat Sheet Series
• The Audit Log Wall of Shame: list of vendors that don't prioritize high-quality, widely-available audit logs for security and operations teams.
• Guide on Structured Logs

Error/exception handling

• Error handling antipatterns in this repo.
• Writing Helpful Error Messages, Google Developers' course on Technical Writing
  • Explain the problem
  • Explain the solution
  • Write clearly

메트릭

• Meaningful availability
  • A good availability metric should be meaningful, proportional, and actionable. By "meaningful" we mean that it should capture what users experience. By "proportional" we mean that a change in the metric should be proportional to the change in user-perceived availability. By "actionable" we mean that the metric should give system owners insight into why availability for a period was low. This paper shows that none of the commonly used metrics satisfy these requirements…
• ? Meaningful Availability paper.
  • This paper presents and evaluates a novel availability metric: windowed user-uptime

Monitoring

• Google, Site Reliability Engineering, Monitoring Distributed Systems
  • Alerting on SLOs
• PagerDuty, Monitoring Business Metrics and Refining Outage Response
• ? crazy-canux/awesome-monitoring: monitoring tools for operations.
• Monitoring in the time of Cloud Native
• How to Monitor the SRE Golden Signals
  • From the Google SRE book: Latency, Traffic, Errors, and Saturation
  • USE Method (from Brendan Gregg): Utilization, Saturation, and Errors
  • RED Method (from Tom Wilkie): Rate, Errors, and Duration
• Simple Anomaly Detection Using Plain SQL
• How percentile approximation works (and why it's more useful than averages)
• Implementing health checks
• IETF RFC Health Check Response Format for HTTP APIs

Open source

• Non-code contributions are the secret to open source success

Operating system (OS)

• The Linux Programming Interface: A Linux and UNIX System Programming Handbook: already mentioned above.
• Modern Operating Systems, Andrew Tanenbaum, Herbert Bos (not read)
• Operating Systems: Three Easy Pieces (free book, not read)
• Linux Kernel Development, Robert Love. A very complete introduction to developing within the Linux Kernel.
• The 10 Operating System Concepts Software Developers Need to Remember
• Play with xv6 on MIT 6.828
• macOS Internals

Over-engineering

• 10 modern software over-engineering mistakes
• A good example of over-engineering: the Juicero press (April 2017)
• You Are Not Google: the UNPHAT method to avoid cargo cult.
  • Don't even start considering solutions until you Understand the problem. Your goal should be to “solve” the problem mostly within the problem domain, not the solution domain.
  • eNumerate multiple candidate solutions. Don't just start prodding at your favorite!
• 지나치게 생각합니다
  • 1st poison: education.
  • 2nd poison: marketing.
  • 3rd poison: ego
  • Solution: Stop trying to connect all the dots ahead of time. Embrace uncertainty and start doing.
• Don't Let Architecture Astronauts Scare You, Joel
  • Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
  • Your typical architecture astronaut will take a fact like “Napster is a peer-to-peer service for downloading music” and ignore everything but the architecture, thinking it's interesting because it's peer to peer, completely missing the point that it's interesting because you can type the name of a song and listen to it right away.

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”

— John Gall, General systemantics, an essay on how systems work, and especially how they fail..., 1975 (this quote is sometime referred as "Galls' law")

"Software engineering is what happens to programming when you add time and other programmers."

— Rob Pike, Go at Google: Language Design in the Service of Software Engineering

You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

— Steve Jobs

성능

• Numbers Everyone Should Know
• Latency numbers every programmer should know
• Rob Pike's 5 Rules of Programming
  • You can't tell where a program is going to spend its time.
  • 측정하다
  • Fancy algorithms are slow when n is small, and n is usually small.
  • Fancy algorithms are buggier than simple ones
  • Data dominates.
• Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust: a great way to learn about measuring performance.
• The Mathematical Hacker
• Four Kinds of Optimisation

Personal knowledge management (PKM)

• Zettelkasten Method
• How to build a second brain as a software developer
• Notes Against Note-Taking Systems
  • An interesting contrarian take!
  • I am waiting for any evidence that our most provocative thinkers and writers are those who rely on elaborate, systematic note-taking systems.
  • I am seeing evidence that people taught knowledge management for its own sake produce unexciting work.
• MaggieAppleton/digital-gardeners
• Notes apps are where ideas go to die. And that's good.

Personal productivity

Check out this section on my list of management resources, "Personal productivity".

관점

• At 31, I have just weeks to live. Here's what I want to pass on
  • First, the importance of gratitude.
  • Second, a life, if lived well, is long enough.
  • Third, it's important to let yourself be vulnerable and connect to others.
  • Fourth, do something for others.
  • Fifth, protect the planet.
• Life Is Not Short
  • "The most surprising thing is that you wouldn't let anyone steal your property, but you consistently let people steal your time, which is infinitely more valuable." — Seneca

은둔

• Privacy Enhancing Technologies: An Introduction for Technologists, Katharine Jarmul, MartinFowler.com

Problem solving

• Dealing with Hard Problems
• Invert, always, invert
  • Define the problem - what is it that you're trying to achieve?
  • Invert it - what would guarantee the failure to achieve this outcome?
  • Finally, consider solutions to avoid this failure
• ? Hammock Driven Development, Rick Hickey
  • A classic talk on problem solving.

Product management for software engineers

See the Product management section on my entrepreneurship-resources list of resources.

• Checkout this newsletter produced by Posthog: Product for Engineers

Project management

See the Project management section on my engineering-management list of resources.

Programming languages

I would recommend learning:

• JavaScript and maybe another interpreted language (Python, Ruby, etc.). Interpreted languages are useful for quick one-off automation scripts, and fastest to write for interviews. JavaScript is ubiquitous.
• A compiled language (Java, C, C++...).
  • Learn c in Y Minutes
• A more recent language to see where the industry is going (as of writing, Go, Swift, Rust, Elixir...).
• A language that has first-class support for functional programming (Haskell, Scala, Clojure...).

A bit more reading:

• A brief, incomplete, mostly wrong history of programming languages
• 유형
• Resources To Help You To Create Programming Languages
• Effective Programs - 10 Years of Clojure ?, Rich Hickey. The author of Clojure reflects on his programming experience and explains the rationale behind some of Clojure's key design decisions.
• Learn more programming languages, even if you won't use them, Thorsten Ball
  • These new perspectives, these ideas and patterns — they linger, they stay with you, even if you end up in another language. And that is powerful enough to keep on learning new languages, because one of the best things that can happen to you when you're trying to solve a problem is a change of perspective.
• Programming Language Checklist: a fun take on "so you want to build your own language?"
• Static vs. dynamic languages: a literature review
• Polyglot Programming and the Benefits of Mastering Several Languages
• It's not what programming languages do, it's what they shepherd you to
• Ask HN: What do you code when learning a new language/framework?
• The seven programming ur-languages: ALGOL, Lisp, ML, Self, Forth, APL, Prolog
• Lua: The Little Language That Could
• The Montréal Effect: Why Programming Languages Need a Style Czar
• TodePond/DreamBerd: a perfect programming language

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

-- Bjarne Stroustrup (C++ creator)

List of resources:

• Great Works in Programming Languages

파이썬

For Python check out my professional Python education repository.

자바 스크립트

In this repository: check ./training/front-end/

JavaScript is such a pervasive language that it's almost required learning.

• mbeaudru/modern-js-cheatsheet: cheatsheet for the JavaScript knowledge you will frequently encounter in modern projects.
• javascript-tutorial: comprehensive JavaScript guide with simple but detailed explanantions. Available in several languages.
• 30 Days of JavaScript: 30 days of JavaScript programming challenge is a step-by-step guide to learn JavaScript programming language in 30 days.
• Unleash JavaScript's Potential with Functional Programming

Garbage collection

• A Guide to the Go Garbage Collector: a very insightful guide about Go's GC

Programming paradigm

• Imperative vs Declarative Programming, Tyler McGinnis.
  • I draw the line between declarative and non-declarative at whether you can trace the code as it runs. Regex is 100% declarative, as it's untraceable while the pattern is being executed.
• ? Imperative vs Declarative Programming

Public speaking (presenting)

• Speaking for hackers

독서

• Papers we love: papers from the computer science community to read and discuss. Can be a good source of inspiration of solving your design problems.
• The morning paper: one CS research paper explained every morning.
• The Complete Guide to Effective Reading
• The benefits of note-taking by hand
• The Art of Reading More Effectively and Efficiently
• You should be reading academic computer science papers, Stack Overflow Blog
• How to Remember What You Read
  • 메모하십시오
  • Stay focused
  • Mark up the book
  • Make mental links
  • Quit books
• Writing summaries is more important than reading more books
  • In 1-2 sentences, what is the book about as a whole?
  • What are the 3-4 central questions it tries to answer?
  • Summarize the answers in one paragraph each.
  • What are the most important things you have learned personally?
  • There was an interesting contrarian take in the Hacker News thread: "Once I relaxed and decided, 'If the stuff in this book is good enough, my brain will keep it FOR me' both my satisfaction AND utility of books increased dramatically."
• You Are What You Read, Even If You Don't Always Remember It
  • "I cannot remember the books I've read any more than the meals I have eaten; even so, they have made me.", Ralp Waldo Emerson

Refactoring

• The Rule of Three, Coding Horror
  • Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalized, most flexible, most one-size-fits all solution that has ever been conceived.
  • It is three times as difficult to build reusable components as single use components.
  • A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
• Refactor vs. Rewrite
• Tripping over the potholes in too many libraries

리그 즈

• The Best Regex Trick
• regex101: build, test, and debug regex

Releasing & deploying

• How we release so frequently
• How to deploy software, Zach Holman
• BlueGreenDeployment, Martin Fowler
• Move fast and break nothing, Zach Holman
• ? Move fast and don't break things, Google
• Shipping to Production, The Pragmatic Programmer

버전 작성

• SemVer - Semantic Versioning
• CalVer - Calendar Versioning
• Semantic Versioning Will Not Save You
• Version numbers: how to use them?

Checklists

• Production Readiness Checklist, Gruntwork
• Checklist: what had to be done before deploying microservices to production
• Things end users care about but programmers don't: includes colors, formatting, themes, integrations, UX, compatibility, operations.

Feature flags

• Flipping out, Flickr. One of the first articles about feature flags.
• Feature Flags, Toggles, Controls, a website documenting feature flags, from Launch Darkly.
• Feature Toggles (aka Feature Flags), Pete Hodgson, martinFowler.com. Comprehensive article on the topic.
  • Deliver new functionality to users rapidly but safely
  • Release Toggles allow incomplete and un-tested codepaths to be shipped to production as latent code which may never be turned on.
  • Experiment Toggles are used to perform multivariate or A/B testing.
  • Ops Toggles control operational aspects of our system's behavior.
  • Permissioning Toggles change the features or product experience that certain users receive.
  • Static vs dynamic toggles
  • Long-lived toggles vs transient toggles
  • Savvy teams view their Feature Toggles as inventory which comes with a carrying cost, and work to keep that inventory as low as possible.
• Feature Flags Best Practices: Release Management, LaunchDarkly
• How we ship code faster and safer with feature flags, Github.
• Flipr: Making Changes Quickly and Safely at Scale, Uber
• Feature flags are ruining your codebase

Testing in production

• Why We Leverage Multi-tenancy in Uber's Microservice Architecture
• Developing in Production
  • Complex systems have emergent behavior, producing epiphenomenon that only appears with sufficient scale.
  • Wood's theorem: As the complexity of a system increases, the accuracy of any single agent's own model of that system decreases rapidly.
  • The more tools and code that you add to create elements in a system, the harder it is to replicate an environment encompassing those tools and code.
  • At the core of testing in production is the idea of splitting deployments (of artifacts) from releases (of features).
• Testing in Production: the hard parts, Cindy Sridharan
  • The whole point of [actual] distributed systems engineering is you assume you're going to fail at some point in time and you design the system in such a way that the damage, at each point is minimized, that recovery is quick, and that the risk is acceptably balanced with cost.
  • How can you cut the blast radius for a similar event in half?
    • Differentiate between deployment (0 risk) and release
    • Build a deploy-observe-release pipeline
    • Make incremental rollouts the norm (canaries, %-based rollouts, etc.)
    • Test configuration changes just like you test code
    • Default to roll back, avoid fixing forward (slow!)
    • Eliminate gray failures - prefer crashing to degrading in certain cases
    • Prefer loosely coupled services at the expense of latency or correctness
    • Use poison tasters (isolate handling of client input)
    • Implement per-request-class backpressure
    • Have proper visibility from a client/end-user standpoint (client-side metrics)
• Testing in Production, the safe way
• Multi-Tenancy in a Microservice Architecture

신뢰할 수 있음

See also System architecture

서적:

• Site Reliability Engineering
  • Written by members of Google's SRE team, with a comprehensive analysis of the entire software lifecycle - how to build, deploy, monitor, and maintain large scale systems.

인용 부호:

Quality is a snapshot at the start of life and reliability is a motion picture of the day-by-day operation. – NIST

Reliability is the one feature every customer users. -- An auth0 SRE.

조항:

• I already mentioned the book Release it! 위에. There's also a presentation from the author.
• Service Recovery: Rolling Back vs. Forward Fixing
• How Complex Systems Fail
  • Catastrophe requires multiple failures – single point failures are not enough.
  • Complex systems contain changing mixtures of failures latent within them.
  • Post-accident attribution to a 'root cause' is fundamentally wrong.
  • Hindsight biases post-accident assessments of human performance.
  • Safety is a characteristic of systems and not of their components
  • Failure free operations require experience with failure.
• Systems that defy detailed understanding
  • Focus effort on systems-level failure, instead of the individual component failure.
  • Invest in sophisticated observability tools, aiming to increase the number of questions we can ask without deploying custom code
• Operating a Large, Distributed System in a Reliable Way: Practices I Learned, Gergely Orosz.
  • A good summary of processes to implement.
• Production Oriented Development
  • Code in production is the only code that matters
  • Engineers are the subject matter experts for the code they write and should be responsible for operating it in production.
  • Buy Almost Always Beats Build
  • Make Deploys Easy
  • Trust the People Closest to the Knives
  • QA Gates Make Quality Worse
  • Boring Technology is Great.
  • Non-Production Environments Have Diminishing Returns
  • Things Will Always Break
• ? High Reliability Infrastructure migrations, Julia Evans.
• Appendix F: Personal Observations on the Reliability of the Shuttle, Richard Feynman
• Lessons learned from two decades of Site Reliability Engineering

자원:

• ? dastergon/awesome-sre
• ? upgundecha/howtheysre: a curated collection of publicly available resources on SRE at technology and tech-savvy organizations

Resiliency

• ? The Walking Dead - A Survival Guide to Resilient Applications
• ? Defensive Programming & Resilient systems in Real World (TM)
• ? Full Stack Fest: Architectural Patterns of Resilient Distributed Systems
• ? The 7 quests of resilient software design
• ? Resilience engineering papers: comprehensive list of resources on resilience engineering
• MTTR is more important than MTBF (for most types of F) (also as a presentation)

찾다

• What every software engineer should know about search

보안

• Penetration Testing: A Hands-On Introduction to Hacking, Georgia Weidman
• Penetration Testing Tools Cheat Sheet
• A practical guide to securing macOS
• Web Application Security Guide/Checklist
• Reckon you've seen some stupid security things?: everything not to do.
• Checklist of the most important security countermeasures when designing, testing, and releasing your API
• OWASP Cheat Sheet Series: a series of cheat sheets about various security topics.
  • Docker Security
  • How to improve your Docker containers security
• Secure by Design, a book review by Henrik Warne.
  • There is a big overlap between secure code and good software design
  • Every domain value should instead be represented by a domain primitive.
  • External input needs to be validated before it is used in the system, in the following order: origin, size, lexical content, syntax, semantics.
  • Entities should be consistent at creation, have limited operation, shouldn't be sharing mutable objects.
  • Three Rs to do every few hours: rotate secrets automatically, repave servers and applications (redeploy on clean footprint), repair vulnerable.
  • Don't use exceptions for the control flow.
• OWASP Top Ten Web Application Security Risks
  • How to start an AppSec program with the OWASP Top 10
• ukncsc/zero-trust-architecture: Principles to help you design and deploy a zero trust architecture
• ? Minimum Viable Security
• The Open Software Assurance Maturity Model
• Security by Obscurity is Underrated
• Don't Wanna Pay Ransom Gangs? Test Your Backups, Krebs on Security
• The Beginner's Guide to Passwords
• The Password Game
• Learnings from 5 years of tech startup code audits
• API Tokens: A Tedious Survey: don't use JWT.
• The Six Dumbest Ideas in Computer Security

Training for developers:

• Hacksplaining
• Codebashing
• OWASP Security Knowledge Framework
• PagerDuty Security Training
• Gruyere: Web Application Exploits and Defenses

List of resources:

• ? meirwah/awesome-incident-response: tools for incident response
• ? Starting Up Security
• ? decalage2/awesome-security-hardening: security hardening guides, tools and other resources

Shell (command line)

• The case for bash
• ? alebcay/awesome-shell
• ? dylanaraps/pure-bash-bible: pure bash alternatives to external processes.
• The Bash Hackers Wiki provides a gentler way to learn about bash than its manages.
• Awk in 20 Minutes
• ? Linux Productivity Tools
• jlevy/the-art-of-command-line: master the command line, in one page must read
• Minimal safe Bash script template
• Command Line Interface Guidelines
• The Linux Commands Handbook
• How to write idempotent Bash scripts
• Learn bash by playing an adventure
• Effective Shell
• Computing from the Command Line
• What helps people get comfortable on the command line?, Julia Evans
• 6 Techniques I Use to Create a Great User Experience for Shell Scripts

SQL

• SQL styleguide
• Best practices for writing SQL queries
• Practical SQL for Data Analysis
• Reasons why SELECT * is bad for SQL performance
• Animate SQL
• Lost at SQL, an SQL learning game
• Joins 13 Ways
• spandanb/learndb-py: learn database internals by implementing it from scratch.
• SQL for the Weary

System administration

• ? kahun/awesome-sysadmin: a curated list of amazingly awesome open source sysadmin resources

System architecture

See also Reliability, Scalability

Reading lists:

• ? donnemartin/system-design-primer: learn how to design large scale systems. Prep for the system design interview.
• ? A Distributed Systems Reading List
• ? Foundational distributed systems papers
• ? Services Engineering Reading List
• ? System Design Cheatsheet
• karanpratapsingh/system-design: learn how to design systems at scale and prepare for system design interviews
• A Distributed Systems Reading List

Blogs:

• High Scalability: great blog about system architecture, its weekly review article are packed with numerous insights and interesting technology reviews. Checkout the all-times favorites.

서적:

• Building Microservices, Sam Newman (quite complete discussion of microservices)
• Designing Data-Intensive Applications

조항:

• 6 Rules of thumb to build blazing fast web server applications

• The twelve-factor app

• Introduction to architecting systems for scale

• The Log: What every software engineer should know about real-time data's unifying abstraction: one of those classical articles that everyone should read.

• Turning the database outside-out with Apache Samza

• Fallacies of distributed computing, Wikipedia

• The biggest thing Amazon got right: the platform

  • All teams will henceforth expose their data and functionality through service interfaces.
  • Monitoring and QA are the same thing.

• Building Services at Airbnb, part 3

  • Resilience is a Requirement, Not a Feature

• Building Services at Airbnb, part 4

  • Building Schema Based Testing Infrastructure for service development

• Patterns of Distributed Systems, MartinFowler.com

• ConwaysLaw, MartinFowler.com (regarding organization, check out my engineering-management list).

• The C4 model for visualising software architecture

• If Architects had to work like Programmers

Architecture patterns

• BFF (backend for frontend)
  • Backends For Frontends
• Circuit breaker
• Rate limiter algorithms (and their implementation)
• Load Balancing: a visual exploration of load balancing algos
• Good Retry, Bad Retry: An Incident Story: insightful, well-written story about retries, circuit breakers, deadline, etc.

Microservices/splitting a monolith

• Service oriented architecture: scaling the Uber engineering codebase as we grow
• Don't start with microservices in production – monoliths are your friend
• Deep lessons from Google And EBay on building ecosystems of microservices
• Introducing domain-oriented microservice architecture, Uber
  • Instead of orienting around single microservices, we oriented around collections of related microservices. We call these domains.
  • In small organizations, the operational benefit likely does not offset the increase in architectural complexity.
• Best Practices for Building a Microservice Architecture
• ? Avoid Building a Distributed Monolith
• ? Breaking down the monolith
• Monoliths are the future
  • "We're gonna break it up and somehow find the engineering discipline we never had in the first place."
• 12 Ways to Prepare your Monolith Before Transitioning to Microservices
• Death by a thousand microservices
  • Microservices

확장 성

See also: Reliability, System architecture

• Scalable web architecture and distributed systems
• Scalability Rules: 50 Principles for Scaling Web Sites (presentation)
• Scaling to 100k Users, Alex Pareto. The basics of getting from 1 to 100k users.

Site Reliability Engineering (SRE)

See: Reliability

Technical debt

• TechnicalDebt, Martin Fowler.
• Fixing Technical Debt with an Engineering Allocation Framework
  • You don't need to stop shipping features to fix technical debt
  • Communicate the business value
• Ur-Technical Debt
  • Today, any code that a developer dislikes is branded as technical debt.
  • Ward Cunningham invented the debt metaphor to explain to his manager that building iteratively gave them working code faster, much like borrowing money to start a project, but that it was essential to keep paying down the debt, otherwise the interest payments would grind the project to a halt.
  • Ur-technical debt is generally not detectable by static analysis.

테스트

• ️ Testing strategies in a microservices architecture (Martin Fowler) is an awesome resources explaining how to test a service properly.
• ? Testing Distributed Systems

Why test:

• Why bother writing tests at all?, Dave Cheney. A good intro to the topic.
  • Even if you don't, someone will test your software
  • The majority of testing should be performed by development teams
  • Manual testing should not be the majority of your testing because manual testing is O(n)
  • Tests are the critical component that ensure you can always ship your master branch
  • Tests lock in behaviour
  • Tests give you confidence to change someone else's code

How to test:

• A quick puzzle to test your problem solving... and a great way to learn about confirmation bias and why you're mostly writing positive test cases.
• Testing is not for beginners: why learning to test is hard. This shouldn't demotivate you though!
• Arrange-act-assert: a pattern for writing good tests
• Test smarter, not harder

Test pyramid:

• The test pyramid, Martin Fowler
• Eradicating non-determinism in tests, Martin Fowler
• The practical test pyramid, MartinFowler.com
  • Be clear about the different types of tests that you want to write. Agree on the naming in your team and find consensus on the scope of each type of test.
  • Every single test in your test suite is additional baggage and doesn't come for free.
  • Test code is as important as production code.
• Software testing anti-patterns, Kostis Kapelonis.
• Write tests. Not too many. Mostly integration. for a contrarian take about unit testing
• ? Unit test 2, Integration test: 0
• Testing in the Twenties
• Google Testing Blog: Test Sizes
• Pyramid or Crab? Find a testing strategy that fits, web.dev

End-to-end tests:

• Just say no to more end-to-end tests, Google Testing Blog
• End-to-end testing considered harmful

도구

• DevDocs API Documentation: a repository for multiple API docs (see also Dash for macOS).
• DevChecklist: a collaborative space for sharing checklists that help ensure software quality
• ? Free for developers: list of free tiers for developments tools and services
• Choose Boring Technology
• Ask HN: Best dev tool pitches of all time?
• A list of /uses pages detailing developer setups, gear, software and configs

The future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age — Lindy's Law

Type system

• Counterexamples in Type Systems: a library of runtime issues that weren't caught by the type system

타이포그래피

• Butterick's Practical Typography
• Typography for Lawyers
• Quick guide to web typography for developers · OlegWock
• Features of your font you had no idea about

Version control (Git)

Learning Git, courses and books:

• Git Book
• Git from the inside out
• Git Tutorials and Training, Atlassian
• Git Immersion
• A Visual Git Reference (a bit more advanced)
• Think Like (a) Git
• Git's database internals I: packed object store: an insightful deep dive from Github
• Oh My Git!: a game to learn git

Cheat sheets:

• Git Cheat Sheet
• git-tips
• Oh Shit, Git!?!

More specific topics:

• Conventional Commits
• Git Merge vs. Rebase: What's the Diff?
• ? Story-telling with Git rebase
• ? Git Rebase vs. Merge
• ? 10 Git Anti Patterns You Should be Aware of
• Learn Git Branching: an interactive game
• Fix conflicts only once with git rerere
• Monorepo Explained
• How to Write a Git Commit Message
• git-worktree: manage multiple working trees attached to the same repository.

Work ethics, productivity & work/life balance

Check out this section on my list of engineering-management resources, "Personal productivity".

Web development

In this repository: check training/web-dev/ and ./training/front-end/

Learning guide and resources:

• grab/front-end-guide: a study guide and introduction to the modern front end stack.
• Front-End Developer Handbook 2019, Cody Lindley
• A Directory of design and front-end resources
• ? codingknite/frontend-development: a list of resources for frontend development

Topics:

• 136 facts every web dev should know
• Maintainable CSS
• Things you forgot (or never knew) because of React
• Checklist - The A11Y Project for accessibility
• DevTools Tips
• 67 Weird Debugging Tricks Your Browser Doesn't Want You to Know
• Client-Side Architecture Basics
• Web Browser Engineering: this book explains how to build a basic but complete web browser, from networking to JavaScript, in a couple thousand lines of Python.

Writing (communication, blogging)

➡️ See also my engineering-management list

• Undervalued Software Engineering Skills: Writing Well
  • From the HN discussion: "Writing a couple of pages of design docs or an Amazon-style 6 pager or whatever might take a few days of work, but can save weeks or more of wasted implementation time when you realise your system design was flawed or it doesn't address any real user needs."
• Sell Yourself Sell Your Work
  • If you've done great work, if you've produced superb software or fixed a fault with an aeroplane or investigated a problem, without telling anyone you may as well not have bothered.
• The Writing Well Handbook
  • Ideas — Identify what to write about
  • First Drafts — Generate insights on your topic
  • Rewriting — Rewrite for clarity, intrigue, and succinctness
  • Style — Rewrite for style and flow
  • Practicing — Improve as a writer
• Write Simply, Paul Graham
• Writing is Thinking: Learning to Write with Confidence
• It's time to start writing explains why Jeff Bezos banned PowerPoint at Amazon.
  • The reason writing a good 4 page memo is harder than "writing" a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what's more important than what, and how things are related.
  • Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.
• Programming and Writing, Antirez
• Writing one sentence per line
• Ask HN: How to level up your technical writing?. Lots of great resources.
• Patterns in confusing explanations, Julia Evans
• Technical Writing for Developers
• Some blogging myths, Julia Evans
• George Orwell's Six Rules for Writing
  • Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
  • Never use a long word where a short one will do.
  • If it is possible to cut a word out, always cut it out.
  • Never use the passive where you can use the active.
  • Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
  • Break any of these rules sooner than say anything outright barbarous.
• Blog Writing for Developers

Guides & classes about technical writing:

• Documentation Guide — Write the Docs
  • 원리
  • Style guides
  • Docs as code
  • Markup languages
  • 도구
• Technical Writing One introduction, Google
  • 문법
  • Active voice
  • Clear & short sentences

If you're overthinking, write. If you're underthinking, read. – @AlexAndBooks_

Resources & inspiration for presentations

• https://twitter.com/devops_borat
• https://speakerdeck.com/
• Dilbert
• Calvin & Hobbes (search engine)
• https://twitter.com/_workchronicles

Keeping up-to-date

Website and RSS feeds (I use Feedly):

• Hacker News ️
• 벤처 비트
• High Scalability: see above

보안:

• Schneier on Security
• Krebs on Security
• The Hacker News

Newsletters:

• Bytes (JavaScript)
• PyCoders (Python)
• Posthog

Blogs:

• kilimchoi/engineering-blogs

개념

어휘

• BDD
• CAP theorem
• DDD
• 마른
• EAV
• 파악
• 키스
• Make it run, make it right, make it fast
• OOP
• 단단한
• TDD
• Two Generals' Problem
• YAGNI

My other lists

• engineering-management
• entrepreneurship-resources
• professional-programming
• python-education