COMO PUNIR UM PROGRAMADOR QUE NÃO ENTREGA?

Desenvolvedor de Software que não entrega a tarefa corretamente, como podemos punir ele?
✅ Aulas ao Vivo de Desenvolvimento Android:
comercial1657028932.kpages.on...
✅ 𝗢𝗦 𝗠𝗘𝗟𝗛𝗢𝗥𝗘𝗦 𝗩𝗜𝗗𝗘𝗢𝗦 𝗗𝗢 𝗖𝗔𝗡𝗔𝗟
▸ Odeio Desenvolvimento Web do Fundo da Minha Alma | React do TabNews
• Odeio Desenvolvimento ...
▸ Abrindo o que faço na Disney+ como Software Engineer
• Abrindo o que faço na ...
▸ 2023 Programadores
• 2023 Programadores
▸ VAMOS FALAR de R$ 40.000,00 como Software Engineer
• VAMOS FALAR de R$ 40.0...
▸ NÃO DIGA TEU SALÁRIO PROGRAMADOR
• QUAL TEU SALÁRIO ATUAL...
✅ Torne-se membro para obter conteúdo exclusivo:
/ @lucasmontano
✅ Livros, Cursos, Equipamentos, Discord, Aplicativo Memo ↴
lucasmontano.com

[@dacaff]

Esse tweet diz mais sobre o autor do que sobre o Dev que "não entregou".. Parece os assuntos da sala de aula do meu filho de 5 anos.

[@mican3474]

Sou dev Júnior, minha maior dificuldade nos primeiros 6 meses de empresa, foi entender as tasks, a galera tem uma dificuldade de escrever certinho a tarefa

[@lokideveloper2034]

pode me dizer um exemplo de task? Para eu ir treinando meu estudo prático sabe

[@TheHackerHigor]

​​@@lokideveloper2034 uma tarefa que você deve fazer, por exemplo alguém encontra um texto que não está centralizado e cria uma task: "centralizar texto da página x". Obviamente também tem tasks mais complexas que podem ser subdividida em outras como a refatoração de um site que pode ser dividido por em varias tasks para cada páginas ou seção do site, etc. As vezes acontece de ter pouca informação e você não entender direito, pq as vezes quando vc olha o código vc pode pensar que não faz sentido ou que não é necessário, por isso é preciso sempre explicar bem e especificar a situação que o problema acontece, por exemplo o primeiro exemplo que eu dei, pode ser que o texto não fique centralizado só quando esta na versão mobile, se isso não for especificado a pessoa pode não entender direito e achar que não há nada a se corrigir 😅

[@tiagonyss]

@mican3474 acabastes de achar um "pleno" da tua empresa te stalkeando né @lokidev? ...kkkkkkkkkk

[@douglast.9790]

Manda os cara treinar o chatGPT pra criar as task certinhas

[@frnandoh]

@@lokideveloper2034 arrasta pra cima.

[@Jonathanlm.developer]

Mano em 8 anos trampando como dev Android / iOS, tarefas que eu peguei que estavam "redondinhas" foram pouquíssimas... O termo punição aliado ao estilo de respostas da thread me fez questionar os processos e o tipo de empresa em questão. Nunca recebi "punição" de empresa, acho de punição já basta a que o próprio dev se dá muitas vezes (cobrança de si mesmo que levam a ansiedade, insegurança, extrapolar limites, burnout etc). Existem casos e casos, e muitas vezes uma demissão além de não ser justificada, nem sempre pode ser considerado "punição". Eu mesmo e muitos colegas já passamos por isso (demissão injustificada), e aconteceu o famoso "caiu pra cima", vindo melhores oportunidades/maturidade/ambiente na sequência.

[@GCFTuto]

O processo de dev Todo cagado Vai punir o dev com demissão e depois Vai se lascar pra treinar outro

[@danilsonvss]

Rarida manito! Raridade!

[@WandersonItsMe]

Cara nem sou do meio da programação, na verdade já fui, porém a maioria dos problemas desse tipo eram por causa de notas recebidas pelo cliente que as vezes nem sabia o que queria, ou uma pessoa que intermediava isso passava errado, ou as vezes ambos, acho que nenhum profissional vai dedicar energia para fazer coisas erradas, seja na programação ou na minha área atual que é 3D e VFX.

[@WandersonItsMe]

Ou em qualquer área na verdade, esse é o ponto de saber ser profissional, qualquer um independente da ára vai se matar para fazer algo que vai voltar e ter que retrabalhar tudo novamente. Na área de VFX as vezes o cliente volta 40 vezes um shot, isso é tenso, porém faz parte da área e nesses casos muitas vezes são os clientes desenvolvendo a ideia durante a produção, isso nos mata, porém o marcado aceita isso e quem realmente coloca a mão na massa que sofre haha...

[@eltrem_th]

@@WandersonItsMe linkedin cadê papai??

[@robertochostakovis]

Para mim isso é mais sobre liderança que desenvolvimento. Seja qual for o nível do desenvolvedor, o lider deve acompanhar para não acontecer exatamente o que foi descrito.

[@raf.rafaelcastro]

Botar para o escritório é ótimo kkkkk. O escritório seria tipo uma espécie de "reforço escolar" para não "repetir de ano". Trabalha de casa quem está entregando bem, mas se fizer m* vai passar uns dias no escritório para aprender e poder "passar de ano".

[@eduardodocarmo6395]

Pela minha experiência, a maioria das tasks que voltaram foram: 1. Task só continha o título e aí precisava puxar nas memórias o que tinha sido falado em grooming/planning 2. Task/Figma com pouca definição 3. Combinei com o backend de enviar X dados, ele concordou mas no meio do caminho mudou para Y dados e não avisou

[@danigui8573]

A 1 é todo dia comigo

[@eduardodocarmo6395]

@@danigui8573É raro, mas acontece sempre 😅

[@drells21]

Resumiu minha vida de trabalho em 3 passos..

[@carolinet4859]

1 é tao rotina q é triste, fora quando vc pede pra mandar anotado e a pessoa diz q gravou a reuniao, so q a reuniao durou varias horas e a galera nao decidiu o q quer.

[@McLovinJoe]

Quem ta começando mesmo, a nível de estagiário, dificilmente vai entregar um task difícil ou média. O negócio é que o estagiário deveria ser acompanhado por alguém e que nunca um Junior ou estagiário deve ta sozinho em um projeto, sempre tem que ter o Sênior pra guiar a galera.

[@OFabianoSilva]

Às vezes o desenvolvedor está em uma empresa onde não se tem feedback, a equipe de trabalho não é muito expressiva e ninguém se comunica direito. Não se trata de simplesmente punir a pessoa.

[@Nilander]

a pessoa já está a sendo punida só de trabalhar num ambiente assim

[@JoaoCarlos-fi4rr]

@@Nilander meua migo, vocês não sabem da missa metade (sim, eu trabalho nessa empresa e sou um dos devs que tavam no meio dessa treta toda)

[@emanuelacoutinho4700]

@@JoaoCarlos-fi4rr Eu queria rir (com respeito), mas ocorre que meu trampo é algo semelhante....

[@OFabianoSilva]

@@emanuelacoutinho4700 e eu que estou querendo entrar na área mas já com receio. Me candidatei a uma vaga em uma agência de marketing da minha região. Eles utilizam PHP com MySQL

[@ellathet]

É interessante, na empresa onde trabalho, não tem testes automatizados, não tem Code Review, e geralmente o dev faz ponto a ponto a task, desde o desenvolvimento até o deploy. A um tempo fui cobrada por demorar em uma task que comparando com as outras nem tava tão mal explicada, de um dev da minha equipe, porém quando fui dizer que havia várias formas de ajudar esse dev, como implementar as coisas que disse acima, a unica solução da empresa, foi falar que o Home Office estava atrapalhando a comunicação kkkk as vezes as empresas só n querem "mais trabalho" implementando processos!

[@rafaelcarvalho139]

Tive minha primeira experiência como dev(estágio) e fui demitido há duas semanas. Eu havia pego projeto em Java, simplesmente toda vez tinha que ter uma reunião para entender melhor a regra de negócio e o detalhe é que o dono, que fazia papel de PO, ainda entendeu errado o que o cliente queria e no dia da entrega, senti a pior sensação da vida por não saber como lidar com a situação. Depois um projeto em React para um projeto para o RH, fui demitido no meio do projeto, mesmo desenvolvendo a maioria do Front-End. Até hoje me pergunto se eu poderia ter feito algo pra que isso fosse diferente. Com base nessa experiência, acho que pode haver muita coisa que não foi dita no tweet sobre esse caso, o que abre margem pra vários contextos.

[@alefsasi]

Vou contar uma situação que aconteceu comigo, no meu trabalho anterior me pediram pra fazer uma tarefa de integração com um sistema que ainda estava sendo desenvolvido, a princípio essa tarefa era pra ser executada em um mês, mas a gestão pediu para entregar anntes por alguns motivos que não lembro mais, acontece que na semana da entrega quando a história já estava desenvolvida faltando pouco mais de 3 dias para entregar uma pessoa que estava na outra equipe que estava desenvolvendo o outro sistema falou que não daria pra entregar, pois o escopo passado para eles era diferente do que estava na minha história, e tive que em 3 dias tentar adequar o que tínhamos feito pro escopo certo, porém por essa falta de tempo obviamente não deu certo e a versão que subimos nesses 3dias estava cheia de bugs. Mas o pior é o que estava por vir, o gestor do projeto na época colocou toda a culpa nos devs (mesmo que ele tivesse acompanhado através das dailys e sala de guerra nossas dificuldades) e ate teve uma reunião onde o cara nos humilhou e falou coisas como "não ser aceitável um dev com mais de um ano de projeto ter entrega daquela forma", depois disso nos tiraram da tarefa e colocaram pra outro time refazer com um tempo bem maior. Mas essa situação especificamente me deixou muito mal e puto, a ponto de pedir demissão.

[@pedroluiz2741]

Fala a empresa pra gente passar longe

[@alexandresantos7966]

Refinamento de sprint serve exatamente para isso. E é obrigação do desenvolvedor ficar atento e tirar todas as dúvidas, observando os critérios de Definition of Ready (DoR) definidos pelo time. Podem ocorrer situações onde mesmo uma história estando como "Ready", surjam dúvidas não cogitadas no momento do refinamento, nestes casos é melhor procurar as pessoas envolvidas: Product Owner, Arquiteto, ou membro de outra equipe e solicitar um momento para tirar uma dúvida. Porém, se as definições estão claras, o dev não comunica a dúvida de entendimento. Talvez seja o velho caso do desenvolvedor que pensa que sua função é de somente colocar tasks em "done". E não entender que o trabalho de desenvolvimento de software envolve muita comunicação, na maioria das vezes o trabalho de comunicação é muito maior que o de codificação de fato.

[@Arthur4lves]

Há um contraponto sobre a palavra corte, porque para o dev pessoalmente e geralmente, é considerado uma punição pra ele. Inclusive com um pouco de rolagem no Linkedin vc vai ver vários, principalmente de layoff falando que foram "punidos" com a demissão. Para o contratante se chama corte, e muitas vezes para o dev se chama punição. Não significa muito, mas corte seria mais no ponto de vista do contratante.

[@Ddiidev]

Vou ser polêmico, eu acho que o problema é a equipe! Equipe engessada e que todo dia parece uma segunda-feira. Eu trabalhei em uma equipe em que um cara lá teve 63 retornos(certo é demais), mas a questão é que os QA não tinha o menor problema com isso, testavam e brincavam com os dev, a gente brincava com eles também dizendo que só tinha bug porque eles achavam.... 😅 Enfim, resumo... Mesmo com 63 retornos, esse dito cujo é muuuito produtivo, e entregava muita task em produção por dia, nossa produtividade sempre foi e é alta. Obs: Não era recorrente, a recorrência era demandas pouco documentada. Esse dev ta lá até hoje e ninguém nem menciona isso mais no dia-a-dia. Punição: Vai reescrever o backend em python.

[@Arthur4lves]

Que tipo de punição é esta? Manda pra cá. Punição positiva? Que mundo estranho kkkk.

[@Ddiidev]

@@Arthur4lvesIsso ai foi só uma piada ácida 'kkkkk

[@CarvalhoTi_]

Trabalho como desenvolvedor a 8 anos e pouquíssimas vezes a descrição da tarefa, quando existia, era bem escrita. Entretanto o processo não é uma receita de bolo, o que funcionar para um modelo de empresa talvez não funcione para outro devido nível de maturidade e orçamento que não permitam que o processo seja como o 'sonhado' por parte dos desenvolvedores. Por isso é importante seguir e ter definidos os ritos durante o processo, porém como comentei depende de alguns fatores que ficam externos ao querer e ao achar culpados, se a empresa não dispõem de um orçamento que permita ter pessoas dedicadas a cuidarem das etapas e dos ritos, então o processo tem que se adaptar a realidade da empresa e não a empresa se adaptar ao processo, e de tempos em tempos conforme for necessário o processo deve sofrer melhorias e ir se adaptando. Como o Lucas comentou a pessoa pode estar em um momento ruim, e é um ponto de atenção para se aproximar e tentar descobrir os motivos. Eu não sou a favor de demissões, sou a favor de ajudar e desenvolver as pessoas, salvo em casos muito extremos. Mas se a pessoa está na tua empresa é porque ela passou por um processo e ela tem o perfil da empresa.

[@_jbabo]

São tantas variáveis e tão poucas informações que minha divagação ficaria vazia. Então deixo o comentário só pelo engajamento

[@ShuHikari]

Meu tweet! Valew pela resposta, acho que, tirando muita gente que tava lá de troll ou de hate, os que deram boas respostas contribuíram demais pra uma resolução da hora num fluxo que é tão divergente em várias empresas.

[@BrunoJorsp]

O dev da minha empresa aqui que nao entregava nada certo tomava retorno em tudo e n conseguia terminar uma task sozinho foi recompensado com o selo open to work dourado no linkedin

Nunca rolou comigo, mas já ajudei no processo adequado nesse caso: PIP. Performance improvement program. Vc cria um set de objetivos pro engenheiro atingir de acordo com o que se espera dele, e da um prazo pra isso, enquanto um engenheiro mais sênior acompanha. As vezes n tem jeito mesmo, a pessoa tá passando por algo difícil na família ou algo do tipo, ou ela simplesmente não foi feita pra esse trampo, e no fim a demissão acaba sendo super esperada.

[@viniciusgoneli7859]

O Lucas deve ser extremamente feliz por ser desenvolvedor Android e não iOS. É um inferno lidar com a Apple kkkkk

[@JonatanEdOrtiz]

A Apple é muito chata pra aceitar alterações mesmo, tá loco

[@mso2000]

Sério que isso é que faz ser dev Android melhor, rs? Fun fact: a app Android daqui da empresa é a única que é reprovada pela Google na maioria das releases (e pela mesma razão sempre). Acho que só vi a app iOS ser rejeitada uma vez.

[@gravity2387]

@@mso2000 quais são os aplicativos que a empresa que vc trabalha faz ?

[@GustavoAlves-lv5wh]

essa chatice da Apple não se compara ao desprazer que é desenvolver para android

[@viniciusgoneli7859]

@@mso2000 Então, não estou dizendo que a chatice da Apple justifica abandonar o desenvolvimento iOS, mas para mim isso dá uma desanimada. Não sou dev mobile nativo, uso react native, e no Mac, emular iOS é bem melhor que emular Android. No entanto, as guidelines da loja da Apple são muito piores do que a da Google; algumas parecem até picuinha, sério. Além também de demorar mais para revisar o app. Mas cada um tem sua própria experiência com a Apple. Pra mim, no geral, a Apple atrasa muito o deploy do aplicativo.

[@donyjunior]

Programação ainda é Hobby pra mim, mas sou administrador (o que não significa nada). Posso dizer que a palavra "punição" não se aplica em liderança. Um líder de equipe tem somente duas opções que são executadas necessariamente nesta ordem - Desenvolver e Demitir. Demitir é sempre a última opção. Neste caso, significa que a seleção falhou e o gestor não teve êxito em desenvolver seu subordinado. Uma taxa de demissão discrepante em uma gerência é sinal típico de que a liderança está falhando em algum ponto.

[@Fockus]

Só trabalhei como programador em uma empresa quando estive na Marinha, no serviço obrigatório enquanto eu cursava a faculdade acabei indo parar no setor de TI da base, a punição que eu recebia era ter que ir trabalhar em outro setor fazendo faxina, ou organizando a "lixeira de hardware" que era uma sala lotada de hardware queimado que estava na fila pra ser aprovado o descarte, eu recebia punições porque era só eu trabalhando no software, e eu não sabia quase nada na época, não existia uma equipe pra me auxiliar além dos superiores que mexiam com os servidores, mas não consigo imaginar isso sendo feito numa empresa civil kkkkk BTW adoraria ter um emprego na área, mas tô na luta

[@edmilson1178]

Lucas, sugestão, fala dessas diferenças entre Junior, Pleno e Sênior e dos débitos técnicos que são gerados nos sistemas quando não se coloca alguém com a qualificação adequada desde o inicio de um Projeto Novo!....

[@manghinoni]

sou senior e tenho muita experiencia, 90% das rejeições sao porque tem malandragem antes do programador, o cliente para nao pagar descreve algo simples e depois fica inventando que falta isso ou aquilo, ou o PO para burlar descreve como bug algo que é nova implementação ou vc faz certinho o que esta descrito lá e na esteira : ah, precisa tambem disso ou aquilo 🙂

[@assiszang6191]

Aqui a gente faz o que chamamos de DevBox, onde o dev faz todo o fluxo da alteração localmente junto com o QA, tem dado muito certo

[@lucasmefernandes]

Ansioso para vivenciar essas situações pessoalmente HAHAHAHAH. Lucas, você poderia fazer um vídeo falando sobre esse glossário de termos utilizados por desenvolvedores em empresas, como TASK, CODEREVIEW e outros. Seria um vídeo semelhante àquele que você fez sobre não gostar de CALLBACKS kkk.

[@samueldecarvalho240]

Realmente, são raras as vezes que pego uma tarefa bem escrita e com todos os detalhes necessários pra desenvolver, porém, temos Clientes, PMs, POs e Devs mais experientes pra ajudar nisso. Se tá com dúvida, vai lá e pergunta! Sempre terá alguém pra te ajudar. Uma coisa que eu sempre falo pro pessoal, e vai de conselho pra quem tá entrando agora na área: "Nunca tente desenvolver algo que você não entendeu" Se não entendeu 100% do que deve ser feito, vai atrás de sanar as suas dúvidas antes de digitar qualquer código. Não dá pra desenvolver sem saber o que a sua solução soluciona, e mesmo se tentar, só vai gerar dor de cabeça pra você e para seus colegas.

[@waltwhite8126]

Isso me fede a dev júnior com problema de comunicação/ansiedade social. Eu era assim quando comecei e aprendi rapidinho a mudar isso com uns feedbacks muito importantes.

[@samueldecarvalho240]

Com certeza. Muita gente também é assim. Eu também era... Mas eu não recebi esse feedback cedo e apanhei muito antes de entendê-lo, por isso o meu comentário. A ideia é deixar claro que precisamos praticar essa "coragem" o mais cedo possível na carreira dev, pois só trás benefícios: Menos pressão psicológica, maior autonomia, mais produtividade, menos sindrome do impostor, mais contentamento, felicidade, etc. Tem que se soltar.

[@waltwhite8126]

@@samueldecarvalho240 acho que um dos maiores inimigos pra pedir ajuda é a síndrome do impostor. Eu tinha muito isso e ficava achando que o que eu iria pedir é algo que eu já deveria saber.

[@codex4599]

Minha punição foi fazer o front end kkkkk. Cara na empresa aonde trabalho se o dev tá tendo dificuldade ele pede ajuda isso vem muito da cultura da empresa

[@michelledigdecarvalhoperei144]

Pede pra ele codar um programa que printe "SOU PROGRAMADOR E VACILÃO" em assembly, aqui na firma sempre funcionou

[@Santos-fr95gt]

Eu nem faço se não entender kkkk enquanto as expectativas e a definição não estiverem alinhadas e clara, nem na sprint deve entrar kkk

[@RobsonNascimento95]

"A vida tem punição em todos os níveis". Essa parte foi sintomática sobre a personalidade de quem abriu a discussão. Ele tá querendo tomar pra si o papel de "Punisher", talvez por ter glamourizado em sua consciência essa função que a vida já trata de forma orgânica. Deveria focar a energia em outras coisas, como os colegas aqui falaram, em prol do trabalhador, da empresa e até dele mesmo.

[@diegodiga1]

A cada 5 task que entrego pelo menos 3 volta kkkkj, mas sempre com correções pequenas, sempre foco em olhar o macro e acabo pecando no micro, coisa que estou fazendo um esforço do caramba para me corrigir.

[@joaquimjane]

Simples e varios avisos antes da entrega resolve isto, a todo problema que impeça a evolução evitará um clima de punição, e deve motivar a "empatia técnica" da equipe...

[@rodrigodanieldonha]

Sou programador mas não trabalho em empresa de software, trabalho remotamente para 2 empresas e sou o único programador do código, como não tive experiência em trabalhar em equipe não tinha a noção que isso acontecia, do supervisor passar uma tarefa com um grande número de requisitos e o programador de equipe ter dificuldade de entender e entregar, pois imaginava que a equipe auxiliava no entendimento e na engenharia do código antes de programarem. Agora vejo que tenho as mesmas dificuldades trabalhando sozinho e de quem trabalha em equipe, pareceu que é cada um por si. Eu já tive problemas pessoais por conta de requisições muito complexas, pois me atrapalhava pensar, dormir, fazer o básico, só melhorei quando finalizei porquê eu não conseguia parar de pensar em soluções de lógica para aqueles requisitos complexos, é complicado pensar em uma punição, pois pra mim a maior punição já é essa, ficar o tempo todo ligado ao trabalho e a tarefa.

[@douglasrcm]

Muito bom!

[@alessandrobecker1]

Além de tudo que foi dito, existe uma imensa parcela de profissionais (a maioria altamente inteligente e capaz) que tem algum tipo de condição neuropsicológica que pode exigir abordagens inclusivas e um pouco de empatia. Por exemplo, pessoas com TEA, TDAH ou Dislexia, ou pessoas com Superdotação (acreditem ou não, são pessoas altamente sensoriais e podem ter dificuldades com soft skills ou msm atenção focada) e até mesmo pessoas com TOC ou Ansiedade Generalizada. Claro que é responsabilidade do portador que ele/ela busque ajuda e que cuide de suas próprias dificuldades com terapias e/ou medicações. Mas de qualquer forma, essas condições estão cada vez mais presentes e a compreensão das diferenças, a inclusão e o acompanhamento para que profissionais de qualidade com dificuldades de adaptação, possam se sentir integrados e respeitados, é bastante necessária. E o meu discurso aqui se baseia nisso pois fui demitido hoje. E eu tenho TDAH e Superdotação. Sou Arquiteto (de formação) mas trabalho como Designer. E exceto a Arquitetura, sou totalmente autodidata: sou ux/ui designer, sou front-end dev, sou progmado, modelador 3D, faço games além de tocar vários instrumentos, cantar, compôr. Nos ultimos dois anos fiz um monte de curso online (pq to sem tempo com minha recem nascida filha e nao da pra aprender 100% sozinho com o tempo que tenho) e possuo uma facilidade absurda de resolver problemas complexos de forma criativa e lógica. Isso faz com que eu entre em qlqr empresa e perceba em poucos dias todas as falhas pertinentes à minha área. E aí eu simplesmente travo. Pq eu, como sempre fui muito autônomo, tenho uma forma peculiar de trabalhar: sozinho e altamente organizado. Ou seja, eu já perdi inumeras oportunidades por entrar em empresas que estavam tão perdidas em seus processos que eu não conseguia entendê-los. Hoje, mais uma vez. Enfim, eis uma mistura de desabafo com pedido de ajuda. Que as pessoas e empresas de áreas da tecnologia consigam ser mais empáticas e que enxerguem e acolham o humano (às vsz altamente capaz de solucionar os TEUS problemas) em face à posição de uma mera engrenagem na linha de produção. Seguimos em frente. Forte abraço.

[@henriquesdj0]

Já tive colega que o gerente teve que chamar a atenção diversas vezes. Quando não deu mais, passaram pra outro setor. E depois pra outro. E depois pra outro. Daí ele foi demitido porque não dava mais. Ele subtraía valor em vez de somar, no sentido de que a gente sempre tinha que corrigir as cagadas que ele fazia e ainda fazer corretamente a tarefa que ele deveria ter feito. Pior que ele saiu da empresa com um baita orgulho de ter sido expulso de todos os setores. Bem moleque mesmo.

[@rnt802]

Já presenciei casos semelhantes de dev júnior cometendo vários erros seguidos na entrega e o motivo era sempre o mesmo, o dev não conhecia muito bem a lógica de negócio, as histórias de usuários eram sempre rasas faltando informações importantes. Por outro lado, ao invés do dev esclarecer suas dúvidas, acabava presumindo a funcionalidade e entregando errado. Acho que antes de considerar punir (e a única punição que deveria ser feita seria feedback negativo) tem que avaliar muito bem onde está o problema e não apontar culpados.

[@painnagato7617]

feedback negativo é a melhor forma de perder uma equipe, quando o foco está no problema você não vê solução

[@GabrielSampaio01882]

Eu acredito que a falta de documentação é o que atrapalha, sem documentação fica sem modelo e obviamente o programador fica sem rumo

[@wesleyhallan8772]

Uma possível punição: escrever em binário toda a letra de starway to heaven, usando apenas um dicionário fisico (tipo aurélio) para consulta. Não sei se vai ajudar o dev a melhorar, mas com certeza deve ser chato pra caramba ficar traduzindo letra a letra...

[@jeanalmeida3340]

Pode existir diferentes situações: se é alguém que já está integrado ao time e a cultura da empresa, bom partir para uma conversa direta no primeiro atraso, time é time, melhor recuperar o cara do que trocar. Se é um DEV novo, bom conversar já no primeiro atraso e entender o motivo, colocar alguém mais sênior do lado para acompanhar e mentoriar. Cada empresa constrói sua cultura, mas algo é fato: quando o cara está de picuinha, melhor detectar no início e disponibilizar ele para sua caminhada.

[@jonathanigorpereira]

já, tive que fazer planilha de micro-gerenciamento e algumas outras coisas

[@BrunoLopese1]

Tá faltando engenharia de software nesses processos

[@gabrieltorino2851]

"Coloca lá no cantinho do escritório e reflete sobre essa tarefa que tu entregou" foi foda KKKKKKK

[@roberotto]

O cara descobriu um problema no processo da empresa, onde o importante é enviar algo para o QA, sem importar-se com o resultado final, visto que não há nada prevendo "penalizações" ou tratativas mais altas em caso de insucessos seguidos, ganhando tempo para completar a tarefa. Também pode ser um caso de Quieting quitting, ou, pior ainda, quieting firing.

[@MarcelinoSandroni]

O mais importante sempre eh ter refinado a tarefa ja especificada as necessidades e criterios de aceite. Eh comum pegarmos tarefas que nao sao refinadas por parte do negocio ou funcional, e como devs precisamos correr atras disso. Eu ja boto sempre qq coisa q falta informacao como BLOCKED e sempre alerto qm eh o responsavel por fazer isto, apenas atuo fazendo o trabalho de outra pessoa se realmente isto for impeditivo para continuar o projeto e outra pessoa nao atendeu a demanda, mas sempre deixando bem claro para a empresa. O mais importante eh sempre a comunicacao, e sempre informar o progresso e possiveis problemas/bloqueios/falta de informacoes. Isso esta mais para o desenvolvimento agil do que conhecimento de hard skills.

[@leonidev]

eu percebia que os devs tinham bastante dificuldade de fazer as coisas quando as tasks eram escritas pela metade. agora eu comecei a escrever com mais detalhes e dificilmente o pessoal me chama para tirar dúvidas genéricas, todas elas são bem pontuais. destalhando o que o pessoal tem que fazer economizou o meu tempo, e o tempo deles. hehe

[@MrAlexDuzi]

Eu acho que depende muito de empresa pra empresa. Normalmente se a pessoa não está performando bem, mesmo após vários feedbacks, o caminho infelizmente é a demissão. Tem empresas que tem avaliações anuais e dependendo da sua performance se vc não está indo bem, te colocam como plano de ação, te explicam os pontos que vc tem que melhorar e podem cortar o seu bonus de final de ano (caso a empresa pague ppr, plr).

[@eduardoamaral8085]

Já enfrentei muito problema com mudança de discurso, dentro da empresa, ada vez que mudava o gestor mudava o discurso sobre oq fzr e como fzr... e sempre que era contestado, ou feito da forma antiga, era punido com ameaças de advertência por escrito, e que após a terceira seria justa causa.

[@matheusrosa1367]

Meu ritual de almoço é ver os vídeos do samuca agora

[@olivmath]

Esse tipo de video é bem ácido pra quem já perdeu o trampo por vacilo, traga mais mano, a gente tem que tirar a casquinha do machucado pra poder sarar mesmo.

[@aquijazumcanal9863]

Putz. comecei uma dessas feature mal diagramadas antes de tirar férias. Voltei das feiras e ela estava garrada há 3 sprints, mudaram tudo na implementação. Ficou mais 1 sprint na minha responsabilidade e por outros motivos o projeto foi de base. Um dos meus colegas já sabia que podia dar errado essa feature e assim que ela entrou na sprint falou que estava sondando outras empresas. Eu achei que ía ser mandando embora, pois todos foram realocados em outros projetos . Nem meus superiores sabiam o que ia acontecer, tudo por quê a gestão nao deixava a gente trabalhar e ficava deslocando pessoa para demandas prioritárias. QUando tudo é prioritário, nada é prioritário e nada é concluído!

[@facsrandom]

Eu recebi punição, uma demissão! kkkkkkkkk Na época não estava bem comigo mesmo, e eu tinha dois empregos e fazia curso técnico. Trabalhava a noite no setor de hotelaria, gerenciando setores de TI, recepção e financeiro, e trabalhava de dia como dev. até meio dia, ou 2 da tarde quando sobrecarregava a entrega (era stack house). As 4 já ia pra academia pois queria voltar a competir jiujitsu e tinha desistido por causa de depressão...tive recaída, abandonei tudo, não abandonei setor hoteleiro, mas reduzir de cargo, e virei um mero recepcionista, nada contra kkk. 2 meses dps o negócio faliu. E eu tive minha liberdade, pra curtir minha depre em casa kkkkkkk. Alegria!

[@1est1]

Na minha empresa tem code review, provavelmente alguém teria comentado os erros no review, se o próximo commit da task continuasse errado provavelmente já teria uma reuniao entre o dono da task e o code reviewer tentando entender o que ele fez e por que ele nao corrigiu como foi indicado no review e se o reviewer entendesse que a pessoa nao compreendeu ainda provavelmente o ticket seria remanejado e seria passado algum ticket mais fácil para ele nesse sprint. Se acontecesse algo parecido alguma outra vez provavelmente teria uma segunda reuniao com scrum master para entender se ta tendo algum problema pessoal ou ele só não ta conseguindo perfomar mesmo para possivelmente remanejar ele para outra equipe/contexto ou até alocar ele numas férias adiantada, ou fornecer alguns cursos de formacao vinculado algum projeto interno da empresa que nao tivesse essa demanda tao grande cliente. Um caso que aconteceu parecido na minha empresa foi que a pessoa tinha perdido o pai para covid, no fim adiantaram as ferias dele e deram suporte por um tempo eu acredito mas no fim ele acabou nao voltando para empresa depois.

[@Guilherme22914]

Punição é uma palavra muito ruim mesmo, parece que vai colocar o dev de castigo no cantinho do escritório kkkkkkk

[@danielfonsecadelira9430]

Não costumo ter cliente externo, parece o mesmo caso da "task" em questão. Então quando acho que a coisa esta muito enrolada, chamo a pessoa para fazer o trampo junto... compartilho a tela (quando precisa) e vou fazendo e perguntando o que precisa fazer, vamos batendo um papo enquanto eu faço, na tranquilidade... No fim a gente fica feliz, e quando perguntam para a gente se foi feito, a gente sorri e diz que sim. No fim estou pouco me lixando para o que escreveram no ticket...

[@alexdominguess]

Quem é do time sabe quem é o dev bom, o ruim, o que é bom mas enrola.... Se é um problema de processo ou de dev ruim, o time sabe. Primeiro aproach aqui seria sentar com o dev e pedir uma explicação, não como uma bronca, mas tentar entender e achar uma forma que funcione pra ele melhorar a entrega. Vai ver ele esta sendo pressionado pra entregar outros projetos mais importantes.... vai saber

[@Lucianovianasouza]

Não entreguei um projeto sem nenhum planejamento e o prazo era "uma semana", isso foi na minha segunda semana de empresa, e me falaram que deveria ter falado que não dava tempo e me ameaçaram de me tirar do projeto, resultado sai dessa empresa antes de completar a experiência.

[@user-jo3pp5pf3j]

Lucas, to precisando de uma luz! Me dê um rápido conselho por favor, entenda meu caso: Comecei na programação a um pouco menos de 1 ano, por uma necessidade bem específica da empresa que trabalho (uma clínica de saúde) para lidar com processamento de dados, aprendi python pra resolver a demanda, de fato resolvi e fui me aprofundando na área... acabei aprendendo laravel (php) e django, desenvolvi um sistema muito louco sem ter conhecimento técnico na área, hoje esse sistema é fundamental na empresa, ele gera os documentos comercializados pela empresa, processa atendimentos médicos, envia dados no formato xml pro governo e faz mais uma porrada de coisa. Meu problema é que já cresceu de uma forma tão absurda que eu não consigo gerenciar tudo direito e aqui na empresa nunca teve um setor de tecnologia nem nada do tipo, sou apenas eu como programador solo e os donos/administradores são muito resistentes quanto a contratar novas pessoas (com experiência) que PRECISAM ser melhor do que que, afinal como já disse, sou um iniciante curioso que foi tentando e fez acontecer... Hoje tenho outro projeto paralelo à empresa que também já começou a rodar um dinheiro violento, ainda não há a necessidade (pelo menos ao meu ver) de botar pessoas experientes, mas queria saber em que momento eu devo contratar alguém, dito que NUNCA TRABALHEI COM TECNOLOGIA e faz pouco menos de 3 meses que descobri canais que falam sobre isso na internet e me assusta o tamanho da complexidade das coisas que você e seus colegas youtubers acabam passando (no sentido de precisar ter muito conhecimento em cada pequeno pedaço da aplicação). O que fazer? Eu sequer faço idéia de como deveria ser um processo ideal de desenvolvimento, simplesmente vou fazendo, testando e vendo se o cliente gosta (no caso do meu projeto paralelo) ou se os patrões aprovam a ideia (no caso da empresa). Eu penso, desenvolvo, testo, valido os testes, implemento a produção, ensino as pessoas a usarem, eu monitoro o uso e assim por diante...

[@Bruno0907]

95% das tarefas que são abertas aqui na empresa são mal escritas. Elas só andam e são entregues pq a equipe é calejada e corre atrás pra esclarecer as solicitações.

[@Baeyk]

O problema das lideranças da área de tecnologia, é pensar na punição do próximo e não em entender em quais pontos a própria liderança falhou! A final ser lider é isso, certo? Um desenvolvedor ruim não vai falir um projeto, uma liderança ruim com certeza vai falir um projeto! Outro ponto, qual o nivel de pressão dentro da empresa? Quanto mais pressão de entrega mais lixo é o codigo.

[@fred5663]

Penso que esse termo "punição" é meio inadequado. Por exemplo, a questão de entrega pode ser relativizada de diversas formas, como por exemplo, pode ser que o programador realmente não tenha o conhecimento para tal demanda, ou pode ser que a entrega seja demasiada complexa devido a questões diversas de desenvolvimento, ou por prazos que não condizem com a demanda. Penso que nenhum programador ou pessoa em geral deve ser punida por questões de rendimento no trabalho.

[@j.j.9538]

Depende também. Talvez o desenvolvedor esteja recusando a tarefa por que ele viu algum problema. Às vezes, as tarefas estão mal especificadas ou o tempo de desenvolvimento é irrealista. Muitos gerentes têm favoritos e jogam as melhores tarefas para alguns desenvolvedores e entregam as piores para outros. Tem sempre que ver o caso.

[@artu_almeida]

cara punir? em 4 anos de mercado nunca ouvi essa palavra, punir dev, e olha q fiz pós em engenharia de software com foco em métodos ágeis

[@alessandrohudson5221]

Creio que se chegou ao ponto de errar a task 3x então não é um problema apenas do dev. Houve uma boa reunião discutindo sobre a task? Houve um devido refinamento de negócio/ refinamento técnico? Quem revisou o código revisou direito? E o teste? Validação do PO? (tudo que você abordou no vídeo Lucas)...meio estranho este questionamento que foi feito, estão é querendo fritar o mano kkkk

[@BlackCode2777]

kkkkkkkkkkkkkk muito boa!

[@chuck8177]

esse título é uma indireta pra mim????

[@caffegoiano]

bora meu fi, cadê a task que era pra entregar mês passado?

[@DAllanR]

Sobre tirar a tarefa do Dev, eu já vi muito foi "quer tirar a tarefa" só, tirar mesmo só quando virou pressão total de fora, primeiro porque outro dev em si não ia pegar a tarefa rápido, fora o fato de que não são muitas pessoas que vão lá falam na cara do Dev que vai tirar a tarefa da mão dele. Outro ponto é o fato de o gestor fazer isso não garante que a tarefa será feita..

[@LeonardoJaquesDev]

Meus 20 centavos, não deveria ter PR sem testes. Tem muito Dev que sacaneia na aprovação do PR, principalmente se está rolando layoff na empresa. Já vi pr ser negado porque o cara era brasileiro, tech lead teve que intervir. Mulher ter o pr negado por ser mulher, tech lead teve que intervir. E a pessoa é terceirizada, o tech lead teve que intervir. O problema que algumas empresas deixam o pr virar um gargalo, justamente aquelas que não adotam o teste como padrão.

[@ThiagoOliveira-ex3vw]

Penso que oferecer treinamento, buscar compreender, resolver, etc, é melhor e ideal. Demissão pode ser algo cruel, principalmente se não houver conversa, e realmente pode repingar em toda a equipe e gerar fragilidades na liderança. Tudo se torna muito desagradável quando os funcionários começam a se sentir dispensáveis, quando passam a pensar que podem acordar desempregados. Todo mundo sabe que não existe estabilidade no emprego, mas não se costuma pensar nisso diariamente, porém há situações capazes de desencadear essa insegurança e ansiedade. Enfim... Demissão tem de ser sempre o último recurso, exceto em caso extremos.

[@jorgelaba8783]

Em questão de qualidade de código quando se trata de dev junior a melhor alternativa seria treinamento e pair programming. Quando se trata de feature com bugs , eu sinceramente olho os casos de teste criados pelo dev e procuro expandir o cenário para que ele conclua. Dev junior vai errar, o que você espera do mesmo é uma evolução ao longo do tempo, já para dev senior's problemas repetitivos são realmente um problema, se for constante a única alternativa seria a demissão, após uma boa conversa.

[@devdenegociosbr]

Perder prazos é muito complicado, embora seja frequente no nosso mercado. O que eu faço é deixar que o programador defina o prazo. Aqui na minha empresa funciona bem.

[@rfcosta85]

São raros casos de fato, o triste é quando o designer vive mudando o layout enquanto vc está desenvolvendo durante a Sprint e você só descobre quando você vai fazer o review final, TENSO!

[@rodrigoeggea]

outra questão: como entregou se não passou pelos testes? quem faz os testes não deve ser o mesmo que programa, não adianta jogar tudo pro dev fazer "quero um botão bonito que aperta e funciona". Essa pergunta parece ser de um péssimo gerente que não sabe programar só sabe cobrar

[@felipek.deboni8157]

Se tiver teste né kkk

[@ViniciusOliveira-rx6fx]

a minha "punição" foi ser demitido mesmo, demorei 1 mês pra fazer uma card(taks sla) e logo dps fui demitido. era um estagiário, nunca tinha mexido no backend, tive que aprender tudo na marra.... e pela demora, fui demitido.

[@McLovinJoe]

Isso é foda, aconteceu comigo também, só que eu me demitir antes kkkkk E isso é erro da empresa! Estagiário e Junior não pode ta sozinho no projeto.

[@McLovinJoe]

@@hiagocavalcanti fullstack. Você não pode começar a carreira se limitando com front ou back. Qualquer curso de TI te ensina a ser fullstack, é o que a maioria das empresas esperam.

[@McLovinJoe]

@@hiagocavalcanti Outra coisa, muito vendedor de curso sai prometendo milagres da área de TI. Por causa da Bolha Dev, a bolha estorou e se você olhar vagas no Linkedln tem vagas que 1.000 nego se candidatando. Inflacionou o mercado pra Dev Junior e Estagiário.

[@egsantos10]

E outra pra mim tem que escrever sempre em algum lugar nem que for em bloco de notas, mas precisa escrever pra facilitar o processo. Coisa apenas ditas em reunião normalmente não da certo.

[@joeythai1000]

Quais livros vocês recomendam para melhorar a qualidade do código ? Se possível livros baseados em PHP

[@afsdab]

Trabalhei em uma empresa que ocorreu um acordo do time que era o que definia uma história/demanda pronta pra ser desenvolvida, se o time aceitava ela sem esses critérios o time assumia o risco, exceto se fosse um TOP/DOWN que aí o time deixava claro que estava faltando e mesmo assim decisões superiores forçaram ela entrar. Dessa forma muita coisa foi evitada.

[@molestando]

Na minha experiência, o que MAIS tem, é lider ou gestor que não tem experiência nem conhecimento para atuar no cargo (e nem liga para melhorar), ou empresa que nem estrutura tem (alta rotatividade de talentos, etc, etc). Entao, se você emprega uma pessoa, verificando que o que diz o CV dela é verdade (por meio de um teste tecnico, por exemplo) e você dá uma tarefa que se enquadra no que ela sabe, na grande maioria dos casos o problema na entrega vai ser tarefa com descrição ruim, prazo de estimativa ruim ou falta de comunicação com o time (caso tenha time, porque muitas vezes nem isso), e ao invés de pensar em punir o cara, pensa... sera que coloquei para ele uma tarefa que não está dentro dos conhecimentos que hoje tem? E se sim, sera que a gente consegue treinar ele no que esta precisando? Porque aí tem outro problema comum nas empresas, falam de crescimento de carreira, mas no geral não acontece, e às vezes nem cara sênior disponível você tem para fazer uma consulta, ou a empresa tem, mas o cara não da a mínima para ninguém (desculpa dele: "falta de tempo"). Então assim, essa trend sem contexto fica complicado para saber qual é o problema de verdade. E para que não fique como que passo pano para o dev da questão, às vezes tem SIM pessoas que não trabalham focados, que perdem tempo fazendo outras coisas (pessoas que não conseguem ser profissionais com modalidade home office) e na final das contas nenhum prazo para elas é suficiente ou a qualidade das entregas é muito ruim. Mas cada casso é um casso.

[@leonardocamargo5412]

Visto que ele disse que o DEV entregava a tarefa concluída de forma correta, porém tinha problema em outra parte. Isto nos leva a entender que o DEV é bom, porque ele resolveu o problema, no entanto, esta questão de dar problema em outra parte, é outra questão, só que é muito comum de acontecer. Mas, aí voltaram a Task para o DEV resolver este novo problema, isto é errado precisa ter revisão do código, alguém mais especializado revisando, e conversando com o DEV, pra entender o que houve, antes de voltar (criar uma nova task) a TASK para o DEV resolver. Pode ser problema na arquitetura do sistema, no frontend, ou algum problema que não foi visto antes, etc. Por exemplo, muitas vezes o DEV assume uma tarefa, mas esta tarefa impacta outras partes do projeto, devido a problemas na arquitetura, estrutura, codificação, etc. Aí o DEV não fala nada e tenta resolver estes problemas sem está comunicando com alguém. Esta é uma falha de comunicação do DEV que traz problemas para ele, mas ele não é o causador do problema nesta situação. Isto já denuncia que esta empresa não tem um programador qualificado para estar revisando e avaliando os processos do projeto, e arquitetura, estar se comunicando com os Devs, etc. E além disso, o dono está querendo punir o DEV, que parece que é o único que está responsável pelo código e implementações.

[@wiilamaral]

Isso é bem relativo, nesse caso está me parecendo que é "cada um por si", quando na verdade o time todo deveria ser responsável pela qualidade do que é entregue, se tem um DEV júnior que está com dificuldades pra entregar a terefa, ele deveria ser instruído e ser acompanhado de perto, onde estão os Sêniors e Especialistas do time nesse momento? A tarefa voltar várias vezes, pode indicar que existe uma falha no processo, o ideal é o time se reunir e procurar entender o que está acontecendo.

[@danieldesbesel]

A maior punição seria dar um aumento, o dev nem vai entender o pq, mas com medo do motivo vai trabalhar melhor.

[@egsantos10]

Entregar qualquer tarefa sem testar, pra mim não existe isto, fica completamente inadequado. Agora se o Dev não esta conseguindo evoluir ele mesmo deve levantar a mão e pedir ajuda, tem tarefas que são muito mais complexas que as outras.

[@edu_amr]

Lucas eu tenho uma duvida em relação ao seu mac, ele fica o dia todo conectado na beteria carregando? ele não vicia? Estou querendo pegar um pois meus notebooks ficam viciados pois utilizo com monitor ultrawide.

[@Leonardo-uh3vs]

Sou sênior, trabalho com tecnologia há 3 anos, e nunca trabalhei em nenhum lugar que de fato tivesse "code review".

[@linhasdiagonais6053]

Onde trabalho, não tem punição . Mas temos métricas de qualidade . Se uma tarefa retorna por causa de bug , perde pontos . E a quantidade de pontos depende do número de tarefas . Então há um incentivo a quebrar uma tarefa em várias e ir entregando sem bugs e com qualidade. Code Review é obrigatório e sempre temos um teste do app como todo . Antes de submeter, testa se não quebrou a o código . No final as métricas de qualidade servem para definir bonificações salariais .

[@GabrielGothmate]

O pior tipo de líder é o que procura de quem é a culpa, no lugar de procurar a solução. Esse tipo é melhor chamar de chefe, porque é o cara que leva a empresa pra baixo junto com ele. Se for o caso desse cara, é até melhor pro dev ser desligado, porque ao que dá a entender ele é do tipo que vai perseguir o cara daí pra frente, até arrumar um motivo pra desligar o dev.

[@Mike-Zz]

Recebi. Os caras nao tinham senior na empresa, me passavam a task com explicação porca e sem descrição no painel de tasks (Azure DevOps). Obviamente que algumas entregas eu entreguei "errado", e isso gerava um certo atraso. PS: eu era junior na epoca. A puniçao: demitido 🙃. A propósito, teu som é foda

[@anisbertoreis6438]

Ter a entrega rejeitada 3x já é uma punição kkkkk Mas é provavel que o entendimento não foi correto!

[@nayronmoura5889]

Na empresa que trabalho, temos um timebox de 30min... se eu não conseguir um direcionamento em alguma task eu passo ela para frente e pego outra, as vezes pegamos uma parte do sistema que por algum motivo ficamos travados... não significa que o cara é ruim, as vezes acontece mesmo e é a vida. Melhor passar essa task para frente e pegar outra do que ficar insistindo em algo que claramente não está dando resultados

[@emersonbarros6815]

Os que não entregam não são punidos. Agora que entrega com eficiência é punido sem dó, se você termina tudo rapidamente antes do prazos só vão te jogar mais coisa até ficar sobrecarregado e entregar no prazo exato, e não antes do fim do mesmo

[@egsantos10]

No meu ver não deve ter punição e sim melhoria, se alguém seja quem for precisa de ajuda precisa de desenvolver de alguma forma temos que ajudar, se ninguém ajudar é porque o time não é bom e não é unido......

[@gleitonfranco1260]

Requisito é um documento, não deveria ter coisas "nas entrelinhas" ou "está subentendido", mas acontece muito =\

[@MrHUGOLADEIRA]

depois de um amigo reclamar do rendimento de outro dev, na esperança da liderança ir la conversar com ele pra cobrar uma melhoria, demitiram ele sem dar um feedback decente...

[@PedraKill]

Eu recebi uma punição, quando eu falei pro meu chefe que era ele que deveria resolver o problema do ambiente de QA e não eu pq eu estava gastando tempo codando, e ele tinha o papel de scrum master e ele deveria tirar os impedimentos do time, ele não gostou e no começo do outro mês eu fui demitido.

[@gustavocosta9139]

o dificil é quando você sabe que tem um dev enrolando mas n pode demitir ele pq alguem entregando 0,5 é melhor do q nada.

[@kauavictor5285]

A qualidade da task depende muito do quão bem definido o produto já tá e da cultura de quem tá pedindo pra task ser gerada. Se quem pede a task não entende o que tá acontecendo no produto ou não se importa muito com o trabalho e com o dev responsável, a task não vai ser delegada, vai ser "delargada".

[@Tobi1200]

0:24 Não, essa é muito pesada. kkkkkkkkk