Как эффективнее управлять своим временем «на удалёнке»

Кажется, посты на тему организации рабочего дня в условиях фриланса или удаленной работы стали уже доброй ежегодной традицией, так что продолжу эту тему и сегодня.

Итак, если вы работаете из дома, и в целом не очень-то стеснены временными рамками - начать и закончить рабочий день можно практически в любое время - то есть вероятность попасть в непродуктивное состояние и застрять в бесконечном цикле прокрастинации.

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

Из-за этого же рабочий день толком никогда не кончается, и можно поймать себя, что ты работаешь и в 11 вечера, и в час ночи, хотя при нормальном раскладе стоило бы закончить в 7. И постоянно находишься либо во сне, либо в полуработе-полупрокрастинации.

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

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

Отказывать себе в отдыхе и развлечениях - непродуктивно. Они нужны не меньше, чем работа. Но на них лучше выделять отдельные от работы интервалы времени. Например, используя «метод помидора» - ставите таймер на 20-30-40 минут, и этот интервал посвящаете строго работе. После окончания интервала обязательный перерыв 5-10-15 минут - посвящаем исключительно отдыху. Потом снова интервал работы. Таким образом рабочие задачи не перемешиваются с развлечениями и тайм-киллерами.

Дальше - рабочий день обязательно нужно заканчивать, и отделять от личного времени. В конце рабочего дня хорошо придумать какой-нибудь ритуал, который будет означать, что на сегодня с работой окончено, и дальше начинается свободное время. Можно каждый день после окончания рабочего дня выходить на прогулку, или совершать мини-уборку, или отжиматься/приседать, или еще что-то подобное придумать. Когда люди ездят в офис, в качестве такого ритуала выступает дорога из офиса домой. Работая из дома, полезно придумать какой-то аналог. Мозгу нужно понимать, что теперь можно переключиться в другой «не рабочий» режим.

Удаленка и фриланс могут убить любой распорядок дня, и этому процессу стоит сопротивляться, привязывая дела к определенному времени. Иначе и работа, и прочие планы расползаются во времени и по-настоящему свободного времени не остаётся вовсе. А это чревато выгоранием.

#вашивопросы

Здравствуйте, как научить себя учиться?

Первое, что приходит в голову - это курсы на тему «learn how to learn» - можно загуглить такие. Точно видела нечто подобное на курсере. На русском языке нашла несколько таких вариантов:
- Как учиться эффективно
- Секреты дистанционного обучения
- Экспресс-обучение умению учиться

Сама, честно говоря, в эту тему не углублялась, и методик не знаю.

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

Задать вопрос автору блога можно здесь: @hum_it_bot

#вашивопросы

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

Ну что касается новости - сейчас программ переподготовки примерно как грибов после дождя. У меня самой есть диплом о профпереподготовке, но знаете что - кажется, на трудоустройство где-либо он не повлиял вообще никак.
Он скорее нужен для ощущения «у меня есть диплом». Профпереподготовка - это скорее курсы, чем полное высшее образование.

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

Поэтому будем отталкиваться от общих законов, царящих на рынке труда.

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

Иногда требования в вакансии могут появляться фиг пойми почему.
«Потому что так обычно пишут», «потому что это наверно нужно», «потому что мне кажется, что такой кандидат будет лучше».
И никаких рациональных причин за ними не стоит.
О техническом образовании может написать девушка-рекрутер просто потому что ей кажется, что так нужно.
А может, начальник отдела - убежденный сторонник наличия 5-6 лет вузовской подготовки, и не верит в кандидатов без такого бэкграунда.
Не факт, что у него есть рациональные аргументы. Всё бывает очень по-разному.

Вообще вдумайтесь - техническое образование - это очень широкий термин.
Можно быть специалистом в области металлургии, авиации, нефти и газа, химии итд итп - и не иметь никакого отношения к IT.
Иногда словосочетание «техническое образование» - это всего лишь мантра, заклинание.
Думаете, знания в области химии помогут писать код?

Что же касается компетенций, которые приобретают в ВУЗе, и которые ценят некоторые работодатели - скорее всего, речь идёт о математике, и более глубоких знаниях в области информатики, чем можно получить на коротких курсах - полистайте вузовские программы для IT-специалистов, там будет список предметов.

Курсы часто сосредоточены вокруг непосредственно разработки, языков программирования и Data Science, а в ВУЗах программа включает более широкий набор предметов - архитектуру компьютера и сетей, операционные системы, компиляторы, микроконтроллеры, криптографию, где-то - акцент на микроэлектронике, где-то - на большом количестве математических дисциплин.

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

Что же касается вакансий, где указано техническое высшее образование - напоминаю, что требования в вакансиях можно игнорировать, и всё равно на них откликаться.
Если вакансия кажется вам подходящей, скажем, на 70% - значит имеет смысл попробовать, может, вы понравитесь работодателю.
Часто в вакансиях описывают «идеального кандидата» - то есть такого, каких не бывает. А брать на работу придется тех, кто реально существуют.

Задать вопрос автору блога можно здесь: @hum_it_bot

Почему курсы могут «не сработать»

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

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

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

Ниже опишу несколько причин, которые по моему мнению, могут быть основными:

1. Неправильная мотивация. Вы хотите в IT почему? Чтобы что? Да, эти профессии востребованы на рынке, и там зарплата выше рыночной - но это само по себе недостаточная мотивация.

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

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

Как это пофиксить: искать область, кооторая вас действительно увлечёт. Это может быть программирование, или что-то другое - главное, поймать «поток», почувствовать, что сам процесс, например, разработки вам приятен, и вы готовы этим заниматься подолгу и с увлечением. Это же касается и готовности искать информацию самостоятельно, интересоваться, копать вглубь.

2. Завышенные ожидания о результате. Разработка и IT - это не совсем то ремесло, которому можно научиться чисто механически, и без особых усилий, и потом выйти на работу и бесконечно повторять одно и то же несложное действие, которому вас научили ‌в‌ ‌П‌Т‌У‌ на курсах. Большинство вакансий в IT требуют готовности экспериментировать, придумывать свои решения, пробовать новое, работать с до того незнакомыми технологиями. Это интересно, но этому не научишься заранее, учатся уже «в бою». А если у вас настрой «научите меня печь пирожки, и я буду всю жизнь их печь одинаково» - это, вероятно, не сработает.

Как пофиксить: вашей целью должно быть не просто выполнение всех «домашних заданий» и получение какого-то сертификата на выходе. Поставьте себе цель - научиться самостоятельной работе над проектами. Чтобы преуспеть, вы должны уметь сделать нечто работающее «с нуля» и без подсказок (гугление не в счет). Если речь идет о веб-разработке - то, очевидно, это должен быть свой сайт (лучше много сайтов). Если о гейм-деве - то игра, и так далее, и тому подобное. А к курсам лучше относиться как к знакомству с инструментами - вот есть отвертка, она нужна для этого и этого, вот молоток - он для другого. Ваша же задача - набить себе руку, и научиться делать что-то полезное с помощью отвертки и молотка.

​​Если вы уже знакомы с основами программирования и системного администрирования, но хотите освоить смежную высокооплачиваемую профессию и повысить свою квалификацию, то этот курс для вас!
Вы узнаете:
⚡️что такое CI/CD и зачем они нужны;
⚡️как работать с Git из консоли;
⚡️зачем нужна виртуализация и контейнеризация;
⚡️как установить Prometheus и Grafana;
⚡️основы управления инфраструктурой и конфигурацией и много другое.

👉Переходите по ссылке и регистрируйтесь. Первые 3 месяца обучения бесплатно!▶️ https://clc.to/nVNfbQ.

Для тех, кто спрашивал про скидки у Гикбрейнс, сейчас у них наконец появились сентябрьские скидки, запоздало, но лучше поздно, чем никогда.

На что действуют акции:
- 10% на факультет и профессию «Геймдизайн» и факультет «Разработка игр на Unreal Engine»
- 20% на факультет «Разработка на С++», «Разработка игр на Unity», «2D-художник игр»
- 30% на факультет «Игровая аналитика»
- До 30% Разработка на Python, Тестирование ПО, Веб-разработка и другие факультеты, а также на курсы по аналитике
- 30% на факультет «Управление персоналом»
- 20% на факультеты «Проджект-менеджмент» и «Продакт-менеджмент»
- 10% на факультет «Руководитель проектов в строительстве» (не знала, что у них даже такое есть).

По официальным условиям, акции действуют до 30 сентября. Будут ли они продлевать скидки на октябрь, пока не знаю.

Как чтение может принести вред

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

Часто начинающие айтишники проникаются этузиазмом, подписываются на всё подряд и начинают читать кучу разных случайных статей на технические темы - то, что выходит на Хабре, в десятках телеграм-каналов, посвященных разработке и тому подобное.

Казалось бы, что с этим не так? Разве может любознательность навредить?

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

Особенно в этом смысле удивляют телеграм-каналы в духе «случайные факты обо всём подряд». В первом посте будет написано про какую-то особенность JavaScript, во втором - про веб-фреймворк к Java, в третьем - как настраивать MongoDB.

Вот прочитаете вы эти три статьи - и они вам как помогут, если вы никогда не работали и в ближайшее время не планируете работать ни с JS, ни с Java, ни c MongoDB? Отвечу за вас - никак они вам не помогут. Попытка нахвататься случайных фактов обо всём подряд, максимум - заполнит вашу кратковременную память, и вскоре вся информация оттуда улетучится.

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

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

#вашивопросы

Привет! Прохожу сейчас cs50 (огромное спасибо за рекомендацию!). Возник такой вопрос: сколько времени у вас уходило на один раздел, такой, как week 2, к примеру? Требовалось ли просмотреть/прочитать лекцию несколько раз, подождать, чтобы она "уселась" в голове? Поэкспериментировать с элементарными вещами, посоздавать arrays, посмотреть как они себя ведут — прежде, чем переходить к лабам и задачам?

Ну время я не засекала, но вообще я, как правило, слушаю лекции всего 1 раз. Перематываю и переслушиваю я только те места, в которых не поняла материал или что-то не расслышала. Тут нет универсальных стандартов - если лично вам мало 1 раза, слушайте больше.

Кстати, советую попробовать слушать лекции и прочие учебные видео в любых курсах не на изначальной скорости, а чуть быстрее - x1.5, x2, x3 - чем медленнее речь лектора, тем быстрее можно ставить скорость. Это для кого-то может прозвучать непривычно, но на более высокой скорости информация может усваиваться гораздо лучше, на эту тему даже были какие-то исследования. А медленная речь наоборот - ухудшает концертрацию слушателей. Главное - найти комфортный для вас темп.

Что касается самостоятельных экспериментов с материалом после лекции - это я делала в тех случаях, когда мне было интересно и хотелось что-то попробовать, повникать. То есть железного правила в духе - «что-то обязательно делать после лекции и до лабы» у меня не было, это всегда был вопрос желания. В каких-то случаях я сразу переходила к лабам, в каких-то нет.

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

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


Задать вопрос автору блога можно здесь: @hum_it_bot

#вашивопросы

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

Под твёрдыми знаниями я подразумеваю хотя бы примерно представлять, что нужно делать с проектом и что нужно гуглить и как применять нагугленное правильно и подходит ли эта информация для проекта😂

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

Насколько я понимаю, речь идёт о каком-то небольшом курсе по Python, и больше вы ничего не изучали, к примеру, базы данных, сети, ОС Linux итд? Если это так, то на данном этапе у вас может быть представление о Python примерно как об умном калькуляторе для обработки чисел и текста. При этом более широкого представления о Computer Science и о том, как там что работает может и не быть. Если это так, я бы рекомендовала курс для углубления в тему - например, для этих целей я всем советую CS50 (можно набрать в поиске по постам в канале).

С другой стороны - вот вы пишете, что не знаете, «что делать с проектом» - а этого вы и не узнаете, пока вы не начнёте работать с настоящими проектами. А где еще с ними можно начать работать, кроме как на настоящей работе? Поэтому, если вы найдете работодателя, готового вас взять на стажировку - конечно же идите на стажировку, как раз прокачаете свой опыт и заодно страх поиска работы - я вижу, что у вас он есть. Если пока вас никто не готов брать - тогда собирайте обратную связь, спрашивайте на собеседовании, каких вам знаний недостаёт по мнению работодателя, обычно на такие вопросы все охотно отвечают - сможете составить список тем для изучения.

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

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

Так что лучше всего найти время и поспать днём минут 20-30. Это поможет повысить работоспособность. Но дольше 30-40 минут днем специалисты спать не советуют.

Задать вопрос автору блога можно здесь: @hum_it_bot

#вашивопросы

Проходили ли вы CS50 и курс по питону одновременно, или сначала закончили один, а потом начали другой? Если одновременно, не приходилось ли бороться с путаницей в голове из-за разницы между C и питоном?

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

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

Если у вас возникает путаница в голове, то попробуйте больше сравнивать 2 языка друг с другом и, возможно, даже выполнять одни и те же задания на обоих языках по очереди. У Python тоже Си-подобный синтаксис, просто нужно запомнить, какие конструкции в Си обозначаются по-другому в Python. Например, там где в Си используются фигурные скобки { }, в Python чаще всего идёт двоеточие : и отступы на следующей строке.

И второй момент, о котором стоит себе напоминать - язык Python фактически написан на Си (точнее, на си написан самый распространенный интерпретатор для Python, CPython, но в этом контексте это уточнение не так важно).

Так что можно считать, что Си - это как бы «нижний слой» питона, то, что у него под капотом. И, изучая, например, структуры данных в Python, можно заодно поинтересоваться, как они написаны, и на каких структурах языка Си основаны. Например, list в Python основан на массивах в Си, с некоторыми дополнениями и удобными методами. Поизучайте массивы и списки в Python, и проанализируйте, чем они отличаются, и чего язык Python добавил нового в концепцию массивов, чтобы упростить нам, пользователям, жизнь.

Возможно, при таком подходе эти два языка будут для вас восприниматься как части единой системы, а не как два разных иностранных языка.

Задать вопрос автору блога можно здесь: @hum_it_bot

Наконец, дошли руки прочитать книгу Remote, про работу на удалёнке.

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

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

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

Я же за полтора года успела пройтись, наверно, по всем граблям удалённой работы, и сделать всё именно так, как не надо. Так что вот вам вредные советы, о работе на удаленке - почитайте и сделайте наоборот:

- 8-9 часовой рабочий день в офисе превращается в 12, а то и 16-часовой дома - бывает, ты за компом и с утра, и поздно ночью, и практически всегда. Утром написал коллега, что-то спросить - ты уже за компом. Вечером спешить некуда, на электричку домой не опоздаешь, и кажется, что сейчас еще чуть-чуть закончишь с той задачей, там немного осталось, и вот уже час ночи. В итоге work-life balance превращается в work-work balance. Работаешь практически круглосуточно

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

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

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

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

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

И первая рекомендация там звучит так - следить за переработками.
Переработки - верный путь к выгоранию.

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

Вторая рекомендация - следить за физической активностью. Гулять, заниматься физкультурой, в фитнес-клуб, я не знаю, записаться. Авторы книги советуют всем работодателям оплачивать своим сотрудникам фитнес (в идеальном мире люди живут). Иначе, сами знаете, +10 кг, а со временем и проблемы со здоровьем

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

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

Локалка | Статьи для IT-специалистов - сохраняем лучшие статьи по программированию и администрированию в удобном для чтения формате

@Local_Area_Network

TDD или зачем писать тесты

TDD расшифровывается как test driven development, разработка через тестирование. Что это такое расскажу ниже, для начала пара вводных слов о самих тестах.

Прежде всего, что такое тест? Тест - это код, который проверяет, что наша программа работает правильно.

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

Когда мы ленимся написать тест, мы делаем так, потому что нам кажется, что в нашей программе нет никаких ошибок. И мы доверяем этому «кажется». Но представьте, что будет, если, например, при создании лекарства его создатели будут полагаться это чувство: «нам кажется, лекарство не вредное и работает», а клинических испытаний проводить не будут. Или если создатели самолётов будут просто верить, что «он летает», и никак это не проверять.

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

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

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

Основное в TDD - тесты мы пишем до того, как пишем/меняем код самой программы. И очень часто их запускам - после любого изменения программы.

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

Начнём с элементарного теста для этой функции. Если товар стоит 100 рублей номинально, мы его будем продавать за 200. Если он стоит 0, то и цена будет бесплатной:

def test_calculate_price():
assert calculate_price(100) == 200
assert calculate_price(0) == 0

После этого напишем саму функцию. В целях демонстрации она будет максимально простой:
def calculate_price(nominal):
return nominal * 2

Теперь мы можем запустить тест, и он отработает как нужно, если, конечно, мы нигде не ошиблись. Первая версия программы готова.

Внесение изменения

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

Обнаружен баг

Один покупатель в нашем Интернет-магазине оформлял заказ, и увидел, что товар стоит -200 рублей. Так мы узнаём, что наша функция может возвращать отрицательные значения. С чего мы начнем исправлять эту ошибку? Поменяем функцию calculate_price ? Нет, первым делом нужно доработать тесты. Раз в программе есть баг, значит тесты должны его отлавливать. Предположим, мы хотим, чтобы наша функция возвращала None, если мы передаём ей отрицательную номинальную цену. Добавим в наш тест проверку на работу с отрицательными числами:

def test_calculate_price():
assert calculate_price(-100) is None

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

Изменение логики функции

Предположим, цены в нашем магазине изменились, и теперь все товары стоят в 2 раза больше номинальной стоимости + наценка 20% от номинальной стоимости. Что мы поменяем первым делом, чтобы реализовать эту логику? Правильно, тест.

def test_calculate_price():
assert calculate_price(100) == 220
# и так далее

Запускаем тест, убеждаемся, что он возвращает ошибку, и переделываем саму функцию, чтобы она теперь считала стоимость по-новому.

Вот так примерно выглядит разработка по методике TDD.

✅ Хотим обратить ваше внимание на полезный telegram-канал для обучения высокоуровневому языку программирования Python

На канале ежедневно публикуются задачи по Python и Machine Learning: алгоритмы, функции, классы, регулярные выражения, итераторы, генераторы, ООП, исключения, numpy, pandas, matplotlib, scikit-learn, TensorFlow и многое другое!

✔️Станьте специалистом по Python вместе с каналом "Задачи по Python и машинному обучению"

#вашивопросы

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

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

В то же время меня смущают две вещи: во-первых, у меня достаточно разные задачи, и большинство из них не связаны между собой. То есть в одном месте я больше с Фласком копаюсь, в другом с запросами в БД, в третьем вообще со стилями в CSS.

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

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

То есть у тебя я бы хотела спросить, это проблема в моем подходе — или же проблема компании? Если это проблема моего подхода, что бы ты мне посоветовала для систематизации знаний? Если это проблема в компании, как и что со своей стороны я могу прокомунницировать?

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

Ответ в следующем посте.

[Ответ на вопрос из поста выше]

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

То есть, пример формулирования задачи для джуна: «Добавь в базу данных таблицы user новый столбец last_seen_at, дата самого последнего посещения». И всё. Никаких разъяснений - зачем нужен этот столбец? Как он будет использоваться? Какую задачу это решает? Просто вот тебе задача, выполняй. То есть, дают коммуникацию, что делать, и как это делать, но не объясняют, зачем. Я не знаю, похоже ли это на ваш случай, подумайте об этом.

Пример задачи для специалиста middle и выше: «Если пользователь не посещал сайт больше недели, мы хотим присылать ему Push-уведомление о том, что для него действует персональная скидка.» Дальше разработчик уже декомпозирует задачу (один или вместе с коллегами), и придумывает сам, как он это будет делать. В частности, он решает, что в базе данных нужно хранить дату последнего посещения сайта пользователем. Но это лишь одна из подзадач.

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

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

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

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

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

Задать вопрос автору блога можно здесь: @hum_it_bot

​Стать программистом за 3 дня

«Невозможно», — могли подумать вы и были правы. Нельзя стать программистом за 3 дня, но разобраться, как устроен мир разработки и сделать к нему первые шаги — вполне реально.

На бесплатном трехдневном курсе Нетологии «Как стать программистом» вы узнаете, чего ждать от профессии разработчика, подходит ли она вам и как сделать самое сложное — начать.

Сделайте первый шаг к большим возможностям, а мы поможем двигаться дальше ↓
https://netolo.gy/heN

#вашивопросы

Если у меня уже есть довольно большой стек технологий, стоит ли записываться на вакансии просто QA-тестировщика (например) или что-то оч низкой планки такой по отношению к стеку из-за страха, что не справлюсь?

Подробнее про стек:
Ну из основных, из языков и фреймворков, технологий, которые я знаю я знаю, ну мой стек т.е.: Python (довольно хорошо себя чувствую), Java (очень хорошо знаю), JS (начинаю учить), C++ (средне знаю, но постоянно подтягиваюсь в плюсах конкретно сейчас), SQL (средне), TypeScript (начинаю учить, но т.к. это как жс, то будет, думаю, проще), C# (начинаю учить, но схожесть с плюсами и джавой облегчают изучение неплохо так) […]

Ниже еще полстраницы навыков и скиллов, опускаю для краткости.

Дальше автор вопроса спрашивает, стоит ли ей идти в тестировщики или например в техподдержку.

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

У вас уже огромный список скиллов, даже для не новичка. Я не знаю, насколько глубоки знания каждой технологии у вас, но «в ширину» список впечатляет. И на этом этапе мне уже не совсем ясно, зачем продолжать расширять этот список, вместо того, чтобы идти и применять свои знания. Просто в качестве хобби? Или всё же учеба - это способ прокрастинации?

Чтобы преодолеть страх, нельзя позволять ему принимать решения за вас и вести куда-то за собой. Идти нужно туда, где страшно. Страх поначалу никуда не денется, так что придется просто нести его с собой. :) Чтобы было развитие, нужны задачи чуть сложнее, чем вам было бы комфортно. Если делать только то, что привычно и легко - никакого роста и не будет.

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

Хочу, чтобы по времени такая реальная работа не занимала всё время, т.к. хочу продолжать изучать много чего ещё из своего чек-листа для себя и ещё заниматься совместно с друзьями проектом/начать делать свой один. И помимо просто изучения языков и прочего для себя из своих планов, я сплю около 13-15 часов, чтобы чувствовать себя хорошо + ещё общаться просто с друзьями и заниматься чем-то своим за день нужно. Ну то есть, я не выхожу никуда из дома почти никогда, но при этом времени у меня сейчас и так не особо много и много чего делать нужно.

Что касается желания иметь много свободного времени, я сомневаюсь, что реально всё вот так совмещать, как вам бы хотелось. С full-time работой, вероятнее всего, так не получится. Всё же работа диктует свой график, и работодатели не станут подстраиваться под вас. Но раз у вас есть желание усидеть на двух стульях (то есть учиться, работать и иметь кучу свободного времени) - поищите какие-нибудь стажировки с частичной занятостью, скажем на 2 дня в неделю.

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

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

Задать вопрос автору блога можно здесь: @hum_it_bot

UPD: тут мне пишут, что я несправедлива по отношению к техподдержке, когда пишу, что что им не нужны технические знания и скиллы.

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

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

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

В общем, как водится, везде всё по-разному.