Respostas:
Sempre existe uma maneira melhor de escrever seu código.
Não importa o quão excelente você encontre o código que escreve, você ficará surpreso com o quão ruim é se você o revisar em alguns anos. Só porque alguns anos antes, você desconhecia alguns padrões que conhece hoje, ou alguns recursos de linguagem que aprendeu enquanto isso etc.
Pense antes de começar a codificar.
Não há nada mais permanente do que soluções temporárias :)
Se for muito difícil resolver um problema, provavelmente o problema em si está mal colocado desde o início.
Seu software terá uma vida útil consideravelmente maior do que você imagina no momento em que o escreve.
Comecei minha carreira nos anos 80. Comecei com um software que se originou nos anos 70 e ainda estava sendo usado nos anos 90 (talvez mais, não sei ao certo seu destino). Parte do meu próprio código-fonte aberto está na metade de sua segunda década.
Trabalhar bem com os outros é muito importante.
"Mostre-me o seu 'Go to guy' e eu mostrarei o seu problema"
Os codificadores de heróis Slapdash - aqueles que simplesmente desenvolvem códigos sem levar em consideração convenções, legibilidade ou qualquer outra pessoa que esteja trabalhando - podem causar mais mal do que bem.
Não estou dizendo que as pessoas que podem escrever toneladas de código de boa qualidade são coisas ruins. Apenas raro.
Aprender novos idiomas faz parte do trabalho
Eu aprendi sobre quatro linguagens de programação na escola nos anos 80, mas usei uma delas em um emprego. Eu tive quatro empregos em que nem sabia o idioma que fui contratado para usar.
No geral, aprendi e usei profissionalmente talvez uma dúzia de idiomas em minha carreira, incluindo FORTRAN, c, c ++, c #, java, perl, Tcl, ruby, groovy, awk, python, sh, lote, DCL, javascript e um alguns pequenos DSLs. Fazendo um pouco de matemática, pareço calcular a média de um novo idioma a cada dois anos, embora exista muita sobreposição.
Se alguma coisa tem sido uma constante na minha carreira, é mudança.
Continue estudando todos os dias. O conhecimento de hoje é obsoleto amanhã.
Ironicamente, essa resposta também deve ser obsoleta amanhã. Mas, realmente, estude um ou dois itens e seja certificado, se possível, seja o Deus dessas coisas (talvez linguagens de programação ou administração de sistema / rede / banco de dados) e sempre fique de olho em outras coisas menores, como outras linguagens sem importância. vocês.
Quero dizer, por exemplo, ser um profissional incrível em administração de Java e Oracle DB, mas estude um pouco de Python, PHP, C ++, HTML5, Javascript, embora não no nível de certificação. Estude cada estrutura da web ou linguagem que exista. Estude ou tente ter alguma experiência (básica) com cada banco de dados existente, como SQL Server, MySQL, Cassandra, HBase, PostgreSQL e todo o mundo sem SQL, como MongoDB e CouchDB. Tente ter alguma experiência com administração e virtualização do linux.
Essa é a maior lição que aprendi nos meus 16 anos de experiência. Eu fui por quase 10 anos um programador em linguagem mono, usando Pascal em sua época, e Visual Basic 6 no início do milênio, e desenvolvedor de PHP desde 9 anos atrás. Mas a partir daí eu aprendi que os desenvolvedores precisam saber pelo menos um pouco de tudo.
Aprendi que o melhor princípio de design é o KISS (seja simples, estúpido!) .
Aprendi que manter o seu código simples e limpo deve ser a principal preocupação e cada membro da equipe deve entender o que você tem. The KISS principledeclara que a maioria dos sistemas funciona melhor se mantidos simples e não complexos, portanto, a simplicidade deve ser um objetivo fundamental no design e a complexidade desnecessária deve ser evitada.
Não há tentativa
Digamos que você tenha uma tarefa ou várias tarefas estimadas em 4 dias. Em seguida, seu chefe ou gerente de projeto pergunta se você pode tentar fazê-lo em dois dias por algum motivo importante. Querendo ser um funcionário bom e flexível, você pode ficar tentado a dizer: com certeza, você pode tentar. Os resultados mais prováveis disso são que você perde o prazo final ou faz um hack de meia-boca para fazê-lo. E não é culpa do seu chefe pedir que você faça isso, esse é o trabalho dele. A culpa é sua por não dizer não, que é o seu trabalho.
Você não pode negociar com o tempo. Você pode negociar com escopo. Seja profissional e não se venda a descoberto.
"Isso nunca acontecerá" significa realmente "Isso nunca acontecerá até o primeiro dia de produção"
Escrever código é fácil. Ler código é difícil. Mesmo se o código for seu. Portanto, sempre que possível, escolha uma abordagem legível.
Você não é mais esperto que os outros. Nunca pense que sua abordagem é a melhor apenas porque é sua.
Preste atenção ao que é dito, não por quem é dito. Idéias brilhantes podem vir para as fontes mais inesperadas.
Não seja preguiçoso. Tome seu tempo para escrever um bom código. Você precisará corrigi-lo de qualquer maneira a um custo mais alto.
Não use recursos sofisticados de OOP apenas porque você pode! - YAGNI (Você não vai precisar)
Use fancy OOP featuresporque eles têm benefícios específicos e demonstráveis para o problema que você está tentando resolver . Você ri, mas eu vejo isso o tempo todo. A maioria dos programadores nunca encontrou um objeto que não gostasse. Eu acho que deveria ser o contrário: essas técnicas são culpadas até que se prove inocente no tribunal do KISS .