TDD está morto?

Nesta semana o chão estremeceu após a declaração de David Heinemeier Hansson (@DHH), autor de livros como Getting Real, Rework, Remote, além do framework Ruby On Rails e do Basecamp, postada recentemente em seu blog, de que para ele TDD está morto. O texto original pode ser encontrado aqui.

Nos últimos anos quem busca estar sempre atualizado com as práticas modernas de desenvolvimento de software tem ouvido sempre que praticar TDD, ou seja, escrever testes unitários antes de escrever o código que será testado, deve ser uma prática obrigatória para se garantir a qualidade do trabalho realizado. Livros e livros foram escritos sobre o assunto, e provavelmente alguns mais ainda serão.

O desenvolvimento utilizando TDD é conceitualmente simples: Para cada método público que pretende escrever em cada uma das entidades que compõem seu software, escreva antes um ou mais testes unitários que entreguem a esse método algumas combinações de parâmetros de entrada, o executem e por fim verifiquem se o resultado de sua execução é aquele esperado para cada um dos conjuntos de parâmetros informados. Faça isso escrevendo primeiro os testes, em seguida, antes mesmo de escrever o conteúdo do método a ser testado, execute os testes para garantir que eles não estão indicando um falso positivo, em seguida escreva apenas o mínimo de código necessário para fazer com que aquele teste passe e por fim refatore o código para torna-lo mais claro e/ou eficiente. Ao terminar essa refatoração seus testes passaram novamente e você terá um indicador para lhe dizer caso alguém faça uma besteira e acabe alterando o comportamento do seu método.

Tudo muito lindo, até se colocar em prática. Na prática, é muito difícil determinar o que testar, além de a arquitetura e o desenho do software mudarem bastante à medida em que sua implementação evolui. E quanto mais granulares os seus testes, mais difícil será mantê-los atualizados. Sem falar no inferno de mocks, fakes e stubs que acabam sendo necessários para permitir que apenas aquele método, aquela unidade de código, esteja de fato sendo testada naquele momento, e não tudo que é executado como dependência a partir dela.

Diante dessas dificuldades, muitos desistem do TDD. Creio que a maioria desista, por elas e pela falta de disposição em aprender e treinar o calhamaço de novas habilidades necessárias para se praticar TDD. Em Janeiro de 2012 o maior advogado do TDD, Uncle Bob (@unclebobmartin), autor de livros como PPP, Clean Code e The Clean Coder, escreveu um artigo em que falava justamente sobre a mudança de posicionamento necessária ao desenvolvedor para que ele pudesse finalmente virar o bit e se tornar um praticante de TDD. Esse artigo pode ser visto aqui, e é um interessante contraponto ao que foi apresentado ontem pelo David.

Pelo que já coloquei acima, já da pra perceber que minha posição se assemelha mais à posição do David nesse caso. Sempre fui extremamente pragmático, e escrever quilos e quilos de mocks e testes para verificar o comportamento de um método que em poucos dias provavelmente nem existirá mais nunca ganhou minha simpatia. Estudei muito a respeito, ainda tenho livros na minha estante sobre o assunto que lerei em breve, mas nunca consegui assumir essa prática (TDD) como uma religião, como muitos tem feito e advogado que deve ser feito. No entanto, assim como David, não me coloco no outro extremo, não sou de modo algum um Programmer Motherfucker que quer apenas escrever código do jeito que bem entender, sem critério algum por que é isso que fazermos, programar. Não estaria me dedicando a este blog agora se fosse esse o caso.

A saída pra mim foi encontrada na verdade em um irmão mais novo do TDD (Test-Driven Development) o BDD (Behavior-Driven Development). Ao qual tenho me referido bastante ultimamente como Especificação por Exemplo.

Após Dan North (@tastapod) introduzir a técnica denominada BDD, muitos afirmaram que BDD não seria mais que TDD feito da forma correta, e a forma correta nesse caso seria dar ênfase ao comportamento a ser apresentado pelo software a ser testado, e não a um único método, uma única unidade de código. Neste link e neste link vemos respostas de Uncle Bob a esse tipo de afirmação.

Dando ênfase a um comportamento, favorecemos a modularização, damos um norte ao desenvolvedor, que pode ter liberdade para criar o desenho do software, tendo como parâmetro o comportamento descrito. Tal comportamento pode ser definido por ele mesmo, ou em conjunto com outros envolvidos, como testadores e analistas de requisitos, mas será no fim parte do código fonte do sistema, será compilado, traduzido para código e testado, num ciclo muito semelhante ao ciclo do TDD, no entanto sem a ênfase absurda à unidade. Serão testes maiores, mais lentos, integrados, embora não necessariamente end-to-end. É uma técnica que com certeza vale a pena conhecer. Obtém-se muitas das vantagens do TDD, sem trazer consigo a maioria de seus problemas.

Enfim, não vou me estender demais. Queria apenas aproveitar a polêmica do momento e escrever esse texto contrastando as duas técnicas e expondo minha posição a respeito do uso de TDD.

Recentemente fiz um trabalho acadêmico sobre o assunto: Melhorando a Eficiência no Desenvolvimento de Software através da Aplicação de Técnicas de Especificação por Exemplo. Tal trabalho pode ser encontrado aqui.

Módulos de Negócio vs Módulos de Infraestrutura

Módulos de Negócio versus Módulos de Infraestrutura. Essa é uma das discussões que me deixam mais empolgados quando o assunto é Arquitetura de Software. Mas antes de mais nada, uma breve revisão sobre o que são Módulos.

Um Módulo de Software pode ser visto como uma peça de software que implementa uma determinada especificação e realiza um determinado trabalho conforme especificado. Tais módulos podem ser compostos por um arquivo, uma classe, uma DLL, ou até mesmo um conjunto de DLLs, dentre outras possibilidades, desde que em conjunto esses artefatos implementem uma dada especificação e realizem um determinado trabalho conforme especificado.

Sempre que falamos em Módulos de Software, é comum alguém fazer a comparação com Módulos de Hardware, e gosto bastante dessa comparação. Um módulo de hardware, um componente eletrônico normalmente, pode ser facilmente substituído por um outro semelhante, desde que este outro implemente as mesmas especificações. Os demais módulos que interagem com aquele que for substituído se quer perceberão a mudança. E este seria o Santo Graal da modularização de software, poder simplesmente remover um módulo e substituí-lo por outro que implemente a mesma especificação, sem que os demais módulos reclamem da mudança.

Infelizmente isso ainda é uma realidade pouco comum. Arrisco dizer que a grande maioria das aplicações desenvolvidas no país, ainda que considerando apenas a pequena amostra a que tive acesso, são mal modularizadas e acabam mantendo um alto acoplamento entre seus módulos. E isso prejudica não apenas a possibilidade de fazer substituições de uma implementação por outra, algo que apesar de muito bonito não é tão necessário assim, mas também a definição das fronteiras do escopo de cada módulo, e é ai que está o grande prejuizo em modularizar mal uma aplicação.

De volta ao tema desta postagem, vamos supor que estamos trabalhando no desenvolvimento de um sistema em que há uma boa modularização, em que o papel de cada módulo está bem definido, o acoplamento está baixo e as fronteiras entre os módulos muito bem definidas.

Se tivermos essa realidade, será fácil identificar a separação entre Módulos de Negócio, aqueles que implementam exclusivamente funcionalidades específicas do negócio que está sendo automatizado pelo software, e Módulos de Infraestrutura, que implementam funcionalidades de suporte, drivers de acesso a bancos de dados ou sistemas de mensageria, ferramentas de log e auditoria, gerenciamento de usuários e tantas outras que estarão presentes, sem muita variação, em praticamente toda aplicação que viermos a desenvolver.

Módulos de Infraestrutura são componentes genéricos, reutilizáveis, que podem ter seu desenvolvimento e manutenção totalmente desacoplado dos sistemas que os utilizam. E ai está a grande vantagem em sermos capazes de fazer essa distinção. Quando baixamos um módulo como o Json.NET ou o FluentAssertions através do NuGet, recebemos uma peça de software pronta que apenas consumiremos. Por que não pode ser assim com os Módulos de Infraestrutura desenvolvidos pela própria equipe que consome esses módulos desenvolvidos por terceiros?

Pense que há na empresa em que você trabalha, e não há porque não haver caso você desenvolva aplicações .NET, um repositório NuGet privado, assim como uma política de Gestão de Reuso que defina que todo Módulo de Infraestrutura deva ser desenvolvido de modo independente das aplicações que os consomem, e que devam ser disponibilizados neste repositório uma vez que atinjam uma versão estável. Isso permitirá que esses módulos sejam utilizados pelas equipes de desenvolvimento da empresa, incluíndo as equipes que os desenvolveram, pois estas também deverão consumí-lo através do repositório NuGet, e não através de referências diretas a projetos da mesma solução.

Num cenário como este, teriamos uma solução limpa, composta apenas por Módulos de Negócio se referenciando entre si e consumindo, via NuGet, os Módulos de Infraestrutura que precisam.

Pensem nas possibilidades que um cenário como esse lhe proporcionaria. Pense em possibilidades como abrir alguns desses módulos como projetos Open Source, ganhando a contribuição de desenvolvedores de todo o mundo. Ou a vantagem de poder vender a seus clientes apenas o que realmente precisa e deve ser entregue exclusivamente a esses clientes: seus Módulos de Negócio. Afinal, se você pode consumir componentes de terceiros não relacionados ao negócio do seu cliente sem ter que fornecer a ele a propriedade sobre o código desses componentes, por que não poderia fazer o mesmo com o código dos Módulos de Infraestrutura que você mesmo desenvolve?

Por hoje era isso! Deixem suas opiniões nos comentários.

.NET Native

Recentemente tenho conversado com alguns colegas sobre as impressões que tenho tido ao ler Advanced .NET Debugging, livro que recomendo a todo desenvolvedor .NET que queira realmente entender como o framework funciona (mas ressalto que há uma nova edição no forno, do mesmo autor mas com outro nome, .NET Internals and Advanced Debugging Techniques).

Resumidamente, após entender como .NET funciona de verdade, analisando suas entranhas, percebemos que trata-se basicamente de um Assembly Loader, um JIT Compiler e um Garbage Collector (claro que estou sendo bastante simplista, mas é basicamente isso). Após carregados e JITados os programas .NET se tornam programas muito semelhantes a programas nativos, contando no entanto com o Garbage Collector para gerenciar a memória utilizada pela aplicação. Ainda assim, tudo está disponível para inspeção usando as mesmas ferramenta de debug nativo do Windows SDK, tanto que a passagem de objetos de e para aplicações nativas em tempo de execução é feita de modo bem direto, embora perca-se com isso a conveniência e segurança do Garbage Collector.

Uma vez JITadas, as aplicações .NET tornam-se código nativo, otimizado para o computador em que serão executadas, por isso a MSIL é distribuída nos assemblies ao invés de código nativo. No entanto, é possível gerar imagens nativas, pré-JITadas, dos assemblies e distribuí-las já prontas para uso, através da ferramenta NGen, já existente desde as primeiras versões do .NET, eliminando a etapa de compilação no momento do carregamento desses assemblies.

Essa contextualização é necessária para entender a estratégia .NET Native, anunciada em 02 de Abril de 2014. Tal estratégia consiste no uso de uma ferramenta que, resumidamente, irá pré-JITar as aplicações enviadas para distribuição pela Windows Store para todas as plataformas (modelos específicos de tablets, celulares e PCs) antes que seja feita distribuição para as máquinas clientes. Com isso, espera-se que tais aplicações tenham um carregamento 60% mais rápido, além de serem mais eficientes no uso de memória. Além da pré-compilação, também foram feitas algumas alterações na CLR para otimizar a execução de aplicações .NET Native. Bastante interessante, principalmente sabendo-se que o objetivo é estender de alguma forma esse benefício a demais aplicações .NET, não ficando restrito a aplicações da Windows Store.

Veja mais neste link.

Arquitetura de Microserviços e DDD

DDD já é velho conhecido de muitos desenvolvedores de software já há mais de 10 anos, no entanto o termo Microservices Architecture tem ganhado popularidade apenas recentemente.

Venho trabalhando em uma arquitetura de micro serviços, desenvolvida sobre o .NET Framework, já há quase 1 ano, desde antes da popularização do termo e até mesmo antes da publicação do Manifesto Reativo. No entanto, essa arquitetura tem se mantido desde o início bem aderente a esses dois conceitos.

Chamada aqui de Plataforma ST (nome real omitido), trata-se de uma arquitetura que permite que pequenos serviços de aplicação coexistam e se comuniquem entre si, de modo seguro, escalável e permitindo que novos serviços possam ser incluídos na plataforma a qualquer momento, complementando as funcionalidades já existentes. Note que não se trata de um único produto composto por múltiplos serviços relacionados, mas sim de uma plataforma de agregação de serviços. É possível haver uma instância da Plataforma ST agregando serviços de CRM, outra agregando serviços de ERP e outra para serviços de POS, cada uma dessas compondo um sistema distinto. Ainda assim, para cada uma delas, existe a possibilidade de se agregar novos serviços, incluindo alguns que sejam responsáveis exclusivamente pela interação entre esses diferentes sistemas.

Segundo as recomendações do DDD, módulos de um sistema, no nosso caso assemblies ou namespaces .NET, não devem conter no seu nome um nome de produto, mas sim a funcionalidade que ele provê, assim como devem conter como prefixo o nome da empresa que os desenvolveu. Assim, um módulo de gerenciamento de projetos ágeis desenvolvido pela empresa Contoso deveria ser nomeado com.contoso.agileprojectmanagement.applicationservice, de acordo com o que fora apresentado por Vaughn Vernon em Implementing Domain-Driven Design. No entanto, o padrão com.nomedaempresa se limita ao mundo Java, linguagem usada pelo autor para ilustrar o livro. Em projetos .NET, não há o costume de acrescentar o nome da empresa nos nomes dos módulos, e muito menos o prefixo com.

Ainda assim, poderíamos adaptar essa terminologia e nomear um dos nossos módulos de Contoso.AgileProjectManagement.ApplicationService, no entanto optei por usar ST.AgileProjectManagement.ApplicationService, e posso justificar essa decisão.

A Plataforma ST requer que os serviços desenvolvidos para executar sobre ela sigam um determinado padrão. Há uma classe abstrata ou no minimo uma interface que precisa ser implementada por todos os serviços, além disso eles precisam ser desenvolvidos levando em consideração o modo como a Plataforma ST irá gerir seu ciclo de vida. E mais, a Plataforma ST não é uma bala de prata, obviamente. Há cenários em que o mais interessante seja usar uma outra plataforma, ou desenvolver o sistema diretamente sobre o .NET Framework, já descartando os casos em que o próprio .NET Framework não seja a melhor opção.

Imagine por exemplo que seja desenvolvido na mesma empresa um sistema de colaboração, uma espécie de Wiki, que se adere aos padrões DDD mas não se encaixa na Plataforma ST. Esse sistema será desenvolvido de modo completamente independente dela, seus módulos serão totalmente incompatíveis. Agora seguindo a recomendação de usar o nome da empresa para determinar o nome dos módulos, teríamos algo como Contoso.Collaboration.ApplicationService, algo muito semelhante aos módulos dos sistemas desenvolvidos sobre a Plataforma ST, mas sem relação alguma com ela.

Por que não usar então Contoso.ST.AgileProjectManagement.ApplicationService? Ai vem um ponto em que discordo da recomendação do Vernon. Usar o nome da empresa, de qualquer modo que seja, na nomenclatura dos módulos, pode ser ruim e prefiro usar em seu lugar não o nome comercial de um serviço, o que concordo não ser recomendável, mas manter o módulo nomeado conforme sua função e prefixá-lo com um nome de projeto ao invés do nome da empresa. Seria algo que identifica todos os módulos que possuem algo em comum e cumpre a mesma função do nome da empresa na recomendação do livro.

Mas por que isso? Já trabalhei em uma empresa que mudou de nome, e via produtos legados com o nome antigo por todos os lados. Há casos de fusões e aquisições, em que o nome do proprietário do produto muda, e mesmo havendo motivações para manter o nome do desenvolvedor original mesmo que ele não exista mais, há o risco de novos módulos que integrem a mesma aplicação passarem a ser nomeados conforme o novo nome da empresa, o que geraria uma combinação de nomes de módulos não muito interessante.

Enfim, era isso que gostaria de compartilhar aqui e gostaria de ouvir a opinião de quem trabalha com DDD e já teve que passar por situações semelhantes às que descrevi. O que vocês tem a dizer?

"Apagão de talentos na área de TI? Que absurdo."

"Apagão de talentos na área de TI? Que absurdo."

Essa é a reação padrão de muitos profissionais de TI quando alguém diz que há um apagão de talentos na área de TI. Muitos verdadeiros talentos acreditam não estarem isolados, embora creio que a maioria se sinta assim. Já outros, talentos fajutos, que por alguma razão se consideram talentos natos mas que mal conseguiriam elaborar uma boa redação, se ofendem e partem pro ataque.

Não tenho em mãos dados estatísticos ou qualquer outra evidência forte de que esse apagão de fato exista, no entanto posso falar pela minha percepção. Já faz uns 8 anos que sou um dos responsáveis pela seleção de desenvolvedores e testadores de software nas empresas em que trabalhei nesse período, e o que observo é assustador. Sempre fui muito exigente e os exames de seleção que costumo aplicar refletem isso, no entanto sou criterioso o bastante para não exagerar e a impressão que fica é que a cada 10 que se candidatam, apenas 1 ou 2 merecem se quer serem considerados.

O mercado de TI nos últimos anos, em especial na área de desenvolvimento de software, tem se inflado cada vez mais de "profissionais" acomodados, que aprendem a fazer o básico, muitas vezes usando uma única tecnologia, uma única linguagem, um único framework, e mesmo assim escrevendo códigos de péssima qualidade mas que por já terem feito CRUDs por alguns poucos anos se consideram profissionais experientes. Há muitos profissionais de desenvolvimento de software no mercado, alguns são realmente bons e me daria orgulho os terem como colegas de trabalho, no entanto o que percebo é que são minoria (minoria no mercado como um todo, pois se considerar apenas os que participam ativamente das comunidades online de desenvolvedores creio que o número cresça bastante, pois apenas por estarem participando delas já podem ser considerados mais interessados pela profissão que os demais).

Portanto, o que penso é que há sim um apagão de talentos na área de TI, embora haja um excesso de profissionais disponíveis no mercado. E as más condições de trabalho e baixos salários pagos em alguns segmentos do setor em algumas cidades do país não servem como desculpa para o desapego e a falta de compromisso com a carreira que muitos demonstram. Pelo contrário, a baixa valorização pode até ser em parte justificada pelo excesso de maus profissionais, que aceitam qualquer condição de trabalho, desde que não exijam muito em troca.

Enfim, se quer saber o que eu espero de um profissional, veja este link e este link.

Arquitetos de Software na Era da Agilidade

Atualmente tenho trabalhado como arquiteto de software e também como ScrumMaster em um time Scrum. Estamos desenvolvendo um projeto bastante complexo, onde temos na mesma equipe desenvolvedores de software, engenheiros, desenvolvedores de firmware e até mesmo desenvolvedores de hardware. Trata-se de uma única equipe de mais de 10 pessoas, e quem já tem experiência no assunto já pode imaginar que não deve ser nada fácil tocar um projeto como esse, principalmente se acrescentar que esta é a primeira experiência com Scrum para a maioria dos integrantes da equipe, e também meu primeiro projeto como ScrumMaster.

Estou escrevendo isso porque hoje tive contato com um artigo, escrito por Stravos Kontopoulos, que trás não apenas uma excelente definição das responsabilidades de um arquiteto de software como também destaca os principais desafios de um arquiteto de software em um projeto ágil. Achei fascinante, pois a realidade que vivo hoje é muito bem descrita por ele.

Segundo Stravos,

Arquitetos de software, para serem bem sucedidos, devem possuir diferentes habilidades: habilidades técnicas, habilidades gerenciais, habilidades de liderança.
A razão por trás disso é que eles são a interface para muitos grupos dentro da organização: desenvolvedores, interessados do negócio, engenheiros de operação, testadores, marketing, conselhos, etc. 

Habilidades técnicas são uma necessidade para uma arquitetura válida, servindo os propósitos do negócio de acordo com as necessidades atuais e futuras. Além disso, habilidades técnicas destacadas garantem que a tecnologia está sendo aplicada da maneira correta.

Um conjunto de habilidades gerenciais é essencial. Entregar um produto/projeto dentro do tempo/orçamento é de grande importância e um arquiteto de software é normalmente assistido por um gerente de projetos responsável por essa tarefa. O aspecto chave aqui é que o arquiteto de software sabe melhor como priorizar o trabalho, sabe melhor determinar riscos para o cumprimento dos requisitos do projeto/produto de acordo com sua perícia em software. A atual execução do gerenciamento pode ficar por conta do gerente de projetos, que também monitora os recursos/riscos em maior detalhe.

Acima de tudo, todo arquiteto de software deve ser um construtor de equipes. Frequentemente essa não é uma tarefa fácil. Pegar as pessoas certas, que frequentemente não são de sua escolha, manter o equilíbrio dentro do time, gerenciar as expectativas e a produtividade das pessoas, e eventualmente liderar o time é de vital importância. É como conduzir uma orquestra. Se você não fizer isso direito, o resultado será ruim, mesmo que tenha os melhores músicos.

Posso dizer que essa foi a melhor descrição para a função de um arquiteto de software que já encontrei. Reflete exatamente os desafios que encontramos no dia a dia, e as responsabilidades que temos que assumir. Quem pensa que ser um arquiteto de software é sentar a bunda na frente do Enterprise Architect e passar o dia desenhando diagramas (coisa que, como arquiteto ágil, raramente faço), está muito enganado.

Na sequência, Stravos fala sobre o papel do arquiteto de software em uma equipe ágil:

Na era da agilidade, em que não há tal coisa como uma arquitetura estável pré-definida, desenvolvedores devem trabalhar próximos ao arquiteto de software, monitorando a evolução da arquitetura.
Isso quer dizer que desenvolvedores também devem ter alguma habilidade com projeto arquitetural, de modo a fazer parte da evolução da arquitetura, sendo capazes de compreendê-la efetivamente. Um arquiteto de software não é capaz de estar ciente de todos os detalhes de um produto de software, mas deve estar ciente de cada decisão ou restrição que possa fazer a arquitetura se tornar inconsistente ou se desviar de sua tendência inicial.
O arquiteto de software, por sua vez, deve estar próximo de seu time, auxiliando-o durante as iterações de desenvolvimento, e por isso deve estar acostumado à codificação e codificar até um certo nível.

Muito frequentemente, um trabalho negligenciado é a documentação das arquiteturas. Isso pode ser parte de uma tarefa ágil em que a documentação é refatorada a cada iteração que também modifique a arquitetura.
Esta é a única maneira de se saber quais caminhos arquiteturais você está seguindo e ser capaz de apresentar aos interessados que você de fato sabe, e que eles possam ver através de seus olhos, o que você está construindo.

Confira o artigo completo neste link.

Uma retrospectiva pessoal dos últimos 3 anos!

O ano de 2013 foi um ano realmente produtivo pra mim. Concluí projetos pendentes, iniciei novos projetos, atingi objetivos profissionais, encarei novos desafios, e isso tudo é devido fortemente de uma mudança de atitude que ocorreu ao final de 2011.

Há algum tempo recebi um conselho que considero o mais importante que já recebi: "não invista demais em sua mente se esquecendo de cuidar também do seu corpo, pois um não vive sem o outro". Na época eu passava por alguns problemas de saúde devido basicamente ao estresse e ao sedentarismo, e esse conselho me fez abrir os olhos e perceber que de fato eu estava investindo demais em qualificação e deixando de lado o lazer, a saúde e o bem estar, algo considerado normal nos dias de hoje. Isso foi em meados de 2009, e de lá pra cá passei a dar muito mais atenção ao meu bem estar e principalmente à minha saúde.

Decidi, a partir de então, estudar menos, deixar as coisas evoluírem mais devagar, usar um pouco o produto de tanto investimento antes de investir mais. No entanto, isso me fez perceber que a qualidade do investimento que eu havia feito até então não era bem o que eu esperava. Ainda me sentia despreparado, ainda havia dúvidas que eu precisava responder para me sentir maduro profissionalmente.

Como então equilibrar as coisas? Voltar a estudar, produzir mais e melhor, e ao mesmo tempo não passar pelo estresse absurdo em que vivia?

Primeiramente, mudei de emprego, pois vinha de lá a grande fonte de estresse pelo qual eu passava. Mais que isso, pedi demissão sem nem mesmo ter outro emprego. Decidi ter férias prolongadas, esquecer completamente os compromissos e as consequências, passei dois meses apenas descansado, e por fim retomei os estudos.

Fiz uma breve pesquisa de mercado para entender o que eu precisaria aprender de novo, em que eu precisaria me reciclar, escolhi alguns livros, e passei a me dedicar a eles. Isso aconteceu em meados de 2011.

Era hora de voltar à realidade. Pesquisei um pouco a respeito de algumas empresas de Belo Horizonte onde eu gostaria de trabalhar e fiz contato. Destas, nenhuma oportunidade surgiu, ao menos não nas semanas iniciais, mas para minha surpresa recebi uma ligação de uma outra empresa, até então desconhecida por mim, que havia recebido uma indicação de alguém para me contactar, pois eu seria a pessoa certa para resolver o problema pelo qual eles passavam naquele momento. Fiz contato numa quinta feira, e no dia seguinte já havia sido contratado. Parecia mesmo urgente o problema rs.

Em um novo ambiente, livre do estresse de antes, encontrei espaço para buscar os novos desafios que precisava para me manter motivado.

Em paralelo a isso, passei a investir mais em saúde, o sedentarismo crônico ficou para trás, embora sempre passe de vez em quando para dar um oi. E a ideia de pesquisar o que eu previsava aprender, em que eu precisava investir, foi um ótima ideia. Aprendi muito com os 6 primeiros livros que escolhi, e vi que esse seria um ótimo caminho, muito mais produtivo que a participação em cursos e a leitura de blogs e mais blogs, os quais eram minha principal fonte de informação até então.

Apenas no segundo semestre de 2011 li 6 livros, um recorde para quem era acostumando a ler não mais que 1 ou 2 livros por ano, se muito. Em 2012 a produção já foi mais baixa em números, mas não em valor. Ao final do mesmo ano, diante do desafio de produzir um trabalho de conclusão de curso que demandaria bastante pesquisa, decidi tornar a leitura uma atividade mais frequente, e decidi que faria isso sem prejudicar as demais atividades do meu dia a dia. Qual a solução? Não mais que míseros 30 minutos de leitura diária, antes de dormir, principalmente. Com essa estratégia, consegui concluir, supreendentemente, 15 livros técnicos no ano de 2013. Isso enquanto fazia um curso de pós graduação, que me exigia em média 1 hora por dia de dedicação.

Hoje tenho tempo para me dedicar ao meu bem estar, e em 2014 talvez invista menos em qualificação, mas certamente com muito mais qualidade que nos anos anteriores a 2011. Ao que tudo indica, será um bom ano.