Pragmatismo e Engenharia Baseados em Equipe

Quando se trata de fazer qualquer tipo de desenvolvimento – não importa se é para a web, para celular ou para alguma outra plataforma – há muitos livros, cursos on-line e assim por diante que facilitam incrivelmente o aprendizado é você quer aprender.

Para ser claro, também não estou criticando nenhuma das maneiras disponíveis para aprender. Afinal, todos nós aprendemos de maneiras diferentes, certo? E quem sou eu para dizer qual caminho é melhor do que qualquer outro, especialmente pelo fato de escrever diariamente sobre tópicos aqui e em outros sites?

Mas posso dizer definitivamente para mim – alguém que gostou de aprender por meio de educação formal, tutoriais, cursos e assim por diante – a melhor maneira de ganhar experiência neste setor tem sido duas vezes:

• trabalhar com outras pessoas,
• quebrar coisas e aprender como consertá-las.

Quero dizer fazê-lo nesta ordem específica? Não. Isso significa que estou aos trancos e barrancos à frente dos outros? Isso é risível.

Mas como tive o prazer de trabalhar com outras pessoas em vários projetos, conversando com outras pessoas via Twitter, conferências e assim por diante e experimentei tanto o bom quanto o ruim, é algo que acho que todos deveriam ter a oportunidade de fazer em algum momento.

Se eu tivesse que resumir, diria que se trata de encontrar um equilíbrio entre pragmatismo e engenharia baseados em equipe. Por que, porém, se nada do que foi dito acima é novo (dado que as empresas de software existem há décadas), estou me incomodando em escrever sobre isso agora?

Pragmatismo e Engenharia Baseados em Equipe

Eu provavelmente poderia apresentar uma lista de razões pelas quais eu acho esse tópico específico importante, mas há três coisas específicas que eu gostaria de mencionar neste post. E, por uma questão de comprimento (leia-se: tempo), farei o que puder para mantê-los curtos.

Na verdade, o TL;DR do que vou falar tem a ver com pragmatismo e habilidade de engenharia. Originalmente, eu também ia incluir uma perspectiva sobre negócios em geral, mas o post geral ficou um pouco fora do tópico.

1 Pragmatismo

Já escrevi sobre equilibrar engenharia e pragmatismo antes.  Então, posso não ter muito a oferecer em termos de algo novo, mas estou começando a mudar um pouco minha perspectiva.

Ou seja, em um ponto, tratava-se estritamente de encontrar um equilíbrio entre encontrar uma solução que funcione para o cliente, que seja bem construída e que resolva o problema deles. E ainda subscrevo isso.

E, claro, há algo a ser dito sobre como o código é organizado para que possa ser mantido ao longo do tempo. Isso é fundamental. Mas como o código é construído é escrito e a solução é construída é onde as coisas podem ficar um pouco mais embaçadas em relação ao pragmatismo.

Isso quer dizer que é fácil escrever código orientado a objeto básico, documentá-lo, fazer com que algumas classes ou funções chamem umas às outras, conectem-se ao WordPress e depois concluam.

2 Habilidade de Engenharia

Mas esse nível de equilíbrio entre o envio da solução e a arquitetura da solução é uma linha tênue a ser percorrida. Acredito, no entanto, que há um perigo em tentar ser muito opragmático: se você pretende permanecer o mais pragmático possível o tempo todo e deixar suas habilidades de engenharia em um nível específico, pode não progredir como desenvolvedor.

Embora eu prefira usar programação orientada a objetos no tipo de trabalho que faço, não sou de entrar em uma guerra religiosa ou entrar em qual versão de qual linguagem, qual tecnologia, ou se funcional, procedimental ou orientada a objetos a programação é melhor.

Simplificando: trata-se do nível geral de habilidade que você pode alcançar ao longo de sua carreira.

E quando trabalho com desenvolvedores que trabalharam em projetos de diferentes habilidades, que foram educados de maneiras diferentes e que resolveram diferentes tipos de problemas, descobri que aprendo coisas novas consistentemente.

Isso não quer dizer que não haja conversas sobre coisas que podemos implementar como equipe ou parceria, mas significa que isso pode impedir o potencial de crescimento como programador.

Eu poderia continuar sobre isso, mas o resumo é o seguinte: se você for trabalhar com outras pessoas, certifique-se de que elas sejam experientes, goste de usar o mesmo tipo de paradigma que você, esteja aberto a conversas ponderadas e traga uma variedade de experiência à mesa.

Em última análise, isso pode ajudar a melhorar sua capacidade e a qualidade do que você e sua equipe estão trazendo para a mesa.

Sempre Há Mais

Como eu disse anteriormente no post, sempre tem mais. Provavelmente falarei mais sobre o aspecto comercial disso em posts futuros.

Por enquanto, porém, vou deixar o que escrevi onde está e partir daí mais tarde.