Autonomia & Tecnologia

Programador: Liberte-se da caixa!

Neste post, você vai entender o que é estar dentro da caixa, como essa caixa pode afetar a sua carreira e o que fazer para não ficar preso nela. Confira!

9

É muito comum ouvir pessoas falando sobre a importância da criatividade no universo profissional. Existem blogs, palestras e muitos materiais que prometem nos ensinar a pensar fora da caixa. Mas você já se perguntou o que é estar dentro da caixa?

Olhando para dentro da caixa

O mundo é extremamente complexo e para lidarmos com isso, desenvolvemos a necessidade de dar nome às coisas, organizando tudo em categorias.

No entanto, em algum momento essa dinâmica foi intensificando ao ponto que os nomes deixaram de ser etiquetas para facilitar a referência a algo, e se tornaram caixas opacas se confundindo com a coisa em si.

Foi nessa loucura que começamos a nos reduzir aos nomes. Passamos a enxergar a nós mesmos e os outros como meros objetos. Locais de trabalho viraram sobrenome: Arnaldo da Empresa de 3 Letrinhas. Cargos viraram qualidades: CTO Bóris. Função virou identidade: Clóvis, o Programador.

O grande problema é que estes nomes e rótulos tem utilidade limitada, eles são como caixas que não se expandem e não são capazes de representar integralmente quem realmente somos.

Como saber se você está dentro da caixa?

Trazendo esta ideia para a área de TI, podemos perceber um sintoma dessa objetificação quando um programador se sente ofendido porque alguém falou mal da linguagem que ele usa ou quando ele sente raiva de alguém que criticou seu código.

Lembre-se: o código que você escreve não te define! Apenas sugere algo sobre o contexto no qual você o escreveu: condição, pressão, tempo, informação, humor, etc. Por exemplo: o código criado após uma boa noite de sono é completamente diferente do código criado em um final de semana virando noite correndo atrás do prazo.

De toda forma, por mais que haja um componente artístico na prática de programação, o propósito do código é resolver o problema do cliente. O valor que o código gera não está nas linhas escritas, mas na solução de um problema obtida com a execução do código.

Você pode se prejudicar por estar dentro da caixa?

Quando nos definimos apenas como programadores, nos limitamos! Ficamos reduzidos a uma mera função, projetamos a nossa identidade no que fazemos e não em quem somos. Ignoramos o fato de que somos pessoas multi-talentosas com habilidade de programar.

Cada vez mais a programação é um meio, uma ferramenta incrível para conseguir diversos fins. Isso significa que o mercado de tecnologia está se expandindo exponencialmente e permeando todos os outros mercados. Isso coloca as pessoas com habilidades de programar em uma posição estratégica para aproveitar as oportunidades que surgem.

Sempre que eu converso sobre esse assunto com a galera, alguem pergunta:

Tá Henrique, mas a nossa área muda tão rápido que mal damos conta de nos atualizar nas questões do código em si. Como conseguiremos perceber as oportunidades de geração de valor e riqueza?

É aí que está o desafio! Para sair da caixa que o mercado insiste em nos colocar, precisamos alinhar simultaneamente três questões fundamentais:

  1. como você faz (nível prático);
  2. o que você faz (nível tático);
  3. porque você faz (nível estratégico).

Muitos programadores acabam se limitando a uma dessas questões. Mas como eu disse, o real desafio é se desenvolver nestes quesitos simultaneamente, pois uma coisa alimenta a outra. Observe:

1) Saber como programar é pré-requisito.

Dominar a linguagem e as ferramentas é essencial para realizarmos a atividade de programação.

2) Saber o que fazer é o meio de campo.

São as táticas que você cria e aplica para viabilizar a solução necessária para o problema, respeitando todas as restrições.

3) Saber porque fazer te dá “visão além do alcance”.

Exige entendimento do problema que você está resolvendo em múltiplos níveis, pois é impossível programar algo que você desconhece.

Como colocar tudo isso em prática?

Aprender a navegar por estas camadas sem me restringir foi e é essencial na minha carreira. Para mim, a verdadeira autonomia está na capacidade de conseguir visitar as caixas conforme meu interesse e necessidade, sem ter que me limitar a nenhuma delas.

Quando você desenvolve esta habilidade de alinhar as 3 camadas, você rapidamente estabelece um ciclo de produtividade que se retroalimenta conectando você cada vez mais com o valor que você gera. É essa mudança que desloca da vida de um executor de demandas para um se tornar um solucionador de problemas.

Ser um programador fora da caixa é um processo contínuo, que se for bem estruturado pode ser simples e trazer benefícios fantásticos. Ultimamente, tenho abordado essa forma sistêmica de programar em dois ambientes:

No Welcome to the Django, onde nós aplicamos estratégias, táticas e práticas para executarmos um sistema real de ponta à ponta e de forma indolor (acredite, 0 dores de cabeça).

E na série gratuita de vídeos “Como ser protagonista da sua carreira na transformação”, que foi lançada nesta semana, onde no primeiro vídeo da série eu explico porque é tão difícil manter a satisfação trabalhando no mercado de tecnologia – você pode assistir clicando aqui.

E aê, o que achou do texto? Você se sente preso em uma caixinha? Já saiu dela há tempos? Conta pra mim como foi o processo!

Estou esperando o seu comentário!

Abração, HB.

 


Imagem originalmente postada em: Jobs&Careers

você pode gostar também
  • João Paulo Oliveira

    Caramba já o quarto artigo que leio seu hoje, fiquei aqui preso no seu site lendo as postagens, descobri seu site por acaso e você fala boa parte das coisas que eu falo, e que eu sempre reflito.

    Você não fala só de programação e sim de lição de vida, lição de um ser humano mesmo, nem explicar bem. Mas eu achava que estava sozinho numa jornada de tentar alinhar tecnologia a vida, todos dão risada da minha cara porque tenho essas ideias.
    Eu venho tentado aprender a programar (comecei a estudar Python), mas nunca sai do basicão if else e entre outras coisas,acho que estou caindo na armadilha de dar ouvidos aos críticos, de tipo as pessoas darem risada do meu código e etc.
    Sobre questões voltadas a vida em si, eu gosto sempre estou metido em outros assunto (eclético)
    pois quando debato sobre outros assuntos fora da área de tecnologia é como se minha expandisse eu vejo sempre uma solução de como resolver aquela coisa, tenho uma vontade enorme de alinhar a minha satisfação pessoal com o gosto da tecnologia, se você tiver algum grupo de estudos que tenha pessoas boas assim como vc me avisa por favor. E obrigado por seus textos 🙂 Espero um dia poder conversar com vc pessoalmente e trocar ideias .

  • Excelente texto!

  • Luiz Alberto Melchert de Carva

    Lido com TI há mais de trinta anos e observo que os programadores são escravos do que surge de novo sem verificar se não é algo que ele já conhece com nome novo. Aí, o programador abraça siglas e nomes como se isso fosse resolver todos os problemas da humanidade. Adotam um jargão odioso como “Esse cara faz isso” ao referir-se a uma classe ou a um método. São pessoas que, se estivessem dirigindo um carro, tentariam mudar para um mais novo sempre que para num semáforo. O resultado é que não consegue dar um projeto or findo e nunca atende as necessidades do usuário. Some-se a isso a vergonha que sente por não estar usando o que acabou de ser lançado e gasta mais temo na Internet lendo sobre coisas que não poderá usar imediatamente do que, de fato, programando. Por causa disso, numa mesma versão de um produto, encontramos uma verdadeira colcha de retalhos tecnológicos em que que ninguém consegue dar manutenção. Pessoalmente, considero que a lógica é soberana e a linguagem é a forma e aprendo com grande facilidade a programar em qualquer uma delas. Só que não jogo fora o que aprendi e uso características de uma na outra, como a organização do Cobol, a estruturação do Xbase, a capacidade de gerar scripts durante a execução do Python entre outras facilidades, sempre procurando mudar de plataforma depois de esgotar todos os recursos da anterior.

    • Interessante suas observações, Luiz.

      Eu noto o efeito negativo da hype e por isso acho fundamental se proteger dela.

      Do outro lado eu também noto o efeito positivo das novidades e dessa forma eu acho importantíssimo compreender as inovações não apenas olhando para frente, mas integrando o novo conhecimento ao que já existe.

      • Luiz Alberto Melchert de Carva

        Não resta a menor dúvida de que precisamos estar a par do que acontece ao nosso redor. O que não dá é tentar adotar tudo o que existe de novo num projeto em andamento. A indústria em geral não faz isso para ter uma certa unicidade de desenvolvimento. A VW, por exemplo, acaba de soltar uma nova plataforma e o primeiro carro a ser lançado nela é o Polo, depois virão outros, até que essa plataforma não responda mais técnica e economicamente, sendo abandonada por outra melhor. A melhoria contínua é respeitada melhorando-se componentes mas a arquitetura está lá coesa. Os programadores, por lidarem com algo impalpável, não entendem bem isso e, durante o desenvolvimento, mudam de linguagem, de plataforma e de banco de dados, ou seja, estão sempre num ponto anterior ao ponto de inflexão na curva de conhecimento. Se agirmos como a indústria, que se apoia numa plataforma, desenvolve nela enquanto seu ganho marginal for positivo, mudando somente no lançamento de um novo projeto, a velocidade de desenvolvimento sobe muito, acelera-se o nivelamento da equipe e todos ficam mais felizes. Duro é o que acontece em várias consultorias que tenho dado em que desenho um projeto baseado numa plataforma e, no meio do caminho, fulano descobre um novo método na internet e acha que, se não empregar imediatamente, será um dinossauro informático. Só que ele não sabe lidar com a ferramenta e perde um tempo precioso aprendendo, enquanto já poderia ter resolvido o problema com o que já sabia. Acho que sim, que devemos ter um tempo até diário para estudar e descobrir coisas novas, armazenando-as em uma biblioteca a ser usada num projeto vindouro para não prejudicar a coesão do projeto em curso.

  • Marcelo Andriolli

    Muito bom! Achei interessante a abstração das três questões do como, o que e porque, me remeteu o ao golden circle por conta do o que, como e porque.

    • Bela lembrança. Não tive isso em mente quando escrevi, mas tem total relação.

      • Marcelo Andriolli

        nesse caso eu chamaria de “the fucking dev circle”