Como faço para que as pessoas parem de andar de bicicleta (com foco em trivialidades)?

Fui encarregado de ensinar a outras equipes uma nova base de código, mas continuo com um problema. Sempre que eu passo o código com as pessoas, não chegamos muito longe antes de todo o exercício se transformar em exercício de ciclismo (membros de uma organização que dão peso desproporcional a questões triviais). Como eles não conhecem a base de código, mas acham que precisam ajudar a melhorá-la, eles se concentram no que pode entender:

Why is that named that? _{(2 minutos para explicar por que recebeu esse nome, mais de 10 minutos debatendo um novo nome)}

Why is that an abstract base class rather than an interface? _{(2 minutos para explicar, mais de 10 minutos debatendo os méritos relativos desta decisão)}

...e assim por diante. Agora, não me interpretem mal - bons nomes e design bom e consistente são importantes, mas nunca discutimos o que o código realmente faz ou como o sistema é projetado de maneira significativa. Fiz algumas reuniões de arbitragem para tirar as pessoas dessas tangentes, mas elas se foram - distraídas com o que o código será / deveria ser quando sua trivialidade de estimação for corrigida e elas perderem a visão geral.

Então, tentamos novamente mais tarde (ou com uma parte diferente da base de código) e, como as pessoas não obtiveram conhecimento suficiente para superar o efeito de ciclismo, ele se repete.

Eu tentei grupos menores, grupos maiores, código, quadro branco, diagramas visio, paredes gigantes de texto, deixando que eles discutissem até a morte, interrompendo os argumentos imediatamente ... alguns ajudam mais que outros, mas nada funciona . Inferno, eu até tentei que outras pessoas da minha equipe explicassem isso, porque pensei que poderia ser apenas ruim em explicar as coisas.

Então, como você educa outros programadores o suficiente para que eles parem de se apegar a trivialidades e possam contribuir significativamente para o design?

Penso que o problema é a tarefa: "Fui encarregado de ensinar a outras equipes uma nova base de código".

Você recebeu o emprego errado ou talvez tenha interpretado mal o trabalho que recebeu.

Ao apresentar no nível do código, você convida o pensamento no nível do código.

Comece no nível do sistema e apresente o design e as opções de design que foram feitas. Não permita discussões prolongadas: você não está revisando. Permita perguntas: você deseja que eles entendam o sistema. Se as pessoas "teriam feito de maneira diferente", tudo bem. Talvez concorde. Ou não. Mas siga em frente. É assim que é agora.

Quando você chega ao nível do código, você já os aprontou com a terminologia do sistema. Os nomes (eu assumo) farão sentido. O mesmo que acima: sem discussão prolongada, perguntas para compreensão. Ir em frente.

Agora, defina alguns problemas de classe. Como podemos fazer o aprimoramento X? Escolha algo não trivial que "acompanhe o fluxo" do design do sistema e trabalhe com o que você mudaria. Eles deveriam estar entendendo a lógica do sistema agora. Escolha outro aprimoramento que poderia interromper o sistema se feito errado e mostrar como ele pode ser feito corretamente. Esse deveria ser um momento Ah Ha para eles. Alguns podem até vencê-lo!

É um show difícil, especialmente após o início falso que você teve. Parece que você já investiu muito tempo e esforço, e talvez exista um pouco de eu versus eles. - Confesse e comece de novo. Assumimos que eles são pessoas inteligentes. Dê a eles o desafio de pensar em um nível superior. E divida os grupos que já existem selecionando diferentes seções transversais de equipes para as novas sessões.

"Estacione-os". No início da lição, explique o que você deve discutir e explique claramente o que é considerado Fora do Tópico. Se você fizer uma pergunta claramente OT, diga-a e siga em frente. Se eles voltarem, escreva a pergunta em um quadro branco (Isso é crítico) para discussões posteriores e siga em frente. No final da lição, quando estiverem no seu tempo livre, não no seu, observe a rapidez com que essas perguntas são resolvidas.

Defina as expectativas corretamente e seja honesto, aberto e aberto.

Verifique se seus objetivos são abertos e transparentes.

Inicie as discussões com a visão de alto nível promovida por andy256 (+1), mas também certifique-se de incluir seus objetivos, por exemplo

"... ao examinarmos esse problema, certifique-se de não focar em x, ye z. Verifique também se não estamos analisando detalhes de implementação, como detalhes a, b, c ou triviais como j, k, l. Eu sei que há muitos detalhes no código e detalha coisas que poderiam ser tratadas, aprimoradas ou tornadas mais padrão, mas vamos tentar ver o que realmente está alcançando em um nível mais alto primeiro "

Então, como você educa outros programadores o suficiente para que eles parem de se apegar a trivialidades e possam contribuir significativamente para o design?

Primeiro, não pense em suas preocupações como "trivialidades" ou "bikeshedding". Essas são palavras de julgamento e são insultantes. Suas preocupações são válidas. Eles simplesmente não são importantes no momento.

A chave para qualquer boa reunião é que todos saibam:

• por que você está tendo uma reunião e
• o que você espera tirar disso
• quanto tempo deve durar

Declare essas coisas antecipadamente, explicitamente, e explique os objetivos.

Por exemplo, você pode dizer: "Esta reunião é para eu familiarizá-lo com o pacote Foo e como ele é usado em nosso módulo de relatórios. Meu objetivo é fazer com que você entenda o suficiente sobre Foo para poder trabalhar no projeto Bar Reports a ser lançado. semana que vem. Gostaria que terminássemos nos próximos 90 minutos. "

Então, quando um tópico surgir, pode ser assim:

Nova pessoa: "Por que o FooWidget é implementado como um padrão de fachada?"

Você: "Bem, acho que é porque (breve explicação da decisão de design)" ou "Não sei".

Se a resposta for suficiente, isso é ótimo. Caso contrário, e continua:

NP: "Você não acha que seria melhor fazer um singleton?"

Você: "Eu realmente não tinha pensado nisso, mas gostaria de continuar explicando como o FooWidget funciona".

NP: "Mas se for feito como um singleton, podemos--"

Você: "Sinto muito por interromper, mas preciso manter isso focado em como o FooWidget funciona. Esta reunião está agendada apenas até às 11: 00h e temos muito o que fazer. A discussão sobre design terá que aguardar outra hora. . "

Depois de passar por isso uma ou duas vezes, você pode abreviar para "Isso está fora do escopo desta reunião".

Observe que você não está dizendo "Isso é besteira para se preocupar" ou "Não importa" ou "Cale a boca" ou "Você é novo demais para ter sugestões". Você está simplesmente concentrando a reunião no que precisa ser feito e no tempo envolvido.

Em certa organização, você nunca será capaz de conseguir isso. Muitas organizações valorizam muito mais a disputa política e a subida de escada do que a capacidade intelectual, diligência e lealdade. E por que eles não? Subir escadas coloca as pessoas em posições de poder, permite que elas melhorem suas vidas pessoais com mais renda discricionária e realmente nunca se tornam obsoletas.

Compare essa disputa de poder com a solução real de problemas, o pensamento abstrato e a tomada de decisões sobre questões difíceis, que podem ser responsáveis ​​pelas consequências de mais tarde, e muitos funcionários pesam muito ao lado de tentar andar de bicicleta o máximo possível.

O único conselho que sugiro é que você deixe claro, no contexto da sua organização, se possível, que o destino pessoal desses participantes depende de sua compreensão, contribuição e esforço em relação ao problema real que você está tentando resolver. Se essa é a arquitetura corporativa, expressa nessa base de código -errant e em todas as falhas, é isso. Deixe claro para eles que eles devem fornecer informações significativas e significativas sobre isso . Não qualquer outra aleatoriedade, que por acaso é uma irritação de um veterano ou outro e ganhará pontos agradáveis ​​ao concordar com o veterano.

Isso geralmente é difícil de fazer, pois a pessoa mais velha geralmente não entende a tecnologia em andamento, não está interessada e, infelizmente, controla os ingredientes básicos: tempo do funcionário; contratar e demitir, política da sala de conferências, promoções, etc., etc. a sério, etc.

O que você chama de ciclismo, eu chamaria de converter o fluxo de pensamentos de alguém em nosso. Ao discutir nomes, padrões, eles conseguem entender o código em seus próprios termos e não há como evitá-lo, é necessário.

Além disso, não há necessidade de fazer uma explicação muito detalhada de toda uma base de código, porque os detalhes serão esquecidos muito antes de eles começarem a trabalhar nela.

Com base nessas duas idéias, sugiro dividir a base de código em unidades e os alunos em grupos de duas pessoas. Para cada unidade de código, cada grupo terá, digamos, 25 minutos (depende do LOC, é claro), para poder fazer um passo a passo de 5 a 10 minutos do código para os outros. Três minutos de perguntas e repita com a próxima unidade. Explicar é a palavra-chave; eles precisam garantir que os outros tenham entendido tudo isso.

Você estaria lá apenas para impor tempo, sem tópicos e controlar a unidade que foi entendida o suficiente. Eles serão atores de seu aprendizado e estarão mais focados em explicar aos outros do que em bicicletas.

Você pode exigir um esquema de alto nível desenhado a partir deles da unidade de código, que será copiado e mantido nos documentos compartilhados pela equipe, para que eles tenham algo tangível a que se referir no futuro. É bom também ancorar memórias.

Desculpe se você já tentou isso ...

Você já tentou fazer pré-aulas que as pessoas examinam individualmente?

Faça vídeos ou apresentações curtas que expliquem o conteúdo, como o código funciona ou basicamente tudo o que você deseja ensinar a eles em um formato em que eles precisem analisá-los por conta própria e aprender as informações que você está tentando ensinar.

Em seguida, você usa as sessões baseadas em equipe para discutir questões relacionadas ao conteúdo. Você precisa identificar claramente que as sessões da equipe são para discutir e solucionar problemas relacionados apenas ao conteúdo.

Se você fornecer as lições para as pessoas individualmente, poderá evitar esse outro problema social em que um único assunto pode se tornar a voz do grupo como um coletivo e desviar o objetivo real das lições.

Tente ensinar a eles o design da base de código primeiro, guie-os pela arquitetura, ANTES de começar a olhar para exemplos específicos. Dessa forma, eles podem ver como os exemplos de código que você vê se encaixam no quadro geral. Pense em como seu programa de treinamento está estruturado. E inclua a motivação comercial por trás do design.

Passei vários anos treinando outros desenvolvedores e nunca entrei no código antes de mostrar como o sistema se encaixava. Então, quando os fiz fazer exercícios de código na estrutura, as perguntas foram estruturadas e no tópico.