Человеческий мозг ленив, поэтому все мы любим определенность. Ведь так приятно получить четкий ответ: "так делай", "так не делай", "результат будет через 2 дня"... Но в IT четких ответов не бывает, и даже из самых очевидных правил есть исключения
1) Английский - самый важный из языков
Английский - главный язык международного общения, и в совместном проекте с условными монголами вы будете коммуницировать именно на английском. Да даже во внутрироссийской разработке все переменные, классы, объекты БД мы называем английскими именами (хотя бы чтобы проблем с кодировкой избежать). И, тем не менее, существуют ситуации когда лучше вкладываться в изучение другого иностранного языка.
Предположим вы решили переехать в Мексику и даже нашли там работу. В офисе. Переменные и объекты БД все также будут английскими, как, наверное и общение в мессенджере. А вот коммуникация за чашечкой кофе - вряд ли. Есть шанс, что и техническое задание будет на испанском. Так не лучше ли в этом случае сосредоточиться на местном языке?
2) Не меньше одного коммита в день
Понятный каждому совет: поработал - сохрани результат. Как "поймал нарушителя - составь протокол" для сотрудника ДПС или "проверил контрольную - поставь отметку" для учителя. Но у разработчиков результат не всегда детерминированный.
Вполне типичная ситуация: конец рабочего дня, человек написал код, ничего лучше придумать не может. Запускает...а там рекурсия. Или Exception. Или жуткое нарушение безопасности. Сохраниться в этом случае = потенциально нанести вред продукту. Даже если не в ветку master. Куда лучше оставить свое творчество на локальном компьютере, чтобы завтра с новыми силами вернуться к решению проблемы.
3) Хочешь расти на проекте - разбирайся с бизнес-логикой
Заказчик платит не за красивый код, он платит за решение своих проблем. Погружаясь в бизнес-логику мы начинаем говорить с заказчиком на одном языке, лучше понимать его желания и становиться более ценным сотрудником. В принципе логично.
Но не без исключений. Есть такая профессия - пожарный. И на работе пожарный не думает о личностном росте и успешном успехе, ему надо людей спасать. Программистам людей спасать не надо, но иногда надо спасать проект. Быстро, по инструкции, без лишних вопросов. И когда менеджер не может оформить кредит из-за 'missing ; before statement' надо вставлять эту несчастную ';', а не выяснять, кто клиент вашей фичи и какие у него цели.
4) Начинающему специалисту лучше работать в офисе
Безусловно, в офисе молодому специалисту проще развиваться. Здесь ты более заметен, знаешь к кому обратиться по тому или иному вопросу, а за счет общения в неформальной обстановке еще и более спокоен.
Но что если человек живет в райцентре на 30 тысяч человек и учится в местном ВУЗе/колледже? Есть подозрение, что IT-компаний в таком райцентре около нуля, так не лучше ли вместо "бросить всё и рвать отсюда когти" развиваться более постепенно? Например, не отрываясь от учебы найти удаленную стажировку, а затем переехать в город покрупнее уже образованным и опытным человеком? Хотя да, по итогу все равно лучше переехать в город покрупнее)
Если знаете хоть одно IT-шное правило без исключений буду рад увидеть вас в комментариях