Neste artigo, simplesmente farei a tradução de um pequeno trecho do livro The Passionate Programmer, de Chad Fowler, que me chamou muito a atenção.

Infelizmente, a indústria de software tem produzido em massa esses especialistas superficiais, que usam o termo especialista como uma desculpa para saber apenas uma coisa. Na indústria médica, um especialista é alguém com um entendimento profundo de alguma área específica. Médicos encaminham seus pacientes a especialistas porque, em circunstâncias específicas, o especialista pode cuidar melhor deles do que um clínico geral.

Então, o que deve ser um especialista na área de desenvolvimento de software? Eu vou lhe dizer o que estava procurando em cada esquina e beco naquela viagem de recrutamento. Eu estava buscando pessoas que entendessem profundamente o ambiente de programação e produção Java. Queria gente que pudesse dizer “já passei por isso, resolvi de tal jeito” em 80 por cento das situações que poderíamos encontrar, cuja profundidade de conhecimento pudesse fazer os 20 por cento restantes suportáveis. Eu queria alguém que, enquanto lidasse com abstrações de alto nível, entendesse os detalhes de baixo nível da implementação daquelas abstrações. Eu queria alguém que pudesse resolver qualquer problema em produção que pudéssemos encontrar ou pelo menos soubesse para quem pedir ajuda.

Esse é o tipo de especialista que sobreviverá às mudanças na indústria da computação. Se você é um especialista em .NET, isso não é uma desculpa para não saber nada além de .NET. Isso significa que se algo tem a ver com .NET, você é a autoridade. O Servidor IIS travou e precisa ser reiniciado? “Sem problemas.” Integração de código fonte com Visual Studio .NET? “Vou mostrar como se faz.” Clientes ameaçando cancelar o projeto por questões obscuras de desempenho? “Me dá 30 minutos.”

Se não é isso que ser um especialista  significa para você, então espero que você não diga que é um.

Texto original:

Unfortunately, the software industry has churned out a whole lot of these shallow specialists, who use the term specialist as an excuse for knowing only one thing. In the medical industry, a specialist is someone with a deep understanding of some specific area of the field. Doctors refer their patients to specialists, because in certain specific circumstances, the specialist can give them better care than a general practitioner.

So, what should a specialist be in the software field? I can tell you what I was searching for in every nook and cranny on that recruiting trip. I was searching for people who deeply understood the Java programming and deployment environment. I wanted folks who could say “been there, done that” in 80 percent of the situations we might encounter and whose depth of knowledge could make the remaining 20 percent more livable. I wanted someone who, when dealing with high-level abstractions, would understand the low-level details of what went into the implementation of those abstractions. I wanted someone who could solve any deployment issue we might encounter or would at least know who to call for help if they couldn’t.

This is the kind of specialist who will survive in the changing computer industry. If you’re a .NET specialist, it’s not just an excuse for not knowing anything except .NET. It means that if it has to do with .NET, you are the authority. IIS servers hanging and needing to be rebooted? “No problem.” Source control integration with Visual Studio .NET? “I’ll show you how.” Customers threatening to pull the plug because of obscure performance issues? “Give me thirty minutes.”

If this isn’t what specialist means to you, then I hope you don’t claim to be one.

Charles Chaplin, no filme Tempos Modernos, pinta um retrato cômico de um operário na era industrial. Seu trabalho é apertar um parafuso e provavelmente ele não tem ideia do que está ajudando a construir. Extrapolando toda a crítica social dessa obra, será que, como profissionais, podemos extrair uma lição prática para hoje? Acredito que sim!

Antes de falar sobre que tipo doença é essa tal de dependência organizacional ;-), deixarei o caro leitor com uma indagação: você é dependente da estrutura da sua empresa? Se trocar de emprego hoje, ainda que na mesma área, teria que praticamente recomeçar sua carreira?

O que é a Dependência Organizacional

Na área de TI, tenho notado que, em empresas de médio e grande porte, as quais contam com um ambiente complexo, o desenvolvedor tende a aprender uma forma muito específica de engenharia de sistemas. Ele simplesmente “pega o jeito” da empresa, isto é, aprende a usar ferramentas e processos específicos para criar um tipo específico de aplicação.

Também já vi currículos onde profissionais de desenvolvimento afirmam ter experiência com ferramentas ou frameworks criados dentro da empresa onde trabalham e usados exclusivamente por elas. Sinceramente, tal experiência é, no mínimo, irrelevante, exceto se conceitos de Engenharia de Software forem explícitos, o que dificilmente ocorre com ferramentas internas. Imagine alguém que passou anos criando software com o gerador de tabelas e formulários do Microsoft Access. Dificilmente isso agregará boas práticas sobre modelagem de banco de dados, programação e elaboração de interfaces que sirvam para outras plataformas.

Além disso, a área de TI está cada vez mais complexa. Novos processos, ferramentas, tecnologias e frameworks surgem com uma frequência alta. Se não nos esforçarmos constantemente em aprender, permanecendo numa zona de conforto, acabamos nos tornarndo “especialistas” limitados.

Enfim, a verdade é que muitos profissionais são completamente dependentes da estrutura de uma empresa. Eles ficam perdidos fora do ambiente de trabalho com o qual estão acostumados e dificilmente conseguem manter um diálogo com colegas de outras empresas. Infelizmente, a carreira deles se resume a fazer o que lhes é ordenado.

O ambiente de trabalho

O local de trabalho influencia, até certo ponto, no desenvolvimento do profissional. O trade-off que muitos encontram é algo dessa natureza:

• Trabalhar em uma empresa de grande porte, com estabilidade e boa estrutura, mas ser apenas um operário com uma tarefa específica que nunca enxerga o todo.
• Ou entrar numa empresa menor, talvez com um salário menor, um trabalho desafiador, mas que recompensará e impulsionará sua carreira.

Não é uma escolha fácil, quando há chance de escolha. Porém, independente da cultura da empresa na qual trabalhamos, devemos buscar nos desenvolver e amadurecer como profissionais.

Uma dica para desenvolvedores de software

Desenvolver-se como profissional de TI não se trata apenas de código e tecnologia, mas, falando especificamente aos desenvolvedores, gostaria que todos fossem full stack developers. O que é um full stack developer? Trata-se de alguém que domina diversos aspectos da arquitetura de sistemas.

Faça uma auto-avaliação sobre seu conhecimento. Todos querem ser o novo Zuckerberg, mas, sinceramente, ideias não valem nada. Você tem a capacidade de concretizá-las? Criar um sistema do zero, desde o banco de dados até a interface com o usuário?

Listarei abaixo alguns dos conhecimentos^[1] que um desenvolvedor pode (e deve) ter:

Servidor, Rede e Hospedagem

• Entender o funcionamento, onde e porque podem ocorrer falhas.
• Usar apropriadamente sistemas de armazenamento, nuvem e recursos de rede.
• Entender de redundância e disponibilidade de dados.
• Compreender como a aplicação escala de acordo com o hardware.
• Entender problemas de concorrência e multi-threading.
• Prover mensagens de log coerentes, pois provavelmente outras pessoas irão analisá-las antes de você.

Modelagem de dados

• Criar modelos consistentes pois, se o modelo de dados é ruim, as regras de negócio ou outras camadas mais altas da arquitetura começarão a ter gambiarras para contornar os casos que o modelo não consegue tratar.
• Full stack developers devem saber como criar modelos de dados razoavelmente normalizados, usando adequadamente chaves estrangeiras, índices, visões e outros recursos disponíveis.

Regras de negócios

• Ter conhecimentos sólidos sobre orientação a objetos é essencial para a implementação do “coração do sistema”.
• Conhecer bibliotecas  e frameworks específicos é importante para não se reinventar a roda.

Controle da aplicação e integrações

• Usar adequadamente frameworks é fundamental para a interação da aplicação com o “mundo externo”.
• Full stack developers devem ter a habilidade de criar interfaces de integração simples, claras e consistentes.

Interface com o usuário

• Entender como criar interfaces legíveis, além de reconhecer a importância da ajuda de designers. O visual é um fator chave de um sistema.
• Dominar HTML e CSS. JavaScript também é de extrema importância. Quem não está acompanhando, pelo menos em parte, os imensos avanços desta linguagens em suas variadas aplicações está perdendo um grande recurso.

Experiência com o usuário

• Full stack developers devem entender que os usuários querem um sistema que funcione.
• Um bom sistema não deve provocar tendinite ou cansar a vista. Bons desenvolvedores devem ser capazes de analisar a aplicação como um todo e reduzir um processo que exige uma dúzia de cliques e três passos para apenas um clique.
• Mensagens de erro devem ser claras. Se algo está errado, não saia colocando a culpa no usuário. Alguns programadores, mesmo sem querer, escrevem mensagens de erro que fazem as pessoas se sentirem estúpidas.

Entendimento das necessidades do cliente e do negócio

• Este item já vai um pouco além do papel de desenvolvedor, mas é importante ter um entendimento ainda que básico do que acontece na área do cliente onde o software é usado.
• Hoje, conhecer as regras de negócio é muito mais valioso do que saber 10 linguagens de programação.

E quem não é desenvolvedor?

Me perdoem os demais profissionais, mas o foco do artigo está nos desenvolvedores de software. Mesmo assim, estou certo de que os princípios apresentados são validos para as demais áreas.

Conheço muita gente que é razoável em desenvolvimento, mas simplesmente não está “no sangue”. Se você reconhece isso e aspira a gerente de projetos, analista de negócios ou qualquer outra área, esqueça o tópico anterior e busque um conhecimento estruturado em sua área. Não se assuste nem se iluda, galgar os degraus da carreira não é impossível, mas também não ocorre da noite para o dia.

Além disso, mesmo não sabendo programar uma linha de código, um bom profissional pode participar da próxima grande ideia bilionária se souber cumprir seu papel com excelência. Todos querem trabalhar com pessoas boas e com isso quero dizer pessoas que fazem as coisas acontecerem.

Dicas para vencer a Dependência Organizacional

Está parecendo um macaco apertando botões e preenchendo documentos que não entende? Converse com pessoas mais experientes e procure entender sobre o processo de desenvolvimento e sobre o negócio de sua empresa.

Você está acomodado em um mesmo projeto há muito tempo? Mude. Participe de projetos extra, com amigos ou open source. Em último caso, trocar de emprego pode ser necessário.

Faz tempo que não aprende nada novo? Estude. É importante estudar por conta. Ainda que você tenha alguém mais experiente para lhe dar direções gerais, não desgaste essa relação.

Diga-em com quem andas! Procure estar com pessoas que sabem mais do que você. Melhor, esteja perto de alguém que seja mais ou menos aquilo que você quer ser. O princípio de aprender por osmose pode não funcionar dormindo com a cabeça sobre um livro, mas garanto que funciona se acompanhar bons profissionais de perto.

Conclusões

Mesmo trabalhando num ambiente com poucas oportunidades de crescimento é possível agregar experiência e conhecimento que transcendam sua atual empresa se conseguir entender as razões da existência de ferramentas e processos, seu funcionamento e aplicar na prática esses conhecimentos de alguma forma. Entenda porque as coisas são como elas são!

Profissionais de outras áreas também podem aplicar os princípios apresentados aqui para quebrar a dependência organizacional. Gerentes de projeto devem refletir: eles são apenas “cobradores” e “preenchedores de planilhas” ou eles sabem realmente como fazer um projeto qualquer andar e obter a colaboração dos envolvidos? Arquitetos de sistemas sabem aplicar as boas práticas reconhecidas no mercado ou simplesmente perpetuam “o jeito que as coisas são feitas por aqui”? Administradores de bancos de dados conhecem mesmo sobre bancos de dados ou apenas seguem os padrões pré-estabelecidos pela organização?

Enfim, é normal haver, no início de qualquer carreira, um certo nível de dependência organizacional. Porém, devemos, dia após dia, nos esforçarmos para quebrar essa dependência e evoluirmos para sermos melhores do que o ambiente que nos cerca. Disciplina, estudo, auto-crítica, reflexão e auto-avaliação são fundamentais para esse processo de amadurecimento.

[1] A lista de conhecimentos e habilidades foi baseada no conteúdo deste artigo: http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/

Nossa jornada como profissionais de TI é uma grande curva de aprendizado. Entretanto, desenvolvedores recém-formados raramente compreendem isto. Alguns acham que já sabem tudo o que precisam porque conhecem uma ou duas linguagens de programação. Falo com conhecimento de causa, pois alguns anos atrás eu mesmo acreditava ser suficiente aprender tudo sobre uma linguagem para tornar-se um desenvolvedor experiente.

Mas não é apenas importante estudar constantemente, como todos já afirmam, mas também desenvolver o caráter e personalidade como um todo. Alguns de nós têm um certo prazer nerd em estudar apenas tecnologia. Gastamos nossos dias “escovando bits” no porão da empresa, deixando a barba crescer e ficando sem tomar banho.

É claro que estou exagerando, mas infelizmente isso não está tão longe da realidade. Tenho amigos que são excelentes técnicos, mas por falta de saber trabalhar em equipe e comunicar seu conhecimento, acabam isolados e não se desenvolvem como profissionais. Vencer a timidez, o comodismo, a procrastinação não é algo que ocorre da noite para o dia, mas é possível.

Pessoas são complexas. Entretanto, para fins de ilustração, classifiquemos três níveis de maturidade que caracterizam nossa jornada profissional:

1. O Lobo Solitário

Também conhecido como prima donna (ver Modern usage outside opera) por ter o ego inflado e se achar a estrela principal e indispensável do espetáculo. Em geral possui a síndrome chamada not invented here, isto é, prefere “reinventar a roda” ao reaproveitar o trabalho de alguém. Ele despreza o processo e segue apenas suas próprias regras.

A vantagem de um profissional desse nível é que ele não necessita de muito treinamento e trabalha bem em ambientes com poucos desenvolvedores que conduzem pequenos projetos sozinhos. Porém, ele causa muitos problemas quando uma equipe de verdade é necessária.

Não importa quantos anos de trabalho ou quanto conhecimento um desenvolvedor de software tenha. Enquanto orgulho, ego inflado e superioridade forem suas características, ele nunca será um profissional maduro.

O principal passo para vencer essa fase é reconhecer a importância do trabalho dos outros, de cooperar com os colegas e das regras estabelecidas na organização.

2. O Senhor dos Processos

O desenvolvedor aprende sobre alguns processos, metodologias, normas ou padrões. Ele adota uma metodologia, um par de padrões e tenta seguir tudo à risca, acredita que toda regra estabelecida é importante e todos os que não acompanham nesse pensamento estão errados, não entendendo como essas pessoas podem ser tão tolas.

Em geral, o desenvolvedor adota uma abordagem única, a qual ele acredita ser a melhor para todos os cenários. Ele pode ter sucesso em alguns empreendimentos semelhantes, mas quando surgir um projeto diferente ele estará em maus lençóis.

Para vencer esse nível,  é preciso aumentar o leque de conhecimentos, estudar outras abordagens e compreender os diferentes contextos de cada projeto de software.

3. O Desenvolvedor Consciente

O desenvolvedor consciente trabalha com base em princípios. Ele utiliza esses princípios para selecionar a melhor abordagem para cada situação, extraindo regras de metodologias existentes, mas aplicando-as com sabedoria quando elas devem ser aplicadas.

A maior dificuldade desse nível é a necessidade de grande investimento em educação para que o desenvolvedor entenda os princípios do desenvolvimento de software efetivo. Porém, uma vez que o desenvolvedor está treinado conforme esses princípios, ele estará equipado com todas as ferramentas necessárias para enfrentar uma grande variedade de projetos.

Nesse nível, o profissional não é apenas um programador, mas um Engenheiro de Software. Deste ponto em diante, sua própria experiência e sabedoria o guiarão no seu aperfeiçoamento contínuo.

* Este artigo foi parcialmente baseado em Raising Your Software Consciousness, de Steve McConnell.