Какой бывает обычно график программиста удаленно работающего с зарубежными компаниями?

Question

[hero_hamada]

Суть в том что мне предлагают работу с разными сменами, то есть в один день я могу работать 5:00-13:00, а в следующий день 21:00-6:00. И график заранее составляют на неделю примерно. Я не плохо могу работать, понимать и кодить,и ночью, и с утра, но мне интересно был ли у вас такой опыт работы с разными сменами, от этого не будет ли мозг плохо варить и выполнять свои обязанности? Или главное высыпаться нормально в отведённое время, а в какое время суток будешь работать это не важно, так как с иностранными компаниями удаленная работа подразумевает всегда это? Я пока начинающий программист с опытом работы всего 3 месяцев.

Comments

[Виталий Першин]

Если ночью привыкли спать, то лучше продолжайте спать ночью, ночные смены до добра не доведут..

[Одиночка Айс]

Сменная работа подразумевает перерывы. Типа сутки через 2 или 3. А не так, что каждый день, как кому-то там хочется. На твое здоровье всем плевать, АБСОЛЮТНО всем.

[pavelsha]

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

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

Можно найти истории, как например, во франче 1С молодые разрабы приходили в 7-30 , 8-00 на работу прямо от девок или из клубов. И всем было паралельно пока не пришли сильно мятыми и с финалами.

Ну и как противоположный пример расскажу про программиста в Энтерпрайзе. Который завис в статусе Джуниора, потому что магистрант и очень любит поспать минимум до 10 утра. И работает полставки с 12-00

Answer 1

[Saboteur]

Какой бывает обычно график программиста удаленно работающего с зарубежными компаниями?

1. 40 часов в неделю на усмотрение разработчика, плюс созвоны в запланированное время
2. стандартное время работы с 9-10-11 утра до 5-6-7 вечера, плюс созвоны в запланированное время
3. Зарубежные компании могут быть в Европе или Японии или Китае, где часовые зоны могут совпадать практически полностью.

Если говорить про американские компании, то там все может быть как угодно. Но программист это же не саппорт. По идее график может быть гибкий, и если заказчик требует работу по "сменам", то это разработка связана с поддержкой?

Comments

[hero_hamada]

Спасибо за ответ, да работа будет в основном с сша и мексикой и связана с поддержкой, но команды разработчиков будут. И по словам работодателей, они думали, что многим не понравится что именно support, а не разработка.
А начинающим support не подходит?
Можете рассказать, в чем их различие, что лучше для начинающих?
Почему программист не саппорт?
Простите, если задаю глупые вопросы. Я не особо представляю, так как сейчас я занимаюсь в основном bugfixing-ом разрабатываемых продуктов.

[Saboteur]

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

Есть проекты, которые были написаны и просто используются. В них ничего нового нет, только поддержка (устранение багов, миграция и адаптация продукта под новые версии библиотек, технологий, операционных систем, версий платформы (например продукт работает под java8 и нужно адаптировать под java11, или продукт написан под php 5.2, надо переделать под новую). Работу теоретически может сделать и джуниор.

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

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