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

Привет! Прохожу сейчас 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 - в зависимости от компании).

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

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

Дополнение от подписчиков:

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

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

Как искать ошибки в коде

Мне достаточно часто присылают в бота вопрос: «А где у меня тут ошибка?» и дальше целая страница кода.

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

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

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

Но это лирическое вступление. А пост о том, как искать ошибки в коде.

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

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

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

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

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

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

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

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

Знания математики от тестировщиков не требуют, как и от DevOps.

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

Я хочу быть скрам мастером, как мне попасть на работу?

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

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

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

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

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

Какие знания о разработке нужны среднестатистическому продакт менеджеру?

Моё мнение - продакт-менеджер не обязан быть программистом и уметь писать код. Это не его задача.

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

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

Помимо этого нужны знания в области IT на уровне ликбеза. То есть вам не нужно самому/самой уметь писать и запускать сайты, мобильные приложения или программы. Но нужно понимать, что такое в принципе программа или приложение или веб-сайт. Например, как устроена в общих чертах клиент-серверная архитектура, что такое API, как примерно работает веб-сайт. Чем клиентская часть сайта отличается от серверной. Что такое база данных, и для чего она нужна. Итд итп.

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

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

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

Имею высшее образование с отличием в области машиностроения (инженерконструктор), им толком не пользовалась (на практике не зашло), знаю англ на уровне В1, хочу попробовать себя в IT (вроде склад ума позволяет). Не знаю, что для себя выбрать, с какого языка/ направления начать.

Поскольку вы пока не знаете, какое направление выбрать, можно его на этом этапе и не выбирать. Начните с курса «Введение в Computer Science», я для этих целей традиционно советую всем бесплатный гарвардский курс CS50. Там будут и азы программирования, и знакомство с несколькими языками, да и с областью в целом. Возможно, после него вам станет понятнее, в каком направлении интереснее развиваться, и какие яыки, к примеру, изучать.

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

Тут, к сожалению, много не подскажу, так как я сама училась не по книгам, а по онлайн-курсам - мои «книги» - это coursera, edx, stepic, и сайты университетов (MIT, Stanford итд) c онлайн-курсами. Но список литературы, который рекомендуют студентам технических ВУЗов, думаю, нагуглить несложно. А если не гуглить - то спросить на каком-нибудь студенческом форуме.

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

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

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

Подскажите, пожалуйста, перенасыщен ли рынок джунами (например, Java)? Тяжело ли им найти работу, высокая ли у них конкуренция? Закрадываются мысли, что могут выбрать не тебя, а другого человека, который знает больше.

Как там дела с перенасыщением (или недосыщением) рынка неопытными кандидатами я вам не отвечу, так как давно не занималась подбором кандидатов, а подбором кандидатов-джавистов не занималась в принципе никогда.
Я знаю, что канал читают в том числе и HR-специалисты, и возможно, у них найдутся комментарии к этому вопросу? Присылайте в @hum_it_bot, интересные ответы опубликую в канале.

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

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

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

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

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

Во фронтенд - бесплатный роадмап/план изучения по фронтенду.

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

На канале вы узнаете:
-как код пишется в реальном мире, за пределами учебников
-разборы собеседований, задач, вопросов, подводных камней
-эффективные приемы и техники изучения

Примерные сроки - 6 месяцев, в любом случае, этот роадмап останется, и можно будет идти по нему в своем темпе. welcome, @into_frontend

Я намеренно не стала вчера писать про Чёрную пятницу, так как, думаю, всех уже и так достала повсеместная реклама и скидки, скидки, скидки.

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

А кто задумывается о покупке какого-либо курса - можете посмотреть мою сентябрьскую подборку онлайн-школ и скидок в них https://news.1rj.ru/str/it_human/527 - все промокоды из поста всё ещё действуют, я проверяла. Разве что точный размер скидки может отличаться.