Ruud Van Nistelrooy, o artilheiro da primeira década do século 21

O holandês Ruud van Nistelrooy é o melhor marcador internacional da primeira década do século 21, para a Federação da História e Estatísticas do futebol (IFFHS).


A IFFHS teve em conta os golos marcados nas seleções ou nos clubes, incluindo jogos dos "AA", Jogos Olímpicos, Mundiais, competições de clubes e supertaças das seis confederações e jogos oficiais entre campeões continentais.


Entre 2001 e 2010, Van Nistelrooy totalizou 86 golos, 33 dos quais pela seleção holandesa e 53 nos clubes, seguido do francês Thierry Henry, com 85 (43/42) e do costa-marfinense Didier Drogba, com 83 (45/38).


O avançado português Pedro Pauleta, já retirado dos relvados, surge no 21.º lugar, com 55 golos marcados, 42 pela seleção portuguesa e 13 por Bordéus e Paris Saint Germain, os clubes pelos quais passou ao longo da década.


Cristiano Ronaldo, o mais mediático jogador português, é 26.º, com 54 golos.


O futebolista, actualmente no Real Madrid, tem, no período de 2001/2010, 26 golos na seleção portuguesa e 28 em jogos internacionais, pelo Manchester United e os merengues.


Destaque ainda para a presença no "top 10" do avançado internacional angolano Flávio Amado, que ocupa o sexto lugar, com 73 golos, 32 pela seleção e 41 pelos clubes, vários pelo Al-Ahly, no qual foi treinado por Manuel José.


Classificação:


1. "Ruud" Van Nistelrooy (Holanda), Manchester United/Real Madrid/Hamburgo, 86 golos (33 seleção/53 clubes)
2. Thierry Henry (França), Arsenal/Barcelona, 85 (43/42)
3. Didier Drogba (Costa do Marfim), Marselha/Chelsea, 83 (45/38)
4. Miroslav Klose (Alemanha), Kaiserslautern/Werder Bremen/Bayern Munique, 81 (58/23)
5. Samuel Eto'o (Camarões), Maiorca/Barcelona/Inter Milão, 79 (44/35)
6. Flávio (Angola), Atlético Luanda/Al-Ahly/Al-Shabab, 73 (32/41)
7. Dimitar Berbatov (Bulgária), Bayer Leverkusen/Tottenham/Manchester United, 71 (46/25)
8. Raul (Espanha), Real Madrid/Schalke 04, 71 (26/45)
9. David Villa (Espanha), Saragoça/Valência/Barcelona), 68 (44/24)
10. Andrei Shevchenko (Ucrânia), Milan/Chelsea/Dínamo Kiev, 68 (32/36)
(...)


21. Pedro Pauleta (Portugal), Bordéus/PSG, 55 (42/13)
26. Cristiano Ronaldo (Portugal), Manchester United/Real Madrid, 54 (26/28)

Marca de Amor

Um menino tinha uma cicatriz no rosto, as pessoas do seu colégio não falavam com ele, e nem sentavam-se ao seu lado, na realidade quando os colegas o viam, franziam a testa devido à cicatriz ser muito feia.


Então a turma se reuniu com o professor, e foi sugerido que aquele menino da cicatriz não frequentasse mais o colégio, o professor levou o caso à directoria do colégio.
A directoria ouviu e chegou à seguinte conclusão: Que não poderia tirar o menino do colégio,  e que conversaria com o menino e ele seria o ultimo a entrar em sala de aula, e o primeiro a sair, desta forma nenhum aluno via o rosto do menino, a não ser que olhassem para trás.
O professor achou magnífica a ideia da directoria, sabia que os alunos não olhariam mais para trás.


Levado ao conhecimento do menino da decisão ele prontamente aceitou a imposição do colégio, com uma condição: Que ele compareceria na frente dos alunos em sala de aula, para dizer o por quê daquela CICATRIZ.


A turma concordou, e no dia o menino entrou em sala dirigiu-se a frente da sala de aula e começou a relatar:
- Sabe turma eu entendo vocês, na realidade esta cicatriz é muito feia, mas foi assim que eu a adquiri:
- Minha mãe era muito pobre e para ajudar na alimentação de casa minha mãe passava roupa para fora, eu tinha por volta de 7 a 8 anos de idade...


A turma estava em silencio atenta a tudo .


O menino continuou: além de mim, haviam mais 3 irmãozinhos, um de 4 anos, outro de 2 anos e uma irmãzinha com apenas alguns dias de vida.


Silêncio total em sala.


-... Foi aí que não sei como, a nossa casa que era muito simples, feita de madeira começou a pegar fogo, minha mãe correu até o quarto em que estávamos pegou meu irmãozinho de 2 anos no colo, eu e meu outro irmão pelas mãos e nos levou para fora, havia muita fumaça, as paredes que eram de madeira, pegavam fogo e estava muito quente... 
Minha mãe colocou-me sentado no chão do lado de fora e disse-me para ficar com eles até ela voltar, 
pois minha mãe tinha que voltar para pegar minha irmãzinha que continuava lá dentro da casa em chama. 
Só que quando minha mãe tentou entrar na  casa em chamas as pessoas que estavam ali, não deixaram minha mãe buscar minha irmãzinha, eu via minha mãe gritar:
- " Minha filhinha está lá dentro!" 
Vi no rosto de minha mãe o desespero, o horror e ela gritava, mas aquelas pessoas não deixaram minha mãe buscar minha irmãzinha...
Foi aí que decidi. 
Peguei meu irmão de 2 anos que estava em meu colo e o coloquei no colo do meu irmãozinho de 4 anos e disse-lhe que não saísse dali até eu voltar.
Saí de entre as pessoas, sem ser notado e quando perceberam eu já tinha entrado na casa. Havia muita fumaça, estava muito quente, mas eu tinha que pegar minha irmãzinha. Eu sabia o quarto em que ela estava. 
Quando cheguei lá ela estava enrolada em um lençol e chorava muito...Neste momento vi caindo alguma coisa, então me joguei em cima dela para protegê-la, e aquela coisa quente encostou-se em meu rosto...
A turma estava quieta atenta ao menino e envergonhada então o menino continuou: 
Vocês podem achar esta CICATRIZ feia, mas tem alguém lá em casa que acha linda e todo dia quando chego em casa, ela, a minha irmãzinha me beija porque sabe que é marca de AMOR.


Vários alunos choravam, sem saberem o que dizerem ou fazerem, mas o menino foi para o fundo da classe e imovelmente sentou-se.

Humor - O presidiário e o casal apaixonado

Um presidiário, condenado a prisão perpétua por assassínio em primeiro grau, consegue fugir da prisão ao fim de 25 anos. Ao fugir, entra numa casa onde dorme um jovem casal. O assassino amarra o homem a uma cadeira e a mulher à cama. A seguir, encosta o seu rosto ao peito da mulher, levantando-se de seguida, e saindo a seguir do quarto. Imediatamente, arrastando a cadeira, o marido aproxima-se da esposa e diz-lhe:


- Meu amor, este homem não vê uma mulher há anos. Eu vi-o beijando-te o peito, e aproveitando ele ter-se afastado um pouco, quero pedir-te que cooperes com ele, e faças tudo o que ele te pedir. Se ele quiser fazer sexo contigo não o evites, e finge que gostas. Por favor, não o afastes. As nossas vidas dependem disso!!! Sê forte, minha linda, eu amo-te.


A jovem esposa diz ao marido:
- Querido, estou-te reconhecida por pensares assim!!! Efectivamente este homem não vê uma mulher há anos. No entanto ele não estava a beijar-me o peito. Estava a dizer-me ao ouvido que gostou muito de ti, e perguntou-me se guarda-mos a vaselina na casa de banho. Sê forte, meu lindo, eu também te amo muito.


Moral da história: Não estar verdadeiramente informado pode trazer sérios inconvenientes. A informação actualizada, e exacta é fundamental para ter êxitos, e assim evitar surpresas desagradáveis...

Humor - Namorado surdo

Ia uma jovem muito linda,  a passear com o seu namorado, quando ouviram uns trabalhadores de uma obra a gritarem:


- Oh cabrão, não a leves a passear, leva-a mas é para um beco ou lugar escuro e come a gaja!!!


O rapaz, muito envergonhado, segue o seu caminho com a sua namorada, e passam por um parque, onde estão vários idosos, que ao vê-los começam às bocas ao namorado:


- Olha, olha, de mãozinha dada com a miúda... Devias é levá-la para um motel, ó paneleiro!!!


O rapaz, cada vez mais envergonhado, decidiu levar a namorada a casa, e despede-se:


- Então até amanhã, meu amor!


A namorada responde-lhe: 
- Até amanhã, seu surdo de merda!!!


Moral da história: Escuta, e põe em prática os conselhos dos outros. São pessoas com experiências. Se não o fizeres, a tua imagem será...rsrsrsrsrss

Como escrever códigos mais eficientes

Como em qualquer tipo de empreendimento o difícil está sempre nos detalhes. É como diz o velho ditado: "O Diabo está no detalhe".

Um código pode parecer óptimo no papel, mas se não for implementado com extrema atenção aos detalhes, usando técnicas de programação sólidas e com uma pitada de arte, ele de certo, será um fracasso. Ele provavelmente vai cumprir a lista de tarefas, mas não vai ser atraente, intuitivo ou prático. 

A parte mais importante de se implementar um programa, não é fazer as coisas funcionarem, é não deixa-las estragarem. 

Discute-se muito tratamento de erros, como captura-los, como manuseá-los, etc... Estas coisas se fixam no que fazer depois do leite derramado, ou seja, depois do erro ocorrer. Elas são importantes para o sucesso do seu programa, mas não se comparam a prevenção de erros, esta sim deve ser enfatizada. 

Prevenção de erros deve ser o prato principal do projecto e não uma simples sobremesa. Este post foca algumas técnicas de prevenção de erros, vulgarmente conhecida por validação,  e outros assuntos ligados ao desenvolvimento de software. 

Clareza: Cada função ou procedimento deve ter um, e somente um, propósito claro. Este propósito deve ser comunicado no primeiro comentário. Assim como cada bloco comentado de código numa rotina deve ter só um claro propósito. 

O mesmo se aplica a variáveis. Cada uma deve ter um só propósito. Variáveis multiusos devem ser reduzidas ao mínimo, e claramente identificadas como tal. 

Seguindo esta regra geral a clareza do código vai ser melhorada e este vai ficar mais robusto e fácil de manter. 

Escopo: Sempre considere o escopo. Suas variáveis são locais, ou globais? Suas classes são públicas ou privadas? 

Geralmente o escopo deve ser o mais restrito possível. Na dúvida, comece declarando a variável como local. Se ela for necessária a outras rotinas do formulário mude seu escopo para modular (válida somente no módulo ou formulário em que foi declarada). Por fim se for necessária em outros módulos faça-a Global. Não se esqueça de mudar seu nome para que este reflita sua nova abrangência. 

Mais uma vez, faça todo o possível para manter as variáveis locais. Modulares ou globais só devem ser declaradas se absolutamente necessárias. Passando variáveis como parâmetros de funções ou procedimentos (Subs) e criando propriedades num módulo de classe são alternativas muito mais recicláveis e fáceis de mudar quando necessário. 

Quanto a funções, mantenha-as privadas a não ser que tenham que ser públicas. Não exponha nenhuma função ao usuário sem ter certeza absoluta que todo o código de prevenção de erros está no lugar e funcionando. Não exponha ao usuário funções internas as quais ele não necessita. 

Tente não usar constantes públicas desnecessárias. Embora sejam de grande valia elas fazem com que um módulo seja menos auto suficiente e reciclável. 

Identificadores: Um nome apropriado consiste de um prefixo, normalmente 3 letras, para indicar o tipo, seguido de uma descrição da sua função no todo. Por exemplo, uma nova TextField, ela deve ter o  nome imediatamente mudado para algo como txtNomeDoUsuario. Isto indica que se trata de uma TextField, que recebe o nome do usuário. 

Sempre use os prefixos padrão para que outros que venham a usar o seu código entendam com mais facilidade. Abaixo está uma lista com alguns tipos padrão que uso: 

txt - TextField

lbl - Label

cmb - ComboBox

chk - CheckBox

opt - OptionButton

img - Image

pic - Picture

vsc - Vertical ScrollBar

hsc - Horizontal ScrollBar

tmr - Timer

Arcana: Sempre use o mais simples, directo e legível código possível. As duas linhas abaixo fazem a mesma coisa:

1. bool função Existe(x, lista)

 parm tipoitem x;

          tipolista lista;

{

 int i;

 para i de lista.primeiro ate lista.ultimo

 faca se lista.item[i] = x

         entao retorna verdadeiro;

         senao retorna falso;

}

2. bool função Existe(x, lista)

 parm tipoitem x;

          tipolista lista;

{

 int i;

 para i de lista.primeiro ate lista.ultimo

 retorna lista.item[i]=x

}

A linha 1 é muito mais legível do ponto de vista humano. A 2 é mais complicada e demora mais tempo para a maioria dos programadores entender. É verdade que a linha 2 é mais compacta e avançada, mas clareza deve estar sempre em primeiro lugar.

Comentários: Porquê comentar o meu código? Fui eu que escrevi, daí não preciso de lembrete. De qualquer maneira um código fonte coeso é sempre auto explicativo e evidente. Comentar meu código seria dizer em voz alta que ele não é bom. Além disso, qualquer programador que reclamar que não consegue entender o meu código por falta de comentários é um "Besta Lógica" (Engº. Manuel Meneses) que não sabe de nada. Eu não tenho  e não perco tempo de comenta-lo.

Estas são algumas reacções naturais alguns programadores têm sobre comentários. Comentários são parte essencial de um código coeso e reciclável. O que parece óbvio num dia fica totalmente obscuro em outro. Se o programa é um sucesso, outros programadores vão, eventualmente, continua-lo. Algumas partes do código não serão óbvias a eles, não interessa quanta experiência eles tenham. 

O equilíbrio é o segredo. Alguns programadores não põem comentários, outros põem comentários inúteis ou óbvios, outros ainda põe comentários demais. Estes últimos podem, as vezes, causar mais danos do que aqueles que nem comentam. Este tipo de código é cheio de comentários redundantes, decoração e linhas em branco que não acrescentam nada. 

'===============================

'"""""""""  COMENTÁRIO  """"""""

'===============================

O bloco acima pode ser um "neon" para chamar a atenção a um comentário, mas ele atrapalha. Ele gasta muito espaço na tela e acaba por fazer o código mais difícil de se ler. Comentários devem aparecer para comunicar informação que NÃO é óbvia. Eles não devem interferir com a legibilidade do código, mas devem ser fáceis de achar se o programador os procura. Eles não devem usar mais espaço que o necessário. Como regra geral, olhe para sua tela de código. Se você só vê comentários algo está errado, se você só vê código as chances são que você não está sabendo antecipar adequadamente o que outro programador (ou você mesmo) pode precisar saber no futuro. 

Longo Prazo: Muitos programas tiveram de ser completamente dilacerados ou até reescrito, quando passados a um novo cliente ou vendidos a uma companhia. O porquê? O programador não pensou a longo prazo. 

Quando programamos, a ênfase é basicamente em fazer o programa funcionar. Como se o EXE fosse a única coisa que conta. Assim pensamos em curto prazo. Nós assumimos que enquanto entendermos o código tudo bem. 

É bem mais importante pensar a longo prazo. O EXE não importa muito realmente, mas o código sim. Não deve ser suficiente que entendamos o código, mas que outros também possam entende-lo. Nós entregaremos e eles o pegarão e o modificarão com facilidade. 

Pensar a longo prazo significa fazer comentários que vão ajudar outros, mesmo que voce não precise deles (os comentários). Significa usar convenções padrão para nomes mesmo que prefiramos nossa própria maneira de nomear componentes. Significa declarar tudo explicitamente mesmo quando você conhece os defaults. Significa usar código simples e facilmente legível mesmo sendo capaz dos mais variados truques. Significa escrever nosso código, a pensar, e para os outros. 

Moral da história: A moral da história aqui é que um programa que é legível, mas não funciona direito, é bem melhor do que um que funciona, mas ninguém consegue entendê-lo. O primeiro programa pode ser consertado, mas o segundo, certamente terá que ser reescrito.

Debugging Post.1

Debugging é um execício de investigação. Raciocínio dedutivo, observação cuidadosa, lógica abstrata, perseverança e auto-questionamento são todos essenciais. 

Em qualquer projecto de programação, debugging é inevitável. Mesmo um bug simples pode consumir horas, e até mesmo dias de trabalho. É claro que o objectivo é produzir código de maneira a prevenir bugs. O problema é que, muitas vezes, não podemos prevenir bugs até conhece-los. E nós normalmente não os conhecemos até encontra-los e extermina-los pelo menos uma vez.

Talento é essencial no desenvolvimento de um aplicativo, mas é aqui que a experiência compensa, pois o programador experiente não é pego pelo mesmo bug 2 vezes.

Outra parte importante em escrever código de qualidade é mante-lo robusto. Quando mudanças são feitas no código ele não pode parar ou gerar novos bugs. Se o programa não é fácil de manter então estará destinado a uma vida útil muito curta.

Por exemplo: Quando escrevemos funções ou procedimentos em VB, é mais seguro passar parâmetros por valor (ByVal) do que por referência (ByRef) que é o default. Isto assegura que a função não tem como modificar o valor da variável que é passada como parâmetro.

Note que como ByRef é o padrão é uma boa prática adicionar a palavra ByVal a cada novo parâmetro.

ByRef só deve ser usado se você tiver um propósito específico. Uma razão para usa-lo é a função retornar um parâmetro modificado, outra é um pequeno ganho em performance que o ByRef oferece. Entretanto na maioria dos casos o pequeno ganho em rendimento não justifica o risco acarretado pelo uso do ByRef.

Se você usar ByRef o propósito deve ser indicado num comentário.

Os melhores programadores vão "debugando" a medida que programam. Eles não dão um novo passo até que qualquer erro possível de ser antecipado e tratado assim o seja. Quando o programa chega na data limite, este programador pode não estar com todas as rotinas no lugar, mas as que estão funcionam perfeitamente. Isto é preferível a um programa completo que "deixa de responder" quando é executado.

Na arte de achar erros nunca assuma nada. Esta é uma óptima razão para ser sempre explícito.

Sempre use Option Explicit em cada módulo de VB para ter certeza que o programa só rodará se todas as variáveis tiverem sido declaradas. 

Sempre inicialize variáveis e arrays. Nunca confie em valores default. 

Sempre especifique ByVal ou ByRef 

Sempre dimensione ou redimensione arrays explicitamente, indicando o índices do primeiro e do último elemento. 

Estas práticas protegem contra mal entendidos, contra mudanças na linguagem de programação e fazem o código mais legível, auto-suficiente e sem ambiguidade.

Enquanto é importante ter uma resposta rápida em caso de incêndio, é mais importante ter uma prevenção ainda melhor.

No geral, a maior parte da sua atenção enquanto programador deve ser gasta, não criando novas funcionalidades ou tratando erros depois deles terem acontecidos, mas prevenindo-os de acontecer.

Em qualquer ponto do programa onde o usuário pode fazer uma entrada, um erro pode acontecer, quer seja na hora ou um pouco depois. Ao invés de focar em como trata-los tente sempre preveni-los de acontecer.

A prevenção de erros deve acontecer o quanto antes. Por exemplo, uma TextField para a entrada de IDADE. As seguintes regras devem ser implementadas assim que o controle for criado e ter sua função definida (no caso, a entrada de IDADE):

 -Definir a propriedade MaxLength em 2. 

-Filtrar qualquer caracter alfanumérico no evento KeyPress.

-Verificar se exactos 2 caracteres foram digitados no evento LostFocus. 

Em cada um destes tópicos nós estamos prevenindo erros de acontecerem. É claro que nós não podemos prever todos os erros possíveis de acontecer, por isso além da prevenção devemos também nos preocupar com o tratamento depois do erro ter acontecido.

Depois de escrever o código de prevenção de erros e implementa-lo, você deve passar para a parte de captura e tratamento. As vezes é impossível controlar a entrada de dados ou eventos externos que podem fazer com que partes de seu código falhem ao executar. Pegue como exemplo a abertura de um arquivo externo. Você já tomou o cuidado de verificar se o arquivo escolhido existe e está onde deve mas ainda assim você pode incorrer num erro se ele estiver corrupto.

Como ser um bom programador

NOTA: Esta mensagem visa aconselhar o programador na sua conduta e metodologia, e não no conhecimento técnico inerente a profissão. Não faça deste texto um guia, são apenas alguns conselhos para o lado prático do desenvolvimento. Este texto foi escrito com a melhor das intenções, e baseia-se na minha pouca experiência pessoal na área. 

 1 - Tenha Calma: Se você não conseguir de primeira, não é motivo para desistir já, e ir correr procurar ajuda. Se você não perseverar, o lado negro da força dominará você e a mediocridade eterna será a sua recompensa profissional. Programação exige, entre outras coisas, muita perseverança. Tenha fé, acredite sempre em ti, por vezes sabes a resposta, ou seja, por vezes o teu cérebro não consegue processar aquilo que os teus olhos vêem.

2 - Tente Entender: Se a dúvida é sua, assuma a responsabilidade, tente entender a resposta que te foi dada exaustivamente antes de descartá-la. Muitas vezes ela está certa, e o seu conhecimento ou empenho é que não não foram suficientes. Faça o mesmo antes de aceitá-la 

 3 - O Passo Maior que a Perna: Se você não se garante em alguma coisa é porque ainda falta para você chegar lá. Tente começar pelo inicio. De que adianta você fazer um programa usando código que te foi passado, ou copiaste de algum lado, e você não entende como ele funciona? O bom programador é aquele que tem uma boa base, que conhece e domina o básico da linguagem e cultiva uma boa lógica, o resto vem com o tempo e a necessidade. 

4 - Seja Humilde: A humildade é um factor crucial em qualquer profissão. Cultive-a, ela pode te ensinar muito, tanto no trabalho como na vida. Cultive-a pelo prazer de ser verdadeiro nas suas acções e honesto na sua profissão. 

5 - Seja Independente: Não fique esperando a ajuda de todos para realizar o que você quer. A tarefa tem que ser a sua principal motivação. Além do mais cada vez que alguém te entrega uma solução "mastigada" você deixa de aprender com o processo. 

6 - Nada é Complicado: Uma coisa complicada nada mais é do que o encadeamento de varias coisas simples. O erro é tentar resolver o problema inteiro com o estigma de acha-lo complicado na cabeça. Ao invés, divida o problema em pedaços menores e mais simples (rsrsrs hehehe,  capitulo 7 do manual de Técnicas de Programação, Divisão e Conquista) e resolva-os ou divida de novo até ficar simples o suficiente. Feito isso o que restar já não será tão complicado. Note que isso não quer dizer que você irá resolver qualquer problema de agora em diante, mas já da uma perspectiva bem melhor. Tome este conselho como uma maneira de ver as coisas, nada mais. 

7 - Não Abuse: Sua dúvida é primariamente problema seu. Os seus colegas, professores, amigos, etc... não estão aqui somente para ajuda-lo, portanto se você realmente preza a ajuda que recebe, contente-se com ela. Lembre-se que todos tem mais o que fazer do que ficar atendendo "caprichos" dos outros. Sua prova de apreciação é sempre bem vinda. 

8 - A César o que é de César: Dê crédito, se você usou código de alguém e esse código ajudou para o desenvolvimento do seu software, mencione esta pessoa nos seus créditos, afinal de contas ela trabalhou bastante para que você não precisasse, e nem está te cobrando. Depois, qual é a graça de dizer ter feito algo quando você não fez?

9 - Bom Senso é Tudo! : Sem bom senso você está perdido, pode considerar isso a pura verdade. Diante de uma situação complexa e aparentemente sem saída, pare, relaxe e use o seu bom senso, escute os seus neurônios. Lembre-se que mesmo depois de ter seguido este conselho e o problema continuar lá não quer dizer que ele é insolúvel. 

10 - Nada é Impossível: Embora algumas coisas parecem!. Imagine, existe programadores (e não só) criando jogos, portanto,  se aquilo é possível, sua tarefa também deve ser. O importante é perseverar e manter uma atitude positiva diante da tarefa, não encare a tarefa como inimiga e sim como uma amiga que não fala a sua "língua". 

11 - Nunca Pare de Aprender: Se um dia você se cansar de aprender novas tecnologias em desenvolvimento, siga meu conselho: Mude de curso, ouvi dizer que em Economia têm vaga. É como diz o meu professor de Programação: "Não existe uma lei que obriga todo mundo a ser Engenheiro, se não está a dar, meu caro, desista, abre uma janela aberta o quê, epá, a vida é durra!".

12 - Tenha Curiosidade: Procure, pesquise e corra atrás. Isso ensina mais. A máquina é o computador e não você, portanto não se torne um autômato que apenas faz o necessário e apenas sabe o suficiente. 

13 - Tenha Criatividade: Muitas vezes é o que distingue o "bom" programador do "medíocre". Programação não é somente uma técnica, é também uma arte. Sem criatividade você está a mercê da mesmice num mundo cada vez mais dinâmico e variado. Infelizmente criatividade não pode ser ensinada, tem que ser aprendida na prática. 

14 -  Faça Bem Feito: Seja detalhista e capriche em tudo até que isso fique automático em você, essa atitude lhe renderá um diferencial importante nesta nossa profissão.

15 - Seja Simples: A simplicidade é mágica e as pessoas de hoje tendem a complicar, portanto mantenha-se simples. Se existirem 3 possíveis soluções para um problema, tente a mais simples, é geralmente a mais eficaz. 

16 - Não Tenha Pressa: O aprendizado é uma estrada longa e cheia de obstáculos, que começa no primeiro passo e termina quando você a abandona. Aprenda a não ter pressa, de que adianta entregar no prazo, se está mal feito. O velho ditado vale: "A pressa é inimiga da perfeição".