Посетителям сайта stackoverflow.com был задан вопрос: «Какие программерские термины вы придумали, так чтобы они стали популярны в ваших кругах (то есть вы слышали, что кто-то их повторяет)?

Ниже — вольный перевод самых популярных ответов.

Само наличие психологической деформации у какой-либо профессии, как правило, достаточно спорный момент ввиду того, что у разных людей она проявляется по-разному. Однако общую тенденцию можно выделить и, пожалуй, настало то время когда можно достаточно смело говорить, что программисты всё же имеют свой особенный психологический портрет который обусловлен их профессиональной деятельностью.

Я достаточно часто сталкивался с подобным мнением и не придавал ему особого значения, но когда женский коллектив нашей организации поздравил программистов с 23-м февраля по доброму назвав их «космическими войсками», решил всё же расставить определенные акценты в данном вопросе, т.к. одна из моих профессий связана напрямую с психоанализом. Да и баш уже не молчит.

Знаете, когда читаешь публикации в СМИ насчёт очередных особенностей очередного поколения молодых людей, начинает казаться, что мир катится в пропасть. Все эти фразы про молодёжь, которая не умеет работать, не признаёт авторитетов и скоро погубит мир, свежестью своей мысли заставляют вспомнить глиняные таблички времён Хаммурапи.

Чушь. Познакомьтесь с поколением Z. Они скоро станут вашими коллегами, подчинёнными и даже начальниками. Они обычные люди, просто получившие смартфон раньше, чем научились читать. Умные, целеустремлённые, образованные. Да, они не жгли тряпки на заброшенной стройке и не ели муравьёв в песочнице, но зато многие из них уже успели собрать свой первый школьный проект на Arduino и вовсю осваивают 3D-печать.

Эта тема всё больше нервирует рекрутеров, которые ещё не совсем понимают, как правильно их нанимать, и руководителей, которые не уверены, что получится ужиться с этим поколением. Всё не так страшно. Я хочу рассказать немного больше о социологических аспектах поколений. А ещё попробуем понять, почему бывает так сложно работать с центениалами, и как направить их творческую натуру на благо компании.

Привет, Хабр! Представляю Вашему вниманию перевод статьи «JavaScript in 3D: an Introduction to Three.js» автора Брета Кемерона (Bret Cameron).

Введение

Three.js это мощный инструмент. Он помогает использовать 3D дизайн в браузере с приемлемой производительностью. По началу Three.js может быть сложным, особенно если вы никогда не погружались в мир 3D программирования ранее.

У меня есть базовый опыт работы с игровым движком Unity и C#, но все равно многие концепции оказались новыми для меня. Я пришел к выводу, что сейчас совсем мало ресурсов для начинающих разработчиков, поэтому я и решил написать эту статью. В ней мы рассмотрим основные элементы Three.js сцены от полигональных сеток и материалов до геометрии, загрузчиков и много другого.

Привет, меня зовут Серёжа, мне 31 год, я живу в Брянске — и это точно не технологическая столица мира. Первая за десять лет ИТ-конференция прошла в нашем городе в этом октябре, а названия местных компаний, за исключением пары федеральных аутсорсов, едва ли что-то вам скажут. Тем не менее живя в самой настоящей провинции, я смог выпустить ряд книг по программированию (и они даже приносят доход), стать гостем зарубежных подкастов и начал как докладчик выезжать на различные конференции.

Нет, это не история о том, какой я уникум. Несколько лет назад я не знал, что такое SOLID — и на просьбу расшифровать аббревиатуру честно спросил: “А что это?”. Много лет я плыл по течению, пока не осел в уютном “болоте”. Но потом очнулся и, кажется, за несколько лет смог выбраться на твердую землю. Не повторяйте моих ошибок)



Надеюсь, что-то из моего опыта вам пригодится (решения простые и не требуют много сил и вложений). А еще очень хочу, чтобы другие ребята, которые смогли расти, не уезжая с малой родины, поделились своими советами в комментариях.

Как начать деградировать, но не поддаться

Поддержка технологии WebAssembly (Wasm) появилась в браузерах относительно недавно. Но эта технология вполне может серьёзно расширить возможности веба, сделав его платформой, способной поддерживать такие приложения, которые обычно воспринимаются как настольные.

Освоение WebAssembly может оказаться непростым делом для веб-разработчиков. Однако ситуацию способен улучшить компилятор AssemblyScript.

Автор статьи, перевод которой мы сегодня публикуем, предлагает сначала поговорить о том, почему WebAssembly — это весьма многообещающая технология, а потом — взглянуть на то, как AssemblyScript может помочь в раскрытии потенциала Wasm.

Прошло примерно 18 месяцев с внутреннего релиза Deno, вышел preview release, появилось несколько статей на Хабре, и Райан ездит по конференциям и рассказывает о нём. Однако я нигде так и не видел сколько-нибудь вдумчивого разбора этого проекта — почему-то все ограничиваются переводом документации...

Что же, давайте попробуем это сделать сейчас. Последние 5 лет я пишу на Node.JS, а компания OneTwoTrip, где я сейчас работаю, пишет проекты на ноде около 9 лет (да, это я писал историю про 9 лет в монолите на ноде). Так что анализ должен выйти неплохой. Тем более что я его уже рассказал на Moscow Node.JS Meetup 10, и было интересно. Кстати, если вам удобнее слушать, а не читать, то послушать и посмотреть можно вот тут. Моё выступление второе, я чувак в розовой рубашке.

Дэвид Хэррон, автор материала, перевод которого мы публикуем сегодня, задался следующим вопросом: «Должен ли человек, работавший более 10 лет в Sun Microsystems, в команде Java SE, до последнего вздоха думать лишь о байт-коде Java и создавать экземпляры абстрактных интерфейсов?». Он задавал этот вопрос применительно к себе, и для него платформа Node.js, после Java, оказалась подобна глотку свежего воздуха. Дэвид говорит, что когда он был уволен из Sun в январе 2009 года (прямо перед поглощением этой компании Oracle), он узнал о Node.js. Эта технология его зацепила. Что значит «зацепила»? С 2010-го года он много писал о программировании для Node.js. А именно, написал несколько книг, в том числе — «Node.js Web Development», четвёртое издание которой вышло в этом году. Он подготовил множество небольших материалов о Node.js, опубликованных в интернете. Фактически, он уделил очень много времени и сил, рассказывая о платформе Node.js и о возможностях JavaScript. Почему того, кто раньше занимался исключительно Java, так увлекли Node.js и JavaScript?

Слово «бренд» часто связывают с материальной выгодой. HR-бренд позволяет эффективнее нанимать, а личный бренд — наниматься. А еще у личного бренда есть одно неочевидное преимущество, которое никак не связано с качеством/посылом/стратегией личного бренда. Неважно, знают вас как щепетильного перфекциониста или любителя хайпа, вы получаете свои плюшки и становитесь лучшим программистом.



Под катом бытовая нейрофизиология для айтишников и традиционно ошибающийся здравый смысл.

«Извини, кажется, мне надо было раньше это сказать – я столкнулся с депрессией». Такое письмо мне пришло утром от одного из сотрудников, который уже пару дней не мог закрыть несложный тикет.

Контекст: работаю тимлидом в крупной корпорации, в подчинении – удаленная команда из 50 человек (территориальный разброс — от Нью-Йорка до Токио). Столкнувшийся с депрессией сотрудник – мой ровесник (+- 30 лет), работает на этом месте 5 лет. Один из лучших членов команды, стабильно показывает отличные результаты, с мотивацией проблем ранее не было. Рабочий день – ненормированный: то густо, то пусто.

Нет, это не профессиональное выгорание. Работа его всегда драйвила, ничего в ней менять не хочет (ни локацию, ни команду). «Ищу терапевта».

Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.

И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.

Итак, поехали

Статьи о дистанционной работе часто рисуют картину с коктейлями на пляже, путешествиями по миру и другими наслаждениями, вызывая зависть в социальных сетях. Эта статья не такая.

Кто везде — тот нигде. Кто проводит жизнь в странствиях, у тех в итоге гостеприимцев множество, а друзей нет.

Сенека.

В 23 года я расстался с девушкой, продал или раздал почти все вещи, собрал чемодан и забронировал билет в один конец на Тайвань. Я жил мечтой о путешествиях и абсолютной свободе, понятия не имея, что начинается самый несчастный период моей жизни.

Для протокола, прекращение долгосрочных отношений и уход от семьи, друзей и любых других значимых человеческих связей в мире — ужасная идея. Добавьте отсутствие баланса между работой и жизнью — и получите готовый рецепт депрессии.

Возникает такое ощущение, что буквально каждую неделю появляется новый «веб-фреймворк» для Node.js, который называют чем-то таким, что работает быстрее, чем всё, что было до него. Всем известно, что Express — это медленно, но способен ли очередной фреймворк по-настоящему улучшить производительность подсистемы ввода-вывода Node.js? Единственное, что он может — это устранить чрезмерную нагрузку на систему, создаваемую Express. Об улучшении чего-то фундаментального речи не идёт. Собственно говоря, для того, чтобы кардинальным образом улучшить ситуацию, нужно работать на более глубоком уровне, а не добавлять новые абстракции поверх Node.js.



Что нужно для того, чтобы на платформе Node.js можно было бы создавать серверные приложения, работающие гораздо быстрее чем всё то, что есть сегодня?

Я работаю с Реактом на протяжении почти 3 лет, использовал как Redux так и MobX и у меня к текущему моменту возник вопрос. Почему абсолютное большинство front-end разработчиков продолжают свято верить в то, что Redux + Redux Saga + Reselect + 100500 других библиотек «облегчающих» жизнь — это лучшее решение на сегодняшний момент? Я приведу 4 аргумента в пользу того, чтобы в следующем проекте вы использовали MobX вместо Redux.

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

Первая попытка

Все началось с того, что я люблю ходить по конференциям и частенько хожу на них в Яндекс, Mail.ru и другие крупные компании. Однажды мне написал HR из Яндекса и попросила сделать тестовое на стажера фронтенд-разработчика.

Я его сделала, вот оно. По условию оно должно было работать на айфонах и андроидах, поэтому я проверила его в Browser Stack и дописала пару префиксов и css-стилей.

Через какое-то время поняла, что не хочу быть стажером, имея несколько лет опыта за плечами и зааплаилась в Я.Маркет через форму на их сайте.

Мне позвонила HR и предложила пройти скайп-интервью с лайвкодингом. Перед собеседованием я повторила структуры данных, сложность алгоритмов, сортировки. Тогда я еще не знала, что этого недостаточно.

На интервью я не смогла решить алгоритмические задачки, не знала внутренности JS и меня сбрили.

Это задело мою самооценку и весь следующий год параллельно с работой я учила JS на глубоком уровне и решала задачки на codewars. Здесь можно оценить мой прогресс.

IT — не детский садик. Это место для взрослых, руководствующихся логикой и здравым смыслом. Их не надо опекать, не надо следить за словами, не надо переживать, что у них сформируются комплексы. Если человек некомпетентен, надо дать ему об этом явно понять, а не беречь его нежные чувства в ущерб всем остальным.

Так какого же чёрта моё прекрасное IT превращается в детский сад «Весёлый Програм-Мишка»?

С самого начала сентября широким потоком хлынули на Хабр публикации об успешном успехе на тему «Детство программиста», «Как стать программистом после N лет», «Как я ушёл в IT из другой профессии», «Путь в программирование» и так далее. Подобные статьи пишут постоянно, но вот сейчас они пошли как-то особенно кучно. Каждый день пишут то психологи, то студенты, то ещё кто-нибудь.

И в каждой статье звучит знакомая песня: главное, что советуют авторы — «стараться», «не сдаваться», «не бояться» и «идти к своей мечте»; а в комментариях очень часто можно встретить мнение, что ежели ты с самого детства любил компьютеры, то работа с ними в итоге неудивительна. Я хотел бы на примере своей биографии подвести читателей к мысли о том, что начальные условия могут быть важнее, чем приложенные усилия. Вера в справедливый мир способствует психологическому комфорту, но не очень-то корректно отражает реальность.

Привет, меня зовут Дмитрий, мне 35 лет. Раньше я часто слышал, что программист — профессия для молодых. Тем не менее прошлым летом я получил приглашение в Яндекс и перебрался работать в Москву.

В этой статье я хотел бы затронуть вопрос, который не раз обсуждался на Хабре: насколько реально быть программистом после 35–40 лет? Не ведущим архитектором, не тимлидом, не менеджером проекта, а именно программистом? Я не согласен с мнением, что программирование — это удел молодых. Считаю его вредным и сейчас расскажу почему.

Существует несколько доводов, на которые опирается этот миф. Давайте-ка их подробно рассмотрим.

Так уж сложилось, что последние несколько лет я занимал самые разнообразные руководящие должности в полудюжине компаний, занимающихся разработкой программного обеспечения разного рода. Довелось побывать и тимлидом, и менеджером проекта, и группы проектов, руководителем отдела и руководителем технического направления; подопечных бывало от двух до ста пятидесяти человек, да и размеры компании варьировались от трёх до двухсот тысяч работников. Неизменным оставалось только одно: чисто управленческая работа, постепенный и окончательный отход от технических задач.

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.