Todo programador, uma hora ou outra, ou quase sempre passa por isso. Você escreve código e as vezes sente que aquilo faz parte de você, e por isso, a partir desse sentimento, você quer escrever o melhor código do mundo, pelo menos o que você considera ser o melhor código do mundo.

Isso é uma coisa muito boa, partindo do principio que você quer cuidar do projeto cada vez mais, estabelecer padrões e pensar formas cada vez melhores de escrever o código e escalar o sistema. Porém, é comum se sobressair o outro lado desse mesmo sentimento, que iremos observar alguns aspectos abaixo.

Imagine que você trabalhe em equipe e que não só você, mas que mais pessoas estarão fazendo alterações em um projeto. Por mais que você estabeleça padrões de escrita de código, padrões de estrutura para testes e escreva cem páginas de docs com boas práticas, os outros programadores nunca irão escrever exatamente da mesma maneira que você, ou utilizar a mesma abordagem que você usaria. Nessa hora, esse sentimento de propriedade do código pode começar a te incomodar.

O fato disso te incomodar não chega a ser um problema, mas é preciso pensar nas atitudes que você toma frente à uma diferente forma de pensar.

É importante você conseguir analisar o que é bom ou não para o projeto e não o que é diferente ou igual ao que você pensa, ou que fere o seu ego.

Acho válido nós nos questionarmos, para que não nos tornemos pessoas autoritárias, mas sim pessoas colaborativas:

Quando alguém traz uma solução diferente da sua, você considera a possibilidade de essa solução ser melhor, ou você discorda, achando que a sua já é boa o suficiente?

Se você costuma discordar logo de cara, você já está fazendo isso errado. Considere a possibilidade de você estar errado ou de a outra ideia ser melhor. Pessoas pensam de maneiras diferentes e soluções mais simples podem vir das pessoas mais inesperadas, saiba dar espaço para os outros falarem e saiba ouvir o que os outros dizem.

Você costuma pedir que as pessoas façam as coisas sem explicar o porquê?

Se você delega uma tarefa que não tem um motivo explícito e não explica o porquê de a tarefa ser feita, você está desincentivando a pessoa a pensar. Eu mesmo, simplesmente não consigo fazer uma tarefa se eu não entender o escopo e a razão da mesma. Eu preciso entender o que eu estou fazendo, para que eu elabore a minha maneira de fazer aquilo, a maneira que eu acho melhor e que posteriormente será revisada por outros. Como desenvolvedor de software, eu sou pago também para PENSAR e não somente para escrever código!

Quando você vai dar uma opinião contrária a algo, você costuma ser vago?

Quando alguém trouxer uma solução e você discordar da mesma, você deve ser claro e objetivo do porquê discorda. Se você costuma discordar sem argumentos, apenas utilizando frases vagas como: “Eu não acho legal assim”, pode dar a impressão que você não quer que faça de tal maneira apenas porque não é do seu jeito.

Você costuma ser fechado a novas opiniões e idéias?

Esteja sempre aberto a novas ideias, principalmente de pessoas novas no time. Essas pessoas vem com uma outra visão, não tem os “vícios de grupo” como os outros que já estão no projeto.

Isso não quer dizer que você irá fazer tudo da maneira que os outros disserem, mas a mescla das ideias pode chegar à uma solução nunca antes pensada.

Falando sobre vícios de grupo, o vídeo abaixo mostra um experimento sobre Análise comportamental em grupo. É essencial assistir!

Devemos nos fazer essas perguntas com frequência e não podemos nos permitir achar que, possuindo uma experiência menor, uma pessoa não tenha nada a ensinar.

E só pra não esquecer: Código não é escrito em pedra, código é um organismo vivo que constantemente muda.

Para quem quiser ler mais sobre o assunto, eu indico um artigo do Tiago Garcia, explicando o conceito de Propriedade Coletiva do código: Be a thoughtful programmer by exercising more collective ownership

Gostou do post e achou útil? Dê um like ❤️ abaixo para ajudar na divulgação e para que mais pessoas tenham acesso :)