Arquivo da tag: Desenvolvimento

Não peça feedback, obtenha-o

Todo grande líder sabe que o feedback sincero daqueles que estão à sua volta é uma das principais ferramentas para melhoria e evolução de seu trabalho e de seu papel como líder. Receber e saber processar as críticas é fundamental para aprender e melhorar como líder, quando o feedback é um elogio é ainda melhor, nada mais gostoso do que ter a certeza que você está no caminho certo.

Mas há um grande dilema: Como consigo o feedback sincero dos membros do meu time?

A resposta parece simples, afinal, não bastaria apenas perguntar? Bom, é quase por aí, mas deve-se tomar muito cuidado com o tipo de pergunta a se fazer.

A primeira regra que deve-se ter consciência é que nunca será possível conseguir feedback sincero com perguntas idiotas. Uma pergunta idiota geralmente é uma pergunta da qual você não quer ouvir a resposta, ou uma pergunta que você espera ouvir aquilo que você quer ou, até mesmo, uma pergunta cuja resposta é óbvia.

Pergunta idiota: No meio de um jogo de futebol, pergunta-se para a árbitro: Você está ocupado?

Qualquer ser vivo pensante saberá a resposta do árbitro. Se a pergunta é idiota a resposta é tola.

Isso não significa que a pessoa não queira te dar feedback, mas que há outras maneiras mais eficazes de se conseguir feedback. Não faça uma solicitação em forma de ordem pergunta direta.

Lembre-se sempre destas palavras pois elas serão a chave para o seu sucesso como líder de qualquer time em qualquer área ou empresa, especialmente para se obter feedback sincero e colaboração das pessoas. Estas são as palavras mais poderosas que existem para obter cooperação: “Eu preciso de”. Essas simples palavras são capazes de mágicas e feitos surpreendentes.

Pedir feedback não significa que você irá consegui-lo, especialmente se o pedido começar com “eu quero”. Quando você diz a alguém de seu time que você “quer” algo, a primeira coisa que essa pessoa pensa é: “ah, claro, todos queremos algo que não podemos ter”. Mas se você começa com “Eu preciso de”, significa que você pensou sobre o que é necessário para alcançar o que você está pedindo e, para tal, precisa da ajuda desta pessoa. É incrível como as pessoas adoram sentir-se necessárias, saber que podem ajudar com algo, isso faz toda a diferença entre escutar uma resposta tola e conseguir um feedback sincero.

Aprendendo a obter feedback: Preciso de feedback específico sobre meu plano para que a próxima iteração dê certo.

Simples e indolor, certamente você terá muito a ouvir e aprender.

Um líder é qualquer pessoa que possa lhe dar apoio e orientação necessárias para alcançar seu objetivo. Às vezes o seu maior desafio como líder é saber onde e quando cada pessoa do seu time executará este papel, e cabe a você conseguir obter o feedback necessário destas pessoas.

Evitando o cache no cliente

HTML e CSS nunca foram meu forte, eu sei o que preciso saber para sobreviver, já que trabalho com desenvolvimento web. Não da pra esperar que eu consiga montar uma apresentação fantástica usando HTML5 e CSS3 e ainda por cima pensando fortemente em semântica, organização e melhores práticas, fato!

Não estou aqui criticando HTML e CSS, eu entendo perfeitamente a importância de tudo isso, mas não posso negar que nunca me dediquei muito para aprende-las, até porque nunca tive a necessidade de ser o responsável por esse trabalho. Exatamente por isso eu aprendi algo babacamente simples esses dias, porém extremamente eficiente.

Imagine mudar o CSS, subir pra produção e o cliente simplesmente ver o seu site totalmente quebrado? Pior, mudar uma imagem (um banner ou qualquer outra imagem) e o cliente continuar recebendo a imagem antiga. Quem trabalha com sistemas web e nunca passou por isso?

É muito comum alterarmos qualquer coisa estática como CSS, imagens e até JavaScript e essas alterações não serem interpretadas pelo navegador. O jeito é limpar (ou desligar) o cache do navegador, dar uns 3 ou mais refreshs ou apelar pro CTRL+F5, isso é o que fazemos desenvolvendo. Mas e quando isso acontece em produção, vamos dizer pro usuário/cliente ‘limpar o cache’? Claro que não, temos que dar um jeito então do navegador do cliente reconhecer as alterações logo na primeira visita.

Isso ocorre pois o navegador faz cache local destes recursos e os utiliza quando julga ser a melhor opção. A mesma coisa ocorre com proxy de redes, que também podem fazer cache. O jeito para descartar esse cache é fazer algum malabarismo no servidor web, mas nem sempre isso é possível, então precisamos recorrer à aplicação, onde – geralmente – temos maior domínio.

O cache no navegador tem uma regra básica super simples: o nome do recurso estático. Se mudarmos o nome de um arquivo CSS ou imagem, por exemplo, não teremos problema algum com cache. Se você puder fazer isso na sua aplicação, ótimo, problema resolvido.

Mas se não puder, temos outra opção simples e eficiente, podemos anexar algum parâmetro falso no nome do recurso, por exemplo:

1
<link rel="stylesheet" type="text/css" href="/css/estilo.css" />

Ao atualizar propriedades desta folha de estilo as alterações não serão perceptíveis no navegador enquanto o cache (do navegador) não for atualizado. E isso ou o cliente faz explicitamente ou nós faremos por ele. Então, vamos fazer a nossa parte, vejam:

1
<link rel="stylesheet" type="text/css" href="/css/estilo.css?1" />

O simples parâmetro ?1 cuida disso pra nós. O navegador vai encarar que se trata de uma nova folha de estilos e fará o download do servidor, utilizando esta nova versão no lugar da que ele tem em cache, na próxima visita o ?1 não vai fazer mais nada, já que o navegador já tem a folha de estilo com o ?1 em cache. O parâmetro ?1 pode ser atualizado toda vez que for preciso fazer alguma alteração na folha de estilo, desta forma o cliente terá sempre a versão correta toda vez que ela for atualizada.

Outra saída é usar um parâmetro que nunca será o mesmo, por exemplo: usar a data completa (dia, mês, ano, hora, minuto e segundo). Só que isso fará com que o cliente faça o download do recurso no servidor toda vez que acessar o site, o que pode causar um grande tráfego no servidor, impactando diretamente na performance da sua aplicação. Num captcha faz sentido, mas em outros casos é bom pensar bastante antes.

É isso, dica simples e fácil (e talvez boba), mas que me salvou um dia desses.

Usando Working Sets no Eclipse

Quem não tem mais de uma workspace do Eclipse que levante a mão. Alguém!? Alguém!? Tenho certeza que todos que trabalham com o Eclipse há algum tempo, por mais organizado que seja já se pegou gerenciando duas, três, quatro ou mais workspaces.

Isso sempre foi um problema pra mim, especialmente pelo modo que o Eclipse gerencia suas configurações, que são particulares para cada workspace. Isso é bom, é um modelo legal e funciona super bem. Não era bom pra mim pois eu estava teimando em usar as workspaces de forma errada, então eu sempre tive um sério problema com as configurações, pois elas estavam sempre diferentes entre cada workspace.

Eu sempre tentei separar os projetos por clientes, por área de interesse ou por atividade. Uma workspace de projetos open source, outra do cliente ABC, outra do cliente XPTO, outra de projetos que eu estava estudando o código e assim por diante. Os problemas na hora de trabalhar eram vários, por exemplo: um repositório criado numa workspace era só dela, um atalho configurado na outra ficava só lá, um bookmark também, ou templates de código também. Resumindo, a bagunça ficava gigante e a redundância de configurações então nem se fala.

Então resolvi jogar tudo pra uma workspace só. Problema resolvido!? O das configurações sim, mas de brinde ganhei um novo: performance. Outro hábito não muito bom que eu tenho é o de manter todos os projetos abertos. São tantos projetos (141 atualmente) que só pra abrir o Eclipse demorava muito tempo. Depois, pra abrir/buscar um tipo (CMD+SHFIT+T), por exemplo, demorava de mais para indexar, limpar a workspace então nem pensar. A solução que eu encontrei foram as Working Sets, um recurso que sempre esteve ali presente e eu nunca dei bola.

As Working Sets são grupos de trabalho que podem concentrar um ou mais projetos e funcionam como se fossem várias workspaces. No meu caso as working sets caíram como uma luva para a minha antiga distribuição de workspaces. Ao invés de usar várias workspaces por clientes, agora mantenho uma única workspace com várias working sets, algumas de clientes, outras de estudo, etc. Isso resolveu o meu problema de configurações completamente e com as working sets eu posso escolher em que vou trabalhar num determinado momento e ver somente aqueles projetos, resolvendo também o problema de performance.

E para quem quiser usar as working sets, seguem algumas dicas.

Ativando a visualização por working sets

O passo essencial é trocar a visualização de Projetos para Working Sets, isso é bem simples. Veja a imagem a seguir:

eclipse_ativar_working_sets

Gerenciando suas working sets

No próximo passo você deverá criar as suas working sets e associar cada uma delas com os projetos que quiser.

eclipse_visualizando_working_sets

Crie, modifique ou remova qualquer working set.

eclipse_gerenciando_working_sets

Trabalho feito, agora basta escolher em qual working set quer trabalhar e pronto, paz e sossego.

eclipse_go_into_working_set

Lembre-se que você pode optar por fechar ou abrir todos os projetos de uma working set bem como “ir e voltar” para qualquer uma delas.

Ativando Syntax Highlighting no VIM

Recentemente participei de algumas discussões nas listas que participo que abordaram ambiente de desenvolvimento e, consequentemente, editores e IDEs. A escolha do editor ou da IDE é algo completamente particular e extremamente pessoal, e depois que alguém adota alguma ferramenta, não adianta alfinetar ou empalar com uma lança, as opiniões dificilmente mudarão, não importa quais ou quantos argumentos forem usados. Até mesmo por isso não quero falar sobre melhor ou pior aqui.

Numa dessas discussões, inevitavelmente começaram a falar sobre o VIM e num determinado momento alguém exclamou que o VIM era tão ruim que nem Syntax Highlighting fazia. Mas oras, é claro que faz. Uma dica rápida.

1) Ativando Syntax Highlighting manualmente

Durante a edição de um arquivo, você pode ativar ou desativar a Syntax Highlighting quando quiser. Para ativar:

:syntax on

E para desativar:

:syntax off

2) Ativando Syntax Highlighting automaticamente

Se você quiser, pode deixar que o VIM faça isso automaticamente sempre que possível. Pra isso edite o arquivo vimrc e adicione o trecho abaixo. No Linux esse arquivo geralmente fica em /etc/vim/vimrc, enquanto no Mac OS X você o encontrará em /usr/share/vim/vimrc.

if has("syntax")
  syntax on
endif

E é isso. Feche e abra o próprio arquivo vimrc e veja as diferenças. No meu caso ele ficou assim:

picture-2

Os arquivos de syntax ficam no diretório syntax dentro do diretório de instalação do vim, pro caso de você querer mudar alguma coisa.

Estudar é uma obrigação. Evoluir, consequência

Eu demorei, mas aprendi que criticar diretamente não é a melhor forma para se cativar as pessoas, ainda estou tentando praticar de forma mais eficaz, é difícil, muito difícil, mas funciona. Contudo, existem situações onde a crítica é inevitável, infelizmente existem e nós precisamos estar sempre preparados para elas – tanto para criticar quanto para receber uma crítica. Mas fazer uma crítica sem motivo ou razão e, principalmente, sem um conhecimento sólido que dê credibilidade à esta crítica é, no melhor dos casos, desprezível.

O pior é que ultimamente com tanta mídia gratuita por aí eu tenho notado muita gente se empolgando e embarcando na onda de “crítico matador”, e simplesmente querendo fazer o papel do grande sábio e conhecedor de todos os assuntos, criticando a tudo e a todos sem o menor pudor – e na maioria das vezes, sem a menor autoridade para tal.

Alguns pensam que girando a metralhadora e disparando críticas para todos os lados serão mais respeitados, ou sair logo criticando com todas as forças algo novo e recém lançado é um grande negócio para auto-promoção e até mesmo que a crítica é a melhor forma de “falar que sabe tudo do assunto”.

Mas assim como a síndrome do seniorismo, onde muita gente se tornou consultor senior de negócios após 1 ano de estágio, a síndrome do criticismo está se alastrando rapidamente. Hoje em dia todo mundo acha bonito criticar, todo mundo acha bonito fala mal, chamar o código alheio de porcaria (adoraram fazer isso com o twitter, recentemente) e por aí vai. E o pior, o que está alimentando essa nova síndrome é o comportamento da maioria que tem respeitado e tem até sentido uma pontinha de medo de quem adora criticar tanto.

É muito fácil criticar, aliás, qualquer idiota pode criticar, condenar e queixar-se – e a maioria dos idiotas faz isso. Por vezes é muito mais simples e não requer esforço e nem conhecimento, basta disparar qualquer asneira e pronto. HEI! Pessoal, acordem!

Já do outro lado nem é preciso ser conhecedor do assunto criticado para entender a crítica, afinal, célebres frases como: “- Odeio o framework X”, “- A API de fulano é horrível, deplorável” e “- O serviço do João é cheio de bugs”, são muito fáceis de serem compreendidas e são ótimas para causar uma má interpretação do assunto. Mas eu me pergunto, por que a pessoa odeia o tal framework, será por algum motivo que justifique a crítica ou seria apenas porque antes da síndrome do criticismo esta pessoa já passou pela síndrome do seniorismo e agora além de não saber a ferramenta ainda a crítica. Ou por que a API do fulano de tal é tão ruim, não seria por que a API é REST e o crítico só sabe fazer integrações usando stored procedures? Ou quais seriam os tais bugs no serviço do João, será que existem de fato?

Eu não quero que este post seja visto como uma crítica aos críticos, não é. De certa forma estou usando este espaço e escrevendo sobre isso exatamente aqui no meu blog pois tenho visto que muitos amigos e pessoas próximas que mantenho contato estão sofrendo de tal síndrome do criticismo. E isso é muito mais do que simplesmente chato, é frustrante.

A intenção é dar uma dica: estudem; estudem, ESTUDEM SEMPRE! Saibam ser humildes, tenham respeito pelo próximo e aprendam a admirar o trabalhos dos outros. Você será verdadeiramente respeitado e admirado ao dizer “- Parabéns pela sua implementação, sua idéia para resolver aquele problema foi ótima” do que criticando sem conhecer por pura falta de vontade e empenho em aprender, criticar de forma irresponsável somente vai trazer respeito e admiração de outros irresponsáveis e alienados.

Um exemplo simples e clássico

Eu estudei por muitos anos (há muito tempo atrás) seguidos e tive cerca de 4 anos de experiência profissional com Struts 1.x e até hoje penso duas vezes antes de formular uma crítica a este velho conhecido e tão calejado framework. Tenho consciência que não sei sobre todos os detalhes do Struts e que posso ter compreendido ou até utilizado de forma errada um ou outro recurso, por isso sempre penso se sou a pessoa mais adequada para aquilo, principalmente quando estou inserido num cenário que sei que a minha opinião, por exemplo, poderá repercutir ou influenciar a opinião de outras pessoas. É preciso ter humildade para reconhecer que não se sabe tudo e responsabilidade para criticar.

Mas mesmo assim eu escuto/leio muita coisa ruim do Struts que vem de pessoas que estão começando a aprender JSF sem nunca ter tido qualquer experiência com outra ferramenta/framework antes, que credibilidade dar a pessoas assim? Que credibilidade dar a uma pessoa que desdenha do código alheio sem nunca te-lo visto?

Responsabilidade, humildade e maturidade devem estar sempre juntas para te ajudar a manter-se em seu lugar e saber quando e como expor a sua opinião.