Uncategorized

Por que os desenvolvedores de bugs são tão bem pagos?

O código que você escreve tem muitos bugs? Se sim, então você não está sozinho. A maioria dos desenvolvedores gasta mais da metade de seu tempo corrigindo bugs que eles não deveriam ter escrito em primeiro lugar. O que causa esses bugs? Vamos descobrir.

“If debugging is the process of removing software bugs, then programming must be the process of putting them in.” — Edsger Dijkstra

“Desenvolvedores de bugs” tendem a escrever código cheio de bugs. Eles estão mais inclinados a completar o trabalho atribuído e lhes faltam um toque pessoal e profissional para escrever código sem bugs de primeira. Soa áspero? Bem, não se desmoralize, pois não é a única razão por trás da escrita dos bugs. Muitos desenvolvedores simplesmente não têm a experiência para escrever código de alta qualidade com bugs mínimos. É preciso tempo e paciência para ser bom em seu ofício e escrever bugs, no início, é uma parte da viagem.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian Kernighan

Antes de nos aprofundarmos na verdadeira questão, primeiro precisamos abordar algumas questões fundamentais.

Quanto ganha um desenvolvedor de software?

Hoje em dia, desenvolvedores de software ganham muito dinheiro. Em média, eles fazem facilmente US$100.000 por ano nos EUA. No entanto, isso depende muito de suas habilidades, localização e da empresa em se está trabalhando. Se você estiver trabalhando para uma empresa de classe mundial, como o Google, você pode fazer o dobro dessa média.

Com o crescimento rápido da indústria, há uma necessidade constante de programadores talentosos. Se você souber o que você está fazendo e o fizer bem, as companhias irão pagar-lhe uma bela quantidade de dinheiro em troca de seu talento.

Antes de se tornar um engenheiro de software, primeiro você precisa se tornar um desenvolvedor de bugs.

Há sempre uma fase de transição. Você se lembra do primeiro programa que você codificou? O código pode ser um simples, “Olá, mundo” ou um programa que desenha um círculo na tela. Agora, compare com sua habilidade atual e quanto você melhorou. Incrível, né?

Agora você pode lidar com o desenvolvimento no mundo real. É complexo e implacável. Requisitos e prazo devem ser atendidos. A comunicação humana também não ajuda você a alcançar o seu melhor. Requisitos são mal compreendidos, o ruído de comunicação está sempre lá e assim por diante.

Você está mais para um “desenvolvedor de bugs” do que um desenvolvedor de software no começo. Isso lentamente desaparece à medida que você ganha experiência e habilidade.

Claro, você pode argumentar que não há diferença fundamental entre os dois. No entanto, a diferença significativa entre eles é o conhecimento, a experiência e a eficiência. E isso é bom.

O período de transição é obrigatório, e todo desenvolvedor passa por ele.

Veja o livecoder Thiagão desenvolvendo em C# um sistema ERP para gerenciar fazendas:

Quanto tempo leva você para a transição de um desenvolvedor de bugs para um engenheiro de software?

A resposta à pergunta depende do quanto você é bom. Você codificou quando você estava se formando? Quanto tempo você investiu em melhorar suas habilidades? E assim por diante.

Não há um tempo certo para alcançar a excelência no que você faz. Demora muito tempo para deixar de ser um desenvolvedor de bugs para um engenheiro de software que escreve código excelente.

Já mencionamos que o desenvolvimento de software é complexo. Além disso, a rápida mudança no mercado significa a evolução da tecnologia existente e a introdução de novas tecnologias. A cada cinco anos, o desenvolvedor precisa aprender novas habilidades para acompanhar a mudança de mercado que, em si, é uma façanha desafiadora.

Então, há um período de tempo que você pode atingir para se tornar bom? Demora entre 5 e 6 anos em média para se tornar um desenvolvedor melhor e escrever código melhor. Nessa altura, um desenvolvedor ganha experiência em vários projetos ou domínios. O fator chave aqui é a experiência que um desenvolvedor ganha ao longo dos anos.

De acordo com Malcolm Gladwell, 10.000 horas de prática deliberada pode ajudá-lo a alcançar uma habilidade melhor em seu ramo. Há também muitos estudos que contradizem as alegações de Malcolm Gladwell. No final, a situação, habilidade e experiência da pessoa desempenham um papel muito importante.

Quando você vai começar a sua carreira de desenvolvedor de bugs?

Escrever código buguento não é ruim. É apenas uma parte da viagem. Deixe-nos saber na seção de comentários abaixo quando você vai iniciar sua jornada e tornar-se um desenvolvedor de bug? Nós estamos ouvindo.

Ao transmitir sua experiência, você está apenas se beneficiando. Você pode voltar e verificar seus erros. Outros desenvolvedores também podem orientá-lo e ajudá-lo a melhorar mais rapidamente. Além disso, streaming de projetos on-line pode ajudá-lo a construir uma carteira on-line ao vivo que, por sua vez, pode ajudá-lo a chamar a atenção dos clientes.

Então, não se esqueça de transmitir suas aventuras no LiveEdu.tv, queremos ter certeza de que tudo está gravado 😉

 

Avatar
About author

I, Dr. Michael J. Garbade is the co-founder of the Education Ecosystem (aka LiveEdu), ex-Amazon, GE, Rebate Networks, Y-combinator. Python, Django, and DevOps Engineer. Serial Entrepreneur. Experienced in raising venture funding. I speak English and German as mother tongues. I have a Masters in Business Administration and Physics, and a Ph.D. in Venture Capital Financing. Currently, I am the Project Lead on the community project -Nationalcoronalvirus Hotline I write subject matter expert technical and business articles in leading blogs like Opensource.com, Dzone.com, Cybrary, Businessinsider, Entrepreneur.com, TechinAsia, Coindesk, and Cointelegraph. I am a frequent speaker and panelist at tech and blockchain conferences around the globe. I serve as a start-up mentor at Axel Springer Accelerator, NY Edtech Accelerator, Seedstars, and Learnlaunch Accelerator. I love hackathons and often serve as a technical judge on hackathon panels.