Quando ensino programação pela primeira vez, acho que o primeiro sinal de aptidão como programador aparece em saber ou não ler as mensagens de erro com atenção.
Eu nunca tinha pensado nisso como algo semelhante a um trabalho artesanal, mas concordo muito.
Pensando por esse ponto de vista, parece que muitos fenômenos passam a fazer sentido.
Depois de ler os comentários críticos, fiquei pensando bastante. Há pontos com os quais concordo, e outros sobre os quais penso diferente.
Pode haver, até certo ponto, uma bolha em torno do status atual dos desenvolvedores, mas acho que isso vale para outras profissões também. De algo mais restrito para algo mais amplo. Ou seja, à medida que o número de profissionais cresce e a diversidade aumenta, isso é um fenômeno natural. Não estou dizendo que essa direção esteja necessariamente certa, mas não acho que isso aconteça de forma especialmente marcante apenas com os desenvolvedores.
É fácil aprender. Concordo, mas ter uma barreira de entrada baixa não significa ter baixa especialização. Acho que, em comparação com outros setores, especialmente outras funções técnicas da manufatura, o motivo de ser mais fácil aprender não é porque desenvolver em si seja fácil, mas talvez por causa da cultura open source e do baixo risco. Como falei antes sobre a diversidade entre desenvolvedores, há trabalhos que podem ser aprendidos e feitos rapidamente, e há trabalhos que precisam se basear em especialização.
O ambiente mudou. Não acho que o motivo de as expectativas e recompensas do mercado em relação aos desenvolvedores serem maiores do que no passado seja apenas a habilidade, a experiência ou a especialização deles. Quanto mais o IT se aprofunda na vida humana, mais importante o software se torna, sustentando uma enorme quantidade de infraestrutura. Não acho que a remuneração aumente porque a capacidade de cada desenvolvedor cresceu, mas porque o próprio trabalho ficou mais caro. Afinal, ele se tornou mais importante do que antes.
Faz sentido comparar diretamente com a manufatura? Do ponto de vista de que a sofisticação da indústria ainda não amadureceu o suficiente, esse termo de comparação parece ser a manufatura. Se tentarmos entender a indústria de software pelo paradigma da manufatura, ela pode parecer um trabalho artesanal ou desenvolvimento por hobby. Mas, por outro lado, acho que justamente esses aspectos criam uma cultura flexível e criativa própria do desenvolvimento de software, e que ele cresce apoiado nisso.
Envolvimento excessivo é perigoso. Concordo muito. Desenvolver não é a única coisa que existe no mundo para estudar e, no fim das contas, ainda escrevemos "funcionário de empresa" no campo profissão. Mesmo que haja uma bolha no clima social, é preciso tomar cuidado para não achar que isso torna a área algo muito diferente das outras profissões. Mas isso vale para qualquer profissão.
Para a Toss, UX está diretamente ligado à sobrevivência
Mas, por outro lado em relação a este texto, não sei se essa empresa persegue bem a lucratividade
Acho que esse tipo de feedback, dependendo da personalidade, da cultura e das diferenças individuais, pode soar desagradável ou até causar raiva quando a pessoa ouve. Mas, no geral, abordar isso partindo do princípio de que "essa pessoa não está tentando me atormentar de propósito" parece ser melhor tanto para a saúde mental quanto para o crescimento. Quando uma situação assim surgir, acho que dá para lembrar deste texto e pensar: "Será que esse gerente também?". Ótimo texto.
Se alguém corrigir um erro de ortografia, bastaria agradecer e dizer “não sabia”; não parece ser algo que justifique ficar bravo. Acho que pensar que os outros vão sentir o mesmo que você sentiu é uma generalização perigosa. E não é "aceitar separado", mas sim "aceitar".
Ao pensar na adoção de IA, é preciso olhar não pela perspectiva da velocidade de desenvolvimento, mas pela perspectiva da expansão do pensamento, mas parece que ainda existem gestores obcecados com velocidade. Quando vejo os produtos que defendem o uso de IA, no geral não há nada tão especial, e no máximo fazem uma validação de mercado de vez em quando; será que estão ajustando o nível do próprio produto que estão criando a isso?
Uau... isso é bem significativo, não? Até as tarefas relacionadas a impostos vão ficar muito mais fáceis, e a precisão das estatísticas também deve aumentar.
Como usuário que vem usando do XE1 dos primórdios até o Rhymix há mais de uma década, é um conteúdo com o qual dá para se identificar bastante.
Acho que o maior problema é que grande parte do mercado que o Rhymix mira não tem capacidade suficiente para desenvolver por conta própria.
Quem tem essa capacidade, em vez de aceitar a documentação insuficiente, a estrutura ambígua e os legados do XE ou do Rhymix, muitas vezes acaba adotando algo como Laravel.
Assim como o autor do texto original, eu também
um painel administrativo com o qual muita gente provavelmente se sente familiar
funcionalidades de CMS que, mesmo com alguns pontos frustrantes, não deixam a desejar
uma equipe de desenvolvimento do core que incorpora ativamente novas propostas
o apego de usá-lo há muito tempo
e assim por diante, por esses motivos também tenho adotado o Rhymix em alguns projetos novos, mas sempre fico pensando bastante se essa escolha é realmente a certa.
Tenho feito pessoalmente várias tentativas para complementar os pontos que senti falta ao usar o Rhymix como substituto de framework. https://github.com/nemorize/rx-make (branch develop / projeto PoC sem previsão de produção)
Tenho experimentado várias abordagens, como transformar o Rhymix inteiro em framework/biblioteca, minimizar o acesso às APIs legadas e reconstruir APIs mais modernas (mais ou menos compatíveis com as legadas), mas... isso realmente me faz pensar muito haha...
Nunca tinha organizado essas reflexões de forma clara, então vou aproveitar esta oportunidade para tentar colocá-las em ordem de maneira mais objetiva.
Os comentários no Hacker News dão medo... "Dez milhões? Tá de brincadeira?"
Embora digam que não é uma checklist, acho que vou adotá-la como minha checklist.
Um experimento realmente interessante.
Pelo visto havia um motivo para o Gemini estar com uma velocidade de time to first token tão absurdamente rápida ultimamente...
Concordo muito com a ideia de que é preciso consultar a documentação oficial.
Quando ensino programação pela primeira vez, acho que o primeiro sinal de aptidão como programador aparece em saber ou não ler as mensagens de erro com atenção.
Não são todos, mas a maioria dos itens realmente faz sentido para mim.
Eu nunca tinha pensado nisso como algo semelhante a um trabalho artesanal, mas concordo muito.
Pensando por esse ponto de vista, parece que muitos fenômenos passam a fazer sentido.
Hyperlight WASM: rápido, seguro e sem OS - Gerenciador de Máquina Virtual Leve (VMM) | GeekNews
Hyperlight WASM: rápido, seguro e sem OS | GeekNews
Depois de ler os comentários críticos, fiquei pensando bastante. Há pontos com os quais concordo, e outros sobre os quais penso diferente.
Para a Toss, UX está diretamente ligado à sobrevivência
Mas, por outro lado em relação a este texto, não sei se essa empresa persegue bem a lucratividade
Feliz aniversário. Ouça bem o que o tio diz e viva por muito, muito tempo com saúde.
Acho que esse tipo de feedback, dependendo da personalidade, da cultura e das diferenças individuais, pode soar desagradável ou até causar raiva quando a pessoa ouve. Mas, no geral, abordar isso partindo do princípio de que "essa pessoa não está tentando me atormentar de propósito" parece ser melhor tanto para a saúde mental quanto para o crescimento. Quando uma situação assim surgir, acho que dá para lembrar deste texto e pensar: "Será que esse gerente também?". Ótimo texto.
Se alguém corrigir um erro de ortografia, bastaria agradecer e dizer “não sabia”; não parece ser algo que justifique ficar bravo. Acho que pensar que os outros vão sentir o mesmo que você sentiu é uma generalização perigosa. E não é "aceitar separado", mas sim "aceitar".
Ao pensar na adoção de IA, é preciso olhar não pela perspectiva da velocidade de desenvolvimento, mas pela perspectiva da expansão do pensamento, mas parece que ainda existem gestores obcecados com velocidade. Quando vejo os produtos que defendem o uso de IA, no geral não há nada tão especial, e no máximo fazem uma validação de mercado de vez em quando; será que estão ajustando o nível do próprio produto que estão criando a isso?
Parece que são os braços direitos do CTO
Feliz aniversário ^^
Uau... isso é bem significativo, não? Até as tarefas relacionadas a impostos vão ficar muito mais fáceis, e a precisão das estatísticas também deve aumentar.
Como usuário que vem usando do XE1 dos primórdios até o Rhymix há mais de uma década, é um conteúdo com o qual dá para se identificar bastante.
Acho que o maior problema é que grande parte do mercado que o Rhymix mira não tem capacidade suficiente para desenvolver por conta própria.
Quem tem essa capacidade, em vez de aceitar a documentação insuficiente, a estrutura ambígua e os legados do XE ou do Rhymix, muitas vezes acaba adotando algo como Laravel.
Assim como o autor do texto original, eu também
e assim por diante, por esses motivos também tenho adotado o Rhymix em alguns projetos novos, mas sempre fico pensando bastante se essa escolha é realmente a certa.
Tenho feito pessoalmente várias tentativas para complementar os pontos que senti falta ao usar o Rhymix como substituto de framework.
https://github.com/nemorize/rx-make (branch
develop/ projeto PoC sem previsão de produção)Tenho experimentado várias abordagens, como transformar o Rhymix inteiro em framework/biblioteca, minimizar o acesso às APIs legadas e reconstruir APIs mais modernas (mais ou menos compatíveis com as legadas), mas... isso realmente me faz pensar muito haha...
Nunca tinha organizado essas reflexões de forma clara, então vou aproveitar esta oportunidade para tentar colocá-las em ordem de maneira mais objetiva.