Desenvolvimento•
em 23/04/2009•
Drupal, Joomla! e WordPress. As três ferramentas de gestão de conteúdo livres mais usadas na Internet mundial serão apresentadas e discutidas tecnicamente em São Paulo no dia 20 de junho dentro do CMS Brasil, evento realizado conjuntamente pelo portal iMasters e a Fábrica Livre.
Matt Mullenweg, criador do WordPress; Anthony Ferrara, líder do desenvolvimento do Joomla! e Addison Berry, líder da documentação do Drupal são os convidados internacionais que desembarcam no Brasil para participar junto com outros doze especialistas nacionais de palestras técnicas e oficinas na troca de experiências e conhecimentos sobre o desenvolvimento e uso de ferramentas de gestão livres.
O evento é totalmente técnico e voltado ao programador que deseja conhecer as formas para a criação de portais de todos os tamanhos e para todos os segmentos da economia. Em dois ambientes distintos, o participante poderá ver, ouvir e conhecer as dicas e macetes do desenvolvimento de soluções para todas as necessidades, seja um simples blog ou até mesmo uma rede social completa. “Ousamos trazer pela primeira vez ao Brasil grandes nomes do mercado de CMS mundial e mais que isso, colocá-los juntos em um mesmo evento” comenta Paulino Michelazzo, diretor da Fábrica Livre.
São esperados quinhentos participantes de todo o país e as inscrições para todo o evento ou somente para as oficinas já estão abertas com desconto no endereço www.cmsbrasil2009.com e vão até o dia 28 de abril. Não perca.
Desenvolvimento•
em 03/06/2008•
Quem nunca encontrou um “sobrinho” diante do caminho e que nunca precisou refazer um trabalho dele que atire a primeira pedra.
- Estou precisando fazer um web site. Quando você cobra?
- Depende do que precisa. Com design, banco de dados, dinâmico e etc… uns quatro mil.
- Nossa, tudo isso? Então deixe que vou pedir para meu sobrinho fazer.
Quem nunca passou por esta situação? Tanto no desenvolvimento quando na criação, sobrinhos são como pragas que infestam lavouras e fazem o profissional perder a paciência em todos os sentidos. Perde-se tempo montando uma proposta de serviços, perde-se tempo pesquisando, perde-se tempo no telefone e depois, lá adiante, perde-se novamente todo este tempo novamente para arrumar o que o sobrinho fez errado. Mas quem é o sobrinho afinal?
No começo de minha profissionalização na área de TI, usávamos o termo “sobrinho” para designar aquele que come angú e arrota peru. Diferentemente de um estagiário, o sobrinho acredita que é o super-homem mas não passa de um chapolin colorado que nos propicia as mais belas pérolas de como não fazer algo, principalmente depois que achou aquele “tutorial bacana” na Internet e acredita que consegue resolver qualquer problema. Sofrendo de uma crônica incapacidade de se colocar dentro de suas limitações, os sobrinhos conseguem o mais improvável: estragar não somente sua vida mas a de terceiros também.
Semana passada em visita a um grande cliente, este me contou a história dos sobrinhos que lá apareceram. Dignos de credibilidade até então, disseram que poderiam dar nó em pingo d’água e mascar azulejo. Contratados para alguns treinamentos, que vexame! os treinandos sabiam mais que aqueles que lá estavam teoricamente ensinando e no final, aquele fiasco. Não contentes, conseguiram jogar a culpa em conjunções dignas de astrólogos indianos e continuam na ativa, importunando como moscas em dia de calor.
Com o advento de ferramentas easy-to-use, a classe dos sobrinhos cresce exponencialmente e infesta todas as áreas possíveis e imagináveis. Existem sobrinhos personal trainner, sobrinhos mecânicos, sobrinhos programadores e até mesmo sobrinhos advogados, todos conspirando conjuntamente para a derrocada do bom trabalho, do bom preço e principalmente, do bom resultado.
Dentro de minha área de atuação sobrinho é mato em terreno baldio. Com a pseudo-facilidade de uso das modernas ferramentas de gestão de conteúdo tais como Drupal, Joomla! e Mambo, baixam o sistema da Internet, aproveitam-se de alguns temas disponíveis gratuitamente na rede e bam! nasce outro sobrinho para atazanar. Outro amigo, designer, lamenta a mesma coisa; um dreamweaver na mão e lá vem mais um sobrinho criador, desta vez, “designer”. Esquecem estes que qualquer ferramenta por si não faz o trabalho. É necessário um profissional que saiba trabalhar com a ferramenta no intuito de aproveitar ao máximo suas opções e capacidades e que para isso leva-se tempo de estudo, treinamento, leitura, pesquisa e muitas horas diante de uma tela.
O leitor pode estar pensando: “isso é conversa de quem não consegue trabalho”. Ledo engano. É conversa de quem tem que refazer o trabalho que o sobrinho executou de forma errada ou que simplesmente no meio do projeto desapareceu. O cliente sempre vem, seja por coerência ou ainda com hematomas adquiridos quando caiu-se nas armadilhas armadas pelos sobrinhos ao longo do projeto. Claro, perder ninguém gosta e para um sobrinho mais ainda. Mas o que pior é aceitar apagar um incêndio e depois perceber o tamanho da bomba de napalm que o sobrinho deixou para você.
Não sendo sobrinho
Como a área de TI sofre constantemente com este espécime e para que não caia na armadilha de se tornar sobrinho, algumas dicas são bem vindas:
Limite-se a sua ignorância
Procure no dicionário; ignorância não é sinônimo de burrice. Ser ignorante é não saber determinado assunto ou algo. Se você não sabe, assuma este papel e procure aprender. Será melhor para você e para todos.
Seja honesto
Não existe coisa pior que dizer para um cliente “eu faço” e depois não conseguir fazer. Neste ponto a ignorância se torna burrice, você perde o cliente e arruma trabalho sujo para outro fazer. É muito melhor deixar claro quais são seus limites do que assumir um compromisso que não faz idéia de como resolver.
Dê passos menores que suas pernas
Não são passos do tamanho de suas pernas, mas sim menores que elas. Com esta atitude você poderá entregar mais do que prometeu e “ficará bem na foto” com todo mundo.
Aprenda com quem já faz
Caiu um projeto grande em sua mão e não sabe por onde começar? Chame parceiros para trabalhar contigo e partilhe os dividendos tanto financeiros quanto de aprendizado. Trabalhando em conjunto você aprende, não passa vergonha diante do cliente, entrega um bom produto e cria um portifólio para sua carreira.
Fácil não é simples
Não acredite que fácil é sinônimo de simples. É fácil chegar a Antártida mas não é simples chegar lá. Ferramentas easy-to-use facilitam muito sua vida e sendo assim, aproveite o tempo que sobra para estudá-la a fundo tornando-se um expert.
Fuja da síndrome de super-homem
Não aceite qualquer coisa para fazer pois por mais simples que seja. Qualquer compromisso tem um resultado embutido nele e você terá que honrá-lo. Vá com menos sede ao pote e dê tempo ao tempo. Tudo tem sua hora para acontecer e certamente se praticar e tiver paciência, seu futuro será muito sólido e não motivo de piadas nas rodas dos profissionais de TI.
E você? É sobrinho?
A web está com um motor 2.0 zerinho. Mas estão seus desenvolvedores prontos para tanta potência? Conheça dois exemplos diferentes de motorização.
Admiro Tim O’Reilly por vários motivos. Criou uma empresa muito bem conceituada, edita ótimos livros e desenvolve um bom trabalho na área de FLOSS. Mas admiro-o ainda mais estando lado a lado com os gênios do marketing tecnológico, Bill Gates e Steve Jobs, para os quais não deve absolutamente nada quando o assunto é criatividade. Dentre suas façanhas para galgar tal posto encontra-se a cunhagem do termo “Web 2.0”. Um nome bonito, simples e ao mesmo tempo que nada diz, como a maioria das propagandas dos grandes gênios. A evidência que ele é tão bom quanto seus pares está na capacidade de arrebatar milhares de seguidores em todo o mundo para o “nada novo”.
Pode pensar o leitor que sou contra a web 2.0. De forma nenhuma. Acho-a bonita, interessante, excitante. Mas sim, sou contra a forma como os fanáticos seguidores desta “nova onda” tentam pegar o bonde andando querendo sentar na janelinha. Deixando a analogia de lado, me impressiona a busca incessante por informações sobre novas tecnologias da afamada web 2.0 quando o programador ao menos toma cuidado de manter antigos conceitos fundamentais paralelos ao novo aprendizado. Neste momento, o possante motor da web 2.0 se torna um xumbrega 0.2.
Um mau exemplo
Há alguns dias precisei fazer a aquisição de uma passagem aérea partindo de São Paulo para o Oriente Médio. Sendo uma “pessoa da web”, nada mais lógico que usá-la para tal tarefa. Usando um conceituado site multinacional de viagens que opera no Brasil, consegui a reserva somente após vários telefonemas para o site, gastando tempo e dinheiro que não precisava. Os erros? Muitos. Uma mesma busca com as mesmas variáveis retornava resultados diferentes, datas incorretas, trechos errados e cancelamentos não solicitados. Tudo isso sinalizava para mim um mau código criado por um mau desenvolvedor que no deslumbre da web 2.0 maciçamente usada no site, esqueceu do básico que seria a verificação de queries executadas em uma base de dados, ou seja, acredita este que o novo motorzão de tão moderno, não precisa nem de óleo.
Erro 1
Erro 2
O leitor atento vai achar estranho como podem dois vôos entre as mesmas cidades possuírem uma diferença tão grande de tempo de viagem (10 horas). Poderia ser por alguma escala no meio do caminho, mau tempo ou então vento contrário, mas nenhum destes “poréns” era correto. De tão estranho, comecei a procurar na Internet se o avião usado pela companhia tinha autonomia para 20 horas seguidas sem reabastecimento e descobri que não existe um único aparelho hoje capaz disso (exceto em condições excepcionais para quebras de recordes). Assim sendo, a conclusão foi óbvia: soma-se ou subtrai-se o número de horas entre a partida e chegada sem levar em conta os fusos horários. Um erro tolo mas que custou-me vários dólares em tempo e ligações, além de alguns milhares de reais da empresa que precisa manter um (ou vários) funcionários ao lado do telefone para sanar problemas com clientes que não podem acreditar no horário de chegada de um vôo para marcar outro pois, a cada momento, uma nova informação é fornecida.
E o motorzão 2.0 da web? Virou um 0.2 no velho e bom telefone.
Um bom exemplo
Mas existem bons exemplos de como a web pode funcionar bem (e muito bem, obrigado) quando mesmo com um motor novo, não são esquecidas as lições aprendidas lá na auto-escola da Internet.
No mesmo período desta passagem, tive que solicitar um visto de entrada no Camboja, pequeno país da Indochina bem conhecido pelas suas paisagens florestais usadas em filmes do Rambo e da bela Lara Croft. Ao contrário do que o leitor preconceituosamente possa imaginar, este país que só conheceu a tranqüilidade civil em 1999 e que atualmente possui somente 44 mil endereços na Internet, mantém um dos melhores sistemas de e-visa do planeta, deixando para trás nações desenvolvidas de todos os continentes. De forma simples, fácil e objetiva, qualquer viajante (com as excessões de praxe) pode solicitar seu visto e de mais quatro pessoas eletronicamente, recebendo-os em qualquer lugar do mundo no prazo de três dias úteis. Erros e problemas no sistema? Simplesmente nenhum. Um pouco de web 2.0 bem dosada e uma sólida programação por trás do sistema fizeram com que mais de trinta e cinto mil turistas utilizassem a ferramenta desde seu lançamento que permitiu a redução de custos com papéis, funcionários, “burrocracia” e claro, a paciência daqueles que desejam conhecer este interessante país.
Se existe comparativo dentro da Internet, o trabalho do ministério de turismo cambojano é a verdadeira web 2.0: eficiente, simples, prática e, neste caso, turbinadíssima.
A lição de mecânica
Não importa se você está pilotando um site 1.0, 1.3, 1.8 ou 2.0 (e já está chegando a 3.0!). Existem pequenas lições que aprendidas uma vez em qualquer “motorização”, devem ser usadas sempre. O usuário da web antes de querer cores bonitas, janelinhas saltitantes, efeitos especiais “made in DreamWorks” deseja informação e mais que isso, informação correta. Não acredita no que digo? Pois veja dois campeões unânimes de ibope, Google e Wikipédia e encontre onde está a “web 2.0” multicolorida neles. Não é o show de efeitos que faz um site ser bem visitado, mas sim seu conteúdo bem estruturado e de fácil recuperação. A web 2.0 está errada não em sua conceituação, mas sim na mão daqueles que a programa e que acreditam ser o máximo uma “janelinha Ajax” aqui e ali. Bonita e bacana, ela perde toda a funcionalidade e finalidade quando o suporte dela é capenga e permite o retorno daquele motor 0.2 a lenha!
Você pode fazer muito pela saúde de seu motor 2.0 (e não ser um exemplo em um artigo como estes) se manter a manutenção básica do mesmo em dia com os seguintes pontos:
- Atenha-se primeiro a informação e depois em como ela será distribuída. De nada adianta as belas caixinhas Ajax o códigos DOM mirabolantes se a informação não é estruturada ou é simplesmente, uma nuvem de CO2. É preferível um site simples, básico, funcional e com informação relevante do que aquela mega produção entendiante. Conteúdo é o que conta (claro que se bem apresentado, melhor ainda);
- Tome cuidado redobrado com fidelidade da informação que está distribuindo. Um pequeno erro em um zero pode custar uma retífica completa ou ainda a “perda total” do seu motor (inclusive de seu emprego). Faça verificações dentro e fora do sistema com o intuito de encontrar erros na programação e sane-os o mais breve possível. A web 2.0 aceita o conceito de ajuda do usuário para encontrar falhas e erros mas não abuse. Usuários não são seus beta-testers (como algumas empresas adoram fazer) mas sim parceiros.
- Aproveite-se daquilo que seus usuários mais possuem: senso crítico. Quando um usuário navega de um lado para outro num site (facilmente verificável com um código de log atrás do sistema), alguma coisa errada está ocorrendo. Será que ele está encontrando a informação que precisa ou será que está pulando aqui e ali tentando achá-la? Se você possui formulários de contato para críticas e sugestões, use-o efetivamente. Críticas são sempre bem-vindas e muito úteis quando se deseja melhorar o que existe. Responda as críticas tanto com a correção/adaptação quanto para o usuário que a fez;
Finalizando
A web 2.0 e a novíssima 3.0 podem e devem ser usadas pelos desenvolvedores. Mas como já cantado por Jorge Benjor, “prudência e canja de galinha não faz mal à ninguém”. Deixe de lado os efeitos pirotécnicos (a menos que esteja fazendo o site do concurso mundial de fogos de artifício) e atenha-se onde realmente é necessário usar tal conceito. Interações com o usuário são muito importantes mas ainda mais importante é a resposta dada. A frustração do usuário é muito maior quando a resposta obtida à sua necessidade é pífia do que aquela encontrada na dificuldade de obtenção da resposta.
Não esqueça que aquelas regrinhas básicas aprendidas nos gol’s, uno’s e até fusca’s são usadas até para dirigir uma Lamborghini. E na web a analogia é a mesma, o básico é básico mas nunca deve ser desperdiçado.
Desenvolvimento•
em 30/08/2007•
Está começando agora a programar e não sabe como fazer? Precisa de dicas de como executar determinada função ou código e não tem onde achar? Este artigo não responde estas perguntas mas fornece várias dicas para programar melhor em qualquer linguagem.
Há muito tempo recebo mensagens de pessoas que querem começar a programar e desejam dicas de como fazer isso, seja para uma linguagem específica, seja para a área da programação.
Infelizmente não posso dar dicas para todas as linguagens pois não as conheço para escrever sobre. Entretanto, algumas por serem genéricas, podem ser fornecidas e servem como base para toda a área e não somente para esta ou aquela linguagem. É disto que este artigo trata: dicas de como programar melhor. Vamos lá?
Aprenda com os outros
Existem programadores que não suportam imaginar sua “grande invenção” sendo copiada por outros. Para estes, é uma verdadeira heresia compartilhar o conhecimento e o código com outras pessoas. Infelizmente estes programadores estão, em sua maioria, fadados a fracasssar pois vão viver inevitavelmente em uma ilha, isolados.
O ser humano chegou em seu estágio de desenvolvimento porque compartilha seu conhecimento e descobertas. Isso acontece em todas as áreas, sejam exatas, humanas ou biológicas. Assim é um equívoco gigantesco pensar que a descoberta de uma nova estrela ou ainda de um novo remédio é um fato isolado e feito por uma pessoa. São dezenas de pessoas em dezenas de instituições diferentes que juntas fazem “o sucesso”.
A melhor forma de aprender é tomar exemplos daqueles que já fizeram. Não digo que a criatividade deve ser colocada fora da questão, pelo contrário. Bom é aquele que consegue ver algo e melhorá-lo, levando à excelência. Assim, obtenha código de terceiros e compreenda como o autor chegou em determinado resultado. Compare com o que você já sabe e peneire aquilo que é valioso para você. Muitas vezes a leitura de um código pode resultar na descoberta de uma solução totalmente diferente e que cai como uma tábua de salvação no seu problema.
Lendo o código de outros programadores também aprende-se como NÃO FAZER (inclusive acredito que é por isso que muitos não divulgam o que fazem). Falta de identação, criação sistemática de variáveis, loops infinitos e todo o tipo de aberração pode ser encontrada em códigos mal feitos. Lendo estes códigos e comparando com aquilo que já conhece, certamente poderá identificar o que é utilizável e o que é “> /dev/null”.
Pense antes de fazer
O número de programadores que começa a fazer um software pelo código é tão grande quanto a quantidade de cimento usado para construir as torres Petronas na Malásia. Seja por falta de conhecimento, seja por desespero do cliente ou empregador ou ainda por ego, eles começam a fazer uma casa pelo telhado e não pelo alicerce. Aí meu amigo, a casa cai, literalmente.
Os melhores softwares que conheço são aqueles onde o tempo “gasto” na sua idealização é muito maior que 70% do tempo total para finalizá-lo. Código, qualquer um faz, basta a leitura de um livro, dois tutoriais e um guia de referência à mão que ele sai. Agora, pensar como ele deve ser feito e como ele deve se comportar é algo que poucos fazem mas atitudes que separam o bom do mau software.
Pense no que a aplicação vai fazer. Execute testes de mesa, faça fluxogramas, pense nas tabelas do banco de dados. Considere as variáveis existentes e as não existentes e como a aplicação deve responder para cada uma delas. Imagine o que o usuário é capaz de fazer (cada coisa!) e como contornar as idéias mais mirabolantes possíveis. Levando tudo isso em consideração, seu software está sujeito a ter menos erros e não se tornar uma colcha de retalhos dentro em breve (como alguns sistemas que conhecemos).
Documente
A esmagadora maioria dos programadores não consegue criar um parágrafo de texto com nexo. Conheço vários exímios programadores que não se aventuram em escrever um livro ou um artigo sobre o que conhecem por não conseguirem ser expressar além de parênteses, colchetes e sinais de igualdade. Outros até tentam e depois que percebem o erro que fizeram, abominam a idéia e fogem dela como o diabo da cruz.
Mas feliz ou infelizmente (para você), mais cedo ou mais tarde terá que parar e escrever a documentação do que está fazendo. Ela é imprescindível não somente para aquele que paga pelo seu trabalho, mas também para que você possa, em caso de necessidades futuras, saber o que foi feito, como foi feito e onde está cada parte de seu software. É trabalhoso, é cansativo, é chato e principalmente, maçante. Mas acredite, tem que ser feito e o quanto antes. Se no meio do caminho você se perder, poderá saber onde está e para onde vai.
O método correto é começar a documentação ANTES do desenvolvimento do software. Fluxogramas, dicionários e modelos de dados são o mínimo esperado de um programador que vai começar a fazer um sistema. Se começa sem isso, já começa errado e vai certamente dar com os burros n’água logo adiante.
Arme-se com ferramentas produtivas
Em minha última viagem comprei um daqueles afamados canivetes suíços. Uma ferramenta que acho imprescindível em todos os sentidos. Mas ao contrário do que pode pensar, não comprei um “turbo canivete” com mais de cem funções. Comprei um que possui somente aquilo que preciso, ou seja, duas lâminas de corte, uma tesoura, uma pinça, um alicate e uma chave com pontas intercambiáveis que retira qualquer parafuso dos computadores e notebooks atuais, inclusive aqueles com cabeças em estrela usados em disco rígidos. Poderia comprar um super canivete? Sim, mas para quê? Carregar peso desnecessário, pagar mais caro e nunca usar a maioria de suas funções?
Na programação acontece a mesma coisa. Existem ferramentas e “ferramentas” para tudo. Editores de código, gerenciadores de bancos de dados, documentadores e assim por diante. Uns melhores que os outros, sejam em recursos, em funcionalidades e também em preços.
Um bom editor que faça highlight de código, uma identação decente e que forneça acesso rápido à sintaxe das linguagens que usa é extremamente útil e produtivo. Da mesma forma, gerenciadores de bancos de dados são extremamente importantes a fim que possa executar comandos diretamente no mesmo para comparar os valores com o que obtém no código e também, vez em quando, alterar suas propriedades.
Fuja de ferramentas com muitos recursos ou “gordas”. A maioria destes recursos você nunca irá usar e se tornarão um peso em sua máquina, além de deixá-lo frustrado por não saber usar tudo o que existe. Prefira uma ferramenta que faz efetivamente o que deseja e que você se sinta confortável com ela. É muito melhor saber usar completamente uma ferramenta mais simples do que não saber usar uma com todos os recursos possíveis e imagináveis.
Não teste, peça para outros testarem
Tudo o que fazemos repetitivamente torna-se mecânico e não percebemos. Exemplos são: dirigir, andar de bicicleta e respirar (ou você pensa para respirar?). Com o teste de software acontece a mesma coisa. Estamos tão inseridos em seu desenvolvimento e conhecemos todas as vírgulas que elas se tornam um problema para o programador que, na hora dos testes, passa por cima de pequenos erros sem perceber e libera uma versão “bugada”, ou ainda perde horas para descobrir que falta um ponto dentro de uma operação matemática.
Sempre peça para terceiros testar o que está fazendo e, preferencialmente, que seja um futuro usuário do software. Como ele não está inserido no processo de desenvolvimento e na maioria das vezes pouco conhece de programação, poderá encontrar erros que você simplesmente não percebeu, seja uma imagem deslocada, um pixel a mais numa área da tela ou ainda uma mensagem sem motivo de lá estar (principalmente quando é um palavrão). Fazendo isso, as chances de erros é muito menor (por isso existem beta testes).
Páre e descanse
A programação de software é uma área extenuante. Horas e horas diante de uma tela sentado em cadeiras que não atendem em absoluto a ergonomia de seu corpo. Muitos programadores passam o dia inteiro assim e a grande maioria reclama, depois de alguns anos, que não aguenta mais, seja pela pressão de fazer mais em menos tempo, sejam pelos olhos cansados ou pelas dores nos pulsos.
Se você entrar na onda do “estouro de boiada” e passar dez, doze, quatorze horas diárias sem pausas diante de um código, terá, além dos problemas já citados, um outro comum: lapso de memória. É comum quando estamos em uma situação de estresse psicológico sermos “desligados”. Isso não é seu ou meu, mas sim da genética do corpo humano. Ele se “desliga” para isolar-se de situações que possam causar risco à sua sobrevivência. Exemplos são as pessoas que desmaim diante de um estresse grande como um seqüestro ou ainda a perda de um ente querido. E não adianta ir contra isso, se forçar, vai ter um reboot em breve (só espero que não seja um shutdown!).
Sempre faça pausas durante o trabalho. Levante-se, vá até o bebedouro (ou geladeira), beba água, caminhe, converse com alguém. Claro que não é para fazer isso a cada meia hora e tampouco pausas de duas horas. Mas sempre dê tempo ao tempo e principalmente à você. Use esta dica com regularidade para manter seu corpo e suas faculdades mentais em dia. E por favor, jogue no lixo aquelas bolinhas ridículas usadas para massagear as mãos. Elas servem somente como desculpa para que fique sentado com seu traseiro na cadeira e produza o máximo possível. Lembre-se, produção não é volume, é qualidade.
Não se prostitua
Claro que não estou falando de favores sexuais em troca de qualquer coisa. Não é nada disso. Estou dizendo que você não deve se vender por qualquer coisa, para qualquer um. Infelizmente um dos maiores problemas da área de programação é o ato da prostituição laboral onde o programador, por motivos mil, vende seu trabalho a qualquer preço, fazendo com que ele mesmo toda a categoria seja prejudicada.
Você pode advogar que a vida está difícil ou que precisa comer. Claro que sim, todos precisamos. Mas será que precisa ser tão barato? Muitas vezes os programadores são comparados com pessoas que estão começando na profissão mas levando em conta somente a parte financeira, ou seja, o valor de A é muito menor que B, não mensurando a experiência daquele que está há anos fazendo software.
Seja honesto consigo mesmo. Se você é um iniciante na programação, cobre o que é correto pela sua experiência. Entretanto se você é um “macaco velho”, não se sujeite aos ditames pré-existentes. Na maioria das vezes isso é ruim para você, ruim para o contratante e ruim para todos nós. Acredite, ainda existem contratantes que sabem o quanto vale um bom programador. Se ele te oferece pouco, certamente é porque seu trabalho para ele vale pouco. Se vale pouco, para que ser escravizado?
A melhor forma de escapar desta armadilha é o planejamento. Muitas vezes somos obrigados a aceitar qualquer coisa que colocam em nossa frente porque não temos um planejamento financeiro adequado e nos vemos numa situação que é pegar ou largar. Não vou aqui ensinar regras de economia pessoal para você mas acredito que seria muito bom ler alguma coisa sobre o assunto e praticar. Com isso não precisa passar por apertos e pode ser valorizado como deve realmente.
Finalmente, como última dica; Seja humilde
Ninguém sabe tudo! Quando você toma uma postura como esta, mantém os braços abertos para receber novas informações e aprender mais, principalmente com aqueles que sabem algo diferente de você. Isso inclusive deve ser usado não somente relacionado com a metodologia ou linguagem que usa, mas sim em toda a área da programação. Muitas vezes você pode ter a solução de um problema baseando-se no conhecimento de outra pessoa que programa em linguagem diferente da sua ou que usa métodos diferentes dos seus.
Obs: agradecimentos ao leitor Luiz Pedro Jr. pela pergunta que resultou neste artigo.