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

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

Я 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 специалистом, чтобы начать использовать сервисы прямо сейчас

ООП. Полиморфизм

Продолжаем серию постов с ликбезом по ООП.

Кто присоединился недавно и хочет разобраться с тем, что такое объектно-ориентированное программирование, советую начать с предыдущих постов:
1. Что такое классы
2. Что такое объекты классов и как их создавать. Конструкторы
3. Что такое ООП
4. Принципы ООП: абстракция. Инкапсуляция
5. Принципы ООП: наследование
6. Абстрактные классы. Интерфейсы

Сегодня рассмотрим азы такого принципа ООП, как полиморфизм.

Полиморфизм означает возможность использовать для одних и тех же целей объекты разных типов (например, разных классов).

Возьмём для примера снова телевизор. Телевизор - это объект класса TVSet. Нам нужно запрограммировать его так, чтобы им можно было управлять с помощью пульта. Если не использовать полиморфизм, то мы разрешаем классу TVSet взаимодействовать ТОЛЬКО с классом пульт (назовем его Remote) - и никак по-другому включить и выключить телевизор, кроме как определенным, специально для него созданным пультом мы не сможем.

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

Таким образом, нам не нужно жёстко привязывать именно класс Remote к классу TVSet. Мы можем запрограммировать телевизор так, чтобы он работал с любым классом, если этот класс поддерживает интерфейс (про интерфейсы читайте предыдущий пост из цикла) - такой же интерфейс, как у пульта к телевизору. То есть класс должен уметь делать turnOn, turnOff, переключать каналы, менять громкость - и этого достаточно, чтобы он подходил к телевизору. Это и есть пример полиморфизма.

Когда мы определяем функцию или метод в строготипизированном языке, мы можем потребовать, чтобы в аргументе был объект строго определенного класса (например, пульт):

function turnOnTV(Remote remote) {
… }

А можем зайдествовать полиморфизм, и сказать функции, чтобы она принимала любой объект, у которого реализован интерфейс (назовем этот интерфейс IRemotable):

function turnOnTV(IRemotable remote) {
… }

И тут мы передаем в нее любой объект с подходящим интерфейсом, не только пульт.

А как конкретно полиморфизм использовать в разных языках программирования - зависит от их синтаксиса и возможностей.

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

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

Про сексизм уже писала тут и тут.

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

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

К тому же в IT часто совсем не агрессивная среда. Часть ребят там - вообще очень робкие интроверты и стесняются даже глаза на женщину поднять (вспомните персонажа Раджеша Кутрапалли из «Теории большого взрыва» - вот примерно такие ребята).

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

С ущемлением по части зарплаты тоже не сталкивалась. Да и зарплата - это же дело переговоров - за сколько вы себя «продадите» на собеседовании - столько вам платить и будут. И на повышении зарплаты тоже нужно настаивать и разговаривать с начальством - далеко не везде её повышают без вашего вмешательства). Кстати, чаще всего коллеги не знают зарплат друг друга, такую информацию не принято разглашать.

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

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

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

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

Умение копать и умение не копать

Один раз на одной IT-конференции мне запомнились слова из одного доклада: «У меня есть лопата. Я хорошо умею копать. С её помощью я накопаю вам сколько хотите столбов».

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

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

И минус тут не только в том, что технологии используются по назначению, и решение получается очень неочевидным и неудобным (для всех, кроме вас самого). Проблема еще и в том, что вы так не развиваетесь. Вместо того, чтобы сесть и наконец научиться работать с SQL, вы снова и снова пытаетесь работать с одним только питоном.

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

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

Посоветуйте, пожалуйста, книгу для изучения MongoDB.

Среди русскоязычных изданий встречала только такую: MongoDB в действии. Но сама её пока не читала (давно стоит на полке и ждет своего часа).

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

Правила выживания в офисе

Многие говорят о том, что офисы в современном мире никому не нужны, а пандемия усилила этот тренд, вытеснив многие компании целиком на удалёнку.

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

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

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

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

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

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

Django

Раз уж я Python-разработчик, давайте сегодня поговорим о чем-то питонячем, а, точнее, о Django.

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

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

При этом django довольно трудоёмок в изучении для новичка - в отличие, скажем, от более легковесного варианта Flask. Так что потратить некоторое время на него придётся.

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

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

Так что ловите подборку из таких курсов (как всегда, предложения по цене и длительности есть самые разные):

Есть, например, полноценная полуторогодовая программа: Fullstack-разработчик на Python от Skillfactory - тут научат не только джанге и бэкенду, но и фронтовой стороне разработки, включая JavaScript и React.

У Skillbox есть более короткий курс по Django - длительностью 6 месяцев.

А, например, этот курс от Нетологии, посвященный Django, рассчитан он на тех, кто уже знаком с питоном и длится около двух месяцев (соответственно и цена не такая высокая)

У Geekbrains есть ещё более быстрый вариант - курс по Django, длительностью в 1 месяц.

А в Udemy (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя) по запросу «django» я нашла более 400 курсов для самостоятельного обучения в своём темпе - там, как обычно, цены начинаются от 1000 рублей, но есть и совсем бесплатные курсы.

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

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

Маленький не для всех очевидный совет: всегда обращайте внимание на дату публикации. Возможно, этот ответ на Stackoverflow (или статья) был написан лет 10 назад. И, возможно, решение давно устарело и уже даже не работает.

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

Здравствуйте! На данный момент я учусь в 9 классе и мои многие друзья/товарищи ходят в МШП, а у меня недавно появилось желание тоже углубиться в IT. Можете сказать, не поздно ли начинать в моём возрасте? Если не поздно, то с чего нужно начать(и есть ли смысл в МШП)?

Раньше я удивлялась вопросу «мне 20 лет, не слишком ли поздно начинать?» - и шутила, что однажды такой вопрос начнут задавать и 16-летние. У нас, наверно, любой человек считает себя «слишком старым», независимо от возраста. И вот этот день настал, оказывается, даже в 9м классе люди уже считают, что начинать нужно было когда-то раньше.

Не поздно.

МПШ (это Мытищинская школа программирования) выглядит как хороший вариант - если поступите туда, то почему бы и нет?

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

И в любом случае - готовьтесь поступать в технический ВУЗ.

Здравствуйте. Давно Вас читаю и очень интересно узнать Ваше мнение. Я учусь в техническом вузе, но не на супер-программистской специальности (по сравнению с другими направлениями в универе). С 1го курса нам преподают С++ (сейчас я на 3 курсе), немного в виде ознакомления были js и python.
Так вот, наткнулась недавно на одну онлайн школу, в которой можно бесплатно изучить Scala. Как Вы считаете, стоит ли изучать сейчас этот язык? (Если не рассматривать то, что учить что-то новое - это хорошо, тем более бесплатно. Хотелось бы просто узнать ваше мнение именно по этому языку, востребован ли он и тому подобное)

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

Но во многих случаях Scala используется в связке с Java, так что, вероятно, если вы решите изучать Scala, лучше освоить заодно и Java (если что, вакансий, связанных с Java в Москве больше 3000).

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