O tempo voa, certo?

Minha carreira começou em 2012, com o primeiro estágio em C ++. Honestamente, eu não tinha ideia do que estava fazendo (na verdade, nada mudou). No entanto, eu aprendi algumas lições.

Isenção de responsabilidade: Não haverá código nesta mensagem.

Pergunta: Qual é a linguagem mais importante na programação?

Isso é inglês Ou espanhol, chinês, polonês. Qualquer pessoa que você usa para se comunicar com colegas.

Conversar com as pessoas é muito mais importante do que conversar com carros.

A programação é um esporte de equipe. Raramente existe um produto brilhante criado do zero por uma pessoa (o CodeSandbox é um ótimo exemplo, embora Ives tenha contratado recentemente alguns funcionários), mas na maioria dos casos é necessária uma equipe.

As habilidades de comunicação podem salvar ou enterrar um projeto. Não se preocupe, o problema não é só seu, até a NASA sofre por causa disso .

As habilidades profissionais e de comunicação podem ser mais importantes para o sucesso do projeto do que as puramente técnicas. Quem se importa que você tenha contratado os cinco melhores especialistas em banco de dados do mundo, se eles se recusarem a conversar, e você terá cinco instâncias diferentes do MySQL, Aurora e MongoDB.

Você precisa entender profundamente o que está desenvolvendo e por que

A maioria das pessoas fica mais feliz quando tem um objetivo. Isso também se aplica ao trabalho.

Seu objetivo como desenvolvedor não é traduzir o JIRA para JavaScript, Trello para C #, etc. Seu objetivo é resolver problemas .

Se você tem um entendimento profundo do sistema que está construindo / mantendo, poderá tomar decisões fora da tecnologia pura. Faça perguntas: esse recurso é necessário? Que problema ele resolve? Podemos resolver esse problema de maneira diferente? Queremos resolver esse problema em primeiro lugar?

Às vezes, esse pensamento é chamado de contexto de negócios, mas se você deseja fazer bem o seu trabalho, precisa entender não apenas o contexto, mas ser capaz de moldá-lo e influenciá-lo. Para influenciar um produto, não é necessário ocupar uma posição gerencial em uma organização. No mínimo, isso não é necessário para entender o produto.

Se uma revisão de código é estressante, é organizada de maneira terrível e incorreta.

Oh deus Verificação de código.

Realmente não pensamos nisso, mas o ato de publicar o trabalho com o estudo de várias outras pessoas é um pouco exclusivo da nossa profissão. Não é de admirar que isso cause estresse.

Eu pessoalmente vi pessoas enviando uma revisão de código especificamente em um momento em que X não estava no escritório ou Y estava em uma viagem de negócios. X é um programador brilhante, mas difícil de sustentar sua revisão de código. Centenas de comentários exigentes sob a solicitação de pool júnior não comprovam sua superioridade como desenvolvedor. Isso prova apenas a sua natureza ruim.

OK, mas o que devo fazer quando esta função estiver completamente quebrada?

Levante-se. Entre em contato com essa pessoa, converse pessoalmente . Fale com ele, descubra por que ele implementou o código dessa maneira.

A maioria das pessoas não deseja escrever código incorreto. E se o fizerem, provavelmente estão lidando com restrições das quais você não está ciente. Eles também podem não ser muito bons em programação (ainda), e aqui você pode se provar um mentor.

Algo DEVE dar errado, prepare-se

De acordo com a Wikipedia:

A Lei de Murphy é um provérbio ou epigrama que costuma ler: "Tudo o que pode dar errado vai dar errado".

Essa é uma daquelas coisas que são verdadeiras demais . Ao projetar um sistema, sempre assuma algum tipo de falha.

Se você estiver criando um formulário de login, presuma que as pessoas copiem e colem o texto do livro inteiro no campo de senha.

Se você criar uma janela WYSIWYG, suponha que alguém tente quebrá-la e provavelmente poderá fazê-lo.

Se você tiver um banco de dados, ele será desconectado em algum momento. Se você não testou a restauração de um banco de dados a partir de um backup, este não é um backup.

Se você estiver preparando uma demonstração na frente de uma platéia, verifique se a demonstração funciona on-line, off-line, de cabeça para baixo e debaixo d'água.

Não tenha medo de dizer "eu não sei"

O privilégio mais agradável do título "Sênior" no crachá é, finalmente , a oportunidade de responder:

Não sei, nunca tentei. Vou olhar e ligar de volta.

Sendo júnior, fiquei com muito medo: de repente, alguém imaginaria que eu era um impostor. Depois de alguns anos como desenvolvedor - se eu não vi algo, talvez ainda não tenha surgido. Ou apareceu outra tecnologia interessante que precisa ser explorada. A aprendizagem ao longo da vida não é um chavão, é uma realidade em TI.

Ou sou apenas um golpista incrível que conseguiu enganar a todos que eu realmente posso fazer o meu trabalho. Você nunca sabe.

Aprenda em público

Assim que você alternar de "não sei" para "Bem, isso foi interessante" - compartilhe com alguém. Escreva um blog, grave um vídeo, converse em um evento de compartilhamento de conhecimento ou apenas ... conte a alguém. Se você acha que algo é óbvio para todos, não é assim. Até os melhores profissionais têm algo a aprender com iniciantes e vice-versa.

Ensinar é uma maneira incrivelmente eficaz de garantir que você realmente entenda o assunto em questão.

Como alguém malditamente inteligente disse:

Quando alguém ensina, dois aprendem.

Que lições você aprendeu como desenvolvedor?