?

Log in

No account? Create an account
Живой Журнал Якова Сироткина Below are the 10 most recent journal entries recorded in the "Яков Сироткин" journal:

[<< Previous 10 entries]

October 3rd, 2019
09:39 am

[Link]

Технологическое банкротство
Есть такое понятие - технический долг. А если есть долг, то должно быть и банкротство. Термин "техническое банкротство" уже используется со своим особым смыслом, поэтому будем говорить "технологическое банкротство". Если по техническому долгу нужно платить проценты в неявной форме в виде лишней инфраструктуры и низкой производительности разработчиков, то технологическое банкротство - это полноценное финансовое банкротство, когда отсталость в технологиях приводит к краху компании. Возможно, именно это произошло недавно с Thomas Cook.

1. Как появляется технический долг

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

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

Часто технический долг возникает просто с течением времени. Например, с выходом Java 5 появилась возможность значительно улучшить весь ранее написанный на Java код. А по мере распространения Python 3 весь код на Python 2 постепенно устаревал, причём в данном случае миграция является серьёзной проблемой. Если когда-то Oracle использовали почти все, то теперь есть много гораздо более дешёвых баз данных.

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

2. Технический долг и человеческий фактор

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

Эта проблема решается новыми людьми, которые могут посмотреть свежим взглядом. Конечно, это должны быть хорошие программисты и они должны быть настроены много работать. Если на добавление ешё одного поля в форму у нового человека уходит весь весь день, потому что нужно поменять код в 10 местах, то нужно найти силы, чтобы выкинуть 3-4 уровня абстракции, чтобы в следующий раз было проще вносить изменения.

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

3. Трудности найма

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

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

Прямо скажем, не так часто встретишь программиста, который с энтузиазмом готов делать из чужого кода конфетку. И мне уже тоже кажется, что лучше работать в небольшой компании, которая захватит мир за счёт использования современных технологий, чем продлить жизнь какому-нибудь динозавру ещё лет на 10.

4. Кто следующий?

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

Tags:

(7 comments | Leave a comment)

August 29th, 2019
08:32 am

[Link]

10 дней до выборов: посвящается JetBrains
Про типичного кандидата на наших выборах обычно нельзя понять, где он работает, как зарабатывает, а по декларируемым доходам видно только то, что он уходит от налогов. На этом фоне отрадно видеть кандидатов, работающих в JetBrains, пожалуй, лучшей компании нашего города. Владимир Волохонский готовился к выбором задолго до того, как пошёл работать в JetBrains, а Слава Тутушкин наоборот — много лет работал программистом, но внезапно решил попытаться изменить окружающую действительность. Третий кандидат, Александр Грибович, выдвинулся в депутаты, но не смог зарегистрироваться в МО Введенский. То есть в JetBrains человек работать может, ума хватает, а вот зарегистрироваться кандидатом на муниципальных выборах — нет, возникают непреодолимые бюрократические трудности.

И я хочу сказать: ребята, вы построили самый шикарный офис, но он находится в Петербурге, где вся власть принадлежит жуликам и ворам. И типичные городские проблемы вроде гололёда, неработающей ливневой канализации и пробок на дорогах убивают всё великолепие. И уж точно наш суд без колебаний посадит любого сотрудника JetBrains на 10 суток, какую бы чушь не написали полицейские в протоколе. Никто не вкладывает в российское образование больше, чем JetBrains, но почему университетских преподавателей бьют дубинками по голове?

Коллеги, я прекрасно понимаю, что вы занимаетесь гораздо более интересными вещами, чем российские выборы. И понятно, что тем, кто уже проработал 5 лет в УИК, это всё давно уже осточертело. Но если вы хотите жить в России, идите наблюдать на выборах. 500 наблюдателей из JetBrains могли бы сильно бы помочь в борьбе с фальсификациями.

Tags:

(1 comment | Leave a comment)

June 20th, 2019
08:32 am

[Link]

Бэкенд на Kotlin?
Допустим, вам нужно сделать бэкенд: не очень сложный, не очень нагруженный, но нужно сделать хорошо, чтобы он бесперебойно работал долгие годы. Понятно, что для контроля версий нужно использовать git, в качестве базы данных можно взять PostgreSQL и если писать на Java, то собирать можно Maven и всё сделать на Spring Boot, это будет максимально стандартное решение.

Но использовать Java нет желания, хочется сразу писать на Kotlin. Какие библиотеки стоит использовать?

Предвижу шквал вопросов про Java и сразу приведу несколько аргументов. Даже заниматься выбором версии Java не хочется. Проект рассчитан на большое светлое будущее и через 5 лет доля Kotlin на рынке разработки существенно вырастет. И так как мы собираемся инвестировать в разработку несколько лет, то не хочется тратить время на NPE и проблемы, уходящие корнями в прошлое столетие.

Tags: ,

(5 comments | Leave a comment)

April 11th, 2019
07:43 am

[Link]

Full-stack или нет?
Не видел доклад Антона Кекса на JPoint, но посмотрел слайды и хочу об этом поговорить. Конечно, если проект может быть сделан одним человеком — это здорово, не надо нанимать команду. Но скорее всего это будет очень маленький проект. Безусловно, современные стандарты поддержки начинающих позволяют очень быстро освоить большинство новых технологий. Если раньше требовалось штудировать документацию, то теперь может быть достаточно посмотреть видео. И, действительно, есть люди, которые очень много знают, потому что сначала они программируют на работе, а потом ещё дома изучают всё новое. Но не стоит рассчитывать нанимать исключительно таких специалистов — у них обычно много альтернативных предложений. Разумеется, программист должен понимать смежные области, например, для серверного программиста было бы естественно разбираться в базах данных и быть способным сверстать простую веб-страничку.

Но тезис, что full-stack разработчик будет больше зарабатывать — очень спорный. Чтобы выйти на миллионную аудиторию важнее сделать качественный продукт, а не нанять поменьше разработчиков. Автоматическое тестирование — это хорошо, но разработчику будет тяжеловато конкурировать в качестве тестирования с тестировщиком, для которого это основная специализация. Возможно, у универсально специалиста получится больше вкалывать за счёт разнообразия видов деятельности, сначала 6 часов программировал, потом 6 часов тестировал, получился 12-часовой рабочий день. Но это сомнительный путь. Также программист может настроить мониторинговую систему, чтобы она слала сообщения ему лично, но обычно программисты не осуществляют круглосуточную поддержку. И я верю, что парное программирование повышает производительность труда, но это жёсткий режим, обычно программисты работают в гораздо более комфортных условиях.

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

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

По моему опыту, хорошее программное обеспечение — это много раз переписанное недостаточно хорошее программное обеспечение. И даже после релиза нужно ещё несколько итераций, чтобы исправить различные недостатки. Для проектов с большой аудиторией важно выпускать новые версии не только качественно, но и быстро. Очевидно, что они все делают ставку на узкую специализацию — кто-то занимается авторизацией, кто-то платежами, кто-то базой данных, кто приложением для iOS, кто-то под Android. Конечно, современный программист должен быть морально готов к радикальной смене используемых технологий, мало кому удаётся хотя бы 10 лет заниматься однотипными проблемами. Но в рамках одного проекта обычно ставка делается на специализацию, а не на универсальность.

Tags:

(4 comments | Leave a comment)

March 6th, 2019
07:25 am

[Link]

Agile и реальность
Многие любят поговорить о своём аgile, но если присмотреться поближе, то оказывается, что от agile остались только рожки да ножки. И это не очень удивительно, потому что на многие актуальные сейчас проблемы agile не даёт ответа.

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

2. Хорошие инженеры дорого стоят, их трудно найти и ещё трудней удержать. Многие проекты объективно не могут привлекать лучших специалистов, у них нет для этого ни бюджета, ни амбициозных задач. Если программист по характеру ленив, то возможно, он не только работает без фанатизма, но и по собеседованиям не ходит. При определённых условиях это может быть очень ценный специалист, потому что раз в год нанимать нового человека на эту позицию может быть очень некомфортно. И если говорить о специфике аутсорсинга, то если заказчику продали 4-х программистов, то заказчик своё получит, даже если придётся привлекать интернов без опыта работы.

3. У современных инженеров есть узкая специализация. Даже если речь идёт про веб-приложение, то разработка фронтенда уже требует наличия в команде специалиста по фронтенду. А если нужно мобильное приложение, то добавляются разработчик под iOS и разработчик под Android. Плюс тестировщик, плюс админ, да ещё помножить на 2, чтобы люди могли в отпуск ходить. Получается, что команда легко может дорасти до проблем с коммуникацией, да ещё и задачи должны выполнятся соответствующими специалистами.

4. Отсутствие дедлайнов. Это немного парадоксальный пункт, потому что обычно маленьких детей пугают дедлайнами. Но agile как раз умеет показывать максимальную эффективность в ограниченное время: расставляем приоритеты, заранее отбрасываем то, что не успеваем, и вперёд. Но в больших компаниях люди часто привыкают постоянно переносить сроки, поэтому мотивация работать с полной самоотдачей пропадает.

5. Злоупотребление гибкостью. Agile предполагает, что могут измениться внешние обстоятельства, могут быть внезапно обнаружены ошибки в архитектуре — к этому люди обычно готовы. Но если техническое задание изначально написано очень плохо, а начальство потом начинает хаотично вносить изменения, то энтузиазм у инженеров быстро пропадает.

Tags:

(3 comments | Leave a comment)

December 7th, 2018
07:45 am

[Link]

Трудности highload
Тема высоконагруженных приложений очень популярна среди программистов и на профильных конференциях очень много докладов на эту тему от представителей известных компаний. Обычно докладчик сначала немного рассказывает о себе, о проекте, о стоявшей перед командой задаче. Потом переходит к технологиям, которые они выбрали. Затем описывает архитектуру решения, как тестировали и как внедряли. Возможно, упомянет о каких-то специфичных технических проблемах. И тут доклад заканчивается.

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

Например, мы недавно запустили новый кластер Redis. Внезапно оказалось, что если увеличить кластер, то одна из машин остаётся под высокой нагрузкой. Понятно, что это потенциальная проблема и нужно разбираться. Оказалось, что при batch-запросах redisson всегда отправляет запрос на первую машину в кластере, а она уже делает редирект на машину, где эти ключи на самом деле лежат. Правильное поведение — вычислить на клиенте по первом ключу нужную машину и послать запрос сразу на неё. Я не принимал участие в совершении этого производственного подвига, но хочу отметить, что был настроен мониторинг, были люди, которые по данным мониторинга заметили, что масштабирование не совсем горизонтальное и был программист, который залез в исходный код redisson и разобрался, что происходит.

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

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

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

Tags:

(7 comments | Leave a comment)

December 5th, 2018
07:22 am

[Link]

Что можно сделать за 3 месяца?
Когда-то я писал про то, что могу прийти на новый проект и 2 месяца наносить пользу. Идея была в том, чтобы не тратить время на ритуалы, связанные с постоянной работой, а сразу договариваться на временный контракт и сосредоточиться на причинении максимальной пользы. На свою нынешнюю работу я вышел в самом конце мая и вспоминал свои слова с лёгкой иронией, потому что первые 2 месяца я только входил в курс дела, и осознавал, как тут всё устроено.

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

Пожалуй, в большинстве проектов просто нет необходимости делать такие масштабные изменения единым пакетом. При этом мы уложились в 3 месяца, над новым модулем работало только 2 программиста и параллельно мы ещё много разного сделали. Если у вас 8 человек полгода пишут прототип, то, скорее всего, ваш процесс разработки не очень эффективен, возможно, вы просто тратите деньги.

Конечно, у нас есть вакансии, работы хватит: https://spb.hh.ru/employer/3266823.

Tags:

(Leave a comment)

August 1st, 2018
08:42 am

[Link]

Зачем нужны опционы
В 41 год я впервые устроился на работу, где есть содержательные опционы и их дают программистам. Есть повод написать, зачем они нужны. Допустим, что основатели компании хотят в перспективе продать её (наши уже так делали несколько раз). Предположим, что продать они её хотят за инстаграм долларов. Понятно, что зарплату придётся платить выше средней по рынку, иначе толковые специалисты будут разбегаться в разные стороны. Но можно ли прибавить всем к месячной зарплате тысячу долларов и надеяться, что потом получится продаться за инстаграм? План весьма сомнительный, потому что 20 человек по 12 тысяч долларов каждому — это 240 тысяч долларов в год: смешные деньги по сравнению с амбициями по продаже компании за инстаграм. И эти дополнительные деньги надо ещё где-то найти! Гораздо проще договориться, что в случае продажи компании 10 процентов получат сотрудники (разумеется, цифры я называю из головы, они не основаны на реальных данных). С одной стороны, основатели вполне могут поделиться плодами своего успеха с командой, а с другой — у работников есть мощный стимул, чтобы продажа всё-таки случилась.

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

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

Да, у нас ещё открыта вакансия программиста — https://spb.hh.ru/vacancy/25683991

Tags:

(9 comments | Leave a comment)

July 31st, 2018
08:06 am

[Link]

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

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

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

Некоторые программисты страдают от переработок. По российскому законодательству переработки оплачиваются в двойном размере. Если есть задачи, которые оплачиваются вдвое лучше, то зачем делать обычные? Иногда бывает, что нужно работать на выходных, потому что выкладки новых версий только по субботам или у заказчика этот день рабочий и кто-то должен быть доступен, но использовать переработки, чтобы избежать срыва сроков — это плохая идея. Обычно я довольно плотно работаю в начале итерации, когда есть много открытых задач — аврал должен быть на старте, а не на финише, ближе к релизу проект должен стабилизироваться. Иногда я могу программировать по 10 часов в день, если пытаюсь побороть какой-то странный баг или делаю какие-то большие изменения, но обычно важные изменения требуют обсуждения и согласования, сделать их быстро не получается, да и не имеет смысла. Работа по 70 часов в неделю — это для меня очень плохой знак и такого опыта у меня нет.

Ещё одной особенностью работы программиста могут являться командировки. Много лет оказывалось, что я вполне могу работать и в Питере, а встречаться с заказчиком поедут другие. Потом я пошёл работать в Яндекс и был реальный шанс провести несколько месяцев в Москве, но я стал ездить на 3 дня каждые 2 недели — получилось достаточно продуктивно и без больших потрясений для семьи. Самая большая командировка у меня была на 2 месяца в Калифорнию и при всей нашей семейной любви к путешествиям я как-то сразу заскучал по дому. Нужно отметить, что командировочные — это в некоторых компаниях очень существенная прибавка к зарплате, но, пожалуй, не так плохо, что я в своей карьере избежал большого количества длинных командировок.

Уже много лет по миру ходит идея о 20% проекте, я считаю, что это просто провокация. Я могу очень настойчиво эскалировать проблемы по основному проекту, если считаю их достаточно важными, но второстепенный проект — да наплевать на него. При этом не так давно я взял на работе второй компьютер и параллельно работал над дополнительным проектом. Сделал, компьютер отдал. То есть в принципе можно делать два проекта, но только если это естественным образом получилось, а не потому что основная работа не нравится.

Многие считают, что программист должен радоваться изучению новых технологий, а иначе ему будет скучно. По-моему, я — не такой. Конечно, если будет возможность, я без колебаний начну программировать на Kotlin. Потому что мне нравятся в идеи, которые в нём заложены, нравится команда, которая за ним стоит и я считаю, что Kotlin завоюет мир. Но просто изучить технологию X, использование которой в данном проекте ещё и не факт, что оправдано — это звучит не очень вдохновляюще.

Программистов часто советуют заниматься какими-то своими открытыми проектами, но у меня никогда не было амбиций сделать что-то великое самому в свободное от основной работы время. Кто-то справился, но у меня не было идей, в которые я готов был вложить столько труда, чтобы превратить их в популярный продукт. Зато я 10 лет делал JUG.RU. В последние несколько лет я занимаюсь анализом состава УИК в Петербурге — общественно-значимая деятельность с элементами программирования, но в основном много довольно скучной работы.

Не трудно заметить, что я много внимания уделяю современной российской политике. Скажу прямо — трудно представить тему более токсичную. Как-то переживать эти потоки дерьма мне помогают занятия спортом 7 дней в неделю: 4 раза баскетбол, 2 раза настольный теннис и 1 раз дорожка-турник-бассейн. Баскетбол довольно часто выпадает из графика и тогда получается больше фитнесса. Я и раньше любил заниматься спортом, но сейчас явно ощущаю, что спорт помогает поддерживать душевное спокойствие.

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

Tags:

(21 comments | Leave a comment)

July 11th, 2018
08:32 am

[Link]

Хватит ли России программистов?
В силу своего профессионального опыта и бурной общественной деятельности я всегда был склонен думать, что смогу найти квалифицированного программиста без особых проблем и действительно находил по мере необходимости. Но за последний месяц уволились двое моих коллег, один из них уже в лондонском Facebook, второй тоже уезжает. А на предыдущем месте работы весь бизнес строился на длительных, вплоть до переезда, командировках в Штаты. И тут я осознал, что очень, очень многие из моих знакомых, с кем я хотел бы работать, уже уехали из России.

Лет 10 назад на конференции в Москве я слушал доклад человека из Facebook, который говорил про то, что если вам нужно 3 человека, наймите 2, если нужно 4, наймите 3. Сейчас Facebook вошёл во вкус и набирает крайне агрессивно. И не только он. В результате получается, что если программист живёт в России, то либо его не берут в Facebook, либо он не хочет уезжать из России. Увы, но в первом случае шансы создать конкурентоспособный продукт примерно равны нулю.

А теперь придётся сказать о политике: что наше государство делает для того, чтобы программисты оставались в России? Два слова: LinkedIn и Telegram. Мало есть энтузиастов, которые готовы вести политическую борьбу в свободное от основной работы время. Гораздо естественней просто переехать в другую страну, особенно если детей нет и квартиру приходится снимать. Врачи, учителя и многие другие тоже хотели бы уехать, но у программистов есть возможность: специально обученные люди придут, аккуратно запакуют все вещи и отправят в другую страну за счёт нового работодателя.

В принципе, это нормально что люди переезжают и государства конкурируют между собой, чтобы привлечь к себе больше налогоплательщиков. Но из России поток идёт в одну сторону. Вот в Латвии живёт много русских, но они почему-то не переезжают в Россию. Конечно, можно приводить примеры, какие у нас есть хорошие IT-компании, но лучшие программисты уже много лет работают преимущественно на экспорт, а из-за тех мерзостей, которые в нашей стране регулярно происходят, они и налоги начинают платить в других странах.

Tags:

(10 comments | Leave a comment)

[<< Previous 10 entries]

Telamon.RU Powered by LiveJournal.com