Você pode ser gerente e programador ao mesmo tempo? [fechadas]

Gerenciando outros programadores enquanto você faz parte da força de trabalho de programação.

É um esquema muito comum, pelo menos nas empresas em que trabalhei.

Você pode ser um bom programador ou um bom gerente se fizer as duas coisas ao mesmo tempo?

Estou questionando a eficácia de um indivíduo que tem que ter duas funções muito diferentes, exigindo habilidades, ambiente, concentração, organização etc. muito diferentes.

ATUALIZAÇÃO : minha pergunta inclui o gerenciamento da empresa (que é o meu caso), não especificamente o gerenciamento de equipes. Mas estou interessado em ambos, é claro.

Depende da quantidade e tipo de programação que você deve executar e da quantidade e tipo de tarefas administrativas que você deve executar.

Ser gerente significa muitas interrupções, mudanças de rumo e coisas como reuniões etc.

Se sua programação é "limitada" a pequenos trabalhos não urgentes, você pode ajustá-los às suas tarefas administrativas. Se você precisar gastar uma quantidade significativa de tempo de "qualidade" em uma tarefa de programação, não receberá esse tempo devido às suas responsabilidades gerenciais.

Se sua equipe é grande e / ou complexa, você precisará gastar mais tempo gerenciando do que faria se fosse uma equipe pequena dedicada a um ou dois produtos / projetos. Você descobrirá que não tem tempo para fazer nenhuma programação significativa - mesmo em pequenas tarefas.

Em um trabalho anterior, eu tinha esse papel e funcionou para mim porque mantinha minhas tarefas de programação pequenas. Na verdade, funcionou a nosso favor.

Em primeiro lugar, pude avaliar todas as solicitações recebidas e, se elas fossem pequenas, adicioná-las à minha fila (que era sempre curta) ou retornar ao cliente (nesse caso, outro gerente) com uma escala de tempo mais precisa para quando o trabalho seria concluído. ser feito.

Em segundo lugar, significava que os desenvolvedores da equipe não estavam sendo constantemente retirados do trabalho atual para corrigir pequenos bugs ou fazer pequenos aprimoramentos.

Em terceiro lugar, os clientes ficaram satisfeitos porque seus problemas urgentes foram resolvidos rapidamente.

Isso me manteve em contato com a base de código para que eu pudesse ter conversas significativas com minha equipe sobre problemas e com meus gerentes e clientes sobre prazos, sem ter que envolver a equipe o tempo todo.

Eu fazia parte de uma equipe de desenvolvedores onde um programador também era nosso gerente. Isso levou a um colapso total de qualquer coisa semelhante à produtividade. Em suma, todas as decisões foram tomadas por esse cara + ele era um micro gerente completo. Todas as idéias e sugestões com as quais ele não concordava foram abatidas ou ignoradas. Isso acabou matando toda a criatividade e motivação.

Então, acho que é uma má ideia ter alguém na equipe de desenvolvimento em uma posição "superior". No meu caso, o cara era um gerente de comando e controle, mas eu até mesmo um ótimo gerente influenciará (involuntariamente) os outros desenvolvedores, o que eventualmente leva a um desempenho inferior. Pelo menos a equipe está se reportando a ele.

Sim,
eu vi alguns gerentes que eram programadores e gerentes ao mesmo tempo, acredite que trabalhar com esses caras foi maravilhoso.
Ser gerente e programador não apenas permite que os gerentes liderem de frente, mas também motiva os subordinados a dar o melhor de si.
A maioria dos funcionários reclama de seus gerentes que eles não têm valor, mas o gerente que não apenas gerencia, mas também escreve código, sempre oferece melhores resultados.
Os dois gerentes que mencionei, a programação era sua paixão, que não apenas ajudou os outros, mas também produziu um aplicativo quase sem erros.

Sou gerente de projetos de programação há anos, com diferentes empresas, projetos e equipes.

O gerenciamento e a programação do projeto são tipos tão diferentes de trabalhos / funções que eu argumentaria que você não pode fazer as duas coisas ao mesmo tempo no nível "excelente". É um compromisso - mestre de nada, valete de todos os negócios, tipo de coisa.

Para mim, a maior dor é a troca de contexto entre o modo gerente e programador. Eles parecem envolver diferentes partes do cérebro (ou algo assim). Um dia de programação, um dia gerenciando, posso me sair bem, mas é difícil alternar entre essas funções constantemente.

Eu já vi os dois cenários. Gerentes de desenvolvimento que fazem {alguma porcentagem de seu tempo} de codificação e um gerente de desenvolvimento que não faz nenhuma codificação.

O problema é que, quanto mais velho você se torna, maior a probabilidade de querer receber mais, e a única maneira de conseguir isso em muitos lugares é passar para a gerência. (não é claro, mas muitos lugares). Portanto, isso pode levar as pessoas que realmente não estão preparadas para serem gerentes a ficarem presas nessa situação.

(É claro que existem empresas nas quais você pode passar pelo Dev, Lead Dev - diferente do gerente de Dev, é claro - para cargos como Architect etc.)

As chances são de que, sendo um técnico, você pode ser inútil no gerenciamento de pessoas, além disso, o leva mais longe do código. Então você se torna um gerente ruim e está fazendo menos do que gosta e, presumivelmente, entrou em desenvolvimento!

Para mim, para ser gerente, você realmente deve estar longe da codificação, mas mantenha-se atualizado com a tecnologia, para que você possa pelo menos ainda falar sobre questões de forma coerente.

Por acaso, comecei a trabalhar como freelancer por esse motivo exato. Não tenho interesse em gestão de pessoas e acho que não seria particularmente bom nisso, além de não conseguir codificar tanto.

Isso pode ser feito, mas está cheio de armadilhas. O tamanho do grupo e o nível de interrupção têm um papel importante, mas o risco mais significativo é ter o gerente também como líder técnico. Muita opinião pesada quando não há tempo / esforço suficiente para justificar a opinião pode levar a algumas decisões ruins. E, o debate sobre direção não é um campo de jogo muito equilibrado entre um gerente e o resto da equipe.

Para aqueles que consideram esse caminho, alguns conselhos:

• Trabalhe para sair da função de arquitetura e identificar leads em seu grupo.

• Não trabalhe nos itens do caminho crítico. Corrija bugs, trabalhe em protótipos ou outros itens que podem ser descartados rapidamente quando seu chefe encontra muito mais 'coisas importantes' para distraí-lo.

• Aumente seu nível de atenção e concentre-se na eficiência geral, defendendo e promovendo a equipe, processo, moral e outros aspectos necessários para ter uma equipe de sucesso. É provável que seu objetivo seja muito mais do que apenas um projeto bem-sucedido (independentemente do que seu chefe, gerente ou outro possa dizer).

• Ajude a sua equipe a crescer: torne-se mais independente, auto-organizado, especialista em técnicas e alto nível de consciência.

• De muitas maneiras, você é a ponte entre a equipe e o mundo exterior. Uma parte significativa do seu foco deve estar fora da equipe.

Para responder à pergunta, sim, isso pode ser feito. Não, não é fácil e muitos gerentes novos do lado técnico da casa, que podem ter sido ótimos líderes, não podem fazer a transição para o trabalho de um gerente de sucesso.

Um bom gerente pode ser, sim. Enquanto você permanecer assertivo e consistente, geralmente não há problema.

Se for solicitado aos funcionários que levantem problemas com os colegas de equipe com o gerente .. e o gerente também seja um companheiro de equipe, ele poderá ficar pegajoso. É essencial visualizar todo o feedback objetivamente e perceber que você pode estar errado de tempos em tempos. Você também deve fornecer algum tipo de meio anônimo para feedback.

É extremamente comum (como você disse) ver isso em empresas iniciantes.

Eu acho que não.

Ambos os trabalhos exigem muito foco, energia e dedicação. É muito difícil executar as duas coisas ao mesmo tempo. Quando tive que assumir algumas responsabilidades de líder de equipe, a quantidade de tempo que gastei na programação (e consequentemente a quantidade de trabalho relacionado à programação realizado por mim) diminuiu.

Conheço outro colega que assumiu a função de gerente de uma função de líder da equipe e parou completamente de codificar em um mês (embora ele tentasse fazer as duas coisas).

Também conheço um arquiteto que foi convidado a se tornar gerente. Ele também parou de codificar dentro de um mês depois de assumir responsabilidades gerenciais. O mesmo arquiteto após 8 meses teve que voltar à codificação devido a problemas críticos de campo. Ele contribuiu significativamente na correção de bugs, mas em um mês eles precisaram encontrar um gerente de substituição para assumir suas responsabilidades gerenciais.

Na minha experiência limitada, não encontrei ninguém que gerencia outros programadores e códigos como um programador completo.

Na minha opinião, embora seja possível na maioria dos cenários, não é um bom arranjo. Existem inúmeros artigos sobre como as pessoas que são proficientes como desenvolvedores são notadas e levadas a uma função de gerenciamento de equipe, mesmo que essa não seja sua qualificação específica ou mesmo uma posição desejada. Eles lutam para manter o foco no "gerenciamento", porque consideram o "trabalho" como a realização da programação, não a criação de relatórios e a participação em reuniões.

Spolsky escreveu em seu artigo na Developer Abstraction Layer o seguinte:

"Com uma empresa de software, a primeira prioridade do gerenciamento precisa criar essa abstração para os programadores."

No artigo, (opinativo, mas bem fundamentado, eu acho), o papel do gerente não é entrar no código ou no desenvolvimento de software, mas criar um ambiente em que os que o produzem possam se concentrar totalmente nele.

Meu ex-chefe tentou. Havia muitas interrupções em seu papel de gerente.

Ele ainda é um dos melhores desenvolvedores que conheço.

Absolutamente você pode, mas isso não significa que é fácil. É preciso um certo tipo de pessoa para ser um bom desenvolvedor, é preciso um certo tipo de pessoa para ser um bom gerente e um certo tipo de pessoa para ser os dois. Se você pode encontrar essa pessoa (ou é essa pessoa), há vantagens definidas. Os gerentes de programadores de primeiro ou segundo nível precisam entender realmente o que seus funcionários fazem e encontram todos os dias. Difícil de fazer se você não fosse um desenvolvedor e manter contato / atualizado sem continuar desenvolvendo.

O melhor gerente que já tive (estou no ramo há 25 anos), foi um desenvolvedor ativo, meu gerente e meio-proprietário da empresa (cerca de 40 emps). Ele era especial, mas claramente conseguiu essa questão.

COM CERTEZA NÃO !!

Você pode tentar, mas acabará gerenciando mais do que qualquer coisa. O problema é que você não pode codificar quando as pessoas ligam para você a cada 5 minutos ou tentam fazer reuniões de "status" a cada hora. É ridículo ... Estou fazendo isso agora, e é por isso que tropecei nessa discussão.

Embora um gerente de uma empresa de tecnologia DEVE .. não ... DEVE saber como codificar. Você simplesmente não será capaz de estimar ou entender os problemas do cliente. Codificação e gerenciamento são dois tipos de pessoas. Um lado é nerd e desajeitado com as pessoas (encare isso, nerds que você sabe do que estou falando), e o outro é bom com as pessoas. Você deve escolher um lado. Você não chegará a lugar algum com a codificação se fizer as duas coisas. Se você gosta de codificar e pode fazê-lo 24 horas por dia, 7 dias por semana, se sua esposa não interferiu em seu caminho, FIQUE LONGE DE GERIR. Mesmo faça um corte salarial, se for necessário. Estou prestes a fazer isso, mas não acho que os chefes gostem disso, porque facilito a vida deles na parte administrativa. Terei que voltar a trabalhar como freelancer se eles não concordarem porque a felicidade e fazer o que você ama é muito mais importante que o dinheiro e as ilusões que ele compra.

Muitas felicidades com o seu esforço e por favor, mantenha essas postagens chegando. Caras, vocês são incríveis.

Leia a seção "Falta de uma carreira centrada na programação" neste site. Coisas muito boas e muito relevantes: http://c2.com/cgi/wiki?ProgrammingIsNotFun

É possível que uma pessoa tenha um bom gerente e boas habilidades de programação, embora o ditado "um valete de todos seja um mestre de ninguém" venha à mente ...

No entanto, a combinação de ambas as funções ao mesmo tempo me parece propensa a fazer as duas tarefas apenas pela metade. Depende da quantidade de gerenciamento que precisa ser feita, mas inevitavelmente você está lidando com duas tarefas de natureza completamente diferente, e a mudança de foco que isso exige é bastante grande. Percebo por mim mesmo que desempenho muito menos na seção de codificação quando tenho algumas tarefas de gerenciamento também (no meu caso, gerenciar os cursos e escrever relatórios).

Outra armadilha é que você está gerenciando um grupo, mas também é uma parte diretamente envolvida. Às vezes isso compensa, às vezes isso pode causar grandes problemas. Se outros programadores não concordam com seu trabalho, o fato de você ser o gerente pode impedir que eles sejam completamente abertos.

Então, novamente, quando você está codificando no mesmo projeto que está gerenciando, você se sente um pouco mais com o próprio código, portanto, nesse caso, o bit de programação pode realmente ajudar o bit de gerenciamento. Tudo depende do que você precisa gerenciar, quanto tempo exige e quanto fica relacionado ao código no qual você está trabalhando.

Acho que não há uma resposta clara, mas tenho tendência a evitar misturar os dois em demasia. Meus 2 centavos

bem, eu li que os gerentes de projetos de software definitivamente deveriam ser os próprios codificadores.

Eu acho que um gerente é um gerente por um motivo - para gerenciar. Eu aceitaria isso como regra geral ... alguns podem ser uma faca de dois gumes.

Conheço um caso em que funciona. O homem é meio que burocrático, então ele trabalha em período integral como gerente e quase em período integral como programador.

Considerando o horário normal de trabalho, não acho que uma função tão dupla seja uma boa idéia. Um programador de gerenciamento (ou gerente de programação) sempre é tentado a fazer muito do material de programação sozinho, em vez de fazer com que seus programadores o façam. Sempre existe essa desculpa "leva mais tempo para explicar do que para fazer", mas a longo prazo, o trabalho de 50% do programador que ele faz está ausente na parte de gerenciamento, para que outros programadores sejam menos eficientes.