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 aberto a iterar e melhorar seu código sem deixar seu ego segurá-lo.
Lição #4: Iteração é chave para melhoria
Ao projetar, é muito raro que a primeira direção que você tomar para um projeto será a melhor. Em vez disso, através de iterar e explorar diferentes direções e apresentá-las durante a crítica, você pode usar críticas para ajudá-lo a encontrar a direção mais forte. Mesmo que você não os apresente para crítica, ter vários trabalhos para comparar uns com os outros pode ajudá-lo a encontrar pontos fortes e deficiências uma vez que você tem várias peças para comparar entre si. Uma vez que você decide sobre uma direção sólida para tomar para um design, você pode continuar iterando sobre esse design e criticando-o até ter certeza de que ele está em sua melhor forma.
A lição para engenheiros de software
Da mesma forma com a codificação, a primeira direção que você toma para resolver um problema pode não ser a melhor maneira. Muitas vezes, eu coduei algo, mas depois percebi que há uma maneira mais ideal e/ou simples de resolver algo. Durante uma solicitação de tração, um colega de trabalho pode apresentar uma solução alternativa que você não pensou que é mais simples ou rápida. No final, essas iterações vão finalmente ajudá-lo a crescer, à medida que você aprende algo novo no processo.
Lição #5: Sempre critique seu trabalho
Um elemento comum em todas essas lições anteriores é a crítica. O feedback mais valioso ou ideias para melhorar meu trabalho de design sempre veio durante as críticas, sejam elas sozinhas ou com colegas de classe. Durante as críticas na sala de aula, você joga seu trabalho em uma prancha na frente da classe, explica a direção que está tomando com a peça e o raciocínio por trás disso, e então você abre a palavra para feedback. Muitas vezes, meus colegas de classe encontravam coisas que eu tinha esquecido ou me ajudavam a descobrir quais direções são as mais fortes.
Mesmo fora da sala de aula, ajudou a se afastar do projeto e segurar uma crítica por conta própria. Fazendo perguntas como: “O que esse design faz bem e o que ele não faz bem? O que ele comunica? Essa é a mensagem que eu quero comunicar?” Recuar e criticar meu próprio trabalho me forçou a criar a melhor peça possível.
A lição para engenheiros de software
Como engenheiro de software, a lição que tirei disso é que você deve sempre fazer revisão de código. Mesmo em projetos paralelos, não é sempre que eu empurro para o ramo mestre a menos que seja uma correção pequena e rápida. Para a maioria dos recursos, faço meu trabalho em um ramo separado e abro um pedido de tração, mesmo que eu seja o único trabalhando no projeto. Durante esses pedidos de tração, eu mesmo reviso meu código, para ter certeza de que não há nenhum bug ou que eu não perdi nada. Eu até adiciono amigos ao meu projeto paralelo repos e pedir-lhes revisões de código em recursos mais complicados apenas para ter certeza de que eu não perdi nada.
No trabalho, embora você possa precisar ter um membro da equipe revisá-lo antes de fundi-lo, você deve fazer um passe do código uma ou duas vezes a si mesmo. Você também pode usar esses pedidos de tração para dizer aos revisores: “Esta é a direção que tomei, mas também pensei em fazê-lo desta maneira, pensamentos?” Isso é o mesmo que obter feedback sobre duas direções que você pode tomar para um design durante a crítica e pode ser útil ter feedback para levá-lo pelo caminho certo.
No geral, essas são as principais coisas da escola de design que foram inestimáveis para minha carreira como engenheiro de software e eu tenho escola de design para agradecer por isso. Espero que essas lições forneçam o mesmo valor para você.
