Eu escolhi originalmente o design porque queria aprender as habilidades de design necessárias para melhorar a usabilidade e a aparência dos meus projetos pessoais. Enquanto eu entrei no programa…

Quando me formei na faculdade em 2014, fiz isso com dois diplomas de bacharelado, um em ciência da computação e outro em design. Eu escolhi originalmente o design porque queria aprender as habilidades de design necessárias para melhorar a usabilidade e a aparência dos meus projetos pessoais. Embora eu originalmente me juntei ao programa para adquirir essas habilidades duras e intrapessoais, foram as habilidades e conhecimentos suaves e interpessoais que se mostraram mais valiosos na minha carreira. Estou aqui para compartilhar um pouco sobre essas habilidades, para que outros engenheiros possam aprender com elas.

 

Lição #1: Você não é seu público

 

No design de comunicação visual, você deve manter seu público em mente. Isso requer um pensamento extra e nuance quando você está projetando para manter essas pessoas em mente. Você não está projetando algo para si mesmo, mas sim você está projetando para comunicar algo para o público. Como eles vão interpretá-lo?

 

A lição para engenheiros de software

 

Da mesma forma para os engenheiros, quando você está construindo um produto, esta frase se transforma em “você não é seus usuários”. Mesmo que seus usuários possam ser semelhantes a você, eles nunca serão exatamente como você. Quando você trabalha em empresas com uma presença global significativa, como o Google, isso se torna mais facilmente aparente, pois você tem que projetar produtos para usuários em países em desenvolvimento e desenvolvidos. Nunca assuma que seus usuários finais estarão pensando a mesma coisa que você.

 

Lição #2: Feedback construtivo e objetivo é sempre melhor do que feedback redutivo e subjetivo

 

Robert Sedlack, meu professor de Design de Comunicação Visual I (que também era meu conselheiro e a razão de dirigir por que decidi participar do programa de design) baniu duas frases durante críticas em sua classe: “Eu gosto” e “Eu não gosto”. Em vez disso, ele nos encorajou a usar para dar feedback mais completo e substancial usando frases mais fortes com linguagem menos subjetiva. Aqui estão algumas frases de exemplo:

 

“Eu acho que isso é bem sucedido porque…”

 

“Eu não acho que é bem sucedido porque…”

 

“A maneira como você fez X fortalece este trabalho porque…”

 

“Eu acho que a direção de X é mais forte porque…”

 

A lógica por trás disso é porque qualquer um pode dizer, “Eu gosto disso” ou “Eu não gosto disso” e nomear a primeira coisa proeminente que fala com eles em uma peça. Ao reformular a entrega de feedback/crítica, fomos forçados a dar uma análise mais profunda do projeto e articular claramente nosso raciocínio por trás de nossa crítica. A mesma comunicação era esperada quando estávamos explicando os rumos que estávamos tomando para nossas peças também, forçando-nos a analisar profundamente nosso próprio trabalho e realmente pensar as coisas.

 

A lição para engenheiros de software

 

Feedback e linguagem construtivos e objetivos é útil para engenheiros de software ao fazer revisões de código. Embora eu acredite que não há nada de errado em usar a frase proibida “Eu gosto de como você estruturou este pedaço específico de código ou resolveu este problema”, eu acho que você não deve usar as palavras, “Eu não gosto de como…” Em vez disso, transforme sua linguagem para ser um feedback construtivo e objetivo em revisões de código. Por exemplo, vamos olhar para duas formas de feedback.

 

“Eu não gosto da forma como este código é estruturado. Use um mapa hash em vez de uma matriz.”

 

“Você já considerou armazená-lo em um mapa de hash em vez de uma matriz? Eu acho que poderia ter melhor desempenho.

 

Ambos têm a mesma mensagem subjacente, mas a segunda tem mais substância porque contém um porquê, enquanto a primeira não.

 

Além disso, use isso ao pensar em defender suas decisões de implementação em seu código. Se você está ignorando o feedback ou sugestões de alterações no seu código porque você gosta de fazê-lo de uma certa maneira em vez de uma abordagem alternativa, suas emoções podem estar tirando o melhor de você. Afaste-se e pergunte a si mesmo: “Esta é realmente a melhor maneira que isso poderia ser feito, dado os requisitos, ou esse feedback ajudará a melhorar meu código?”

 

Lição #3: Você não é seus projetos/trabalho

 

Outra joia que Sedlack constantemente reiteraria é que “você não é seus projetos”. O que significa que você não deve ter qualquer senso de ego ou apego pessoal quando se trata de seu trabalho. Ao aprender isso, percebi que, embora seja ótimo ter orgulho do seu trabalho, você não deve anexar seu senso de si mesmo ao seu trabalho. Isso ocorre muitas vezes porque uma vez que você anexa um senso de si mesmo ou apego pessoal ao seu trabalho, pode se tornar mais difícil aceitar críticas ao seu trabalho e se esforçar para iterar ou melhorar sobre ele. Descobri que, removendo meu senso de si mesmo e apego pessoal às minhas peças de design, tornou-se mais fácil para mim voltar e iterar no meu trabalho, para ver se eu posso empurrá-lo em uma direção mais forte a partir do feedback das críticas.

 

A lição para engenheiros de software

 

Acho que esta é uma das lições mais valiosas para engenheiros de software. Muitas vezes, tanto em bases de código profissionais quanto em código aberto, há casos em que as pessoas se ligam ao código que escrevem. Isso torna a colaboração mais difícil quando o ego de alguém está envolvido, especialmente se você acha que o código que você escreve não tem espaço para melhorias. Você já conheceu alguém que sempre foi contra explorar mudanças sugeridas em seu código em um pedido de atração? Talvez eles ficaram chateados se alguém entrou e refatorou algum código em que trabalharam no passado? Ou talvez eles ficam na defensiva em resposta ao feedback construtivo sobre seu código. Eu pessoalmente acredito que tudo isso decorre de ser muito ligado ao seu código, então deixe isso ir. Ao deixá-lo ir, você estará mais aber