O que todo programador deve saber?

Independentemente da (s) linguagem (s) de programação ou sistema (s) operacional (is) usado (s) ou do ambiente para o qual eles desenvolvem, o que todo programador deve saber?

Alguns antecedentes:

Estou interessado em me tornar o melhor programador possível. Como parte desse processo, estou tentando entender o que não sei e me beneficiaria muito se soubesse. Embora existam muitas listas ao longo das linhas de "n coisas que todo desenvolvedor de [linguagem de programação de inserção] deveria saber", ainda não encontrei nada semelhante que não se limite a uma linguagem específica.

Também espero que essas informações sejam de interesse e benefício para os outros.

Como engolir orgulho e admitir erros sem levá-los pessoalmente.

Como pensar como um usuário, e não como um programador nerd de tecnologia.

Quando pedir ajuda e quando NÃO pedir ajuda.

Como ler o código de outras pessoas.

Familiaridade com os sistemas de controle de versão. Não precisa ser todo mundo, mas os conceitos básicos que podem ser aplicados a todos eles devem ser conhecidos.

Aqui estão meus 10 bits:

• Como ser humilde. Estamos todos aqui para aprender. Você pode ser mais esperto que os outros, mas há muitas pessoas mais espertas que você.
• Como estudar / consumir informações. Não sei você, mas estou estudando para sempre! Livros, Internet, tanto faz!
• O que é um dicionário e como usá-lo, e como descobrir acrônimos rapidamente.
• Quais são as ferramentas básicas do comércio e o que elas fazem (IDE, CVS et al).
• Conheça terminologia comum e o que eles significam: padrões de design, usabilidade, teste (ha!), Pilha, etc.
• Compreenda o POO.
• Seja "capaz" em pelo menos um idioma, nada incrível, apenas saiba como identificar variáveis ​​e métodos, etc. A partir daqui, você pode aprender RÁPIDO.
• Entenda que, em última análise, as pessoas usam software e desejam fazê-las felizes.

Talvez seja muito sutil, mas penso nisso como "saber qual problema resolver". Muitos programadores (e pessoas normais) perdem um tremendo esforço resolvendo coisas que simplesmente não são muito importantes; ou eles criam uma solução, com muito trabalho extra, que não é exatamente o que é necessário.

Como relaxar. É o segredo da produtividade.

Eventualmente, força de vontade e cafeína não são suficientes. Essa constante contração que fazemos é muito prejudicial.

Este é um grande negócio.

Tipo básico de dados e teoria de algoritmos. Coisas como notação Big O, matrizes, filas etc.

Como escolher a ferramenta certa para a tarefa certa e não participar de guerras tolas e inflamadas sobre suas ferramentas de programação favoritas.

Bem, aqui está o meu .02 $:

• O aprendizado nunca para. Não importa o quão bom você pense que é, sempre há alguém melhor que você e sempre há algo que você pode melhorar sobre si mesmo. Se você parar de aprender, inevitavelmente se degradará como programador. Leia livros. Leia blogs. Converse com outros programadores.
• Tente aprender vários idiomas. Pelo menos um deles é orientado a objetos. Além disso, você deve saber algo sobre várias tecnologias relacionadas à linguagem que você aprende (por exemplo, se você aprender Java, seria bom se você soubesse algo sobre Spring, etc.).
• Refatoração. Cedo ou tarde, você precisará desse conhecimento.
• Aprenda a lidar com o código herdado.
• Escreva testes de unidade. Aprenda sobre o TDD.
• Aprenda a trabalhar em equipe.
• Escreva um código elegante e legível. Como diz o velho ditado: "Escreva seu código como se a pessoa que o manteria fosse um serial killer psicótico que sabe onde você mora".
• Aprenda a ser preguiçoso e disciplinado ao mesmo tempo. Bons programadores possuem essas duas qualidades. Por mais estranho que pareça, eles não são contraditórios entre si, mas complementares.

Você não pode testar a qualidade de um produto.

Todo programador deve entender os padrões de design .

Estou um pouco atrasado para este, mas vou com o conhecimento estabelecido por Edsger Dijkstra:

Além de uma inclinação matemática, um domínio excepcionalmente bom da língua nativa é o ativo mais vital de um programador competente.

Se você não consegue escrever um bom parágrafo, é provável que também não consiga escrever um bom código.

Não fique muito emocional, apegado ou religioso a qualquer tecnologia, sistema operacional ou idioma - nenhum é perfeito - a longo prazo, é provável que você acabe desejando criar seu próprio ala carte a partir do que você como sobre cada um diferente.

Pense nisso como carros - você pode não ter dirigido um carro em particular antes, mas todos eles têm chaves, volantes, aceleradores e freios - você deve poder entrar em um e sair rapidamente assim que descobrir o que está acontecendo. Trate sistemas operacionais e idiomas da mesma forma e concentre-se em aprender os conceitos essenciais subjacentes a eles, mesmo se você estiver envolvido nas especificidades de qualquer instância.

E, com o tempo, tente entender e apreciar a ancestralidade, a herança e os pontos em comum das várias tecnologias que ajudarão você a manter a perspectiva. Perceba, por exemplo, que, embora a árvore evolutiva esteja se ramificando ativamente e cheia de becos sem saída, com o tempo a tecnologia tende a convergir repetidamente em torno das 'melhores práticas' e 'economias de escala' ( por exemplo, observe que um Mac não é tão diferente de um PC sob o capô nos dias de hoje ...).

Por fim, lembre-se, não importa o quanto você esteja se divertindo com tudo isso, a tecnologia representa essencialmente uma lente imperfeita entre o que sua mente pode imaginar e o que você realmente produz. Faça o seu melhor, aprenda a aprender e permaneça adaptável ...

Como programar em C.

Que o dia em que você para de aprender deve ser o dia em que não é mais um programador.

Teste de unidade e depuração.

• Expressões regulares
  • Para que servem
  • Quando não a utilizar -los
  • Como escrever regexes legíveis
  • Como depurá-los

Já foi mencionado antes, mas acho que merece sua própria resposta.

Ninguém quer usar software. Eles querem problemas resolvidos.

Coffee e IntelliSense são seus melhores amigos de todos os tempos.

Como observar um grande objeto complicado e decompô-lo em pequenos objetos simples que ainda realizam a mesma tarefa quando montados novamente.

Nunca confie em um usuário ( especialmente se o aplicativo for público!), Ele fará tudo o que estiver ao seu alcance para interromper seu aplicativo de uma maneira ou de outra.

Torne-o à prova do futuro e expansível - você nunca sabe quando deseja expandi-lo em alguns anos e percebe quanto esforço seria necessário para re-codificar códigos mal criados.

Que o programador não sabe tudo e deve sempre tentar aprender novas linguagens / tecnologias, etc.

Noções básicas de um bom design de interface do usuário e design de comunicação (também conhecido como gráfico) .

Vejo tantos aplicativos e projetos arruinados por mau design ou pouca usabilidade. Apenas aprender o básico pode fazer um mundo de diferença. Além disso, as técnicas visuais de solução de problemas (como comunicar um conceito visualmente) são um desafio estimulante que deve abrir seus olhos para novas formas de ver, que, por sua vez, devem impactar seu código.

Um livro recomendado é o livro de design de não-desenhista de Robin Williams

Aqui está o que Joel Spolsky diz sobre isso :

Uau! Todo mundo tem que fazer algum design gráfico, e nem toda equipe de software tem o luxo de designers profissionais. Este excelente e fino livro lhe dará uma compreensão dos princípios por trás do layout da página, fontes, etc. A boa notícia é que você pode lê-lo no banho antes que a água esfrie. No dia seguinte, suas caixas de diálogo e powerpoints e as páginas da web começarão a ter uma aparência melhor.

Todo programador deve saber aprender rapidamente. Muitas vezes você entra em um emprego e será solicitado a desenvolver uma tecnologia que nunca usou. Eles podem lhe dar uma semana ou mais para se levantar (se você tiver sorte) antes de ser solicitado a escrever um código de qualidade de produção.

Controle de versão. E para citar minha namorada: "Eu não quero apenas que você lave a louça, quero que você goste !"

Os requisitos mudam, seu código precisará se adaptar e pode ou não ser você quem deve adaptá-lo.

Houve várias perguntas aqui relacionadas a tópicos afetados por isso.

Em cima da minha cabeça:

1. Muito poucos problemas de programação exigem matemática além de adição, subtração, multiplicação e divisão. Se você estiver pensando em usar o cálculo para resolver um problema, pesquise exaustivamente as alternativas antes de fazê-lo.

2. Sempre que você adivinhar como algo deve funcionar, você está fazendo errado. Não é seu trabalho ser telepático.

3. A pessoa que fornece as especificações raramente sabe tudo o que quer até que você as resolva.

4. Mais da metade de ser um grande programador vem de lidar com seres humanos. Interagir com sua equipe, gerenciar seu gerente e aperfeiçoar o usuário final são metade do trabalho.

5. Um bom código é escrito para ser lido pelas pessoas tanto quanto pelo seu compilador.

6. As melhores práticas e a realidade prática estarão em conflito mais do que o programador pensa, mas menos do que o gerente. Quando eles parecem estar em conflito, cabe a você delinear e entender o conflito e ceder à prática. A solução sutil e inteligente só é melhor que a feia e brutal, se for mais rentável a longo prazo.

7. Ótimas ferramentas não podem criar ótimos programadores, mas ferramentas ruins nos tornam igualmente terríveis.

8. Nunca menospreze uma tecnologia, mas sempre procure a melhor alternativa.

9. Quanto mais idiomas você souber, melhor estará no idioma que está usando.

10. Não seja perturbado pelo lento rastejamento dos pensamentos orientados para a programação em sua vida diária. Mesmo quando não estamos em um computador, todos sofrem limitações de largura de banda, sofrem penalidades de desempenho pela alternância de tarefas e precisam carregar coisas do armazenamento de backup. Os computadores devem imitar o pensamento humano e os análogos estão por toda parte.

Ler o código de outras pessoas não vai estragar seu cérebro, mas sim descobrir por que você não faria dessa maneira (se melhor ou não, é outra questão).

Isso fornece a você experiência de programação e, ocasionalmente, você encontra alguém implementando algo muito melhor! Como de uma maneira melhor.

Essa resposta naturalmente se expande para a leitura de seu próprio código, e se expande para usar o controle de versão e o DIFF e, portanto, para 42.