Чудеса, в Microsoft объявили конец поддержке IE11 в собственных веб-приложениях.
Помню еще время, когда IE6 казался (и был) современным браузером, IE5.5 for Mac - волшебное словосочетание, как потом от IE6 с радостью открещивались, а потом то же самое с IE9 и YouTube, кажется.
И вот, последняя веха в битве движков. Chromium победил всех, получается? Сколько там у Gecko осталось, процентов 10 рынка?
И радостно, что не придется больше чинить поломанный CSS в IE, и грустно, что тот, у кого больше всего денег (от гугла и apple) и больше всего пользователей, как следствие, в итоге побеждает.
Помню еще время, когда IE6 казался (и был) современным браузером, IE5.5 for Mac - волшебное словосочетание, как потом от IE6 с радостью открещивались, а потом то же самое с IE9 и YouTube, кажется.
И вот, последняя веха в битве движков. Chromium победил всех, получается? Сколько там у Gecko осталось, процентов 10 рынка?
И радостно, что не придется больше чинить поломанный CSS в IE, и грустно, что тот, у кого больше всего денег (от гугла и apple) и больше всего пользователей, как следствие, в итоге побеждает.
Про мотивацию и impact в Фейсбуке
В Фейсбуке к мотивации, как и приблизительно ко всему остальному в разработке, свой подход. Есть магическое слово, универсальное мерило успеха продуктов и программистов - impact. То есть влияние, положительное. Делать нужно только то, что принесёт пользу - продукту, инфраструктуре, коллегам, вам.
Новая архитектура, которая ускорит обработку сообщений на 10% - impact, тащи! Сделать десяток новых фич, которые помогут продукту занять запланированную нишу на рынке? Impact, вперёд! Вкрутить UI-библиотеку, чтобы интерфейс наконец стал непротиворечивым - impact, конечно же.
Хоть я и настроен крайне критически по отношению к корпоративной шелухе, неумело маскирующей нередко потогонный характер работы и прочие проблемы крупных компаний, идея impact вполне хороша.
Чтобы такой подход полетел, важно не только делать что-то полезное, но ещё и рассказывать об этом коллегам и начальникам и демонстрировать положительный результат. Причём всё время, а не только в преддверии PSC (performance summary cycle - период длиной в полгода, в течение которого на вас собирают фидбек, выставляют оценки и дают повышения).
Можно поспорить, может ли и должен ли разработчик отвечать за что-то большее, чем код и его качество. Я даже вижу целый спектр мнений, почти как в политике - от полной анархии (разработчики решают, что делать) до абсолютной вертикали (пишем код по спецификации от бизнес-аналитиков и "архитекторов" за подписью десяти руководителей).
И, разумеется, экстремисты нелепы. Программисты-анархисты - это стартаперы, которые ещё об этом не знают. Им надо в предпринимательство, а не фейсбук. Разработчики-тираны вообще с трудом вписываются в ландшафт современной гибкой разработки. Мало того, что они ничего хорошего не сделают по своему регламенту, так с ними ещё и ни один нормальный человек в окоп не полезет.
Но разве идея оценки через призму impact не слишком "левая"? Может быть, но однозначно хорошее в ней тоже есть.
Искать проблемы, заслуживающие внимания, качественно решать их и убедительно об этом рассказывать - это вполне универсальный рецепт успеха в любом окружении. А если за это ещё и платят, то вообще отлично. Конечно, в сравнении с менее продвинутыми компаниями, а не с идеальными условиями (да-да, я тоже согласен с Талебом по поводу зарплаты).
А вы хотели бы, чтобы вашу работу оценивали через impact?
В Фейсбуке к мотивации, как и приблизительно ко всему остальному в разработке, свой подход. Есть магическое слово, универсальное мерило успеха продуктов и программистов - impact. То есть влияние, положительное. Делать нужно только то, что принесёт пользу - продукту, инфраструктуре, коллегам, вам.
Новая архитектура, которая ускорит обработку сообщений на 10% - impact, тащи! Сделать десяток новых фич, которые помогут продукту занять запланированную нишу на рынке? Impact, вперёд! Вкрутить UI-библиотеку, чтобы интерфейс наконец стал непротиворечивым - impact, конечно же.
Хоть я и настроен крайне критически по отношению к корпоративной шелухе, неумело маскирующей нередко потогонный характер работы и прочие проблемы крупных компаний, идея impact вполне хороша.
Чтобы такой подход полетел, важно не только делать что-то полезное, но ещё и рассказывать об этом коллегам и начальникам и демонстрировать положительный результат. Причём всё время, а не только в преддверии PSC (performance summary cycle - период длиной в полгода, в течение которого на вас собирают фидбек, выставляют оценки и дают повышения).
Можно поспорить, может ли и должен ли разработчик отвечать за что-то большее, чем код и его качество. Я даже вижу целый спектр мнений, почти как в политике - от полной анархии (разработчики решают, что делать) до абсолютной вертикали (пишем код по спецификации от бизнес-аналитиков и "архитекторов" за подписью десяти руководителей).
И, разумеется, экстремисты нелепы. Программисты-анархисты - это стартаперы, которые ещё об этом не знают. Им надо в предпринимательство, а не фейсбук. Разработчики-тираны вообще с трудом вписываются в ландшафт современной гибкой разработки. Мало того, что они ничего хорошего не сделают по своему регламенту, так с ними ещё и ни один нормальный человек в окоп не полезет.
Но разве идея оценки через призму impact не слишком "левая"? Может быть, но однозначно хорошее в ней тоже есть.
Искать проблемы, заслуживающие внимания, качественно решать их и убедительно об этом рассказывать - это вполне универсальный рецепт успеха в любом окружении. А если за это ещё и платят, то вообще отлично. Конечно, в сравнении с менее продвинутыми компаниями, а не с идеальными условиями (да-да, я тоже согласен с Талебом по поводу зарплаты).
А вы хотели бы, чтобы вашу работу оценивали через impact?
🏖 С последним днём лета!
Не знаю, насколько легко вы отключаетесь от работы, но у меня с этим проблемы. Я обычно так влипаю в свои задумки, что занимаюсь ими всё свободное время. Либо, наоборот, не занимаюсь вообще. И, хотя второй вариант меня вполне устраивает теоретически, мне сложно смириться с тем, что вот прямо сейчас - по любой причине - я не двигаюсь к своей цели.
Основная причина этому - сильное желание кое-что поменять, ну и нетерпеливость. Но, безотносительно причины, позволить полностью отключиться от работы и избавиться от чувства вины мне удаётся с трудом. Но гениальное решение есть!
Нужно только полететь в отпуск за границу тогда, когда все здравомыслящие люди стараются сидеть дома; узнать, что багаж потерян и прожить в одних шортах и майке почти неделю; забить на это и просто ходить поесть, на пляж и поспать; смотреть дрянные сериалы на НТВ; сломаться в горах на арендной тачке и бросить её там, потому что с детьми в сорокоградусную жару лучше быть дома, а не на горном серпантине; уехать назад с пьяным водителем, который кидается бутылками из окна и предлагает порулить, пересаживаясь на пассажирское на полпути.
Исчерпывающий список аттракционов для тихого семейного отдыха получился. Едва ли я успел расслабиться - но точно отвлёкся от впечатавшийся в подушечки пальцев рутины.
А как ваше лето? Получилось отдохнуть без экстрима?
Не знаю, насколько легко вы отключаетесь от работы, но у меня с этим проблемы. Я обычно так влипаю в свои задумки, что занимаюсь ими всё свободное время. Либо, наоборот, не занимаюсь вообще. И, хотя второй вариант меня вполне устраивает теоретически, мне сложно смириться с тем, что вот прямо сейчас - по любой причине - я не двигаюсь к своей цели.
Основная причина этому - сильное желание кое-что поменять, ну и нетерпеливость. Но, безотносительно причины, позволить полностью отключиться от работы и избавиться от чувства вины мне удаётся с трудом. Но гениальное решение есть!
Нужно только полететь в отпуск за границу тогда, когда все здравомыслящие люди стараются сидеть дома; узнать, что багаж потерян и прожить в одних шортах и майке почти неделю; забить на это и просто ходить поесть, на пляж и поспать; смотреть дрянные сериалы на НТВ; сломаться в горах на арендной тачке и бросить её там, потому что с детьми в сорокоградусную жару лучше быть дома, а не на горном серпантине; уехать назад с пьяным водителем, который кидается бутылками из окна и предлагает порулить, пересаживаясь на пассажирское на полпути.
Исчерпывающий список аттракционов для тихого семейного отдыха получился. Едва ли я успел расслабиться - но точно отвлёкся от впечатавшийся в подушечки пальцев рутины.
А как ваше лето? Получилось отдохнуть без экстрима?
Зачем программисту копаться в мозгах
В моих заметках достаточно много самокопания, и вам наверняка интересно, зачем это в блоге "о программировании, карьере и бизнесе". Даже если мой скромный, личный во всех отношениях опыт представляет какую-то ценность для других, зачем он лично вам, ещё и оттуда, где вы его не ждёте?
Отвечу длинно. Попробуем смоделировать профессиональную жизнь, используя две ортогональные оси. Для простоты назовём их "польза" и "удовольствие".
В левом нижнем углу мало пользы и отсутствующее удовольствие. Скорее всего, это глупая, однообразная работа, не несущая ни ценности в мир, ни удовлетворения, роста или высокого заработка. Её может делать любой, и я уверен, что никто из моих подписчиков не находится в этом положении.
Поднимаясь по оси Y, получаем высокую пользу и мало удовольствия. Предположу, что тут оказываются многие карьеристы, добившиеся высот и делающие что-то важное и нужное - для других, но не для себя. Удовольствия и удовлетворения от работы они получают мало, много беспокоятся, переживают и потому быстрее стареют, но, вероятно, неплохо зарабатывают. Это архетип успешности в глазах обывателя, не учитывающий индивидуальность, либо попросту отрицающий её существование.
В правом нижнем углу много удовольствия, но отсутствующая польза для других. Это своего рода "уголок Нарцисса", куда попадают бездельники, "живущие для себя". Они, вероятно, вполне довольны жизнью, но, т.к. не являются частью ни одной из существующих социально-экономических систем, не получают и положительной обратной связи от общества - денег и признания.
Заветный угол, разумеется, правый верхний. Находясь в нём, вы приносите большую пользу обществу через своё занятие и при этом искренне наслаждаетесь процессом как в моменте, так и в долгосрочной перспективе. Это место, которое я бы назвал "ваше место", и мне кажется, что отыскать или создать его непросто.
Ни школа, ни институт, ни работа в корпорации или "на галере" не имеют целью помочь вам найти своё место. Не выдуманное, как в мечтах нарциссов, где они за одну ночь становятся звёздами, а настоящее, заслуженное и признанное миром.
Так зачем же программисту копаться в мозгах и забивать и без того занятую голову психологией? Чтобы попасть из левого верхнего угла, где много ответственности и нервов и нет удовлетворения и настоящего личностного роста, в правый верхний угол, где ответственности по-прежнему много, но уже можно быть искренне довольным как процессом, так и результатом - а результаты вашей работы нужны другим.
По моим наблюдениям - в первую очередь за собой и близкими, - трудолюбивые и ответственные ребята часто оказываются в верхнему левом углу. Наверняка, и вы тоже там. У вас сложная, но регламентированная и противоречащая внутренним ценностям работа, которая, тем не менее, позволяет жить хорошо и покрывает потребности всей семьи. Это может казаться достойным компромиссом с собой. Но, увы, чревато глубокими психологическими, а вслед за ними и физиологическими проблемами.
Так вот, наблюдение за собственными эмоциями, умение анализировать их и работать с ними фундаментально важны для работников умственного труда. Вы уже достаточно упорны и трудолюбивы, чтобы достичь успеха, но, вероятно, недостаточно внимательны к себе, чтобы разобраться, как именно и где применить свои навыки на пользу не только другим, но и себе.
Когда я рассказываю, как отношусь к работе в корпорации или как я отдохнул и отвлёкся, я хочу не только "подумать вслух" или выплеснуть эмоции, что, безусловно, полезно лично для меня. Я стараюсь привлечь ваше внимание к тому, что вы - не бездумная, бесчувственная машина. Не работник с 9 до 5 по звонку, не Software Development Engineer at Google в апогее траектории своей карьеры.
Вы очень сложная, чувствительная к внешним и внутренним изменениям система, со своим прошлым, настоящим и невероятным будущим. Но оно будет невероятным только если хорошо поработать и быть по-настоящему внимательным к себе.
https://oleggromov.com/u/programmer-occupation-psychology.png
В моих заметках достаточно много самокопания, и вам наверняка интересно, зачем это в блоге "о программировании, карьере и бизнесе". Даже если мой скромный, личный во всех отношениях опыт представляет какую-то ценность для других, зачем он лично вам, ещё и оттуда, где вы его не ждёте?
Отвечу длинно. Попробуем смоделировать профессиональную жизнь, используя две ортогональные оси. Для простоты назовём их "польза" и "удовольствие".
В левом нижнем углу мало пользы и отсутствующее удовольствие. Скорее всего, это глупая, однообразная работа, не несущая ни ценности в мир, ни удовлетворения, роста или высокого заработка. Её может делать любой, и я уверен, что никто из моих подписчиков не находится в этом положении.
Поднимаясь по оси Y, получаем высокую пользу и мало удовольствия. Предположу, что тут оказываются многие карьеристы, добившиеся высот и делающие что-то важное и нужное - для других, но не для себя. Удовольствия и удовлетворения от работы они получают мало, много беспокоятся, переживают и потому быстрее стареют, но, вероятно, неплохо зарабатывают. Это архетип успешности в глазах обывателя, не учитывающий индивидуальность, либо попросту отрицающий её существование.
В правом нижнем углу много удовольствия, но отсутствующая польза для других. Это своего рода "уголок Нарцисса", куда попадают бездельники, "живущие для себя". Они, вероятно, вполне довольны жизнью, но, т.к. не являются частью ни одной из существующих социально-экономических систем, не получают и положительной обратной связи от общества - денег и признания.
Заветный угол, разумеется, правый верхний. Находясь в нём, вы приносите большую пользу обществу через своё занятие и при этом искренне наслаждаетесь процессом как в моменте, так и в долгосрочной перспективе. Это место, которое я бы назвал "ваше место", и мне кажется, что отыскать или создать его непросто.
Ни школа, ни институт, ни работа в корпорации или "на галере" не имеют целью помочь вам найти своё место. Не выдуманное, как в мечтах нарциссов, где они за одну ночь становятся звёздами, а настоящее, заслуженное и признанное миром.
Так зачем же программисту копаться в мозгах и забивать и без того занятую голову психологией? Чтобы попасть из левого верхнего угла, где много ответственности и нервов и нет удовлетворения и настоящего личностного роста, в правый верхний угол, где ответственности по-прежнему много, но уже можно быть искренне довольным как процессом, так и результатом - а результаты вашей работы нужны другим.
По моим наблюдениям - в первую очередь за собой и близкими, - трудолюбивые и ответственные ребята часто оказываются в верхнему левом углу. Наверняка, и вы тоже там. У вас сложная, но регламентированная и противоречащая внутренним ценностям работа, которая, тем не менее, позволяет жить хорошо и покрывает потребности всей семьи. Это может казаться достойным компромиссом с собой. Но, увы, чревато глубокими психологическими, а вслед за ними и физиологическими проблемами.
Так вот, наблюдение за собственными эмоциями, умение анализировать их и работать с ними фундаментально важны для работников умственного труда. Вы уже достаточно упорны и трудолюбивы, чтобы достичь успеха, но, вероятно, недостаточно внимательны к себе, чтобы разобраться, как именно и где применить свои навыки на пользу не только другим, но и себе.
Когда я рассказываю, как отношусь к работе в корпорации или как я отдохнул и отвлёкся, я хочу не только "подумать вслух" или выплеснуть эмоции, что, безусловно, полезно лично для меня. Я стараюсь привлечь ваше внимание к тому, что вы - не бездумная, бесчувственная машина. Не работник с 9 до 5 по звонку, не Software Development Engineer at Google в апогее траектории своей карьеры.
Вы очень сложная, чувствительная к внешним и внутренним изменениям система, со своим прошлым, настоящим и невероятным будущим. Но оно будет невероятным только если хорошо поработать и быть по-настоящему внимательным к себе.
https://oleggromov.com/u/programmer-occupation-psychology.png
Привет! О чём хотели бы почитать?
Final Results
40%
Фейсбук и собеседования в корпорации
41%
Жизнь за рубежом: в Англии, США, Швеции
45%
Английский и как его учить
Сразу в продакшн
Я задумывал намного больше проектов, чем начинал, а начинал намного больше, чем заканчивал. Спад примерно экспоненциальный. Можно найти массу причин этому феномену, но одна из них - элементарное отстутствие удобного деплоя в продакшн одной командой.
Простой пример - любое объектное хранилище, например Google Storage или Amazon S3. У обоих есть CLI-тулзы, с помощью которых деплой статического файла действительно выполняется одной командой. Второй настраивается edge-кэш - и ваш файлик готов к миллионам скачиваний.
А как же приложения посложнее статики? Когда мы говорим про рабочее окружение, в CI/CD-инфраструктуру вкладываются огромные силы и средства, и деплои для разработчиков, как правило, просты и прозрачны. Смёржил свой пул-реквест в master, и погнали. А под капотом: несколько окружений, тысячи тестов, инкрементальные выкладки и A/B-тесты, миграции схемы БД и данных.
Хоть DevOps-подход и популярен, сложно представить себе разработчика на развесистом проекте (особенно с микросервисами), который и код пишет, и всю инфраструктуру вокруг настраивает, и работает при этом не 16 часов в день. В крупных компаниях есть целые команды, которые если и не настраивают каждую сборку, то, как минимум, собирают и поддерживают инструменты для деплоя.
А вот в сайд-проектах всё совсем по-другому, и помогать вам некому. Инструменты автоматизации можно либо взять существующие (GitHub Actions, например), либо сделать самому. Какой бы подход вы ни выбрали, постарайтесь сделать так, чтобы ваш код попадал в продакшн максимально просто и быстро. Это увеличит шансы вашего проекта быть запущенным и позволит вам не прокрастинировать из-за очередной хитрой выкладки, а делать что-то полезное.
Первое, что я делаю в своих проектах - это автоматизация настройки серверов и деплоя. После серии экспериментов с Google Cloud и их встроенными инструментами, я ушёл на DigitalOcean и "ручную" настройку через Ansible. Для моих миниатюрных проектов получается и дешевле в рантайме, и не сложнее, а скорее более гибко и надёжно, чем с гуглом.
Когда деплой автоматизирован, разработку я веду в 2 окружениях параллельно: локальном, где я пишу код, и продакшене, куда попадает каждый комит в master. Тестирования, которое могло бы заблокировать выкладку, у меня конечно же нет - я не фейсбук для таких мер. Из тестов - только юнит-тесты на какие-то критические и непонятные куски кода. Для сайта, когда он будет готов, я наверное добавлю интеграционное тестирование для проверки наличия страниц и корректности кэширования, но тоже в продакшене.
Большим проектам и командам такой процесс, разумеется, не подойдёт - слишком много рисков и точек отказа, но для моих микропроектов с одним разработчиком - в самый раз. А вы свои сайд-проекты тоже деплоите в прод одной командой?
Я задумывал намного больше проектов, чем начинал, а начинал намного больше, чем заканчивал. Спад примерно экспоненциальный. Можно найти массу причин этому феномену, но одна из них - элементарное отстутствие удобного деплоя в продакшн одной командой.
Простой пример - любое объектное хранилище, например Google Storage или Amazon S3. У обоих есть CLI-тулзы, с помощью которых деплой статического файла действительно выполняется одной командой. Второй настраивается edge-кэш - и ваш файлик готов к миллионам скачиваний.
А как же приложения посложнее статики? Когда мы говорим про рабочее окружение, в CI/CD-инфраструктуру вкладываются огромные силы и средства, и деплои для разработчиков, как правило, просты и прозрачны. Смёржил свой пул-реквест в master, и погнали. А под капотом: несколько окружений, тысячи тестов, инкрементальные выкладки и A/B-тесты, миграции схемы БД и данных.
Хоть DevOps-подход и популярен, сложно представить себе разработчика на развесистом проекте (особенно с микросервисами), который и код пишет, и всю инфраструктуру вокруг настраивает, и работает при этом не 16 часов в день. В крупных компаниях есть целые команды, которые если и не настраивают каждую сборку, то, как минимум, собирают и поддерживают инструменты для деплоя.
А вот в сайд-проектах всё совсем по-другому, и помогать вам некому. Инструменты автоматизации можно либо взять существующие (GitHub Actions, например), либо сделать самому. Какой бы подход вы ни выбрали, постарайтесь сделать так, чтобы ваш код попадал в продакшн максимально просто и быстро. Это увеличит шансы вашего проекта быть запущенным и позволит вам не прокрастинировать из-за очередной хитрой выкладки, а делать что-то полезное.
Первое, что я делаю в своих проектах - это автоматизация настройки серверов и деплоя. После серии экспериментов с Google Cloud и их встроенными инструментами, я ушёл на DigitalOcean и "ручную" настройку через Ansible. Для моих миниатюрных проектов получается и дешевле в рантайме, и не сложнее, а скорее более гибко и надёжно, чем с гуглом.
Когда деплой автоматизирован, разработку я веду в 2 окружениях параллельно: локальном, где я пишу код, и продакшене, куда попадает каждый комит в master. Тестирования, которое могло бы заблокировать выкладку, у меня конечно же нет - я не фейсбук для таких мер. Из тестов - только юнит-тесты на какие-то критические и непонятные куски кода. Для сайта, когда он будет готов, я наверное добавлю интеграционное тестирование для проверки наличия страниц и корректности кэширования, но тоже в продакшене.
Большим проектам и командам такой процесс, разумеется, не подойдёт - слишком много рисков и точек отказа, но для моих микропроектов с одним разработчиком - в самый раз. А вы свои сайд-проекты тоже деплоите в прод одной командой?
FizzBuzz Enterprise Edition
Уверен, что вы слышали про FizzBuzz - простейшую задачку для собеседований, которую, по слухам, проваливает немалое количество кандидатов, стремящихся в тот самый кровавый энтерпрайз.
Так вот, есть даже целый почти соревновательный жанр, где разные авторы конкурируют за самую эзотерическую реализацию нехитрого алгоритма. Лучшее решение из увиденных мной пока написано на джаве: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
На скриншоте только один из сотен классов - покопайтесь в репозитории для вдохновения! Можно даже пару-тройку шаблонов проектирования по нему выучить 😉
Уверен, что вы слышали про FizzBuzz - простейшую задачку для собеседований, которую, по слухам, проваливает немалое количество кандидатов, стремящихся в тот самый кровавый энтерпрайз.
Так вот, есть даже целый почти соревновательный жанр, где разные авторы конкурируют за самую эзотерическую реализацию нехитрого алгоритма. Лучшее решение из увиденных мной пока написано на джаве: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
На скриншоте только один из сотен классов - покопайтесь в репозитории для вдохновения! Можно даже пару-тройку шаблонов проектирования по нему выучить 😉
Как я целеполаганием прокрастинацию победил
Полгода назад, занимаясь Quiken, я активно фигачил. Практически каждый вечер садился и писал код, переписывал код, настраивал деплои, фоновые таски, экспериментировал с дизайном и UX, рисовал логотип, промо-картинки, писал описания в Chrome Store. И так три месяца подряд. Это было непривычно: мне редко удавалось настолько сконцентрированно работать над чем-то "своим", не считая разве что литкода и подготовки к вступительным по математике.
В том проекте часть задач мне нравилась, а другая часть - нет. Свободного времени по сути не было, но я его всё равно находил. Состояние потока приходило часто, но не всегда - хотя самое главное, что я не прокрастинировал и планомерно шёл к запуску проекта.
Когда активная работа над Quiken завершилась, я взялся за новый сайт. Долго думал, зачем он мне. Увязывал в одну стратегию телеграм, длинные статьи и блогинг; публикации на других сайтах и тактики продвижения; съёмки видео. Пришёл к определённым решениям по технологиям, взялся за прототипы, проверил и подтвердил жизнеспособность всех идей. Всё шло хорошо.
А потом на полной скорости влетел лбом в уже ставшую непривычной стену прокрастинации.
Отвлёкся на основную работу; домашние дела; потом поехали отдыхать; копался в мозгах, пытаясь найти новые ориентиры и ценности; искал детский сад для ребёнка; потом заказал в Японии гитару, о которой мечтал с юности, и выбирал усилитель для занятий дома. Месяцы шли, а я всё никак не садился за работу, проводя всё больше времени в размышлениях и без какого-либо результата.
Неприятнее всего, что подобный режим, когда много запланировал, а потом только думаешь и почти ничего не делаешь, угнетает психологически. Вроде бы и цели есть, и всё понятно - но ничего не получается. Несложно попасть в downward spiral (это как по-русски?) и утонуть в море вины, жалости к себе и отвращения к работе.
Побарахтавшись чуть-чуть, я стал выплывать. Сначала вернулся к выработанному принципу "деплоить в продакшн сразу же": настроил Ansible, серверы на Digital Ocean, миграции - чтобы каждый комит в master одной командой релизить на живой сайт. Это немного помогло, так как я взялся за работу, но код самого сайта я всё равно не писал. Прокрастинация не уходила.
Тогда я заподозрил целеполагание. Как и многие из вас, я привык ставить цели в контексте работы. Иногда организуя их в иерархию objectives and key results, иногда опираясь на SMART-методологию: чтобы был срок, чтобы было точно понятно, что делать - а потом оценивать результат по заранее определённой шкале. И, кажется, эта привычка сыграла со мной злую шутку.
У меня не так много времени, чтобы заниматься своими проектами; внимания, силы воли и даже желания часто тоже не хватает. И получается, что я не достигал практически ни одной из своих целей, прикреплённых к календарю и выраженных количественно. От этого пропадает уверенность в себе и адекватности целей, и приходит тот самый ступор, заставляющий смотреть сериалы даже тогда, когда отдыхать уже не хочется.
Обнаружив неладное, я попробовал изменить подход к планированию. Вместо намерения достигать определённого результата к определённому сроку решил сконцентрироваться на соблюдении определённого расписания. 2-4 часа в будни должно уходить на свои проекты, включая сайт, канал и прочее. Разумеется, это получается не всегда: я стараюсь садиться за работу каждый день, но не винить себя, когда не выходит.
Привычное планирование с таким подходом почти невозможно, но в моих нынешних начинаниях так много неопределённости, что придерживаться планов всё равно не получается. И если поначалу ослабить хватку контроля страшно, спустя какое-то время становится намного легче жить и работать.
Полгода назад, занимаясь Quiken, я активно фигачил. Практически каждый вечер садился и писал код, переписывал код, настраивал деплои, фоновые таски, экспериментировал с дизайном и UX, рисовал логотип, промо-картинки, писал описания в Chrome Store. И так три месяца подряд. Это было непривычно: мне редко удавалось настолько сконцентрированно работать над чем-то "своим", не считая разве что литкода и подготовки к вступительным по математике.
В том проекте часть задач мне нравилась, а другая часть - нет. Свободного времени по сути не было, но я его всё равно находил. Состояние потока приходило часто, но не всегда - хотя самое главное, что я не прокрастинировал и планомерно шёл к запуску проекта.
Когда активная работа над Quiken завершилась, я взялся за новый сайт. Долго думал, зачем он мне. Увязывал в одну стратегию телеграм, длинные статьи и блогинг; публикации на других сайтах и тактики продвижения; съёмки видео. Пришёл к определённым решениям по технологиям, взялся за прототипы, проверил и подтвердил жизнеспособность всех идей. Всё шло хорошо.
А потом на полной скорости влетел лбом в уже ставшую непривычной стену прокрастинации.
Отвлёкся на основную работу; домашние дела; потом поехали отдыхать; копался в мозгах, пытаясь найти новые ориентиры и ценности; искал детский сад для ребёнка; потом заказал в Японии гитару, о которой мечтал с юности, и выбирал усилитель для занятий дома. Месяцы шли, а я всё никак не садился за работу, проводя всё больше времени в размышлениях и без какого-либо результата.
Неприятнее всего, что подобный режим, когда много запланировал, а потом только думаешь и почти ничего не делаешь, угнетает психологически. Вроде бы и цели есть, и всё понятно - но ничего не получается. Несложно попасть в downward spiral (это как по-русски?) и утонуть в море вины, жалости к себе и отвращения к работе.
Побарахтавшись чуть-чуть, я стал выплывать. Сначала вернулся к выработанному принципу "деплоить в продакшн сразу же": настроил Ansible, серверы на Digital Ocean, миграции - чтобы каждый комит в master одной командой релизить на живой сайт. Это немного помогло, так как я взялся за работу, но код самого сайта я всё равно не писал. Прокрастинация не уходила.
Тогда я заподозрил целеполагание. Как и многие из вас, я привык ставить цели в контексте работы. Иногда организуя их в иерархию objectives and key results, иногда опираясь на SMART-методологию: чтобы был срок, чтобы было точно понятно, что делать - а потом оценивать результат по заранее определённой шкале. И, кажется, эта привычка сыграла со мной злую шутку.
У меня не так много времени, чтобы заниматься своими проектами; внимания, силы воли и даже желания часто тоже не хватает. И получается, что я не достигал практически ни одной из своих целей, прикреплённых к календарю и выраженных количественно. От этого пропадает уверенность в себе и адекватности целей, и приходит тот самый ступор, заставляющий смотреть сериалы даже тогда, когда отдыхать уже не хочется.
Обнаружив неладное, я попробовал изменить подход к планированию. Вместо намерения достигать определённого результата к определённому сроку решил сконцентрироваться на соблюдении определённого расписания. 2-4 часа в будни должно уходить на свои проекты, включая сайт, канал и прочее. Разумеется, это получается не всегда: я стараюсь садиться за работу каждый день, но не винить себя, когда не выходит.
Привычное планирование с таким подходом почти невозможно, но в моих нынешних начинаниях так много неопределённости, что придерживаться планов всё равно не получается. И если поначалу ослабить хватку контроля страшно, спустя какое-то время становится намного легче жить и работать.
В эту пятницу в 17 часов по Москве поговорим про собеседования в большие компании с ребятами из g-mate. Я расскажу про свой опыт с Яндексом, Toptal и Facebook и постараюсь дать рекомендации, которые вы сразу сможете применить на следующем собеседовании. Вебинар будет длиться всего час, так что плотность информации будет высокой. Регистрируйтесь!
Ещё я давно хотел сделать форму для вопросов и актуальных тем, чтобы у канала была более широкая повестка. Вот она: предложить тему для обсуждения.
Ответить подробно на большинство вопросов мне наверное не удастся, потому что вебинар короткий, но я обязательно коснусь каждого в постах на канале. Буду благодарен за ваши идеи и предложения!
Ещё я давно хотел сделать форму для вопросов и актуальных тем, чтобы у канала была более широкая повестка. Вот она: предложить тему для обсуждения.
Ответить подробно на большинство вопросов мне наверное не удастся, потому что вебинар короткий, но я обязательно коснусь каждого в постах на канале. Буду благодарен за ваши идеи и предложения!
Нашёл классный ресурс с “дорожными картами” для разработчиков: https://roadmap.sh/
Особенно полезно и интересно будет тем, кто только начинает или недавно начал, либо тем, кто меняет специализацию. Конечно, это не полная энциклопедия всех возможных навыков (кайф начинается, когда совмещаются специализации - например, backend и devops), но вам наверняка будет интересно сравнить свои знания с commmunity-driven эталоном.
Особенно полезно и интересно будет тем, кто только начинает или недавно начал, либо тем, кто меняет специализацию. Конечно, это не полная энциклопедия всех возможных навыков (кайф начинается, когда совмещаются специализации - например, backend и devops), но вам наверняка будет интересно сравнить свои знания с commmunity-driven эталоном.
roadmap.sh
Developer Roadmaps - roadmap.sh
Community driven roadmaps, articles and guides for developers to grow in their career.
Как разработчику успешно пройти собеседования в FAANG
Для прошедшего в пятницу вебинара об устройстве на работу в крупные компании у меня был конспект (посмотрите запись, если не удалось присутствовать). Вебинар получился короткий, всего на час, и все рекомендации удалось в лучшем случае лишь упомянуть - поэтому привожу их здесь. Надеюсь, вам пригодится.
🤩 Получите рекомендации от сотрудников интересующих вас компаний. Без рекомендации ваше резюме имеет все шансы затеряться среди тысяч таких же и остаться без ответа. После получения рекомендации вам практически гарантирован разговор с рекрутером, а крупные компании платят премии сотрудникам за успешные рекомендации.
📝 Делайте резюме под каждую позицию. Упоминайте только релевантный опыт, а для позиций уровня senior и выше описывайте не только свои достижения в разработке, но и в организации командной работы и найме, достижении бизнес-целей.
⏰ Акцентируйте внимание интервьюера на проектах, в которых вам удалось блеснуть. У большинства ваших собеседников будет совсем немного времени, чтобы ознакомиться с резюме. Поэтому вы можете рассказать не только о самом последнем опыте, а о своих главных достижениях. Подавайте себя с выгодной стороны, но не врите.
👩💻 Подготовьте связный рассказ о себе и своём опыте. Он точно пригодится на поведенческих интервью, а сокращённая версия с примерами успешных проектов и вашими пожеланиями к новой работе - для вводного рассказа о себе на каждой секции. Репетируйте вслух и с диктофоном.
🦾 Отведите несколько месяцев на подготовку к алгоритмическим задачам. Прорешайте не меньше 30-50 задач на Leetcode по разным темам, найдите или придумайте обобщённый алгоритм решения задач и придерживайтесь его. Старайтесь начинать писать код только когда алгоритм решения задачи известен, включая edge-кейсы и его сложность.
📣 Говорите во время решения задач. То, как вы размышляете, не менее важно, чем то, насколько быстро и верно вы находите решение задачи. Ведите диалог с собеседующим, чтобы получать постоянную обратную связь. Если вы не уверены, уточните, что правильно поняли задачу.
⚙️ На system design интервью обозначьте общую архитектуру решения и постарайтесь углубиться в область, в которой вы разбираетесь лучше всего. Ведите себя как техлид, уточняющий требования у заказчика, и двигайтесь от общего к частному. Держите в голове план решения задачи и следите за временем.
🤝 Для позиций высокого уровня ваши софт-скиллы важнее, чем умение писать код. Прокачивайте умение работать в команде - обсуждать, спорить, договариваться. Учитесь презентовать и продавать свои идеи, быть услышанным, принимать чужую точку зрения. Развивайте эмпатию, не поддавайтесь эмоциям и учитесь ладить с другими и собой.
🇬🇧 Учите английский язык. Вашего уровня будет достаточно для прохождения собеседований примерно тогда, когда вы сможете понимать на слух большую часть выступлений с профильных конференций и сможете убедительно рассказать о своих проектах. Продолжайте учиться - выразительность и точность никогда не будет лишней, особенно если вы не носитель языка.
💰 Собеседуйтесь в несколько компаний и старайтесь получить несколько оферов. Это поможет торговаться (в пределах рынка и вилки зарплат на данной позиции) и чувствовать себя спокойнее. Будьте открыты к предложениям рекрутеров, держите их в курсе процесса и сообщайте о получении других оферов.
🤯 Будьте готовы к отказам и не принимайте их слишком лично. Несмотря на стремление объективно оценить каждого кандидата, иногда процесс даёт сбой - и вам попадается собеседующий не в настроении или неудачная задача. Крупные компании придерживаются правила "лучше не нанять хорошего разработчика, чем нанять плохого", поэтому иногда отказывают даже лучшим.
Ну и напоследок: не рвитесь исключительно в FAANG только ради строчки в резюме. Лучше оказаться на своём месте в небольшой компании, делать что-то важное, развиваться и иметь слово в принятии решений, чем быть винтиком в большом корпоративном механизме. Удачи!
Для прошедшего в пятницу вебинара об устройстве на работу в крупные компании у меня был конспект (посмотрите запись, если не удалось присутствовать). Вебинар получился короткий, всего на час, и все рекомендации удалось в лучшем случае лишь упомянуть - поэтому привожу их здесь. Надеюсь, вам пригодится.
🤩 Получите рекомендации от сотрудников интересующих вас компаний. Без рекомендации ваше резюме имеет все шансы затеряться среди тысяч таких же и остаться без ответа. После получения рекомендации вам практически гарантирован разговор с рекрутером, а крупные компании платят премии сотрудникам за успешные рекомендации.
📝 Делайте резюме под каждую позицию. Упоминайте только релевантный опыт, а для позиций уровня senior и выше описывайте не только свои достижения в разработке, но и в организации командной работы и найме, достижении бизнес-целей.
⏰ Акцентируйте внимание интервьюера на проектах, в которых вам удалось блеснуть. У большинства ваших собеседников будет совсем немного времени, чтобы ознакомиться с резюме. Поэтому вы можете рассказать не только о самом последнем опыте, а о своих главных достижениях. Подавайте себя с выгодной стороны, но не врите.
👩💻 Подготовьте связный рассказ о себе и своём опыте. Он точно пригодится на поведенческих интервью, а сокращённая версия с примерами успешных проектов и вашими пожеланиями к новой работе - для вводного рассказа о себе на каждой секции. Репетируйте вслух и с диктофоном.
🦾 Отведите несколько месяцев на подготовку к алгоритмическим задачам. Прорешайте не меньше 30-50 задач на Leetcode по разным темам, найдите или придумайте обобщённый алгоритм решения задач и придерживайтесь его. Старайтесь начинать писать код только когда алгоритм решения задачи известен, включая edge-кейсы и его сложность.
📣 Говорите во время решения задач. То, как вы размышляете, не менее важно, чем то, насколько быстро и верно вы находите решение задачи. Ведите диалог с собеседующим, чтобы получать постоянную обратную связь. Если вы не уверены, уточните, что правильно поняли задачу.
⚙️ На system design интервью обозначьте общую архитектуру решения и постарайтесь углубиться в область, в которой вы разбираетесь лучше всего. Ведите себя как техлид, уточняющий требования у заказчика, и двигайтесь от общего к частному. Держите в голове план решения задачи и следите за временем.
🤝 Для позиций высокого уровня ваши софт-скиллы важнее, чем умение писать код. Прокачивайте умение работать в команде - обсуждать, спорить, договариваться. Учитесь презентовать и продавать свои идеи, быть услышанным, принимать чужую точку зрения. Развивайте эмпатию, не поддавайтесь эмоциям и учитесь ладить с другими и собой.
🇬🇧 Учите английский язык. Вашего уровня будет достаточно для прохождения собеседований примерно тогда, когда вы сможете понимать на слух большую часть выступлений с профильных конференций и сможете убедительно рассказать о своих проектах. Продолжайте учиться - выразительность и точность никогда не будет лишней, особенно если вы не носитель языка.
💰 Собеседуйтесь в несколько компаний и старайтесь получить несколько оферов. Это поможет торговаться (в пределах рынка и вилки зарплат на данной позиции) и чувствовать себя спокойнее. Будьте открыты к предложениям рекрутеров, держите их в курсе процесса и сообщайте о получении других оферов.
🤯 Будьте готовы к отказам и не принимайте их слишком лично. Несмотря на стремление объективно оценить каждого кандидата, иногда процесс даёт сбой - и вам попадается собеседующий не в настроении или неудачная задача. Крупные компании придерживаются правила "лучше не нанять хорошего разработчика, чем нанять плохого", поэтому иногда отказывают даже лучшим.
Ну и напоследок: не рвитесь исключительно в FAANG только ради строчки в резюме. Лучше оказаться на своём месте в небольшой компании, делать что-то важное, развиваться и иметь слово в принятии решений, чем быть винтиком в большом корпоративном механизме. Удачи!
YouTube
Как устроиться в Facebook и Яндекс: 7 рекомендаций
Позвали Олега Громова, фронтенд-инженера из лондонского офиса Facebook (ex. Yandex, Toptal etc.) рассказать, как готовиться к собеседованиям в крупные компании. У Олега есть опыт с обеих сторон: он нанимал технических специалистов в российские и зарубежные…
#вслух
Все мы в существенной степени "продукт среды". Например, я после 9 класса думал не как закончить 10-11 класс получше и поступить в хороший университет, а о том, как бы побыстрее сбежать из школы и начать наконец зарабатывать. Это в 13-14 лет-то! Среда была такая - вечная нужда во всём, привычка выживать. Ну и пошёл настраивать компьютеры, барыжил железками на радиорынке.
Разумеется, это сильно трансформировало меня и как человека, и как профессионала - если я и оптимизировал какой-то параметр в карьере, то, в основном, заработок. Оставлю вам возможность пофантазировать о том, какие последствия могут быть у этой многолетней погони.
Кроме объективной данности жизни - дохода родителей, благополучия исторического периода, характера - есть ещё информационное поле, которому каждый из нас так или иначе принадлежит. Люди моего поколения в детстве вряд ли могли по-настоящему выбирать информационные потоки - в лучшем случае, книги или каналы по телеку, а окружающая действительность была примерно однородной. Девяностые, гаражи и подъезды, хаос, кризис и свобода.
А сегодня? Насколько же круто, должно быть, живётся молодёжи (особенно в пандемию, ха-ха - можно вообще из дома не выходить). В 2020-м нет особенной разницы, живёшь ты в Москве, Лос-Анджелесе или под Волгоградом - при наличии интернета есть возможность находить в сети интересных именно тебе людей, занятия и информацию.
Грубо говоря, у среднего подростка должно быть больше шансов вырасти не наркоманом (пытался подобрать не пошлый синоним слову "успешный", но не смог), а у среднего программиста - узнать, каково это - работать в любой компании или жить в другой стране - и решить, что делать.
И это круто. Не только для молодёжи - хотя интересно, конечно, насколько они этими возможностями реально пользуются. А ещё и для нас, частично состоявшихся, потому что мы фактически можем по-настоящему выбирать, кем быть через "настройку" своего окружения.
Все мы в существенной степени "продукт среды". Например, я после 9 класса думал не как закончить 10-11 класс получше и поступить в хороший университет, а о том, как бы побыстрее сбежать из школы и начать наконец зарабатывать. Это в 13-14 лет-то! Среда была такая - вечная нужда во всём, привычка выживать. Ну и пошёл настраивать компьютеры, барыжил железками на радиорынке.
Разумеется, это сильно трансформировало меня и как человека, и как профессионала - если я и оптимизировал какой-то параметр в карьере, то, в основном, заработок. Оставлю вам возможность пофантазировать о том, какие последствия могут быть у этой многолетней погони.
Кроме объективной данности жизни - дохода родителей, благополучия исторического периода, характера - есть ещё информационное поле, которому каждый из нас так или иначе принадлежит. Люди моего поколения в детстве вряд ли могли по-настоящему выбирать информационные потоки - в лучшем случае, книги или каналы по телеку, а окружающая действительность была примерно однородной. Девяностые, гаражи и подъезды, хаос, кризис и свобода.
А сегодня? Насколько же круто, должно быть, живётся молодёжи (особенно в пандемию, ха-ха - можно вообще из дома не выходить). В 2020-м нет особенной разницы, живёшь ты в Москве, Лос-Анджелесе или под Волгоградом - при наличии интернета есть возможность находить в сети интересных именно тебе людей, занятия и информацию.
Грубо говоря, у среднего подростка должно быть больше шансов вырасти не наркоманом (пытался подобрать не пошлый синоним слову "успешный", но не смог), а у среднего программиста - узнать, каково это - работать в любой компании или жить в другой стране - и решить, что делать.
И это круто. Не только для молодёжи - хотя интересно, конечно, насколько они этими возможностями реально пользуются. А ещё и для нас, частично состоявшихся, потому что мы фактически можем по-настоящему выбирать, кем быть через "настройку" своего окружения.
Не боги горшки обжигают
Классная фраза из обсуждения к статье, написанной по мотивам нашего с Лёшей вебинара полторы недели назад. Читатель отметил, что код “выпускника” из какого-то техногиганта его вообще не впечатлил. А мне кажется, это вполне логично. Вот мой комментарий:
«Разумеется, в фейсбуках работают обычные люди. Чаще всего они заинтересованные, целеустремлённые и продуктивные (система мотивации "выживает" других, как мне кажется), но далеко не обязательно лучшие инженеры.
Более того, сила техногигантов, на мой взгляд, не в их крутейшем коде (хотя и в нём тоже), а в размере (рынка, прибыли, сотрудников). Гипотетически, я бы нанимал как можно больше людей, чтобы проверять как можно больше идей (на микро- и макро-уровнях, внутри существующих продуктов и как совершенно новые инициативы) — ведь всё равно никто не знает что делать. А тут уже относительно абстрактный показатель качества или чистоты кода не слишком важен — вероятно, код будет выкинут, либо, если идея выстрелит, его потом десять лет будут рефакторить уже другие люди.»
Как обычно, в комментариях интереснее, чем в статье: https://habr.com/ru/company/gms/blog/526366/#comments-list
Классная фраза из обсуждения к статье, написанной по мотивам нашего с Лёшей вебинара полторы недели назад. Читатель отметил, что код “выпускника” из какого-то техногиганта его вообще не впечатлил. А мне кажется, это вполне логично. Вот мой комментарий:
«Разумеется, в фейсбуках работают обычные люди. Чаще всего они заинтересованные, целеустремлённые и продуктивные (система мотивации "выживает" других, как мне кажется), но далеко не обязательно лучшие инженеры.
Более того, сила техногигантов, на мой взгляд, не в их крутейшем коде (хотя и в нём тоже), а в размере (рынка, прибыли, сотрудников). Гипотетически, я бы нанимал как можно больше людей, чтобы проверять как можно больше идей (на микро- и макро-уровнях, внутри существующих продуктов и как совершенно новые инициативы) — ведь всё равно никто не знает что делать. А тут уже относительно абстрактный показатель качества или чистоты кода не слишком важен — вероятно, код будет выкинут, либо, если идея выстрелит, его потом десять лет будут рефакторить уже другие люди.»
Как обычно, в комментариях интереснее, чем в статье: https://habr.com/ru/company/gms/blog/526366/#comments-list
Хабр
[Личный опыт] Фронтенд-инженер из лондонского Facebook: как попасть в FAANG?
Как готовиться к собеседованиям, чтобы устроиться в компанию уровня FAANG? Вместе с Олегом Громовым , фронтенд-инженером из лондонского офиса Facebook (ex. Yandex, Toptal etc.),...
⏱ Программист и дедлайн
Мы все сталкиваемся с дедлайнами, и мало кому нравится спешить и перерабатывать, чтобы успеть к сроку. Ладно ещё, когда дедлайны привязаны к внешним событиям - запуску проекта или маркетинговой кампании, но ведь иногда проджект-менеджеры или руководители устанавливают их "для порядка", а по факту - для давления на разработку.
Неприятно, если в компании сформировалась культура неоправданной срочности - скорее всего, стоит искать новую работу, чтобы не сгореть. Либо поучиться какое-то время более умно решать типовые задачи, хотя такое позволят не везде. Но если у компании дальновивдные руководители, они позволят вам - разработчикам, тимлидам, менеджерам - влиять на процесс. Тогда у вас появляется крутая возможность прокачать скиллы и карьеру при наличии дедлайнов, даже взятых начальством с потолка.
Используйте сжатые сроки как предлог для проверки новых технологий, написания библиотеки или фреймворка, упрощаещего жизнь и ускоряющего разработку. Попробуйте внедрить генерацию кода там, где была копипаста шаблонных, склеивающих кусков. Вы можете начать безжалостно приоритизировать задачи: релиз через 2 недели - сильный аргумент против ненужных фич. Всё это зачтётся вам другими разработчиками на код-ревью и адекватным руководством при следующем повышении.
Если вы уже тимлид, включайте политическую смекалку и используйте срочность как аргумент к расширению команды. Активно нанимая, вы научитесь лучше понимать людей и увеличите своё влияние в компании. А команда, нанятая собственноручно, всегда больше уважает, слушает и любит своего руководителя.
Конечно, бывают условия, в которых с жёсткими сроками сделать ничего невозможно - например, в аутсорс-компании, находящейся на грани выживания из-за нестабильного потока заказов. В таких компаниях руководство вынуждено брать новые проекты, ещё не успев (и часто не собираясь) закончить текущие. И программисты нередко оказываются крайними, хоть и переребатывают по глупости руководства - хорошо если за деньги.
В таком случае стоит подготовить резюме, порепетировать собеседования, порешать задачки и уходить. К счастью, на рынке полно отличных компаний и позиций, где вас ждут. А пока вы живёте с дедлайнами, извлекайте из них пользу по максимуму.
Как дела со сроками обстоят у вас в проекте?
Мы все сталкиваемся с дедлайнами, и мало кому нравится спешить и перерабатывать, чтобы успеть к сроку. Ладно ещё, когда дедлайны привязаны к внешним событиям - запуску проекта или маркетинговой кампании, но ведь иногда проджект-менеджеры или руководители устанавливают их "для порядка", а по факту - для давления на разработку.
Неприятно, если в компании сформировалась культура неоправданной срочности - скорее всего, стоит искать новую работу, чтобы не сгореть. Либо поучиться какое-то время более умно решать типовые задачи, хотя такое позволят не везде. Но если у компании дальновивдные руководители, они позволят вам - разработчикам, тимлидам, менеджерам - влиять на процесс. Тогда у вас появляется крутая возможность прокачать скиллы и карьеру при наличии дедлайнов, даже взятых начальством с потолка.
Используйте сжатые сроки как предлог для проверки новых технологий, написания библиотеки или фреймворка, упрощаещего жизнь и ускоряющего разработку. Попробуйте внедрить генерацию кода там, где была копипаста шаблонных, склеивающих кусков. Вы можете начать безжалостно приоритизировать задачи: релиз через 2 недели - сильный аргумент против ненужных фич. Всё это зачтётся вам другими разработчиками на код-ревью и адекватным руководством при следующем повышении.
Если вы уже тимлид, включайте политическую смекалку и используйте срочность как аргумент к расширению команды. Активно нанимая, вы научитесь лучше понимать людей и увеличите своё влияние в компании. А команда, нанятая собственноручно, всегда больше уважает, слушает и любит своего руководителя.
Конечно, бывают условия, в которых с жёсткими сроками сделать ничего невозможно - например, в аутсорс-компании, находящейся на грани выживания из-за нестабильного потока заказов. В таких компаниях руководство вынуждено брать новые проекты, ещё не успев (и часто не собираясь) закончить текущие. И программисты нередко оказываются крайними, хоть и переребатывают по глупости руководства - хорошо если за деньги.
В таком случае стоит подготовить резюме, порепетировать собеседования, порешать задачки и уходить. К счастью, на рынке полно отличных компаний и позиций, где вас ждут. А пока вы живёте с дедлайнами, извлекайте из них пользу по максимуму.
Как дела со сроками обстоят у вас в проекте?
Наткнулся на классную рассылку “Career Advice for Tech Professionals”. Например:
- Как спланировать первый год работы, чтобы произвести хорошее впечатление
- Когда пора уходить с работы
Я сам только что подписался, но тематика и подача (с симпатичными графиками) мне уже нравится. Если читаете на английском, рекомендую.
- Как спланировать первый год работы, чтобы произвести хорошее впечатление
- Когда пора уходить с работы
Я сам только что подписался, но тематика и подача (с симпатичными графиками) мне уже нравится. Если читаете на английском, рекомендую.
Если вы ищите, искали или собираетесь искать удалённую работу разработчиком в зарубежной компании, и у вас есть какие-то вопросы, напишите в личку @oleggromov - с радостью поговорю о вашем опыте и попробую помочь.
А если вы вдруг не читали мои статьи про поиски работы, вот они:
- Как найти удалённую работу за доллары
- Как пройти собеседования на удалёнку за рубеж
- Как торговаться на собеседованиях
- Как найти удалённую работу за доллары
- Как пройти собеседования на удалёнку за рубеж
- Как торговаться на собеседованиях
Каким браузером пользуетесь на рабочем компьютере?
Anonymous Poll
6%
Opera
2%
Edge
18%
Firefox
2%
Brave
13%
Safari
71%
Chrome
10%
Что-то на Chromium
0%
Собираю свой Chromium
0%
Lynx
4%
Посмотреть результаты
Объясню, почему спрашиваю: я сделал Quiken, расширение для хрома, которое помогает учить английский. Практически сразу после публикации в сторе, гугл распубликовал его, потому что у меня нет странички privacy policy. Я её сделаю и обязательно опубликую расширение снова, а сейчас любопытно узнать, нужно ли поддержать ещё какие-то браузеры.
А вообще расширения для хрома - это как телеграм-боты. Их легко делать в одиночку: можно придумать кучу функций, где вообще не нужен бэкенд, а данные можно хранить в Web Storage или IndexedDB прям на клиенте.
PS На скриншоте первый слайд из стора. Их я тоже рисовал сам - чуть ли не с большим удовольствием, чем делал саму софтину 😁
А вообще расширения для хрома - это как телеграм-боты. Их легко делать в одиночку: можно придумать кучу функций, где вообще не нужен бэкенд, а данные можно хранить в Web Storage или IndexedDB прям на клиенте.
PS На скриншоте первый слайд из стора. Их я тоже рисовал сам - чуть ли не с большим удовольствием, чем делал саму софтину 😁
Forwarded from Пять Франков
Владение кодом
В прошлом гостевом посте Виктор давал советы о том, как пройти собеседования в FAANG и другие крупные компании. А что будет после принятия офера? Как преуспеть в корпорации и построить успешную карьеру разработчика?
Придётся упорно трудиться, прокачивать навыки коммуникации, учиться понимать продукт и его пользователей. И конечно, писать понятный, поддерживаемый и надёжный код. Но не только 😜
С вами Громов, и сегодня я расскажу про один из главных навыков современного разработчика и почему он обязательно пригодится вам в большой компании. Я также веду канал о программировании, карьере и предпринимательстве, где примерно раз в неделю публикую авторские заметки подобные этой. Подписывайтесь!
Я работаю в Фейсбуке в Лондоне. До этого — Toptal, Klarna, Яндекс.
Несмотря на очевидную специализацию, каждый день мне приходится взаимодействовать с разными системами, написанными на TypeScript, React, Electron, CG/SQL, C++, Hack/PHP. Кроме использования совершенно разных платформ и языков, нужно хотя бы поверхностно разобраться со всеми компонентами стека, а ещё лучше — понять архитектуру всей системы и детали реализации.
Как и любой программист, я больше люблю работать со знакомым кодом (ещё лучше — написанным собственноручно). Это намного легче, приятнее и эффективнее, чем часами разбираться в чужих абстракциях, добавляя маленькую фичу или исправляя баг.
Раз так, почему крупные компании не поощряют strong code ownership, когда за развитие и надёжность каждого модуля отвечает отдельный человек? Разработчики были бы счастливы, код был бы чист, а техдолг канул бы в небытие.
Тем не менее, за 15 лет моей карьеры — столько же прошло с момента публикации Фаулером классической статьи про code ownership — ни в одной из компаний я не сталкивался с единоличным владением кодом. Каким бы естественным ни казался такой подход начинающим разработчикам, бизнес стремится уменьшить риски при потере ключевых сотрудников — чем больше людей знает, как работает система — тем лучше.
Можно подобрать и исключения. Например, библиотечный код: важные для архитектуры сервисы и модули, которые обычно создаются и поддерживаются отдельными командами, но не конкретными людьми. По Фаулеру, это не единоличное владение кодом, а скорее weak code ownership, когда за систему и код отвечает группа разработчиков.
Другое исключение — одноразовый код какого-нибудь лендинга, который проработает месяц в праздники. Такие вещи делают скорее быстро, чем качественно, и сложности в них немного.
А как в Facebook?
В Фейсбуке любой программист может изменить любой нужный ему кусок кода любой системы. В лучшем случае, он запросит ревью у «авторов», но в некоторых случаях обойдётся и без него. Авторство в такой системе постоянно меняется, и ревьюерами становятся те, кто внёс больше всего изменений в код, либо сделал это последним.
Значит ли это, что архитектура систем неизбежно деградирует, появляется всё больше странных багов и разных реализаций одинаковых функций? Именно так. Но для крупных организаций со множеством команд это существенно лучше, чем риски потери ключевых людей и сильная взаимозависимость команд.
Оттуда же происходит идея монорепозиториев, единой для всех проектов инфраструктуры и утилит — чтобы каждый знал, как код собрать, запустить, протестировать и выложить в продакшн.
Главный навык
Получается, главный навык программиста в современной крупной компании с shared code ownership — не просто писать понятный, поддерживаемый и надёжный код, но и обязательно уметь делать это внутри любой системы, даже той, которую он видит впервые. А свой код проектировать максимально очевидным образом, чтобы будущие изменения минимально влияли на архитектуру и непротиворечивость.
А как организовано владение кодом у вас в проекте? Поделитесь в комментариях.
Это гостевой пост на канале. Если вы тоже хотите поделиться опытом — напишите мне в @winterview_contact_bot
В прошлом гостевом посте Виктор давал советы о том, как пройти собеседования в FAANG и другие крупные компании. А что будет после принятия офера? Как преуспеть в корпорации и построить успешную карьеру разработчика?
Придётся упорно трудиться, прокачивать навыки коммуникации, учиться понимать продукт и его пользователей. И конечно, писать понятный, поддерживаемый и надёжный код. Но не только 😜
С вами Громов, и сегодня я расскажу про один из главных навыков современного разработчика и почему он обязательно пригодится вам в большой компании. Я также веду канал о программировании, карьере и предпринимательстве, где примерно раз в неделю публикую авторские заметки подобные этой. Подписывайтесь!
Я работаю в Фейсбуке в Лондоне. До этого — Toptal, Klarna, Яндекс.
Несмотря на очевидную специализацию, каждый день мне приходится взаимодействовать с разными системами, написанными на TypeScript, React, Electron, CG/SQL, C++, Hack/PHP. Кроме использования совершенно разных платформ и языков, нужно хотя бы поверхностно разобраться со всеми компонентами стека, а ещё лучше — понять архитектуру всей системы и детали реализации.
Как и любой программист, я больше люблю работать со знакомым кодом (ещё лучше — написанным собственноручно). Это намного легче, приятнее и эффективнее, чем часами разбираться в чужих абстракциях, добавляя маленькую фичу или исправляя баг.
Раз так, почему крупные компании не поощряют strong code ownership, когда за развитие и надёжность каждого модуля отвечает отдельный человек? Разработчики были бы счастливы, код был бы чист, а техдолг канул бы в небытие.
Тем не менее, за 15 лет моей карьеры — столько же прошло с момента публикации Фаулером классической статьи про code ownership — ни в одной из компаний я не сталкивался с единоличным владением кодом. Каким бы естественным ни казался такой подход начинающим разработчикам, бизнес стремится уменьшить риски при потере ключевых сотрудников — чем больше людей знает, как работает система — тем лучше.
Можно подобрать и исключения. Например, библиотечный код: важные для архитектуры сервисы и модули, которые обычно создаются и поддерживаются отдельными командами, но не конкретными людьми. По Фаулеру, это не единоличное владение кодом, а скорее weak code ownership, когда за систему и код отвечает группа разработчиков.
Другое исключение — одноразовый код какого-нибудь лендинга, который проработает месяц в праздники. Такие вещи делают скорее быстро, чем качественно, и сложности в них немного.
А как в Facebook?
В Фейсбуке любой программист может изменить любой нужный ему кусок кода любой системы. В лучшем случае, он запросит ревью у «авторов», но в некоторых случаях обойдётся и без него. Авторство в такой системе постоянно меняется, и ревьюерами становятся те, кто внёс больше всего изменений в код, либо сделал это последним.
Значит ли это, что архитектура систем неизбежно деградирует, появляется всё больше странных багов и разных реализаций одинаковых функций? Именно так. Но для крупных организаций со множеством команд это существенно лучше, чем риски потери ключевых людей и сильная взаимозависимость команд.
Оттуда же происходит идея монорепозиториев, единой для всех проектов инфраструктуры и утилит — чтобы каждый знал, как код собрать, запустить, протестировать и выложить в продакшн.
Главный навык
Получается, главный навык программиста в современной крупной компании с shared code ownership — не просто писать понятный, поддерживаемый и надёжный код, но и обязательно уметь делать это внутри любой системы, даже той, которую он видит впервые. А свой код проектировать максимально очевидным образом, чтобы будущие изменения минимально влияли на архитектуру и непротиворечивость.
А как организовано владение кодом у вас в проекте? Поделитесь в комментариях.
Это гостевой пост на канале. Если вы тоже хотите поделиться опытом — напишите мне в @winterview_contact_bot
Какой у вас стаж работы программистом?
Anonymous Poll
11%
Меньше года
14%
1-2 года
20%
3-4 года
9%
5-6 лет
31%
Больше 6 лет
14%
Я не программист