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

Возможно ли самостоятельно обучится на тестировщика, с какой литературы начать? Нужно ли глубоко углубляться в программирование?

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

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

В любом случае, что бы вы не имели в виду под «самостоятельным изучением» - сделать это можно.

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

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

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

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

Вариант третий - open source. Есть тысячи проектов на github - больших и маленьких, сложных и простых - к разработке которых может подключиться любой желающий. Это очень хороший вариант, так как там вы научитесь не только свой код писать, но и работать с кодом, ранее написанным кем-то другим. А чтобы подобрать себе подходящий проект - введите в гугле «open source для начинающих» - в топе будет сразу несколько статей с советами, как найти такой вариант.

Автор, спасибо за контент! Ты не только программист, но и психолог, причем хороший )

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

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

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

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

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

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

Перед отпуском

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

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

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

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

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

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

Слишком сложно

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

Собственно, эта мысль убивает любую попытку и любое новое начинание.

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

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

Будьте реалистами, друзья. Всё возможно, но не сразу.

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

Хочу научиться веб программированию, но все никак не могу найти с чего начать. Можете что нибудь посоветовать?
Сама студентка, не по этой специальности(пока что)
Самой это интересно, пыталась и начинала изучать языки для веб программирования

А еще очень интересна тема веб дизайна, были попытки пройти бесплатные курсы
Но почти везде были представлены только figma и tilda
Очень бы хотелось услышать ваши советы насчёт этого

Всем самостоятельным начинающим я обычно советую пройти курс по введению в Computer Science - а точнее начать с гарвардского cs50 - в этом посте есть ссылки и на оригинальный курс и на его версии в переводе на русский язык. Это бесплатно.

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

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

Более дешевые варианты курсов есть на Udemy (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя) и аналогах.

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

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

Системы контроля версий

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

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

Предположим, у вас есть файлик с кодом и вы решили внести туда изменение. Вы что-то поменяли в коде, сохранили файлик. И только через две недели обнаружили, что теперь в коде есть ошибка и всё сломалось. Хорошо бы вернуть всё, как было раньше. Но вы уже не помните, что именно поменяли в файлике.

А если бы код хранился в системе контроля версий (например, в 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» можно написать любой другой комментарий, рассказывающий, какие изменения вы сохраняете на этом шаге.

Готово! У вас есть свой репозиторий, который можно использовать для отслеживания истории изменений. Продолжим тему в будущих постах.

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

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

Не важно, Гугл, Фейсбук, Нетфликс — при вперед. За спрос, как говорится, денег не берут. А отказываться от работы мечты просто потому, что страшно провалиться — затея упадочная

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.

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

Меня часто спрашивают, как побороть синдром самозванца и неуверенность в себе, и заставить себя составить резюме, ходить на собеседования и искать работу.

На эту тему я много писала, но вот вам ещё один способ. Не боритесь с синдромом самозванца, а используйте его.

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

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

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

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

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

Добрый вечер! Нужна помощь с анализом умений и выбором направления. Мне 31 и после долгих блужданий по профессиям решил попробовать айти. По моему мнению хорошо у меня получается:
- собрать информацию, переварить и выдать что-то внятное или что-то объяснить (преподские навыки);
- часто ясно вижу долгосрочное развитие тенденций (не как Ванга конечно);
- развиваться вширь, чем вглубь;
- дружить с людьми и техникой.
- придумывать, изобретать.
Вопрос в том, где с таким набором приживусь, а где буду мучиться. Мне очень хорошо знакомо, когда оказываешься не в своей тарелке.

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

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

Вот примеры курсов, где такому учат:

- Product Live - тут курсы для Product- и Project-менеджеров, системных аналитиков и др.
- Факультет системной и бизнес-аналитики от гикбрейнс.
- У тех же гикбрейнс предлагаю присмотреться к таким направлениям обучения как Product-менеджмент, Бизнес-аналитика, Проджект-менеджмент, Продуктовая аналитика
- Линейка курсов по тематике Бизнес и управление от Нетологии.

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

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

Что я увидела: авторы подобных опусов часто выдают свои очень субъективные взгляды на то, о чем спрашивать кандидатов и как трактовать их ответы за общепринятую истину.
Например, среди «понравившегося»:

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

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

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

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

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

Вот тут товарищ напоминает, чтобы вы не слишком доверяли статьям в духе «как я стал программистом за 6 месяцев»: https://habr.com/ru/company/productivity_inside/blog/544970/.

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

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

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

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

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

Зависимость от успеха

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

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

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

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

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

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

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

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

Начала изучать Python и в целом очень нравится программировать, писать код. Участвую в разных вебинарах, смотрю уроки и почему-то везде твердят, что нужно выбрать какое-то конкретное направление: frontend, backend, разработка приложений, тестирование, data science и куча всего. Так вот вопрос, нужно ли вообще выбирать направление или можно двигаться просто в сторону программирования на Python? Что изучать, чтобы быть разработчиком Python? Или все равно придется выбрать одно направление?

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

Фронтэнд - это не про Python, а про JavaScript.

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

Тестирование в общем случае - это не программирование вообще.

А вот в Data Science Python действительно популярен, но если вы захотите туда - нужно будет изучать в первую очередь математику и саму Data Science. Туда же разные аналитики, которые используют Python как инструмент для более удобной аналитики - то есть для них он примерно как калькулятор или Excel.

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

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

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

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

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


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

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

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

Я готов пойти на платные курсы, но не могу понять что конкретно в моем случае будет более актуально, сначала думал на разработчика питон(там на geekbrains пишут пишут типа 1,5 года и ещё трудоустроят и зп больше чем моя сейчас в 2 раза), но что-то слабо верится.

Потом смотрел курс веб разработчика, там вроде как поинтереснее для меня тема и дешевле даже, но хз куда потом устроиться. И самое что меня смущает, это то что уж больно сладко обещают после курсов работу и ЗП такую (типа на питоне мне манагер по телефону сказал от 110к на нач уровне).

А во вторых мне с моим бек граундом) направление откуда начать: разработк на питон, веб разработка, разработка прил для андроид(вроде ненежно нынче)) или вообще начинать с обучения С, C+, php.

Ну во-первых - вы говорите, что вы «человек движа» - может тогда вам рассмотреть менеджерские и продуктовые профессии? О таких я писала в этом посте не так давно.

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

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

Что касается зарплат, гарантировать, что вы сразу найдёте работу, где вам со старта будут платить 110к, я бы не стала. Существует ли такая вероятность? Наверно да. Но также вероятно, что первое время вам придётся обходиться гораздо более скромными цифрами. Одни работодатели платят новичкам и стажерам, скажем, 60к, а другие ближе к 100. Ну а опытные разработчики получают больше, чем обозначенная вами цифра, это правда.

В вашем бэкграунде нет ничего такого, что указывало бы на какое-то конкретное направление из перечисленных вами. Из вашего вопроса я вижу, что вы пока не до конца понимаете разницу между ними. Поэтому я бы предложила вам начать с бесплатного курса по введению Computer Science - денег не потратите, зато сформируете какое-никакое представление об IT и чем тут люди занимаются. А дальше уже можно будет более осознанно подойти к выбору направления. Заодно это страховка от того, что вы разочаруетесь в процессе и зря потратите деньги на курсы.

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

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

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

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

Не отделяйте теорию от практики, и не изучайте её как что-то отдельное.

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

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

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

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

Хорошо знаю html, но не до конца понимаю css, плохо идёт практика верстки сайта. Что с этим можно сделать?

Посмотрите тут вот есть и разъяснения по поводу CSS и учебные задания для тренировки - https://www.w3schools.com/css/css_exercises.asp

Хочу написать текстовый квест, хотя из опыта только Turbo Paskal 7.0😁.
Подскажите пожалуйста, какой язык выбрать для освоения и чем компилировать, чтоб получилась игруха для телефона на Android?

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

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

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

Меня часто спрашивают: как составить себе портфолио из готовых проектов? На чем попрактиковаться? Где взять идеи для разработки своих первых программ? Как перейти от простых учебных задач к сложным и большим?

По этому поводу я подсмотрела у другого блогера вот такой проект: https://github.com/danistefanovic/build-your-own-x/blob/master/README.md#build-your-own-web-search-engine

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

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

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

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

Кстати по ссылке выше рекомендую присмотреться к разделу Build your own Programming Language - там можно создать свой собственный язык программирования, написать интерпретатор или компилятор к существующим языкам.

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