Sou sensato ou implicante?

Não é tão simples assim. Não dá para você mesmo colocar 3 parágrafos da sua visão sobre isso e pedir uma avaliação de pessoas aleatórias na internet sobre uma situação que elas desconhecem completamente, e mesmo que conhececem você não saberia avaliar se o que elas disseram é adequado. Ou seja, ainda tem uma longa jornada para ser sênior.

Na verdade estou usando o termo como a maioria usa, e é errado. Porque isso é só um título que está na sua cartweira profissional ou currículo. Não existe essa categorização na vida que 99% das pessoas acham que existe. Você tem pessoas mais ou menos experientes, mas não tem algo que determine claramente onde começa uma coisa e termina outra, só o RH pode fazer uma classificação quase sempre completamente arbitrária para dar um título para o cargo.

A maioria das pessoas que se dizem sêniores não o são. Eu com mais de 40 anaos de experiência não sei se sou. De verdade, não é humildade. Eu sou em certos aspectos, mas não em outros, então não sei se conta. Eu sei que não caio nas armadilhas que a maiorias dos profissionais caem, eu não defino coisas que eu não sei o que é, eu não cravo certezas que não só possíveis, mesmo que alguém vá dizer, como aconjtece muito, que eu "nunca" dou uma resposta concreta. Porque eu aprendi que a vida não é assim. Busca por souções mágicas e fórmulas simples para reproduzir não funcionam na vida real e induzem a erro.

Eu sei o que eu faria em uma situação que eeu conhecesse bem. Eu sei que eu poderia errar nessa decisão ainda hoje. Eu não sei sobre os outros. Pode ser só que tenha que mandar essa pessoa embora. Ou outras soluções mais radiciais. POde ser que tenha algumas tarefas a serem feitas para esgatar a situação e fazer entrar tudo nos trilhos.

É possível que precise de uma consultoria externa para resolver essa questão, alguém experiente, sensato e tivesse tempo de avaliar a situação de perto em todos os detalhes. Se não for assim, é loteria.

Eu estou pensando em lançar um serviço assim de "sênior de aluguel", mas não já e ainda não sei se devo fazer, então não estou te vendendo nada, mas sinto que isso é uma falta no mercado.

A busca pela resposta simples é o que emais está causando problemas hoje em dia. E falarei bastante sobre isso no primeiro vídeo do meu canal, descascando as tais "boas práticas".

https://www.tabnews.com.br/maniero/faq-do-programador-perdidao

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Uma coisa que você precisa se perguntar é: "Se um dev de senioridade superior a sua chegar nesse projeto, ele vai conseguir tocar o projeto facilmente ou vai ter que ler o código todo e fazer várias perguntas para você para só depois conseguir fazer algo?"

O que eu quero dizer é o seguinte, o projeto pode estar me arquitetado e organizado, mas o mapa das coisas pode estar apenas na sua cabeça, e idenpendente de quem estiver chegando no time pode ter dificuldades.

em TODOS os casos eu tenho um retrabalho gigantesco, porque o código fica uma bagunça e, não só no sentido visual, mas no sentido lógico/funcional.

Será que não está faltando uma documentação por mais simples que seja com:

• As principais decisões do projeto
• Padrões utilizados, e com referências para essas documentações como os design patterns adotados
• Estilos de código adotados, para nomes de classes, variáveis, arquivos e etc.

Essas e outras definições você pode colocar em um arquivo .md simples no repositório do projeto, e toda vez que encontrar algo fora dessas definições nos PRs, você rejeita a PR indicando o ponto que está errado e insere a referência da documentação de padrões.

Sem isso, não importa a senioridade de quem estiver chegando no projeto, sempre será uma novela. É claro que quanto menor a capacidade técnica maior será a dificuldade.

Olá, Nynosamou! Também sou desenvolvedor e estou há 2 anos trabalhando no mercado. Nesse tempo, já vi os dois lados da moeda, fazer parte de um projeto que já tinha muito código desenvolvido, arquitetura e padrões bem definidos e outro que desenvolvi boa parte do código e passava pela mesma situação que você descreveu.
É importante entender que com menos experiência, é comum escrever códigos menos elegantes e que são sim menos efetivos. Eu, por exemplo, olho códigos meus de meses atrás e percebo diversas oportunidades de melhoria e coisas que eu faria diferente. Sou uma pessoa que quando trabalha em um projeto com padrões bem definidos pergunto muito e busco entender, mas nem todas as pessoas que encontramos na equipe são assim e muitas vezes isso pode ser difícil de lidar.
Mas respondendo sua pergunta, conversei com um Dev bem mais experiente que eu (que também é professor) quando estava passando pelo mesmo que você e algo que ele me disse me ajudou extremamente: sempre que for dar uma sugestão, justifique da forma mais simples e clara o motivo daquilo (como se fosse explicando para você mesmo quando tinha menos conhecimento, como você gostaria que te explicassem) e busque ensinar, além de só mostrar o caminho, porque isso vai fazer com que esse problema de inconsistência diminua cada vez mais e as sugestões passem a ser cada vez menos necessárias.
Então, se você não conseguir justificar com motivos plausíveis, pode ser que você esteja sendo implicante. Mas se você puder agregar para o outro desenvolvedor e ajudá-lo a entender o porquê de tal mudança, mesmo que sejam muitos pontos de sugestão, você está sendo perfeitamente sensato e ainda mais: ajudando com o crescimento profissional de alguém. Cresci muito e sou muito grato a Devs que já fizeram isso comigo.

Espero ter ajudado! :)

Ao meu ver parece uma oportunidade de evoluir nas suas soft skills, tu esta tomando responsabilidade de pleno/senior (code-review), cabe a você a compreensão quanto ao seu parceiro, apontando as melhores direções para que ele faça um código mais condizente ao padrão do projeto. Mostrar o por quê fazer daquela forma é melhor talvez ajude ele a entender melhor ou despertar nele o interesse de melhorar como profissional. Claro, isso no melhor dos casos, quando há interesse da outra parte.Entretanto, Não há muito o que fazer quando o outro não está nem ai pro trampo e só quer entregar mesmo, receber o salário e boas (nada contra..), sem querer melhorar ou agregar no serviço.
Espero que tenha entendido os meus pontos.Em tudo há dois lados, cabe a você: ver o copo meio cheio ou meio vazio...

É ciúmes, eu também tenho, estou passando por algo parecido, não nas mesmas circunstâncias, mas sentindo o mesmo sentimento

Acho que você tem uma bela oportunidade de fazer pair programming com ele. Pilota meia hora, vai codando e explicando o que você está fazendo. Depois de meia hora, troca e ele pilota. Quando você ver algo que não concorda, pergunte o porque ele fez daquela forma. Se ainda assim não concordar, ai sim, vai orientando e falando o que deve ser feito e o porque.

Você está sendo implicante. Use essa oportunidade para ensinar e ajudar seu colega, porque isso também vai melhorar suas habilidades de didática. Agora, se ele realmente não quiser aprender, aí não há muito o que fazer.

E lembre-se: o código de hoje não é seu, é da empresa. Não se apegue tanto a ele. Você está no começo da carreira, e muitos outros projetos mais desafiadores virão, onde sua criatividade e envolvimento farão mais sentido.

Aqui nossos devs que entram depois precisam se ajustar e seguir o padrão da arquitetura original do sistema, se nao for assim vira bagunça.

Eu trabalho com alguns estagiários, e todos passam e me criam os mesmos problemas. Parece que querem mudar e fazer as coisas que vêem na internet, e não respeitam a arquitetura que existe no trabalho que está. Além disso, vejo que muitos não se esforçam em aprender, muito menos em perguntar. Eu digo isso por que dos 5 estagiários que temos/tivemos, só dois se esforçaram para serem contratados, e foram quando tivemos a oportunidade. 1 desses dois demorou um bocado para entender que precisava correr contra o tempo para aprender, até pq o tempo passa muito rápido, já o outro contratado já tinha um conhecimento grande de programação, e quis implementar muita coisa q ele achava que seria interessante para ele, mas logo entendeu que tem um padrão na empresa na arquitetura do nosso código, e logo foi contratado.

Enquanto os outros 3, por mais que a gente explicasse, déssemos dicas de como se comportar, como trabalhar, como codar, entra por 1 ouvido e sai pelo outro.
Uma forma que eu gossto de ensinar, é ir perguntando conforme vou vendo com ele o código, conforme a gente coda junto, vou fazendo perguntas do que ele ta fazendo, do que x variável faz ou tem de valor, para que a pessoa pense, e não fique recebendo tudo mastigado, até pq se vc não pensar no que vc está recebendo de informação, é a mesma coisa de nada.

Tente conversar com ele, mostrar como é e o por que é da forma que vc criou a arquitetura, se ele não quiser melhorar em 1 ou 2 conversas, acho que você deveria procurar ajuda de alguém acima de você na hierarquia e mostrar todos os pontos do que está acontecendo.

Cuidar de estagiário/júnior é sempre uma tarefa árdua kkkkkkk

Cara, acredito que como você estava trabalhando sozinho no projeto seria legal se fizesse meio que um onboarding do projeto pra esse dev novo, já que ele também é júnior. Explica a arquitetura que está usando, por que fez as coisas da maneira que fez e etc, isso já daria um bom ponto de partida pra esse novo dev. Além disso, não sei se fazem code review, já que você disse que tem retrabalho sobre o código do seu colega. Fazer um bom code review, e pontuar o que pode ser alterado no código, dando exemplos e deixando que ele faça as alterações pode ajudar com que ele aprenda mais facilmente a arquitetura e padrões do projeto que vcs estão trabalhando. Não tenha medo de solicitar alterações e recusar PRs em que você ache que algo precisa ser alterado ou simplesmente não está correto, principalmente se o código desse outro dev não atende os requisitos funcionais, por isso, tire um tempo pra testar as alterações rodando a branch desse seu colega localmente. Se for preciso, peça apoio de um dev mais sênior pra analisar o código do seu colega, assim você tem mais garantia de que o que você tem pra reclamar não é só ciúmes do seu código, como vc disse. Não entendi muito bem o que você quis dizer com a bagunça no "sentido visual", imagino que esteja falando sobre linting. Se for esse o caso, ter um linter configurado no projeto pode ajudar bastante a evitar essas divergências de estilo no código.
Já passei por essas situações algumas vezes, e situações como essa vão te ensinar a diferenciar o que é um PR ruim do que é apenas algo feito de uma maneira diferente do que seria sua preferência, então não fique desanimado! =)