Arquivo da categoria: Filosofais

Existe vida, e muita, além dos seus for / if e else!

Nos meus últimos dois anos profissionais, vivenciei uma experiência, no mínimo, muito interessante: saí do desenvolvimento para atuar na área comercial. Fui desempenhar o papel de pré-venda tentando fazer o meio de campo entre demandas dos clientes, nosso time de novos negócios e nosso time de desenvolvimento.

“Bacana, Lulão… e por que você tá nos contando isso?”

Porque uma das coisas mais fantásticas que aconteceu, nesse período, foi eu conseguir enxergar, e principalmente, vivenciar que existe muita coisa no desenvolvimento de um software além da programação. E isso é incrível!

Durante esses dois anos, eu me envolvi em atividades comerciais, preocupações administrativas e financeiras, assuntos do marketing, assuntos do RH e por aí vai. Assuntos geralmente colocados como menos importante ou, então, como assuntos de áreas de apoio. Eu prefiro chamar de assuntos, ou áreas, de sustentação. Apesar de serem sinônimos, a palavra sustentação me traz uma imagem muito mais forte, indispensável para algo se manter.

Essa vivência, alimentada por leituras como um post do Elemar e um pedaço de um post do Akita, começaram a me fazer questionar sobre como costumamos definir a senioridade de uma pessoa. Ah, e também como as pessoas costumam enxergar a sua senioridade. Pelas minhas observações, o mercado anda extremamente inflacionado com relação à senioridade. E quando eu falo senioridade, eu não estou falando somente de sênior: estou falando também de júnior e pleno.

Minha impressão é de que hoje existe um misto de um tempo de experiência, curtíssimo por sinal, que determina a senioridade de uma pessoa bem como se sua atuação, em um único projeto, foi boa isso, automaticamente, aumenta sua senioridade. Esquisito, não é?! Pois é. Talvez seja uma questão de geração… Talvez, e eu acredito mais nisso, seja em função de uma visão míope da realidade!

Nós, desenvolvedores de software, somos criados dentro de um cenário egocêntrico onde o único critério importante é o saber programar. E, muitas vezes, uma única linguagem. Em um único contexto. Isso, talvez, faça de você um bom programador. Mas não um bom desenvolvedor. Talvez você seja um programador java sênior. Isso, porém, não faz de você, automaticamente, um desenvolvedor sênior.

“Uai, Lulão… se é assim, o que é um desenvolvedor sênior para você?”

Não existe um critério único e objetivo com o qual eu possa me explicar para você. Mas uma série de características e habilidades que colaboram para que você melhore sua senioridade. O tempo influencia? Sim! O conhecimento de programação ou de uma linguagem? Também. Talvez muito menos do que você imagina. Mas influencia sim…

Da mesma forma, eu acho que influencia sim como você lida com seus clientes, seja no relacionamento propriamente dito, seja na gestão de suas expectativas. Influencia em como você entende as demandas do seu cliente e em como você entende do negócio do seu cliente. E como você cobra seu cliente? Também! E como você, e sua empresa ou a empresa que você trabalha, se expõe no mercado? Também! E como funciona o processo seletivo? Também! E como se testa uma solução? Também! E como você contrata novos integrantes para o time? Também! E como você apresenta seus resultados para seus clientes, para o mercado? Também? E como eu conquisto um novo cliente? Também!

Do surgimento de uma demanda, seu entendimento e apresentação de uma proposta para viabilização até a entrega efetiva da implementação da solução, e principalmente sua manutenção / evolução e sustentação em produção, a programação é apenas uma parte de todo esse ciclo de vida.

“Lulão, você tá escrevendo isso pra dizer que você é mais sênior que eu por ter vivenciado toda essa realidade extra-programação?”

Não! Eu estou dizendo que, após essa vivência, eu descobri que desenvolvimento de software vai além, e muito além, de fors / ifs / elses. E que se eu quiser ser um desenvolvedor com uma boa senioridade, de verdade, eu tenho que entender, ou no mínimo saber o que se passa ao redor, de tudo aquilo que extrapola minha atuação, o mundo de bits e bytes.

Que fique claro que essa é a minha interpretação da vida e que você não precisa se ofender com ela. Aliás, você está mais do que convidado a comentar e expôr seu ponto de vista. Se você quiser continuar apenas programando e, achando que todo “o resto” é um mero apoio, você pode continuar assim. Só vai fazer mais sentido você se sentir um bom programador. Ou até mesmo um programador foda. Mas estará longe de ser um desenvolvedor com uma alta senioridade!

PS: Edição feita após a publicação original. Minha análise é feita com base em minha vivência (resumida ao mercado brasileiro, mais especificamente no estado de São Paulo principalmente no eixo Campinas – São Paulo) e está longe de ser considerada a verdade absoluta e incontestável de uma situação.

Anúncios

Ideologia, eu quero uma pra viver!

Minha vida com o desenvolvimento de software foi de idas e vindas. Começou no COTUCA quando, na verdade, o que eu queria era fazer um colégio técnico para logo ter minha graninha para começar minha vida e dos cursos que existiam, Processamento de Dados era o que mais me atraia. Mesmo sem saber ao certo o que isso significava.

Com o passar do tempo, e com minha entrada no mundo profissional, o desenvolvimento de sistemas passou a ser algo massante e cansativo. E olha que eu comecei super bem trabalhando com caras (@wmariusso e @alexjunq) excepcionalmente fora da curva. Caras, aliás, que me ensinaram muito e sinto-me cria deles. Meu desânimo com a área se dava, em parte, porque quase sempre nada dava certo e porque eu era uma partezinha do nada: um cara que pegava diagramas feito por alguém e, simplesmente, traduzia para código-fonte.

Foi então que decidi que não era aquilo que eu queria pro resto da minha vida. Resolvi fazer Biologia na faculdade e usar a computação como mera forma de sustento. E só para isso. Acabou que na Biologia, mesmo finalizando o curso, eu não me achei: fazer pesquisa era mais chato do que aquela programação que eu fazia e era covardia, profissionalmente falando, eu começar uma vida de professor contra quase 8 anos de computação. O resultado disso foi que eu acabei me vendendo pra computação e decidi ficar, de vez, nesse mundo de desenvolvimento de software.

O que parecia ser uma decisão conformista (se é que existe esse termo), tomada apenas pelo fato de que esse era o caminho inevitável, tornou-se a decisão mais acertada da minha carreira profissional. Após uma volta traumatizante, que só reforçavam aqueles pontos que me fizeram decidir que eu não queria computação pro resto da minha vida, passei a ter contatos com caras que enxergavam essa profissão, que enxergam o desenvolver software de um jeito diferente. E, então, eu tomei a pílula vermelha!

Esses caras, caras como @rafaferry, @flsusp, @feoult e @ederign, me ensinaram, me mostraram e me fizeram entender que desenvolver um software bem feito é algo extremamente prazeroso. Esses caras também me ensinaram que desenvolver um software bem feito imerso em um time de verdade com pessoas fodas, como foram meus gurus lá do começo e como são esses caras que eu tô falando, é gratificante e inspirador! Caras que me fizeram ver e aprender que o desenvolver software não é só escrever algumas linhas de código mas sim pensar numa solução, é resolver um problema e melhorar uma situação, é discutir e se relacionar com pessoas e, por que não, uma forma de ajudar a transformar o mundo. Por mais maluco que isso possa parecer…

A terceirização de TI

“Líderes de TI precisam desaprender para inovar, diz especialista”. Foi lendo este artigo na Computer World que eu decidi criar o blog e começar a escrever um pouco mais sobre o assunto. Seguindo a recomendação de uma colega aqui do trabalho, fui ler o artigo e confesso que fiquei bem empolgado: não só pelo título mas pelo o conteúdo que eu vinha lendo. Até chegar o penúltimo parágrafo quando o autor fala de terceirização de TI. Aí bagunçou…

Não há dúvidas de que passou do tempo de TI parar de ser um mero produtor, ou reprodutor, de códigos e soluções e passar a ser uma figura crítica e viabilizadora de oportunidades. A aproximação desta área às áreas de negócios trazem experiências extraordinária e resultados incríveis. Mas dizer que terceirizar a engenharia de software é algo que nunca deveria ser aprendido foi o ponto que me doeu. Não só pelo fato de eu ter trabalhado a vida inteira em empresas terceiras de desenvolvimento de software mas por não bater com a minha concepção do que essa ação implica em um negócio.

TI, software, quase sempre, é meio. Quase nunca é fim. Pensemos em um negócio qualquer… um banco, por exemplo. O negócio de um banco é mexer com dinheiro: contas correntes, empréstimos, investimentos e afins. O fim de um banco é esse. É nisso que ele precisa ser MUITO bom e eficiente. Para que isso seja possível, dentre outras coisas, esse banco vai precisar de um baita software que o auxilie a gerenciar da melhor forma, a tomar as melhores decisões, a fornecer aos seus clientes uma ferramenta de acompanhamento do dinheiro investido. Mas o negócio dele é mexer dinheiro, não TI.

Internalizar a engenharia de software pra dentro de um banco é se fechar para tudo aquilo de novidades e melhorias que o mundo de TI possa a vir oferecer. E por que isso? Porque o negócio do banco é mexer com dinheiro, não é desenvolver sistemas. E é nisso que esse banco deve ser expert, excepcional e é bem provável que é para onde irá a maior parte do investimento disponível, seja de dinheiro, de energia, de conhecimento. Da mesma forma, empresas terceiras de desenvolvimento devem ser expert e excepcionais em desenvolvimento de sistemas que, afinal de contas, é o seu negócio. Internalizar algo que é meio, e não fim, para dentro de seu negócio é direcionar sua visão apenas para a sua realidade.

Empresas de desenvolvimento de software estão, deveriam pelo menos, antenadas em absolutamente tudo o que rola de novidades nesse mundo. E devem conseguir, de uma forma bem mais prática, rápida e eficiente, colocar uma novidade em prática para analisar se ela pode mesmo ser adotada, em qual cenário aquilo melhor se encaixa. Empresas de desenvolvimento costumam trabalhar com uma diversidade de negócios e tecnologias bem maiores o que lhes permite ter uma diversidade de soluções de tecnologia mais amplas e, até mesmo, mais eficientes.

Internalizar a engenharia de software, na minha visão, é a mesma coisa que você ser um advogado e querer construir sua casa com suas próprias mãos. Pode ser legal e pode até ficar bom, no caso de você ter algumas habilidades. Mas se você contar com a ajuda de um profissional, cujo negócio dele seja construir casas e que entenda MUITO do assunto, o resultado vai ser bem melhor!