professional programming

Índice

• Programação profissional - sobre esta lista
  • Princípios
  • Contribuindo para esta lista
  • Livros obrigatórios
  • Artigos de leitura obrigatória
  • Outro material geral e lista de recursos
    • Outras listas
    • Livros
    • Artigos
    • Axiomas
    • Cursos
  • Tópicos
    • Algoritmo e estruturas de dados
    • Design e Desenvolvimento da API
    • Atitude, hábitos, mentalidade
      • Procrastinação
    • Autenticação/autorização
    • Automação
    • Práticas recomendadas
    • Além de engenharia de software e aleatório
    • Preconceitos
    • Negócios
    • Cache
    • Crescimento na carreira
      • Escolhendo sua próxima/primeira oportunidade
      • Chegando ao Staff Eng
    • Conjuntos de caracteres
    • Xadrez
    • Nuvens
    • Revisões de código
    • Codificação e qualidade do código
    • Comunicação
    • Compiladores
    • Configuração
    • Integração contínua (IC)
    • Bancos de dados
      • Nosql
      • PostGres
    • Formatos de dados
    • Ciência de dados/engenharia de dados
    • Depuração
    • Design (visual, UX, interface do usuário, tipografia)
    • Design (modelagem OO, arquitetura, padrões, anti-padrões, etc.)
      • Design: Esquema de banco de dados
      • Design: Padrões
      • Design: Simplicidade
    • Ambiente e ferramentas de desenvolvimento
    • Docker
    • Documentação
    • DOTFILES
    • Editores e IDE
      • Vim
    • E-mail
    • Gerenciamento de engenharia
    • Exercícios
    • Experimentação
    • Programação funcional (FP)
    • Desenvolvimento de jogos
    • Gráficos
    • Hardware
    • Http
    • Humor
    • Resposta de incidentes (OnCall, alerta, interrupções, combate a incêndios, post -mortem)
      • Post -mortem
    • Internet
    • Entrevista
    • Kubernetes
    • Modelo de linguagem grande (LLM)
    • Aprendizagem e memorização
    • Licenças (Legal)
    • Linux (gerenciamento do sistema)
    • Low Cod/sem código
    • Montagem de baixo nível
    • Aprendizado de máquina/ai
    • Matemática
    • Marketing
    • Rede
    • Observabilidade (monitoramento, log, manuseio de exceções)
      • Log
      • Manuseio de erro/exceção
      • Métricas
      • Monitoramento
    • Código aberto
    • Sistema Operacional (OS)
    • Engenharia excessiva
    • Desempenho
    • Gestão do Conhecimento Pessoal (PKM)
    • Produtividade pessoal
    • Perspectiva
    • Privacidade
    • Resolução de problemas
    • Gerenciamento de produtos para engenheiros de software
    • Gerenciamento de projetos
    • Linguagens de programação
      • Python
      • JavaScript
      • Coleta de lixo
    • Paradigma de programação
    • Falar em público (apresentando)
    • Leitura
    • Refatorando
    • Regex
    • Liberando e implantando
      • Versão
      • Listas de verificação
      • Sinalizadores de recursos
      • Testes em produção
    • Confiabilidade
      • Resiliência
    • Procurar
    • Segurança
    • Shell (linha de comando)
    • SQL
    • Administração do sistema
    • Arquitetura do sistema
      • Padrões de arquitetura
      • Microsserviços/dividindo um monólito
    • Escalabilidade
    • Engenharia de Confiabilidade do Site (SRE)
    • Dívida técnica
    • Teste
    • Ferramentas
    • Sistema de tipo
    • Tipografia
    • Controle de versão (git)
    • Ética no trabalho, produtividade e equilíbrio entre trabalho e vida
    • Desenvolvimento da Web
    • Escrita (comunicação, blog)
  • Recursos e inspiração para apresentações
  • Mantendo-se atualizado
  • Conceitos
  • Minhas outras listas

Programação profissional - sobre esta lista

Dê -me seis horas para cortar uma árvore e eu gastarei os quatro primeiros afiando o machado. (Abraham Lincoln)

Uma coleção de recursos de pilha completa para programadores.

O objetivo desta página é torná -lo um desenvolvedor mais proficiente. Você encontrará apenas recursos que achei realmente inspiradores ou que se tornaram clássicos atemporais.

Princípios

• Esta página não deve ser abrangente. Estou tentando mantê -lo leve e não muito esmagador.
• A seleção de artigos é opinativa.
• Não concordo ou endosso necessariamente com todas as linhas escritas em cada um desses recursos. O mesmo se aplica aos seus autores: não endosso tudo o que cada um desses autores disse e jamais dirá.

Unid:

• ? : Lista de recursos
• : livro
• ? : Extrato de vídeo/filme/filme/conversa
• ? : slides/apresentação
• ️: leitura obrigatória
• ? : papel

Contribuindo para esta lista

Sinta -se à vontade para abrir um PR para contribuir!

Não vou adicionar tudo: como mencionado acima, estou tentando manter a lista concisa.

Livros obrigatórios

Achei esses livros incrivelmente inspiradores:

• O Programador Pragmático: Do ​​Journeyman ao Master: Hands-In o livro mais inspirador e útil que li sobre programação.
• Código completo: Um manual prático de construção de software: uma boa adição ao programador pragmático, oferece a estrutura necessária para falar sobre código.
• Libere!: Este livro vai além do código e oferece práticas recomendadas para a construção de software pronto para produção. Isso lhe dará cerca de 3 anos de experiência no mundo real.
• Regras de escalabilidade: 50 princípios para dimensionar sites
• A interface de programação Linux: um manual de programação do Linux e Unix System: Fora de ensinar quase tudo o que você precisa saber sobre o Linux, este livro fornecerá informações sobre como o software evolui e o valor de ter interfaces simples e elegantes.
• Estrutura e interpretação dos programas de computador (gratuitos): um dos livros mais influentes da ciência da computação (escritos e usados ​​no MIT), o SICP foi influente na educação de CS. Byte recomendou o SICP "para programadores profissionais que estão realmente interessados ​​em sua profissão".

Existem alguns livros gratuitos disponíveis, incluindo:

• Desenvolvimento de software profissional: bastante completo e um bom companheiro para esta página. Os capítulos gratuitos estão focados principalmente nos processos de desenvolvimento de software: design, teste, redação de código etc. - e não muito sobre a própria tecnologia.
• ? VHF/livros de programação livre
• ? EbookFoundation/Livros de programação livre

Artigos de leitura obrigatória

• Conselhos práticos para novos engenheiros de software
• Em ser um engenheiro sênior
• Lições aprendidas no desenvolvimento de software: um desses artigos que oferecem anos de lições suadas, tudo em um pequeno artigo. Deve ler.
• Coisas que aprendi da maneira mais difícil
  • Especificação primeiro, depois código
  • Os testes são melhores APIs
  • O pensamento futuro é a lixeira futura
  • A documentação é uma carta de amor para o seu futuro eu
  • Às vezes, é melhor deixar o aplicativo travar do que não fazer nada
  • Entenda e fique longe do culto de carga
  • "Ferramenta correta para o trabalho" é apenas para empurrar uma agenda
  • Aprenda a programação funcional básica
  • Sempre use fusos horários com suas datas
  • Sempre use UTF-8
  • Crie bibliotecas
  • Aprenda a monitorar
  • Explícito é melhor do que implícito
  • As empresas procuram especialistas, mas mantêm generalistas por mais tempo
  • A melhor maneira segura de lidar com os dados do usuário não é capturá -los
  • Quando é hora de parar, é hora de parar
  • Você é responsável pelo uso do seu código
  • Não diga "está feito" quando não for
  • Preste atenção em como as pessoas reagem a você
  • Cuidado com micro-agressões
  • Mantenha uma lista de "coisas que eu não sei"
• Sinais de que você é um bom programador (nem tudo aqui é ótimo - alguns dos pontos são contraproducentes)
  • O instinto de experimentar primeiro
  • Destacamento emocional do código e design
  • Ansioso para consertar o que não está quebrado
  • Fascinado pelo incompreensível
  • Obrigado a ensinar
  • Paciência incorruptível
  • Uma busca destrutiva da perfeição
  • Compreensão enciclopédica da plataforma
  • Pensa em código
  • Quando em Roma, faz o que os romanos fazem
  • Cria suas próprias ferramentas
  • Indiferente à hierarquia
  • Animado pelo fracasso
  • Indiferente às circunstâncias
  • Substitui o impulso por compromisso
  • Impulsionado por experiências
• 7 Verdades absolutas eu desaprendi como desenvolvedor júnior
  • No início de sua carreira, você pode aprender 10x mais em uma equipe de apoio em 1 ano, do que codificar por conta própria
  • Toda empresa tem problemas, toda empresa tem dívida técnica.
  • Ser excessivamente opinativo sobre os tópicos com os quais você não tem experiência no mundo real é bastante arrogante.
  • Muitas negociações de conferência abrangem provas de conceitos em vez de cenários do mundo real.
  • Lidar com o legado é completamente normal.
  • A arquitetura é mais importante que o Nitpicking.
  • Concentre -se na automação sobre a documentação, quando apropriado.
  • Ter alguma dívida técnica é saudável.
  • Os engenheiros seniores devem desenvolver muitas habilidades além da programação.
  • Ainda somos juniores em algumas áreas.
• Como construir um bom software
  • Um bom resumo de alto nível das práticas fundamentais de engenharia.
  • A causa raiz do software ruim tem menos a ver com opções específicas de engenharia e mais a ver com a forma como os projetos de desenvolvimento são gerenciados.
  • Não existe engenharia platonicamente boa: depende de suas necessidades e dos problemas práticos que você encontra.
  • O software deve ser tratado não como um produto estático, mas como uma manifestação viva do entendimento coletivo da equipe de desenvolvimento.
  • Os projetos de software raramente falham porque são muito pequenos; Eles falham porque ficam grandes demais.
  • Cuidado com os objetivos burocráticos que se disfarçam de declarações de problemas. Se nosso objetivo final é melhorar a vida dos cidadãos, precisamos reconhecer explicitamente as coisas que estão piorando suas vidas.
  • A construção de software não se trata de evitar o fracasso; Trata -se de falhar estrategicamente o mais rápido possível para obter as informações necessárias para criar algo de bom.
• Como ser um engenheiro -10x
  • Anular a saída de 10 engenheiros.
  • Segure 10 engenheiros reféns em uma discussão técnica.
  • Desperdiçar 10 semanas de salários nos custos da nuvem.
  • Desperdício 400 horas de engenharia em arquitetura ruim.
  • Inclua 400 horas de triagem de insetos.

Outro material geral e lista de recursos

Outras listas

• Liuchong/Awesome-roadmaps: uma lista com curadoria de roteiros.

Livros

• O manual do impostor - US $ 30. Do autor: "Não tenha um diploma de CS? Nem eu - é por isso que escrevi este livro".
• O livro de ciência da computação

Artigos

• MR-MIG/TODOS AMPROGRAMARME
• Leis famosas do desenvolvimento de software
• A biblioteca dos construtores da Amazon
  • Há uma lista dos melhores artigos neste tópico do Twitter
• Kdeldycke/Awesome-Falsehood: Falshonds Programmers acreditam em
• HELLERED/ALGULAÇÃO DE PROGRAMAÇÃO
• Techyaks: Lista de palestras
• Conversas que mudaram a maneira como penso em programar
• O que todo graduado em ciência da computação deve saber
• Kamranahmedse/desenvolvedor-roadmap
• mtdvio/todos os programas de programa-uma coleção de (principalmente) coisas técnicas
• Expectativas de Mike Acton de engenheiros de software profissionais
• Coisas que eles não te ensinaram sobre engenharia de software
  • O conhecimento do domínio é mais importante do que suas habilidades de codificação
  • O código é secundário. O valor comercial é o primeiro.
  • Você trabalha com incerteza na maioria das vezes
• Superestimamos nossa capacidade de curto prazo, mas subestimamos nossa capacidade de longo prazo.
  • A especialização é para insetos.
• Quer uma vantagem injusta em sua carreira tecnológica? Consumir conteúdo destinado a outros papéis
  • O entendimento multifuncional é fundamental nas empresas de tecnologia modernas
  • Ajuda a evitar subestimar a importância e dificuldade em outros papéis
  • Ajuda você a ser estratégico em sua interação com as pessoas nesse papel
• Ensine -se programando em dez anos

Axiomas

• Preceitos - Urbit
  • Os dados são melhores que o código.
  • A correção é mais importante que o desempenho.
  • Bates determinísticos heurísticos.
  • Cem linhas de simplicidade são melhores que vinte linhas de complexidade.
  • Se suas abstrações estão vazando, não se deve a alguma lei do universo; Você apenas é péssimo em abstrair. Geralmente, você não especificou a abstração por pouco.
  • Se você evitar alterar uma seção de código por medo de despertar os demônios, você está vivendo com medo. Se você permanecer nos confins confortáveis ​​da pequena seção do código que você escreveu ou conhece bem, nunca escreverá o código lendário. Todo o código foi escrito por seres humanos e pode ser dominado por humanos.
  • Se houver claramente uma maneira certa de fazer algo e uma maneira errada, faça da maneira certa. A codificação requer disciplina incrível.
  • A melhor maneira de obter a resposta certa é experimentá -la da maneira errada.
  • A prática diz que as coisas são boas ou ruins; A teoria diz o porquê.
  • Não estar qualificado para resolver um problema não é motivo para não resolvê -lo.
  • Se você não entende um sistema que está usando, não o controla. Se ninguém entende o sistema, o sistema está no controle.
• Regras de polegar incorporadas
• 50 idéias que mudaram minha vida
• Reflexões sobre 10.000 horas de programação
• 20 coisas que aprendi nos meus 20 anos como engenheiro de software

Cursos

• Guia do Google Tech Dev
• O semestre ausente da sua educação CS, MIT. Inclui palestras sobre o shell, editores, disputa de dados, git, depuração e criação de criação, meta -programação, segurança e criptografia.
• Matemática para o aventureiro auto-aprendizado, Neil Sainsbury
• Jwasham/coding-interview-University: um plano completo de estudo de ciência da computação para se tornar um engenheiro de software.
• Ensine a si mesmo ciência da computação: um conjunto opinativo dos melhores recursos de CS.
• OSSU/Computer-Science: Educação autodidata gratuita em ciência da computação!

Tópicos

Algoritmo e estruturas de dados

• Leia os CLRs. Você pode assistir e baixar o curso na OCW - também existem cursos mais recentes.
• Ou o manual de design do algoritmo
• Experimente alguns algoritmos no Projeto Euler
• CS 61B Spring 2023

Outros recursos:

• Algoritmos, Jeff Erickson

Sejamos honestos: os algoritmos podem ser um tópico bastante seco. Esta pergunta do Quora lista algumas alternativas mais engraçadas de aprendizado, incluindo:

• Algoritmos de Grokking
• Algoritmos essenciais
• Visualização da estrutura de dados
• ? 15 algoritmos de classificação em 6 minutos
• Hashing
• Visualizando algoritmos
• Árvores B e índices de banco de dados

Exemplo de implementações:

• Algoritmos de Trekhleb/JavaScript: algoritmos e estruturas de dados implementadas em JavaScript
• Os algoritmos

Algoritmos em sistemas distribuídos:

• Algoritmo de consenso de jangada

Design e Desenvolvimento da API

Conteúdo de descanso geral:

• Estilos arquitetônicos e o design de arquiteturas de software baseadas em rede, Roy Fielding (o inventor do REST)
• Uma coleção de recursos úteis para a construção de APIs HTTP+JSON RESTful.
• Melhores práticas para Design de API em REST, Blog de estofamento de pilha
• Resto não perturbado: um guia para projetar a API perfeita: Livro muito completo sobre o design da API RESTful.

Exemplo de diretrizes:

• Diretrizes de API de REST da Microsoft
• Diretrizes de API e eventos de API e eventos Zalando RESTful
• Guia de design da API do Google: um guia geral para projetar API em rede.
• AIP-1: propósito e diretrizes AIP
  • O AIP significa proposta de melhoria da API, que é um documento de design que fornece documentação concisa e de alto nível para o desenvolvimento da API.

Tópicos mais específicos:

• Por que você deve usar links, não chaves, para representar relacionamentos em APIs, Martin Nally, Google
  • "O uso de links em vez de chaves estrangeiras para expressar relacionamentos nas APIs reduz a quantidade de informações que um cliente precisa saber para usar uma API e reduz as maneiras pelas quais clientes e servidores são acoplados um ao outro".
• Me dê /eventos, não webhooks
  • Os eventos podem desbloquear recursos de webhook muito necessários, como permitir que seus consumidores de webhook reproduzam ou redefinam a posição de sua assinatura da Webhook.
• Desbloqueando o poder do JSON Patch

Atitude, hábitos, mentalidade

• Mastering Programming, Kent Beck.
• As características de um programador proficiente
• O TAO da programação: um conjunto de parábolas sobre programação.
• Tomar a propriedade é a maneira mais eficaz de conseguir o que você deseja
• Encontrar tempo para se tornar um desenvolvedor melhor
• Dez minutos por dia: como Alex Allain escreveu um livro em menos de 200 horas, escrevendo 10 minutos todos os dias.
• O cuidado e a alimentação de engenheiros de software (ou por que os engenheiros estão mal -humorados)
  • No triunvirato de software, gerentes de produto, designers e engenheiros de software, apenas os engenheiros devem desativar suas mentes criativas e apenas produzir.
  • Tanto os engenheiros quanto os gerentes de produto tendem a pensar incorretamente, que as especificações ou requisitos do produto são equivalentes ao manual de móveis da IKEA.
  • Esta é uma das principais coisas que deixam os engenheiros mal -humorados: prioridades constantemente mudando.
  • Embora muitos engenheiros reclamem que os gerentes de produto mudam de idéia, quase nenhum explicará isso em suas estimativas de tempo.
  • Os programas de ciência da computação não são sobre prepará -lo para as tarefas que você enfrentará na indústria.
  • Quando há mais engenheiros do que o usado, o tempo de engenharia acaba se afastando do desenvolvimento e do planejamento, sincronização e coordenação.
  • Envolver engenheiros no processo criativo
  • Dê oportunidades aos engenheiros para serem criativos.
  • Incentive a folga.
  • Deixe -o código
  • Expressar apreciação
• O engenheiro de software com espírito de produto, Gergely Orosz
  • Ótimos engenheiros de produtos sabem que os produtos mínimos adoráveis ​​precisam da profundidade certa
  • Os engenheiros mentos de produto mapeiam rapidamente os casos de borda e pensam em maneiras de reduzir o trabalho neles: frequentemente trazendo soluções que não requerem trabalho de engenharia
  • Envolva -se em pesquisa de usuários e suporte ao cliente
  • Traga sugestões de produtos bem apoiadas para a tabela
  • Ofereça trocas de produto/engenharia
• 40 lições de 40 anos, Steve Schlafman
  • Se você deseja progredir nas coisas que mais importam, precisa decidir quem vai decepcionar. É inevitável.
  • O melhor investimento que você pode fazer é sua própria educação. Nunca pare de aprender. O segundo melhor investimento que você pode fazer é construir sua rede por meio de interações autênticas e significativas. É o que você sabe e quem você conhece.
  • Você nunca conseguirá o que não pede ou procurar ativamente. Vá em frente!
  • Não é sobre a luz no fim do túnel. É o túnel. Apareça todos os dias e aproveite o processo.
  • Um grande companheiro de equipe sempre coloca a organização e seu objetivo à frente de seus próprios interesses.
  • Escolha seus pontos. Temos tempo limitado e nosso cérebro só pode processar muito. O foco é fundamental. Escolha sabiamente.
  • Toda pessoa provavelmente está lutando com alguma coisa. Seja gentil. Seja útil.
• Na codificação, ego e atenção
  • A mente do iniciante aceita o fato de que o conhecimento absoluto é infinito e, assim, manter a pontuação é uma perda de tempo.
  • O domínio é simplesmente o acúmulo de impulso, não o acúmulo de conhecimento.
  • Lidar com a distração do ego me ensinou a amar o processo de resolução de problemas. Isso me ensinou a amar e respeitar o processo de aprendizado. Como resultado, sou mais produtivo. Estou menos ansioso. Sou um companheiro de equipe melhor. Sou um amigo melhor e um pensador melhor.
• Fixo versus crescimento: as duas mentalidades básicas que moldam nossas vidas
• Como é um ótimo engenheiro de software?
• Bom sono, bom aprendizado, boa vida
• ? Steve Jobs: se você não pedir ajuda, você não vai ficar muito longe
• Citações de programação
• Seja gentil
  • Ser gentil é fundamentalmente sobre assumir a responsabilidade pelo seu impacto nas pessoas ao seu redor.
  • Requer que você esteja atento aos sentimentos deles e atenda à maneira como sua presença os afeta.
• Warren Buffett diz que este 1 hábito simples separa pessoas de sucesso de todos os outros
  • A diferença entre pessoas de sucesso e pessoas realmente bem -sucedidas é que as pessoas realmente bem -sucedidas dizem não a quase tudo.
• Como ter sorte?
• Os programadores devem parar de comemorar a incompetência, DHH
  • A magia da programação é em grande parte apenas coisas que você ainda não conhece.
  • Não é bom pensar que você não deve estar em alguns caminhos para o domínio, se pretende fazer programar sua carreira.
• Não há limite de velocidade
• Não espere pela motivação, aja por impulso
  • Comece com uma pequena tarefa. Em seguida, monte seu impulso.
• Os hábitos de codificação mais importantes
  • Os hábitos de codificação mais importantes
  • Alongamentos diários
  • Faça pausas regulares
  • Não codifique tarde da noite
  • Melhore seu ambiente de codificação
• Conselhos para novos desenvolvedores de software que leram todos esses outros ensaios de conselho
• Os microsserviços não são o problema. Pessoas incompetentes são

A síndrome do impostor é subestimada: muita palestra entra na superação da síndrome do impostor. Eu digo abraçar o auto-keticismo e duvidar a si mesmo todos os dias. Em uma indústria veloz, onde muito do seu conhecimento expira todos os anos, mesmo as pessoas mais juniores ao seu redor cozinham constantemente as habilidades que você não tem; Você permanece competitivo ao aplicar com a determinação (e até o medo) do novato. A vantagem dessa esteira é que todo engenheiro está nela: só porque você é um impostor não significa que outras pessoas sejam mais merecedores do que você, porque elas também são impostores. Você deve se defender, correr riscos, dar um tapinha nas costas quando as coisas correrem bem e, quando você começa a criar um histórico de resolver problemas, confie em suas habilidades e adaptabilidade. Apenas não se engane: você é tão bom quanto o último problema que resolve.

Dan Heller, construindo uma carreira em software

Eu já havia aprendido a nunca esvaziar o poço da minha escrita, mas sempre parando quando ainda havia algo lá na parte profunda do poço, e deixou reabastecer à noite das fontes que a alimentavam. - Ernest Hemingway

• O desenvolvedor do Breg Brain: hábitos do programador autoconsciente. Como Tao de programação, estilo diferente.

O bom julgamento vem da experiência. A experiência vem de mau julgamento.

Procrastinação

• Notícias são ruins para você - e desistir da leitura o deixará mais feliz, o Guardian
  • Notícias enganos
  • Notícias são irrelevantes
  • Notícias não têm poder explicativo
  • Notícias são tóxicas para o seu corpo
  • Notícias aumentam erros cognitivos
  • As notícias inibem o pensamento
  • Notícias funcionam como uma droga
  • Notícias perdem tempo
  • Notícias nos tornam passivos
  • Notícias mata a criatividade

Autenticação/autorização

• Autorização em um mundo de microsserviços
• Lógica de autorização: as regras são difíceis porque evoluem com o tempo
• O Livro de Copenhagen fornece uma diretriz geral sobre a implementação de autenticação em aplicativos da Web

Automação

• A automação deve ser como Homem de Ferro, não Ultron

Práticas recomendadas

• Práticas de engenharia de software

Além de engenharia de software e aleatório

• Por que engenheiros de software como madeira

Preconceitos

Os vieses não se aplicam apenas à contratação. Por exemplo, o viés de atribuição fundamental também se aplica ao criticar o código de alguém escrito há muito tempo, em um contexto totalmente diferente.

• Folha de dicas de viés cognitivo. #contratando

Negócios

• Pagamentos 101 para um desenvolvedor
• Os 4 maiores problemas com sistemas de cobrança caseiros
• ? As 14 dores de construção de seu próprio sistema de cobrança

Cache

• Desafios e estratégias de armazenamento em cache, biblioteca da Amazon Builders

Crescimento na carreira

• Os triângulos conjuntos do desenvolvimento de nível sênior analisam como definir um engenheiro sênior.
• Dez princípios de crescimento como engenheiro, Dan Heller.
• Não se chame de programador, Patrick McKenzie.
• Em ser gerente de engenharia
• Os conselhos de carreira que eu gostaria de ter aos 25
  • Uma carreira é uma maratona, não um sprint
  • O maior sucesso vem da repetição, não coisas novas
  • Se o trabalho fosse realmente tão bom, todas as pessoas ricas teriam os empregos
  • A gerência é sobre pessoas, não coisas
  • Realmente ouça os outros
  • Reconheça que os funcionários são pessoas com capacidade emocional finita
  • Não apenas inteira com as pessoas com a sua idade
  • Nunca sacrifique a ética pessoal por um motivo de trabalho
  • Reconhecer que o fracasso está aprendendo
• Conselhos de carreira que eu gostaria de ter recebido quando era jovem
  • Não se concentre muito em planos de longo prazo.
  • Encontre bons pensadores e chamada fria dos que você mais admira.
  • Atribua um alto valor à produtividade durante toda a sua vida útil.
  • Não otimize coisas que não são sua principal prioridade.
  • Leia muito e leia coisas que as pessoas ao seu redor não estão lendo.
  • Refletir seriamente sobre qual problema priorizar a solução.
  • Leia mais história.
• Por que bons desenvolvedores são promovidos para a infelicidade, Rob Walling. Ou por que a gerência pode não ser para você.
• Um guia para usar sua carreira para ajudar a resolver os problemas mais prementes do mundo
• O que é o trabalho de um engenheiro sênior? Você precisa ser mais do que apenas um colaborador individual.
• De codificação de pós -graduação do bootcamp a bancos de dados distribuídos de construção
  • Leia livros (e papéis), não postagens de blog
  • Assuma a responsabilidade por sua trajetória de carreira
• ? O engenheiro bem arredondado inclui muitas ótimas recomendações de livros.
  • Poliglota de paradigma (aprenda diferentes idiomas e paradigmas)
  • Poliglota de banco de dados
  • Poliglota de protocolo (de preferência TCP/IP e HTTP)
  • Proficiência com ferramentas de construção, embalagem e distribuição
  • Depuração, observabilidade
  • Implantação, infra e DevOps
  • Arquitetura de software e escala
  • Capacidade de escrever compiladores de brinquedos, intérpretes e analisadores
  • Capacidade de escrever jogos de brinquedo
  • Capacidade de entender a análise algorítmica
• Alguns conselhos de carreira, Will Larson.
  • O conselho que você recebe é a tentativa de alguém de sintetizar suas experiências, não uma declaração precisa sobre como o mundo funciona.
  • Construa um reservatório de prestígio.
  • Algumas pessoas são tão boas em algo que acabam sendo insubstituíveis em seu papel atual, o que os leva a ficar preso em seu papel, mesmo que sejam um bom candidato a mais interessantes.
  • Grandes relacionamentos o seguirão onde quer que você vá. Maus também.
  • No início de sua carreira, tente trabalhar com tantos tipos diferentes de empresas e em diferentes produtos verticais possível.
• Dica do mal: evite coisas "fáceis"
• O código final kata
• Traços de um engenheiro sênior de software: impacto, percepção, visibilidade, influência, orientação
• Engenharia de software - as peças suaves
  • Pense criticamente e formule argumentos bem fundamentados
  • Domine os fundamentos
  • Concentre -se no usuário e tudo mais seguirá
  • Aprenda a aprender
• Como possuir seu crescimento como engenheiro de software
• O programador de quarenta anos
  • Quanto melhor você tiver, menos você se parece com todo mundo
  • Você aprende princípios profundos fazendo o básico
  • Olhe para outros campos, aprenda com outros campos
  • Tenha cuidado com as dicas de produtividade
• Engenheiros seniores estão vivendo no futuro
• Como seria um mapa da sua carreira?
• Como ter sucesso na Amazon (ou qualquer outra grande empresa para esse assunto)

Sobre engenheiros seniores:

• Falsidades desenvolvedores juniores acreditam em se tornarem seniores

Escolhendo sua próxima/primeira oportunidade

• Decisões de carreira - por Elad Gil - Elad Blog

Chegando ao Staff Eng

• Tornei -me um engenheiro da FAANG em 5 anos. Estas são as 14 lições que aprendi ao longo do caminho.
  • A engenharia de software não é apenas codificação. Na verdade, a codificação é uma pequena parte dela.
  • Pipeline seu trabalho
  • Esteja aberto a feedback e ouça. Sério, ouça.
  • É difícil encontrar um ótimo feedback; valorize.
  • Fique de olho no horizonte (mas não nos dois).
  • Descubra o que importa e deixe o resto ir.
  • A comparação é realmente o ladrão de alegria.
  • A orientação é uma coisa linda.
  • Bons dias, em geral, não apenas "aconteça".
  • Conselhos e orientações são exatamente isso; Eles não são regras.
• Guias para alcançar funções de engenharia de funcionários-mais
  • Sendo visível
  • Recursos adicionais em engenharia de funcionários-mais

Conjuntos de caracteres

• O mínimo absoluto todo desenvolvedor de software absolutamente, deve saber positivamente sobre o Unicode e os conjuntos de personagens (sem desculpas!)
• O mínimo absoluto que todo desenvolvedor de software deve saber sobre o Unicode em 2023 (ainda sem desculpas!)

Xadrez

(sim - xadrez recebe sua própria seção :)

• Wiki de programação de xadrez
• Comprimindo movimentos de xadrez

Nuvens

• Open-Guides/OG-AWS: um guia prático da AWS

Revisões de código

• Como fazer uma revisão de código, a documentação de práticas de engenharia do Google.
• Revisões pós-comprometimento: uma idéia interessante para aumentar a velocidade do desenvolvedor (existem algumas advertências).
• Como fazer seu revisor de código se apaixonar por você
  • Revise seu próprio código primeiro
  • Escreva uma descrição clara de Changelist
  • Automatize as coisas fáceis
  • Responda a perguntas com o próprio código
  • Alterações de escopo por pouco
  • Alterações funcionais e não funcionais separadas
  • Responda graciosamente às críticas
  • Solicitar informações ausentes
  • Conceda todos os laços com seu revisor
  • Minimizar o atraso entre as rodadas de revisão
• Como fazer críticas de código como um humano
• Ask HN: Como você revisa o código?: Ótima discussão sobre Hackernews, cheia de idéias interessantes.
• Pirâmide de Código de Código de Maslow
  • Outro sobre o mesmo tópico: a pirâmide de revisão de código
• Revisão do código em equipes remotas: conjunto muito completo de regras.
• Nenhuma revisão de código por padrão
  • Responsabilidade sobre a convenção

Codificação e qualidade do código

• Escreva código fácil de excluir, não é fácil de estender
• Os Dez Mandamentos da Programação de Egola
• Código limpo: um manual de artesanato de software ágil, Robert C. Martin. Descreve inúmeras práticas recomendadas úteis. Um pouco longo. Há também uma folha de truques de código limpo.
• O que é o artesanato de software
  • Estamos cansados ​​de escrever porcaria.
  • Não aceitaremos a velha mentira estúpida sobre a limpeza das coisas mais tarde.
  • Não acreditaremos na alegação de que rápido significa sujo.
  • Não permitiremos que ninguém nos force a se comportar de maneira não profissional.
• Dicas sobre como nomear variáveis ​​booleanas
  • Existe uma convenção para prefixar variáveis ​​booleanas e nomes de funções com "is" ou "hou".
  • Tente sempre usar é, mesmo para plurais ( isEachUserLoggedIn é melhor que areUsersLoggedIn ou isUsersLoggedIn )
  • Evite prefixos personalizados ( isPaidFor é melhor do que wasPaidFor )
  • Evite negativos ( isEnabled é melhor do que isDisabled )
• Como escrever código não de dizeres
• Kettanaito/Naming-Cheatsheet: Casa do padrão A/HC/LC.
• ? Guias de engenharia de qualidade

Comunicação

Veja também a seção de escrita

• Como se comunicar efetivamente como desenvolvedor
  • Muitos conselhos e exemplos concretos para escrita curta, média e longa
• O que você visualiza durante a programação?

Compiladores

• A página de recursos do compilador
• kanaka/mal: mal - faça um lisp

Configuração

• As desvantagens do JSON para arquivos de configuração, Martin Tournoij.
  • Não posso adicionar comentários
  • Citação excessiva e ruído de sintaxe
  • Usar CC (configuração declarativa) para controlar a lógica geralmente não é uma boa ideia.
• Suas configurações são péssimas? Experimente uma linguagem de programação real
  • Os formatos de configuração mais modernos são péssimos
  • Use uma linguagem de programação real

Integração contínua (IC)

• Integração contínua, martinfowler.com

Bancos de dados

Veja também a seção SQL.

• Uma introdução inglesa clara ao teorema de Cap
• Teorema do PACELC: "No caso de particionamento de rede (p) em um sistema de computador distribuído, é preciso escolher entre disponibilidade (a) e consistência (c) (conforme o teorema do limite), mas caso contrário (e), mesmo quando o sistema está sendo executado normalmente na ausência de partições, é preciso escolher entre latência (l) e consistência (c). "
• Migrações de banco de dados de tempo de inatividade zero (exemplos de código estão usando trilhos, mas isso funciona muito bem para qualquer linguagem de programação)
• Algoritmos por trás dos modernos sistemas de armazenamento, fila ACM
• Vamos construir um banco de dados simples
• Leituras em sistemas de banco de dados, 5ª edição
• Comparando os tipos de banco de dados: como os tipos de banco de dados evoluíram para atender às diferentes necessidades
• Como funciona um banco de dados relacional
• Use o índice, Luke
• Introdução ao curso - MySQL para desenvolvedores, PlanetScale
• Como funcionam os motores de consulta
• Por que você provavelmente deveria estar usando o SQLITE | EPIC Web Dev

Nosql

• Padrões NoSQL
• Bancos de dados NoSQL: uma orientação de pesquisa e decisão
• O DynamoDB Docs tem ótimas páginas:
  • Leia a consistência
  • De SQL para NoSQL
  • NOSQL Design for DynamoDB
• Redis explicou

PostGres

• Operações seguras para o PostgreSQL de alto volume (isso é para PostgreSQL, mas também funciona muito bem para outros DBs).
• Isolamento de transações em Postgres, explicado
• Exercícios PostgreSQL
• Postgres Operations Catch Sheet
• Basta usar o Postgres
• Postgres é suficiente
• PostGres: não faça isso
• PostGresql e Uuid como chave primária

Formatos de dados

• Os programadores de falsidades acreditam sobre os números de telefone, libphonenumber do Google.
• Regras para preenchimento automático: especificações aproximadas para campos de preenchimento automático
• Os programadores de falsidades acreditam sobre endereços
• Os programadores de falsidades acreditam sobre nomes
• Kdeldycke/Awesome-Falsehood: Falshonds Programmers acreditam em
• Compreendendo Uuids, ULIDs e Representações de String
• Os programadores de falsidades acreditam nas listas de falsidades
• Austrália/lord_howe é a fuga mais estranha

Ciência de dados/engenharia de dados

• Uma dúzia suja: doze armadilhas comuns de interpretação métrica em experimentos controlados on -line
• DataStackTV/Data-Engineer-Roadmap: Roteiro para se tornar um engenheiro de dados
• Caminho de aprendizado de engenharia de dados impressionante
• Arquiteturas emergentes para infraestrutura de dados modernos
• Como ir além de um lago de dados monolítico para uma malha de dados distribuída
  • As plataformas de dados baseadas na arquitetura do Data Lake possuem modos de falha comuns que levam a promessas não realizadas em escala.
  • Precisamos considerar os domínios como a preocupação da primeira classe, aplicar o pensamento da plataforma para criar infraestrutura de dados auto-atendidos e tratar os dados como um produto.
• Mlops
• Plataforma de Big Data da Uber: mais de 100 petabytes com latência minuciosa
• O SQL deve ser a opção padrão para a lógica de transformação de dados

Depuração

Veja também a seção de resposta a incidentes neste documento

• Resolução de problemas de pato de borracha
• Borracha se esquivando
• Cinco porquês
• A análise das cinco mentiras
  • O problema real se revela quando a técnica se torna parte de um modelo.
  • Os itens de ação podem estar muito distantes da causa raiz.
• O Infinite Hows critica o método cinco porquês e defende um conjunto diferente de perguntas para aprender mais com os incidentes.
  • Veja também: Erros humanos: modelos e gerenciamento
  • "O problema com os cinco porquês é que ele é revisado no túnel em uma explicação linear e simplista de como o trabalho é feito e os eventos acontecem".
  • "O erro humano se torna um ponto de partida, não uma conclusão". (Dekker, 2009)
  • "Quando perguntamos 'como?', Estamos pedindo uma narrativa."
  • "Quando se trata de decisões e ações, queremos saber como fazia sentido alguém fazer o que fazia".
  • Em cada etapa de "por que", apenas uma resposta será selecionada para uma investigação mais aprofundada. Perguntar "como" incentivar a exploração mais ampla.
  • "Na investigação de acidentes, como na maioria dos outros empreendimentos humanos, fazemos vítimas do que você gosta de ser o princípio do que é o que é um reconhecimento do fato de que as suposições sobre o que somos somos Vou ver (o que você gosta), em grande parte, determinará o que realmente encontramos (o que você encontra). " (Hollnagel, 2009, p. 85) (ver ilustração de 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

Recursos:

• ? 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.

Articles:

• 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)

Recursos:

• ? 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

Ferramentas

• 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.

Docker

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

Documentação

• 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
  • Delegar
  • 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

Artigos

• 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

• ? 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

E-mail

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

Engineering management

Checkout my list of management resources.

Exercises

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

Prática:

• CodinGame
• Codewars
• Exercism

Experimentação

• 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
• ? Functional Programming
• 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

Gráficos

• Text Rendering Hates You

Hardware

• 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

Humor

• 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.

Postmortem

• 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:

• Sumário executivo
  • Impacto
  • Causa raiz
• Impacto
  • Number of impacted users
  • Lost revenue
  • Duração
  • Team impact
• Timeline
  • Detecção
  • Resolução
• 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)

Internet

• 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.

Retomar:

• 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 para. — Elon Musk

"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

Matemática

• ? Statistics for Hackers

Marketing

• goabstract/Marketing-for-Engineers

Rede

• 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)

Logging

• 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

Metrics

• 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!
• Pensar demasiado
  • 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

Desempenho

• 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.
  • Medir
  • 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".

Perspectiva

• 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

Privacidade

• 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

Gerenciamento de projetos

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
• Tipos
• 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

Python

For Python check out my professional Python education repository.

JavaScript

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

Leitura

• 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
  • Take notes
  • 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

Regex

• 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

Versão

• 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

Confiabilidade

See also System architecture

Books:

• 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.

Citações:

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.

Articles:

• I already mentioned the book Release it! acima. 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

Recursos:

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

Resiliência

• ? 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)

Procurar

• What every software engineer should know about search

Segurança

• 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.

Books:

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

Articles:

• 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

Escalabilidade

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.

Teste

• ️ 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

Ferramentas

• 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

Tipografia

• 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
  • Princípios
  • Style guides
  • Docs as code
  • Markup languages
  • Ferramentas
• Technical Writing One introduction, Google
  • Gramática
  • 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 ️
• VentureBeat
• High Scalability: see above

Segurança:

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

Newsletters:

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

Blogs:

• kilimchoi/engineering-blogs

Concepts

Glossário

• BDD
• CAP theorem
• DDD
• SECO
• EAV
• ENTENDER
• BEIJO
• Make it run, make it right, make it fast
• OOP
• SÓLIDO
• TDD
• Two Generals' Problem
• YAGNI

My other lists

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