Tag: maturidade

Desafios na carreira de um desenvolvedor

business

Programador, Analista, Desenvolvedor, Engenheiro de Software. Não importa qual o título adotado. Você escreve código? Então é mais um que caiu nessa “cilada”! 😉

Brincadeiras à parte, a área de desenvolvimento de software é uma das mais comentadas, desejadas, amadas e até odiadas da atualidade. Sendo sua história relativamente recente, ainda há muita confusão sobre a identidade do profissional de TI.

Isso se reflete na dificuldade de muitos, senão todos, profissionais ao tomar decisões sobre carreira. O que devem estudar? Vale a pena saber a linguagem X? Em que se especializar?

Todos já ouviram o mantra de que em TI “é necessário estar sempre se atualizando”. Esta é mais uma frase pronta que, de tantas vezes repetida, já perdeu completamente o significado e o impacto em nossas mentes.

Quero agora levá-lo a uma breve reflexão sobre o seu desenvolvimento como profissional e tentar responder de forma geral às indagações acima.

Sim, TI é complicada

Brooks escreveu na edição especial do livro The Mythical Man-Month, lançada em 1995, que ele já não conseguia mais acompanhar o avanço em todas as áreas da Engenharia de Software como antigamente. Quem dirá hoje!

A situação piorou muito. A cada ano aumenta a gama de conhecimento, plataformas, linguagens, frameworks e ferramentas. Os formandos que vão trabalhar com software precisam sair da faculdade dominando conceitos que foram formulados ao longo de anos, décadas e até séculos. É como se cada turma saísse da faculdade sabendo menos que a anterior, já que existem sempre novidades e o gap de informação aumenta.

Essa gigantesca gama de informações faz com que muitos fiquem ansiosos sobre a infinidade de tecnologias a serem aprendidas. E as empresas parecem procurar super programadores que parecem já ter nascido sabendo tudo.

Algumas vezes já fiquei bastante ansioso por conhecer tão pouco e ver cada dia novas tecnologias sendo lançadas. Parecia nunca ter fim!

Não se desespere

Apesar do cenário acima, precisamos compreender que leva tempo para se aprender bem qualquer profissão. Alguns dizem que leva uma média de 10 anos para alguém ser realmente bom no que faz. E pesquisas indicam que passamos a gostar mais do que fazemos proporcionalmente ao tempo que nos dedicamos aquela atividade.

Além disso, não se deixe levar por aquelas milhares de siglas que você não entende, por exemplo quando você olha aquelas vagas de emprego que pedem centenas de conhecimentos que você nem tem ideia do que são. Isto é algo possível de se conhecer com o tempo.

Não estou dizendo que é fácil. É preciso se esforçar bastante, mas o segredo é ter calma, paciência e persistência. Então você poderá planejar seu avanço profissional dentro de suas capacidades e estudar rotineiramente sem desistir ou desanimar.

Ninguém nasce sabendo

Você não precisa saber de tudo para atuar numa certa área. Aliás, faculdade ou curso algum vai ensinar o que é realmente preciso para encarar um trabalho desafiador ou mesmo empreender em seu próprio negócio.

Basta aprender o necessário para cada fase de sua carreira. Para quem está começando em TI, o importante é conhecer bem os fundamentos da computação, orientação a objetos e pelo menos uma linguagem de programação. Depois disso, é importante intercalar ciclos de estudo e trabalho prático para começar o amadurecimento profissional.

Em minha experiência é importante pensar iterativamente, isto é, em ciclos. Você pode traçar uma meta de aprender profundamente sobre uma tecnologia por ano ou a cada 6 meses, dependendo do seu ritmo. Aí você pode gastar o primeiro mês estudando livros e apostilas, o segundo implementando um protótipo simples, o terceiro estudando um pouco mais a fundo, o quarto tentando criar um projeto mais sério, o quinto lendo material mais difícil sobre o assunto e assim por diante.

Especialistas

Persistindo nos estudos, muitos profissionais acabam se especializando num subconjunto de conhecimentos de uma das áreas de TI. Tornam-se especialistas.

Isso fica bem visível ao analisar alguns eventos de TI. É possível observar diferentes nichos de tecnologias, com palestras e cursos voltados para cada subcultura de TI, cada uma com um público bem específico.

É bom especializar-se em algo. Trabalhar e estudar diferentes aspectos de alguma tecnologia por alguns anos é um grande investimento, pois você passa a ser distinto dentro desse segmento.

Porém, a especialização tem lados positivo e negativo.

Especialistas e especialistas

Como mencionei, há algumas pessoas que são especializadas porque se aplicaram consideravelmente em conhecer determinado assunto.

Por outro lados, outras são “especialistas” porque não se aplicaram em conhecer nada além daquilo que já usam no dia-a-dia.

Enquanto os especialistas de verdade estão dentro da média na maioria dos assuntos e dominam sua especialidade, há os falsos especialistas que não se interessam por nada que não é necessário para eles.

Respeitando a individualidade

Devo fazer uma consideração aqui. Precisamos entender que nem todas as pessoas que trabalham em TI são aficionadas por programação ou questões técnicas.

Conheço bons profissionais, organizados e produtivos, mas que não chegam perto de serem bons programadores. Nem todos os “especialistas” e bons profissionais são necessariamente bons programadores. A Engenharia de Software possui muitas disciplinas que envolvem outras áreas.

Não devemos cair no grande erro de muitos educadores no decorrer da história, o qual tem impactado nossa geração inteira. Estou falando da padronização do que é considerado “inteligência” ignorando as singularidades de cada indivíduo. Isso nada mais é do que dar vantagem a um perfil específico em detrimento dos demais.

Muitas empresas e muitos profissionais ignoram isso e inconscientemente geram incalculáveis prejuízos para si mesmas. Aliás, os profissionais que coordenam processos seletivos deveriam ser os melhores da empresa, porque nada como um excelente profissional para identificar as potencialidades dos entrevistados. Porém, o que geralmente ocorre é que essa tarefa fica relegada a profissionais, no mínimo, medíocres. E o resultado são contratações, no mínimo, medíocres.

Enfim, se você não é um programador, ainda pode aplicar todas as dicas que tentou passar aqui em sua área de conhecimento.

Generalistas

Outro perfil profissional é do generalista, isto é, aquele que estuda diferentes áreas, não ficando muito tempo em apenas uma coisa.

Por muito tempo ouvi críticas a esse tipo de profissional. Você já ouviu algo como “saber pouco de tudo é não saber nada de nada”?

Pois bem. Há até um certo fundo de verdade nisso. Se um profissional troca frequentemente de trabalho, mas não se aprofunda em nada, seu destino será exatamente esse: não saberá “nada de nada”.

Por outro lado, veja a tendência do mercado mudar fortemente nos últimos anos. Antes todos queriam espacialistas. Hoje, os profissionais mais valorizados são os que possuem uma visão abrangente da Engenharia de Software, mas conhecendo o que fazem profundamente.

No entanto, colocarei esses profissionais numa nova categoria…

Generalistas especialistas

Que diacho é um generalista especialista?

Após alguns anos de mercado, analisando vagas em grandes e pequenas empresas, notei uma tendência no perfil mais desejado por boas empresas.

É mais ou menos assim. O profissional deve:

  1. Ter pelo menos 5 ou 7 anos de experiência
  2. Dominar pelo menos 2 tecnologias
  3. Ter conhecimentos intermediários em várias tecnologias
  4. Conhecer o básico de todos os conceitos importantes da Ciência da Computação e Engenharia de Software

Obviamente esses valores e as estatísticas são uma média arbitrária da minha cabeça, mas serve bem para ilustrar meu ponto aqui. Vou traduzir isso em alguns princípios e estou certo que será útil para você.

1. Experiência

Os anos de experiência na verdade não são tão importantes em si mesmos. A questão toda está na maturidade do profissional.

As empresas e os próprios desenvolvedores querem alguém que agregue à equipe e não que seja um atraso. É uma realidade cruel para os novatos, mas a verdade é que hoje não importa muito se você é um gênio em matemática ou em programação. Os desafios mais comuns da Engenharia de Software estão em outras áreas, principalmente nas relações humanas. E, convenhamos, poucos recém-formados são habilidosos em trabalhar com pessoas.

Além disso, não importa se você sabe uma linguagem de programação de cabo a rabo. Resolver problemas complexos da via real exige uma carga de conhecimentos em diferentes áreas.

2. Especialização

Para entregar software no prazo e com qualidade, além de corrigir os problemas mais difíceis, o profissional deve dominar a tecnologia com que trabalha.

Porém, conhecer uma única tecnologia não é mais suficiente.

A grande maioria dos sistemas desenvolvidos hoje são web. De início, podemos dividir esses sistemas em back end e front end. Se você é da área, deve saber que em geral as tecnologias de um e de outro são completamente diferentes. Por isso, é comum hoje um bom profissional que domina .NET ou Java também dominar Javascript, HTML e CSS.

Note que não estou falando em conhecer um pouco de cada tecnologia, mas sim em ser altamente proficiente em várias delas.

3. Generalização

Com a grande variedade de tecnologias disponíveis, o profissional que conhece pelo menos em nível introdutório o funcionamento básico de cada uma, além dos conceitos que dão suporte a essas ferramentas, terá muito mais capacidade de escolher a solução mais correta e adequada para os diferentes desafios.

Isso parece contradizer o tópico anterior, mas não é bem assim. Se você domina pelo menos uns dois paradigmas de programação e tem bons fundamentos técnicos, provavelmente se dará bem com qualquer novidade. Este é o ponto: um generalista é muito mais adaptável a novos desafios.

As antigas guerras de “Ruby vs PHP”, “Python vs Perl”, “C++ vs Java” simplesmente acabaram, exceto para alguns que faltam em maturidade.

Hoje os bons profissionais sabem que não é preciso escolher uma linguagem definitiva. Você poderia usar todas ao mesmo tempo, se quiser. Aliás, em determinadas situações você deve usar um conjunto delas no mesmo projeto.

4. Visão abrangente

Primeiro, desenvolver software não é apenas digitar código. Tenha em mente que para programar bem você deve sim conhecer os fundamentos da Ciência da Computação.

Não vou menosprezar quem aprendeu por conta. Alguns conseguem. Mas não pense que nesta área você será um bom profissional sabendo apenas digitar comandos numa linguagem qualquer.

Estruturas de Dados, Sistemas Operacionais, Geometria, Cálculo, Estatística. Tenha certeza que, cedo ou tarde, disciplinas que lhe faltam poderão ser um empecilho para uma atividade de mais alto nível, a não ser que você queira fazer sistemas de cadastros e relatórios pelo resto da vida.

Segundo, desenvolver não é apenas programar bem. Se você tem alguma experiência em projetos, já deve saber que a programação em si é apenas uma parte de uma grande cadeia de comunicação, motivação, acordos, burocracia, egos e muito mais. Saber lidar com tudo isso é o que realmente irá levá-lo a algo maior.

O perfil do profissional ideal

Escutamos repetidas vezes que as empresas procuram o profissional com experiências nas tecnologias X, Y ou Z. Pode até ser verdade em muitos casos. Porém, quem já trabalha em TI há mais tempo sabe que bons profissionais, com bons fundamentos teóricos, podem aprender qualquer linguagem ou tecnologia.

Outra habilidade importante é a de realmente produzir coisas úteis. Pode parecer estranho, mas muitos profissionais com boa formação e conhecimento abrangente têm dificuldade em implementar ferramentas e sistemas que tenham algum valor para os clientes. Pode ser porque eles deem excessiva importância a minúcias técnicas ou não consigam entender o que o cliente realmente quer, mas seja qual for o motivo por detrás disso, o código que eles produzem é bom só para eles mesmos.

Já o profissional ideal é aquele que consegue compreender os usuários do sistema e implementar, tecnicamente da melhor forma, exatamente aquilo que o usuário precisa.

Por último, mas não menos importante, vou citar as habilidades interpessoais. Inclua no pacote boa capacidade de comunicação e uma personalidade agradável para então ter um profissional realmente “perfeito”.

É claro que na maioria das vezes essas questões de comunicação e relacionamentos são extremamente subjetivas. Elas acabam ficando de enfeite nas descrições de vagas e grande parte dos entrevistadores não dão importância a isso. Mas não se engane! A personalidade é um fator chave para o sucesso e fracasso de toda uma equipe.

Qual seria a personalidade ideal? Aquela que faz as pessoas se sentirem bem ao trabalhar com você. Um profissional que deixa o ambiente da empresa ruim gera um prejuízo incalculável. Porém, se os membros de uma equipe encontram em um profissional alguém com quem realmente desejam trabalhar, este profissional deveria ser mantido na empresa a todo custo.

Como chegar lá

Todo esse papo pode deixar você com um grande peso nas costas. Mas, como já disse, deixe a ansiedade para trás.

Se você é da geração Y ou, pior, da geração Z, mude sua disposição e saiba que todas as coisas boas levam tempo para serem construídas e tem um custo associado.

Primeiro, se você acha que sabe tudo, conscientize-se de que então não sabe nada.

Segundo, Aprenda conceitos e fundamentos sólidos. Não tente seguir todas as ondas e modinhas tecnológicas. Por exemplo, aprenda muito bem orientação a objetos antes de dizer que sabe C++, Java, Scala, Go. Aprenda o que é programação funcional antes de dizer que sabe Javascript. Aprenda sobre redes e protocolos antes de dizer que sabe desenvolver um sistema web.

Crie um planejamento de estudos. Quais são as coisas mais importantes e prioritárias para se aprender na sua área?

Estude frequentemente, não muito intensamente. Se você quer aprender bem Java, por exemplo, pode estudar para obter a certificação. Você vai precisar ler mais de 800 páginas. Faça um plano de estudos de 6 meses a 1 ano, dependendo do seu ritmo. Pode parecer muito, mas lembre-se que tudo leva tempo.

Conclusões

Você pode estar ansioso por alguma pressão externa. Então espero que este artigo tenha lhe acalmado.

Por outro lado, se você fica ansioso porque quer progredir muito rápido, tenha cuidado para não se decepcionar.

Se você acha que sabe muito mais do que pessoas mais velhas e mais experientes, talvez achando que a empresa não te reconhece, também tome cuidado. Faça entrevistas em empresas melhores para tirar a prova disso, pode ser uma lição de humildade.

Alguns programadores acham que são melhores que os chefes porque estes não conhecem tanto sobre uma certa linguagem ou certas novidades. Sim, em alguns casos pode ser verdade, mas na maioria das vezes falta maturidade em compreender os desafios diários que ele precisará enfrentar.

É o mesmo caso de tantos jovens que acham fácil programar e tentam empreender, só para depois perceber que não conseguem clientes o suficiente ou não dão conta das demandas técnicas e da gestão do negócio.

A experiência mostra que os inexperientes acham que tudo é fácil. A maturidade de um proporcional vem sempre acompanhada de sua capacidade de enxergar os desafios que ele precisa enfrentar e as consequências de suas decisões.

Enfim, não tenha pressa, estude sempre e aproveite todas as oportunidades que tiver para aprender e se relacionar com outros profissionais mais experientes.

Seja um especialista

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.


homem-com-lupaInfelizmente, 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.

Dependência Organizacional

Annex - Chaplin, Charlie (Modern Times)_01

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/

Você é um desenvolvedor consciente?

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

lobo

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

agent-smithO 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

desenvolvedor-experienteO 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.

Bons programadores escrevem código complexo?

Você já viu algum desenvolvedor se gabar de ter criado código difícil de ler? Talvez você já tenha se sentido o máximo ao fazer algo assim:

void Run( const std::string& v, int tgt, int start ) { for( ; tgt >= 2 * start + 1; ++start ) Run( v + ' ' + boost::lexical_cast( start ), tgt - start, start + 1 ); std::cout << v << ' ' << tgt << std::endl;} int main() { Run( std::string(), 10, 1 ); getchar();}

(Extraído de http://www.cplusplus.com/forum/lounge/13042/)

Código complexo é código ruim

spaghetti-code Bons programadores sabem que a complexidade é sua inimiga. Quando trabalhamos com software de verdade temos de lutar contra ela. A complexidade esconde erros, dificulta a leitura do código e inviabiliza a manutenção. Se nada disso lhe diz muita coisa, pense que o impacto vai diretamente para o seu bolso, principalmente para consultores e freelancers.

Você já precisou dar manutenção em código escrito por você mesmo há muito tempo e teve dificuldades em entender, além de ficar pasmo por ter escrito algo tão hediondo? Será que o cuidado ao produzir código no passado poderia ter lhe poupado de dificuldades e perda de tempo no presente? É claro que sim! E grande esperança há para você se for capaz, hoje, de fazer melhor que antes!

Código complexo é código ruim. Sua manutenção exigirá refatoração abrangente. Você já olhou um programa tão confuso que, antes de modificá-lo, preferia reescrevê-lo completamente?

“Ah, mas pra isso existem os comentários”, você pode argumentar. Não se precipite! Muitos irão lhe contradizer. Processos como o XP enfatizam a necessidade do código ser claro e auto-explicativo. Comentários são por vezes nossos inimigos. Eles podem nos enganar ao declarar algo que o código efetivamente não faz. Em excesso, poluem visualmente o código e tornam nossos fontes mais extensos.

Seja simples

Uma das abordagens para fugir da complexidade é o princípio conhecido como KISS: “Keep It Simple, Stupid!“. Em português poderia ser: “faça isto simples, seu estúpido!”

Resumirei alguns passos deste “programa de reabilitação para programadores”:

  • Seja humilde, não pense em si mesmo como um gênio.
  • Divida suas tarefas em sub-tarefas: não leve mais do que algumas horas para trabalhar em um código.
  • Aprenda muito bem sobre coesão, acoplamento e responsabilidades de classes e métodos.
  • Resolva o problema primeiro, codifique a solução em seguida.
  • Não tenha medo de descartar código.

Um engenheiro de software experiente deve saber usar as ferramentas à disposição para produzir o resultado desejado com o mínimo de complexidade e esforço. Por outro lado, programadores são apaixonados por “reinventar a roda”. Nos meus primeiros anos, pensava comigo: “para que aprender o framework X  se posso escrever o meu?!”. Já reescrevi muitos frameworks. Serviu-me de alguma coisa? Claro! Principalmente em ver minhas limitações e a importância do trabalho alheio!

Exemplo de simplicidade

Pense no cara da direita como você na faculdade e no da esquerda já com alguns anos de experiência.

Conclusão

Quem se importa se o programa leva alguns milissegundos a menos para executar ou se o código é mais “bonito”? O ego do programador?

Um profissional de TI maduro deve se esforçar para aperfeiçoar suas habilidades de comunicação. Isto independe de sua área de atuação, pois todos os artefatos do processo de desenvolvimento, incluindo o código, devem ter qualidade suficiente para cumprir o seu papel e transmitir a informação o mais efetivamente possível.

Além disso, é melhor guardarmos nossas habilidades artísticas para um concurso como o International Obfuscated C Code Contest:

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
        _-_-_-_-_-_-_-_
            _-_-_-_
}

Da anarquia à otimização: maturidades do processo de desenvolvimento de software

Em seu artigo From Anarchy to Optimization, McConnell analisa um estudo do Instituto de Engenharia de Software (SEI, em Inglês) do Departamento de Defesa norte americano, a respeito da efetividade do processos de desenvolvimento de software praticados.

Veja a seguir como o autor descreve os cinco níveis de maturidade.

Os níveis de maturidade do SEI

I. Anarquia

Não há planejamento nem gerenciamento. O desenvolvedor faz o que pode e espera que tudo dê certo.

II. Folclore

Nessa altura o desenvolvedor ganhou experiência num tipo específico de sistema. Ele realiza alguma espécie de planejamento, estimativa e gerenciamento, acreditando que desenvolveu um processo de trabalho efetivo. A empresa depende fortemente dos desenvolvedores que, se deixam o emprego, levam embora todo seu conhecimento. O sucesso depende dos novos projetos serem semelhantes aos anteriores e geralmente há problemas com novas ferramentas e domínios diferentes.

III. Padrões

A mitologia da empresa é documentada em forma de padrões, assim o processo não é mais dependente de indivíduos. Porém não há dados e métricas para análise e comparação da eficácia do processo. O fato de haver documentação não significa que o processo é bom, então os programadores geralmente discutem o valor do processo em geral.

IV. Medidas

Dados brutos do processo são coletados para medir sua eficiência e possibilitam a comparação e o julgamento com outros processos de forma objetiva. Isso acaba com a discussão subjetiva do nível anterior.

V. Otimização

Com a documentação e as métricas, a empresa começa a melhorar o processo. Ferramentas automatizadas de coleta de métricas são usadas para acelerar ainda mais o processo.

Suponha que a empresa mediu o número de defeitos por linhas de código. Ela então cria uma variação do processo original e mede o resultado. Se este for positivo, a variação se torna o novo padrão de processo.

Benefícios

Você pode estar se perguntando se investir na melhoria dos processos vela realmente a pena. Para responder a isso, o autor utiliza dados obtidos por Alfred Pietrasanta.

Alfred acompanhou uma empresa chamada Lockheed num programa de melhoria do processo de desenvolvimento de software por cinco anos. Nesse tempo, eles partiram do nível 1 e chegaram até o nível 3, obtendo resultados substanciais e tangíveis. A tabela abaixo representa numericamente os benefícios de um projeto típico de 500 mil linhas de código:

Nível Custo de desenv. (milhões) Tempo de desenv.
(meses)
Qualidade
(defeitos / KLOC)
Produtividade
(LOC/Hora)
Produtividade
($/LOC)
1 33 40 9 1 66
2 15 32 3 3 30
3 7 25 1 5 14
4* 3 19 0.3 8 6
5* 1 16 0.1 12 2

* Os resultados desses níveis são apenas projeções, já que a empresa chegou apenas até o nível 3.

Nos cinco anos, a Lockheed melhorou a produtividade em 5 vezes e reduziu a quantidade de defeitos em quase 10 vezes. Resultados semelhantes foram obtidos em projetos da IBM, Motorola e Xerox. A empresa Hughes Aircraft relatou que um investimento único de $ 400 mil na melhoria do processo para 500 empregados está agora dando um retorno de $ 2 milhões ao ano.

Conclusão

Embora o artigo seja relativamente antigo, a verdade é que o cenário de TI pouco mudou no que se refere à maturidade das empresas, o que prova que realmente não existem “balas de prata” (soluções mágicas) quando se fala em desenvolvimento de software.

Portanto, a receita continua a mesma: é necessário investir constantemente para colher melhores resultados no desenvolvimento de software.

Creative Commons O blog State of the Art de Luiz Ricardo é licenciado sob uma Licença Creative Commons. Copie, compartihe e modifique, apenas cite a fonte.