Que chapéu um programador não deve usar? [fechadas]

Na minha experiência, os desenvolvedores de software tendem a usar vários chapéus e preencher várias funções com responsabilidades diferentes. Não apenas codificando, mas também escrevendo SQL, projetando a interface do usuário, projetando o banco de dados, manipulação de gráficos e até mesmo o teste de controle de qualidade.

Se a função principal é escrever software / código, que funções o desenvolvedor não deve assumir? Há alguns?

A intenção desta pergunta não é porque um desenvolvedor é incapaz de desempenhar outra função - mas ter a função adicional realmente funciona contra a função principal ou deve ser realmente uma função dedicada de alguém que não programa principalmente.

Sysadmin. Desenvolver software e manipular a infraestrutura de TI são duas habilidades diferentes que se parecem com alguém de fora. (Tudo está apenas batendo nos computadores, certo?) Para uma empresa pequena, a tentação será muito forte em tornar o The Computer Guy responsável por todas as máquinas no escritório.

Se você tem as habilidades necessárias para usar os dois chapéus, incrível; mas é uma daquelas coisas que pode levar muito mais tempo do que as pessoas imaginam e, se você é autodidata, é provável que não esteja fazendo isso muito bem.

Você usa o chapéu que seu empregador pede. É isso que faz de você um jogador de equipe. É isso que faz de você um solucionador de problemas .

As pessoas ficam muito envolvidas com a idéia de ser um "desenvolvedor" ou "arquiteto" ou "analista". Dane-se isso. Você deve ser um solucionador de problemas. O código é apenas uma ferramenta no seu cinto.

A solução de problemas nunca sai de moda.

Se meu empregador quer que eu faça suporte técnico ou construa computadores, que assim seja. Eles acham que estão desperdiçando seu dinheiro, considerando um salário de desenvolvedor, mas isso é problema deles. Estou aqui para resolver problemas. No entanto, eu posso fazer isso, eu farei. E se eu sentir que, após um certo período de tempo, meus talentos são desperdiçados ou minha satisfação no trabalho não é onde eu quero que seja, então tenho o direito de mudar para outro emprego.

Mas para a pergunta básica - não há um chapéu que você não use. Caramba, se eles querem que você pegue café, faça-o. Resolver seus problemas; apenas saiba que você tem o direito de encontrar outro emprego, se desejar mudar.

Testador!

Envie-nos os testadores diretamente para fora da escola, se necessário!

Sem testadores, as pessoas esperam que tudo dê certo, porque o programador é o testador e elas são muito inteligentes, portanto, deve funcionar.

Não estou dizendo que dogfooding não é uma boa ideia. Só acho que os testadores são muito importantes agora que sou programador.

Você deve ter cuidado ao se tornar o principal responsável por problemas de hardware de escritório . Isso pode incluir solução de problemas do PC, administrador do servidor, backups e até trabalho do sistema telefônico. Cometi o erro de mencionar minha experiência anterior em hardware e, eventualmente, minhas tarefas de hardware / solução de problemas entraram em conflito severo com minhas tarefas de programação.

Um programador não deve ser o único testador para seu próprio código .

Os desenvolvedores escrevem código com um conjunto de suposições. Se os testadores tiverem o mesmo conjunto de suposições, eles não exercerão a funcionalidade inesperada fora desses limites e muitos problemas permanecerão sem serem detectados.

Além disso, para avançar, os desenvolvedores não estão altamente motivados a tentar quebrar as coisas, enquanto os testadores estão (talvez no nível subconsciente).

Isso não implica que o teste do desenvolvedor seja inútil. Muito pelo contrário - um bom teste de desenvolvimento permite que os testadores se concentrem em encontrar problemas mais profundos. No entanto, o teste do desenvolvedor não substitui um testador dedicado.

Dois eu consigo pensar logo de cara.

1. Suporte técnico. Não estou aqui para ajudar os clientes a trabalhar no novo site ou ensiná-los a usar os recursos.
2. Embora possa ser necessário interagir com os clientes em vários pontos do processo, a menos que você seja um programador de gerenciamento, não deve se comunicar diretamente com eles sobre recursos e implementações de design.

Você poderia dizer que o desenvolvimento de CSS / UI estaria fora do "domínio" da programação, mas, na minha experiência, é uma habilidade necessária hoje. Você não pode simplesmente se safar das tabelas e depender de outra pessoa para implementá-la corretamente. Talvez eu não goste de implementar o design ou alterar o código para lidar com um novo design, mas isso faz parte do trabalho.

Escrever consultas é bom, o teste de Q / A é bom (e o IMO deve ser o trabalho do programador, é necessário encontrar um departamento externo, mas primeiro você deve testá-lo). A administração do servidor é um pouco de uma área cinzenta. Dependendo do tamanho do projeto ou se você possui um administrador de servidor dedicado, ele pode ou não ser necessário.

Em geral, é minha experiência que a maioria dos programadores não deve desenvolver a aparência da interface do usuário - embora eu certamente seja capaz de desenvolver uma interface do usuário (e muitas vezes crie uma ao criar um protótipo ou prova de conceito), isso é melhor deixar para uma pessoa de fatores humanos (que em nossa pequena empresa é um artista gráfico que também faz os layouts de tela e cria a maioria dos manuais e brochuras).

Além disso, os desenvolvedores não devem fazer testes de controle de qualidade - esse é o trabalho do departamento de controle de qualidade (a empresa em que trabalho fabrica dispositivos médicos incorporados, portanto, é um requisito que os testes sejam feitos por um departamento separado).

Por outro lado, não vejo razão para que os desenvolvedores não possam criar bancos de dados e escrever SQL, se tiverem o plano de fundo para fazê-lo - já o fiz muitas vezes.

Suporte técnico

Grande parte do meu dia é desperdiçada ao receber chamadas de suporte técnico ...

Alguns populares são:

• "Minha conta está bloqueada" ou "Esqueci minha senha"
• "Meu [telefone | teclado | mouse | computador] não funciona"
• "Meu computador está lento, você pode verificar se há algo incomum?"
• "Por que X acontece quando clico neste botão? Ele deveria estar executando Y"
• "Eu continuo recebendo esses pop-ups ..." ou "Eu acho que tenho um vírus"
• "Essa pessoa não está mais aqui, você pode desativar todas as suas coisas?"
• "Temos um novo funcionário, você pode configurá-los com login, cartão de segurança, telefone ext, e-mail, etc?"

Qualquer papel que o faça se administrar. Em equipes pequenas, geralmente há uma tendência de tornar um dos desenvolvedores seniores o gerente de projetos, mas também o mantém na equipe como programador. Isso leva a todos os tipos de problemas, já que esse cara, como programador, é basicamente não gerenciado. Em vez de delegar todas as tarefas aos outros membros da equipe, ele muitas vezes fica tentado a atribuir muitas delas a si próprio, especialmente as tarefas mais difíceis. Portanto, as tarefas mais difíceis, aquelas com maior probabilidade de causar problemas, são atribuídas a uma pessoa que tem apenas 50% de disponibilidade como programador e, como tal, não reporta a ninguém. Quando outros membros da equipe não conseguem entregar, em vez de chutar a bunda, ele tenta executar suas tarefas, pois, como gerente de projeto, ele é responsável pelo sucesso e a maneira mais segura de fazê-lo é fazê-lo sozinho. , não é?

Suporte técnico para algo que você não teve nenhuma ajuda no desenvolvimento, implantação ou manutenção, e não recebeu treinamento nem está atualizado sobre as principais mudanças. Parte do meu trabalho passou a ser atender o telefone para clientes ligando sobre o motivo de a internet não estar funcionando. Eu não lido com essa metade dos negócios, então não posso contar nada a eles.

Não é necessário suporte técnico, não há problema. É ser um gerente / suporte técnico enquanto tenta desenvolver as coisas.

Fica bastante cansativo ter que ouvir as pessoas reclamando o dia todo e não poder contar nada a elas. Eu recomendaria evitar isso a todo custo.

Vendas .

Algum bugger pobre tem que fazer isso, mas com certeza não deve ser o desenvolvedor.

À medida que envelheci, percebi que isso é melhor se os desenvolvedores não fizerem suas próprias implantações (lutei contra este dente e unha). Eles não devem ter direitos sobre o banco de dados de produção, exceto direitos selecionados. Nosso código ficou muito menos problemático (e a mesma coisa não surgiu várias vezes porque a alteração foi feita apenas no prod e uma implantação posterior do desenvolvimento substituiu-o novamente, depois foi corrigido apenas no prod com pressa, enxaguando e repetindo) quando teve que começar a entregá-lo a outras pessoas para implantar e não ter permissão para fazer alterações rápidas na produção de correções porque a implantação não estava certa. Além disso, paramos de ter essas "atualizações acidentais sem a cláusula where destacadas que alteravam todos os registros da tabela".

Artista e designer de interface do usuário .

A maioria dos programadores é muito pobre em obras de arte, mas as empresas não se preocupam em pagar por um artista para desenhar imagens e ícones para seus produtos, e apenas usam a "arte do programador" - com resultados hediondos. (Até o Windows Vista, esse era o fator de diferenciação mais óbvio imediatamente entre Macs e PCs - os Macs pareciam bonitos e amigáveis, os PCs eram uma desgraça)

De maneira semelhante, muitos programadores não estão muito interessados ​​na interface do usuário - eles se preocupam principalmente com o código. Eles simplesmente expõem o conteúdo de suas variáveis-membro diretamente em alguns campos editáveis, geralmente não se importando onde colocam botões e campos em seus formulários, e assumem que isso é suficiente, resultando em software inutilizável. (Todo o setor de telefonia móvel foi muito culpado por isso até o iPhone chegar para mostrar a eles que você realmente podia criar uma interface do usuário do telefone que fosse agradável de usar)

O Lotus Notes é um exemplo brilhante de como essas duas coisas podem ser ruins se você não conseguir um designer profissional para ajudar os programadores.

Escrevendo testes e planos de teste gerais. Sério, pessoal, eu posso escrever meus próprios planos de teste, mas isso significa incorporar no produto quaisquer equívocos, suposições falsas e erros cognitivos que cometi ao escrever as coisas. Era a única coisa que eu odiava em uma empresa em que trabalhava; onde estou agora, pelo menos temos análises de código que provavelmente capturarão essas coisas.

Nunca use mais "chapéus" do que você pode razoavelmente lidar e se sentir confortável, tentando convencer os desenvolvedores a dizer que eles não devem usar A ou B significa que um ótimo designer de interface do usuário pode passar despercebido porque alguém acha que os programadores devem ficar longe a interface do usuário.

No final do dia, todos terão pontos fortes e fracos diferentes e um bom gerente / supervisor / líder de equipe deve saber a melhor maneira de direcionar as pessoas que trabalham para eles, a fim de garantir que os talentos sejam usados ​​adequadamente. Da mesma forma, se você não estiver familiarizado com o design de UIs ou com os usuários finais, informe a equipe para que você possa minimizar sua função nessa área. No entanto, você deve estar preparado para buscar algum trabalho adicional em outra área.

Além disso, se você estiver usando muitos chapéus (por exemplo, programador, designer de interface do usuário, testador, analista de negócios, etc.), você terá um desempenho ruim em alguns deles ou se queimará. Certifique-se de saber quantos chapéus você pode manipular e tente manter a carga de trabalho nesse nível.

Além disso, realmente não existem "chapéus" que um desenvolvedor não deva usar se tiver habilidades para se destacar nesse papel.

Costumo aceitar qualquer trabalho que seja lançado para mim se e somente se:

• Eu aviso com antecedência sobre o meu nível de habilidade e possíveis implicações e meu chefe decide que é aceitável
• Existe uma pessoa de nível de guru que pode (e provavelmente irá, em algum momento) me ajudar a lidar com algo inesperado
• Leia a documentação, as perguntas feitas on-line etc.

Dessa forma, estou mais seguro contra meu chefe e, se alguém der errado, é pelo menos corrigível.

Os desenvolvedores são partes interessadas na situação (como clientes, proprietários, etc.), portanto, eles têm o direito de esperar um emprego significativo. Na minha opinião, isso significa a oportunidade de trabalhar com seus pontos fortes .

Portanto, um desenvolvedor não deve usar um chapéu que não energize, contribua para o crescimento pessoal e leve ao desempenho máximo - e roube tempo dos "chapéus" que fazem essas coisas por eles.

Além de não ser o único a testar seu próprio código, acho que qualquer "chapéu" está ok se for um trabalho significativo para o desenvolvedor que está usando o chapéu.

O "designer" ou o "cara criativo". Você passará da montagem inocente de uma maquete da interface de um aplicativo para a redação de texto de marketing para a próxima campanha publicitária on-line ou discussões intermináveis ​​sobre o tom "certo" de azul antes que você perceba x_x.

aquele chapéu com as latas de cerveja ao lado com um canudo. má ideia se você for pego.

editar:

Aqui está o chapéu que eu odeio, mas que tem uma grande recompensa - é um grande sinal para mim que diz que se tudo isso quebrar, é tudo culpa sua ... ah, mas se for bom, então você, meu filho, é o bom garoto que todos conhecemos são - agora volte para o porão ... bom garoto ... é isso.

O chapéu da culpa.