Комментарии 150
Это пахнёт постсоветским снобизмом, но некоторы не подаются в гугл потому что просто не хотят на галеру. Даже очень большую и с рестораном :)
Называть Гугл галерой весьма грубо. Это сейчас одна из лучших фирм для работы https://techcrunch.com/2021/01/12/glassdoor-best-tech-companies-to-work-for-in-2021/. Все мои знакомые, кто там работал или работает, весьма довольны и условиями труда и оплатой. Если вы там работали, поделитесь негативным опытом
Да. Гугл рулит, лучше Амазона. Но гугл любит пользоваться своим именем и занижать оклад на входе.
Откуда это? Вот средняя зп в гугле для синьора $358,000 в год https://www.levels.fyi/company/Google/salaries/Software-Engineer/L5/. Это огромная зарплата по меркам США
Классика ошибки выжившего и selection bias. Это одна из лучших компаний для тех, кто туда вполне сознательно решил устроиться, смог устроиться и остался.
Иллюстрация проблемы попроще. Оператор станка с ЧПУ может получать в Boeing в два раза больше, чем на соседней фабрике. Почему, тем не менее, не то что "не все", а только конкретные люди идут в Boeing? Потому что ты там - исключительно ответственный нажиматель кнопок. Нет, я не говорю, что в Гугле - то же самое, я говорю, что на основании того, что все, кто работает в Boeing операторами, сознательно сделав такой выбор, могут быть очень довольны всем, что им там полагается, нельзя делать выводы о том, что это "лучшая компания". Есть множество людей, которые и близко подходить не намерены, несмотря на все плюшки.
А вы, кажется, одной рукой занимаясь искоренением личного снобизма, заменяете его на групповой, идентифицируя себя с компанией-работодателем чуть сильнее, чем стоило бы.
Это правда, Гугл ищет людей, которые могут сами себя мотивировать и это подходит не всем. У меня знакомый работает в Dell над Spring и, хотя мог бы зарабатывать больше в Гугле или Фейсбуке, его абсолютно устраивает спокойная обстановка, в которой можно ничего нового не учить и никуда не торопиться. Но опять же, это статья для тех, кто активно развивается. Им больше подходит менталитет самомотивации
что значит работает над Spring?
Spring boot - популярный Фреймворк на Java
Мне всё сильнее кажется, что вы слишком сильно отождествляете себя со своим местом работы и превращаете это в культ. Потому что вы только что противопоставили Гугл, как "место для мотивированных" и "всех остальных", как места для ленивых и тех, кто не желает развиваться. В реальности это совершенно не так.
Да, для гугла нужно себя очень хорошо уметь мотивировать работать в условиях когда 95% твоего кода зачастую просто никому не нужны и уходят в мусорку и весь интеллектуальный труд сотрудника за пределами рабочего времени принадлежит компании.
Очень интересное мнение. Спасибо
Про боинг не скажу, а с локхидом работал. И нажиматель кнопки станка там - исключительно гайка, имени которой дальше тимлида никто не знает.
Более того, если вдумчиво посмотреть на организацию работы в крупной компании, на стандарты кода и документации, на жёсткие ограничения по инструментарию и тестированию, то становится понятно: не высочайшие стандарты качества являются целью, а возможность заменить тебя завтра другим Васей или Джононом, и чтоб в работе компании ничего бы не поменялось.
Например, в локхиде обязательным этапом сдачи изделия было моделирование в менторе. Это хорошо, но ментор, как любая тупая машина, не может распознать те или иные хаки. У нас был случай, когда блок не проходил тестирование на охлаждение. Причём, реальный прототип работал прекрасно, а ментор, в тех же условиях, показывал перегрев. Просто его модель не могла учесть решения, применённые разработчиками.
Пришлось сдавать худший вариант, который был менее оптимален, но проходил тест ментором. Потому что таковы стандарты компании и пришедший на твоё место Раджу Ситарама должен понять как оно работает.
Таким образом, тебе не надо быть специалистом и "видеть" процессы, делать уникальные вещи и т.п., тебе надо просто тупым перебором подобрать конфигурацию в менторе и запустить её в прод.
Поэтому реальные спецы долго там не засиживаются, получают строчку в резюме и уходят в стартапы, где и платят больше, и творить можно на всю котлету.
Насколько знаю, в гуглях история аналогична.
Есть один нюанс, на который мало кто обращает внимание: все, кто где-то работал, прошли несколько этапов отбора. Где профессиональные навыки составляют от силы 50%. Остальное - софт скилс, психотип и т.д. Поэтому ваше сообщение можно прочитать как "все члены КПСС любили Ленина, поэтому Ленин - классный".
В хорошем продукте даже джуниор может починить баг.Синьор в таком случае уже уволен.
«Куда тебе до крутых программистов, у тебя в школе по математике 3 было!». Интеллект, конечно, важный аспект успеха в любой работе, но далеко не последний. Умение сидеть долго над задачей или материалами не теряя фокус - гораздо важнее.
Просто царская оговорка. И очень иронично звучащая.
Весь пост прямо гимн восхваления говнокода, велосипедостроения и стиля фигак фигак и в продакшн :)
Как говорил Чацкий «А судьи кто?»
Позвольте, только после Вас
Вы судите о программистах по продукту, который приносит миллиарды долларов. При это React от FB самый популярный Фреймворк на фронтенде. И у вас, конечно же, есть такой же продукт, но без багов.
При это React от FB самый популярный Фреймворк на фронтенде
Ага, а ещё React «Native». К сожалению. К большому сожалению. Передаю привет всем перегретым телефонам и ноутбукам, летающим в стратосферу на своих вентиляторах. Мне плевать, кто сколько на чём зарабатывает, я хочу удобство и комфорт, а не знать, что Пейсбук заработал на мне и сокращении толковых разработчиков (и времени на разработку).
Вот так и работает монополизация. Популярное вовсе не означает качественное. Макдональдс тоже популярный и приносит миллиарды долларов (полагаю). Значит ли это, что там работают крутые повара?
Вы оцениваете уровень программистов основываясь на отзывах о продукте за который несет ответственность менеджмент. Не будем забывать что задача менеджмента как раз управлять процессом и нести ответственность за конечный продукт.
За баги тоже несет ответственность менеджмент? А программисты все в белом?
Менеджмент выбирает себе команду, менеджмент оценивает сложность работы, сроки и состояние продукта. Баги связаны с тем что сроки, компетенции или задачи были неправильно запланированы и распределены.
Оценка компетенций специалистов это важная задача.
Так откуда вообще вывод о высокой квалификации именно разработчиков? Продукт приносит миллиарды? Так это менеджмент молодцы, смогли при помощи такого говна денег заработать.
Я тут слегка упрощаю, но надеюсь мысль мою можно уловить? Да, качество продукта — результат общих усилий. Ну в таком случае просто работу программистом в фейсбуке нельзя заранее считать достижением (кроме зарплаты, конечно), а точнее показателем высокой квалификации.
Если вы считаете, что у продуктов Фейсбука плохое качество, то сдается, что вы не видели продуктов действительного плохого качества. Либо это из серии "Ах, они же считают себя элитой, тогда возьмем любые мелкие недочеты и раздуем их уровень до критических ошибок, мешающих использовать их ПО, дабы корона череп не жала".
Но в общем, да, они реально считают себя элитой — и для элиты качество прямо скажем не впечатляет.
Ну и вопрос в общем стоял немного в другой плоскости — можно ли считать, что человек, просто устроившись в фейсбук, уже заведомо имеет высокую квалификацию, просто «потому что потому»? Да, продукт приносит кучу денег — но это не результат работы только программиста. Да, в продукте куча недостатков — и это тоже может быть вина не только программистов.
Низкоквалифицированный Вася с улицы туда просто не пройдет. Не просто так же придумали эти многоэтапные собеседования с алгоритмическими секциями: понятно, что эти алгоритмы в массе своей не потребуются в ежедневной работе, но тот факт, что человек виртуозно вертит красно-черные деревья, говорит о том, что человек обладает глубоким алгоритмическим мышлением, целеустремлен, поддерживает скиллы в тонусе и точно не окажется бесполезным раздолбаем, который потянет проект и команду вниз.
А откуда тогда баги в ужасных количествах? Кстати, мой опыт мне подсказывает, что наличие «глубокого алгоритмического мышления и целеустремленности» в общем случае не дает на выходе качественный продукт само по себе. Просто потому, что это еще не все, что нужно для его получения. Ну т.е. да, это желательные свойства — но не все.
Сложность продукта, недостаточное тестирование, потенциальные выгоды от раннего запуска фич - причин может быть много.
В общем, я просто хочу сказать что — вот представим себе, что завтра ко мне пришел наниматься разработчик из Фейсбука. Какие у меня причины подойти к нему на интервью более лояльно, чем к любому другому человеку, с которым я не знаком и вместе не работал? На мой взгляд — никаких. Даже более того — если я знаю, что этот человек приложил руку к проекту, который мне знаком как пользователю, и вызывает вопросы по качеству — наоборот, это будет повод поспрашивать такого человека более пристрастно. И не потому, что другие продукты без греха, а потому, что его произведение — на виду у всех. Да, скорее всего он не «Низкоквалифицированный Вася с улицы». Ну так и вопросы скорее всего будут не такие, как для Васи.
>Низкоквалифицированный Вася с улицы туда просто не пройдет. А откуда тогда баги в ужасных количествах?
просто: берем нанимаем крутого питониста Джона, садим разрабатывать плюсовый проект, удивляемся как человек, уверенно победивший алгоритмические секции, допускает простые ошибки на едва знакомом ему языке
ну учитывая что современному плюсовику крайне не рекоммендуется пользоваться ни первым, ни вторым (имеются в виду просто сырые массивы, даже без VLA), то я даже не уверен, что это прям грандиозный минус кандидату.
Хотя в таких случаях я бы скорее перепроверил что собеседование проходил тот же человек, что вышел на работу.
Дело там не в багах.
Мне тоже раньше казалось, что юзабилити инстаграмма ужасно кривое.
Но потом меня посетила мысль, что эта "кривость" сделана специально, с целью задания формата поведения пользователя.
Я бы сказал это про эффект Даннинга - Крюгера. Что бы понять насколько в ИТ важны знания, опыт, и интеллект, нужно каждый день сталкиваться с задачами на которые не хватает скилов. И тебе и коллегам.
Время не бесконечный рессурс. Я бы даже сказал что скорость решения задач и определяет требования к опыту и знаниям. К сожалению, очень много "специалистов" считают что все что нужно они могут загуглить. Для сложных задач, построения архитектуры работает только вариант загуглить у себя в голове, иначе пальцы в строке поиска печатать не успеют.
Останусь при мнении, что именно хорошему ИТшнику нужен хороший и интеллект, и опыт, и знания. А смелость, только на уроовне чтоб на звонок рекрутера ответить))
У меня нет цели обесценить опыт и знания. И я писал, что интеллект необходим. Но опыт и знания можно получить, а любовь к написанию кода - вряд ли
Это прекрасно, если кто-то искренне любит свое занятие или просто находит в этом удовольствие. Однако, это не является необходимостью для того, чтобы просто хорошо делать свою работу. Как правило, люди, которые имеют хорошие знания (получение которых требует терпения) способны отлично делать работу просто потому что "это их работа". А вот с теми, кто имеет к работе эмоциональную привязанность, могут быть разные проблемы вроде необходимости постоянно "освежать отношения" новыми более интересными задачами. Вот где-то по этой причине и происходит большинство нарушений принципа "работает - не трогай" и постоянное переписывание того, что не нужно менять. Потому что работа делается ради удовольствия, а не ради полезного результата.
Так что давайте не обожествлять "любовь к работе".
Компания ценит смелых? Пишем и заучиваем историю, где мы были смелыми.
Это точно про айтишников?
Нужны алгоритмы? Учим алгоритмы.
Всего лишь выучить алгоритмы.. Пару вечеров посидеть за книжкой, делов то..
Можно ещё один миф разрушить. Чтобы пробежать марафон, не обязательно быть крутым спортсменом. Достаточно просто хорошо подготовиться.
Я рад, что для вас очевидно, что к интервью надо готовиться. Но я не раз сталкивался с людьми, которые так не считают. Они считают, что их опыт и знания и так должны говорить о себе.
Привет. Мне 34, занимаюсь IT с 2002 года, идти работать в фейсбук не имею ни малейшего желания, есть куча более интересных мест. Не готовлюсь к интервью и считаю, что мой опыт и знания и так говорят о себе. Без проблем устроился на крутую работу. Рекомендую почитать про эффект Даннинга-Крюгера.
Ого! Поделитесь, что это за места, пожалуйста. Пока что в Фейсбуке для меня наибольшая зп, отличный соц. пакет и отличные условия труда. Любопытно, где лучше и по каким параметрам
И сколько нужно отработать в Фейсбуке, чтобы купить домик в Штатах?
у меня одного впечатление, что единсьвенный смысл и посыл написания статьи автором - многократно и во всеуслышание прокричать: " я в Фейсбуке, лошары! А вы - нет!" ?
А я с большинством тезисов автора в общем-то согласен.
Он не написал, где работал до переезда, но в 2016 я наблюдал в крупной российской компании, когда "крутостью" разработчика считалось написание именно сложного (а потому и не поддерживаемого остальной командой) кода.
Т.ч. на самом деле все зависит от зрелости компании, думаю, что все еще полно мест с "уникальными" разработчиками, в коде которых могут разобраться только они сами.
Без проблем устроился на крутую работу.
Осталось выяснить, что вы считаете крутой работой.
К примеру, если вы пишите ПО для самолетов/ракет/спутников/марсоходов - это, с моей точки зрения, круто. Так же круто для меня смотрится написание компиляторов и SDK, виртуальных машин, ядра ОС, IDE, баз данных, базовых фреймворков(Spring, Actix, .NET core, Netty).
На всякий случай уточню, что крутая работа не обязана оплачиваться высоко и оплата не является критерием крутости для меня.
Но вот ваше определение крутой работы было бы неплохо узнать, чтобы более конструктивно задавать вопросы.
Ну, меня в SpaceX звали, но я не захотел, потому что там на работе надо жить и зп низкая. Я руководствуюсь общественными данными, например, вот https://techcrunch.com/2021/01/12/glassdoor-best-tech-companies-to-work-for-in-2021/. Тут список ИТ компаний, в которых лучше всего работать в этом году
Рейтинг без описания методологии и следование рейтингу без описания методологии - это как-то совсем антинаучно.
Там описана методология в статье. Рейтинг гласдора - самое точное, потому что основан на отзывах людей.
Э... отзывы людей - это и есть confirmation bias, survivor bias, selection bias - все три вместе взятые, так что если что-то и может быть менее точным, то мне такой метод неизвестен.
Это спор ради спора? Bias как раз и снижается за счёт количества, которое на гласдоре самое большое. Я предоставляю ссылки, метрики, а вы мне просто говорите, что вас эти данные не устраивают. Ну, я с этим поделать ничего не могу. Для меня всегда данные на гласдоре совпадали с моим опытом и опытом моих знакомых
Нет, мне просто любопытно, в какие дебри вы забрались в смысле дремучего непонимания, как работает статистика и социология. Речь не о том, что эти данные меня не устраивают, а о том, что соц. опрос о том, что думают люди об одной компании имеет смысл, так как они находятся в одном контексте, а вот результаты опроса по разным компаниям сравнивать - это уже какой-то заведомый антинаучный бред (особенно про улучшение результата через увеличение выборки).
Объясню на пальцах, на примере. Опросим сто людей, которые переехали в город с теплым климатом из холодного и сто людей, которые переехали в более холодный климат из-за жары. В результате, может оказаться, что среди первых больше довольных переездом, чем среди вторых. Или наоборот. Говорит ли это что-то о том, что в одном из этих двух типов климата жить лучше вообще? Нет, не говорит, потому что это разный выбор.
Это не соц опрос, а добровольные отзывы людей, которые там работали или работают. Это как отзыв о товаре на Амазоне. Если отзывов много и они в основном хорошие, то, скорее всего, и товар хороший. Ну, можно конечно послушать человека выше и сказать «я не хочу работать на галере», но на что спорим, что он там не работал, а я лично сравнивал отзывы на гласдоре с мнением людей, которые там сейчас работают или работали.
Вообще у каждого может быть свое мнение об этом. Разное.
>На всякий случай уточню, что крутая работа не обязана оплачиваться высоко и оплата не является критерием крутости для меня.
Согласен. При этом репутация компании (Фейсбук как раз хороший пример) — для меня таким является.
Осталось выяснить, что вы считаете крутой работой.
Разрабатываю видеоигры для ПК и консолей. Но дело не в этом. Вы (как и я) смотрим на _суть работы_.
А ценности автора - "наибольшая зп, отличный соц. пакет и отличные условия труда".
Но вот ваше определение крутой работы было бы неплохо узнать, чтобы более конструктивно задавать вопросы
Без какого-либо определённого порядка, крутая работа обеспечивает:
Возможность влиять на принятие решений, гибкое выполнение задач. Из экстремальных случаев - бывало, уговоривал геймдизайнеров что на самом деле они *не хотят* ту фичу, которую заказали
Ценность написанного софта для меня же. В написанную игру можно взять и поиграть.
Возможность профессионального роста "вширь". Занимался и базами данных, и контейнерами, и чинил рендер на PS4, искал утечки в Java-сервере, писал AI, клиентское предсказание поверх UDP, билд-скрипты для CI, отправлял патчи в Git, всего уж и не вспомню.
Возможность творить. Когда уходишь в состояние потока на пару дней, а потом вылезаешь оттуда с чувством что только что сделал классную вещь.
Возможность роста вверх. Увеличение и ЗП, и ответственности, и полномочий для принятия решений.
Коллеги, которые тоже разделяют эти ценности.
Возможность заниматься opensource-проектами
Вещи, которые я считаю само собой разумеющимися: производительное железо, удобное рабочее место, кофе-печеньки
Я конечно читал и про алгоритмы разные, и про методы фреймворков, и про паттерны, и про архитектурные подходы, и про прочее, но делал это всегда между делом и для себя, ради интереса.
И тем не менее принципиально не готовлюсь к собеседованиям. Людям со мной работать и моими реальными знаниями, а не зазубренными методами библиотек/фреймворков и алгоритмами сортировки (которые через месяц забудутся)
это если людям потом работать именно с вами, а не с абстрактным программистом Петей, который ничем не лучше вас как специалист, но потратил пару дней на подготовку к интервью...
Если уж совсем утрировано отнестись к спортсменам, то на нынешней олимпиаде тетька из Нидерландов пробежала марафон будучи учительницей. Да, она готовилась к этому, но без тренера и химии.
Так что вполне работает миф, другой момент, как оценивать такой результат.
Жанр критики мифов сам по себе основан на мифе о том, что эти мифы в реальности распространены до степени, граничащей с универсальностью. Тем временем, от него самого - немало вреда, потому что люди начинают думать, что "так везде" и оказываются склонны видеть дурные мотивы там, где их нет.
У меня с тремя менеджерами одним за другим была как-то одна и та же проблема - исходя из идеи о подобных мифах о стремлении к самоутверждению и так далее, они вбили себе в голову, что я (и не только я) беспокоюсь за судьбу внесённых предложений не потому что хочу, чтобы всё лучше работало и все (включая меня) получали больше денег (потому что в компании есть бонус, зависящий от годовой прибыли), а потому что я, якобы, считаю себя очень крутым спецом, который достоин вознаграждения в виде особого внимания ко всему, что он предложит или скажет.
Одним словом, когда кто-то пытается так или иначе критиковать мифы, как негативный стереотип действий или мышления, есть большой шанс сделать нехорошее - убедить аудиторию, что проблема более распространена, чем на самом деле.
Мне ничего не "кажется", я потратил несколько часов на беседы с этими конкретными людьми, и они были достаточно адекватны, основные причины этого бреда были в том, что им попадались разные "умные" публикации на подобную тему, а потом на эту благодатную почву упал опыт с малолетними эгоцентричными работниками.
Я не утверждаю, что человек, который хорошо разбирается в людях, может внезапно поддаться влиянию подобных баек о вездесущем снобизме, я утверждаю, что обычный человек, который не очень критически относится к тому, что читает о предмете, который весьма субъективен, может получить дополнительный импульс не в ту сторону.
Хорошее замечание! Да, ситуации, описанные здесь - это на закон, а вероятные события, которые могут демотивировать развивающихся людей
Интересная динамика + и — для статьи. Сначала постепенно минусовалась, потом резко вышла в плюсы, но не помогло и все равно ушла в минус :)
"На такого синьора сейчас все компании мира молятся. И пофиг, что он не может бинарное дерево со всеми ротациями расписать."
И это на фоне статей про интервью в ФААНГ, да :)
Интересно если гуглу нужно редкого штучного спеца получить, есть механизмы его мимо кассы устроить, без многомесячных собесов?
На сколько я знаю, надо все равно проходить собеседование. Они просто дают такую зарплату, ради которой стоит готовиться. Средняя зп L8 в гугле 1 лимон https://www.levels.fyi/company/Google/salaries/Software-Engineer/L8/
Просто это показывает то, что программирование перешло от сложной инженерной дисциплины, где требуется ужиматься по байтам и тактам в раздел ремесла.
Ну, ещё не перешла, но спрос этого требует
Сложные задачи не станут вдруг простой рутиной чисто от того что кто-то там этого хочет.
Это моя первая статья на Хабре и она вышла весьма противоречивая. Количество лайков и дизлайков примерно одинаковое. Но комментарии только негативные. Любопытно, почему так? Писать позитивные комментарии просто не принято? Или люди боятся писать позитивные комментарии под противоречивым постом?
Может потому что статья так и кричит, что ваш профессионализм ничто и он никому не нужен?
Выходит забавно. В статьях и комментариях про рейтинг и карму, люди жалуются на то, что их "минусуют без объяснения" и даже пытаются придумать способ заставить писать эти объяснения насильно.
Вам тут в комментариях расписали подробно, в чём проблема с таким подходом, как у вас. Но вас это всё равно не устраивает, потому что вам хочется вербальной похвалы, а не рейтинга. До того хочется, что вы готовы предположить что-то нехорошее (страх, общественное давление). Интересно.
Ну, нет. Я пришёл промотивировать новичков и ожидал поддержку, а нарвался на толпу людей, которые уже все умеют и считают, что я обесцениваю их опыт
Ваша статья никак не мотивирует новичков, она может промотивировать только очень ушлых личностей. Правда им это не нужно — они и так развили софт скиллы хорошо подсаживаться на уши кому надо и хорошо умеют мигрировать из компании в компанию часто с хорошим повышением.
Если бы вы написали что при наборе в такую-то и такую-то компанию, часто есть вакансии, которые не требуют больших знаний навороченных алгоритмов и т.д. и т.п., т.к. в компании уже выстроен процесс набора где от скилла мало что зависит — это могло бы простимулировать новичков не бояться собеседований. Или хотя бы посоветовать брать принципом спама — куча собеседований только для того чтобы не бояться их.
Но вы же в течении всей статьи пытались доказать что знания для работы программистом не нужны.
Я считаю, что технический опыт и знания важны. Но без мотивации их не насобираешь. И хороший лид, кроме того, что пишет хороший код, ещё умеет мотивировать и развивать людей
Практически всё в вашей статье написано языком критики. Вы критикуете поведение неких абстрактных снобов в вакууме, начиная с заголовка. С каких пор критика негативных явлений (не важно, реальных или гипотетических) является надежным способом кого-то мотивировать или вдохновить? (Вопрос - риторический, потому что она таким способом не является.)
Это такой же ужасный способ кого-то мотивировать, как в классической ситуации, когда родители говорят толстому ребенку что остальные дети - дураки, и дразнят его, потому что они ему "завидуют". Дразнить - нехорошо. Но и в том, чтобы быть толстым, хорошего - мало. Из такой родительской мотивации выходят люди, которые считают, что "мир против них".
Я вам уже сказал, что ваша статья преувеличивает масштабы явления интеллектуального снобизма (которое существует, но не является всепроникающим злом), а теперь еще добавлю, что если вы этим пытались промотивировать пресловутых новичков, это вдвойне вредная идея, потому что как критика явления это еще сойдет, но не вздумайте вбивать это в голову людям, которые еще молоды и не знают, что реально происходит в жизни и в индустрии.
Если вы уже достигли успеха, то это замечательно! Вы можете гордиться собой! Статья для тех, кто развивается и ищет мотивацию. Давайте поможем подрастающему поколению поверить в себя
Касательно заключительной фразы: всегда был уверен,что "Не боги горшки обжигают" (?) , но не лепят - точно. Само это слово "лепят" - какое-то очень грубое, правда?
Вырвано из контекста. Я писал, что учить надо все, что важно. Там есть и пример с алгоритмами. А на счёт красивого резюме - без этого действительно даже на интервью можно не попасть. Конечно было бы хорошо, если бы все писали честно, но в Индии миллиард человек и каждый программист оттуда с шикарным резюме, с которым надо конкурировать
А мне понравились универсальные посылы, которые актуальны во все времена, и о которых надо почаще напоминать себе. Каждый "миф" можно написать покороче:
Не восходить от простоты к сложности, а наоборот - нисходить от сложности к простоте.
Большие проекты надо разбивать на более мелкие составные части, чтобы каждый новый программист мог довольно быстро прочитать какую-нибудь часть, держать её образ в голове, и внести что-то своё.
Настойчивость и умение доводить дело до конца важнее, чем запредельный интеллект.
Лычки а-ля "закончил Королевский Колледж" - bullshit и к делу не относятся.
А что касается названия поста, вспомнилась одна цитата.
На мой взгляд идут в FAANG по двум причина:
1) заработать денег - последние лет пять стоки и RSU в FAANG дают очевидные преимущества перед корпами и стартапами
2) когда понимают, что сами не смогут открыть свой бизнес и прийдется остаток жизни пахать на дядю
Есть еще несколько очевидных критериев к примеру пока молод и в FAANG точно возьмут или лучше синица чем стартап с неопределенным будущем.
Многие успокаивают себя тем, что поработаю в FAANG подучусь и может тогда...
Это миф о мифах, за 15 лет работы в постсоветском IT такие подходы к работе я не встречал ни разу. Зато постсоветское IT характеризуется подходом - сначала попытаться разобраться, почитать документацию, погуглить, а потом уже писать вопросы в поддержку. И это отличный, экономящий огромное количество времени подход к работе.
По статье сложилось такое ощущение, что IT для автора начинается на веб-разработке и заканчивается на мобильных приложениях. Ну, может быть между ними где-то затесалась разработка небольшого десктопного приложения на Яве или Питоне.
На самом деле лучше всего развиваются те, кто не боятся тяжелых задач. Большой проект, большая фича? Значит посидим по-дольше. Что-то ну совсем никак не понятно? Ну, пойдём спросим у кого-то. Неизвестный язык или синтаксис? Самое время выучить!
Продолжим... Не знаешь основ ТАУ? Посмотри ролик популярного ардуино-ютубера. Не знаком с основами мат.анализа? Почитай статейку на Я.Дзене. Не изучал основы ЦОС? Не беда, я тебе на обеденном перерыве все объясню.
Это объясняет почему Наука вертела Прогресс как хотела.
Код должен быть как можно проще и понятнее. Нужны простые и популярные библиотеки.
Неудивительно, что даже самые несложные приложения требуют все больше вычислительных ресурсов. Ардуиноподход.
Интеллект, конечно, важный аспект успеха в любой работе, но далеко не последний. Умение сидеть долго над задачей или материалами не теряя фокус - гораздо важнее.
Угу. При нехватке интеллекта, но с избытком умения долго сидеть над задачей, ты по крайней мере всегда создаешь впечатление упорного трудяги. И не важно, что задача не будет решена оптимально и в срок. Главное - "Он очень упорно трудился, даже перерабатывал. Хороший работник.".
Учитывая, что у нас в аэрокосмической отрасли при трудоустройстве как раз-таки в большинстве случаев явно требуется диплом о высшем образовании
Диплом ВУЗа и знания — это слабо связанные вещи в нашей реальности.
А это уже зависит от того, что требуется заказчику.
Статья ведь не про требования заказчика, а про то как якобы надо делать.
Умение сидеть долго над задачей или материалами не теряя фокус — гораздо важнее.
Без интеллекта эта фраза превращается в
Умение сидеть долго над задачей или материалами и тупить не теряя фокус — гораздо важнее.
Я не совсем понимаю большинство негативных комментариев, так как автор доносит важный разницу в подходах к людям на западе и в пост-советском пространстве. Мне самому довелось вырости в Новой Зеландии и пройти весь путь от школы, универа до работы в компаниях в НЗ и США и теперь и основать свою. Параллельно к этому я сам читаю Хабр с 2010го.
Никто не отменяет требования к наличию профильного образования где оно действительно требуется. Я точно не пойду на позицию электронщика так как я там ничего не знаю, но есть разница когда мы доходим до стажа. Сколько я не смотрю на команды в СНГ а к джунам во многих дедовщина не лучше чем в той армии. Сениор у нас Б-г а джун крепостной. На вопрос "Почему так надо делать?" обычно получаешь что-то вроде "Ты что тупой?" "Читай маны!" и тому подобное. Если не верите, милости просим на Тостер.
Для примера: у нас в НЗ я работал с самыми большими компаниями XERO(500 человек штат) и Trademe(800 человек штат), Aura Infosec(50 человек). Они не выстраивают такие строгие иерархии как в СНГ. Нету "Ты джун, закрой рот и жри мои баги". У нас обычно находят что нравится джуну и туда его втягивают за счет совместных проектов и личных инициатив. Где надо тренируют. Где надо менторят, но нету этого всего снобизма типа "Ты что тупой?" что я не раз слышал в свою сторону спрашиваю достаточно нормальные вопросы. Вся суть сениоров у нас это руководство, наставничество и решения критических ситуаций. Конечно же если горит стек и сайт лежит то джуна никто не будет отправлять все чинить, но нету ничего такого чтобы дать джуну интересную задачу и помочь ему её решить. Это во первых растит джуна и заставляет его быть более вовлеченным в проект и команду, а во вторых учит самого сениора умению учить и управлять.
Так же у нас джунов кидают на новые, перспективные, направления, некоторые которые сами же джуны часто и приносят, именно потому что джуны не думают как все в компании и им соответсвенно легче этим заниматься. Молодая кровь. В том же Trademe, для примера, интерактивные карты разрабатывал джун который сам и принес им эту идею.
Я же работая в Aura Infosec на пример имел личный проект по фаззингу с AFL и потом совместно с сениором мы написали вместе статью https://research.aurainfosec.io/hunting-for-bugs-101/. Так же я делал лекции для своей команды по веб-парсингу и FIDO протоколам и я тогда был второкурсником джуном. В этом нету ничего такого у в НЗ это нормальная практика.
Просто надо к людям по-человечески относиться вне зависимости от их опыта. Мы все когда-то были джунами.
Если кто-то попытается упрекнуть меня в том что я тоже как-то безрукий джун. Ничего не знаю. Милости просим https://github.com/herrjemand https://medium.com/webauthnworks
Все что вы пишете это хорошо и правильно.
Только вот статья совсем о другом. Именно поэтому на нее такая реакция. Автор всеми силами хочет обесценить знания читателей и повторяет несколько раз разными словами, что знания не нужны.
Они не выстраивают такие строгие иерархии как в СНГ. Нету "Ты джун, закрой рот и жри мои баги"
Мне вот интересно, а почему вы считаете, что такие иерархии и манера общения, приняты в условном СНГ? Я вот за 20+ лет работы здесь с таким отношением не сталкивался. А вот с аналогичной политикой одной из американских компаний, правда не по отношению к джунам, а к внешним контракторам, вполне.
Работал и в СССР, и в России. Что интересно, ни разу не встречал описанного Вами отношения к "джунам".
"Ты что тупой?" всегда начиналось только тогда, когда пациент задавал одни и те же вопросы постоянно, причем явно озвучивая свое нежелание "вникать и запоминать", ибо "зачем, всегда же спросить можно?".
Единственная дедовщина, с которой сталкивался, это привлечение молодежи к перетаскиванию тяжестей (компьютеры какие али ИБП с места на место перетащить).
Ну еще кое-где сильно пинали насчет саморазвития, принуждая тех, кто сам не стремился к оному.
Подраздел 1 и подраздел 4 - абсолютно не верны.
Крутые программеры пишут ПРОСТОЙ код.
Куча моих выпускников работали или работают в самых крутых компаниях мира - вплоть до IBM.
По первому "мифу". Сложность - штука относительная. При разном уровне подготовки один и тот же код воспринимается по-разному. Например, "простой код" джунов очень часто кажется "сложным" для более опытных коллег и наоборот.
Второй миф - абсолютная правда. Если в компании позволяют человеку брать задачи, к которым он не готов, то это очень круто, но значит, что либо его способности не правильно оценивают, либо компания готова тратить ресурсы на его обучение (ну или просто вариантов нет). То, что у некоторых подгорает от того, что кто-то менее опытный имеет более крутую лычку и больше зарплату, это, конечно, правда, но я бы не был так уверен, что это особенность постсоветского IT. Подозреваю, что так примерно везде, это просто свойство человеческой натуры. Просто в некоторых коллективах его принято прятать, а в некоторых выставлять на показ.
Опровержение третьего мифа - это вообще не опровержение. Да, одного ума мало. Но какой-то фильтр по интеллектуальным способностям тут абсолютно точно есть. Не раз видел людей, прикладывавших огромные усилия, но не смогших осилить какие-то совершенно элементарные навыки программирования. Да и сам периодически натыкаюсь на вещи, где начинают ощущаться границы собственных способностей.
"Чтобы попасть на крутую работу надо пройти крутое интервью. А к любому крутому интервью можно круто подготовиться. " - в целом это, конечно, правда. Но условный faang может себе позволить действительно отбирать лучших по каким-то своим критериям. Плюс подготовка к некоторым интервью может сделать вас, если не крутым специалистом, то по крайней мере неплохим. А еще на крутую работу мало просто попасть...
Мифы какие то странные. Автор сам придумал.
Миф 1. Крутые программисты пишут сложный код. Не сложный а классный код.
Он хорошо работает, хорошо читается и хорош для развития.
Миф 2 вовсе не миф.
Миф 3 тоже не миф.
Кое с чем я согласен. В основном с тем, что нужно уметь документировать свой код. А это не любят делать программисты.
По первому пункту так же есть замечание, что часто простой код для опытного может оказаться сложным для джуна из-за чрезмерного использования магии и сахара. Не стоит этим злоупотреблять (есть опыт разбора такого кода).
Заходим, читаем про ценности компании и процесс интервью. Нужны алгоритмы? Учим алгоритмы. Компания ценит смелых? Пишем и заучиваем историю, где мы были смелыми. И т.д. Ну и красивое резюме надо или знакомого на фирме, который может дать рекомендацию, чтобы на это интервью попасть.
В общем, учимся с максимальной эффективностью втирать очки на собеседовании.
В хорошем продукте даже джуниор может починить баг.
А если код написан по стандартам фреймворка - хорошим, качественным стандартом, хороший и качественный код. Но этот код требует некоторых знаний в области технологий, используемых во фреймворке - и без этих знаний не то что поправить, но просто найти проблему становится сложно. Сеньор уже плохой сноб, раз взял этот фреймворк? Или всё-же нижняя планка должна присутствовать?
Я считаю, что надо выбирать популярный Фреймворк, тогда, если джуниор его не знает, то пусть учит. Был у меня опыт, когда работал в Comcast, нас заставили писать проект на базе прототипа на Polymer. И хотя его все неплохо выучили, подход все равно не взлетел, потому что даже со всеми полифилами оно не работало правильно в некоторых браузерах, которые нам надо было поддерживать. В итоге мне все равно потом пришлось все на реакте переписывать. Но, правда, есть и немного противоположный случай. Один мой техлид заставлял свою команду писать на Golang, ещё до того, как он стал популярным. Мне его опыт нереально круто пригодился, когда Golang стал популярным и я выбрал именно его для проекта для Wikimedia Foundation
А что у Вас означает словосочетание "постсоветского IT"? Заголовок предполагает, что будет определение советского IT и постсоветского, их сравнение. Но, видать, что-то не сложилось, или Вы просто забыли про свой заголовок.
А мне, старикану, было бы интересно прочитать, что постсоветская молодежь думает о советском, даже, если речь идет о снобизме, тем более в IT.
"
Код должен быть как можно проще и понятнее. Нужны простые и популярные библиотеки. Ну, допустим, пришлось все-таки написать сложный алгоритм - будь добр, подробно опиши, как он работает."
чувак ты не шариш..
Снобизм постсоветского IT