Программирование для гуманитариев

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

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

Вот тут товарищ напоминает, чтобы вы не слишком доверяли статьям в духе «как я стал программистом за 6 месяцев»: https://habr.com/ru/company/productivity_inside/blog/544970/. Что я могу добавить от себя: согласна, 6 месяцев при условии, что вы начинаете с полного нуля - это очень короткий срок. Да, у кого-то получается и так - но там, по-видимому, совпало множество факторов, и к тому же это был сын маминой подруги. Ожидать, что любой человек сможет так же - это типичная ошибка выжившего. Лично я училась полностью сама и бесплатно (+ у меня была куча свободного времени), но заняло это больше 2х лет. Думаю, если записаться на очень интенсивные курсы, то можно это сделать быстрее - скажем, за год-полтора. Но полгода - очень уж оптимистичный план.

Посмотрела несколько видео и статей, посвященных таким темам как «5 ошибок на собеседованиях по программированию» и вот что хочу вам сказать. Похоже, что подобное лучше вообще не читать и не смотреть. А если всё же будете смотреть - то включайте максимальный скепсис и делите услышанное на 5, а то и на 10. Что я увидела: авторы подобных опусов часто выдают свои очень субъективные взгляды на то, о чем спрашивать кандидатов и как трактовать их ответы за общепринятую истину. Например, среди «понравившегося»: - «если кандидат упоминает паттерн Singleton на собеседовании - значит, он не знает ООП и надо гнать таких в шею» - «если кандидат говорит, что инкапсуляция значит сокрытие - значит он не знает ООП» - «мы посмотрели проекты кандидата на гитхабе - там нормальный код, видно, что он умеет работать. Но потом мы посмотрели его же код в чуть более раннем проекте на гитхабе и увидели, что там очень похожий код. А значит, кандидат не разивавается - поэтому нам такой кандидат не нужен» Это всё субъективщина чистой воды и очень неграмотный подход к собеседованиям - «кандидат должен знать всё, что знаю я (включая то, что я сам загуглил буквально 5 минут назад) и формулировать именно в таком виде, как нравится мне». С таким подходом происходит отсев вполне грамотных и нормальных специалистов, а берут кого-то, кто по случайному совпадению угадал с формулировкой или совпал по стэку с капризным интервьюером. В общем, это не конструктивно и служит скорее подогреванию Эго собеседующего, чем поиску людей. Запомните - собеседование - это не экзамен. На собеседовании не только работодатель выбирает вас, но и вы работодателя. А среди потенциальных коллег (также как и среди кандидатов) могут попадаться, мягко говоря, не очень адекватные чуваки. Поэтому не стоит воспринимать всё, что там происходит близко к сердцу. По ту сторону такие же люди, как и вы, и они тоже говорят глупости. Например, задают очень странные вопросы. Я знала человека, который каждого кандидата просил нарисовать график функции логарифма. А на одном собеседовании меня как-то раз просили продолжить какие-то англоязычные поговорки на тему IT - вот только у собеседующего было такое произношение + помехи скайпа, что я даже не смогла расслышать начала этих поговорок. И если вас не приняли на работу из-за того, что вы не смогли продолжить английскую поговорку или потому что упомянули синглтон - то нет смысла расстраиваться. Неужели вам бы хотелось работать вместе с человеком, который придирается вот к таким вещам? По 8 часов в день сидеть с ним в одном кабинете, 5 дней в неделю!

#вашивопросы Добрый вечер! Нужна помощь с анализом умений и выбором направления. Мне 31 и после долгих блужданий по профессиям решил попробовать айти. По моему мнению хорошо у меня получается: - собрать информацию, переварить и выдать что-то внятное или что-то объяснить (преподские навыки); - часто ясно вижу долгосрочное развитие тенденций (не как Ванга конечно); - развиваться вширь, чем вглубь; - дружить с людьми и техникой. - придумывать, изобретать. Вопрос в том, где с таким набором приживусь, а где буду мучиться. Мне очень хорошо знакомо, когда оказываешься не в своей тарелке. Судя по вашим предпочтениям, сугубо технические направления, такие как программирование или системное администрирование - это не совсем про вас - там одним развитием «вширь» не обойдёшься. Я бы на вашем месте рассмотрела такие варианты профессий, как бизнес-аналитик, системный аналитик, product менеджер и тому подобное - они в большей мере связаны с управлением IT-проектами, планированием, придумыванием и внедрением перспективных идей и коммуникациями с людьми - а глубокий технический бэкграунд там не так важен. Вот примеры курсов, где такому учат: - Product Live - тут курсы для Product- и Project-менеджеров, системных аналитиков и др. - Факультет системной и бизнес-аналитики от гикбрейнс. - У тех же гикбрейнс предлагаю присмотреться к таким направлениям обучения как Product-менеджмент, Бизнес-аналитика, Проджект-менеджмент, Продуктовая аналитика - Линейка курсов по тематике Бизнес и управление от Нетологии. Задать вопрос автору блога можно здесь: @hum_it_bot

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

Git (продолжение) В предыдущем посте мы познакомились с понятием системы контроля версий и в частности с git. Сегодня продолжим введение в Git. Для того, чтобы начать с ним работать, вам пригодится всего несколько простых команд. В прошлом посте я рассказала, как создать git-репозиторий локально и добавить в него ваш код. Следующим шагом вы можете загрузить ваш репозиторий на github, следуя этой инструкции. Готово? Вы восхитительны. А теперь давайте поговорим о том, как грамотно вносить изменения в ваш проект. В гите есть такое понятие как ветка (branch). Давайте для простоты рассматривать ветки - как версии вашего проекта. В данный момент в вашем репозитории существует только одна-единственная главная ветка - master. Менять код напрямую в ветке master - очень плохая идея. В мастере «живёт» полностью готовый, стабильный код. Когда же вы хотите внести какое-то изменение - лучше для этого создать отдельную ветку. Ваши измненения поначалу будут записаны только в этой ветке, а в главную версию master они попадут только когда мы полностью будем уверены, что код готов и работает правильно. (Давайте сразу привыкать к лучшим практикам разработки кода) Создать ветку (назовём её my-new-branch) и сразу же переключиться на неё можно командой: git checkout -b 'my-new-branch' (переключиться на уже существующую ветку в проекте можно командой git checkout без флага -b) Теперь у нас есть рабочая «копия» ветки master, и в неё можно вносить изменения. Отредактируйте любой (или несколько сразу) файлов с кодом в вашем репозитории. Теперь добавьте их в историю изменений командами, которые я уже упоминала в предыдущем посте: git add . git commit -m "Тут комментарий, описывающий изменения кода, которые вы внесли" А поскольку на предыдущем шаге вы уже подключили ваш репозиторий к github (вы же это сделали?), можно внесённые изменения «отправить» и в github: git push Запомните - делать git push нужно только из отдельной ветки. Никогда не делайте git push из ветки master - а то привыкнете к такому, и однажды сломаете основной код проекта на работе (это можно исправить, но будет неприятно). Как же записать изменения в главную ветку, master? Хорошая практика - делать это с помощью pull request-ов. Пулл-реквест - это запрос на «слияние» (merge) вашей новой ветки с мастером. Создать пул-реквест можно на github-e, для этого нужно будет найти и нажать кнопку create pull request. Если над проектом работают и другие разработчики, они могут посмотреть на гитхабе в пулл-реквесте, что за изменения вы собираетесь добавить в проект, и либо одобрить их, либо отклонить - либо попросить внести еще изменения в пул-реквест. Этот процесс называется ревью кода (Code Review). Если вы работаете над проектом сами - остаётся только самому же взглянуть на свои изменения ещё раз, уже на гитхабе. И только после одобрения пул-реквеста, можно приступить к слиянию вашей ветки с «мастером» (для этого есть кнопка merge). Готово! Ваши изменения записаны в мастер. Теперь надо обновить ваш локальный репозиторий - код в его версии ветки master устарел. Возвращаемся в ветку master: git checkout master И «забираем» изменения из репозитория на github: git pull Готово! Команд, описанных в этой статье, должно хватить вам на первое время для работы с git. В следующий раз, когда захотите снова изменить код - не забудьте перейти для этого в другую ветку из мастера (или создать новую).

При выборе работы никогда не забывай про эффект Очень Красивой Девушки. Это, когда баба настолько сногсшибательно хороша, что каждому кажется, что она-то точно уже занята, приглашена, вся в женихах и бриллиантах. А на самом деле, так думают все, а наша героиня дома грустно спивается с котом. Потому что подойти к ней все тупо ссут. С работой та же история. Я в свое время случайно откликнулась на вакансию, куда, как дружно рассказывали мне мои взволнованные друзья — не пробиться ни за что. Очень много кандидатов со всей страны. Ад, Израиль и очередь до конца времен. Я, честно говоря, просто не знала. Поэтому легко прошла собеседование и приняла оффер. Не важно, Гугл, Фейсбук, Нетфликс — при вперед. За спрос, как говорится, денег не берут. А отказываться от работы мечты просто потому, что страшно провалиться — затея упадочная

Системы контроля версий Начинающие программисты обычно хранят свой код просто в файликах. И пока кода в них мало, самих файликов мало и возвращаться к старому коду приходится редко - этот способ достаточно удобный. Однако я рекомендую прямо с самого начала привыкать к хранению кода с использованием систем контроля версий, и в этом посте поговорим о том, что это такое, и зачем они нужны. Предположим, у вас есть файлик с кодом и вы решили внести туда изменение. Вы что-то поменяли в коде, сохранили файлик. И только через две недели обнаружили, что теперь в коде есть ошибка и всё сломалось. Хорошо бы вернуть всё, как было раньше. Но вы уже не помните, что именно поменяли в файлике. А если бы код хранился в системе контроля версий (например, в git) - то у вас бы сохранилась информация обо всей истории изменений за всю историю существования файлика. Можно было бы отменить любую правку - даже ту, что была внесена полгода назад, не затрагивая все остальные изменения. Можно было бы вернуть файлик к любой предыдущей версии. К тому же проект, хранящийся в гите можно загрузить в Интернет, например, в публичный репозиторий на github-е и показывать другим разработчикам (пригодится для собеседования). А когда вы будете разрабатывать код совместно с другими разработчиками - как это бывает в компаниях - без системы контроля версий обойтись практически невозможно. Разные разработчики смогут вносить изменения в код, не мешая друг другу (git позволяет разрабатывать код в разных «ветках» - не затрагивая до поры до времени основной код проекта в «главной» ветке - но об этом расскажу подробнее в другой раз). Так что если у вас уже есть какие-нибудь файлы с кодом, но вы не используете системы контроля версий, давайте изменим это прямо сейчас. Для начала поставьте git (инструкции https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - если у вас Linux, он, вероятно, уже там есть. Теперь давайте создадим ваш первый репозиторий. Предположим, у вас есть несколько файлов с кодом, которые относятся к одному проекту (например, к сайту). Положите их в отдельную папку и перейдите в эту папку в командной строке. Нужные вам команды: 1) git init (создать репозиторий) 2) git add . (добавить в новый репозиторий все файлы в данной папке) 3) git commit -m "First commit" - сохранить изменения в репозитории. Вместо «First commit» можно написать любой другой комментарий, рассказывающий, какие изменения вы сохраняете на этом шаге. Готово! У вас есть свой репозиторий, который можно использовать для отслеживания истории изменений. Продолжим тему в будущих постах.

#вашивопросы Хочу научиться веб программированию, но все никак не могу найти с чего начать. Можете что нибудь посоветовать? Сама студентка, не по этой специальности(пока что) Самой это интересно, пыталась и начинала изучать языки для веб программирования А еще очень интересна тема веб дизайна, были попытки пройти бесплатные курсы Но почти везде были представлены только figma и tilda Очень бы хотелось услышать ваши советы насчёт этого Всем самостоятельным начинающим я обычно советую пройти курс по введению в Computer Science - а точнее начать с гарвардского cs50 - в этом посте есть ссылки и на оригинальный курс и на его версии в переводе на русский язык. Это бесплатно. Дальше, если планируете продолжать обучение в самостоятельном режиме, имеет смысл определиться - куда вы хотите - во фронтэнд или бэкенд. И дальнейшую программу обучения можно составить на основе этого роадмапа для веб-разработчиков. Опять-таки, если бюджет позволяет, можно записаться на годовую программу по направлениям фронтэнд, бэкенд или фулстэк разработки в каком-нибудь Geekbrains, или на аналогичной платформе. Более дешевые варианты курсов есть на Udemy (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя) и аналогах. Что касается дизайна - в этом посте была подборка курсов по различным направлениям дизайна, можно подобрать себе что-то оттуда. Задать вопрос автору блога можно здесь: @hum_it_bot

Слишком сложно Мне кажется, у многих есть такая абсолютно глухая, непреодолимая психологическая стена на пути к любым знаниями и умениям, да и в принципе к любому развитию - это мысль «это слишком сложно». Математика - это слишком сложно (я же гуманитарий), программирование - слишком сложно, выучить иностранный язык - слишком сложно. Всё слишком сложно. Собственно, эта мысль убивает любую попытку и любое новое начинание. А что такое «сложно»? Скорее всего, за этим словом скрывается нечто, что нельзя освоить за 1 день. Ну, факт, для любого обучения нужно время. Значит ли это, что не стоит и пытаться? Если бы все выбирали себе профессию по принципу «лишь бы полегче», то мы бы все работали кассирами в супермаркете, в лучшем случае - кассиром Галей, которая умеет покупки отменять. Есть и другая крайность - это когда маркетологи платных курсов внушают вам мысль, что научиться тому же программированию можно практически без усилий. Ну просто записаться на 2-месячные курсы, заплатить чемодан денег, и готово - тебя ждут в Силиконовой долине. Это, конечно, тоже ложная установка - чтобы чему-то научиться нужны усилия и упорство. Слишком легко тоже быть не должно. А неоправданные ожидания приводят к фрустрации и глубокому разочарованию. Будьте реалистами, друзья. Всё возможно, но не сразу.

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