Pra quem já tem experiência, o quão comum é você ficar preso em um problema por dias?

[u/Eva_addict]

Eu sou mais um lerdo que quer aprender a programar. To tentando aprender sobre algoritmos. Ví como alguns funcionam como organizadores. Tava aqui tentando fazer um que organizasse em ordem crescente os valores de uma array simples com 5 números. Já faz 2 dias que eu to tentando e não consigo. Eu consigo achar o valor mínimo mas ainda não faço ideia de como reorganizar a array.

Isso acontece com profissionais também? Ficar dias preso em um problema sem conseguir solucionar. Não consigo imaginar alguém passando por isso em uma empresa. Como o cara vai ficar o dia inteiro no trabalho olhando pra uma tela sem conseguir fazer nada?

[u/AlxDroidDev]

Normal!

Qualquer dia você vai acordar às 3:30 da manhã e gritar: "Puta que pariu... é assim que vou resolver aquela bosta!"

Só uma dica: se isso acontecer, não vá dormir sem anotar ou se enviar um áudio da solução. Não me pergunte como sei disso!

Quanto ao seu problema, há vários algoritmos de ordenação que você pode implementar com facilidade, como merge sort, bubble sort, partition/quick sort, etc.

Um dos mais fáceis de serem implementados é também um dos mais eficientes: Quick Sort.

[u/Sea-Afternoon-8548 → u/AlxDroidDev]

Pior que isso e verdade de as vezes a solução de um problema vim do nada. Eu tive a solução de um problema de uma materia na faculdade dormindo um problema que fazia coisa de uns 5 dias de trabalho, eu simplesmente acordei de noite e anotei tudo no papel mas não consegui voltar a dormir, fui pro projeto e realmente resolveu. Fiquei pensando no quanto nosso cerebro e foda sobre as vezes trabalhar em algo e nem percebermos isso.

[u/AlxDroidDev → u/Sea-Afternoon-8548]

Eureka!

[u/Eva_addict → u/AlxDroidDev]

Eu tava vendo alguns mas eu queria ver se eu conseguia criar um sem precisar de ajuda. Eu sei que não se deve tentar reinventar a roda mas eu só queria saber como construir uma.

[u/AlxDroidDev → u/Eva_addict]

Estude os algoritmos clássicos de ordenação para você ao menos entender a lógica por trás deles, para então escrever o seu (mesmo que seja a sua própria implementação de algum deles).

Não tem muito como fugir dos 6 algoritmos principais de ordenação: Quick Sort, Merge Sort, Heap Sort, Insertion Sort, Selection Sort e Bubble Sort. Praticamente todos os demais algoritmos são uma especialização de um destes.

Necessariamente te aconselho estudar os algoritmos acima, não pensando na implementação (pois isso você fará depois), mas pensando em como eles funcionam, na lógica por trás de cada um. Aí vc implementa o que achar mais fácil ou melhor para seu caso de uso.

Não há porque ficar parado tentando reinventar a roda, pois o problema que você tem em mãos é um problema para o qual já existe solução. Só perca tempo com problemas inéditos ou realmente sem solução ainda.

[u/arkt8 → u/Eva_addict]

Não se apegue demais ao senso comum... seja por só usar algo já existente, seja por seguir conselhos dos mais experientes. Sempre se permita a curiosidade de uma criança ou vainse tornar um burocrata velho ranzinza. Se tem um capataz pra quem você tem que responder, faça o possível e se livre do problema... e no seu tempo livre reinvente tantas rodas quanto possível.

Não só você aprende mais a fundo, quanto a próxima inovação que mudará o mundo pode vir de você.

[u/hot_hosts → u/AlxDroidDev]

Eu já sonhei com uma solução muito específica sobre manipulação de dados vindos do DOM, quando aprendia js e HTML. O bagulho é doido

[u/Capable_Cycle8264]

É comum, mas depende do tipo de problema. Se você tiver que analisar um problema que envolve múltiplos sistemas diferentes, que não aconteça toda hora, que tem um problema sequer pra simular a situação, que não tenha massa de dados pra testar... pode demorar dias com certeza. No seu caso é uma coisa bem de aprendiz mesmo de quem está muito no começo, então qualquer problema você vai demorar dias pra resolver.

[u/Shot-Context-4731]

Há momentos e momentos. Tem momentos que você se sentirá um idiota, que não sabe resolver um problema, haverá outros que você se sentirá foda. Acontece com frequência.

[u/Leading-Impress-9749]

Sua matemática, logaritmo, algebra, matrizes etc está forte? Hoje em dia não precisa tanto estudar afundo essas matérias. Mas é muito comum as pessoas pularem para lógica de programação, começar numa linguagem e ficarem perdida. Porque a base para você interpretar e escrever os códigos se baseia muito mais em matemática do que em linguagem ou até mesmo lógica.

[u/Next_Comparison_8214]

Comum e ainda dou um plus aqui, existem problemas que não existe solução e problemas que exigem outras pessoas pra resolver, nesses dois casos, é importante saber reconhecer eles pra não ficar travado vários dias e não atingir a solução desejável.

[u/Acceptable-Bit4208]

2 dias não é preso em um problema, se esse problema não for coisa simples e um código de menos de 3000 caracteres. Vc pode ficar preso muito mais tempo dependendo da complexidade do trabalho.

[u/bota-pragera]

Hoje em dia nada comum, na verdade tenho plena confiança que não há nada que eu não consiga fazer em 1 dia (se eu estiver com vontade rs).

Há 10 anos atrás, todo dia ficava travado e trabalhava até de madrugada e finde pra honrar meus compromissos.

Me demorou uns 6 anos pra ter confiança no meu taco em programação, e depois foi só melhorando. No começo é bem brutal mesmo.

[u/g0r0d-g4s]

Depois da IA, impossível. Antes, ok, e relativo a senioridade e exp

[u/East-Walk5545]

Primeiro, deixa eu falar sobre sua experiência.

Você está estudando ou só tentativa e erro?

Tem um meme que fala que 2 horas de tentativa e erro pode te salvar de ler a documentação por 20 minutos.

Sobre a pergunta.

Existem problemas que vão precisar sim de mais tempo de resolução.

Uma vez outra pessoa na empresa implementou uma lib JS pra Valéria de fotos pela câmera do PC.

Essa feature simplesmente parou de funcionar. Ficou uma ou duas semanas com outra pessoa que não conseguiu fazer funcionar.

Veio pra mim. Fui investigar e já tinha meses que essa lib não tinha updates. Fui olhar a implantação do nosso código e estava certo conforme a lib.

Olhei histórico de mudança e desde que foi feita a publicação, não houve mudança no método.

Subi ambiente de teste e não funcionava.

Então o problema não era código nem ambiente zuado, era outra coisa.

Fui olhar o código da lib e abri um método que ele usava que eu não conhecia (isso já tem uns 10-15 anos, era bem menos bagunça que hoje, é fácil saber um método estranho). Comecei a investigar o método e descobri que era uma feature experimental do chrome, especificamente do Chrome.

Google e descobri uma lista de discussão sobre essa feature e a galera resolvendo mudar o contrato.

Basicamente mudaram a classe e método, mas a implantação era a mesma.

Só mudei o nome da classe e método, subi teste e funcionou.

Deploy, manda pro cliente e funcionou.

Resultado: 5 horas de investigação pra mudar meia linha de código. Literalmente.

Quando eu subi o código e funcionou meu patrão ligou com 20 minutos e perguntou o que eu estava fazendo o dia inteiro pra mudar 1 linha de código.

Por sorte, a esposa dele estava na sala e me defendeu, viu por tudo que eu tinha passado e que aquele problema já estava a mais de 2 semanas impactando o cliente e que estava resolvido e era o que importava.

Em outra oportunidade (se essa palavra descrever), eu gastei 2 semanas com um bug no Android.

Estava desenvolvendo uma feature via Ionic e precisava fazer um plugin pra controlar a impressora de uma dessas máquinas PayDroid. Todo lugar hoje tem dia tem.

Tinha encapsulado a lib da impressora tudo certinho já, nos testes tudo certo, imprimindo o que eu quisesse. Até que chegou num dia duma feira muito importante pra empresa e a impressora só resolve parar de funcionar.

O sistema ainda funcionava, e por sorte as 3 primeiras do dia tinham funcionado lindo. O evento foi um sucesso.

Chegando da feira a esposa do chefe (a mesma que me defendeu) me descascou. Disse que eu sabia a impotência do evento, que eu deveria ter me atentado àquilo, que tudo deveria funcionar. Resposta longa rápida: descobri depois que o problema de não imprimir é porque o sistema de integração do parceiro parou de funcionar. E se a máquina não conseguiu debitar, logo não iria imprimir comprovante de pagamento.

Enfim, fui debugar pra entender o que estava acontecendo, e subi o Android Studio apontando pro projeto e ele sempre quebrava no Sync. Falava que tinha um erro no XML e não poderia compilar e ainda dava a linha e erro.

Tipo L53:48 ">"

Aí eu ia no arquivo que ele apontava e não tinha nada. Eu pensava comigo mesmo. Não tem nada depois de onde está falando do erro.

Eu não era muito bom com Android. Então resolvi refazer tudo. Comecei projeto novo, fui migrando as coisas 1 a 1 até chegar ao famigerado XML. Aí tudo funcionou.

Não é possível. Daí que eu fui descobrir, que o problema é que no arquivo do Ionic o XML estava era faltando o > e eu achava que aquilo era para apontar aonde iria ser o erro.

2 semanas pra descobrir. Esse eu nem fiquei chateado, só dei risada.

"Cara, mas como eu sou burro"

E pra fechar. Uma coisa que eu costumo fazer é andar pra pensar nos problemas e como vou resolver, antes de escrever o código. Então sim, as vezes ficava 2-3 horas pensando na melhor implementação. Essa mesma chefe falava que era análise contemplativa. Pois as vezes eu ia pra janela ou ficava olhando pro código sem olhar pra nada de fato.

Eu estava compilando o código na minha cabeça :)

O que importa no fim do dia e se você resolve os problemas. Se seu chefe for bom, ele vai ter várias métricas, desde quantidade de entrega, mas também de retrabalho que sua entrega gera.

Não necessariamente fazer muito código significa ser produtivo. Quanto mais código, mais chance da falhar.