Categoria: Carreira (Página 2 de 3)

Curso de Orientação a Objetos com Java na Uniesp de São Roque

Assuntos Randômicos, Carreira Deixe um comentário

DSCN3428

Na terceira semana de Julho de 2014, ministrei um curso de férias sobre Orientação a Objetos com Java na Uniesp de São Roque.

Foi um tempo muito gostoso de interação com os alunos. Todos gostaríamos que tivesse durado mais. De qualquer forma, aproveitamos ao máximo e foi possível lançar as bases da linguagem Java, Lógica de Programação e Orientação a Objetos.

Agradecimentos

Antes de mais nada, parabenizo aos alunos que compareceram em plenas férias para aprimorar seus conhecimentos em programação, em especial ao professor Daniel Vieira, que organizou o evento e teve a disposição que vai além de suas obrigações como docente.

Agradeço ainda à GFT, onde trabalho, por ter apoiado essa iniciativa e, inclusive, disponibilizado alguns brindes para os alunos. Esses brindes foram entregues aos alunos que conseguiram fazer o maior número de exercícios, que eu havia preparado propositalmente em grande número, com grau crescente de dificuldade, para testar até onde eles conseguiriam chegar.

O professor Daniel entregou também um certificado de agradecimento oficial para mim e para a GFT:

DSCN3427

Material do Curso

Preparei um material introdutório, mas completo, consistindo em apostilas e uma apresentação de slides conceituais. Dessa forma, espero que os alunos possam consultar posteriormente e caminhar com as próprias pernas.

Também deixei algumas referências de estudo, tais como livros, sites e apostilas.

Tudo isso você também pode conferir na pasta Java e Orientação a Objetos, compartilhada no meu Google Drive.

Estatísticas

Além disso, também preparei um questionário de avaliação para os alunos, dos quais a maioria respondeu. Veja abaixo o resultado de duas das principais questões (além da minha inabilidade em criar as opções mais adequadas).

O quanto você considera ter aprendido?

aprendizado

Infelizmente na pergunta acima faltou um nível intermediário entre Muito e Pouco, o que talvez tenha distorcido o gráfico.

No geral, o que você achou do curso?

interesse

Reflexões

Ensinar pode ser uma grande experiência. Para mim certamente é.

Alguns dizem que você aprende muito mais ensinando. Concordo plenamente.

Se você é um aluno ou está começando na carreira, procure absorver ao máximo as experiências e conhecimento de quem já é mais maduro, sem esquecer de reconhecer o esforço daqueles que dispõem de tempo para lhe dar algum tipo de instrução.

Se, por outro lado, você é um profissional experiente, olhe para os que estão começando e procure incentivá-los e instruí-los. Isso é recompensador de várias formas. Compartilhar conhecimento nunca faz você perder nada. No mínimo, ajudará a que você reforce e organize seus conceitos.

Desafios na carreira de um desenvolvedor

Carreira 3 Comentários

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.

Resultados de um experimento social

Carreira 6 Comentários

ExperimentingGeneWilder

Após alguns anos trabalhando com TI, sempre me atualizando a aprendendo coisas novas, acredito ter juntado uma boa bagagem profissional. Porém, notei que talento e esforço não são sinônimos de reconhecimento e crescimento profissional.

Minha influência como profissional atingia apenas meu círculo mais próximo. Para o restante do mundo, eu era apenas um pobre desconhecido.

Não, não é de fama que estou falando e sim sobre como mostrar quem realmente você é. Se alguém colocar meu nome no Google, o que ela vê? Um nada? Um desconhecido? Ou alguém que é respeitado por aquilo que faz, sabe e é?

No início de 2013 decidi começar um experimento pessoal e social, isto é, dar minha “cara a tapa” mesmo!

Explicando melhor o cenário

Em meus primeiros 5 anos trabalhando foi raro um dia em que não estudei alguma coisa nova ou criei algo diferente, ainda que seja o simples prazer de aplicar um pattern simples numa classe simples. Mesmo assim às vezes me sentia estagnado.

Em determinados períodos, houve uma “onda de amadurecimento”, aquela adrenalina de sentir que realmente estava progredindo. Mas, com o tempo, o crescimento desacelera e logo a estagnação aparece novamente. Para continuar crescendo e amadurecendo era então necessário reinventar-se para audaciosamente ir onde nenhum nerd jamais esteve (não entendeu?).

Além disso, embora de certa forma eu tenha me destacado no meu restrito círculo profissional, eu não era “ninguém” para a comunidade de TI. Não havia nada além de colegas imediatos que pudessem dar um aval da minha reputação, nada online que provasse algo sobre mim.

Como superar isso?

Analisando progressos anteriores

Uma das maiores “ondas” de amadurecimento ocorreu no desenvolvimento da minha monografia sobre “Estimação de Software” na PUC-SP. Fui orientado por, nada mais, nada menos que o Dr. Ítalo Vega. A cada análise do meu texto, ele parava e me explicava conceitos muito além do que eu já havia aprendido em qualquer lugar. Aprendi muito sobre como funciona uma mente crítica em relação a argumentos objetivos e subjetivos. Posso dizer que toda minha visão de mundo foi afetada, meu modo de pensar e discutir sobre fatos, evidências e opiniões.

Em linhas gerais, o que aconteceu ali? O que deu início a tal evolução? Pude compreender os seguintes pontos:

  • Exposição do trabalho à análise e crítica de um bom profissional
  • Trabalho em conjunto com quem sabe (muito) mais do que eu

Como repetir essa experiência?

A primeira atitude: este blog

Com a mente borbulhando por ideias e a nova visão sobre TI adquirida na pós-graduação, minha primeira atividade foi começar este blog.

A ideia é dupla: tentar ajudar profissionais mais novos e expor algum conhecimento em forma de texto. Com isso, quem deseja saber quem é o profissional Luiz Ricardo precisa apenas gastar alguns momentos de leitura para identificar meu perfil, minha maturidade, minha profundidade. Nesses quesitos, posso dizer que o objetivo foi (e continua sendo) alcançado.

O problema com o blog (e qualquer site) é que não adianta nada apenas colocar o domínio no ar e postar algum conteúdo. A interação com outros bons profissionais não vem automaticamente. Decidi ir além, a procura de…

Comunidades de desenvolvedores

Sabendo da existência de comunidades como GUJ (Grupo de Usuários Java) e StackOverflow, apostei que seria uma forma interessante de colocar meu conhecimento à prova. Será que eu poderia ajudar aleatoriamente outros profissionais, assim como ajudava meus colegas da empresa? Ou seria meu conhecimento restrito ao meu pequeno ambiente de trabalho?

GUJ Respostas

Meu primeiro “alvo” foi o GUJ Respostas, um sistema parecido com o StackOverflow e diferente de um fórum tradicional. Nesse sistema, usuários criam perguntas e os demais publicam as respostas. Os usuários podem votar contra ou a favor nas perguntas e respostas. Esclarecimentos são feitos através de comentários. A cada voto recebido o usuário que fez uma boa pergunta ou resposta ganha certa quantidade de pontos. Votos contra debitam pontos do usuário.

Ao começar respondendo perguntas, tive alguns percalços. Quando lidamos com alguém pessoalmente podemos escutá-la relatar seu problema e perguntar o que quisermos. Tratando à distância, é preciso atentar-se aos detalhes, pressupor corretamente e saber que se falarmos besteira vai ter alguém lá para apontar isso. É um bom treino para a bola de cristal que todo bom engenheiro de software deve ter.

Fiz o cadastro no GUJ Respostas em Outubro de 2013. Três meses depois atingi a primeira colocação no ranking.

StackOverflow em Português

Algum tempo depois, em 13 de dezembro de 2013, deu-se início à comunidade de língua portuguesa do StackOverflow. Aderi desde o primeiro dia do beta privado!

Para quem não sabe, StackOverflow é uma comunidade que pretende organizar e centralizar informação sobre programação e assuntos correlatos, muito embora, haja muitas outras comunidades interessantes que compartilham do mesmo ideal no StackExchange. A comunidade do StackOverflow costuma ser bem mais exigente quanto ao conteúdo de perguntas e respostas publicadas e os moderadores agem fortemente no intuito de garantir a qualidade do site.

Bem, não sei se preciso dizer que tive alguns trancos no começo. Mais uma vez, ao me expor para outros profissionais, fui passível de análise e críticas.

No fim, os resultados também foram positivos. Após 3 meses participando ativamente atingi novamente o primeiro lugar no ranking.

Análise da experiência social

Obviamente, atingir o primeiro lugar em pontuação nos dois sites não prova de forma alguma que eu sei mais do que todos os que estão lá. Também não é, em si mesmo, um qualificador objetivo de minhas competências.

Porém, pelo menos posso dizer que sou útil como profissional para várias pessoas e que meu conhecimento é abrangente o suficiente para ajudar em muitas áreas diferentes. 😉

Ganho também em confiança diante de possíveis entrevistas e discussões sobre tecnologia em geral.

Além disso, muitas vezes fui criticado. Algumas com razão, outras não. Em determinadas ocasiões outras pessoas deram respostas melhores que as minhas. Aos poucos, comparei minha abordagem frente aos problemas com a de outras pessoas e pude aprimorar meu raciocínio, minha forma de pensar e agir.

Não sei por quanto tempo vou continuar em primeiro lugar nos sites. Na verdade, isso nem importa tanto. Talvez eu passe a dedicar esse tempo a outras atividades para continuar avançando como profissional. Mas foi uma ótima experiência!

Conclusões para o leitor

Creio que os princípios expostos acima valem também para todo profissional, a saber:

  • Expor-se à análise e crítica
  • Aprender/trabalhar com pessoas melhores

Saia da sua zona de conforto

Talvez você seja o melhor no seu grupo. Mas, provavelmente, você é melhor somente naquilo que você é melhor. E quanto às áreas onde os outros são melhores? Provavelmente você tem algo a aprender.

Além disso, sempre há alguém melhor. É um princípio básico.

Seja social

Mesmo bons profissionais ficam defasados e alienados ao se fecharem dentro de si mesmos. Tenha contato com diferentes subculturas de TI e aumente o quanto puder o seu leque de contatos. Isso pode trazer vários benefícios para sua carreira, dos quais vou citar dois:

  1. Aprender a expor melhor seus pensamentos e defender suas ideias, o que pode contribuir para promoções.
  2. Estar por dentro das novidades em termos técnicos e também sobre o mercado, o que vai mantê-lo acima da média e pode até ajudar a conseguir um bom emprego.

Vale a pena repetir meu experimento?

Depende.

Participar de comunidades é um meio válido para ajudar colegas distantes e agregar conhecimento de fora do seu ambiente cotidiano.

Entretanto, não recomendo investir tempo demais nisso, muito menos ter como objetivo uma posição específica no ranking.

Existem outras formas de se aperfeiçoar profissionalmente. Esta é apenas uma delas. Talvez, no seu caso, seja melhor tirar o pó daqueles pobres livros abandonados (ou comprar novos). Ou, quem sabe, matricular-se num curso de extensão ou especialização. Outra possibilidade é participar de projetos de código-aberto, onde seu código será avaliado por desenvolvedores mais experientes.

O importante é reinventar-se sempre e não ficar parado!

Morando no interior, trabalhando na capital: experiências das viagens de fretado

Carreira 144 Comentários

bus_dentro Durante quase dois anos enfrentei a rotina diária de viajar de Sorocaba a São Paulo a trabalho. Gostaria de compartilhar algumas experiências com quem vive nessa situação e também com quem cogita essa possibilidade.

Como muitos que trabalham na capital, nasci e fui criado no interior, mais especificamente em Sorocaba. Também estudei no interior, na Unesp em Bauru. Entretanto, algo que não percebi até chegar ao final da faculdade, foi a diferença de salário e oportunidades entre capital e interior na área de tecnologia. Ninguém havia me alertado da dificuldade, se não da impossibilidade, que seria encontrar uma boa oportunidade de trabalho e carreira para um recém-formado em minha cidade natal.

Acabei indo trabalhar em São Paulo. Na época, já casados, minha esposa e eu entramos na mesma empresa, ambos com cargo de Programador Junior, mas cuja remuneração nos permitiu começar a vida de casal e profissional com qualidade.

A motivação da volta para o interior

Por mais de quatro anos, minha esposa e eu moramos num apartamento em São Paulo. Tínhamos alguma qualidade de vida, pois estávamos localizados ao lado do trabalho. Porém, desde o começo sentíamos alguns dos efeitos do estilo de vida da capital: barulho, poluição, falta de espaço para os animais (levamos dois gatos e tivemos que deixar um papagaio para trás), falta de sol (faz uma diferença para secar e tirar manchas de roupas, além de ser um grande prejuízo para a saúde), barulho, tendência ao sedentarismo, sem falar do barulho. Por outro lado, existem as diversas comodidades que nos eram muito atrativas, como a facilidade de encontrar o que precisávamos, o deslocamento fácil de metrô, a abundância de restaurantes, a agilidade das entregas de lojas online e dos correios (que funciona mais eficientemente na capital), etc.

A balança só começou a pender para o outro lado quando tivemos nosso primeiro filho. Quando ele tinha por volta de um ano, começamos a sentir muita falta de um quintal. Ele também sofria com o barulho constante do tráfego, dos eventuais helicópteros que por vezes traziam gente para o trabalho às 7 da manhã, fogos de artifício e vizinhos gritando palavrões sempre que tinha um jogo de futebol e ainda os constantes eventos ali na região da Paulista.

Quando minha esposa engravidou pela segunda vez, decidimos começar o caminho de volta para o interior em busca de mais qualidade de vida. Não foi uma decisão fácil, mas que ocorreu naturalmente como consequência das prioridades que definimos para nossa família.

É preciso se desapegar

Fazer a migração inversa da capital para o interior não é algo fácil, pois nada vem de graça. É preciso abrir mão de certas coisas.

Ao continuar trabalhando na capital, eu mantive meu salário, mas abri mão de uma boa parte do meu tempo, do meu sono e de um pouco da qualidade de vida que eu poderia ter trabalhando na mesma cidade. Em contrapartida, minha família poderia usufruir dos benefícios da mudança.

Um grande impeditivo para uma mudança completa era a questão financeira. Como já mencionei, a diferença de remuneração entre capital e interior, ainda mais considerando São Paulo, pode ser muito grande.

Eu sabia que, cedo ou tarde, eu teria que abrir mão de uma parte da renda para colher o benefício completo de morar no interior.

Opções de viagem

Além do fretado, há as opções das linhas convencionais que saem da rodoviária e também do carro particular.

Quanto aos ônibus de linha, viajar diariamente é muito complicado. No fretado você consegue descansar mais, tem a possibilidade de descer num local mais apropriado que na Barra Funda (no caso de Sorocaba) e sai mais barato.

E quanto ao carro particular, nem mesmo considerei a possibilidade. Apesar de ser mais rápido, eu não poderia ir descansado, nem aproveitar o tempo da volta para ler, estudar ou trabalhar, além de gastar muito mais com combustível, pedágio, manutenção e estacionamento. Tudo somado à irritação do trânsito.

Considerando tudo isso, os fretados são a opção mais viável para quem faz o translado do interior para a capital três ou mais vezes na semana.

A rotina

A rotina diária de quem anda de fretado varia enormemente, dependendo da cidade e da sua localização dentro dela.

Eu acordava 5:10 para pegar o fretado às 5:35 no ponto mais próximo de casa. O ônibus chegava a São Paulo entre 7:30 e 8:00, de acordo com o trânsito do dia, que melhora bastante nas férias escolares. Descendo na estação Pinheiros do metrô, ainda tinha que pegar dois trens, linhas amarela e verde, até a estação Trianon/Masp na Avenida Paulista. Chegava ao trabalho entre 8:00 e 8:30.

Na volta, saía do trabalho por volta das 17:50 paga pegar o ônibus às 18:35 na marginal Pinheiros. O fretado geralmente entrava em Sorocaba pouco depois das 19:30, mas minha descida era perto das 20:15. Poderiam ainda ocorrer atrasos de até 2 horas nas sextas-feiras, vésperas de feriado ou quando ocorriam acidentes.

Contabilizando, eu passava praticamente 15 horas fora de casa. O trajeto de ida e volta levava em torno de 5 horas no total. Com uma esposa e dois filhos, sobrava pouco tempo para dormir. Após brincar com as crianças, jantar, tomar e ajudar a dar banho na pirralhada e se aprontar para dormir, o relógio já marcava meia noite. Isso se não houvesse mais nada para resolver. Minha média de sono, quando não tínhamos crianças com cólica, dente nascendo ou doentes era de 4 e meia a 5 horas durante a semana.

E, se você está pensando que eu compensava no final de semana, está enganado. Uma das grandes desvantagens de trabalhar dessa forma é só ter o sábado de manhã para resolver as coisas em sua cidade. Embora eu nem sempre conseguisse, iríamos fazer compras e resolver algumas coisas nas lojas do centro de Sorocaba no sábado pela manhã. Também era necessário ir ao supermercado e fazer alguma atividade com as crianças. No domingo tem a igreja pela manhã e a noite. Algumas poucas vezes consegui cochilar uma hora de tarde, conciliando o sono das crianças.

Você pode imaginar que, após algum tempo nessa vida, eu já estava um tanto desesperado por uma mudança efetiva para o interior.

Um ponto positivo dessa rotina é que eu tinha um tempo livre razoável no trajeto da volta para me concentrar. Li alguns livros, trabalhei em projetos pessoais e estudei bastante nesse tempo.

O fretado

Diariamente, centenas de ônibus fretados chegam a São Paulo de diversas cidades. Só de Sorocaba temos mais de uma dúzia de opções, variando o itinerário no trajeto dentro da cidade, no destino e no horário. Cada linha possui suas particularidades, mas no geral cada uma possui um coordenador que faz o controle dos passageiros e também os representa junto à empresa.

O valor dos fretados até agora (final de 2013) é de R$ 450,00 mensais. Provavelmente haverá um reajuste em breve, pois faz muito tempo que os valores estão congelados. Os mensalistas têm direito a um assento reservado, mas também existem algumas pessoas que utilizam apenas alguns dias, pagando o valor avulso, por considerarem os fretados mais confortáveis que os ônibus das linhas convencionais.

No trajeto de ida, as janelas vão com as cortinas fechadas para que todos possam descansar. Geralmente os vidros são escurecidos para evitar a luz em excesso. Os coordenadores pedem para que as pessoas evitem usar celulares ou dispositivos sonoros que possam incomodar os demais. Quanto a dormir nesse trajeto, isso varia de pessoa para pessoa. Conheci algumas que já estavam roncando alguns minutos após se acomodarem. Outras, como eu, muitas vezes não conseguiam nem cochilar devido ao ônibus chacoalhar, frear, ao movimento de quem entra, etc.

Existe ainda a questão de onde colocar o braço. Quando tem alguém do seu lado, não dá pra usar o apoio do meio, então você deve cruzar os braços ou apoiá-los de alguma forma para não ficar batendo na outra pessoa. Como eu tenho ombros largos isso às vezes era um problema e eu chegava com meu braço formigando pela posição.

Para quem gosta, alguns ônibus fazem uma confraternização na última sexta-feira do mês, durante a volta, com direito e jogos de cartas, bebidas e salgadinhos. Obviamente isso varia muito dependendo do ônibus estar cheio ou não e também conforme o coordenador.

No trajeto de retorno você pode aproveitar para usar seu notebook, tablet ou celular.  A maioria dos fretados, mas não todos, possui wi-fi via 3G. O sinal falha em alguns trechos, mas é possível fazer alguma pesquisa ou navegar em redes sociais. Outra opção é assistir ao filme que geralmente o coordenador coloca no sistema de DVD do ônibus.

Vale a pena trabalhar na capital viajando todos os dias?

Depende. Para quem possui moraria no interior e não tem filhos pode ser uma opção válida, principalmente porque os trabalhos na capital remuneram bem e agregam bastante no currículo.

Alguns já me sugeriram procurar uma casa mais afastada em São Paulo. O problema é que dentro de São Paulo o deslocamento pode chegar a 2 horas sem dificuldades. Uma dica: não reclame do tempo que você leva de viagem para quem mora em São Paulo, principalmente se a pessoa mora na Zona Leste ou outras regiões mais afastadas do centro. Para elas isso é completamente normal, já que estão acostumadas com longas viagens em uma combinação de ônibus, trem e metrô. Em certa ocasião, ao falar sobre isso, já olharam para mim com uma cara do tipo “você está reclamando do que?”.

Por outro lado, se você tem a necessidade de passar mais tempo no interior com a família e deseja melhorar em qualidade de vida, esqueça essas possibilidades. Como já afirmei, não podemos ter tudo, mas precisamos fazer uma escolha.

Se você trabalha na capital, morando lá ou viajando diariamente, talvez você se identifique comigo. Mas não se desespere. Meu conselho é que você comece a traçar um plano de migrar para o interior.

Migrando para o interior

Primeiro, faça um mapeamento das empresas da sua área para as quais você teria interesse em trabalhar. Procure por vagas nessas empresas e verifique se o seu currículo atende aos requisitos. Estude, faça cursos e o que mais for necessário para que você seja o mais desejável possível para essas empresas. Faça contatos e networking com pessoas da cidade, participe de eventos, adicione-as no LinkedIn. Esteja conectado com pessoas chave que trabalham nessas empresas, pois elas podem anunciar vagas em suas redes sociais, assim como os canais oficiais das empresas (página do Facebook, LinkedIn, sistema online de vagas).

Fique antenado para quando surgirem vagas boas que se encaixem no seu perfil profissional e esteja preparado para a entrevista, pois as oportunidades surgem logo.

Com essas dicas, o impacto na remuneração e no ambiente de trabalho pode ser minimizado, permitindo uma mudança mais suave e planejada, sem correria ou desespero.

O futuro do mercado de trabalho de TI

Existe uma esperança para quem é de TI (o que não exclui outras áreas também). Embora até agora todas as principais empresas estejam sediadas em capitais, estas estão saturadas e as empresas estão começando a ver com bons olhos algumas cidades do interior que possem universidades e faculdades suficientes para prover mão-de-obra qualificada.

Conheço algumas empresas que estão dando preferência para o interior, enquanto mantém um escritório de negócios na capital onde mantêm a carteira de clientes. Particularmente, eu acredito que esta seja uma solução muito mais adequada do que construir mais prédios e inventar mais soluções paliativas para o caos do transporte e moradia.

Meu apelo para os empresários que estão expandindo seus negócios é que comecem a pensar mais efetivamente nesse aspecto. Embora pareça haver mais dificuldades de administração e gastos com telefonia e teleconferências, certamente estes serão muito menores que o ganho obtido. Além disso, oferecer bons empregos no interior é um diferencial que pode atrair de forma eficiente mão-de-obra bem qualificada, pois, como eu, muitas pessoas capacitadas escolhem o interior por questões pessoais.

Conclusões

Trabalhar na capital e morar no interior é uma espécie de meio-termo entre qualidade de vida e oportunidades profissionais.

Entretanto, cedo ou tarde, nossa balança pessoal vai pender para um lado ou por outro. Se a prioridade é a carreira e as facilidades da vida, a capital é a melhor opção. Se, por outro lado, o são a família e a qualidade de vida, faz bem começar um “plano de fuga” para o interior.

Enfim, é possível equacionar tudo isso, mas infelizmente depende de cada um, pois como regra geral não somos ensinados desde cedo a considerar todas essas variáveis.

Você tem “o jeito”?

Carreira Deixe um comentário

Assista aos primeiros dois minutos deste episódio do Dilbert (ative as legendas em português através do botão “Captions”):

É verdade que algumas pessoas nascem com um “jeito” especial para lidar com aspectos técnicos. Posso dizer que, desde o ano de 1997 quando encontrei uma instalação do Visual Basic 4 num CD emprestado, me deparei com algo em que tenho “o jeito”.

Porém, na área de desenvolvimento de software, temos a tendência de supervalorizar o conhecimento técnico em detrimento de áreas humanas e sociais, assim como ocorre por vezes na área de ensino onde um bom aluno em Matemática é mais reconhecido que um bom aluno em Português ou Geografia.

Mas cada indivíduo possui variadas habilidades em diferentes níveis. Por um lado, devemos exercitar nossos talentos para colhermos resultados satisfatórios. Talento sem treino e disciplina é um grande desperdício. Um excelente programador que não procura se aperfeiçoar vai acabar ultrapassado em poucos anos. Além disso, com diligência, um bom vendedor pode ganhar mais que o pessoal técnico. Por outro lado, é importante trabalharmos nossos pontos fracos. Programadores que escarnecem de usuários, mas não sabem se relacionar, dificilmente alcançarão algum sucesso na carreira.

Algo que tenho aprendido em meus poucos anos de experiência é que o empenho consciente em crescer na carreira vale muito mais do que meu talento em criar código. Este blog, assim como tudo o que tenho produzido, não existe apenas devido ao que eu sei, sendo um resultado de um constante investimento de tempo e intelecto.

Existe um conceito que aprendi estudando economia, chamado trade-off. Basicamente isso diz que nossas escolhas tem um custo. Sempre que você escolhe fazer algo, deixa de fazer inúmeras outras coisas. Quando você gasta seu dinheiro em uma coisa, deixa de gastar em inúmeras outras. Aplique isso na sua rotina diária e coloque na balança o custo do tempo que tem investido em atividades supérfluas. Quantas vezes poderíamos estudar, investir na saúde, aprender um idioma, empreender e se preparar para os vários desafios da vida, mas acabamos em frente a uma TV ou vídeo-game?

Em suma, tendo ou não “o jeito”, trabalhe para aperfeiçoar seus talentos e superar suas dificuldades. Não há ganho sem dor.

Você reclama do seu chefe e do seu ambiente trabalho?

Carreira Deixe um comentário

Te peguei, não é? Mas não se preocupe, todos nós reclamamos e criticamos de alguma forma e isso não é necessariamente ruim.

carreira-escritorio-trabalho-profissao-chefe-empregado-demissao-atrito-relacoes-profissionais-1362150805350_956x500

Críticas construtivas ou reclamações fúteis?

Em várias situações, neste blog e mundo afora, costumo criticar como desenvolvemos e gerenciamos projetos de software. Por outro lado, em sombrios cantos de cozinhas e corredores de empresas ouvem-se constantes reclamações despreocupadas que vão desde a cor da cortina do escritório até o aroma do sabão da pia do banheiro. Qual a diferença?

Quando estamos inconformados com uma situação e queremos melhorar, nossa crítica terá o objetivo de gerar mudança e o resultado é positivo. Uma crítica construtiva é aquela que possui um fator motivador e gera ação nas pessoas. Por exemplo, meu objetivo com artigos de auto crítica é levar o leitor a uma reflexão sobre si mesmo e o ambiente ao seu redor, fazendo-o sair da inércia. Meus erros são uma escola para mim e quanto antes os identifico e os supero, mais benefícios colherei mais cedo.

Mas, infelizmente, quantas vezes dizemos coisas que não acrescentam em nada e geram insatisfação em nós e em nossos colegas? Estamos sendo um empecilho para nossas carreiras e para quem nos ouve. Considero vazia e sem sentido a crítica que fica apenas nela mesma. Seria melhor não a termos declarado.

A boa notícia é que, com um pouco de esforço, podemos transformar nossas reclamações vazias em críticas construtivas. Ao invés de dizer “o processo que usamos é um lixo”, não seria melhor pensar um pouco e mudar para “se ajustássemos a atividade X dessa forma Y, nossa produtividade aumentaria”? Ao invés de reclamar para todos os colegas que “o chefe não reconhece o meu trabalho”, seria melhor eu me esforçar para que o resultado do meu trabalho seja mais tangível de forma que possa frequentemente reportar visivelmente o progresso obtido.

Pense como seu chefe

Isso pode ser ofensivo para alguns, mas tenha paciência e acompanhe meu raciocínio um pouco mais.

Ao fazer uma crítica desdenhosa a um superior, você não ganha nada. Apenas reforça a barreira imaginária entre patrão e empregado. Se você quer crescer profissionalmente, coloque-se no lugar dessa pessoa e tente pensar como ela. Isso não significa se tornar igual a ela. Mesmo não concordando com algumas de suas atitudes, você deve compreender suas motivações. Não há problemas em discordar, mas será que você é capaz de propor uma solução comprovadamente melhor para as dificuldades que surgem sem simplesmente criticar a decisão do chefe ou gerente? Qual seria a reação dele se você propusesse uma boa solução?

A verdade é que na maioria das vezes nossas críticas são ignorantes, pois não temos “conhecimento de causa”. Nós reclamamos do nosso trabalho, não o fazemos direito e ainda assim achamos que podemos ser melhores do que os outros. Seja sincero: você acha que seu chefe vê algum potencial de crescimento em você se nem seu próprio trabalho atual é feito com empenho?

rba1_21

Algumas pessoas vêem o chefe como um tirano (não que alguns não sejam), mas na verdade elas não conseguem enxergar as situações do ponto de vista dele.

Por outro lado, poderíamos alcançar muito mais sucesso profissional se fôssemos capazes de produzir algo de valor para nossa área de negócio do que simplesmente sendo funcionários exemplares que chegam no horário e fazem muitas horas extras. Você é um excelente programador? E daí? Isso não tem a mínima importância se os clientes não estão mais satisfeitos do que com a concorrência. Você sempre fica até mais tarde? Mas se não entregar um produto de qualidade, está apenas desperdiçando energia elétrica. Por que temos essa mentalidade de que somos remunerados pelas oito horas diárias de trabalho? Se o valor do seu trabalho está em passar o tempo dentro da empresa, uma pedra prestaria um melhor serviço.

Diga-me com quem andas…

Um dos conselhos que seguramente daria para qualquer pessoa com relação ao ambiente de trabalho é: sempre ande em boa companhia. Quando passamos muito tempo com as pessoas pegamos o jeito delas. Minha esposa viajou há muito tempo para o nordeste e, em uma semana, ela simplesmente não conseguia mais falar sem o sotaque local.

Fique junto de pessoas descontentes, amarguradas, que sempre arranjam desculpas para não estudar coisas novas, que não se esforçam no trabalho e as chances são de que você, no mínimo, vai ter um rendimento menor do que poderia. Ande com pessoas mais experientes, que gostam de aprender e almejam mais da vida e constantemente você será contagiado pelo desejo de progredir.

Conclusão

Eu poderia escrever uma enciclopédia com exemplos de como nossa mentalidade é deturpada por anos de uma cultura dualista entre burguesia e proletariado, que gera tensão constante entre esses dois “lados”. Ou ainda poderia discorrer sobre uma longa lista de conselhos específicos sobre ética comportamental. Porém, vou concluir desafiando o caro leitor com uma paráfrase de uma expressão que minha esposa usa comigo algumas vezes:

Você acha que tem potencial? Pare de reclamar e mostre o seu valor!

Seja um especialista

Carreira 6 Comentários

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

Carreira Deixe um comentário

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?

Carreira Deixe um comentário

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.

9 pecados capitais do planejamento de projetos

Carreira Deixe um comentário

MorteEm seu artigo Nine Deadly Sins of Project Planning, Steve McConnell nos apresenta uma forma bem interessante de reconhecermos um projeto mal planejado. O autor baseou-se em sua experiência para identificar os “pecados capitais” que frequentemente levam os projetos ao fracasso. Francamente, suspeito que ele andou visitando algumas empresas que eu conheço!

O que se segue abaixo é uma tradução um tanto informal do artigo, isto é, não muito ao pé da letra. Eis os nove pecados capitais do planejamento de projetos:

#1 → Não planejar nada

Um dos erros mais comuns. Não é necessário ser um especialista para planejar. Pessoas pouco experientes já o fizeram com sucesso simplesmente porque tiveram o cuidado de atentar para os requisitos do projeto.

Se tiver de escolher entre um especialista em planejamento que não pensa cuidadosamente sobre o plano e um iniciante na carreira, mas que analisa criteriosamente as necessidades do projeto, é melhor ficar com o último.

#2 → Não planejar todas as atividades necessárias

O pecado número 1 é não planejar, o número 2 é não planejar o suficiente.

Alguns planos de projeto simplesmente assumem que ninguém ficará doente, participará de treinamentos, sairá de férias ou deixará a empresa. Tais planos preparam o projeto para um desastre. Há inúmeras variações neste linha. Por exemplo, não incluir atividades auxiliares tais como criar instalação do software, conversão de dados de versões anteriores e outros tipos de tarefas por vezes irritantes que levam mais tempo do que gostamos de admitir.

Em alguns projetos que estão com o cronograma atrasado, tenta-se recuperar o prazo diminuindo o tempo que foi originalmente planejado para os testes. A justificativa é que provavelmente não haverá tantos erros como a princípio se pensava. Fica como exercício para o leitor imaginar por que então o tempo de testes já não foi menor desde o início.  😉

#3 → Não planejar considerando os riscos

Henry Petroski argumenta que os maiores desastres na construção de pontes ocorrem após períodos de sucesso que dão margem à autoconfiança. Os projetistas tornam-se complacentes e simplesmente copiam os atributos de uma ponte para outra sem atentar-se para os riscos em potencial da nova construção.

Em muitos projetos, a palavra “risco” não é mencionada a menos que estejamos com sérios problemas. Em projetos de software, se não estamos usando essa palavra cotidianamente e incorporando-a em nossos planos, não estamos fazendo bem nosso trabalho. Como disse Tom Gilb: “se você não atacar ativamente os riscos, eles irão atacar ativamente você”.

#4 → Usar o mesmo planejamento em todos os projetos

Algumas organizações familiarizam-se com uma abordagem para executar projetos. Ela é mais conhecida como “o jeito que nós fazemos as coisas por aqui”. As coisas costumam ir bem quando os novos projetos são bem parecidos com os anteriores. Mas, se aparecer algo diferente, essa abordagem vai causar mais problemas do que ajudar.

Um bom planejamento visa necessidades específicas do projeto para o qual ele foi criado. Muitos elementos podem ser reusados, mas deve-se considerar cuidadosamente se os elementos antigos se aplicam ao novo contexto.

#5 → Aplicar modelos de planejamento indiscriminadamente

Um planejamento que alguém realizou chega na forma de um livro ou metodologia e parece funcionar muito bem do jeito que está. Então usa-se este plano genérico indiscriminadamente sem pensamento crítico ou consideração pelas particularidades do projeto.

Exemplos conhecidos são o RUP (Rational Unified Process), o XP (Extreme Programming) e, até certo ponto, meu próprio “Guia de Sobrevivência a Projetos de Software” (Software Project Survival Guide). Esses planos “pré-fabricados” podem ajudar a evitar os pecados #1 e #2, mas não substituem nossa análise das demandas únicas do projeto.

Nenhum especialista externo pode entender as necessidades específicos de um projeto como as pessoas envolvidas diretamente nele. O plano de um especialista deve ser adaptado para as circunstâncias específicas. Felizmente, existem gerentes que estão atentos para esses problemas e usam o senso comum para selecionar as partes dos livros de Engenharia de Software que atendem suas demandas.

#6 → Permitir que o planejamento esteja divergente da realidade

Uma abordagem comum ao planejamento é criar o plano no início do projeto e depois abandoná-lo numa gaveta, juntando poeira até o fim projeto. Quando as condições mudam, o planejamento torna-se irrelevante e, no meio do caminho, o projeto anda sem rumo. Não há mais relação do planejamento com a realidade do projeto.

Isso pode estar relacionado ao pecado #5, pois quando alguém abraça uma metodologia pré-fabricadas algumas vezes torna-se relutante em mudar quando ela não funciona. Eles pensam que o problema está na aplicação, quando, na verdade, está no planejamento.

Um bom planejamento deve ocorrer e ser revisado incrementalmente em todo o projeto.

#7 → Planejar muito detalhadamente logo de início

Alguns gerentes bem intencionados tentam mapear todas as atividades do projeto logo no início. Mas um software consiste num constante desdobramento de decisões, cada fase gera novas pendências para decisões futuras. Como não temos uma bola de cristal, tentar planejar atividades distantes em detalhes é um exercício burocrático tão ruim quanto não planejar nada.

Quanto mais trabalho é despendido em criar planos prematuros, maiores são as chances do plano ser engavetado (pecado número #6). Mas ninguém gosta de jogar seu precioso trabalho fora, então o gerente algumas vezes tentará forçar a realidade do projeto para se encaixar em seus detalhados planos, ao invés de revisar o plano prematuramente detalhado.

Eu penso num bom planejamento de projeto como dirigir a noite com os faróis do carro ligados. Eu posso ter um mapa que me diga como ir da cidade A para a cidade B, mas a distância que posso ver com os faróis é limitada. Em um projeto médio ou grande, um macro planejamento pode mapear todo o projeto. Então micro planejamentos detalhados conduzem o projeto apenas algumas semanas por vez.

#8 → Planejar para correr atrás do tempo perdido

Em projetos que começam a atrasar, um erro comum é planejar para se recuperar depois, correndo para “alcançar” o cronograma. A racionalização típica é: “a equipe passou pela curva de aprendizado no início do projeto, nós aprendemos várias lições duras, mas agora que entendemos o que estamos fazendo devemos conseguir concluir o projeto rapidamente”. Resposta errada!

Uma pesquisa de 1991 em mais de 300 projetos descobriu que dificilmente projetos recuperam-se, pelo contrário, a tendências é atrasar ainda mais. O erro desse raciocínio é que a equipe de desenvolvimento toma decisões importantes no início do projeto, enquanto ainda está aprendendo sobre as aspectos tecnológicos, de negócio, e sobre as metodologias. Nas fases posteriores do projeto, o passo não irá acelerar, mas diminuir na medida em que são colhidas consequências de decisões iniciais erradas e então é necessário investir tempo corrigindo esses erros.

#9 → Não aprender com os “pecados” cometidos anteriormente

O pecado mais mortal de todos é não aprender com os pecados já cometidos. Projetos de software podem levar muito tempo e a memória das pessoas pode ficar enevoada pelo ego e pelo tempo. No fim de um projeto longo, pode ser difícil lembrar todas as decisões iniciais que afetaram sua conclusão.

Uma forma fácil de contornar essa tendência e prevenir-se de pecados futuros é conduzir uma autópsia estruturada do projeto. Uma revisão não vai apagar os pecados passados, mas pode certamente evitar mais erros futuros.

Página 2 de 3

← Anterior

Próxima →

Follow

State Of The Art Blog

Novos artigos por e-mail. Sem spam!

Acompanhe minhas respostas no Stack Overflow em Português.

Perfil de utluiz em Stack Overflow em Português, é um site de perguntas e respostas para programadores profissionais e entusiastas

Popular

Descubra

Categorias

Arquivos

Tags

agile ambiente de trabalho apostila apresentação automação boas práticas bootstrap css curso desempenho desenvolvimento profissional design patterns dica eclipse emprego engenharia de software estimação estudo estudo de caso framework web gerenciamento de projetos html5 javascript jquery maturidade maven meme monografia mythical man-month oracle play! framework programação python reflexões requisitos segurança sql server stackoverflow sysdeo tdd testes tomcat transação tutorial ubuntu linux

Social

Github LinkedIn Twitter Página do Blog no Facebook Google+

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.