Блог Хекслета

Специалисты Facebook обнаружили, что их боты общаются на новом языке. И остановили их.

Боб: “I can can I I everything else.”

Элис: “Balls have zero to me to me to me to me to me to me to me to me to.”

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

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

«Не было никакого смысла придерживаться английского», — говорит Дхрув Батра, инженер Georgia Tech из Facebook AI Research (FAIR). Учитывая то, что эти два агента конкурировали за лучший результат — это такая высокоэффективная схватка ИИ против ИИ — инженеры модифицировали «генеративно-состязательную сеть», и ни у одного из ботов не стало стимула общаться как люди. Поэтому они стали отклоняться от нормы и смешивать реальные слова в кажущиеся бессмысленными предложения.

«Агенты будут отклоняться от понятного языка и изобретать кодовые слова для себя», — говорит Батра, высказываясь в пользу уже предсказуемого явления, которое встречается тут, тут, и тут. «Как если бы я сказал «оно» пять раз, а вы бы поняли, что мне нужны пять копий определённого предмета. Это не сильно отличается от того, как сообщества людей придумывают сокращённые понятия».

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

Определение

Global mutable state содержит в себе три слова, каждое из которых имеет важное значение:

Global — значит доступный из любого места кода. Таким способом весь код связан. Необходимо рассуждать о взаимодействии всех частей программы, а не её маленьком фрагменте, потому что любая другая часть может касаться этого фрагмента.

Mutable — означает изменяемый (в русскоязычной среде часто говорят «мутабельный», — прим. ред.). Часто можно заметить: все, что может прочитать значение, может так же и изменить его. Два считывания данных, следующих одно за другим, могут возвращать разные значения. Или, что еще хуже, сами возвращаемые структуры данных изменяются после чтения.

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

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

Чего вам никто прямо не говорит, это — да, наняли вас за специфические навыки, но их важность постепенно угасает. Чем дальше вы продвигаетесь в карьере, тем меньше вас ценят за эти самые качества, а это особенно важно в середине карьеры. Почему? Потому что повышают вас благодаря другим навыкам.

Григорий Грудинин прошел все 4 проекта на Хекслете и рассказал о своем интересном опыте. Вот его история:

Всем привет! Хочу рассказать о своем опыте прохождения проектов. Сразу оговорюсь, что узнав о таком интересном нововведение, бросил свой почти законченный путь по стеку PHP и окунулся в мир nodejs. Сделал я это только по одной причине: проекты - это самое важное, что даёт этот образовательный ресурс. Можно долго решать какие-то задачки, проходить курсы, без этого никуда, но основной толчок в собственном понимании того, к чему всё это идёт, дают именно проекты. Признаюсь честно, после прохождения курсов по PHP, курсы по nodejs казались гораздо более продуманными, более ориентированными на новичка. Проходил их достаточно быстро (никогда не делал больше 1-2 шагов в день, иначе решение дается очень легко, но в голове ничего не остается), кроме нескольких довольно сложных моментов, на уроки по которым запросто могло уйти несколько дней, а то и неделя.

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

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

Начнем с плохого...

1. Работа никогда не заканчивается

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

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

Мы мечтаем о том дне, когда кто-то поблагодарит нас за безупречную работу в проекте и не потребует каких-нибудь "добавок".

Спецификации и требования — заранее, пожалуйста!

2. Люди (до сих пор) не понимают, чем вы занимаетесь

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

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

Интернет по первому же запросу предоставит вам 1000 и одну рекомендацию, как их писать и формулировать. Увы, обычно на одну рекомендацию даже от лучших ресурсов приходится количество воды, равное объёму олимпийского бассейна. Так что мы поговорим о самых общих, обязательных и полезных вещах, включение которых в сопроводительное точно не повредит.

Вы можете недостаточно хорошо вычитать резюме, но сопроводительное, не важно, на hh или отправленное на почту компании, должно быть вычитано идеально. Избегайте ошибок, поставьте красивые кавычки и тире вместо дефисов, или просто поставьте раскладку Бирмана и пишите красиво всегда.

Подсказка: Вычитайте резюме на предмет таких странностей, как «умею “гуглить”», - в умении ничего плохого нет, а вот в этих кавычках вверху - есть. Или Google как название компании и поисковика, или гугл как нарицательное для источника знаний и ответов на вопросы, забудьте про остальные вариации, не заключайте название компаний в кавычки, если речь не идет об ООО “Рога и копыта”. Если просто: у любой компании есть имя “по документам” (ООО “Рога и копыта”), и есть имя для печати и разговорной речи (Предприятие рогокопытных). Давно вы слышали, чтобы в разговоре без обсуждения документов название компании сочеталось с ООО? То-то же.

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

Зачем? Привлеките внимание, покажите заинтересованность в работе именно в этой команде и банальную внимательность к деталям, которая в IT никогда не бывает лишней. Заодно повысите число ответов и качество фидбэка, так как отношение HR’а может стать более личным.

Подвижка в сторону функционального программирования произошла, признаться честно, около десяти лет назад. Мы заметили, что языки вроде Scala, Clojure, and F# начали привлекать внимание. Это было больше, чем приычный энтузиазм — "О, круто, новый язык!". Было что-то выделявшее его, по крайней мере мы так думали.

Закон Мура обещал нам, что скорость компьютеров будет удваиваться каждые 18 месяцев. Этот закон работал с 1960 до 2000. А затем остановился. Вообще. Частота тактовых импульсов достигла 3Гц и перестала подниматься. Скрорость света была достигнута. Сигналы не могли проходить сквозь поверхность чипа настолько быстро, чтобы реализовать более высокие скорости.

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

Это перевод заметки Саймона Саута, оставленной в ответ на вопрос How do you know when someone is a good programmer? на quora.com

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

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

Привет. Уже давно хочу поделиться своими впечатлениями о проектах и о учебе в Хекслете в целом. К сожалению, обычно я никогда не прикладываю в деле особо много усилий. Лень сопровождает меня всегда и везде. И Хекслет не стал исключением. Но сначала небольшая предыстория.

До Хекслета у меня уже был небольшой опыт в программировании: начинал что-то делать на Perl, потом немного увлекся C++, а потом под впечатлением от успехов инди-разработчиков ударился в геймдев, писал на Monkey. Но увы, ни в одном из дел не добился успехов, а все потому, что не изучив до конца инструмент, начинал писать какой-то огромный проект мечты. При небольшой цели мне становилось неинтересно, в итоге вот я уже пишу мморпг с "корованами" и прочим, а это приводило к тому, что временами втыкал по несколько часов, не понимая что написал неделю назад. В какой-то момент пришлось честно себе признаться: либо я так и останусь самоучкой-недоучкой и буду делать свой проект до конца жизни (потому что месяцами не могу заставить себя сесть за свой говнокод), либо надо что-то менять, и пора ставить реальную цель. Так я и пришел учиться в Хекслет с целью устроиться на работу программистом.

В Хекслете с первых уроков мне понравился подход: акцент ставился не на конструкциях языка, а на саму суть программирования. Кажется, это был курс "Построения абстракций". Тогда еще не было совсем простых курсов.