Acredito que minha solução é melhor que a do meu chefe, então devo ignorá-lo? [fechadas]


16

Estou trabalhando com php e sql.

Eu acho que meu método de implementar funções é melhor do que o que meu chefe propõe. Agora ele me explicou como verificar uma lista de endereços de e-mail, e eu não gosto da ideia dele. Propus o meu, que é melhor e mais rápido de implementar, mas ele discordou.

Agora, acho que vou seguir em frente e implementar minha ideia, porque a ideia dele não era clara o suficiente para mim. Você acha que ele vai ficar bravo?


71
Parece que o problema pode ser que você não está fazendo um bom trabalho ao explicar por que o seu é "melhor e mais rápido de implementar".
Nicole

21
Por favor, adicione mais algumas informações: (1) Seu chefe pode programar? (2) Qual foi exatamente a solução do seu chefe. (2) Qual é exatamente a sua solução? Até que essas incógnitas sejam entendidas, é difícil julgar se sua solução é realmente boa.
Darknight

4
Você é melhor que seu chefe? O que faz você pensar isso? Precisamos de detalhes.
Damien Roche

3
Eu acho que poderia também ajudar a editar a sua pergunta para link para seu outra, questão relacionada: programmers.stackexchange.com/questions/28228/...
Damien Roche

3
Deixe-me adivinhar, você está codificando há menos de 5 anos? Doce, criança inocente ... :-)
Ed Griebel

Respostas:


83

Tendo sido "o chefe" e, como se viu, realmente melhor do que minha equipe em todos os casos, com exceção de um - sim, ele ficará bravo - ou irritado ou frustrado e, em qualquer caso, possivelmente, bem em primeiro lugar.

Se você é genuinamente melhor que ele, deve ser capaz de entender a solução proposta e ver por que a sua é melhor e depois explicar por que.

Mas você declara:

porque a ideia dele não era clara o suficiente para mim

Nesse caso, você precisa voltar e entender o que ele quer e por que e se - como tem sido o caso tanto em mim fazendo sugestões para minha equipe quanto na minha equipe propondo soluções para mim - você ou ele perdeu alguma coisa. Mas não assuma que ele está errado e você está certo, a menos e até que você entenda o que ele está pedindo e se ele está cobrindo algo em que você ainda não pensou.


Ah, e no primeiro caso - ele é um programador melhor, mas não é tão bom a alguns passos do problema em que eu sou melhor e nos divertimos muito trabalhando juntos por esse motivo.


13
+1 "a menos e até que você entenda o que ele está pedindo"
Dean Harding

3
Ótima resposta, gostaria de acrescentar que não devemos presumir que o chefe não tenha informações adicionais de seu chefe ou de alguém mais alto que o leve a ter conhecimentos adicionais que lhe permitam concluir que sua solução é melhor. Eu já vi isso acontecer antes e, em vez de parecer um idiota, ajuda a garantir que você entenda seu chefe e de onde ele vem antes de pular para o "meu chefe não entende que minha solução é melhor".
Chris

1
às vezes, ter a melhor solução não é suficiente nem é a coisa mais importante; a realidade é que existem egos, hierarquias e rituais de equipe / empresa, incrustados e consagrados pelo tempo - e são maiores que você e, às vezes, têm importância além do nosso entendimento imediato. a melhor coisa que você pode fazer é poder analisar e apresentar as opções lado a lado e apresentar seus benefícios e advertências com detalhes suficientes para que o gerente (ou equipe) tome uma decisão. pelo menos nesse ponto, você sabe que fez sua devida diligência e o destino do projeto não está mais em suas mãos.
jellyfishtree

1
O que me faz questionar essa resposta é "ter sido melhor que minha equipe". Eu não quero trabalhar para um chefe que pensa que é melhor do que eu ...
Jason Baker

1
-1. Se você realmente é melhor em programação do que todos os seus subordinados, então você recebeu o emprego errado. Nada diz que um gerente deve ser melhor em tudo. Idealmente, um gerente deve ser melhor no gerenciamento do projeto, e os programadores devem ser melhores na programação. Deve ser da mesma maneira com todos em todas as descrições de cargo. Uma equipe realmente excelente é aquela em que as habilidades se complementam, de modo que a equipe é maior que a soma das partes. Sinto muito amigo, mas sua atitude arrogante não tem lugar em uma equipe. Vá trabalhar sozinho e salve a todos um pouco de tristeza.
riwalk

50

Você está critizing -lo por pensar que você é melhor do que ele, em vez de critizing suas idéias .

Você precisa mudar esse comportamento inadequado em primeiro lugar.

Aproveite a oportunidade para desafiar suas idéias positivamente, pedindo "why?"tempo suficiente. Se a idéia é tão estúpida, ele acabará descobrindo por conta própria, respondendo às suas perguntas.

Essa técnica tem a vantagem de ajudá-lo a entender. A ideia dele é provavelmente mais inteligente do que você pensa.

Além disso, seeking to understandantes de tentar ser compreendido, seu chefe se desarmará contra você. Quando você propõe algo a alguém, o cérebro de um lagarto tenta determinar se é um tratamento. Seu cérebro de lagarto quer que ele esteja seguro. Procurar entendê-lo ressegurará seu cérebro arcaico.

Agora, se você tiver uma proposta melhor, tenho certeza que ele ficará mais do que feliz em ouvi-lo. Esteja preparado para ser solicitado "why?"várias vezes até que ele esteja convencido.

Afinal, você é o profissional, por isso ele o contratou em primeiro lugar. Ele deveria ouvir você.

Se ele não estiver interessado nas suas idéias, só há uma coisa a fazer: sair .


2
+1 em "Você precisa alterar esse comportamento inadequado em primeiro lugar". Primeiro, entenda a proposta de seu superior por dentro e por fora antes de criticá-la.
Chris

38

Você diz que seu método é "mais rápido de implementar". Isso soa um alarme para mim.

Código que é mais rápido de implementar pode, muitas vezes, ser difícil de manter.

Ele é seu chefe. A menos que você fique lá a vida toda, ele viverá com esse código por muito mais tempo do que você. Talvez sua estratégia leve esse fato em consideração.

Resposta curta: Insubordinação é uma maneira infalível de ser demitido.


4
Sua resposta curta é o melhor resumo absoluto do problema.
justkt

Eu discordo, mais rápido e mais simples é melhor. mais complexo com muitos casos de esquina é pior e mais difícil de manter. Eu até acredito que você sempre deve fazê-lo da maneira mais simples e, posteriormente, evoluirá, se for necessário.
IAdapter

Concordo parcialmente com você, também acho que "Mais simples é melhor". Mas, favorecendo "mais simples para a pessoa que lê o código 3 anos depois" em vez de "Mais simples de escrever". Portanto, nesse sentido, 'Simpler' pode ter uma troca com 'Quicker'. Se você me pegar.
JW01 9/01/11

9

Seu trabalho de chefe não é programar melhor para você, é administrá-lo. Portanto, deixando de lado o fato de que, dado seu aparente histórico de programação e que ele possa saber os motivos pelos quais sua solução não é a melhor - mostre a ele que você pode tomar uma direção e ele confiará em você mais adiante quando você o encontrar com melhores soluções .

Eu quase posso garantir que é sua maneira de dizer a ele por que ele está errado (que tal dizer como podemos fazer isso melhor?) Que está impedindo que você seja ouvido.

... para não dizer que não existem paus reais e inexperientes por aí :)


6

Considere que seu chefe precisa de algumas coisas de você:

  • A capacidade de programar. Por todos os direitos, a menos que ele seja um gerente em desenvolvimento, ele (esperançosamente) o contratou esperando que você fosse melhor que ele.
  • A capacidade de trabalhar em equipe: isso significa ouvir e explicar idéias.
  • A capacidade de fazer o que você disse. Quando a palavra final é dita, depois de toda a discussão de um problema, você não é o chefe. Se você tentar ser um grande sucesso quando for instruído especificamente a não fazer algo, não será confiável.

Se você quiser continuar com o problema, pode implementar a ideia do seu chefe, implementar a sua própria (no seu próprio tempo, se demorar um pouco), e demonstrar os dois para provar que o seu é melhor. Eu deixaria a atitude no chuveiro quando você o fizer.


"Quando a palavra final for dita, depois de toda a discussão de um problema, você não é o chefe." - o que isso significa é que, quando se trata de explicar para quem está pagando a você e a seu chefe por que não funcionou, você ficará feliz por seu chefe ter que explicar e não você.
Flamingpenguin

6

Sim, ele vai ficar bravo . Por isso, aconselho que envie um e-mail a ele por uma razão pela qual seu método é melhor. E peça a ele uma aprovação para prosseguir com seu método. Meu objetivo do "e-mail" é garantir que você liste e agrupe todas as suas razões antes de iniciar qualquer discussão.

Tente redigir como " Eu confio que esse método se adapte ao projeto / problema " - portanto, a menos que ele tenha uma maneira melhor, ele deve ir com você.

Se você realmente tem certeza e tem munição suficiente para apoiar sua visão, vá em " Confio que este método se adapte ao projeto / problema por causa de 1,2,3 .. razões "

Mais um conselho pessoal - dizer "eu sou melhor que meu chefe" parece um pouco arrogante, eu entendo que você pode estar com raiva agora - mas em um contexto profissional isso não será muito apreciado. Espero que seu chefe não leia este post;)


9
Nunca, nunca, tente resolver um conflito com o Email. Os e-mails permitem que você reaja de acordo com a sua disposição quando os lê.
Morten

Eu concordo com o comentário de Morten. A maioria dos conflitos também começa na conversa por email. A linguagem corporal é vital.

@Morten, Pierre: concorde com os seus comentários por "email". Eu quis dizer que deveria haver uma discussão sobre os pontos do OP versus os pontos de seus chefes.
Josek

O email deve ser uma etapa subsequente, para acompanhar, documentar e detalhar a conversa que precisa ocorrer primeiro. Perdi a conta de quantos e-mails vieram para devolver as pessoas que o enviaram (eu mesmo, incluído). As divergências e mal-entendidos mais voláteis ocorreram devido à estratégia de "primeiro e-mail, faça perguntas depois". Não importa o tom que você tem em mente ao escrever um e-mail, o tom quase sempre será interpretado de forma diferente pelo destinatário. Se houver uma conversa primeiro, um tom já foi estabelecido.
Mark Freedman

4

Ser um ótimo desenvolvedor não é apenas ser um bom programador! Parte do trabalho é trabalhar bem com os outros e colaborar com suas equipes e chefes. Se você acha que seu caminho é melhor, tente e explique isso para ele, mostrando-lhe "dados" do por que é melhor.

Se ele afirma que seu caminho é realmente melhor, do que tentar manter a mente aberta para o caso de ele estar certo. Se ele não está e está apenas exercendo autoridade sobre você, então você tem um chefe ruim ... (porque parte de ser um ótimo chefe também é colaborar com sua equipe e gerenciá-la adequadamente). Nesse caso, pode não ser uma má idéia começar a olhar em volta.


2

É certamente uma maneira rápida e fácil de ser demitido.

Meu conselho é implementar os dois e usar o que seu chefe deseja.

Se há um problema, diga-lhe que você tem uma correção, e mostrar a ele, mas não lhe diga por que você escreveu.


Eu tenho que discordar deste. Criar duas implementações apenas para provar que alguém está errado é simplesmente perda de tempo. Tenho 100% de certeza de que, na maioria dos casos, uma discussão normal sobre prós e contras de cada solução é suficiente.
Tx3

Você não precisa se curvar em todas as situações. Jogadores de alto nível conhecem suas coisas, sabem como prová-las e também sabem quando se retirar. E eles são os mais procurados e pagam os melhores salários. Os macacos de código convertem especificações incompletas em um código incompleto.
Coder

2

Eu não acho que você tem a atitude certa aqui. Pensar que você é melhor que seu chefe ou apenas pensar que você é melhor que alguém nunca ajuda as coisas. Você contou a ele por que não gostou da ideia dele ou acabou de dizer: "Eu tenho uma maneira melhor de fazer as coisas". Por que sua idéia é melhor exatamente? É um algoritmo menos complicado? Tem melhor tempo de execução? É mais fácil de manter? É mais fácil entender os padrões de design?


2

Como muitas respostas já foram fornecidas, não aconselho a codificar uma solução que seu lead não aprovou. Você primeiro precisa provar a ele que sua solução é melhor de uma maneira construtiva. Se ele é um bom gerente e pensa profundamente que sua solução é melhor que a sua, você pode esperar que ele explique o motivo. Não se esqueça que, como gerente, ele pode ter outros critérios além de você para definir o que é uma solução eficiente. A manutenção ou facilidade da leitura pode ser uma delas.

Além disso, se ele é um bom gerente, não será uma desonra para ele escolher sua solução, se você conseguiu objetivamente provar que é realmente melhor.

Mas no final, mesmo se você ainda não concorda com ele, não o engane; não faça algo que ele irá ignorar. O gerenciamento de equipes também se baseia em confiança e transparência, para que você possa estragar seu relacionamento e a eficiência da equipe. E os objetivos da equipe devem ser sua primeira prioridade.

Se a situação ocorrer repetidamente, e suas escolhas forem sempre ruins, ele não deve ficar com seu chefe por um longo tempo. Se for apenas ocasional, não fique muito orgulhoso ...


1

Parece que você está em conflito por algo, então você precisa se concentrar em ser construtivo.

Se você sinceramente não acredita na solução dele, deve encontrar uma maneira construtiva de dizer a ele como se sente a respeito. Existem algumas coisas a considerar nisso. Você é responsável pela entrega, mas a dele é responsável pela entrega da equipe. Você terá que mostrar que seu interesse é o da entrega das equipes e o seu (que esses dois se alinham).

Faça uma lista de prós e contras com as duas soluções e discuta-a com seu chefe de maneira construtiva. Às vezes, é mais fácil mostrar que está faltando um componente-chave da solução em uma lista.

Tente entender o que ele quer, esse é o objetivo final. Se você entrar em conflito com isso, não estará focando no objetivo certo.


1

Meu conselho é primeiro determinar se a solução dele é de fato melhor. Poste as duas soluções, peça uma opinião imparcial à SE.

Eu nunca ignoraria meu chefe. Se ele possui o conhecimento técnico, não há mal em uma discussão saudável. Ele coloca a ideia dele e você propõe a sua.

No entanto, se você determinar que, de fato, o método dele é inferior e ele não permitirá que você faça o trabalho para o qual ele o contratou, saia. Não há nada pior do que ter um cabeçote sobre você, dizendo como você deve fazer algo quando eles claramente não têm idéia do que estão falando.


1

Vamos começar com o fato de que é tarefa do chefe tomar decisões, não sua. Você vai contra essas decisões pelas costas dele e é um caminho rápido para ser demitido por justa causa.

Você pode e deve apresentar suas idéias antes que a decisão seja tomada, mas, uma vez tomada, é sua função fazer com que a decisão funcione, mesmo que você não concorde. Se você não puder fazer isso, terá uma carreira muito curta.


0

Depende da pessoa. Se ele for razoável o suficiente e você mostrar a ele sua solução e for melhor, ele provavelmente não ficará bravo. Mas se ele não estiver, então você está com problemas.

Agora, para a parte besteira não genérica: Ele é seu chefe. Ele não está lá para ser um programador melhor, mas para ser um gerente / líder melhor. Talvez ele tenha razões que você não considerou.

Se você corre um risco, vá em frente, mas não fique bravo se for demitido. É tudo uma aposta.


0

Não morda a mão que o alimenta.
Se você acha que a sua é melhor, mesmo depois de uma análise exaustiva, faça como acredita, mas viverá com as consequências.


Por que não? Ninguém será beneficiado se o produto final for um lixo cheio de insetos. É importante trabalhar em equipe e decidir em equipe. Mas sua tarefa como desenvolvedor profissional é encontrar soluções profissionais e defender sua posição se e quando for certo.
Coder

0

Meu chefe não pode programar o caminho de um saco de papel (na verdade, não pode programar apenas um bom falador e vigarista, mas para satisfazer suas inadequações, ele me faz fazer coisas que encobrem meu trabalho, para que ele possa cobrir o verdadeiro 1% das idéias são das perguntas-chave que faço. 100% do código e dos métodos vieram de mim. Quando o chefe me dá más idéias eu implemento as minhas, meu chefe está mais interessado em se envolver. à frente de um programa bem-sucedido. Minha estratégia de trabalhar em rede com todos os que o rodeiam ajuda a reprimir suas mentiras em nível local. Agora, trabalho na divisão 1/3 dos estados de uma grande corporação. Usarei a mesma estratégia novamente, embora vou precisar ser ainda mais criativo em redes.

Responder à pergunta original neste post que o código dos chefes não é tão bom quanto o meu. Como as outras pessoas afirmaram. O que te faz pensar isso. Código é lógica. Por que exatamente você acredita que o seu é melhor? No meu caso, evoluiu a política que vai além de ter um produto de sucesso. No meu caso, ele quer abafar meu reconhecimento de firma para prosseguir com o seu. Não sei qual é a sua situação com muitas possibilidades aqui.


0

Pode ser de qualquer maneira, dependendo dos detalhes.

Eu sei que já estive em muitas situações em que discuti com os chefes sobre uma coisa ou outra. Muitas vezes eu provei que minha ideia é melhor, às vezes eles me mostraram uma solução muito mais rápida e completa. Às vezes, nenhum de nós sabia, então eu tive que fazer a pesquisa, comparar as idéias e talvez até criar algo novo para a próxima rodada de tomada de decisão.

Se o chefe é um bom chefe e você está no nível sênior, ele provavelmente sabe que você tem muita experiência e uma visão melhor / mais atualizada dos problemas internos, e ele entenderá por que você fez alguma coisa, se explicar para ele. Ele também evitará microgerenciar você.

E, às vezes, não importa o quão bom você seja, você sente falta de coisas simples, que mais tarde fazem você se perguntar como seria estúpido em ignorar uma solução trivial. E o chefe, com sua visão geral à distância, pode identificá-los muito mais facilmente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.