Куда пропали 8 лет?

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

Вместо ответа расскажу историю. Обсуждали как-то с коллегами резюме кандидатки. Главный вопрос, который стоял на повестке: в резюме была «дыра» длиной в 8 лет - непонятно, чем занималась эти 8 лет и почему об этом не написала. И все стали предлагать свои версии.

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

Другой коллега очень настаивал на более романтической версии, что девушка - агент спецслужб, какой-нибудь ФСБ или ГРУ там она и провела 8 лет, и ей просто нельзя писать в резюме, ГДЕ она работала, «но мы-то всё понимаем» - хитрая ухмылка.

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

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

С Новым годом, товарищи!

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

The Website is Down - про будни веселого админа: https://www.youtube.com/watch?v=uRGljemfwUE

Wat - про странности языков программирования: https://www.destroyallsoftware.com/talks/wat

Всё на инглише (sorry)

Не буду даже пытаться

Продолжим тему о багах мышления.

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

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

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

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

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

Поэтому и запрос у таких новичков в духе «А дай списать». «Ну ты же всё знаешь, ну что тебе стоит.»

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

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

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

Так что пытайтесь. Это ключ к успеху. Честно-честно

Ещё про собеседования

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

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

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

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

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

1. Можно ли научиться делать именно десктопные версии приложений без углубления в программирование?
2. Какие языки необходимы, чтобы делать приложения канбан досок и интеллект карт? Я понимаю, что это похоже на изобретение велосипеда, но мне хочется попробовать самой сделать подобные приложения. Отсюда вытекает следующий вопрос:
3. А можно вообще научиться программировать не для общих целей, а например как в моем случае из потребности сделать конкретное приложение?

1. Программирование десктопных приложений - это тоже программирование, так что вопрос можно переформулировать как «можно ли научиться программированию, не углубляясь в программирование». Если ваша цель - только написать 2-3 десктопных программы, которым не нужен Интернет, значит на этом этапе можно проигнорировать, скажем, такие темы, как работа с сетью, HTTP-протокол и всё прочее, что не нужно для ваших потребностей. Но вам понадобятся основы программирования на выбранном языке и умение работать с GUI (графический интерфейс пользователя - то есть визуальная часть приложения - окошечки, кнопочки итд).

2. Какие языки выбрать для десктопных программ - во-первых, можно взять любой язык общего пользования, скажем, Python или Java. К ним понадобятся библиотеки для работы с GUI - например, в Python это tkinter или более новые аналоги. Если приложения хотите создавать под Microsoft, можно использовать платформу .Net (скажем, на языке C#). Еще можно использовать Delphi, но как по мне - это устаревший язык.

Ещё один чуть менее очевидный путь - написать веб-приложение на JavaScript и открывать его в браузере - вместо того, чтобы использовать библиотеки для создания GUI. Можно написать его так, чтобы ему не был нужен доступ в Интернет.

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

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

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

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

Как считаете, какие перспективы есть у Flutter и языка программирования Dart? Стоит ли это изучать в 2021?

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

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

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

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

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

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

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

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

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

ООП. Наследование

Праздники закончились, так что продолжим ликбез на тему ООП.

В предыдущих сериях:
1. Что такое классы
2. Что такое объекты классов и как их создавать. Конструкторы
3. Что такое ООП
4. Принципы ООП: абстракция. Инкапсуляция

Сегодня поговорим о таком столпе объектно-ориентированного программирования как наследование.

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

Возьмём пример - пользователь какого-нибудь чата, создадим для него класс BaseUser, чтобы подчеркнуть, что от этого класса будут наследоваться другие "дочерние" классы:

class BaseUser {

string login;
string email;

function send_message() {
// код
}
}

Базовый юзер - это обычный юзер, самый обобщенный вариант. У любого пользователя есть логин, email и любой пользователь может отправлять сообщения.

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

class AdminUser(BaseUser) {
}

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

А то, что есть у AdminUser, но не у обычных пользователей, мы определим только в этом классе:

class AdminUser(BaseUser) {

function ban_user(user) {
// код - забанить какого-нибудь пользователя
}
}

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

А еще можно переопределить метод, который админ унаследовал у родительского класса, чтобы он работал по-другому, например:

class AdminUser(BaseUser) {

function send_message() {
// код - печатать сообщения красным цветом
}
}

Метод send_message для админов будет печатать весь текст красным цветом. А поля и методы, которые мы решили не переопределять остались такими же, как в родительском классе.

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

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

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

В следующий раз расскажу про абстрактные классы.

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

Очень-очень хочу узнать Ваше мнение о смене работы.

Я Google Ads специалист уровня Middle+/Senior (так сказать Full stack, с большими проектами за плечами). Если сейчас устроюсь на работу то думаю могу ожидать около 2000$ (если получится 2500$) зп.
НО я уже изучаю Python (давно), куча курсов, пишу свои проекты, в общем готова идти на собеседования на Júnior Python dev.

Скажите, в 10-ти летней перспективе будет ли эта смена профессии правильной? Стоит ли?
Может ли девушка реально быть Senior бэкендщиком с зп выше 3,5-4К$?

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

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

Что касается зарплаты больше 3,5к долларов - то есть от 250к рублей и больше - такие вакансии есть, но это зарплата больше среднерыночной, если брать по Москве (скажем, в США разработчики получают больше, чем у нас).

Вакансии на 250к и больше - это часто уже уровень Team Lead или айтишников-руководителей, то есть профессии, где нужны будут не только технические навыки и опыт, но и менеджерские скиллы.

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

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

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

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

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

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

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

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

2. Айтишник бесконечно учится. Опять-таки - и да, и нет. Если вы представляете айтишника как человека, который все 10-20-30 лет своей карьеры неустанно сидит над книгами и курсами - то, скорее всего, ошибётесь. Учиться-то мы учимся, но чаще всего - в процессе работы. Отчасти гуглим ответы на возникающие вопросы, ищем их в документации, отчасти учимся методом проб и ошибок - но всё это пока выполняем рабочие задачи, а не в режиме вечного студента. Если вы спросите, сколько книг по IT я читаю в год - то ответ будет от нуля до двух. Другое дело - период обучения, когда вы только начинаете осваивать профессию, вот в этот период и курсы, и книги очень нужны.

3. Программисту необходимо осваивать как можно больше технологий. Примерно так звучал совет одного из ютюб-блогеров. То есть - изучаете базы данных - не ограничивайтесь одним SQL, изучайте еще и NoSQL. Изучили PostgreSQL - беритесь за MongoDB, Redis, расширяйте свой стэк максимально.

Ожидание - на старте супер-востребованный разработчик с кучей скиллов.

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

Во-вторых - не бывает Junior-разработчиков с большим стэком. Всё, что вы изучаете перед тем как устроиться на работу - это некая база, основа. Чтобы хорошо освоить какую-нибудь технологию, нужно с ней плотно работать в течение года-двух-трёх: спотыкаться обо все подводные камни, искать решения для возникающих неожиданных проблем, пару-тройку раз накосячить и потом исправлять это, а в идеале еще и ходить на конференции, и слушать доклады о работе с этой технологией. Вот так вы через пару лет сможете сказать, что шарите, скажем, в PostgreSQL. И только тогда можно всерьез говорить, что эта технология - часть вашего стэка. На этапе учебы происходит лишь поверхностное знакомство. Так что, ну познакомитесь вы слегка с условным MongoDB, и еще десятком подобных проектов (ClickHouse, Tarantool, Cassandra итд) - а толку? Всё, что не используете - забудете.

Так что моё мнение - изучать нужно основы Computer Science и некий базовый стэк - скажем, 2 языка программирования, SQL на примере какой-нибудь СУБД, сетевые протоколы итд. Выбирать конкретные технологии нужно исходя из вакансий, на которые вы метите, а не стараться объять всё подряд. (Тут - мой субъективный список требований для бэкенд-разработчика)

Я как-то «про запас» проходила курсы по Hadoop - ну потому что модно, молодёжно, популярно - Big Data и вот это всё. Однако, в работе мне он не пригодился ни разу, так что в итоге в памяти остались лишь какие-то базовые термины. Конкретные технологии нужны только если вы будете их использовать, иначе забудете начисто. Так что лучше в порыве перфекционизма не замахиваться на всевозможные технологии, которые в ближайшем будущем не планируете применять.

ООП. Абстрактные классы

Если вы пропустили предыдущие посты об ООП, советую начать с них:

В предыдущих сериях:
1. Что такое классы
2. Что такое объекты классов и как их создавать. Конструкторы
3. Что такое ООП
4. Принципы ООП: абстракция. Инкапсуляция
5. Принципы ООП: наследование

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

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

Вспомним наш класс BaseUser из поста про наследование. Чтобы использовать его как абстрактный класс, мы не должны создавать его экземпляры. То есть объектов типа user = new BaseUser() в коде существовать вообще не может.

Абстрактный класс нужен только для того, чтобы от него наследовались другие классы. Например, мы можем создать классы User(BaseUser) (обычный пользователь), AdminUser(BaseUser), ModeratorUser(BaseUser) - каждый из них наследуется от абстрактного класса BaseUser и заимствует его свойства. Мы можем создать объекты этих классов, но не базового класса - родителя.

Часто в абстрактных классах есть абстрактные методы - то есть такие методы, которые не реализованы в данном классе. Например:

class BaseUser() {

function sayHello() {
throw new NotImplementedException()
}
}

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

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

Возьмём в качестве примера опять пульт от телевизора. В случае с современными телевизорами пульт - это не обязательно пластиковая коробочка с кнопками, вместо пульта можно использовать и android/ios - приложения, и разные устройства из серии «умный дом».

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

class IRemote() {

// методы не реализованы
function turnOn()
function turnOff()
function nextChannel()
…
}

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

Я намерено стараюсь рассказывать о наследовании и связанных понятиях без привязки к отдельным языкам программирования. Каждый объектно-ориентированный язык имеет свою реализацию ООП. Например, в одних языках есть ключевое слово abstract для обозначения абстрактных классов, в других языках его нет, и абстрактный класс можно создать только полагаясь на «джентельменские соглашения» - то есть как бы договориться с другими разработчиками проекта, что мы не будем создавать объекты этого класса. В одних языках есть такой отдельный тип как Interface, в других можно имитировать поведение интерфейса с помощью обычных классов. В C++ есть еще, например, такая сущность как виртуальные классы и методы - но всё это особенности конкретных языков, и рассматривать их имеет смысл в том случае, если вы углубляетесь именно в эти языки.

Вы же помните, что мне можно задавать вопросы здесь: @hum_it_bot?

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

Сегодня разберем два вопроса вместе, так как они очень похожи

1. Интересует ваше мнение вот по какому вопросу: реально ли найти удаленную работу джуну в мобильной разработке?

2. Здравствуйте. Я самоучка, изучаю front-end уже более 6 месяцев. В данное время работаю учителем английского языка в школе.(Я из Узбекистана) Через 1-2 месяцев собираюсь переслать резюме и откликнуться на вакансии. Мне пока фриланс не интересует. Хотел бы работать удаленно на США, Европу или стран СНГ. Каково шансы устраиваться на удаленную работу джуну за рубежом?

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

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

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

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

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

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

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

Но хотелось бы узнать. Если сузиться именно в этом направление. То сколько по времени займёт обучение (хотя бы примерно) и нужно ли изучать что-то помимо Питона?

(Есть понимание, что Питон состоит из библиотек и что все их выучить невозможно)

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

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

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

Естественно, изучать все библиотеки не нужно, только те, которые нужны для ваших задач.

В вашем случае вам могут пригодиться библиотеки для работы с telegram-ботами - быстрое гугление даёт сразу несколько результатов. Какую из них использовать - вопрос удобства.

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

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

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

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

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

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


мой кейс: я бизнес аналитик с 5 летнем (почти 6) опытом в телеком домене, сейчас грядёт повышение до ba lead с зп 3-3,5К. могу выбирать: между ba lead и pm (c зп до 3,5К). это вроде и круто, и моя работа мне нравится. но это потолок.

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

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

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

в общем, возможно ли вообще перейти с позиции senior ba на junior developer? я учу сейчас джаву, есть опции параллельно с ba позицией начинать потихоньку кодить в рамках своих проектов, делать какие-то оч минимальные задачи, но это так страшно, если честно.
есть опасения, что перейдя в разработку, я не только просяду по компетенциям, но и вообще потеряю весь наработанный опыт, отстану в своей отрасли, а в программировании не достигну того уровня, на котором я сейчас в аналитике. что скажите, может что-то посоветуете? реально ли вообще за 2-3 года при капитальном вложении всего свободного времени и ресурсов пробовать переход из аналитики в разработку чтоб просадки были минимальны?

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

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

За 2-3 года вполне реально стать middle-разработчиком, а если поднажать, то и senior-ом. Но помните, что зарплата в районе 3,5к долларов - это чаще всего уровень уже как минимум сильного «сеньора», или же тим-лида/тех-лида. А чтобы стать тех-лидом (я так понимаю, эта должность вам наиболее симпатична) - нужно не просто разбираться в технических аспектах разработки и писать код, а делать это лучше всех в команде - до такого уровня доходит не каждый разработчик, многие остаются на уровне middle/senior или уходят в менеджеры/управленцы.

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

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

Как вернуться к работе или учёбе после отпуска

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

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

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

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

Когда ты сделал даже очень маленькое дело, это повышает мотивацию - ты уже молодец.

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

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

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

Мне сейчас прислали сразу несколько почти идентичных вопросов, все они звучат примерно так:

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

Кого же из 3-5 плюс-минус одинаковых конкурентов я должна посоветовать, а кого - отбраковать?

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

Так что для меня они сейчас все выглядят как братья-близнецы и сходу сказать «идите в А, а не в Б» я не могу.

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

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

2021 год будет лучше. Но не для всех..

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

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

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

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

На канале уже 500+ сервисов. Подпишись, чтобы не потерять.

И необязательно быть IT специалистом, чтобы начать использовать сервисы прямо сейчас