Programador Freelancer

Esse artigo saiu inicialmente na O Melhor da Internet.

Durante muito tempo da minha vida eu trabalhei como programador freelancer. Eu até tive empresa, sócio, etc. mas o fato é que eu era um freelancer como qualquer outro. Afinal eu vendia o serviço, elaborava proposta, negociava, executava o projeto, cobrava, emitia nota fiscal, e dava suporte. Durante esse tempo eu aprendi algumas coisas que gostaria de compartilhar.

Freelancing não escala

Trabalhar como freelancer é divertido e dificilmente enfrentamos problemas com a rotina quando trabalhamos desta forma. Não temos que lidar com a rotina porque cada projeto é único.

Essa variedade de projetos é legal mas tem algumas desvantagens. Como eles são razoavelmente diferentes fica difícil reaproveitar o conhecimento adquirido durante a execução de um deles.

Como o freelancer precisa aprender coisas novas em quase todos projeto perde-se boa parte do “ganho de escala” do negócio. E é o ganho de escala que permite reduzir custos que geram margens de ganho maiores ou preços menores para o cliente. Isso não é bom nem ruim. É uma característica inerente do trabalho do freelancer.

Se o freelancer opta por “crescer” o negócio e montar uma empresa com vários funcionários (ou freelancers) precisa observar que ele pode até ganhar escala mas esse ganho será praticamente linear: para fazer 1 projeto precisa de 1 pessoa e para fazer 2 projetos provavelmente precisará de 2 pessoas.

Você pode até mudar a inclinação do gráfico projetos x pessoas mas ele dificilmente se curvará.

Você vende horas? Cobre por horas

Uma armadilha bastante comum para freelancers iniciantes é a de negociar um contrato com um escopo fechado. A coisa piora se o escopo não estiver muito detalhado.

Essa armadilha é mortal porque na imensa maioria dos casos o contrato vincula o pagamento do serviço à entrega do escopo. E, acredite, os clientes vão expandir esse escopo ao ponto de tornar o projeto prejudicial para o freelancer.

Eu sei que é difícil negociar um contrato baseado em horas de trabalho mas você tem que negociar nesses termos. É melhor não pegar o projeto do que negociá-lo por escopo e/ou vincular o pagamento ao escopo.

Sei que isso é bem complicado porque as contas para pagar chegam todos os meses sem piedade e aquele contrato com escopo fechado oferece uma oportunidade de ter dinheiro para pagar essas contas. Mas no médio prazo você pode acabar se tornando um escravo do projeto e ficar trabalhando de graça nele (ou até pagando para trabalhar).

O melhor para você e para seu cliente é trabalhar com entregas parciais em intervalos curtos e rápidos. Isso nos leva ao próximo ponto…

Atualização: logo depois que enviei O Melhor da Internet o meu amigo Elvis enviou um link para um artigo que ele escreveu onde ele ressalta o fato de que um freelancer raramente consegue vender 100% das suas horas disponíveis.

Atualização 2: Depois que o artigo foi publicado me lembrei de uma outra dica importante relacionada à esse tópico. Quando você está elaborando a proposta e negociando o projeto é importante incluir o tempo usado nesse processo no valor final do projeto. Se você não fizer isso essas horas sairão “de graça” para seu cliente. Para isso funcionar direito as propostas também precisam ter um prazo de validade que permita uma revisão de valores nos casos onde a negociação demora muito.

Não cobre “50% no início e 50% na entrega”

É uma prática bem comum trabalhar dessa forma: o freelancer recebe 50% quando inicia o projeto e o restante quando entrega ele pronto.

Existem duas pegadinhas nesse modelo: uma é o conceito de pronto (veja o tópico anterior) e a outra tem relação com um negócio chamado fluxo de caixa.

Uma das coisas que certamente mata uma empresa é a má gestão do seu fluxo de caixa. E um freelancer é uma empresa de uma pessoa só. Precisa gerenciar seu fluxo de caixa com muita atenção.

Quando você fecha um negócio e recebe por ele 50%+50% fica mais difícil de gerenciar o fluxo de caixa da empresa porque a segunda metade do pagamento vira um alvo móvel. Quando você vai entregar o projeto? Quando ele estará “pronto”?

No lugar de negociar 50%+50% prefira receber parcelas em intervalos regulares (mensalmente? quinzenalmente?). Pode-se até vincular os pagamento às entregas parciais do projeto.

Receber pelo trabalho em intervalos regulares e vincular isso às entregas parciais é o cenário perfeito porque facilita a gestão do fluxo de caixa do freelancer e aumenta a segurança do cliente que pagará por algo que já recebeu.

“Produtize” seus serviços

No primeiro tópico eu falei sobre o problema de escala associado ao freelancing e aqui eu vou apresentar uma forma de amenizar esse problema.

É raro mas acontece: quando um freelancer está trabalhando no seu milésimo projeto ele percebe que certos padrões surgem em todos eles. Exemplo: quase todos os projetos tem um formulário de contato, ou uma página com um mapa mostrando a localização da loja do cliente, ou tem algum sistema de monitoramento, backup, etc.

Quando o freelancer detecta um padrão desses ele pode ter certeza que existe uma oportunidade de transformar essa parte do projeto em um produto que pode ser vendido para vários clientes. Se você fizer isso vai ter um ganho de escala ou até mesmo alguma receita recorrente.

Certos projetos também são genéricos ao ponto de poderem ser transformados em produtos (com a devida anuência do cliente contratante). Um exemplo? Um dos meus clientes solicitaram o desenvolvimento de um sistema de avaliação de funcionários para o RH da empresa.

O sistema usava uma metodologia conhecida como “Avaliação 360°” e gerava relatórios para o RH da empresa avaliar os seus funcionários. O sistema foi desenvolvido para um cliente específico mas, certamente, poderia ser útil para outras empresas. Não foi o caso mas esse projeto poderia ter se transformado em um produto.

Outros tipos de produtos que você pode criar estão na forma de conteúdo. Em meu caso, por exemplo, escrevi um livro e criei um video-curso de programação Python e Django para vender na Internet (que, por não manter mais, acabei disponibilizando gratuitamente).

Crie receitas recorrentes

Todo negócio tem seu risco e com o freelancing não poderia ser diferente. Quando o freelancer está trabalhando e vendendo suas horas de trabalho para alguém as coisas ficam bem. Mas quando, por algum problema, isso não acontece as coisas podem ficar bem complicadas.

Um freelancer pode adoecer, o mercado pode dar uma esfriada, pode acontecer uma entresafra de projetos (ex. o período de novembro a março costuma ser difícil para novos projetos).

Uma maneira de lidar com essas dificuldades é cuidar para poupar nos períodos fartos para ter algo nos períodos difíceis como na fábula da Cigarra e das Formigas. Outro modo de lidar com essa questão é criando formas de se obter receitas recorrentes.

Ofereça serviços de manutenção, suporte, apoio, etc para os clientes que desenvolveram projetos com você. Crie mecanismos (honestos) para continuar recebendo dinheiro deles mesmo depois que o projeto tenha terminado. Ou crie algum produto (tópico anterior) que seja vendido na modalidade de assinatura.

Recuse clientes ruins

Essa é uma das coisas mais difíceis de colocar em prática porque, a menos que alguém nos avise, é quase impossível saber se um cliente novo é bom ou ruim. Mas alguns indícios podem ser observados:

  • Cliente que questiona demais os preços – pode ser uma preocupação legítima mas geralmente não é. Mostra que é um cliente mais preocupado com preços do que com qualidade. Ele vai apertar os seus ganhos e vai te trocar por outro mais barato na primeira oportunidade.
  • Cliente que não sabe o que quer e não te ouve – existem muitos clientes que não sabem exatamente o que querem e isso isoladamente não é um problema. Mas se você tentar ajudá-lo a descobrir e ele recusar a sua ajuda isso pode virar um problema.
  • Cliente que descumpre o combinado – você estabelece com o cliente que ele te pagará mensalmente e no dia do pagamento você tem que ficar lembrando e cobrando. Ou cliente que simplesmente te dá um calote. Eu costumava fazer um teste: eu “esquecia” de cobrar os meus clientes algumas vezes. É engraçado mas os meus melhores clientes sempre me enviavam e-mail avisando sobre meu “esquecimento”.
  • Cliente que oferece uma “oportunidade única” de trabalhar para ele – tem muito cliente que pede um precinho camarada em um primeiro projeto com a promessa de valores maiores em projetos futuros. Não caia nessa armadilha porque esse cliente não é fiel à você. Ele é fiel ao teu preço baixo. E não se engane… tem muita empresa grande e famosa que usa o próprio nome para obter essas vantagens. Se usarem o discurso do “você vai colocar a nossa empresa no teu portifólio!” respondam de forma sarcástica: “eu já gastei a minha verba de marketing para esse ano”.

Para clientes pré-existentes é sempre importante gastar algumas horas do mês para reavaliar a sua carteira de clientes e projetos. Cliente bom é aquele que cumpre com suas obrigações, gera bons projetos, indica você para novos clientes e te dá um bom lucro.

Automatize as tarefas chatas

Coisas chatas que freelancers precisam fazer e precisam ser automatizadas o mais rápido possível:

Responder e-mails de sondagem

Eu recebia muitos e-mails assim: “Oi, Meu nome é Fulano e gostaria de saber quanto você cobraria por um projeto assim e assado”. Você tem que responder à esses e-mails mas 80% deles são de aventureiros. Pessoas que não tem dinheiro para te contratar, não sabem o que querem e não vão fechar negócio contigo.

O problema é que não dá pra você diferenciar as boas oportunidades daquelas que vão fazer você perder tempo.

Um das coisas que funcionou razoavelmente bem comigo foi colocar informações detalhadas sobre o tipo de projeto que eu desenvolvia e um valor aproximado para minha hora de trabalho no site da empresa. Colocava destaque na informação: “Esses valores são negociáveis”.

Com essas informações a pessoa já consegue ter uma idéia se ele consegue contratar o seu serviço. A outra informação (valores negociáveis) filtrava os aventureiros daqueles que realmente queriam realizar o projeto.

O cara pode até não ter o dinheiro para te contratar mas se ele quiser muito realizar o projeto ele vai entrar em contato contigo para tentar negociar o prazo de pagamento, os valores, o escopo, etc. E isso, por si só, mostra que ele pode ser um bom cliente e gerar negócios.

Algumas pessoas (por medo ou desconhecimento) acreditam que essas informações no site afugentam clientes. Pode ser que sim. Mas pergunte-se: “Que tipo de cliente eu estou afastando?”.

Produzir e enviar propostas

Depois que você entende melhor o projeto é o momento de enviar uma proposta para seu cliente.

Se você ainda estiver negociando projetos com escopo fechado fica impossível automatizar essa etapa porque cada proposta será única e precisará ser bem detalhada, mas se você negociar em termos de horas a proposta fica bem mais simples. Você precisa apenas preencher os milestones do projeto (entrego X na data Y, …) e fazer uma multiplicação de horas pelo teu valor/hora.

Eu tinha um template no meu editor de textos onde eu só alterava os dados, gerava um PDF, e enviava para o cliente. Se o cliente já era antigo, muitas vezes, eu só mandava um e-mail: “imagino que dê pra gente trabalhar nisso em uma semana por R$X”. E o cliente respondia: “Ok, pode fazer”. Esse é o tipo de relação de confiança que você precisa construir com seus clientes.

Cobrança e NFe.

Cobrar o cliente e ver se ele pagou é uma daquelas coisas que nunca consegui automatizar 100% mas cheguei à um ponto onde isso não atrapalhava o resto das atividades.

Eu criei uma conta de cobrança sem registro na conta da empresa no banco (dica: não misture sua conta pessoal com a conta usada para seu trabalho) e emitia boletos para meus clientes pagarem. Cerca de 5 dias depois da emissão dos boletos eu puxava um extrato e conciliava os pagamentos na mão. No site da prefeitura eu emitia as NFe daqueles que haviam pagado o boleto.

Comecei com um software que só emitia os boletos e depois migrei para outro que emitia os boletos e a NFe.

Seja parceiro dos bons clientes

É provável que você não consiga resolver todos os problemas de seus clientes e, nestes casos, você deve ajudá-lo a encontrar as soluções para esses problemas. Mesmo que para isso você tenha que encaminhá-lo para um outro prestador de serviços (freelancer, empresa, etc).

Se você fizer isso o cliente criará um modelo mental muito positivo sobre você: “quando eu tenho um problema é só eu entrar em contato com esse cara que ele resolve ou me ajuda a resolver”. Esse modelo mental é poderosíssimo para gerar novos negócios.

Cumpra combinados e faça com qualidade

Deveria ser o primeiro item mas resolvi deixá-lo para o final para que fique mais fresco na sua memória.

É da mais absoluta importância para um profissional que ele cumpra aquilo que foi combinado com o cliente. E mais do que isso… é importante que tudo seja feito com a maior qualidade.

Cumprir com o combinado manterá o seu cliente fiel à você. Fazer isso com qualidade transformará ele num canal de vendas.

Gostou desse artigo?

Assine a minha newsletter quinzenal e receba artigos sobre Programação, Python, Django, carreira e empreendedorismo.

[mc4wp_form]

Trabalho Remoto

O programador, empresário e investidor Paul Graham publicou um artigo afirmando que as leis de imigração americanas impedem que talentos de outros países possam trabalhar nos EUA. Em resposta à esse artigo alguns programadores e empresários conhecidos sugeriram à ele que o trabalho remoto seria uma solução melhor para esse problema. Outros reforçaram a opinião do Paul Graham e começou aí a discussão.

Já faz quase 2 anos que trabalho remotamente para uma empresa de São Paulo a partir de Curitiba. Eu fui o segundo funcionário da empresa a ser contratado para trabalhar desse jeito. Hoje já temos 7 profissionais trabalhando assim.

Não vou mentir pra vocês: no começo foi bem complicado. Erramos de todas as formas e falhamos miseravelmente várias vezes até conseguirmos fazer as coisas funcionarem bem. Ainda está longe da perfeição mas a empresa, as equipes e os remotos estão se esforçando muito para melhorar.

Entre o caos e a situação em que estamos hoje houve um “turning point”. Um momento em que decidimos fazer a coisa funcionar.

Primeiro resolvemos estudar o assunto. Eu comprei livros e mais livros, assisti palestras e mais palestras, busquei referências em artigos, e refleti muito sobre nossos problemas.

O problema principal era a interação deficitária da equipe. Mesmo sendo uma equipe ágil que pratica SCRUM existiam muitos vícios na forma como os membros da equipe interagia. Era uma interação “olho-no-olho”, extremamente verbal (offline) e síncrona.

Essas três características são péssimas:

  • “Olho-no-Olho”: as reuniões diárias eram feitas com todos de pé (standup meeting) com todos os integrantes no escritório. Não preciso dizer que isso não rola para equipes remotas, certo?
  • Comunicação Verbal Offline: para uma equipe remota toda comunicação verbal já é deficitária (precisa de headset, conexão, ajustar o áudio, etc). A comunicação verbal “offline” é ainda pior. Eles decidiam coisas lá em SP e a gente nem ficava sabendo.
  • Comunicação Síncrona é aquela em que os intelocutores precisam estar “conectados” simultaneamente para transmitir a mensagem. Mesmo para trabalho local ela é ruim porque é uma comunicação que interrompe as pessoas. Exige a atenção delas. É o “cutucão no ombro”, o chamar no Skype, a “reuniãozinha rápida”, etc.

Enquanto ia refletindo sobre isso eu me lembrei sobre como foi trabalhar na Conectiva. A Conectiva foi o lugar onde trabalhei onde a comunicação da empresa era um exemplo de eficiência. Toda a comunicação da empresa funcionava pelos meios eletrônicos de forma extremamente eficaz:

  • Listas de Discussão (mailman com histórico online): toda a comunicação “séria” da empresa era feita por email em listas. Todos policiavam o bom uso do email e davam puxões de orelha em quem não usava do jeito certo. Existia uma hierarquia de listas (toda a empresa, equipe técnica, desenvolvimento, etc) e listas para coisas informais (off-topic). O email era para comunicação assíncrona e gerava longas threads muito bem escritas e organizadas onde se discutia quase tudo. Não era para preguiçosos porque exigia bastante esmero dos participantes.
  • IRC: a empresa tinha um servidor interno de IRC com salas organizadas também de forma hierárquica. Era usado majoritariamente pela equipe técnica (a parte administrativa da empresa usava ICQ… lembrem-se que era 2000). Aqui rolava a comunicação síncrona e a coordenação do trabalho.

Observem que não tinha nada de mais nas ferramentas. Mas elas eram usadas de forma correta e havia um policiamento por parte de todos para que isso não fosse desvirtuado.

Olhando pra isso é possível enxergar que a gente trabalhava “remotamente” no mesmo escritório. Não fazia diferença o local onde a gente estava. O trabalho aconteceria de qualquer forma porque tudo era comunicado o tempo todo pelos meios eletrônicos (salvo raras exceções e brincadeiras entre os integrantes da equipe).

Percebi que “tinha algo ali” mas guardei isso comigo.

Em 2013 a empresa onde trabalho mandou um ônibus para Brasília onde participaríamos da PythonBrasil[9]. Em Brasília tudo é “longe” e esse ônibus virou um transporte extra-oficial dos participantes do evento. Um dos convidados do ônibus foi o Sidnei da Silva e na época o Sidnei trabalhava remotamente para a Canonical. Uma grande oportunidade de aprender algo.

Entre as várias dicas que ele nos passou teve uma que me chamou a atenção: “a equipe tem que saber trabalhar remotamente mesmo que esteja no mesmo local”. Bingo!

Meu gerente (que também pesquisava o assunto) estava do meu lado quando o Sidnei disse isso e também percebeu a importância dessas palavras. Voltamos para o trabalho decididos a implantar esse sistema.

Não foi fácil mas conseguimos. Fizemos o seguinte:

  • “Forçamos” o uso de um headset para todos os integrantes da equipe (inclusive quem está no escritório);
  • As Dailys (usamos SCRUM) seriam feitas online (usamos o Mumble em um servidor próprio);
  • Movemos a maioria das conversas e discussões para os meios eletrônicos (isso diminuiu as interrupções causadas pelo “cutucão no ombro”);
  • Migramos todos os nossos whiteboards e post-its para o mundo virtual (usamos Scrumdo mas estamos avaliando alternativas melhores);
  • Usamos Slack e estamos adorando. Avaliamos e usamos outras (IRC próprio, Grove.io, Hipchat) mas o Slack detona;
  • Pareamos com tmate (temos um servidor pra isso) ou Teamviewer mas como a “fauna” de editores de texto e IDEs na empresa é abundante estamos sempre procurando algo melhor. E o Google Hangout é uma bosta. Nem adianta recomendar ele pra gente 😀 (Floobits?);
  • Já usávamos Github mas passamos a aproveitar melhor o sistema.

Tudo isso foi legal e bacana mas o que realmente foi importante nessa mudança foi o compromisso de cada um para que o trabalho desse certo. Começamos a nos policiar e “brigar” para que as coisas funcionassem do jeito certo.

Daily Meeting acontecendo no escritório

Foi importante mostrar para a equipe de SP que, se isso desse certo, eles também poderiam se beneficiar. Poderiam escolher entre ficar em casa ou encarar o trânsito de SP, por exemplo. Alguns poderiam até trabalhar mochilando!

Para a empresa? Só sucesso… ela consegue contratar os melhores funcionários mesmo que eles não queiram morar em SP. Conseguem economizar com infra-estrutura e com folha de pagamento (um salário bom em SP é excelente no interior de SC).

Quando eu era empresário sonhava em ter um escritório bacana cheio de gente foda trabalhando comigo. Hoje sou um defensor ferrenho do trabalho remoto. Acho que os governos deveriam incentivar essa forma de trabalho até mesmo como forma de melhorar o trânsito das grandes cidades.

Gostou desse artigo?

Assine a minha newsletter quinzenal e receba artigos sobre Programação, Python, Django, carreira e empreendedorismo.

[mc4wp_form]

O Melhor da Internet…

… pelo menos na minha opinião 🙂

Desde criança fui uma pessoa curiosa. Na época eu era chamado de “nerd” ou de “CDF” (pra ser nerd hoje basta gostar de Star Wars).

Procurar informações para satisfazer essa curiosidade nos anos 80 significava garimpar informações como um mineiro procura por ouro. A gente usava bancas de revistas, bibliotecas, sebos, livrarias, televisão, rádios, etc. E boa parte disso só estava disponível para quem podia pagar.

Mesmo sendo trabalhoso era bem divertido e gratificante buscar informações desse jeito. A gente ia atrás das informações e não o contrário.

Online: information overload

A primeira vez que consegui uma informação no mundo digital foi via BBS. Fiquei superfeliz por encontrar a lista de interrupções do Ralf Brown. Uma BBS tem toda informação que cabia em alguns CDROMs no computador do dono da BBS e isso já era muito mais do que um ser humano curioso podia lidar.

Quando tive contato com a Internet, com os buscadores (Cadê?, Yahoo!, …) e, posteriormente, com os feeds a coisa saiu do controle. Hoje eu tenho na minha lista de leitura uma quantidade de conteúdo suficiente para consumir durante toda minha vida. E a coisa não para de crescer.

Hoje eu assino vários feeds, sigo várias pessoas importantes, assino muitas newsletters e uma boa fila de livros para ler… o volume de informações que chega é absurdo e, por causa disso, precisei criar algumas regrinhas para melhorar a gestão disso tudo.

Gestão de consumo de informação

Uso três técnicas para me ajudar nessa tarefa: filtragem humana, fila de leitura, deduplicação e priorização por pares.

Filtragem humana

A quantidade de informação para ser consumida cresceu de modo tão intenso que precisei criar mecanismos para filtrar só aquilo que fosse relevante. E é aí que o bicho pega. Se antigamente era difícil garimpar informação na escassez o mesmo se mostrou muito mais difícil na abundância.

Alguns sistemas digitais até te ajudam nessa tarefa (ex. buscadores) mas nada supera os sistemas de “computação humana” (Human Computation).

Quando o Google Reader existia e tinha a funcionalidade de compartilhar artigos entre os seus usuários comecei a implementar um tipo de “filtragem humana”. Descadastrei de vários feeds que meus amigos acompanhavam e passei a ler apenas o que eles compartilhavam. Exemplo: eu assinava o feed do XKCD junto com outros colegas e eles viviam compartilhando as melhores tirinhas. Descadastrando o feed e seguindo esses colegas eu teria disponível só às melhores tirinhas e controlaria o aumento da minha fila de leitura.

Hoje eu faço isso com o Twitter. Dou follow em amigos que seguem sites importantes e sigo alguns sites importantes para compartilhar o conteúdo com eles. O interessante é que ninguém planejou isso. Foi algo criado organicamente.

Outra forma de filtragem humana é a “editorial”. Alguém muito bem informado ou comunidades se reunem para determinar a relevância das informações.

Os sites que melhor trabalham isso em comunidades são os agregadores (ex. Hacker News, Reddit, …) e sites de QA (ex. StackOverflow, Quora, …). Já as pessoas que fazem esse trabalho de forma individualizada, geralmente, usam blogs ou newsletters.

Fila de leitura

Não dá pra parar para ler todas as coisas interessantes que aparecem no momento que elas aparecem. Digo mais: não dá nem para avaliar se essas coisas são importantes ou não. Então eu faço o básico: mando o link direto para minha fila de leitura.

Uso o Instapaper como ferramenta para gerenciar essa fila mas também tem o Pocket. Acho que o Pocket é tecnicamente melhor mas o importador deles é uma porcaria e como o Instapaper me atende satisfatoriamente continuo com eles.

Tenho Instapaper no celular e usava a funcionalidade de exportar para Kindle (parei porque o kindle também já está entupido de coisas pra ler).

A tática para manter a lista de leitura em um tamanho administrável é: algumas vezes por semana tenho como objetivo ler mais artigos do que adicionei desde a última pausa para leitura.

Nem sempre é possível cumprir essa meta e o resultado é que tenho aproximadamente 400 artigos para ler.

Deduplicação

Se percebo que uma fonte de informação está só duplicando informações que já chegaram até mim por outras vias eu reavalio esse canal. Se o nível de duplicação que ele acrescenta é grande eu simplesmente desligo esse canal.

Priorização por pares

Eu priorizo a leitura do conteúdo pelo número de pares (pessoas) que recomendaram o mesmo material. Exemplo: três amigos cuja opinião literária eu respeito muito indicaram o mesmo livro (ebook). Isso e o fato de que Ridley Scott está fazendo um filme com a história desse livro obviamente fizeram eu comprá-lo e começar a ler.

O Melhor da Internet

Com esse método acabo esbarrando em coisas muito interessantes que acabo compartilhando no meu Twitter. Mas para facilitar a vida das pessoas resolvi criar uma newsletter: O Melhor da Internet.

Agora você pode me usar como filtro humano 😀

Quinzenalmente farei um resumo contendo links e uma breve descrição dos melhores artigos e sites que vi desde que comecei a usar a internet. Vou priorizar material recente mas posso incluir coisas antigas que sejam relevantes. Esse resumo será enviado para o email dos assinantes que se cadastrarem no formulário abaixo.

Os tópicos principais serão:

  • Programação – Python, Django, Web, TDD, …
  • Empreendedorismo – side-project, bootstrap, lifestyle business, passive-income-de-verdade, …
  • Carreira – produtividade, boas práticas profissionais, …
  • “Off-topic” – DIY/eletrônica, retrocomputação, jogos, tirinhas, …

[mc4wp_form]

O plano é publicar a primeira edição sai no dia 21 de julho de 2014.

Foto: lecates

E os programadores, onde erram?

O @marionogueira provocou e eu vou responder.

Carreira de programador

Mas antes vou explicar porque eu compartilho da visão de que o trabalho de desenvolvedor guarda semelhanças com o trabalho de um artista (importante dar destaque à palavra “semelhança” para não pensar que as coisas são iguais).

Como programador você pega uma especificação abstrata que se parece com uma ‘inspiração’ e começa a trabalhar nela até obter algo ‘bruto’, aí você vai lapidando (iterando) sobre esse trabalho, simplificando, e aproximando o software daquela inspiração (especificação).

Nesse processo o programador vai deixando seu “estilo” no código. Na escolha de algorítmos, de estruturas de dados, nos textos de comentários e até mesmo no “Coding Style”. Essas características são tão notáveis que depois de um tempo é possível identificar o autor do código mesmo quando ele não está ‘assinado’.

Uma diferença importante entre o trabalho de artistas e de programadores é que raramente vemos o trabalho em equipe (times) no universo das artes e o mesmo é quase uma regra no mundo do software.

Mas daqui para frente eu vou falar sobre um tipo específico de artistas: aqueles que trabalham sob encomenda pintando retratos de reis e nobres para garantir o seu sustento. E para ilustrar o meu raciocínio vou usar uma das obras de arte mais conhecidas no mundo: a Monalisa.

A Monalisa (La Gioconda) foi uma obra encomendada por Francesco del Giocondo a Leonardo Da Vinci. Existe muitas versões, mitos e mistérios que cercam essa obra mas vamos nos ater à “história oficial”.

Francesco passou uma especificação para Da Vinci (ele queria um retrato de sua esposa Lisa Gherardini) e provavelmente especificou prazo e preço. Ou talvez tenham feito um contrato de escopo aberto? Não sei, não estudei essa história muito a fundo.

Leonardo Da Vinci, então, fez os primeiros esboços e foi apresentando esses esboços ao contratante. Talvez não tenha feito isso porque o contratante confiava plenamente na capacidade de entrega dele. Mas não teria sido vergonha se tivesse que apresentar os esboços no meio da execução do projeto.

O resultado final foi um trabalho encomendado, executado no prazo combinado, à um custo determinado e que, mesmo assim, era uma obra de arte.

Curiosamente o escritório da Triveos é vizinho de uma escola de pintura. Todo dia passo em frente à sala de aula e vejo o trabalho dos alunos. É fácil perceber que não tem nenhum Leonardo Da Vinci ali (por enquanto). Falta-lhes experiência. Prática. Com o tempo e empenho eles se transformarão em bons artistas. Talvez gênios.

O mesmo acontece com os programadores. Só com a prática, a experiência, e com o domínio da técnica um programador se tornará um ‘artista’ de verdade.

Mas voltando à questão levantada pelo @marionogueira…

O ‘mundo’ está errado no gerenciamento dos programadores quando eles mudam escopo, prazo e custo dos projetos a todo o instante e ainda exigem uma obra de arte como resultado do trabalho. Ou quando não permitem que o ‘artista’ trabalhe ao seu modo.

A Monalisa seria uma obra de arte se, durante o seu desenvolvimento, o contratante desse palpites sobre as cores e cenários deveriam ser usados na obra?

Mas os programadores também erram!

Erram quando aceitam o desafio de desenvolver uma obra de arte sem ter o domínio adequado da técnica, a prática e a experiência necessária para transformar aquela especificação em arte.

Em projetos ideais onde o escopo é claro, o prazo é razoável e custo está sob controle os programadores falham quando não compreendem que, mesmo tendo sido encomendada, a ‘obra de arte’ é dele também. Sem essa compreensão eles deixam de se comprometer com sua execução.

Mesmo tendo sido encomendada, Da Vinci não fez a Monalisa ‘nas coxas’. Ele fez o máximo possível para entregar uma obra de arte única. Isso fica claro em projetos open-source onde a obra e o nome do artista fica público.

Um artista não precisa de foco e disciplina para se inspirar. Aliás, isso pode até atrapalhar. Mas para executar a obra é necessário muito foco e muita disciplina. Principalmente se a obra foi encomendada e tem custos e prazos pré-estabelecidos.

O programador falha quando ele não tem foco e disciplina no seu trabalho. Twitter, MSN, GTalk, IRC e outros sugadores de foco, hoje, ficam mais tempo em funcionamento do que a IDEs, editor de textos e outras ferramentas de desenvolvimento. Eu sei. Eu vivo isso.

Fora isso eles podem errar em outras questões que envolvem relacionamento interpessoal, trabalho em equipe, ética, etc. Mas nessas questões todos podem errar.

Como garantir um emprego de desenvolvedor

Foto: Robert Lowe

Post rápido e ligeiro com uma lista de atributos que certamente vão garantir a sua vaga como desenvolvedor em qualquer empresa que valha a pena trabalhar.

Cada atributo tem um dos graus de importância abaixo (do mais importante para o menos importante):

  1. Vital – característica mais do que essencial para vagas de desenvolvedor ou para qualquer outro tipo de posição.
  2. Essencial – característica imprescindível para um desenvolvedor.
  3. Importante – característica importante mas não imprescindível. Pode-se contratar um desenvolvedor que não tenha essa característica desde que haja um compromisso do mesmo em desenvolvê-la.
  4. “Plus” – não faz muita diferença mas pode ser uma característica que pode desempatar (a favor de quem a tem) numa disputa entre dois ou mais candidatos.
  5. Desnecessária – não faz diferença alguma.
  6. Condenável – característica que pode depor contra a sua candidatura.

O que está escrito aqui é a minha visão sobre o assunto. Algumas empresas contratantes podem divergir no grau de importância de cada atributo. Outras, por questões legais, podem exigir determinada característica listada como:

  • Comunicação (vital) – comunicação escrita e verbal, capacidade de argumentação e de expressar idéias e conceitos.
  • Prazer em programar (vital) – você programa nas horas vagas? Não? Então desista. Corra atrás de trabalhar com aquilo que você faz nas horas vagas. Todos ficarão gratos.
  • Prazer por aprender coisas novas (vital) – Veja… eu disse “prazer por” e não “interesse em”.
  • Inglês para leitura (vital) – não dá mais tempo de esperar por traduções de documentação.
  • Programação (essencial) – tem que saber teoria e prática. Conhecer algoritmos, estruturas de dados, conceitos de OO, paradigmas de programação, teoria da computação, matemática, …
  • Familizarização rápida com ferramentas (essencial) – você é capaz de corrigir um bug numa aplicação escrita numa linguagem que você não conhece em quanto tempo? Consegue produzir código numa linguagem nova em menos de uma semana?
  • Inglês para escrita (essencial) – grande parte dos softwares, bibliotecas e sistemas que usamos hoje são desenvolvidos por estrangeiros. Freqüentemente precisamos trocar um e-mail com esses desenvolvedores.
  • Conhecer bem ao menos uma linguagem (essencial) – essa linguagem varia de acordo com o que você deseja desenvolver, mas ela tem que ser uma espécie de ‘segundo idioma’ seu. No meu caso essa linguagem é Python, mas poderia ser outra.
  • Inglês conversação (importante) – grande parte dos lugares bacanas pra se trabalhar, hoje, são estrangeiros, tem filiais fora do país ou estão contratando estrangeiros pros seus times. Poder conversar com eles é importante.
  • Ter familiaridade com ‘linguagens chave’ (importante) – algumas linguagens de programação estão presentes em tantos lugares que não é mais possível desconhecê-las: assembly de pelo menos 1 plataforma, C, Shell Script, linguagem funcional (fico devendo essa :D), linguagem OO (Java, Smalltalk, Python, Ruby, …).
  • Participação em projetos FLOSS (importante) – universo perfeito para exercitar, experimentar, participar, desenvolver, aperfeiçoar, … todas as características listadas aqui. Alguns lugares onde trabalhei sequer pedia curriculums para contratar um desenvolvedor e usavam só a participação dos mesmos em projetos FLOSS
  • Formação acadêmica (plus) – desde que seja numa boa faculdade (USP, Unesp, UNICAMP, UF*, UTF*, PUC*, …) podem indicar que os alunos aprenderam alguns fundamentos importantes de programação. O convívio social dos alunos para estudo, execução de projetos e trabalhos também acrescenta.
  • Certificações (desnecessária) – empresas que pedem ou avaliam certificações não podem ser empresas onde valha a pena trabalhar. Empresas que usam certificações são aquelas que são incapazes de avaliar corretamente os candidatos e ‘terceirizam’ essa tarefa para as entidades certificadoras. Uma empresa incapaz de avaliar um candidato não pode ser capaz de lhe dar boas condições de trabalho.
  • “Corporacionismo” (condenável) – profissionais que falam “frases que agregam valor e aumentam a sinergia do time junior de colaboradores” ou que acham fundamental a existência de uma regulamentação no mercado de trabalho de TI geralmente são aqueles que não querem ou não conseguem se destacar como desenvolvedor por conta própria e precisa de uma ‘mãozinha’ do governo pra isso.

Esse artigo descreve algumas características que um desenvolvedor deve ter para conseguir um emprego. Mas se o desenvolvedor quiser empreender e montar o seu próprio negócio, ele precisa das mesmas características? Sim, mas com graus de importância diferentes. Além desses atributos são necessários alguns outros que tentarei abordar em outro artigo.

Gostou desse artigo?

Assine a minha newsletter quinzenal e receba artigos sobre Programação, Python, Django, carreira e empreendedorismo.

[mc4wp_form]

Desempregado ou despreparado?

Foto: Roswitha Siedelberg

Nessa semana a empresa onde trabalho me pediu uma ajuda para conseguir contratar um programador Python com uma certa urgência. Como eu sou o moderador da lista Python Brasil optei por enviar um e-mail ligeiramente diferente para a lista de discussão avisando da oportunidade. O e-mail terminava assim:

Requisitos:
 - Desenvolver pra Linux (necessário)
 - Desenvolver em Python (necessário)
 - Saber inglês (necessário)
 - Se divertir programando (necessário)
 - Desenvolver em C/C++ (plus)
 - Desenvolver Gtk+/GNOME (combo plus)
 - Ter estudado ciências ou engenharia da computação (mega-combo plus)
 - Conhecer bem plataforma ARM (qual é o teu telefone?)

A partir daí eu fui recebendo e-mails e mais e-mails com curriculums de candidatos à vaga e pude ver que os erros básicos que já vi em outras oportunidades continuam sendo cometidos.

Pessoal, as coisas que eu vou dizer aqui são sérias e a forma com que vou dizê-las pode ser um tanto contundente. Mas entendam que é para o bem de quem pretende conseguir um trabalho interessante. Algumas pessoas irão se reconhecer no que eu vou dizer abaixo mas para elas eu quero dizer que não é nada pessoal são apenas conselhos de alguém que trabalhou em bons lugares.

Não lamente, corra atrás

Uma quantidade considerável dos e-mails que recebi dessa vez (e de outras vezes) são de lamentação. Algo do tipo “Pôxa, que pena que eu não programo em Python muito bem :(“.

Vamos ser inteligentes. A oferta diz: “Desenvolver em Python (necessário)”. Que parte de “necessário” não foi possível entender do texto? A gente quer um candidato à vaga não uma pessoa precisando de afago.

No lugar de se lamentar por “não saber Python” você deveria é correr atrás de aprender. Nunca gastei um único tostão pra aprender Python, logo, não ter grana não serve como desculpa. Quando aprendi Python trabalhava em dois empregos e ainda tentava fazer uma faculdade. Isso também elimina a falta de tempo como desculpa.

Mesmo que você tenha uma boa desculpa pra não ter aprendido Python você vai ter que pensar sobre o que você realmente quer da sua vida: a vaga ou alimentar sua desculpa.

Se você não tem um bom projeto em Python para trabalhar fique sabendo que tem milhares de projetos de SL esperando pela sua ajuda. Escolha um que te faça feliz e toca o barco.

O salário será aquele que você irá merecer

Um outro tanto de e-mails que recebi tinham a pergunta: “Qual é o salário?” e na oferta estava escrito: “Salário acima da média local”.

Não se pergunta o salário sem você ter sido sequer entrevistado. O salário é a última coisa que se fala com o candidato. Se tá dizendo que é acima da média local significa que é um salário mais alto do que o que você conseguiria por aqui, entende ou quer que eu desenhe?

Sei que isso é utópico e que as “coisas práticas” são importantes, mas você já pensou que a empresa está te contratando para ajudá-la e não para ter mais um valor saindo mensalmente do seu caixa? Já pensou que você será remunerado na mesma proporção da sua contribuição à empresa?

Se você contribui pouco para a empresa X você vai ganhar pouco. Se a empresa Y diz que paga acima da média local significa que você vai ganhar mais que a empresa X mesmo fazendo pouco.

Quando eu tenho vontade de trabalhar numa empresa eu penso na quantidade de coisas legais que eu posso fazer nessa empresa e não em quanto eu vou ganhar. Só no final do processo é que me interesso pela remuneração.

Ofereça-se apenas para vagas que você consegue trabalhar

Esse é o pior tipo. É a famosa metralhadora giratória de curriculums. Parece que o cara tem um filtro no cliente de e-mail que pega e-mails com as palavras “vaga” ou “emprego” e já dá um reply automático com seu curriculum. Quando eu era o dono da empresa e ia contratar eu não só descartava esses curriculums como ainda marcava o nome do indivíduo na lista de “nunca contratar”.

A vaga é para “desenvolvedor” e não para “administrador de redes”! Se você não consegue ler e interpretar um texto com uma oferta de emprego é bem provável que você também não consiga realizar a tarefa para a qual você seria contratado.

Se você quer “mudar de ares” comece a estudar sobre “desenvolvimento” e mande esse tipo de informação no seu curriculum e não que você sabe instalar “postfix”, “manutenção de hardware” ou coisas do tipo.

Se você não sabe se consegue, imagine o contratante

Se você me manda um e-mail dizendo “Eu programo em Python mas não sei se dou conta de fazer o que vocês fazem” eu (no caso a empresa contratante) devo pensar o que?

Se nem você sabe se dá conta imagina eu 🙂 Mesmo que eu te conheça pessoalmente e a gente tenha conversado sobre o trabalho é você quem tem que bater no peito e bradar: “Eu consigo!”.

Então economize o seu tempo e o meu. Se você não tem certeza da sua capacidade não envie e-mail nenhum. Se você sabe que consegue mande direto o seu curriculum e se candidate à vaga.

Analise a vaga em profundidade

Antes de mandar o seu belo curriculum pra uma vaga procure saber mais sobre a empresa. Personalize o seu curriculum de forma a deixá-lo mais atraente para a tal vaga. Seja inteligente e perspicaz ao enviá-la (mas por favor polpe-se ao trabalho de inventar moda).

Eu tenho umas 4 versões do meu curriculum (e uma versão em inglês para cada uma das 4) e sempre pego ele e edito antes de enviá-lo.

Vamos à uma breve análise dos erros que vi:

  • Página 33 de 150: Não rola, né? 🙂 Se não dá pra resumir as coisas que você fez simplesmente elimine alguns dos empregos que você teve e não acrescentam nada ao seu CV. Por exemplo: eu trabalhei 3 anos em uma agência de publicidade como “publicitário” (ênfase nas aspas). Não preciso colocar isso pra uma vaga de desenvolvedor.
  • Olha a foto! Buuu!: Na mensagem tá pedindo “boa aparência”? Se não tá pedindo significa que tua aparência não importa, certo? Se tua aparência não importa a foto não serve pra nada. Pior: e se você for feio? Num eventual “empate” para a vaga a sua feiura pode te eliminar, mesmo em situações onde ela não seria importante.
  • Mexe com Linux? Pega o .doc: Erro primário esse. Se a vaga fosse pra trabalhar na Microsoft você mandaria seu curriculum no formato .odt? Porque você manda um .doc para trabalhar numa empresa que mexe com Linux? Ok, o OpenOffice “abre” esse tipo de arquivo mas o arquivo .doc mostra habilidade em que tipo de ambiente de trabalho? Na dúvida mande um .pdf, um .txt ou, como eu faço, um .html.

Eu também uso esse conselho para dizer aos candidatos: inverta o papel de quem escolhe quem. Invista no seu aprimoramento muito mais do que o exigido pelo “mercado” e apresente-se numa situação onde a empresa quer contratá-lo.

Eu já vi donos e gerentes de empresa fazendo leilão para levar um candidato. Se você é bom o suficiente para estar nessa situação você concordará comigo que é muito mais confortável.

Mas seja honesto ao ser “leiloado”. Não blefe. Eu já vi ótimos programadores que se queimaram em ambas as empresas porque descobriram o blefe. Acabou sem nenhum emprego e com a imagem arranhada em um mercado onde todo mundo se conhece.

Você trabalha no emprego perfeito, me aconselhe profissionalmente

Pessoal, eu não sou o Max Gehringer. O máximo que eu posso dar de dica é para o tipo de trabalho que eu faço. As dicas do Max são legais para casos mais genéricos mas também não precisa levá-lo à sério demais porque senão você acaba virando mais um daqueles candidatos “robôs” cheio de respostas prontas e pré-fabricadas.

Como teve mais de uma pessoa que me perguntou sobre “investir no aprendizado de Python” eu vou falar um pouco sobre esse caso específico:

Invista o seu tempo em algo que te deixa feliz. Se você gosta de programar em Python invista em Python. Se gosta de programar mas não importa a linguagem programe em várias delas.

Se você não gosta de programar? Vai fazer o que você gosta de fazer. Sai fora dessa área. Evite perder o seu tempo e o de outras pessoas que gostam de trabalhar com isso.

E tem outra coisa: usar o trabalho nessa área como meio para ganhar dinheiro para no futuro atuar em outra área menos rentável. Isso é péssimo. Atue na área “menos rentável” e faça-a se tornar rentável.

Pega o meu curriculum praquela vaga do mês passado

Um certo dia eu ofereci uma vaga em uma empresa onde trabalhava que precisava ser preenchida com urgência e recebemos curriculums para essa vaga por mais de 3 meses.

Se você vê que a oferta foi feita à mais de uma semana desiste.

Se tiver uma gota de esperança de que a vaga não foi preenchida ou tem “inside informations” de que a vaga não foi preenchida tudo bem. Mas se não for esse o caso fica a lição pra você ficar mais atento.

Gostou desse artigo?

Assine a minha newsletter quinzenal e receba artigos sobre Programação, Python, Django, carreira e empreendedorismo.

[mc4wp_form]

Como aprender inglês sozinho (self-taught)

Eu adoro aprender coisas novas, mas eu gosto de ter o controle sobre o meu aprendizado. Não tenho preguiça de ler nem de ouvir os ensinamentos, mas gosto de poder escolher quando, como e quais deles ouvir.

Como quase todo mundo eu também tenho preferência em aprender as coisas que eu gosto mais e não gosto de “perder tempo” aprendendo coisas que eu não gosto. Eu coloquei “perder tempo” entre aspas porque acredito que “perder tempo” e “aprender” são dois conceitos que dificilmente andam junto (ou ao menos não deveriam andar junto).

Pois bem, eu disse tudo isso porque eu não gosto de aprender idiomas. Não importa qual seja. Odiei aprender português enquanto estava na escola e não me esforcei em nada para aprender inglês nas escolas por onde passei (maioria de escolas públicas). Deixei muitos professores revoltados com o fato de que eu não prestava atenção à nenhuma aula e ainda assim conseguia boas notas. Mal sabiam eles que eu estudava a matéria que cairia nas provas. Só que do meu jeito e quando eu queria.

Já comecei uns 10 cursos de inglês e até aprendi um pouco neles mas depois do segundo ou terceiro mês eu já estava desanimado e desestimulado a continuar. Isso acontece porque eu estou tendo que aprender algo que eu não gosto nas horas que os cursos determinavam e do jeito que eles queriam. Desse jeito não rola.

Mas e aí? Eu preciso saber inglês no meu trabalho. E muito. Como eu faço pra aprender inglês? Decidi fazer um auto-aprendizado de inglês. E a minha professora seria a a vida offline e online.

Mas eu não sabia nem por onde começar até que descobri o “poder dos blogs“, dos podcastings e até mesmo dos antigos métodos que usam música e filmes. Coletei alguns deles que listo abaixo e adquiri 3 livros essenciais para o aprendizado do idioma.

BBC-Logo

TV

Assista o noticiário da BBC. Os apresentadores britânicos tem uma dicção melhor e falam mais devagar. É bem melhor para iniciantes do que a CNN 🙂

Internet / Aplicativos

A Internet e os smartphones disponibilizam diversas ferramentas de apoio aos estudantes de vários idiomas. Fiz uma pequena seleção dos que mais gosto. Se você tiver outras sugestões envie através dos comentários.

Duolingo

duolingoEsse aplicativo precisava ter sido inventado antes. Ele é fantástico. Transforma o estudo de inglês em um tipo de partida de “casual game” onde você vai passando de fase, ganhando prêmios (virtuais) conforme aprende um idioma.

Estudei inglês com ele mas existem outros idiomas. E o melhor: totalmente gratuito (não tem nem que comprar créditos de nada).

Esse projeto foi criado por um ex-funcionário do Google que usa o imenso contingente de pessoas que jogam o Duolingo para alimentar com dados sistemas computacionais que fazem traduções de documentos.

English Experts

Fornece um fórum com muitos usuários que podem te ajudar com diversos problemas. Funciona em um modelo de perguntas e respostas que vai premiando os participantes mais ativos.

Tecla SAP

Com um enfoque mais divertido e com histórias engraçadas de pessoas que se deram mal por não saberem inglês é outra boa dica para quem está aprendendo inglês.

Infelizmente os feeds não funcionam muito bem e não são completos.

English as a Second Language Podcast

O mais bem produzido dos podcasts que avaliei é gratuito (exceto se você quiser adquirir o material auxiliar) e tem conversas usadas no dia-a-dia das pessoas seguido de explicações sobre o diálogo.

Livros

Os livros que apresento aqui são ferramentas de apoio e consulta nos seus estudos. Nenhum deles ensina inglês mas todos darão suporte aos seus esforços de aprender.

Oxford Dictionary of Englishoxford-dict

Um dicionário Inglês/Inglês é essencial. Eu sei que é algo caro mas, acredite, eu já comprei um “Michaelis” e considero o dinheiro gasto com ele perdido. A diferença da qualidade do dicionário Oxford e a sua utilidade justificam o gasto extra.

Pense também que esse dicionário lhe servirá por toda a vida e que com essas dicas que estou dando você já está economizando bastante dinheiro.

Oxford Phrasal Verbs

Eu ainda não tenho esse e por essa razão tenho que ficar emprestando o de um companheiro de trabalho. O número de variantes de phrasal verbs é tão grande que merece um dicionário exclusivo para tratar deles. Phrasal Verbs são aquelas expressões compostas de verbo+advérbio ou verbo+preposição tipo: “break down”, “blow up”, “check in”, etc.

Inglês + Fácil Gramática

Essa é uma gramática de consulta rápida. Serve para tirar dúvidas esporádicas sobre gramática. A aquisição deste livro é opcional. É um dos que menos uso apesar de já ter me ajudado algumas vezes.

Longman Dicionário Escolar Inglês/Português-Português/Inglês

Esse dicionário não é muito completo mas o “conjunto da obra” torna-o excelente para aqueles que estão aprendendo inglês agora.

O dicionário português/inglês é extremamente útil para enriquecer nosso vocabulário, os verbetes são fartamente ilustrados, o CD-ROM é prático, os ‘boxes’ explicativos para expressões e gírias são fantásticos e o preço é excelente.

Não deve ser o único dicionário em sua casa, mas é um bom começo. Aqui em casa meu filho usa o tempo todo.

Hábitos Saudáveis

Além do material indicado acima eu pratico alguns hábitos saudáveis para aperfeiçoar meus conhecimentos em inglês.

Filmes

Gosto muito de cinema e tenho o hábito de ver o mesmo filme várias vezes (se o filme for bom, é claro). Quando precisei aprender inglês passei a rever os filmes com a legenda em inglês.

O áudio e a legenda não são iguais mas as palavras principais estão lá. Como eu já conheço a história (assisti com legenda em português antes) o cérebro passa a assimilar o som das palavras (reforçado pela legenda). Se o filme for realmente bom eu ainda tento assistir mais uma vez sem nenhuma legenda.

Músicas

Escute muito à músicas em inglês e, quando se sentir confortável, cante (mesmo no “embromation”) essas músicas.

Depois procure a letra da música na internet (Google: nome-da-música lyrics) e tente cantar lendo a letra. É impressionante a quantidade de coisas que a gente achava que estava certo e não estavam.

Traduzir a música pode ser interessante e buscar o significado dela melhor ainda.

Outros

  • No seu computador: instale tudo em inglês.
  • Participe de grupos de bate-papo em inglês na internet ou em sua cidade. Em cidades maiores é fácil encontrar um grupo desses.

Pratique

Não tenha medo ou vergonha de se expressar em inglês mesmo que você ainda não esteja fluente. Lembre-se que o teu interlocutor não deve saber nada de português também 😀 O máximo que pode acontecer é você ser corrigido e aprender um pouco mais (só um babaca te zoaria por falar errado).

Mais do que ter esse material terei que ter uma grande disciplina para dedicar tempo necessário para estudar.

Atualização: esse artigo foi praticamente reescrito no dia 2/7/2014.

Gostou desse artigo?

Assine a minha newsletter quinzenal e receba artigos sobre Programação, Python, Django, carreira e empreendedorismo.

[mc4wp_form]

Conhecimentos fundamentais

Ja faz algum tempo que tenho notado em diversas listas de discussões da área de informática que alguns profissionais de nossa área parecem estar entrando para o mercado de trabalho sem ao menos ter alguns conhecimentos mais fundamentais sobre computação.

Um “Conhecimento Fundamental” não é um “Conhecimento Essencial” mas é extremamente útil ter esse tipo de conhecimento quando se trabalha com qualquer coisa.

Na minha simplória definição um “Conhecimento Fundamental” é um tipo de conhecimento que não necessariamente é aplicado diretamente na resolução de um problema mas que certamente enriquece muito a ‘teia’ de informações disponíveis em nossa mente. Esse enriquecimento faz com que a gente consiga apresentar soluções muito mais criativas e eficientes para determinados problemas.

Para esclarecer um pouco melhor o que eu estou tentando dizer vou citar algumas situações reais que ocorreram com algumas pessoas próximas à mim.

Operações bit-a-bit

Quando eu fiz escola técnica no segundo grau eu tive um professor (Victor) que passou um semestre inteiro explicando aritmética binária, operações bit-a-bit e um básico de lógica booleana (que no semestre seguinte foi complementada de maneira adequada por outro professor).

Nessa época vários colegas de classe ‘matavam’ essa aula porque ela realmente era bastante teórica e pouco prática e esses alunos estavam mais interessados ou em jogar Truco no páteo do colégio ou em ver o último livro de Clipper (que era a ‘sensação’ da época da mesma forma que Java é a ‘sensação’ do momento).

Eu assisti essas aulas e aprendi sobre deslocamento de bits, soma, subtração, multiplicação binária, aprendi como um número negativo era representado binariamente (complemento de dois e afins), e por aí vai.

Quase uma década depois eu e mais algumas pessoas em Curitiba fizemos um teste prático em linguagem C para entrar no meu atual emprego no INdT. O desafio proposto pra mim era corrigir uma função de um compressor de arquivos que fazia deslocamentos de bits e umas operações bit-a-bit com máscaras.

Corrigi a função (estourei um pouco do tempo disponível) e passei no teste. Algum tempo depois um atual-companheiro de trabalho saiu da sala e havia me dito que ele se atrapalhou com o desafio dele (que também envolvia deslocamentos e manipulações de bits) porque ele não lembrava a sintaxe da linguagem C para fazer deslocamentos de bits (>).

Se eu estivesse na mesma situação que ele eu teria solucionado o problema usando uma ‘alternativa’ à sintaxe da linguagem C e faria sucessivas multiplicações e divisões por 2 que fazem com que os bits se desloquem para à esquerda e direita respectivamente.

Esse foi um caso real onde um “Conhecimento Fundamental” teria ajudado esse meu amigo. De qualquer forma ele se deu bem no restante do teste e hoje ele trabalha aqui do meu lado.

Recursividade

A algum tempo atrás precisei desenvolver um pequeno script pra um provedor de internet que calcularia o valor com pulsos gastos pelos assinantes desse provedor para que posteriormente fossem oferecidos produtos de banda-larga para clientes que fazem uso maior de internet.

No momento em que estava pensando na forma que eu resolveria esse problema (que eh desnecessariamente complicado) emergiu dos fundos de meus “Conhecimentos Fundamentais” as minhas aulas sobre recursividade. Usei uma prática muito simples de ‘dividir e conquistar’ as ligações que encaixavam em diversas categorias diferentes de tarifação chamando a mesma função de cálculo recursivamente.

Evidente que esse script não prevê todos os casos e situações diferentes com as quais uma operadora de telefonia precisa se preocupar mas serviu adequadamente para resolver o problema em questão.

Recentemente um amigo que presta serviços para um provedor de internet que pertence à uma operadora de Telecom me disse que a equipe de desenvolvimento dessa empresa estava ‘batendo cabeça’ a várias semanas tentando resolver o mesmo problema.

Eram desenvolvedores que não possuem “Conhecimentos Fundamentais” para exercerem suas funções. Passei esse script para que o pessoal usasse.

Conhecimentos Fundamentais não envelhecem

Os profissionais de informática hoje perdem muito tempo escolhendo uma faculdade ou outra, um curso ou outro porque uma delas usa Windows e a outra Linux. Uma usa Java e a outra .Net. Algumas ainda usam Pascal e outras começam a usar Python. Os alunos ‘brigam’ com seus professores para que os mesmos ensinem Java ou C# mas nunca brigam com eles pedindo para que explique sobre Autômatos Finitos ou máquinas de Turing.

Saber Java ou C# hoje é o mesmo que ter sabido Clipper ou Cobol à alguns anos atrás. É um tipo de conhecimento que ‘envelhece’ e perde o sentido. Não é um conhecimento desnecessário, mas a aquisição desse tipo de conhecimento deveria ter uma prioridade menor do que os “Conhecimentos Fundamentais”.

Fundamentar o conhecimento é algo imprescindível que torna mais fácil, inclusive, adquirir outros tipos de conhecimentos.