ti-enxame.com

O que todo programador deve saber sobre programação?

Por favor, mantenha-se em questões técnicas, evite problemas de comportamento, culturais, de carreira ou políticos.

52
Maniero
  1. O bug está no seu código , não no compilador ou nas bibliotecas de tempo de execução.

  2. Se você vir um erro que não pode acontecer, verifique se você criou e implantou corretamente o seu programa. (Especialmente se você estiver usando um complicado IDE ou uma estrutura de construção que tente ocultar os detalhes confusos de você ... ou se a sua construção envolver muitas etapas manuais))

  3. Programas simultâneos/multiencadeados são difíceis de escrever e de testar adequadamente. É melhor delegar o máximo possível para bibliotecas e estruturas de simultaneidade.

  4. Escrever a documentação faz parte do seu trabalho como programador. Não deixe para "outra pessoa" fazer.

EDITAR

Sim, meu ponto 1 é exagerado. Até as melhores plataformas de aplicativos de engenharia têm sua parcela de bugs, e algumas das menos bem projetadas estão repletas delas. Mas, mesmo assim, você deve sempre suspeitar do seu código primeiro e só começar a culpar os erros do compilador/biblioteca quando tiver evidência clara de que seu código não tem culpa.

Na época em que desenvolvi o C/C++, lembro-me de casos em que supostos "bugs" do otimizador eram devidos a mim/algum outro programador que fez coisas que as especificações da linguagem dizem ter resultados indefinidos. Isso se aplica mesmo a linguagens supostamente seguras como Java; por exemplo. dê uma olhada longa no Java (JLS, capítulo 17).

92
Stephen C
  • Como ler o código de outras pessoas.
  • O código não existe se não estiver marcado no Version Control System.
84
pramodc84

Os cálculos de ponto flutuante são não precisos.

76
Chinmay Kanchi

Não pare de aprender.

63
systempuntoout

Que a primeira coisa que você pode fazer para aumentar a qualidade e a manutenção do seu código é REDUZA A DUPLICAÇÃO.

44
Chris Holmes

Habilidades para solução de problemas e depuração

Eles dificilmente dedicam algum tempo a esse tópico em qualquer um dos cursos de programação que participei e, na minha experiência, é um dos maiores determinantes da produtividade de um programador. Goste ou não, você passa muito mais tempo na fase de manutenção do seu aplicativo do que na nova fase de desenvolvimento.

Eu trabalhei com muuuuito muitos programadores que depuram mudando aleatoriamente as coisas sem nenhuma estratégia para encontrar o problema. Eu tive essa conversa dezenas de vezes.

Outro programador: Acho que devemos tentar ver se isso corrige.
Eu: Ok, supondo que isso seja corrigido. O que isso diz sobre onde está a fonte do problema?
Outro programador: Eu não sei, mas temos que tentar alguma coisa .

39
JohnFx
  1. Não seja esperto; seja claro.
  2. Use antes da reutilização.
  3. Nomes importam.
  4. Uma função faz 1 coisa e faz bem.
  5. Pequeno é melhor que grande.
37
KevBurnsJr

O básico. Atualmente, os programadores aprendem tecnologias, não conceitos. Está errado.

34
clrod

Todo programador deve saber que está colocando suposições no código o tempo todo, por exemplo "este número será positivo e finito", "este código poderá se conectar ao servidor o tempo todo em um piscar de olhos".

E ele deveria saber que deveria se preparar para quando essas suposições quebrassem.

26
LennyProgrammers

Todo programador deve saber sobre o teste.

19
Tom Duckering

Aprenda conceitos. Você pode pesquisar no Google a sintaxe.

17
pramodc84

Pensamento crítico e lógico. você não pode fazer nada de bom sem ele.

16
Mladen Prajdic
14
Carlos

Teste de unidade. Essa é uma ótima maneira de codificar suas suposições sobre como o código deve ser usado.

14
btlog
13
Maniero

Conhecimento de domínio. A especificação nunca é 100%; conhecer o domínio real com o qual você está desenvolvendo SEMPRE aumentará a qualidade do produto.

13
Steven Evers

É mais difícil do que você pensa.

Embora seja fácil (ish) montar algo que funcione quando usado normalmente, lidar com entradas erradas, todos os casos de Borda e canto, possíveis modos de falha etc. é demorado e provavelmente será a parte mais difícil do trabalho.

Então você deve fazer com que o aplicativo pareça bom também.

13
ChrisF

Ponteiros, obviamente. :)

11
Laurynas Biveinis

Os dados são mais importantes que o código.

Se seus dados forem inteligentes, o código pode ser estúpido.

Código idiota é fácil de entender. O mesmo acontece com dados inteligentes.

Quase todo sofrimento algorítmico que eu já tive foi devido a dados estarem no lugar errado ou abusar de seu verdadeiro significado. Se seus dados tiverem significado coloque esse significado no sistema de tipos.

11
Gonzales

Código Completo 2 - capa a capa

11
Kyle B.

Qual idioma e ambiente é mais adequado para o trabalho. E nem sempre é o seu favorito.

10
Dan Diplo

Dividir e conquistar. Geralmente, é a melhor maneira de resolver qualquer tipo de problema prático, do agendamento à depuração.

10
Rick Minerich

A verdadeira habilidade se reflete na capacidade de executar bem um design simples, e não na capacidade de fazer um design complicado funcionar.

Essa habilidade vem do domínio maior dos fundamentos, não do domínio do arcano. Um programador de alto calibre não é definido por sua capacidade de codificar o que os outros não podem (usando funções de nível superior, programação funcional avançada, o que você tem), mas sim por sua capacidade de refinar a codificação perfeitamente mundana. Escolhendo a decomposição apropriada da funcionalidade entre as classes; construção em robustez; usando técnicas de programação defensiva; e usando padrões e nomes que levam a uma maior autodocumentação, esses são os ingredientes da programação de alto calibre.

Escrever um código bom para o qual você ou outra pessoa possa voltar em uma semana por mês ou ano e entender como usar, modificar, aprimorar ou estender esse código é crucial. Isso economiza tempo e esforço mental. Lubrifica as rodas da produtividade removendo obstáculos que você tropeçaria antes (talvez interrompendo sua linha de raciocínio, ou talvez tirando horas ou dias de esforço de outros trabalhos, etc.) Isso facilita a concentração nos problemas difíceis , e às vezes faz com que os problemas difíceis desapareçam.

Em uma palavra: elegância. Toda classe, todo método, toda condição, todo bloco, todo nome de variável: busca pela elegância.

8
Wedge

Nunca culpe o usuário pelo que poderia ser corrigido com uma experiência mais limpa ou com uma documentação melhor. Frequentemente, os programadores assumem automaticamente que o usuário é um idiota que não pode fazer nada direito, quando o problema é uma experiência geral ruim ou falta de comunicação. Os programas devem ser usados, e tratar o usuário com desprezo é perder o ponto de programação em primeiro lugar.

8
user8

Todo programador deve saber como usar o depurador e saber como usá-lo bem.

6
Brian R. Bondy

Como usar o Google

5
bruno077

Estruturas de dados

5
Maniero

Avaliação de curto-circuito, embora seja uma das primeiras coisas que eles ensinam sobre operadores booleanos.

4
Federico klez Culloca

Erros do usuário não são; eles são erros de usabilidade:

  • A funcionalidade perigosa deve ser desfazível, não apenas avisada. Veja aqui rm, que ainda não funciona com a lixeira.
  • Faça o coisa menos prejudicial se o usuário quebrar (ESC, Ctrl-C). Idealmente, o sistema deve estar no mesmo estado que antes de executar o comando. rm, novamente.
  • As opções prejudiciais devem estar longe das inofensivas. Clicar com o botão direito do mouse em um arquivo na lata de lixo do GNOME mostra "Excluir permanentemente" diretamente ao lado de "Restaurar" :(

Não escolher especificamente as ferramentas GNU Tools ou GNOME, mas estes foram os exemplos mais fáceis de se apresentar.

4
l0b0

Como estimar com precisão quanto tempo um recurso levará para implementar. Mais importante, como transmitir que você não está mentindo quando envia essa estimativa.

4
wheaties

O estilo de codificação é importante:

  • indentação consistente é importante,
  • o uso consistente do espaço em branco (por exemplo, ao redor dos operadores) é importante,
  • posicionamento consistente de {} s assuntos,
  • identificadores bem escolhidos são importantes,
  • etc.

... e um bom design é importante.

Idealmente, o programador aprende essas coisas antes (ou durante) de sua primeira revisão de código. Na pior das hipóteses, o programador as aprende quando o chefe diz a ele para fazer algumas alterações não triviais em algum código horrível com pressa.

4
Stephen C

Falando em desenvolvimento de software comercial aqui ... Obviamente, pode não se aplicar a um sistema de segurança do DOD ou a um quant de fundo de hedge.

  • Concentre-se no que funciona, não no que é inteligente, KISS.
  • Lembre-se da regra 80/20 e não gaste todo o seu tempo tentando agradar/vender a minoria.
  • Faça um curso em estruturas de dados/algoritmos.
  • Teste, teste, teste.
  • Não mexa no código que está em produção e atualmente está funcionando. A menos que você tenha fluxo de caixa excessivo e nenhuma idéia nova. Então está bem.
  • A grande maioria do seu tempo será gasta classificando o cruft e não resolvendo problemas interessantes de programação. A menos que você esteja entrevistando, nesse caso, as pessoas só querem ver como você resolve problemas interessantes de programação.
3
red-dirt

Que há -

1) Outros paradigmas de programação além de apenas OO (orientação a objetos) 2) Outros IDEs melhores além do Visual Studio (este é especialmente para programadores que trabalharam apenas no Windows e apenas nas tecnologias MS)

3
Manoj Waikar

Como o computador realmente funciona, fundamentos da linguagem, algoritmos/estruturas de dados, análise de algoritmos e alguma medida da teoria da complexidade.

3
Paul Nathan

Não acredito que isso não foi mencionado

Todo programador que vale o sal precisa ser capaz de produzir software pronto para o mundo .

Com isso, quero dizer seguir os princípios básicos de internacionalização, como externalizar todas as strings etc.

Não consigo acreditar quantas vezes eu vi seqüências de caracteres em inglês codificadas ou diálogos com seqüências de caracteres truncadas etc. quando o produto foi traduzido.

2
Jimmy Collins

O teste de unidade não é uma bala de prata. Você ainda pode introduzir bugs, escrever testes errados e essa não deve ser a única forma de teste que você faz.

2
aqwert

Computadores não entendem semântica. Suponha que você tenha o seguinte:

var ferrari = new Ferrari();
ferrari.DriveTo(Places.Seattle);

Para o computador, você também pode ter usado nomes de tipos diferentes e usado:

var mxEEcceqs = new safHBBdueWE();
mxEEcceqs.HYBbQAW(n3dNm.pDojeW);

Nomear coisas é muito importante, mas não cometa o erro de supor que o computador sabe o que você "quer dizer" apenas porque nomeou seu tipo "Ferrari" ou seu método "DriveTo".

2
xofz

Ordem de execução.

Você ficaria surpreso ao falar com programadores versus pessoas que nunca viram ou tocaram códigos ou que fingem programadores *, o que eles não entendem é a ordem de execução. Se você encontrar alguém que não consiga entender as estruturas de controle, pegue essa ideia primeiro. Você verá que eles aprendem mais rápido depois disso.

* sim, aquelas pessoas capazes de conseguir emprego como programador, mas quando você faz a pergunta técnica mais simples, elas ficam peidando. Acho que todos conhecemos uma delas.

2
Philip

Todo programador deve conhecer a "ciência" em Ciência da Computação (padrões de design, algoritmos, objetos, etc ...) se você pode dominar isso, pode programar usando qualquer linguagem, é apenas uma questão de se acostumar com a sintaxe.

2
JD Frias

O que é lexing e análise, apenas uma vaga visão geral é boa. Melhor ainda, passando a familiaridade com pelo menos uma estrutura de gerador de analisador.

A maioria das WTFs mais horríveis que eu já vi são as rotinas de análise personalizadas das pessoas. Horrível codificar inicialmente, pior para manter.

2
angusgr

Avaliação.

Um programador deve saber como as declarações que eles escrevem são avaliadas. a(line.of(code) is aSequenceOf(evaluations)) e se você não entender como essa linha se parece após cada etapa de sua avaliação, você será extremamente restringido como programador em sua capacidade de tirar proveito dos recursos da linguagem.

Não estou falando apenas do básico

if (bool == false):
    return true
else:
    return false

que obviamente pode ser substituído por return !bool.

Também estou me referindo à capacidade de entender seu idioma até o ponto em que você pode criar algo assim:

string[] thingsToOutput;
for(int i = 0; i <= thingsToOutput.Length; print(thingsToOutput[i++]));    

Quando vi pela primeira vez uma afirmação como essa, fiquei um pouco confusa; não me ocorreu que eu poderia aproveitar o loop for de tal maneira. A pessoa que escreveu essa declaração compreendeu mais plenamente as possibilidades disponíveis para elas - viu mais portas abertas do que eu, o que lhes deu mais liberdade e poder em sua capacidade de projetar código.

Agora, se é um código bom é um problema - se alguma dessas portas deve deve ser aberta - isso está em debate. Resta que com grande poder vem grande responsabilidade.

2
doppelgreener

Que saber a resposta a esta pergunta não faz de você um programador

2
hplbsh

Noções básicas de licenciamento de software

  • A diferença entre uma licença copyleft "viral" (GPL) quando comparada ao Apache compatível com fonte fechada e ao MS-PL/MS-RL não viral.

  • Quando você deve usar LGPL e quando não.

  • Compatibilidade de licença. Por exemplo, você pode vincular uma biblioteca moderna com licença do Apache a um código GPLv3, mas não à GPL 1 ou 2.

  • Se você possui o código fonte na sua totalidade, poderá publicá-lo com quantas (ou poucas) licenças desejar.

Nota para S.O. comunidade:
Sinta-se à vontade para editar esta resposta como achar melhor ... principalmente para informações não adequadas para a seção de comentários abaixo.

2
goodguys_activate

Criptografia. Você não precisa escrever seu próprio algoritmo de criptografia, mas precisa ter um entendimento básico de como a criptografia, a autenticação de mensagens e a PKI funcionam. Eu lutei por muito tempo com tentativas e erros cegos nessa área. Recentemente, peguei o livro "Cryptography Engineering" (de Ferguson, Schneier, Kohno) e ele tem sido um verdadeiro revelador.

2
Tobias

Conheça o seu sistema operacional/plataforma antes de começar a codificar.

Se você codificar Windows/Linux/Android/iOS etc., comece aprendendo o sistema operacional. Se você segmentar outra coisa como a Web, o mesmo vai para lá.

1
Amir Rezaei

escreva código para as pessoas!

não há mais número mágico!

não escreva todo o código em uma linha!

1
linjunhalida
  1. construir algo que as pessoas querem
  2. construa algo que você deseja usar todos os dias
  3. se você não comentar seu código, verifique se ele está limpo
  4. comente seu código
1
Michael Ossareh

Não existe um bug que não possa acontecer.

1
Rayne

"Hello world" não é uma aplicação completa, pois não há afirmação programática/demonstrada de que a saída seja de fato "Hello world". O código não está completo até que tenha sido testado em unidade.

1
stimpy77

Alguns deles já foram publicados, mas aqui está minha lista:

  • Desenvolva os requisitos, não adicione coisas que não precisa, especialmente se você "pensa" que vai. Se você precisar mais tarde, adicione-o então.
  • Como usar a pesquisa do Google. Não incomode seu colega de trabalho até que você tenha olhado.
  • Não seja esperto.
  • Isso não é feito até que atenda a TODOS os requisitos, testado, documentado e verificado no SVN.
  • Padrões de codificação adequados, por exemplo: convenções de nomenclatura
1
Tyler Egeto

Aprenda a implantar bem seu código, testes e pacote de software.

Um dos piores hábitos dos desenvolvedores que já vi na indústria é o desconhecimento comum de como colocar seu software nas mãos de outras pessoas, eis alguns sinais ruins:

Novo ambiente de desenvolvimento-itus:

  • Eu queria aprender Ruby então escrevemos nossas coisas nele, o cliente e a compilação principal terão que escolher um Ruby agora

Versão-itus:

  • Nossa equipe mudou-se para a versão X + 1 do compilador, porque é a mais recente, não contamos a ninguém?
  • Precisamos da versão da biblioteca Y, ah, suas coisas não funcionam com isso?
  • Testamos em um lançamento muito antigo, ele não funciona com a versão mais recente?
  • Criamos uma versão especial do kernel para que o lançamento funcione

Binário apenas-itus:

  • Nosso ambiente de construção é realmente complicado, nós apenas forneceremos binários

Multi-core-itus:

  • Desabilite o SMP, nossas coisas só funcionam no ambiente de uniprocessador

Código-recurso-itus:

  • Descomente este #define para ativar o recurso X, o que você quer dizer com ele em tempo de execução?
1
tonylo

Simplicidade, Clareza, Generalidade. http://www.math.harvard.edu/computing/programming/rules.html

  • construir sistemas como redes de processos simples conectados por soquetes/tubos
  • troque dados em um formato de texto simples: conjuntos de registros de pares "chave: valor" ou TSV

"A ferramenta de depuração mais eficaz ainda é o pensamento cuidadoso, juntamente com declarações de impressão colocadas criteriosamente." BWK

1
user2137

Quanto mais você souber como a segurança funciona na sua plataforma de escolha, melhor.

1
Ripped Off

Use a ferramenta certa para o trabalho.

O programador é o elemento importante e a linguagem e as ferramentas devem ser escolhidas com base no problema. Não tenha medo de novos idiomas e projetos.

1
Jonathan Hendler
1
Daniel Grillo

Não há choro na programação!

1
Billy Coover
  1. uma compreensão completa dos conceitos fundamentais, p. tipos de dados, interfaces
  2. um entendimento de nível médio a alto da ferramenta que eles estão usando, por exemplo conhecimento específico de .net/Java
  3. uma ideia razoável de "as outras tecnologias com as quais suas coisas interagem", por exemplo como os bancos de dados funcionam
  4. aproximadamente para onde sua base tecnológica está direcionada, p. o que é computação em nuvem e qual o impacto que ela terá no conjunto de habilidades atual
1
adolf garlic

Como escrever um programa FizzBuzz.

1
CtrlDot

Quando você precisa distribuir um aplicativo ou colocar um site em produção fora dos limites da sua empresa, tudo o que você pensava não importava.

1
JeffO

O código só é bonito se ele faz o que deveria fazer.

1
sambeau
  • Binário com entendimento básico de assinado e não assinado.
  • Entenda como funciona qualquer sistema numérico posicional.
  • Entenda como estruturas básicas de dados são armazenadas na memória.
1
Michał Piaskowski

A correção do código requer mais inteligência do que escrever o mesmo código inicialmente.

Portanto, se você escrever um código no limite de sua inteligência, não será, por definição, inteligente o suficiente para corrigi-lo quando ele quebrar.

1
Adam Bachman

Escreva suas estruturas de dados primeiro - isso significa tudo, desde esquemas de banco de dados a mecanismos de swizzling/serialização.

A maioria dos projetos trata de armazenamento e movimentação de dados do ponto A ao ponto B no formato C.

Quando tudo estiver dito e feito, cerca de 90% do seu código será lógico para a formatação, mas o verdadeiro assassino está apenas tendo um formato para acessar e gravar seus dados. Depois de ter uma API para acesso a dados, você pode brincar com a formatação da maneira que desejar, mas depois que você inicia a produção com uma API de armazenamento, pode ser difícil perceber que você estragou tudo.

1
user2040

Nas 5 perguntas essenciais da tela do telefone de Steve Yegge, ele tenta garantir que os entrevistados tenham um conhecimento básico de:

  1. Codificação. O candidato precisa escrever um código simples, com sintaxe correta, em C, C++ ou Java.
  2. Design OO. O candidato precisa definir conceitos básicos OO e criar classes para modelar um problema simples.
  3. Script e regexes. O candidato deve descrever como encontrar os números de telefone em 50.000 páginas HTML.
  4. Estruturas de dados. O candidato deve demonstrar conhecimentos básicos das estruturas de dados mais comuns.
  5. Bits e bytes. O candidato deve responder a perguntas simples sobre bits, bytes e números binários.

http://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions

Na época em que ele escreveu isso, ele estava na Amazon, mas trabalha (e provavelmente realiza entrevistas) no Google agora. Isso apenas faz você passar pela tela. Veja como ele descreveu o que estava procurando:

o que estou procurando aqui é um vácuo total em uma dessas áreas. Tudo bem se eles se debatem um pouco e depois descobrem. Tudo bem se eles precisam de algumas dicas ou sugestões. Não me importo se estão enferrujados ou lentos. O que você está procurando é candidatos totalmente ignorantes ou terrivelmente confusos sobre a área em questão.

1
Lou Franco

A documentação é muito importante. Mais ainda, se você estiver construindo algo do zero. Ajuda a documentar suas idéias antes de escrever qualquer código.

Eu aprendi isso da maneira mais difícil.

1
Pablo

Ainda não posso comentar, mas sobre o tópico "Teste e habilidades de depuração", esta pequena joia de Ned Batchelder é uma leitura obrigatória. (Então ganhe, muito do que ele tem a dizer sobre depuração e asserções é digno de consideração.)

0
Stan Rogers

Todo programador deve saber que a única coisa que ele sabe é que ele não sabe nada. Há muito a ser aprendido.

0
sharjeel

Todo programador deve vincular as ações FindNextSelected e FindPreviousSelected (visual studio) às teclas do teclado (de preferência F4 e F2). Você obtém duas coisas disso:

  1. Maneira mais rápida de navegar entre diferentes pontos de uso de variável/função/substring (mais rápido do que com "Localizar todas as referências")
  2. Possibilidade de diferenciar as coisas dentro de um documento. Ao retroceder e avançar enquanto pesquisa em alguma substring, você pode ver as diferenças entre diferentes locais. Não é necessário usar o Winmerge quando for necessário comparar partes do mesmo documento.
0
AareP

Conheça a sintaxe básica da expressão regular, incluindo o agrupamento condicional. Evite usar suplementos de comando regex específicos da biblioteca ou pelo menos comentar/fatorar essas partes.

0
Bob Dobelina

Como fazer isso.

... Como assim, preciso de 15 caracteres?

0
Randall Schulz

Programa com capacidade de manutenção em mente.

0
Jesse

Expressões regulares THE Book about regular expressions

Não sei dizer quantas vezes simples expressões regulares converteram dados que as pessoas pensavam que levariam dias para manipular. Ele deve estar presente em todas as caixas de ferramentas do programador.

Claro, não podemos esquecer o xkcd: Wait, forgot to escape a space. Wheeeeee—taptaptap—eeeeee.

0
neves

Todo programador deve saber como um processador funciona.

0
Brian Makin

Seja Mestre de Algo, mas Seja Ciente de Tudo !!!!

0
user11020

Existem algumas sugestões muito boas aqui, mas estou surpreso que ninguém tenha mencionado a excelente série de artigos de Ulrich Drepper: O que todo programador deve saber sobre memória .

0
Mansur

Todos os problemas em ciência da computação podem ser resolvidos por outro nível de indireção.

0
FreeMemory

Crie seu código e, se seu gerente quiser usar uma abordagem ao estilo RAD, tente obter o máximo de detalhes possível.) Quando mais funcionalidades forem adicionadas, tente pensar se o código existente pode ser reescrito antes apenas empilhando mais código e você acaba com um arranha-céu em vez de uma casa.

0
Luke Tongs

todo programador deve ter uma base sólida em engenharia de software e também conceitos de análise/design de sistemas e sistemas de informação. Dessa forma, se forem chamados a contribuir substancialmente para análise/projeto de sistemas e/ou arquitetura de informação, estarão em uma posição de conhecimento + opção. enquanto normalmente parece ser apenas uma opinião pessoal que geralmente simplesmente deriva de preferências pessoais. da melhor solução de problema. a engenharia de software é um pouco mais difícil de medir, mas o conhecimento pré-requisito está disponível por aí e em cursos de graduação universitários adequados, onde eles ensinam mais do que apenas como juntar um pouco de código. de qualquer maneira, isso não deve ser negativo, porque o espírito principal é apenas melhorar, mas então eu trabalhei com algumas pessoas que não têm nenhum conhecimento de TI ou há os "script kiddies" de mente única que codificam e recodificam (e somente em sua linguagem de escolha) e só vê todos os problemas como uma repetição de soluções aplicadas anteriormente (por esse codificador.), então eu preferiria muito que os programadores se concentrassem mais no cenário geral em termos de engenharia de software (SSADM) e considerassem os problemas como oportunidades. fazer melhor para o cliente.

0
chris

Execute o código ou a lógica em sua cabeça ou papel primeiro. Não se apresse para acertar o compilar e executar o comando para testá-lo.

0
Aditya Kothadiya

Está em algumas letras, realmente:

Ok, estou simplificando demais, mas basicamente se você é bastante autodidata, nunca para para aprender e é um pouco perfeccionista, deve ter a base para se tornar um bom programador.

Qualquer coisa além disso seria mais específica para papéis e tecnologias específicos.

0
haylem

Se algo pode dar errado, então isso acontecerá. Suponha o pior caso

0
Adham Saad

Não se esqueça da pessoa que vai usar o software que você está criando.

0
Dan Goldstein

Reconheça que tudo o que pode dar errado vai dar errado. Gaste muito pouco tempo escrevendo código - mas reconheça e reutilize padrões comuns. Refatorar o código constantemente para alcançar o design ideal.

0
zkarthik

Todos os dados precisam morar em algum lugar. Você pode encontrá-lo se procurar bastante.

0
Jonathan

Eles precisam saber sobre o poder dos fechamentos e começar a usá-los.

0
nickik

Notação hexadecimal. Também campos de bits - ANDing, ORing (inclusivo e exclusivo), complementando (1 e 2), deslocamento de bits.

0
tcrosley

Meu primeiro voto seria nas Convenções de Nomenclatura.

0
Gopi

Quando alguém lhe pede para construir algo, lembre-se: eles também estão pedindo para você mantê-lo. Possivelmente para sempre.

0
Yevgeniy Brikman

O que quer que programas façam, mais do que dizer a uma máquina como fazer um trabalho, eles são a maneira mais inequívoca de mostrar aos outros seres humanos como fazer um trabalho.

0
vpit3833