Menu

Identidade em desenvolvimento

Na era de desenvolvimento em que vivemos existe um problema particular que pode levar anos a resolver ou em alguns casos, nunca é devidamente resolvido.

Falo de um problema de identidade que existe no mundo desenvolvimento, o problema de os developers serem vistos como developer de X em vez de alguém que resolve problemas ou cria valor através das ferramentas que tem ao seu dispor. Isto acontece com todos os tipos de linguagem, toolsets, plataformas, frameworks, etc a algum ponto.

Imagina que alguém que não sabe programar decide que quer ser um software developer. Faz uma pesquisa no Google e descobre uma escola de código que ensina a escrever software em Java , consequentemente aprende a construir software a usar Java.

Essa pessoa √© agora um "Java Developer". Isto representa um ‚Äúcompromisso‚ÄĚ invis√≠vel.

Sendo um "Java Developer", a pessoa aprende mais sobre Java, torna-se melhor a interagir com Java e sempre que algo novo relacionado com Java √© lan√ßado, essa pessoa aprende e evolui. √Č um processo fant√°stico durante algum tempo.

Mas, de repente, a empresa decide que quer a aplicação feita em Ember.JS ou React e instantaneamente todo o conhecimento de Java que a pessoa adquiriu já não é tão valioso (apesar de, devido a um overlap substancial entre tecnologias, o developer ter sempre um início mais facilitado face a uma pessoa que nunca aprendeu uma linguagem).

Esta pessoa tem algumas op√ß√Ķes:

1. Tornar-se um Ember developer;

2. Tornar-se um React developer;

3. Manter-se fiel ao Java √† medida que a sua import√Ęncia dentro da empresa decresce;

4. Sair da empresa e procurar outro emprego onde possa utilizar Java.

Normalmente, a pessoa acaba por escolher a op√ß√£o 4 de forma a manter a sua identidade como um Java developer. Alguns s√£o capazes de ficar na empresa at√© ao ponto em que a √ļnica op√ß√£o √© sair e outros alterar√£o as suas pr√≥prias cren√ßas e skills de forma a aprender uma nova linguagem e adquirir uma nova identidade.

Todas estas op√ß√Ķes s√£o razo√°veis.

Mas a que trará mais benefício será a de passar de ser um developer X a simplesmente, "developer", alguém que resolve problemas e cria valor de diferentes formas.

A verdade, é que alguns developers nunca se identificam com uma linguagem, framework ou toolset. Conseguem construir qualquer coisa porque não se limitam à tecnologia e resolvem problemas ao criar valor com coisas que se calhar nem são a especialização dos mesmos.

Não é por terem mais conhecimento sobre uma framework ou linguagem específica que decidem resolver todos os problemas da mesma forma.

"Use the right tool for the right job. That’s what an engineer does."

Para estes developers, o facto do projecto ser em Ember.JS/Java/React n√£o passa de um detalhe. Um detalhe importante, mas n√£o t√£o importante face ao problema que pretendem resolver.

Esta adapta√ß√£o de mentalidade permite aos developers alargar o seu horizonte profissional e pessoal pois d√° espa√ßo a uma multitude de intera√ß√Ķes novas no dia-a-dia, intera√ß√Ķes essas que ir√£o ultimamente levar √† resolu√ß√£o do problema (ou n√£o).

Também é verdade que a especialização numa linguagem ou framework especifica tem benefícios, o domínio de uma certa linguagem pode tornar-se mais valioso do que um conhecimento vasto mas algo superficial em diferentes linguagens.

No final, tudo depende da flexibilidade e curiosidade do developer, o quanto o mesmo procura evoluir e se está disposto a lidar com uma adaptação tecnológica e conceptual constante. Mas não nos podemos esquecer que esta adaptação é uma estrada de dois sentidos, para existir, é necessário tanto o developer como o empregador chegarem a um consenso do que será o melhor para o projecto.

O que achas? Devem os developers cingir-se a uma √ļnica linguagem ou framework ou explorar diferentes maneiras de resolver os problemas?

Leave a comment