Category Archives: armadilhas

Stack Overflow pode te emburrecer?

Já faz um tempo que planejo escrever sobre educação, mais especificamente sobre a forma como nós, programadores, nos educamos. Como alguém que se encontra do outro lado da mesa agora – como contratante – creio que é interessante compartilhar aqui minhas impressões e descobertas sobre este assunto.

Vou começar por descrever uma doença que observo em nossas consultorias e, principalmente, nos processos seletivos que realizo tanto para a Itexto quanto para nossos clientes. Chamo esta doença de “emburrecimento por Stack Overflow”. Poderia usar o termo “fórum”, mas dado o sucesso do site, noto que seu nome se tornou uma espécie de sinônimo para “fórum”.

Como aprendemos

Para entender esta doença é necessário começar pensando o modo como aprendemos as coisas, especialmente as complexas, tais como programar. Tudo tem seu início nos conceitos mais simples.

Você começa a partir do clássico “Olá mundo”. O computador irá imprimir textos aleatórios na tela de acordo com aquilo que você definir em seu código fonte. Isto te fornece a ideia (e experiência) do conceito fundamental de comando. Você, humano, enviando instruções para o computador e este te respondendo, no caso, imprimindo algo na tela (ainda me lembro da minha primeira impressão desta experiência, e foi linda!).

msx_oiMundo

Após ter enjoado de todas as variações daquele comando elementar você começa a brincar com operações matemáticas, condicionais, loops, entrada e saída por teclado. Entra a lógica de programação mais básica: começam os códigos mais simples, tais como nossas primeiras funções de soma, talvez algo um pouco mais avançado, como a implementação de um Fibonacci, coisas assim.

Com o tempo adquirimos segurança e começamos a pensar em reuso: surgem as funções melhor elaboradas (uma função chamando outra), você começa a se preocupar com a qualidade do código que vai escrever, pois nota que aquele negócio vai ficando mais complexo conforme evolui. E aí entram as noções de programação procedural, que em pouco tempo irão evoluir para módulos (se estiver experimentando BASIC ou Pascal na faculdade).

smalltalk

Os módulos no futuro se transformarão em classes e objetos, e você começará a modelar sistemas orientados a objetos, a complexidade aumentou, o código começa a ficar bem mais difícil de ser mantido e você busca por soluções que outros tenham adotado para contornar estes problemas. É quando nos deparamos com padrões de projetos, frameworks, bibliotecas…

(se vir por aí alguém dizendo que programar é fácil, já te adianto: é picareta que tá tentando te vender curso ou livro)

Este é um caminho possível e, na minha opinião, o melhor. É o conhecimento sendo construído em camadas. Primeiro você monta uma camada bem simples (os comandos), se sente à vontade com ela, constrói outra (as funções), e outra (reuso), e outra (módulos) e outras (orientação a objetos), e outras (frameworks, bibliotecas) e outras (pensa em arquietura) e outras…. E por aí vai.

grandcanyon

E é por isto que bons professores e livros são tão importantes: se suas primeiras camadas forem mal construídas fica muito mais difícil se reprogramar e apagar impressões erradas. Na minha experiência enquanto contratante e tutor fica claro que os pupilos que melhor se desenvolvem normalmente são aqueles que baseiam seu conhecimento em um guia com começo, meio e fim bem definidos.

(Você sabe a diferença entre pupilo e estudante? O primeiro requer atenção continuada por parte do tutor, o segundo se vira por conta própria)

A importância do guia

Chamo de guia uma sequência de conhecimentos que são passados ao pupilo. Sequência esta que, naturalmente, começa pelo mais elementar, mas provê a base para que os novos conhecimentos (as camadas) possam ser adquiridos.

Este guia pode ter as mais variadas formas: um professor, um livro, vídeo aulas, uma série de artigos. O essencial é que começo, meio e fim sejam bem definidos e, mais ainda: que cada camada forneça a base para que possamos dominar a próxima. O bom guia torna claro a conexão entre as camadas.

(talvez a metáfora das camadas não seja a melhor, pois o conhecimento pode ser não linear, entretanto sempre há um ponto que segue o outro, mesmo que surjam bifurcações, sendo assim a ideia de sedimentação como base para elevar o conhecimento funciona no final das contas)

Ainda mais importante: o guia te diz aonde você irá chegar. Há um objetivo bem traçado: você sabe exatamente aonde deveria estar no final da jornada. E como você sabe que o caminho está certo? Simples, aquele objetivo que parecia distante de repente começa a se mostrar cada vez mais factível, de repente escrever seu próprio sistema operacional, linguagem de programação, website ou sistema de controle de armas nucleares começa a se tornar mais fácil ou pelo menos mais viável de ser realizado por você.

E como você sabe se o caminho está sendo bem trilhado? Simples: a partir da segunda camada de conhecimento, você pode verificar se o que está sendo dito é válido ou não checando aquilo que aprendeu no passo anterior. E se neste momento surgirem dúvidas que serão repassadas ao seu guia, o melhor sinal possível acaba de ocorrer: você está questionando, e se está questionando, é por que está pensando.

Após n camadas, o pupilo começa a perceber novos horizontes, novas fontes de conhecimento. Neste momento ele pode largar seu guia atual e buscar outras fontes de conhecimento. É quando o pupilo se torna estudante.

(no final das contas, o conhecimento sempre se dá a partir de conexões que criamos entre aquilo que está chegando (as novas camadas) e aquilo que já conhecemos (as camadas que sedimentamos))

Aí chega o Stack Overflow e ferra tudo

pollock_1_1949

Não me entenda mal, eu gosto do Stack Overflow, mas não como ferramenta de aprendizado. Infelizmente o problema que observo tanto em consultorias quanto em processos seletivos é que o indivíduo não usa fóruns como fonte secundária de conhecimento, mas sim primária. Explico melhor.

Você em uma sala de aula (virtual ou não): primeiro aprendemos com o guia. Em seguida, comentamos aquilo que aprendemos com os colegas ou mesmo diretamente com aquele que nos guiou até aquele ponto. Há um momento inicial essencial ali: o recebimento da informação e, posteriormente, a confirmação do conhecimento, que se dá normalmente em duas fases:

  1. O indivíduo reflete sobre aquilo que foi dito.
  2. Se não ficou claro após ter refletido (e experimentado) o que foi dito, interage com o guia ou seus colegas ou o mundo buscando entender ou confirmar aquela informação.

Agora: e quando você inverte a ordem? E quando quer criar um sistema de gestão mas não sabe programar? No Grails Brasil, por exemplo, já vi muitas dúvidas que seguem mais ou menos esta forma:

E aí pessoal, tudo bem?
Seguinte: quero criar um sistema de controle para minha padaria. Preciso então saber como, em Grails, eu faço para, me conectar ao banco de dados e persistir os dados para que eu possa gerar meus relatórios gerenciais.

Note: a pessoa sabe que existe uma ferramenta que pode ser aplicada para se atingir o objetivo traçado, mas ela não buscou conhecê-la em um primeiro lugar. Ao invés disto, buscou primeiro o auxílio dos colegas. Naturalmente a frustração irá ser o resultado final desta investida (e não raro a pessoa odiará o framework e sua comunidade até o fim dos seus dias).

Outra situação bastante comum: você precisa integrar seu sistema com alguma tecnologia, um hardware qualquer, por exemplo. Entra no Stack Overflow, busca por algo do tipo: “como ler dados de uma porta serial com Java”.

Encontra uma discussão que tem algum código fonte de exemplo. Copia para o seu projeto pessoal, altera um pouco aquele código fonte e a coisa funciona. A solução para o problema imediato está ali: a questão foi resolvida. Mas e no segundo (e terceiro, quarto…) momento, no qual é necessário entender por que a coisa parou de funcionar?

Tá, você poderia me dizer: “mas Kico, tudo em demasia faz mal, basta usar com sabedoria e bla bla bla bla bla”. O problema é que na esmagadora maioria das vezes noto as pessoas usando em demasia, o que mostra que há algo extremamente errado conosco e a maneira como estamos buscando conhecimento.

O conhecimento baseado em fóruns não passa de uma simples tentativa e erro. Talvez você encontre algo que te atenda, mas sem ter a base, jamais terá a certeza do seu funcionamento. No máximo sabemos que a coisa funcionou naquele caso.

(quanto ao Stack Overflow, confesso que detesto o próprio formato da coisa, que não promove discussões, mas sim uma forma extremamente rudimentar que visa apenas sanar dúvidas imediatas. Já escrevi sobre isto aqui)

O problema tá na web

Quando a Internet se popularizou me lembro bem que todos pensávamos que a partir daquele momento não haveria mais ignorância pois o conhecimento estava todo lá, acessível a qualquer um (que tivesse acesso à Internet). A impressão que tenho hoje é a de que na realidade a ignorância aumentou. Creio que a culpa esteja no link.

Sou da geração pré-internet: quando ela apareceu eu devia ter lá pelos meus 15 anos. Na minha época o guia não era uma alternativa, era minha única opção. Você não tinha dinheiro para comprar vários livros, então comprava um e, como um disco ruim, lia e relia várias vezes caso não tivesse gostado. E aquela leitura do início ao fim (mesmo que não necessariamente na ordem proposta pelo autor) nos obrigava a trilhar um caminho, a sedimentar camadas.

E sabe o que é interessante? Muita gente aprendia a programar pelo help das linguagens de programação (VB, Delphi, PowerBuilder), e normalmente os que se tornavam melhores eram justamente aqueles que haviam estudado horrores seguindo um guia, e não os links dos arquivos de ajuda. (o help de ontem era a web de hoje)

Na web a coisa é diferente: você começa a ler um texto e de repente topa com um link. Clica nele, e vai para outra página, e depois outra, e outra, e outra. No final das contas, o guia sumiu. Em seu lugar entrou um processo que, no frigir dos ovos, não passa de tentativa e erro. Se tiver dado muita sorte, continuou no mesmo assunto que iniciou sua pesquisa.

E ainda mais interessante: com os motores de busca você diz o que precisa saber naquele momento (“como renderizar um cubo em OpenGL”). E sem base alguma você topará com uma resposta em um fórum, contendo aquele código fonte perfeito, que basta copiar e colar para o seu projeto.

A ideia da teia (web) nos remetia a uma certa harmonia, mas na prática o que temos é uma daquelas teias feitas por aranhas que se encontram sob o efeito de narcóticos. Você não sabe o que vai encontrar, nem se aquilo que encontrou de fato resolve seu problema.

webondrugs

E para piorar a situação há a pressão do dia a dia. Seu chefe quer a solução na hora, você tem pouco tempo para resolver o problema. A web está ali: basta realizar uma busca, basta alterar um pouquinho aquilo que obteve na sua pesquisa… basta que o negócio funcione!

Pressa, informação fragmentada, falta de bases bem consolidadas… talvez esteja aí a base para que tantos livros técnicos e cursos online ruins estejam sendo criados.

Então o que faço?

Só tem uma solução: é encontrar um bom guia, por a bunda na cadeira e ler a coisa do início ao fim. Aliás, é importante saber ler também: não raro somos analfabetos funcionais (sobre como ler e minha própria história envolvendo este problema, veja este link).

Fóruns só servem como fonte secundária de conhecimento e troca de impressões a respeito de algo. Eles podem promover maravilhosas discussões e você aprender horrores com elas? Com certeza, basta lembrar de como era o GUJ em seu início. Entretanto, tal como Aristóteles, creio que para que haja uma discussão enriquecedora é fundamental que todos os participantes antes de mais nada saibam sobre o que estão falando.

E pra usar o fórum portanto… você primeiro vai ter de ler seu guia. Hegel tinha um bom nome para a cura deste problema: “paciência do conceito”.

Não tem como: você precisa ser paciente se quiser aprender algo. Ficar pulando de resposta em resposta dificilmente te fornece alguma base.

PS:

_ Mas e se eu não gostar de ler?
_ Se acostume com a mediocridade, pois você dificilmente sairá dela.

Eu e os livros técnicos: sou exigente?

Após ter escrito meu último post algumas(muitas) pessoas me disseram que sou muito exigente e que se há livros ruins sendo vendidos, isto ocorre por que há quem os compre. São pontos realmente interessantes, e que levantam uma série de questionamentos – ao menos para mim – no mínimo fascinantes.

Primeiro algumas coisas que eu devia ter tornado mais claras no post anterior

De novo sobre a importância da bibliografia

Ouvi algumas vezes a seguinte frase: “realmente, bibliografias são ótimas para que possamos nos aprofundar no assunto”. Creio que não fui claro o suficiente, então direi agora: a bibliografia mostra que o autor realmente estudou.

Recentemente peguei um livro técnico que tinha exatamente quatro referências bibliográficas. Este autor realmente estudou? Solto então um parâmetro de avaliação que nunca me falhou:

A qualidade de um livro técnico é diretamente proporcional ao tamanho de sua bibliografia.

Resumindo: bibliografia não é feature, mas sim requisito fundamental.

O peso da responsabilidade

As pessoas levam muito a sério o que leem nos livros. Não raro consideram como referência imediata o(s) autor(es) daquilo que compram. A razão por trás disto é simples, como bem dizia um antigo professor meu (José Henrique Santos, lá na FAFICH) que parafraseio agora:

A mentira existe por que as pessoas esperam ouvir a verdade.

Se o livro foi publicado, o que o leitor espera? Que ele tenha sido bem editado, que o autor tenha se preparado para realizar o trabalho de transmissão de conhecimento, que tenha sido realizado um bom trabalho de revisão, que a editora tenha bem selecionado o autor que irá publicar. Há uma relação de confiança imediata aqui.

Resumindo, visto que você, como autor, será levado a sério e suas palavras guiarão o leitor em sua vida profissional (podendo gerar grandes prejuízos), se a editora for incompetente em seu trabalho ou o autor um aventureiro, estamos lidando com perigosos irresponsáveis.

(sim, você leu bem: estou te chamando de fanfarrão)

Autor e editora são responsáveis pelo trabalho de merda que podem produzir, e acho tristíssimo o fato de ser uma das poucas pessoas que levantam esta questão aqui, mas talvez eu seja uma pessoa exigente demais…

Sou um sujeito exigente?

Pouca gente lembra hoje, mas minha vida profissional começou literalmente entre livros. Eu era livreiro (vendia livros), depois o primeiro produto comercial da itexto foi um ERP vertical para Livrarias, Editoras, Bibliotecas e Distribuidoras de Livros (Plataforma Livreiro) e, no meio do caminho fiz o curso de Filosofia (pasme, pensando em vender mais livros), cuja parte prática é essencialmente o esforço de pesquisa necessário para que livros possam ser escritos e depois publicados.

livreiro_sm

Resumindo: conheço de ponta a ponta o processo que se inicia na pesquisa, evoluí para a escrita, trabalho editorial, comercial e posterior conservação e manuseio do livro que você comprou e guarda em sua prateleira. Este é meu aspecto bibliófilo.

Na outra ponta sou também um empresário que contrata programadores, e que fica horrorizado a cada processo seletivo com a baixíssima qualidade da formação que as novas gerações estão obtendo. Formação esta que vêm não só dos cursos, mas também daquilo que se lê, daquilo que se vê e ouve em eventos.

(tenho um post quase pronto com o seguinte questionamento: como saber quem nos forma?)

Sendo assim, dado que conheço tanto o esforço necessário para se escrever um livro de qualidade (diga-se de passagem, escrevi dois) quanto das consequências de más publicações para o leitor, digo que não sou um leitor exigente, mas sim…

Alguém agindo de forma ética ao não se omitir em relação a algo que sabe trazer problemas imensos para nossa área.

“Há livros ruins por que há quem os compre”

Serei curto e grosso: esta afirmação é covarde e desonesta.

Covarde por que livra da culpa maus autores e editoras e a transfere ao consumidor. Se “esquece” que, tal como disse acima, o leitor ao adquirir um livro espera qualidade e só descobre depois (se tiver sorte) que comprou merda.

Desonesta por que tira das editoras e autores a responsabilidade de formar o leitor, lhe fornecendo as ferramentas necessárias para que possa avaliar o material antes de comprá-lo. Tira-se proveito da confiança do leitor.

Quem afirma este absurdo se esquece (ou omite) algo essencial: leitura é formação, e formação não é um produto cuja qualidade “possa” vir em diferentes níveis. Formação molda mentes, define seu futuro.

(por que não permitimos que um médico irresponsável nos opere mas não gritamos quando nossos filhos tem contato com maus professores e livros?)

A qualidade do livro técnico surge no autor, é validada pela editora e transmitida ao leitor. Este, o elo final da processo, deve ser acostumado não a consumir bobagens, mas sim material de qualidade para que, por sua vez, ao ser bem formado, possa ter o ferramental intelectual para detectar trabalhos ruins, minimizando assim o risco de que sejam publicados.

(Meu medo de um mundo sem editoras é justamente a proliferação de livros muito ruins, o que acabaria por ferir mortalmente a importância do livro técnico em si. Tutoriais e apostilas jamais deveriam substituir o livro.)

E aqui cabe algumas perguntas: se o mercado possibilita publicações ruins, quem ganha com isto no curto, médio e longo prazo? Qual o maior benefício (sempre há pelo menos um) em termos técnicos ignorantes? Por quanto tempo conseguiremos nos manter enquanto incentivamos a ignorância da nossa mão de obra?

Culpar o mercado ou o crítico é omissão

Material ruim ser publicado é um sintoma de algo mais grave: uma má formação geral  assolando nossa área. Não é apenas “ah… tem gente que gosta, por isto é vendido” ou “este cara é muito chato, tem muito livro vagabundo que quebra o galho e bem”.

Se o livro técnico é ruim, não temos uma editora pilantra e um autor picareta (na maior parte das vezes). Temos gente com formação ruim (aonde jamais poderia haver), que realmente acredita estar fazendo algo de qualidade e que valha à pena para seus leitores.

Os leitores, por sua vez, que serão as pessoas formadas por este conteúdo, acidentalmente acabam crendo naqueles que não sabem. Pieter Bruegel ilustrou bem esta situação no século XVI ao pintar a parábola dos cegos.
blind-leading-the-blind-by-pieter-bruegel-the-elder

PS:

O leitor tem lá sua parcela de culpa ao comprar livros ruins? Creio que dependa de sua formação. Mesmo que tenha lá sua fatia, com certeza é a menor: o aluno para criticar seu mestre precisa primeiro saber o que é bom.

Eu e o empreendedorismo do palco

Em janeiro de 2015 Nanna e eu oficializamos a itexto: foi um dos momentos mais legais da minha vida pois um sonho (O sonho) muito antigo finalmente estava se concretizando. Setembro de 2016 está chegando e de lá pra cá já atendemos quase 30 clientes, formamos uma quantidade enorme de pessoas nas tecnologias que dominamos e as coisas caminham bem.

Caminham bem agora, após 16 anos de incontáveis tentativas, a esmagadora maioria fracassada devido à minha arrogância e ignorância. No meio do caminho decidi reduzir minha ignorância partindo para o mercado e buscando trabalhar com aqueles que fossem mais experientes que eu. Venci a arrogância ao reconhecer que pra comandar meu destino primeiro tenho de ter sido comandado.

Este investimento se pagou: observando os erros alheios (sempre os mesmos) pude chegar a algumas teorias que, finalmente, ao colocar em prática se confirmaram e o negócio começou a caminhar, o que se confirma no crescimento (muito) controlado da empresa em um período de crise econômica profunda do país.

E aí você achou que este seria mais um texto motivacional daqueles que geram uma vergonha alheia profunda né?

Esta “vibe empreendedora” me incomoda

(odeio a palavra “vibe”, mas foi a melhor que encontrei no momento, desculpe)

Vejo muito papo furado em apresentações sobre empreendedorismo, startups e cia. Como alguém que tem uma empresa de verdade, pagando salários e impostos reais, resolvi listar aqui parte das lorotas que dizem.

A ausência de uma palavrinha chave que começa com “R”

simpsons-radioactive

Sabe: quando assisto a algum picareta no palco falando sobre sua “trajetória de sucesso” ou mesmo aqueles caras que claramente nunca abriram seu próprio negócio te dizendo como proceder raramente vejo uma palavra ser dita: responsabilidade.

Ok, você quer abrir seu negócio. Você sonha se tornar alguém que criou algo importante, mas já parou pra pensar na imensa responsabilidade que é ter seu próprio negócio?

Já parou pra pensar na honra que é alguém querer trabalhar contigo? Honra esta que não pode se tornar uma decepção. No compromisso que é mensalmente pagar todos os impostos envolvidos no pagamento de salário desta(s) pessoa(s)? Já se atinou pro fato que você pode fuder a vida de quem trabalha com você?

Se só tem sócios na sua empresa, será que sua empresa terá estrutura para ter pessoas recebendo no regime legal, que é o CLT?  Desculpe: você só sabe o que é ter uma empresa quando assinar a primeira carteira de trabalho de alguém.

E a responsabilidade que é alguém te escolher como fornecedor? Te escolheram, confiaram em ti e no seu serviço/produto: agora vai ter de corresponder.

Agora vamos para um nível acima: já parou pra pensar que ao abrir uma empresa você está influenciando a sua economia local? Que se seu negócio for pura lorota, você pode desacreditar todo um ramo?

Quase sempre a mesma historinha!

conto_de_fadas

Releia os três primeiros parágrafos deste post. É inacreditável como sempre escuto nas apresentações a mesma história composta por três atos.

  1. O empreendedor tem uma ideia que considera genial, mas ele é arrogante devido à sua própria ignorância. Ele segue em frente.
  2. Aparece um obstáculo e nosso herói sofre um forte baque. É o momento em que sua ideia é posta em cheque. Será que ele consegue vencer o obstáculo?
  3. Ele aprendeu com os erros, adaptou-se, adquiriu humildade: agora está mais sábio e tudo deu certo.

Há uma outra variação cruel desta mesma história. Segue abaixo:

  1. O empreendedor tem uma ideia que todos consideram idiota, mas ele tem e segue em frente.
  2. Ninguém acredita em nosso herói, mas ele continua. É o período tenso, no qual sua fé é testada.
  3. De repente sua ideia começa a funcionar! Todos percebem que estavam errados e não o herói, mas o mundo percebe que era arrogante e se redime.

Percebeu que há uma forma compartilhada?

  1. Nascimento da ideia – herói empolgado
  2. Momento da dificuldade – herói se questiona
  3. Dificuldade superada, sucesso atingido – herói confirma sua ideia (mesmo que a adapte)

Você realmente acredita que o mundo é tão simples assim??? Não são expostos muitos detalhes a respeito dos passos reais envolvidos no problema. É como Vitor Hugo, que dizia ter escrito Les Miserables de uma única vez. Anos após sua morte encontraram um baú com inúmeros manuscritos.

Resumindo: sempre o mesmo conto de fadas, a realidade é mais interessante (e árdua) que isto.

(aliás, este é o arquétipo mais básico do herói presente na literatura ocidental)

A ideia de que basta ter uma ideia e um… app

Claro, sou um desenvolvedor, quero trabalhar e tal, então não deveria dizer isto, mas é tanta gente iludida com a ideia de que para ser um empreendedor de sucesso você só precisa de um aplicativo e uma ideia…

E os caras falam isto no palco!!!

“Kico, se tivermos um app como o Krankster ficaremos ricos!” – Yeah! Nem precisamos pensar nas pessoas que cuidarão dos fornecedores, contato com clientes, manutenção, suporte, o computador resolve tudo pra nós!!! O Processo é o sistema!

“Nada pode dar errado!” (copyright)

A venda de uma vida sem sentido

O indivíduo é seduzido pela ideia de ter um negócio próprio, investe horrores na construção da infraestrutura necessária e começa a ver a coisa tomando forma.

Então chega uma pessoa e lhe pergunta: uma vez aberta sua empresa, como será seu dia a dia?

 

 

 

 

Um silêncio profundo dominará a conversa.

 

 

 

cricricri

Sério, já parou pra pensar nisto? Uma das razões pelas quais oficializamos a itexto foi nosso desejo de desempenhar um conjunto de atividades diárias no trabalho. Se você não sabe como será o seu operacional básico, pra quê abrir uma empresa?

Já parou pra pensar que uma vez aberto o negócio, você passará um bom tempo nele fazendo alguma coisa? Será que descobrir o que é esta “alguma coisa” depois é uma atitude inteligente?

A venda de uma realidade gringa

Arde: te mostram um modelo de negócio maravilhoso, aquela estratégia genial que funciona extremamente bem… na Europa e Estados Unidos.

São casos envolvendo ideias pouco convencionais no primeiro momento como Twitter (quem poderia imaginar: 144 caracteres!), Facebook, Apple (quem imaginaria um computador em casa?), Microsoft (os caras largaram a faculdade!) e por aí vai.

Mas não mencionam que lá existe uma cultura empreendedora centenária, uma economia brutalmente competente, um governo que não te sufoca com impostos, etc. Não mencionam que é um ambiente no qual você tem fôlego para falhar.

Sério: criar rede social no Brasil? Nossos problemas  são outros! Cansei de ver consultores ou investidores apresentando modelos gringos aqui.

E sinceramente, desconfio que o modelo de startup no Brasil é fadado ao fracasso por ser vendido, em sua maioria, baseado em ideias estrangeiras muito mal adaptadas à nossa realidade (basta pensar um pouquinho no próprio termo “startup”).

Gente que te ensina a abrir uma empresa e cuja própria empresa é… ensinar pessoas a abrir a própria empresa.

Meus comentários são desnecessários aqui.

(aliás, já escrevi a respeito)

As fórmulas prontas

“X passos para o sucesso”, “N oportunidades para ficar milionário em 2017”, “as Z coisas que pessoas de sucesso fazem todo dia”

Sério que as pessoas acreditam que a realidade é tão simples assim?

Levando em consideração a quantidade de leitores destes livros de “auto-ajuda para empreendedores”, era para estar pipocando milionários. Cadê eles?

Uma infantilização extrema

Por favor, faça o seguinte exercício: acesse o YouTube e busque por vídeos apresentando startups. É grande a possibilidade de você ver o seguinte:

  • Uma animação cartunesca
  • No fundo musical vai ter um banjo (99,99% de chance! Se não tiver banjo, tem pandeiro!)
  • Todas as pessoas sorriem por que todo mundo é divertido e o mundo colorido!

Talvez soe ranzinza mas… quem quer investir em uma empresa dirigida por pessoas assim? Oh: desculpe, talvez eu esteja com inveja por não fazer parte do grupo das pessoas legais… (percebo que não faço, sinto alívio!)

Esta infantilização se manifesta de forma clara quando observamos o uso repetido ao extremo da imagem do jovem prodígio.

Na realidade a infantilização nada mais é que a exploração da carência presente em cada um de nós (e sobre isto ainda escrevo um texto).

Então empreender é ruim?

Claro que não: o que quero mostrar neste texto é que abrir uma empresa não é algo simples ou fácil como este povinho picareta diz nos palcos. Empreender é algo sério e deveria ser um ato virtuoso, mas infelizmente aos poucos estão criando uma aura negativa em torno do verbo.

Quer abrir uma empresa, vai fundo, mas saiba aonde está entrando e nas consequências dos seus atos. Quer ver palestra de gente que diz te ensinar como agir? Vai lá e assista, mas pelo menos questione! Saiba assistir a uma apresentação.

Desculpem a franqueza, mas quem tem uma empresa real, como eu, ao assistir este conteúdo furado tem seu estômago revirado. Alguém tem de falar, tá chato ver a quantidade de pessoas afundando por que se iludem com estas lorotas.

Quando o comentário realmente documenta o código

Como alguém que lida com muito código fonte que não é de minha autoria, neste post vou listar algumas dicas para tornar seus comentários no código realmente úteis. São hábitos simples que, se bem seguidos, tornam a vida de quem manterá aquele sistema mais fácil e, portanto, aumentam a produtividade de toda a equipe.

Naturalmente, não irei incluir aqui todas as dicas possíveis, razão pela qual no final deste post irei citar algumas boas dicas de leitura sobre este assunto.

Não vou falar do óbvio: “o comentário deve dizer o que aquele método ou classe faz” ou “comentar o óbvio é bobagem” ou “comente apenas o necessário” pois, convenhamos, é chover no molhado ou mero “preenchimento de linguiça”.

Tudo é história

Todo software é gerado dentro de um contexto: a situação da equipe no momento em que foi criado, quem o escreveu, assim como seus conhecimentos naquela época, quais as tecnologias estavam em voga, etc.

Conhecer este contexto é muito importante para compreender as razões pelas quais o código se encontra em sua situação atual. Infelizmente, na esmagadora maioria das vezes em que encontramos o código pela primeira vez só temos conhecimento do seu estado atual se ignorarmos seu histórico no sistema de controle de versões (seja sincero, quantas vezes já percorreu aquele histórico ao ter seu primeiro contato com uma base de código pré-existente?).

Lidando com o passado – reconstruindo o histórico perdido

 

Comentários podem ajudar e muito aqui. Neste momento entra a primeira dica: use um sistema de controle de issues e replique informações deste sistema nos seus comentários. Como fazer isto? Basta mencionar o número da issue em seu comentário. Seguem alguns exemplos:


/*
Classe responsável pelo envio de e-mails no sistema /* (isto é óbvio) */
Issue na qual se encontra documentado o requisito que deu origem ao
requisito: http://meusistemadeissues/issue/825
*/
class EmissorEmail {

É bastante simples: com isto seus comentários não ficam imensos e quem estiver dando manutenção no sistema poderá entender melhor o contexto no qual aquele código foi criado. Um excelente local para se incluir este tipo de comentários é em código no qual você esteja corrigindo um bug, tal como no exemplo abaixo:

int diasEntreDatas(Date dataInicial, Date dataFinal) {
/*
Havia um erro no código abaixo que não considerava sábados e domingos,
gerando resultados inválidos.
Issue: http://seusistemadeversoes/issue/847
Alterado por Henrique Lobo - 1/3/2016 - 14:20
*/
}

Entra a segunda dica: assine seus comentários. Com isto, caso alguém encontre problemas no código que você alterou, poderá lhe procurar para obter maiores informações a respeito daquela situação que, talvez, não se encontrem documentadas no seu sistema de issues ou qualquer outra fonte de documentação.

Mais do que assinar os comentários, creio que também seja muito importante incluir a data e hora no mesmo. Isto contribuí para entender o contexto histórico daquela alteração e muitas vezes agiliza ao extremo a compreensão do problema e aplicação da solução. Esta portanto é minha terceira dica: date seus comentários.

Três dicas simples relacionadas ao histórico que, se aplicadas em conjunto, facilitarão demais a vida de todos:

  • Use um sistema de issues e o referencie em seus comentários
  • Assine seus comentários para que as pessoas possam lhe procurar (quem não tem culpa no cartório não se esconde)
  • Sempre inclua uma data nos seus comentários para saber quando a alteração foi realizada

Lidando com o passado recente

Há também aquelas situações nas quais você fez uma alteração no código mas não se sente 100% seguro a seu respeito, mesmo que tenha escrito testes para validar o comportamento esperado. É normal e te entendo perfeitamente. Nestes casos, não há problema algum em deixar comentada a versão anterior do código apenas para comparação com o que você fez, tal como no exemplo a seguir:


int soma(int x, int y) {
return x + y;
/*
Acho a versão anterior pura frescura, por isto substituí pela
minha alterantiva melhor otimizada e que não usa ifs!
Issue: http://www.meusistemadeissues.com/issue/13
Henrique Lobo - 2/2/2012 - 13:13
return (x > Integer.MAX_VALUE || y > Integer.MAX_VALUE) ? -1 : x + y;
*/
}

Lidando com o futuro (usando lembretes)

Muitas vezes a pressão do dia a dia faz com que precisemos incluir débitos técnicos em nossos sistemas. É normal: no futuro você vai resolver estas questões (se se lembrar delas).

A maior parte das IDEs hoje, além de sistemas de análise estática de código como o SonarQube oferecem suporte a um tipo especial de comentário: o “TODO”. Nunca o viu? É simples: vamos a um exemplo rápido e completamente fora da realidade.


boolean autenticar(String login, String senha) {

/*
TODO: meu gerente me obrigou a isto para o release 1.0.0 do sistema
Henrique Lobo - 12/3/2004 12:00
Issue: http://www.meusistemadeissues.com.br/issues/666
*/
if (login == "dede") {
return true;
}
}

Comentários do tipo TODO mostram pontos a serem melhorados no sistema. Na imagem abaixo podemos ver um exemplo do uso deste tipo de comentário no Eclipse (práticamente todas as IDEs possuem este recurso atualmente):

todo_eclipse

Mesmo que você não se lembre de ter feito o que estava no comentário, alguém do futuro saberá a respeito e poderá fazer algo a respeito.

Refatorando comentários?

Se você usa um sistema de controle de issues e assina e data seus comentários, passado algum tempo você talvez precise refatorá-los. Como assim?

De duas maneiras: você pode excluir aqueles comentários que envolvam código antigo (pois o tempo já mostrou que as alterações realizadas funcionaram) ou você pode simplesmente remover aqueles comentários que não agregam coisa alguma.

Resumindo: de tempos em tempos é uma boa prática apagar os comentários inúteis. Lembre que você tem o sistema de controle de versões e nele já está presente todo o histórico de alterações.

Não divulgue segredos

Parece estranho o que vou dizer, mas seu comentário pode expor segredos relativos à sua empresa ou contratante. Apesar de ter mencionado no início deste post que não iria mencionar o óbvio, me assusta a quantidade de informações sigilosas que programadores publicam em seus comentários. Alguns exemplos:

  • Credenciais de acesso a serviços ou servidores
  • “Recados” a outros membros da equipe – “Kico, resolva isto depois, ok?”
  • Críticas ao empregador ou outros membros da equipe
  • Críticas à natureza do próprio código fonte (isto você documenta como débito técnico no sistema de issues normalmente)

Quer um bom exemplo histórico? Algum tempo atrás vazou o código fonte do Windows 2000. Que tal ler o que a mídia da época comentou a respeito?

Lembre que remover commits do sistema de controle de versões não é uma tarefa trivial.

Boas leituras

Há dois livros muito bons que possuem capítulos dedicados aos comentários em código fonte:

Code Complete – Steve McConnell – Editora Microsoft (diga-se de passagem, o melhor livro que já li sobre programação em geral, leitura obrigatória) – Traduzido para o português pela editora Bookman

Clean Code – Robert C. Martin – Editora Prentice Hall – Traduzido para o português pela editora Alta Books

As duas traduções são muito boas e ambos são leitura obrigatória apesar da minha preferência pelo primeiro.

Concluindo

Não creio naquela história de que “a documentação do meu sistema é meu código”, no entanto, se for o caso, pelo menos bons comentários irão lhe ajudar na manutenção futura deste sistema.

Sobre minhas críticas ao “código como única documentação”, provávelmente será meu próximo post neste blog (ou quando encontrar uma forma mais polida de lidar com este assunto). :)

“Legado” é um termo maldito

O termo “legado”, quando aplicado a software sempre me incomodou: tanto que algum tempo atrás busquei uma melhor definição para esta palavra dentro do nosso contexto de TI. Hoje volto ao assunto para dizer que não uso mais a palavra “legado” com meus clientes e colegas e explico minhas razões.

O termo que todo mundo busca a definição (inclusive eu)

Fui um dos palestrantes da trilha de legados da QCon Rio 2015 e, para minha sorte (ou azar), fui o último a falar, o que me permitiu assistir a todas as apresentações sobre o assunto. O que achei interessante é que quase todos (inclusive eu) apresentaram seu próprio conceito de legado.

(e neste texto ainda apresento mais definições sobre legado, o que mostra ser um fenômeno global, e não uma particularidade daquele evento)

Claramente há algo errado aqui: se dentro de um contexto bem definido (ou ao menos aparentemente) há tantas definições para uma mesma palavra, surgem duas possibilidades:

a) A palavra não possuí um significado real
b) Devíamos ou categorizar este termo ou mesmo buscar outras palavras

A  má impressão criada pela nossa indústria

Diversas vezes um cliente chega para nós pedindo que executemos manutenções ou evolução em seus sistemas com frases do tipo: “temos este sistema legado, que me disseram ser velho e ultrapassado, mas não tenho dinheiro para reescrever do zero”.

Lendo o código fonte observo que foram usadas tecnologias como Spring BootGrailsPHP, JavaScript, JSF ou qualquer outra que é ativamente desenvolvida hoje. Pior ainda: o sistema tem no máximo 5 anos de idade. Não poderia ser categorizado como “velho”, e levando-se em conta que normalmente está em uso, muito menos “ultrapassado” ou “obsoleto”, pois claramente está satisfazendo objetivos de negócio ali.

Fato é que muitas consultorias e profissionais normalmente ao invés de venderem a evolução do sistema preferem a reescrita por dizerem dar menos trabalho e sair mais barato (o que normalmente  é uma grande mentira e ainda escreverei sobre isto, mas enquanto isto, pode ler este excelente texto do Joel Spolsky).

A situação é ainda pior: já vi apresentações sobre “legados” na qual o palestrante usa o termo “evolução” e apresenta uma completa reescrita como resultado (atualmente uma das formas que esta reescrita vêm disfarçada é como micro-serviços).

Resultado: o termo “legado”, que deveria ter uma conotação positiva (conhecimento e experiência adquirida ao longo do tempo, conquista, satisfação por ter construído algo que é passado pra frente) passa a ser visto por muitos como um defeito.

(não creio que a maior parte dos profissionais e consultorias que vendam a reescrita imediata sejam mal intencionados. Na minha opinião o problema surge da nossa formação. Um dia ainda escreverei sobre isto)

Que termo uso agora

O mais óbvio e tedioso:  “software que você já tem” ou “software pré-existente” ou, ainda “software que não escrevi” ou algo similar pelas seguintes razões:

a) O cliente (que é quem realmente importa) entende o que estou dizendo imediatamente
b) Muitos clientes nunca ouviram o termo “legado”, o que evita a necessidade de explicar uma palavra que creio ser tão mal empregada em nosso idioma
c) Me fornece (e à indústria) um ponto inicial que possibilite uma melhor criação de sub-categorias que auxiliam na definição de estratégias

Sobre categorização

O termo “software que você já tem” é elementar: não consigo pensar em uma categoria superior a este (“software”, talvez :D) , mas consigo pensar em “tipos de software que você tem”. Segue uma pequena lista:

  • Aquele que temos o código fonte
  • Aquele que não temos o código fonte (sim, acontece e muito)
  • Aquele que é parte de sua infraestrutura (SGBD, Sistema Operacional, protocolos de rede)
  • Ou outra categorização qualquer que represente o nível de posse do cliente sobre um software

E esta categorização nos ajuda a pensar melhor o “seu software“. Ao analisar a situação do cliente (a mais importante), a comunicação fica mais simples e direta. É curioso que nas apresentações que vejo sobre legados só escuto sobre a primeira categoria: “aquele que temos o código fonte”. Aonde ele é executado? Como é o ambiente que o rodeia?

(é interessante notar que as pessoas confundem “legado” e refatoração, e esta é minha prinicpal crítica ao livro do Feathers – legado não é só o código)

A partir do momento em que um termo mais simples é usado na conversa, tudo flui, impressionante.

Minha antiga definição de “legado” não era uma definição

Ano passado busquei uma definição de legado e eis a que cheguei:

Sistema legado é aquele cujo controle foi perdido por seus principais stakeholders. – Definição Lobo Weissmanniana

Leia atentamente o que acabei de escrever: isto é uma definição? Hoje creio que não, pois não defini um termo, mas sim o problema fundamental do seu software.

O que é legado? Em português (e pensando no contexto brasileiro) é um termo que causa mais confusão que o necessário, haja visto os pontos que expus. Sendo assim, não irei mais me preocupar com a sua definição ou mesmo seu uso.

(ainda escrevo sobre um possível hype envolvendo este assunto (hype este que não se desenvolverá de forma saudável devido às falhas em nossa formação que comentei em parênteses anteriores))

Meu problema com a infantilização

Tratar adultos como crianças, especialmente desenvolvedores, sempre me irritou. Algum tempo atrás inclusive escrevi sobre isto aqui no blog. O foco da minha opinião é o desperdício de algo fundamental: o processo de amadurecimento.

Vejo de forma muito clara este processo infantilizador se manifestando em vagas de emprego que buscam “padawans”, “jedis”, “super-heróis”, “rockstars” (vergonha alheia infinita). Isto sem mencionar grande parte da cultura “geek” que, devo confessar, não raro vejo carregada de fortíssimo caráter infantilizador. Isto sem mencionar “apresentadores” e “palestrantes” que se vestem como crianças. Nossa, quanta vergonha alheia!

Mas o que é amadurecer?

Para mim envolve a expansão intelectual. Vou partir de um exemplo banal. Ao encontrar alguém usando um chapéu de Mario e lhe pergunto por que o está usando. Normalmente a resposta é um “por que é legal”.

Por que o chapéu?  Por que é legal!

Por que o chapéu?
Por que é legal!

Esta é uma resposta válida, mas se forçar a barra e perguntar “por que é legal?”, não raro o indivíduo infantilizado não vai saber responder. Resumindo: a futilidade (um aspecto infantil resultante de uma percepção limitada) está se manifestando. Lhe interessa o ato de fazer graça. Então, como seria uma resposta adulta?

(já se perguntou por que, na sociedade ocidental na qual o riso é visto com desprezo, de repente ser uma pessoa “divertida e engraçada” passa a ser visto como algo super positivo? Dica de leitura)

“O que envolve o conceito do Mario é interessante e me agrada”. Me lembro quando era pré-adolescente e vi o Mario Bros pela primeira vez. Algo completamente diferente de todos os jogos que havia jogado até aquele momento: o cenário era muito rico e toda a mecânica era algo revolucionário para nós.

free_download_super_mario_bro_game

O que me impressionava era o puramente sensório: a experiência de controlar o Mario e todas aqueles elementos secretos no jogo eram algo fascinante para alguém com 12, 13 anos (muitas cores e surpresas, além de uma música top). A coisa ficou realmente interessante quando notei uma similaridade naquele jogo com algo que já conhecia.

smb3_mush2

Aquela história do Mario comer um cogumelo e de repente crescer. Já havia visto isto em algum lugar: em Alice no País das Maravilhas, mas ao contrário. Ela encolhia.

alice-on-mushroom-3

Caramba! E de repente, observando as ilustrações do livro de Lewis Carroll, conseguia ver no cenário que se movia do Mario elementos daquela história (Mario era um ser diminuto entre cogumelos?). Isto ampliou meus horizontes  e me fez começar a questionar outras coisas: quem criou o Mario? Foi a Nintendo. Mas quem dentro da Nintendo teve esta ideia? Foi o Myiamoto. Quem é ele? O que inspirou este sujeito?

Mario -> Alice no País das Maravilhas -> Nintendo -> Miyamoto -> Lewis Carroll -> Problemas lógicos -> Matemática

A rede cultural se expande: vejo mais pontos e ligações entre eles. Questiono estes relacionamentos e busco confirmações a seu respeito. Resumindo: saio de algo simples e  fútil:  termino em um universo totalmente novo que não para de se expandir conforme interajo com ele.

A pergunta “por que você usa este chapéu de Mario?” adquiriu profundidade. E neste processo de amadurecimento noto que até minha capacidade em aceitar críticas foi ampliada: ao ver um número maior de possibilidades no mundo, são grandes as chances de eu realmente estar errado e existirem alternativas muito superiores. Resumindo: eu venço outra barreira infantil que é a do solipsismo. Estou em um mundo rico com o qual interajo.

Amadurecer é bom e a vida adulta é maravilhosa. O adulto tende a ser sábio, ao contrário da criança. Então, o que ganho ao infantilizar? Para responder a esta pergunta, é importante responder outra: como é ser uma criança?

(algo fascinante: vejo esta “expansão intelectual” em praticamente tudo, basta tentar)

Como é ser criança?

Odiava ser criança. Brincar era legal, não havia trabalho (meus pais me mantinham), mas nem por isto meus problemas eram menores. Há adultos que te controlam e definem o que deve ser feito. Além disto, o mundo é assustador pois você não o conhece direito por ter uma visão limitada da realidade.

E justamente por ter uma visão limitada a criança se vê a mercê do adulto a quem deve obedecer de forma compulsória. O medo do desconhecido faz com que a criança se torne um ser quase solipsista, que vive em um mundo apenas seu, mas controlado por forças desconhecidas.

Seus problemas também não são tão menores como pensamos: basta se lembrar dos medos  que sentia ao se imaginar levando bomba na escola ou na possibilidade de perder seus pais, quem cuidaria de você? E se seus pais não fossem tão legais assim? E se você fosse adotado? Existem monstros no escuro?  Os medos da infância parecem tolos hoje que somos adultos, mas na época eram aterrorizadores.

Verdade seja dita: romantizamos a infância. Além da vulnerabilidade e dependência em relação aos adultos, sabe o que mais a “boa criança” costuma ser? Dócil. Afinal de contas, uma “criança boazinha”, tal como somos criados, é aquela que recebe “presentes do Papai Noel”, é aquele ser que não questionaque obedece.

Pra que infantilizar então?

Essencialmente por que você quer ter um controle maior sobre o outro, que não desejamos vir a se tornar um questionador. E que te admire, pois você estará, em relação ao infantilizado, como o adulto em relação à criança.

É curioso como em diversos casos de infantilização que observo os manda-chuva são pessoas extremamente adultas, formais, exemplares. Já notou isto?

E por que o fútil é tão valorizado? O que faz da fábrica de doces algo sedutor? Ela faz com que o adulto se esqueça dos problemas relativos ao seu amadurecimento. Você afunda o adulto em tolices para que ele se torne dócil.

Por que uma biblioteca de quadrinhos e não clássicos ou grandes livros? Por que os segundos são “chatos”? O que os torna chatos ou, ainda melhor, “quem” os vende como tal?

Por que me incomoda então?

Por que ao diminuir o indivíduo, termina por lotar de tolos o mundo. Confesso sentir calafrios ao pensar na formação de futuras gerações. Será este medo o resultado do meu envelhecer? Talvez.

Me incomoda muito pensar que as pessoas, em sua carência, acabam por se colocarem em uma posição inferior sem a menor necessidade.

Devo ser uma pessoa séria sempre então? Não: só tem de evitar se tornar um “retardado”.
(já notou que normalmente quem se da bem possuí uma forte tonalidade séria?)

PS:

controvérsias sobre a relação entre o Mario e Alice no País das Maravilhas, no entanto o simples fato de podermos fazer a conexão por conta própria já me parece algo incrível.

PS 2:

Sou contra o “trabalho infantil” :D