Também já contribuí com a parte de gerenciamento de memória do kernel Linux e acho que entendo, até certo ponto, como funcionam os mecanismos de baixo nível, mas, pensando que no fim acabei fazendo um trabalho que, contra a minha vontade, fica distante do desenvolvimento, chego a pensar que, para se dar bem como engenheiro, talvez seja preciso agir de forma oposta ao que este texto diz.
Acompanhar novas tecnologias rapidamente
Pensar no mercado antes da curiosidade pessoal
Saber se vender melhor do que se criticar
Focar mais em testes de coding do que em work-life balance/crescimento
Quando voltei ao país, percebi que a Coreia tem um mercado pequeno demais e uma concorrência muito forte, então há poucas empresas e posições em que dá para se concentrar em desenvolvimento; e, como todo mundo disputa essas poucas vagas, no fim parece que é preciso focar no que chama mais atenção para conseguir fazer o tipo de desenvolvimento que se quer.
"Não precisamos de um aluno nota A+ que consiga responder a todas as perguntas
O que queremos é um aluno nota B que consiga ver e questionar o que os outros deixaram passar"
Ao ver isso, pensei imediatamente que eu sou esse aluno B, mas as grandes empresas só olham para alunos nota A+ na hora de contratar.
Há algum tempo, cheguei a fazer um seminário na empresa para um estudo da linguagem Kotlin e lembro que a reação foi boa quando tentei explicar comparando com a linguagem C++, que é a mais usada no departamento. Eu quase não uso C++, e os colegas do departamento estavam tendo contato com Kotlin pela primeira vez, mas pareceu ajudar bastante no crescimento de todo mundo em vários aspectos.
Acho que há um erro de tradução no último item do resumo de opiniões do Hacker News, “A suposição de que a produtividade do software não aumentou de 5 a 10 vezes pode estar errada”. Pelo texto original, um resumo mais neutro seria algo como: “Dizer que a produtividade do software aumentou de 5 a 10 vezes se baseia em premissas equivocadas sobre ganho de produtividade”.
Sim, concordo. Acho que a própria pessoa também precisa se mostrar, e seria bom se as pessoas que ajudam muito se dessem bastante reconhecimento mutuamente. A própria cultura da organização incentiva isso.
> A maioria dos programadores não sabe como usar ferramentas de LLM de forma eficaz ou não tem interesse nisso
Surpreendentemente, muitos desenvolvedores ao meu redor não se interessam por tecnologia. Eles passam a maior parte do tempo consumindo mecanicamente shorts do YouTube, novos ou repetidos.
Parece que o tweet não está lá, talvez o original tenha sido apagado.
Quero experimentar, mas mesmo sendo um período de preview, é pago e também não tem período de teste ;_;
Pesquisando, tem gente dizendo que gastou 5 dólares fazendo algumas consultas, então parece que varia conforme o volume de código do projeto.
Há muitas histórias interessantes, tanto do ponto de vista de RH quanto da cultura organizacional.
Como eu não conhecia bem o termo, fui pesquisar e vi que backdoor reference check significa uma verificação de referências não indicada. Estou deixando isso registrado caso haja outras pessoas como eu.
Nas empresas coreanas, muitas vezes a composição do conselho acaba sendo apenas para cumprir tabela, e esse tipo de questão é algo que você só percebe de verdade depois de empreender e fazer a empresa crescer a ponto de precisar de governança. Ainda assim, achei que valia compartilhar porque é um tipo de leitura que faz bem fazer antes.
> Mesmo quando a empresa poderia crescer mais, agir de forma a induzir um exit propondo um preço de aquisição para recuperar o investimento
Quando você passa por algo assim uma vez, a confiança nos investidores despenca.
Minha experiência profissional é curta, mas concordei com o conteúdo do texto e, ao mesmo tempo, também penso que é algo a se evitar trabalhar “silenciosamente”. Mesmo sem chamar atenção de forma espalhafatosa, parece melhor para a própria pessoa fazer pelo menos um mínimo de autopromoção.
Pela minha experiência, em empresas grandes é bastante difícil que a demissão em si seja justa — é difícil cortar bem, exatamente onde realmente é necessário.
Por isso, mais ainda, as medidas de acompanhamento após as demissões são muito importantes. Moral dos funcionários, redistribuição adequada de recursos etc. Recontratar o pessoal necessário depois (isso pega mal, mas às vezes é inevitável...)
As tentativas de criar slideshows sem usar PowerPoint
vêm de uma longa tradição, começando pelo W3C slidy e passando por s3, s5, s6, s9…
E ir um passo além disso… fazer até a apresentação direto no terminal é bem interessante. O lado ruim é que… por enquanto os protocolos de gráficos de terminal (?!) ainda não são padronizados… então os terminais compatíveis são limitados…
Achei interessante também como eles reuniram várias centenas de milhares de pessoas em um Discord que só tem dois canais, #announcement e #use-cases, dizendo que de vez em quando vão liberar invitation codes.
Como o Cursor parece antiquado, fiquei com vontade de experimentar. Mas, como o custo não deve ser nada barato, não consigo nem me animar a tentar.
Hum, mas as opiniões no Hacker News são meio negativas.
Não seria uma falácia da generalização omitir as premissas, mesmo sendo uma afirmação que pode estar certa ou errada dependendo da situação? Acho que tanto “toda demissão não serve para nada” quanto “toda demissão é eficaz” são frases falsas. Se a empresa revisou seu plano de negócios e encerrou departamentos que não se encaixavam no plano, então a demissão não seria eficaz? Por outro lado, se até departamentos que sofrem com falta de pessoal ou têm alta carga de trabalho foram demitidos em massa sob o pretexto de redução de custos, então a demissão não foi eficaz.
Pelo texto sozinho, não dá para saber se o autor está assumindo alguma situação específica, ou se, mesmo sabendo disso, comete a falácia da generalização por algum outro motivo.
Também já contribuí com a parte de gerenciamento de memória do kernel Linux e acho que entendo, até certo ponto, como funcionam os mecanismos de baixo nível, mas, pensando que no fim acabei fazendo um trabalho que, contra a minha vontade, fica distante do desenvolvimento, chego a pensar que, para se dar bem como engenheiro, talvez seja preciso agir de forma oposta ao que este texto diz.
Quando voltei ao país, percebi que a Coreia tem um mercado pequeno demais e uma concorrência muito forte, então há poucas empresas e posições em que dá para se concentrar em desenvolvimento; e, como todo mundo disputa essas poucas vagas, no fim parece que é preciso focar no que chama mais atenção para conseguir fazer o tipo de desenvolvimento que se quer.
"Não precisamos de um aluno nota A+ que consiga responder a todas as perguntas
O que queremos é um aluno nota B que consiga ver e questionar o que os outros deixaram passar"
Ao ver isso, pensei imediatamente que eu sou esse aluno B, mas as grandes empresas só olham para alunos nota A+ na hora de contratar.
Acho que o MCP não chega a ser JSON, porque também não é uma especificação para comunicação de dados, e considero isso complicado demais.
Há algum tempo, cheguei a fazer um seminário na empresa para um estudo da linguagem Kotlin e lembro que a reação foi boa quando tentei explicar comparando com a linguagem C++, que é a mais usada no departamento. Eu quase não uso C++, e os colegas do departamento estavam tendo contato com Kotlin pela primeira vez, mas pareceu ajudar bastante no crescimento de todo mundo em vários aspectos.
Acho que há um erro de tradução no último item do resumo de opiniões do Hacker News, “A suposição de que a produtividade do software não aumentou de 5 a 10 vezes pode estar errada”. Pelo texto original, um resumo mais neutro seria algo como: “Dizer que a produtividade do software aumentou de 5 a 10 vezes se baseia em premissas equivocadas sobre ganho de produtividade”.
Sim, concordo. Acho que a própria pessoa também precisa se mostrar, e seria bom se as pessoas que ajudam muito se dessem bastante reconhecimento mutuamente. A própria cultura da organização incentiva isso.
O terminal é realmente...
> A maioria dos programadores não sabe como usar ferramentas de LLM de forma eficaz ou não tem interesse nisso
Surpreendentemente, muitos desenvolvedores ao meu redor não se interessam por tecnologia. Eles passam a maior parte do tempo consumindo mecanicamente shorts do YouTube, novos ou repetidos.
Tenho curiosidade se o MCP pode se tornar JSON.
Parece que o tweet não está lá, talvez o original tenha sido apagado.
Quero experimentar, mas mesmo sendo um período de preview, é pago e também não tem período de teste ;_;
Pesquisando, tem gente dizendo que gastou 5 dólares fazendo algumas consultas, então parece que varia conforme o volume de código do projeto.
Há muitas histórias interessantes, tanto do ponto de vista de RH quanto da cultura organizacional.
Como eu não conhecia bem o termo, fui pesquisar e vi que
backdoor reference checksignifica uma verificação de referências não indicada. Estou deixando isso registrado caso haja outras pessoas como eu.Acho que isso seria um método concreto de prática profunda mencionado no livro The Talent Code. Obrigado pelo ótimo texto.
Nas empresas coreanas, muitas vezes a composição do conselho acaba sendo apenas para cumprir tabela, e esse tipo de questão é algo que você só percebe de verdade depois de empreender e fazer a empresa crescer a ponto de precisar de governança. Ainda assim, achei que valia compartilhar porque é um tipo de leitura que faz bem fazer antes.
> Mesmo quando a empresa poderia crescer mais, agir de forma a induzir um exit propondo um preço de aquisição para recuperar o investimento
Quando você passa por algo assim uma vez, a confiança nos investidores despenca.
Minha experiência profissional é curta, mas concordei com o conteúdo do texto e, ao mesmo tempo, também penso que é algo a se evitar trabalhar “silenciosamente”. Mesmo sem chamar atenção de forma espalhafatosa, parece melhor para a própria pessoa fazer pelo menos um mínimo de autopromoção.
Pela minha experiência, em empresas grandes é bastante difícil que a demissão em si seja justa — é difícil cortar bem, exatamente onde realmente é necessário.
Por isso, mais ainda, as medidas de acompanhamento após as demissões são muito importantes. Moral dos funcionários, redistribuição adequada de recursos etc. Recontratar o pessoal necessário depois (isso pega mal, mas às vezes é inevitável...)
As tentativas de criar slideshows sem usar PowerPoint
vêm de uma longa tradição, começando pelo W3C slidy e passando por s3, s5, s6, s9…
E ir um passo além disso… fazer até a apresentação direto no terminal é bem interessante. O lado ruim é que… por enquanto os protocolos de gráficos de terminal (?!) ainda não são padronizados… então os terminais compatíveis são limitados…
FYI, ferramentas de apresentação baseadas em Markdown…
https://gist.github.com/johnloy/27dd124ad40e210e91c70dd1c24ac8c8
Achei interessante também como eles reuniram várias centenas de milhares de pessoas em um Discord que só tem dois canais,
#announcemente#use-cases, dizendo que de vez em quando vão liberar invitation codes.Como o Cursor parece antiquado, fiquei com vontade de experimentar. Mas, como o custo não deve ser nada barato, não consigo nem me animar a tentar.
Hum, mas as opiniões no Hacker News são meio negativas.
Não seria uma falácia da generalização omitir as premissas, mesmo sendo uma afirmação que pode estar certa ou errada dependendo da situação? Acho que tanto “toda demissão não serve para nada” quanto “toda demissão é eficaz” são frases falsas. Se a empresa revisou seu plano de negócios e encerrou departamentos que não se encaixavam no plano, então a demissão não seria eficaz? Por outro lado, se até departamentos que sofrem com falta de pessoal ou têm alta carga de trabalho foram demitidos em massa sob o pretexto de redução de custos, então a demissão não foi eficaz.
Pelo texto sozinho, não dá para saber se o autor está assumindo alguma situação específica, ou se, mesmo sabendo disso, comete a falácia da generalização por algum outro motivo.
Obrigado. Foi interessante estudar pesquisas validadas há muito tempo e aplicá-las à IA.