Programadores têm frases diferentes sobre problemas difíceis. Provavelmente minha opção favorita : "Existem dois problemas difíceis na ciência da computação: invalidação de cache, nomeação e erro por unidade".

Escrevo software há tempo suficiente para enfrentar cada um desses problemas. Ao mesmo tempo, falo do lado dos negócios e explico aos clientes a parte técnica do nosso produto; portanto, encontro constantemente não programadores. O mais importante é transmitir corretamente a ideia ou conceito de maneira que os outros a entendam.

E isso é muito difícil.

Como em todos os campos profissionais, os programadores desenvolveram seu próprio jargão para transferir conceitos rapidamente.

Technolepet

O jargão é muito importante. Se eu e meu colega escolhermos um algoritmo para resolver um problema específico, podemos dizer que "a primeira opção O(n^2)com sobrecarga mínima desde o início e a segunda é depreciada O(n log n), mas com instalação e configuração caras" .

Essa frase única diz muito, para quais cenários o algoritmo deve ser usado e como eles são implementados sob o capô:

A opção A é ótima para um sistema com uma pequena quantidade de entrada.
A opção B é ótima para trabalhar com uma quantidade realmente grande de dados de entrada, onde os altos custos de instalação e configuração do sistema serão compensados pelo melhor desempenho do processo.
Se você pretende usar o algoritmo em um loop, escolha a primeira opção para evitar o caro código de instalação e configuração.
Talvez possamos reduzir o custo de instalação da opção B usando o cache.
Provavelmente, na opção A, cada elemento dos dados de entrada é comparado com todos os outros (por exemplo, for x in inputs { for y in inputs { if some_condition(x, y) { ... }}}).
Provavelmente, a opção B primeiro cria uma árvore e, em seguida, realiza uma pesquisa linear, seguida por uma pesquisa nessa árvore.

Como você pode ver, conseguimos transmitir vários parágrafos de informações em uma frase, simplesmente usando os termos corretos.

Nesse caso, eu quis dizer algoritmos para detectar colisões, ou seja, interseções entre dois ou mais objetos. O primeiro verifica todas as combinações possíveis de dados de entrada, enquanto o segundo usa uma árvore de quadrante ou uma partição de espaço binário para verificar apenas os elementos próximos.

Mas se você tiver uma reunião com pessoas de fora do mundo da programação (por exemplo, engenheiros mecânicos ou elétricos, gerentes, profissionais de marketing), esse jargão técnico apenas insultará e confundirá as pessoas, sem transmitir quase nenhuma informação valiosa.

É isso que chamo de technoleth, o murmúrio de um programador.

Francamente falando, geralmente esses detalhes e termos não são necessários para pessoas de outras áreas e eles realmente não se importam.

Por exemplo, você está explicando uma nova função incrível que encontra o caminho mais curto de A a B, gerando uma grade de navegação e aplicando a pesquisa A * .

Em nenhum caso você precisa descrever a nova função como na sentença anterior. Em vez disso, diga algo como isto:“Calculamos vários caminhos possíveis e aplicamos os algoritmos inteligentes usados na indústria de jogos para encontrar a melhor rota . ”

Não importa se estamos usando a pesquisa A * aqui (ao contrário do algoritmo Dijkstra ou da pesquisa por largura). Não importa que, nos jogos, a pesquisa A * seja usada não apenas para mover personagens. Basta que o interlocutor saiba que você pode encontrar um bom caminho de A a B e que usamos ferramentas confiáveis que já foram testadas em outras áreas.

Não faz mal mostrar a ilustração do que você quer dizer ... Por

acaso, observei como programadores mais experientes usam o jargão técnico para demonstrar superioridade, mostrar sua incrível inteligência e estabelecer domínio. Isso é realmente irritante.

Não entenda errado, às vezes há situações em que um interlocutor suficientemente competente pergunta: "Isso é muito difícil, por que não fazer X?" - e você tem que mostrar que é um especialista aqui, mas ele não sabe do que está falando ... mas você ainda pode fazer isso de maneiras diferentes.

Não tente usar o technolepet para satisfazer o seu ego, pois ostraciza as pessoas e desonra a nossa profissão.

Respeito

Então, vamos gradualmente para o próximo ponto ... não se esqueça do respeito.

Muitas pessoas com quem trabalho são realmente inteligentes e especialistas em seus campos, mas não necessariamente elas têm conhecimento e experiência suficientes na criação de sistemas de informação.

Ao explicar um problema complexo, geralmente é melhor simplificar conceitos. Mas tente não ser condescendente.

O engenheiro de software que mencionei frequentemente respondeu: "É ... complicado" quando uma pessoa "normal" pergunta como essa ou aquela função funciona. É como se o código fosse tão sofisticado que, sem 20 anos de experiência em programação, você não possa entendê-lo.

Não faça assim.

A melhor resposta:“Se você simplifica um pouco as coisas, primeiro fazemos o X, depois fazemos o Y e, finalmente, o Z, mas você precisa ter em mente uma dúzia de situações de fronteira (talvez explique uma ou duas), mas a essência é essa . ” Seus colegas são espertos e sem jargão técnico são capazes de entender você.

Outro truque realmente útil é usar um não programador como deck, como um pato de borracha. Se você estiver trabalhando em um problema complexo, explique a ele com palavras simples sua solução e pergunte se você pode encontrar uma opção melhor.

Nossa empresa trabalha no campo do CNC, ou seja, tem algo a ver com o mundo real (por exemplo, quando você tenta implementar uma compensação pela largura do corte ). Os engenheiros são realmente bons em analisar problemas relacionados à física e geometria.

Personificação, exagero e analogia

As pessoas são seres sociais. Somos programados para entender relacionamentos e adorar analogias para relacionar novos conceitos aos existentes. Ao conversar com alguém, você pode usar esses truques para ajudar a entender tópicos complexos.

Digamos que sua empresa tenha um sistema de compras on-line. O profissional de marketing deseja entender toda a cadeia, desde o pedido on-line até a entrega do pacote, a fim de responder melhor às perguntas dos clientes. Eu poderia dizer algo assim:

, . www.example.com, «» ( -, ).

(-). , () . , , , (, ).

( ), , . , , ( — , ), .

( ) . , , .

Tudo isso parece um pouco cômico, e o exemplo é exagerado, mas posso garantir que essa é uma explicação mais compreensível do que um grande diagrama de rede com os termos “servidor web”, “arquitetura de eventos” e “Apache Kafka” (consulte a seção technolepte )

Outro exemplo. Se você tentar explicar a alguém de fora como o algoritmo de pesquisa de caminho funciona, não diz que "os caminhos visitados recebem mais peso", diz "o algoritmo realmente não deseja seguir os caminhos para onde já foi".

Essa é uma diferença sutil, mas estamos fazendo a personificação do algoritmo. Dizemos que ele “realmente quer fazer X” ou “tenta muito evitar Y”. Muitas vezes isso ajuda as pessoas a entenderem .

Analogias úteis com exemplos (se apropriado). Você provavelmente já percebeu que este artigo está cheio de exemplos. Em vez de uma explicação abstrata, conto histórias específicas que ajudam a explicar a tese. Isto não é um acidente.

Desenhe belas imagens

Parece brega, mas às vezes uma imagem vale mais que mil palavras.

Há alguns meses, eu estava lendo um curso no rádio, e a garota por perto não conseguia se lembrar de quais botões pressionar no menu desse pequeno LCD 16 × 2.

Perguntei se ela poderia desenhar um diagrama.

Ela pensou que eu era um cara inteligente e zombou dela.

Mas eu não estava brincando.

Em vez disso, encontrei um pedaço de papel e, juntos, fizemos algo assim:

O programador reconhece imediatamente o diagrama de estados da teoria dos autômatos. Sem o conhecimento de uma garota, apresentei a técnica fundamental da ciência da computação em seu cérebro e como a interface deste rádio é programada sob o capô.

Mas ela (e todos os outros nesta fase) não dá a mínima para a ciência. Eles têm um mapa que eles podem usar para navegar na interface do usuário.

Há um prazer estranho em adaptar um conceito complexo para alguém de outra área. Especialmente quando eles podem determinar que o mapa é realmente um bug: você precisa pressionar e segurar o botão Cancelar para retornar ao estado de espera, porque pressionar esse botão normalmente o leva ao "Menu principal".

Eu sempre tenho um caderno grande com folhas em branco na minha mesa. Normalmente, escrevo uma lista de tarefas ou alguns desenhos durante a reflexão, mas muitas vezes isso ajuda a explicar. A capacidade de desenhar algo durante uma conversa ajuda a verificar o curso e garantir que você esteja no mesmo comprimento de onda (trocadilho intencional) que você tem a mesma idéia.

Acelerei $ FEATURE dez vezes

Suponha que você tenha feito alguns ajustes de desempenho e agora um determinado trecho de código funcione muito mais rápido. Como explicar isso para um não programador ou alguém que não vê o código fonte?

Por um lado, para a pergunta do que você fez na semana passada, você pode dizer a verdade à pessoa: "Adicionei o cache lookup_something ()para acelerar a pesquisa geral e traduzir o algoritmo de detect_collisions()c O(n^2)para O(n log n)" , mas com uma alta probabilidade de que eles não entendam nada (consulte o technolept ) .

Você também pode dizer que “otimizou a produtividade” , mas parece uma desculpa, e o gerente pensará no motivo de ter contratado você.

Muitas vezes, os desenvolvedores dizem: "Acelerei dez vezes o FEATURE".(ou algum outro número arbitrário) e isso é limitado. Essa frase permite que você desfrute de muitos parabéns dos habitantes da cidade, mas muitas vezes é um pouco ... enganoso.

Na maioria dos casos, você realmente melhorou o desempenho de várias funções, mas se essas funções não representassem um gargalo de desempenho, com uma alta probabilidade, ninguém verá diferença.

Nota. Se você conhece a lei de Amdahl, aumentar o desempenho de uma função que não é um gargalo é como usar mais núcleos de CPU para uma tarefa que é essencialmente consistente.

A pergunta também implora: o que você fez para aumentar a produtividade dez vezes? Esse é um número surpreendentemente específico. Seu código-fonte repetiu um trabalho várias vezes? Ou ele solicitou dados (digamos, de hardware ou site de terceiros) dez vezes mais devagar do que deveria? Até isso me faz duvidar de suas habilidades, porque você adivinhou (mal) a velocidade inicial da pesquisa ou ainda sacrificou o desempenho usando a pesquisa em vez de uma arquitetura de eventos mais eficiente.

Parece-me que é melhor tentar encontrar um meio termo entre precisão e compreensibilidade. Se você fez uma alteração que melhora a complexidade algorítmica de um fragmento de código (por exemplo, uma função detect_collisions()alterada de O(n^2)para O(n log n)), você pode dizer:"A função X agora pode ser dimensionada para uma grande quantidade de entrada em um período de tempo razoável, mas não podia antes . "

É normal dizer "não sei" ...

... e continue assim: "... mas se você me der cinco minutos, eu posso lhe dizer" .

Eu sempre vejo isso. As pessoas têm medo de mostrar sua ignorância; portanto, ficam caladas, atormentadas ou inventam alguma coisa.

Por exemplo, se um gerente chegar até você e perguntar: “O cliente solicitou a função X, isso é possível? E quanto tempo vai demorar? "

Em nove de cada dez casos, a resposta honesta é "não sei", mas não ajuda muito o gerente a decidir o momento. Ele se voltou para você porque você é um especialista na área relevante e está melhor preparado para dar uma resposta.

Alguns tentam adivinhar ou trapacear (por exemplo, "Sim, faremos isso em duas a três semanas"), mas essa abordagem geralmente não funciona a longo prazo. Na melhor das hipóteses, você será atrasado por algumas semanas e, na pior das hipóteses, passará meses trabalhando apenas para descobrir que essa função não pode funcionar com a arquitetura de aplicativo atual.

Essa é uma ótima maneira de perder o respeito dos colegas e superiores.

Por outro lado, as palavras "Não tenho certeza, mas dê 5 a 10 minutos e terei uma resposta" mostram várias coisas ao mesmo tempo:

Você está pronto para admitir que não sabe tudo (isto é, não é um egoísta narcísico).
Você é responsável por suas palavras e não deseja dar uma resposta imprecisa.
Você respeita a pessoa o suficiente para gastar parte do seu tempo ajudando a responder à pergunta dele.
Você é um cara legal :).

(E você tem tempo suficiente para descobrir isso).

Assemelha-se a uma antiga parábola :

Outras pessoas (geralmente) não esperam que você saiba tudo em seu campo. Em vez disso, eles esperam que você tenha ferramentas para pesquisar a pergunta e traduzir a resposta em termos que eles possam entender.

O velho engenheiro se aposentou e, depois de algumas semanas, a Big Machine quebrou, o que é muito importante para a receita da empresa. Como o gerente não conseguiu fazer a máquina funcionar novamente, a empresa convidou o antigo engenheiro como consultor independente.

Ele concordou. Chegando à fábrica, ele olhou para a Big Machine, pegou uma marreta e bateu nela uma vez. Depois disso, o carro começou a funcionar. O velho engenheiro saiu e a empresa começou a ganhar dinheiro novamente.

No dia seguinte, o gerente recebe uma fatura do antigo engenheiro por US $ 5.000. O gerente está furioso e se recusa a pagar. O antigo engenheiro garante que este é um preço justo. O gerente responde que, se esse é um preço justo, você pode solicitar detalhes da conta.

Uma conta nova e detalhada fica assim

: Martelo: US $ 5

Saiba onde o carro bateu com um martelo: US $ 4995

Qualquer pessoa pode pesquisar no Google qualquer pergunta. Mas apenas um engenheiro de software sabe quais palavras-chave usar e como interpretar os resultados.

achados

Normalmente, no meu blog, publico artigos puramente técnicos com toneladas de código, mas às vezes é útil lembrar que há algo mais neste mundo além do código.

Programadores (não sem razão) são percebidos como pessoas com habilidades sociais e de comunicação fracas. Mas uma parte significativa do nosso trabalho requer comunicação eficaz. Espero que minha experiência o ajude com alguma coisa.

Alguns podem considerar isso como "política de escritório" e manipulação das opiniões de outras pessoas. Aqui está o que vou responder:

Bem, sim. Mas isso não se aplica à maioria das interações interpessoais?

A psicologia simplesmente ajuda os programadores a falarem o mesmo idioma com os não programadores e a trabalharem juntos para alcançar um objetivo comum.

Falar é difícil. Ensaios sobre Comunicação com Não Programadores