Pular para o conteúdo principal

Devemos registrar nossos erros

Hoje eu estava assitindo este TED e uma coisa no discurso da Catarina me chamou a atenção. Foi com relação a como os inventores/cientistas de fundo de garagem tem o hábito de regitsrar tudo o que fazem na internet. Não pelo fato disso estar aberto, coisa que a comunidade de software já tem feito a um bom tempo. Mas muito mais pela parte do "tudo". Pois isto é algo que me chama muito a atenção.
Na apresentação ela deixa claro que estes caras não se restringiam a reportar o que deu certo, mas também aquilo que deu errado. Dessa forma, quem está começando já fica alertado de como evitar alguns erros comuns no caminho. Algo que é de grande valia, pois apenas reportar o que dá certo é extremamente restritivo. Tudo bem que essa abordagem indica o caminho mais seguro, mas coloca você dentro de amarras impedem de se experimentar novos caminhos. Conhecer caminhos errados te ajuda a explorar com menos medo estas alternativas.
O que me impressiona nisto é que falar sobre os caminhos que dão errado é bem raro. No meio acadêmico então,  isso é um imenso tabu. Lembro-me bem do Mestre Qui Gondim (meu orientador da graduação) dizendo que não se devia publicar falhas que não se conhece as correções. No mercado temos visto um movimento pra mudar um pouco o medo de se falar sobre os erros. Como tem feito o pessoal da FailCon. Mas ainda assim, é algo bem embrionário. A galera de código tem o StackOverflow funciona como uma imensa base de coisas que deram errado (e suas soluções). Mesmo assim, sinro falta de ver mais posts (ou mesmo livros) sobre caminhos errados.
Eu sei da existência dos "Livros Negros do XXX" e outros afins. Gosto muito deles, mas são poucos e estes buscam manter na fórmula de indicar caminhos certos (junto com os errados). Reforçando ainda mais que não devemos nos restringir apenas no caminho que já conhecemos. Nosso objetivo deve ser buscar um maior aprendizado, mesmo de experiências soltas. Afinal, como o Alê certa vez me disse : "Alguma informação ajuda mais que nenhuma informação.".

Postagens mais visitadas deste blog

A experiência de software

Hoje em dia está muito em voga se falar sobre o desenvolvimento de produtos e serviços de software. Sendo assim as iniciativas e startups estão alta. Mas para quem está no mercado de Brasília (e de alguns outros centros do país) como eu, sabe que a prestação de serviços nas famigeradas "Software Houses" ( me recuso a chamar de Fábricas de Software ) é bem comum. Porém, este trabalho costuma ser renegado ou, como eu vejo, tratado sob um ponto de vista um pouco equivocado. Uma fábrica de software artesanal Onde se enganam tais pessoas é em que elas estão vendendo. Muitas empresas acreditam, de fato, que vendem software. Eu porém digo que isso é não de todo verdade. Se você é um prestador de serviços e constrói software sob demanda, você não vende apenas o software. Aqui não me refiro aos milhões de outros "artefatos" que são empurrados goela abaixo entregues aos nossos clientes. O que vejo é que vendemos algo que não está limitado ao software que vai pra mão (ou se

TDD como ferramenta de aprendizado

Na penúltima sessão do DojoBrasilia surgiu a seguinte questão: Será que o TDD não atrapalha no aprendizado de novas tecnologias?  A grande questão girava em torno de que o respeito estrito as regras ao TDD tornariam o aprendizado lento e enviesado. Isso por que você estaria focado em passar o teste o que estaria limitando sua velocidade no aprendizado na tecnologia, bem como a visão do objetivo final. Caso do dojoBrasília No caso da sessão que levantou a questão acho que o principal sentimento de "lentidão" se deve a grande carga de tecnologias novas que estavam envolvidas. Escolhemos iniciar um problema conhecido em não uma, mas várias tecnologias ( Backbone.js , Undescore , CoffeeScript , Jasmine , etc). Ao final da sessão a sensação de pouco avanço era justificada pelo tempo gasto compreendendo as tecnologias em questão. A sessão seguinte não obteve o avanço que muitos esperavam. Mas nela podemos ver como o uso de TDD compensou. Tínhamos apenas 4 cas

Formando pessoas desenvolvedoras na bxblue

Eu sempre fui apaixonado por ensinar. Trabalho com a formação e ensino desde 2003, indo desde o ensino das bases de computação até lecionar em cursos de pós-graduação. Estar no dia-a-dia com pessoas que estão no começo da carreira é um mix de satisfação e desafio. Satisfação por você ter a oportunidade de contribuir com um pedacinho tão especial da história daquela que será uma pessoa desenvolvedora no futuro. Desafiadora pelo fato de precisarmos nos despir de aprendizados já superados em nossas mentes e nos esforçamos por enxergar novamente pelos olhos de quem ainda não tem a mesma vivência que você. Por onde passei, eu sempre acreditei que um bom equilíbrio entre profissionais experientes e em formação é a melhor combinação para um time de tecnologia. Isso é benéfico não apenas para a retenção, como também é estímulo para uma cultura de aprendizado e humildade. Cultura essa que favorece o compartilhamento e interação não apenas entre quem faz o software, mas também as demais áreas da