“É hora de sair do front-end”: Andrey Sitnik sobre a estagnação da comunidade, código aberto e não apenas

Andrey Sitnik, do Evil Martians, é um dos nomes russos mais famosos no front end: seus projetos PostCSS e AutoPrefixer têm dezenas de milhares de estrelas do GitHub. Mas como Andrei vive em Nova York e viaja por todo o planeta, você raramente o encontra na Rússia.

Em maio, ele estará em São Petersburgo na conferência HolyJS, e Dmitry Dmitry Makhnev Makhnev e Maxim Yuzva, membros do comitê do programa HolyJS, perguntaram-lhe em detalhes sobre isso . Por que Andrei acha que o frontend está estagnado e o código de nossos projetos está muito inchado? Quais são as diferenças entre as comunidades de TI em diferentes países? Como aprender inglês e por que é menos importante do que parece? Onde o projeto Logux apresentado no HolyJS voltou em 2016?

Sobre projetos atuais

Dmitry: Primeiro, conte-nos brevemente sobre você - onde você está e o que está fazendo.

Andrey: Meu nome é Andrey Sitnik, moro em Nova York, mas tento viajar muito. Principalmente, eles me conhecem por código aberto e performances - como agora é popular dizer, "uma marca de mídia no campo da TI". Não posso dizer que realmente mereci, mas a sorte contribuiu para mim.

Além do código aberto, também promovo a diversidade linguística no Twitter @LinguoPunk , a Wikipedia no @LostInWiki e a luta pelo positivismo sexual.

Dmitry: Em quais projetos você está trabalhando agora?

Andrew: No código aberto existem vários projetos de suporte, os mais famosos são o PostCSS e o Autoprefixer. Talvez o PostCSS esteja agora ativando um pouco: Alexey Bondarenko fez uma atualização muito grande da API, portanto, poderá haver um grande lançamento em breve.

E o Autoprefixer está em versões de suporte. A única coisa que estamos vendo ativamente agora é o suporte do Grid para o IE 10-11, mas está indo mal por causa da resistência de Rachel Andrew, que estava promovendo ativamente o Grid. Ela é uma pessoa muito famosa e não gosta de nenhuma ferramenta que automaticamente faça algo em CSS - uma luta religiosa. E devido à sua oposição, esse recurso, infelizmente, não se espalhou particularmente.

Dmitry: Como Rachel pode impedi-lo de fazer um instrumento?

Andrew: A ferramenta não interfere em nada, funciona. Mas o código aberto não é sobre programação, o código aberto é sobre sociedade e socialização. Se ninguém usa o seu produto ou fala sobre mídia, não há motivação para fazê-lo. Como resultado, ele atinge a motivação dos desenvolvedores que o fizeram e continuam a fazê-lo. Poucas pessoas falam sobre seu heroísmo, mas ainda são grandes companheiros e verdadeiros heróis.

De fato, percebemos tudo o que queríamos e podíamos, há até uma ideia maluca com o suporte de grades automáticas, o que geralmente é impossível de ser feito com essa especificação, mas os caras descobriram como fazer isso usando uma combinação astuta de magia de seletor.

Em geral, o PostCSS e o Autoprefixer são suportados, raramente há recursos adicionados e principalmente pequenos, mas o Logux está desenvolvendo ativamente. E este ano eu quero dedicar mais a artigos do que a um projeto de código aberto específico.

Dmitry: Você disparou bastante, mas sobre o Logux após a apresentação no HolyJS em 2016, você realmente não ouve o que aconteceu com ele?

Andrew: Essa é uma boa pergunta, porque levanta um tópico muito interessante. O fato é que existem diferentes maneiras de distribuir software.

Usar código aberto não é algum tipo de tomada de decisão racional. O desenvolvimento de software é melhor descrito pela indústria da moda. A escolha técnica é, antes de tudo, moda, hype e coisas semelhantes.

Portanto, existem várias estratégias para promover novas soluções. Por exemplo, quando algo aparece, ele ainda não funciona como deveria, mas, devido ao medo de perder algo enorme, as pessoas rapidamente pegam um hype, começam a serrar e o colocam em condições de funcionamento.

De uma maneira boa, mais da metade dos projetos populares de código aberto foram escritos apenas nojentos. Em vez disso, o hype em torno deles é completamente inconsistente com a qualidade do código e o nível de suporte dos organizadores. Mas como muitas pessoas se sentaram no trem da moda imediatamente, o projeto sobreviveu e continuou a existir.

Por exemplo, os plugins Babel não têm assincronia. Você não pode criar funções assíncronas dentro de plug-ins, e esse é um problema terrível, não sei como ele entrou em produção, porque limita terrivelmente os enormes mercados de aplicativos Babel. Mas assim que ele foi escrito, essa é sua arquitetura. Babel se diverte muito.

Esta é uma maneira de se espalhar: dizer "tudo se foi, se você não aprender até amanhã - tudo, o mercado precisará de pessoas com três anos de experiência nessa tecnologia". Mas existe outro caminho. Por exemplo, no React, eles fizeram de maneira diferente: primeiro eles “cozinhavam” em seu ambiente e, em seguida, apresentavam um projeto que estava mais ou menos pronto para a produção. Obviamente, a questão em aberto é como exatamente ele estava pronto para a produção, mas é claro que as estruturas não estão 100% preparadas.

Logux é um sistema de comunicação cliente / servidor. A idéia de consultas, seja GraphQL ou Ajax, não se destina à Internet instável e funciona nessas condições apenas nojentas - esse é um problema conhecido da maioria dos sites. O Logux é uma abordagem diferente e, como resultado, é tecnicamente uma solução muito grande. A ideia não é nova, existem muitas dessas soluções, e elas falharam, e isso me preocupou. Até o GraphQL foi feito com um rangido terrível, e isso deveria ter ensinado algo.

Minha opinião é que o hype train não funciona para esse tipo de tarefa. Não podemos tomar uma decisão para que todos se choquem e tudo corra. Quando entregamos a solução imediatamente para o front-end e o back-end, as tentativas de levar tudo para o hype levam a um confronto entre as comunidades.

Portanto, decidi que com o Logux não faremos isso, mas iremos com cuidado e devagar, preparando-o dentro do projeto. Durante todo esse ano ou dois, cozinhamos o Logux dentro do Amplifer , usamos em diferentes projetos e observamos como os backders reagem. Eu tentei explicar, mostrar, e agora Dima Salakhutdinov irá ao Ruby-confu para falar sobre o Logux, para que possamos ver como eles reagem, como damos RP ao back-end. Como dizer a eles o que dizemos aos fornecedores de front-end, no espírito de "é hype", está errado, não funciona lá.

Dmitry: Por que não funciona?

Andrew: O back-end mudou para um sistema de estagnação ou suporte: nos últimos anos, praticamente não houve desenvolvimento. E, como resultado, eles têm prioridades diferentes: quando você não possui novas estruturas a cada seis meses, isso afeta você. Eles estão em algum lugar no Rust or Go, mas Ruby - o que há de novo? Como resultado, as pessoas estão focadas no outro. Obviamente, simplifico bastante e o back-end é diferente.

Quero distribuir isso corretamente no back-end e no cliente. Quero vir com uma solução pronta que realmente funcione, que realmente testamos na produção. Em 2017-2018, já tínhamos uma versão funcional do 0.2, mas não havia escalabilidade. Tínhamos uma idéia de como escalar e, para o PR, seria suficiente, mas na verdade está errado.

Em vez disso, lidamos com os problemas de escalabilidade real, e não teórica, quando é incompreensível para você e você não sabe em que momento. E no Logux, bombeamos seriamente o sistema: por exemplo, podemos facilmente aumentar o servidor em vários servidores ao mesmo tempo e com um comando para aumentar seu número.

Não faz sentido fazer isso até que você tenha análises reais. Porque sem ele você não entenderá onde conseguiu o plugue. Você pode escalar o quanto quiser, mas acontece que existe um lugar que não é escalável. Portanto, temos um código realmente pronto para o dimensionamento e um grande número de análises: quanto e quanto tempo é gasto, quantas solicitações chegam, é possível ver onde o plug é iniciado. Por exemplo, pelo número de operações por segundo ou pelo número de usuários, e tudo isso no servidor é resolvido de maneira diferente.

Dmitry: Isso parece interessante o suficiente. E, pelo que entendi, os planos são grandes o suficiente para o futuro próximo?

Andrei: Sim, já concluímos os planos de aplicação prática, agora lançarei o 0.3 e gravarei docas que não são suficientes para aplicação em massa. E o código é bom.

Sobre o Nano ID e a Internet rápida

Dmitry: Você tocou no tópico da conexão com a Internet: todo mundo está acostumado com o fato de nossa Internet ser estável e boa, mas, na verdade, tudo está completamente errado. E aqui é impossível não prestar atenção ao tamanho dos pacotes e outras coisas, lembre-se do seu Nano ID do projeto. Por que isso te incomoda tanto? Vamos começar com o tamanho.

Andrei: Não me parece que "economize em correspondências" quando todo mundo tem uma Internet normal? Boa pergunta

O Nano ID é uma biblioteca de 141 bytes que gera IDs. Quando reduzimos de 200 bytes, isso não fazia sentido prático, mas era um "manifesto político" que era hora de pensar sobre isso.

O tamanho do JS é uma questão interessante. Em primeiro lugar, os compiladores não o resolvem, mas vice-versa: a maioria dos bundlers combina incorretamente, aumenta significativamente o tamanho ou o usa de maneira ineficiente.

E o fato de que a velocidade das conexões à Internet está aumentando é verdade e, ao mesmo tempo, não. Assim que a Internet acelera, os países declaram estar onde está tudo muito ruim com ela - por exemplo, na África Central. E também novos mercados aparecem - por exemplo, móveis. E há um problema complicado: as velocidades de download estão aumentando, mas os sites não estão carregando mais rapidamente. Você pode verificar alguns LTE, que devem abrir tudo rapidamente, se você dividir o tamanho da página do site pela velocidade da rede.

O problema é que a velocidade real de carregamento do site depende de outros parâmetros. Por exemplo, o número de viagens de ida e volta . O fato é que, entre solicitações e os primeiros bytes, passa algum tempo inevitavelmente quando o sinal chega e retorna. Este tempo é muito longo, até 500 ms . Em primeiro lugar, devido à velocidade da luz, em segundo lugar, o equipamento é lento. E se os arquivos forem carregados um ao outro, o site ficará mais lento.

Felizmente, descobrimos esse problema há muito tempo e aprendemos como resolvê-lo. Mas ela não é a única. Recentemente, nos deparamos com outra: acontece que o problema não está na Internet, mas na velocidade da compilação. O fato é que é fácil baixar e exibir 1 megabyte de imagens, e 1 megabyte de JavaScript é 2-3 vezes mais pesado para o navegador, pois precisa ser compilado. E o número de JS está crescendo. E este é um problema objetivo de sites de baixa velocidade.

Você pode abordar astuciosamente a questão de estudar o site usando o método de entropia . Temos um site que pesa 1 MB. Existe o conceito de "quantidade de informação". Um megabyte não é apenas o número de linhas, é a quantidade de sentido contida neste código. E quão complexo um site deve exigir 1 MB? Existem realmente tantos casos de usuários no site que deve haver um volume de código tão grande para cobri-los?

De fato, esses casos são poucos. Há muito necessário no kernel do Linux, mas não em sites. E, portanto, temos um monte de código redundante.

O significado do movimento Nano ID não é salvar todos os bytes, mas pensar: “o que eu tenho no pacote? Que diabos estou tendo aí 1 MB? Não posso ter tarefas onde esse volume seria necessário. ” Na maioria dos sites, 75% do código não é usado. O Nano ID é um movimento contra o envio deste código aos usuários.

Quando começamos a pensar por que tanto código não é usado, entendemos que, se não for uma equipe enorme, um megabyte de código não poderá ser escrito manualmente. Isso é mais do que o convencional "Guerra e Paz", que pode ser escrito ao longo dos anos, e o código é muito mais difícil de escrever devido a interdependências.

E na maioria das vezes esse volume é de bibliotecas. A famosa história do Moment.js: você o conecta e, devido às peculiaridades da operação do webpack, ele carrega todos os idiomas do seu site . E há muitos casos semelhantes.

Ao mesmo tempo, eu precisava gerar um ID exclusivo no Logux, peguei uma biblioteca e descobri que ele pesa 100 KB. Por que preciso tanto para gerar um ID aleatório?

Esses tamanhos costumam ser devidos ao fato de que os desenvolvedores da biblioteca os escrevem incorretamente. Portanto, a idéia principal é usar o Limite de tamanho para que os desenvolvedores da biblioteca controlem o tamanho de seus projetos. Como o ESLint, apenas para o tamanho da biblioteca. E vemos imediatamente que um grande número de bibliotecas pode ser dividido pela metade.

Dmitry: Não lhe parece que a pergunta não é apenas sobre o tamanho do código, mas também sobre as abordagens das ferramentas de desenvolvimento? Se eu exportar minha biblioteca como um objeto em vez de funções individuais e não conectar o Google Closure Compiler por minha conta e risco, ninguém me cortará nada. O problema poderia ser mais profundo do que apenas escrever código?

Andrew: Eu não diria que o problema de cortar árvores é realmente relevante, porque não funciona em JavaScript. Todo mundo pensa que trichashing vai resolver o problema, mas não. O problema mais comum é diferente: o que o pacote está fazendo. Eles usam algum Rollup , empacotam o projeto inteiro em um arquivo e, por exemplo, as dependências são empacotadas. Esse é um problema enorme e, com a ajuda do Size Limit, reduzimos bastante uma biblioteca, porque removemos as dependências que provavelmente serão repetidas em cada projeto.

O segundo problema é que eles acidentalmente usam alguma API do Node.js. Por exemplo, havia uma biblioteca choo.js - “framework JS compacto”, onde eles checavam os argumentos recebidos usando a declaração do módulo Node.js. E ele carrega quase 4 KB. E por uma pequena biblioteca, enviamos mais 4 KB.

E esses problemas são muito mais comuns do que o uso de árvores.

A melhor recomendação para trishaking é dividir os arquivos na montagem, para que haja funções separadas em arquivos separados. Mas na maioria das vezes o problema é diferente. Basta executar o Limite de tamanho com a opção --why e ver a enorme quantidade de lixo que o webpack incorpora ao usar seu módulo.

Maxim: Acontece que usar o webpack para montagem é uma má educação?

Andrew: Observando o que falar. Se você criar uma biblioteca, provavelmente o webpack não será necessário. Você tem menos de 1% dos usuários que desejam um arquivo separado e, ao mesmo tempo, é melhor forçá-los a usar o webpack, porque eles inserem sua biblioteca como um link para outro arquivo e o site fica mais lento.

Mas do que os usuários coletam suas bibliotecas, do que as pessoas coletam sites - na verdade, não há diferença. No front-end, estamos acostumados a dizer que, se você usar a biblioteca incorretamente, tudo ficará mal; se você não mudar do Webpack para o Parcel hoje, tudo será um adeus, você é um desenvolvedor ruim. Não, para ser sincero, não se importe com as ferramentas.

Há muitos problemas com o webpack, este é um pacote ruim, mas se funcionar para você, então continue. Vi projetos em que ele ajuda a resolver problemas, apesar de ser um dos projetos mais abandonados. Por exemplo, o css-loader é suportado por uma pessoa da Rússia. Este é um verdadeiro herói, mas se ele estiver ocupado - é isso, ninguém resolverá o seu problema, mas há muitos problemas.

Se eu disser que você deve parar de usar o webpack, é apenas porque existem melhores coletores. Mas, novamente, tente um novo projeto e não mude no antigo. Nós nos masturbamos muito em estruturas e ferramentas, embora na verdade elas não afetem a maneira como criamos o código.

Por que o hype do trem e os aristocratas são ruins

Maxim: Você acabou de falar em evitar o webpack em favor de empacotadores mais legais. Talvez haja um problema no fato de que essas recomendações de pessoas do seu nível criam hype? Em vez de recomendar o uso de algo novo, talvez diga "vamos empurrar e tornar o webpack ótimo de novo"?

Andrew: Boa pergunta. Por um lado, há realmente um problema quando esses comentários são percebidos sem entender o contexto. Mas há outro problema: eu tenho medo da estagnação.

O fato é que o frontend está estagnado. Até o fim de nossas vidas, viveremos sob os auspícios do React - nem uma única estrutura nova poderá substituí-lo, porque a massa crítica é adquirida. É como nos idiomas de back-end: os idiomas antigos não são derrotados pelos novos, porque não há massa crítica, condições de transição, exceto em algumas tarefas limitadas. Agora o front end começou.

A estagnação de estruturas e sistemas de construção significa um grande problema: a estagnação das pessoas que nos ensinarão a viver. Vemos isso agora, porque as estrelas do front-end ainda são as mesmas e, como resultado, novas não virão. E estagnação de pessoas também significa estagnação de idéias. Vemos isso até agora por parâmetros indiretos, enquanto há inércia suficiente para trazer novas idéias. Mas você vem à conferência, e todos são iguais, e isso realmente me deprime. Na minha opinião, é hora de derrubar o mundo front-end.

É como o Java - um mercado enorme, onde tudo está bem, mas não há nada de novo. Como lidar com este problema - eu não sei. Mas essa é uma das razões pelas quais me afogo em pequenos projetos e os aconselho constantemente.

Honestamente, o webpack é muito difícil de reescrever, e seu criador não se importa com a qualidade do DX, ele o escreve por si mesmo e se comunica pouco com os usuários. Além disso, existem problemas de arquitetura que dificultam a reescrita. Existem pessoas na equipe do webpack que tentam honestamente fazer o bem, mas há dificuldades que nos impedem de fazer isso.

Existe uma comunidade e para onde movê-la - para estabilizar e adicionar ferramentas antigas ou usar novas - não tenho resposta.

Em um mundo ideal, não criaremos a sensação de que o uso de ferramentas antigas é ruim, mas usaremos novas em novos projetos. E não sei como criá-lo. De fato, as recomendações erradas são feitas e as pessoas começam a envenenar outras pessoas por usarem as coisas "erradas".

Maxim: Na sua opinião, é possível que grandes empresas como Microsoft e Facebook comecem a comprar grandes projetos de código aberto como webpack e Babel?

Andrew: Para comprar - não. Isso não é benéfico para eles, desde que a comunidade traga novas idéias e esse seja um benefício real para os negócios. Eles os controlam, funciona de maneira diferente.

Infelizmente, esse problema já surgiu no front end, mas não se expressa no fato de a empresa ter comprado algo, mas no fato de termos algumas estrelas que não mudam, elas sempre estarão no andar de cima e dirão como iremos escreva código. Eles se conhecem, é mais fácil se aproximarem e pedir que façam alguma coisa. Portanto, a opinião deles é mais importante que a opinião de outras pessoas. Este é um sistema clássico de criação de elites na sociedade.

Sem um sistema de elevadores sociais, isso leva ao fato de que as elites são conservadas, as idéias envelhecem. E o problema não é que as empresas os controlem, mas que temos um grupo muito pequeno de pessoas que decidem qual frontend teremos. O funcionamento do navegador é inteiramente determinado por um grupo muito pequeno de pessoas trabalhando no Chrome. Se o Chrome continuar a crescer em popularidade, haverá um grande problema.

— , . , - , : , . , , , , . , , .

: « » - , ?

: . , , — . , , [] . ?

: , . - , , - , .

: , . , — , , 37signals DHH .

, , , . , , , - . , , .

, . , IT .

DHH , , : , , , . , .

: . -, - - , , ?

: Vue.js. , React, , React. , : , .

« , , », , 20–30% . — . , , Google .

Google , , . , - Instagram Facebook, , , , . . , Vue : , React .

, Vue , . , , . — , , win/win. - .

, , , -, - , , , , - .

: , .

: . : , , -.

, — : , , . « ». , , , , .

-, , 99- . , Size Limit, , , , , Size Limit .

, : - , , , , , , . , , . .

. — « , Google», « , Google, , 99% ».

, , . , , . : , , .

, - pull request Babel, , - . , , — , .

, , - . , , . , .

— - . , PostCSS , , CSS-. Autoprefixer , Compass, , Compass , , , , Opera .

, , , . Accessibility, , URL, , . , — , . , , , Autoprefixer.

, , , , , , , .

: ? , , , JavaScript , , . , ?

: , , — , . — .

: . , , , .

: , , , , , . , . , .

- , … PostCSS , , . , , . - -, , , , , .

: ?

: , , .

: , , , ?

: , , , , - , , , , , . : « Open Collective , , ».

, . . . , , , . « , , . Open Collective, , . , , , ».

, Babel webpack. : « , . issue, Open Collective , ». , . , — . , , . , .

, , . -, issue, , maintainer, , , , . , issue, : «, , , . . , , ?» . , «», . , , .

: - , - ?

: . . , JavaScript , . , Ruby , JavaScript. . - , . , , JavaScript.

: , pet project . , , : , , -, , . , , ?

: - . , . , , .

« ». . , . , . — , , maintainer , , - .

, . , , . , , , issue, - , , , .

, ? . , , , . , , .

: , ?

: , . . . , .

: , , . , . , -, , . , , .

, . , 10, , , , , .

: , , ? , - : « , ».

: , , , . , . , . «» — , , — . , , - PostCSS. .

, - , . - : , , , , , .

— . , , , , , , . , . — , . , .

,

Dmitry: Você disse que o PostCSS ajuda a viajar. Quanto você viaja e como combina isso com o trabalho?

Andrew: Honestamente, o trabalho é ainda melhor. Acabei de chegar em Nova York depois de uma curta viagem. É uma jornada difícil, a Internet é ruim no Marrocos, é impossível trabalhar, mas, na realidade, eu fazia algo útil todos os dias: escrevia um artigo, criava dois sites usando uma técnica completamente nova.

Chegou em Nova York, sentada, assistindo ao YouTube. Viajo para trabalhar normalmente e com eficiência. Em um lugar, eu imediatamente me torno um waffle, deitado no sofá. Viajo para ser mais produtivo, por isso é fácil combinar.

A única regra: não pense que você será capaz de assistir em uma nova cidade, trabalhando, em um dia. Vem com uma margem enorme. Não pense que você andará por toda parte, você realmente trabalhará da mesma maneira. Você será um freelancer turco comum que acorda e trabalha, come na rua, trabalha, assiste a programas de TV e dorme. Se você não mudar de cidade mais de uma vez a cada duas semanas, tudo ficará bem. Não há problemas particulares.

Maxim: todo mundo entende que o conhecimento de inglês é necessário, mas não é tão fácil aprender bem. Você tinha um bom histórico? Onde você conseguiu um bom inglês?

Andrew: Você está rindo? Eu tenho nojento inglês. Estou abordando este tópico no Lingvopank. Estamos acostumados a estudar que a língua é a regra, especialmente com a cultura russa tóxica, onde constantemente criticamos pessoas diferentes. Estamos acostumados ao fato de que, se você diz e comete um erro, tudo está ruim.

De fato, a linguagem é um sistema de comunicação e, desde que você seja compreendido, tudo está bem. Não entendemos como a linguagem é um sistema duplicado. É como um CD ou um código QR. Você sabe que um código QR pode ser destruído em grande parte e ainda será legível? Porque existem algoritmos especiais para duplicar informações. O ponto é que você não precisa conhecer bem o idioma, precisa se comunicar nele.

Meu principal progresso na linguagem aconteceu quando parei de ter medo. Todos temos medo, porque somos constantemente intimidados na escola e na Internet - um péssimo twitter russo, onde eles nos culpam mais por erros de digitação do que por anti-ideias. De fato, os russos têm um bom inglês. Começando com o fato de que estes são idiomas intimamente relacionados: não um chinês, onde você geralmente tem um sistema linguístico diferente. Não podemos imaginar, como no resto do mundo, é ainda pior lá.

A Rússia está em um nível normal. Obviamente, pior do que a Noruega e países pequenos semelhantes que simplesmente precisam aprender o idioma, porque não há conteúdo. Mas o resto dos russos fala inglês bem, não há problemas. A regra principal é não ter medo, basta se comunicar, mudar para a linguagem de sinais, tomar um drinque antes da discussão (isso ajuda a entender que coisas simples são realmente importantes).

O segundo ponto - assista a séries com legendas, isso realmente ajuda.

Viaje, apenas aprenda o idioma.

E o mais importante - tente falar.

Temos medo do idioma, porque na Rússia há um problema: nos comunicamos muito pouco com o mundo exterior. Por um lado, isso é bom, pois existe um mercado interno que permite a saída de algumas pessoas pequenas. Como o Yandex cresceu fora do monopólio do Google devido à barreira do idioma, também há um grande número de elevadores sociais que um programador pode subir, o que nunca aconteceria no Ocidente.

Mas, em troca, há um problema de que o mercado está fechado, não olhamos para fora e todas as pessoas que se levantaram, caras muito bons, não vão para o Ocidente, porque têm medo do inglês. Minha recomendação é ter duas contas no Twitter, escrever em russo em uma para ajudar sua cultura (isso também é importante) e em inglês para praticar. Quando você escreve em inglês, entende que não é difícil. A única coisa é que poucas pessoas vão ler você, porque no Ocidente existem o suficiente, mas a massa crítica está aumentando de qualquer maneira, você ganhará entre 150 e 300 leitores.

Participe de reuniões de língua inglesa na Rússia, não é assustador, ninguém vai te ofender, está tudo bem.

Dmitry: Você recomenda tentar se mudar para algum lugar por um tempo para aprender o idioma? Se sim, onde?

Andrew: Para se livrar do medo, qualquer viagem é suficiente. Mas como aprender mais é uma boa pergunta. Sinceramente, não sei, não conheço bem o idioma. Mas posso dizer que quando você fala em uma manifestação em Nova York, mesmo que a platéia mal perceba seu sotaque, é a mesma coisa, porque metade da platéia da Índia, metade da China.

E eu posso dizer outra coisa. Na Rússia, há uma narrativa popular que precisa ser responsabilizada, e em todo lugar é bom: "Na Rússia, tudo está ruim, vou dar um fora e ser feliz". Honestamente - essa é a motivação que é melhor não ser guiada. Porque a narrativa é muito antiga e, historicamente, sabemos que ela não funciona dos séculos 18 a 19. Em outros países, não fundamentalmente melhor. Existem problemas fundamentais de gestão, mas mais cedo ou mais tarde eles aparecem em qualquer país.

Há um problema de escolha quando você tem uma tarefa, e ela é resolvida de maneiras diferentes. Por exemplo, queremos que a rua seja limpa e, para isso, precisamos de uma sociedade centralizada. Para fazer isso, é necessário oprimir todo mundo que pensa errado, como nos Estados Unidos. Existe um sistema muito rigoroso de regras e equilíbrios internos sobre quem deve pensar como e, de fato, os Estados Unidos nesse aspecto são semelhantes à China. As regras não são ditas e o Estado não faz isso - a sociedade faz.

Eu não diria que existe uma solução definitiva onde é melhor - onde as estradas estão quebradas ou onde a sociedade diz como você deve pensar. Mas essa não é uma solução binária, e é uma questão de política e sociologia. E o esboço geral: muitas vezes outros países são, de certa forma, melhores, porque em outros lugares piores.

É melhor não se mudar imediatamente, mas viajar pelo mundo, e então você perceberá que geralmente é importante o que você está disposto a dar para receber outras em troca. E com esse entendimento, você pode escolher o país para onde pode se mudar. E então se movendo normalmente.

Mas, para ser honesto, você não será feliz, porque a primeira onda de emigração é sempre experimentar um sofrimento terrível, ficar deprimido, depois de se mudar, você perderá todo o seu círculo social.

Dmitry: Gostaria de saber qual é a diferença na comunidade russa de desenvolvedores em outros países.

Andrei: Falando sobre os Estados, esta é uma situação interessante. Em primeiro lugar, existe realmente um sistema rígido de impor uma filosofia. Ela sempre foi, eles têm um rigoroso sistema de punição, por exemplo, assédio público. Mas o sistema é bastante antigo e, em geral, funciona. Honestamente, por outro lado, ela costuma usar as idéias certas para se propagar, e as erradas, bem, excessos no terreno.

A idéia principal é que exista um pensamento muito estereotipado na cultura, a fim de disseminar rapidamente boas práticas. Lá, um grande número de programadores não comete erros estúpidos, porque todos foram instruídos a escrever assim, todos escrevem assim. Em vez disso, é muito difícil promover suas idéias.

E existe uma cultura especial de conversa fiada - o bullying por idéias erradas cria tensão social, e nos EUA há um grande número de nações, e eles não sabem como conduzir tópicos conflitantes de comunicação sem fazer bullying, então eles têm uma lista de temas de interrupção.

Essa é a diferença social mais importante na comunidade. Das vantagens - eles são fáceis de escalar e realmente cuidam para que as pessoas não sofram. Você vem, todo mundo é amigável, está tudo bem, desde que você seja uma pessoa comum que cumpra as regras.

A segunda característica interessante é que eles costumam pagar por mitaps, um preço simbólico de 5 a 10 dólares que vai para a comida. Mais uma vez, porque capitalismo.

Dmitry: E se não os EUA, mas outros países?

Andrew: Em segundo lugar, pelo modo como estudei a comunidade, essa é a China. Há um recurso interessante em um grande número de desenvolvedores e, por outro lado, eles têm um formato interessante - muito pouca rede. Geralmente é fechado, você é convidado para um "café da manhã especial", que acontece com os líderes da comunidade. Por outro lado, as pessoas nas reuniões realmente falam sobre tópicos complexos e absorvem novos conhecimentos. Honestamente, todos esses recursos não são uma estrutura. A comunidade é diversa e há anarquistas suficientes na China; nos Estados Unidos, um grande número de pessoas também cuspiu em proibições. Bem, na Rússia há críticos hospitaleiros, educados e bons, não mesquinhos.

Outra característica interessante da China é que elas estão fechadas, com um mundo separado, isso é um mais e um menos. Eles têm uma quantidade enorme de conquistas, porque há um lugar onde eles podem se desenvolver. E, por outro lado, sofrem terrivelmente com o fato de não poderem levar adiante seus desenvolvimentos, como na Rússia. Todos os principais falantes de chinês têm medo de falar inglês com a palavra "geral", embora normalmente falem inglês.

Em seguida é o Japão. Apesar de ser um país de computadores, uma superpotência com tecnologia avançada, a programação é considerada pior que a administração. Acredita-se que, diferentemente dos gerentes, a programação tenha pouco trabalho: eles contaram à pessoa e ele escreveu o código. Como resultado, não há comunidade, e a TI é desenvolvida de maneira terrível, as startups são desenvolvidas incomparavelmente piores que as capacidades do país. Não há Vale, "gênios-programadores", isso é tudo. E há muito menos mulheres em TI do que na China, por causa da sociedade tradicional. Na China, está tudo bem com isso - há muitas mulheres chinesas com visões e experiências interessantes, embora também haja espaço para crescer.

Existe uma boa comunidade brasileira. Os países hispânicos não o têm, pois todos estão orientados para a América. A França também tem uma boa comunidade interna.

Mas no Sri Lanka, tudo é muito ruim com a comunidade de TI, porque quando eles se casam com uma garota, na maioria das vezes através de sua família, seu pai pergunta: "Com o que você trabalha?" E há uma lista branca de profissões "certas" e os programadores ainda não entraram nela. Portanto, existem muito poucos programadores, embora haja muitas vantagens em potencial: dinheiro, possibilidade de imigração. Um bom pai gostaria que ele entregasse a filha em boas mãos, mas isso não acontece, porque a lista ainda não foi atualizada.

Aconselho que você fale em conferências chinesas e indianas: é fácil chegar lá (eles aceitam com prazer uma pessoa de fora), e você pratica em inglês em um ambiente em que não tenha medo, porque ninguém realmente sabe inglês e todo mundo fala com erros.

Conferências ideais

Dmitry: Se falamos sobre conferências, qual é o fator decisivo para participar como palestrante?

Andrew: Para mim, o fator decisivo é a disponibilidade de conferências. Embora, às vezes, se meu caminho percorrer alguns países, concordo em conferências que não são muito acessíveis para as pessoas, apenas para elaborar o relatório.

Eu acho que há um grande problema que os preços das conferências são muito altos. Entendo que as conferências precisam ganhar dinheiro, não há problema com isso, mas existem alguns JSConf que custam US $ 500 fabulosos e, francamente, eles gastam em coisas que podem ser salvas. Por exemplo, para jantares, a festa mais poderosa, embora eu, francamente, prefira beber uma cerveja desagradável, mas para que haja pessoas interessantes.

E os enormes preços levam ao fato de que os palestrantes não estão interessados ​​em se comunicar com o público, às vezes é difícil apoiar o assunto, pois na conferência apenas funcionários de grandes empresas, o mesmo criador da melhor implementação JS do CRDT Viktor Grishchenko, não puderam vir, porque um ingresso muito caro. Existem várias maneiras de economizar e elas precisam ser aplicadas, pois os bilhetes caros estão errados. A conferência deve estar acessível.

Costumo concordar em ir a uma pequena reunião, apenas para que todos tenham acesso normal à rede. E em muitas reuniões, o diálogo é melhor do que em conferências com um alto preço de ingresso. Esta é a minha abordagem.

Dmitry: Sem o que uma conferência não pode ser boa? Já está claro sobre rede, acessibilidade e o que mais?

Andrei: Bem, como palestrante, eu realmente aprecio quando há um cronômetro na frente do palco. Nesse sentido, no HolyJS tudo é muito profissional, gosto da organização das performances. Em geral, o networking é uma coisa importante, as pessoas vão a conferências não por conhecimento, é mais fácil ler um artigo do que um relatório, mas por um sentimento de pertencer à comunidade.

Comunidade é a coisa mais importante que acontece em conferências. A sensação de que você está falando, e algo mudou em você, você sabe alguma coisa. Há uma boa ideia de que nossa sociedade não tem uma compreensão do "porquê". Vamos a conferências para entender por que fazemos tudo isso. E uma boa conferência provavelmente resolverá esse problema.

Dmitry: Você disse "não pelo conhecimento", esta é uma questão muito controversa. Você participaria de uma conferência na qual se reunisse uma coleção de pessoas com tópicos muito básicos, mas de comunidades muito diferentes?

Andrei: Sim, claro, isso seria muito divertido.

Dmitry: E seria mais interessante do que uma conferência onde existem relatórios sérios e poderosos?

Andrei: Eu acho que as duas abordagens são boas e não há problema aqui.

Dmitry: Provavelmente a pergunta final. O que você espera do HolyJS?

Andrew: Boa festa! Em 2016, foi creditado diretamente, um dos melhores da minha vida, e então tudo foi muito bem organizado.

Dmitry: O que você recomendaria fazer desta vez para torná-lo ainda melhor? Desejo uma festa?

Andrew: Eu tentaria me organizar com as mitaps locais. Temos muitas reuniões locais, e fica muito legal quando eles têm a oportunidade de fazer algo por conta própria - há muitas pessoas de iniciativa, você precisa dar a elas a oportunidade. E seria legal se os organizadores de todos os comícios locais ou seus principais oradores recebessem um ingresso gratuito ou algum tipo de ajuda, isso seria ótimo.

No HolyJS mais próximo (São Petersburgo, de 24 a 25 de maio), Andrei falará mais sobre a promoção de projetos de código aberto. E além dele, haverá muitas outras figuras significativas do código-fonte aberto do JS: de Ryan Dahl (Node.js, Deno) a Michel Weststrate (MobX, Immer). Todos os detalhes sobre os tópicos dos relatórios estão no site , os ingressos podem ser comprados no site e, gradualmente, ficam mais caros.