За 2 дня разбираемся в конструкторах сайтов и таргетированной рекламе 🧨

В эту среду 18-19 ноября начинается бесплатный 2-х дневный интенсив, на котором эксперты из Tilda и Qmarketing Academy научат, как:

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

Будет много реальных кейсов от практикующих маркетологов международного рекламного агентства и школы Tilda School. Регистрируйся по ссылке, мест осталось совсем мало! Записаться успеют только самые быстрые.

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

Хотелось бы попасть в it сферу, но опыта 0. Многие советуют делать это через тестирование (я из тех, кто закончил хоть и технический универ, но специальность моя далека от it), а вот через веб-разработку попасть гораздо сложнее? Дело в том, что я прошёл на codeacademy лёгкий курс по HTML и мне понравилась работа с языком разметки. Сейчас думаю с CSS ознакомиться.
Интересует ваше мнение, куда будет проще новичку попасть?

Знаете, мне не нравится подход в духе «хочу быть программистом, но тестировщиком стать проще, поэтому стану тестировщиком».
Если бы вы хотели стать врачом - вы бы пошли учиться на врача, или на фармацевта?

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

Я сама профессию тестировщика на старте не рассматривала - сразу метила в разработчики, потому что мне было интересно идти именно туда.

А вопрос «куда проще попасть» по моему скромному мнению, не совсем корректно поставлен. Почему нужно попадать именно туда, куда проще всего? Зачем этот минимализм?

Мне кажется, «попадать» нужно туда, где интереснее всего, и куда хочется. Знания и навыки в IT имеют накопительный характер - как наберёте их достаточно - так сможете найти работу. Ограничений к тому, чтобы добрать их до нужного уровня, я не вижу. Если вам сегодня знакомы только технологии A и B, что вас сдерживает от того, чтобы завтра выучить еще и C, а затем D? Всегда есть возможность продвинуться чуть дальше, чем вчера - и так до тех пор, пока сможете найти работу (правда, обучение на этом не закончится, но это уже другая история).

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

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

Я студентка выпускного курса технического вуза, инженер-конструктор. Оценки прекрасные, но (как я считаю) из-за такой логики построения высшего образования, какая у нас есть, знаний у меня не густо. Тут ещё надо учесть, что и работаю я сейчас по специальности, где тоже всё сугубо печально, не интересно. Ближе к сути: как-то вечерком наткнулась на курс "Графический дизайн". Вспомнила, что люблю что бы было красиво, с удовольствием оформляю презентации, хотела бы круто шарить в фотошопе. В общем, глаза загорелись) Но столько но...
~Кординальная смена сферы деятельности: инженер ->творчество
~Мысли: ну и нафига я разбиралась в этих эпюрах 5 лет??

Вопрос вот в чём: как считаете, смогу я приурочить своё понимание техники (путь и на девчачьем уровне) к такой профессии как графический дизайн?

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

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

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

Какие вы можете посоветовать книги по нейронным сетям начинающему? Которые расскажут что это такое, как пишутся и прочее о них.

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

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

Если же у вас уже достаточный бэкграунд, чтобы изучать нейросети - тогда многие рекомендают курс Deep Learning на курсере. Также, чтобы найти простые примеры, можно загуглить «neural network from scratch on numpy».

И, наконец, ответ на ваш вопрос, несколько книг с хорошим рейтингом по данной теме:

- Основы глубокого обучения.
- Создаём нейронную сеть.
- Глубокое обучение с точки зрения практики.

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

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

Я в прошлом финансовый аналитик, чуть касалась баз данных, средний уровень SQL и любительский уровень Python в применении к машинному обучению. Сейчас меняю карьерный трек и свою профессию, очень хочу в разработчики. То есть все, что связано с веб дизайном или тестированием мне не интересно. Но возник вопрос: языков много, как можно их сравнить по применению, объему рынка, з.п ожиданиям и перспективности в целом. Может существуют какие-то полезные статьи, где будет приведено их сравнение? На данный момент мне трудно понять, разработкой чего конкретно я хочу заниматься. Прохожу сейчас CS50, C++ белый пояс (Coursera) и Python (Coursera), чтобы была хотя бы база. Но слышала также о Java, PHP..

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

О зарплатах - в этом посте была картинка с примерными цифрами в зависимости от языка программирования.

Что касается объема рынка и перспективности - самый распространённый язык в мире - это Java, на нём пишут не только серверную часть приложений или десктоп-программы, но и программы под Android. Это значит, что Java-разработчики будут востребованы еще долго.

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

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

Если вас больше интересует фронтэнд-разработка (создание «лицевой» стороны сайтов) - тогда путь один - JavaScript.

Также сейчас в моде яызк Go от гугла.

Если вдруг вам чем-то приглянулась платформа Microsoft - тогда путь в .Net разработку, изучайте язык C#.

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

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

Если вам такое направление интересно - то во-первых, углубляйте свои знания Python (ну или изучайте, скажем, Java, если она вас больше заинтересует). Вместе с языком, обычно изучают его основные фреймворки, например, в случае с Python - это в первую очередь фреймворки для веб-разработки: Django, Flask.

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

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

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

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

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

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

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

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

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

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

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

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

#плохойкод

Как писать красивый код

Красивый код (как и хороший код) - это нечто мифическое: все о нём говорят, но никто не видел.
А вот с плохим кодом сталкивались все.

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

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

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

for (int i; ...) {
      
     
    for (int j;…) {

        // какой-то код

        for (int k;…)) {

           // код

            for (int l;…)) {

                // ещё код

                while (true) {
                    ...
                }
            }
        }
    }
}

То же касается и «многослойных» if-конструкций:

if (smth == true ) {

    // код
 
    if (smth_else == true) {

        if (smth_other == true) {

            // код 
        }
        else {

            // код 
        }
    }
    else if (smth) {

        // код 
    }
}
else {

     // код 
}

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

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

Добрый день, у меня возник вопрос по поводу "плохого кода", а именно (цитата) "циклы внутри циклов внутри циклов внутри циклов" (c), подскажите, пожалуйста, как тогда перебрать все элементы двумерного массива, без использования кмк очевидного цикла внутри цикла?

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

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

То же касается бесконечных «ветвей» if-else. Если ваш код похож на лестницу (за счет отступов перед if-ами и for/while) - вероятно, его нужно упрощать.

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

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

7 дней

Эту неделю мне по работе нужно было заниматься фротэндом сайта (я бэкенд-разработчик), поэтому она прошла в режиме «кодить по 12 часов в день на React». Для тех, кто не в теме, React - это веб-фреймворк на JavaScript.

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

Вот какие стадии я прошла за неделю:

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

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

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

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

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

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

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

Расскажите, пожалуйста, как нашли первую работу программистом, сколько собеседований было до неё

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

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

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

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

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

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

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

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

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

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

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

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

Что касается курсов по тестированию, вот небольшая подборка:

- Факультет тестирования ПО от Geekbrains с гарантией трудоустройства. Или более корткий курс Тестировщик ПО там же.

- Курс Тестировщик от Нетологии.

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

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


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

#плохойкод

Сегодня продолжаем серию о том, как не надо писать код.

Смешение стилей

Скажем, в Python многие любят использовавть snake case, то есть соединять слова между собой нижним подчеркиванием, в результате получаются вот такие переменные: my_variable, my_other_variable. А где-то принято использовать camel case: myVariable, myOtherVariable. И тут важна последовательность - если в коде проекта уже принят один стиль, не надо туда добавлять переменные, использующие другой стиль, так чтобы my_variable соседствовали с myVariable.

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

Названия для переменных

Худшее, что можно придумать - это называть переменные x, y, z, a, b, c, var1, var2, num1, num2 и так далее.
Имя переменной должно рассказывать о том, что в ней содержится (помните, что код должен быть читаемым и понятным для другого человека, не только для вас одного?).

Придумывайте информативные имена, например: average_salary, person_age, count_clicks - никаких переменных в одну букву.

Исключение: переменные итераторов (for int i; i++) - в таких циклах традиционно используют переменные i, j, k.

Не забывайте и про имена функций - они тоже должны быть «говорящими». Не называйте функции, например, do_everything() или do_calculations() - из такого имени непонятно, что именно функция делает или считает, нужно конкретнее: find_person_by_id() - например, ни у кого не вызовет недопонимания.

Магические цифры

Magic numbers - это когда вы используете в коде просто цифры.
Например: x = y * 100 / 2 + 365 - и читающему код непонятно, почему мы умножаем y именно на 100 и делим именно на 2, что это за 365, и так далее. Как это исправить? Использовать константы вместо чисел, например:

DAYS_IN_A_YEAR = 365
PERCENT_VALID = 100
DIVIDE_RATE = 2

x = y * PERCENT_VALID / DIVIDE_RATE + DAYS_IN_A_YEAR

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

Напоминаю, что если вы хотите увидеть в канале ответ на свой вопрос, или хотите больше постов, посвященных какой-то конкретной теме, вы можете написать мне сюда: @hum_it_bot

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

Вот я и свитчнулся в 32 года в Андроид разработчика. Шёл с некоторыми знаниями по яве и несколько большими именно по Андроиду и инфраструктуре, а проект на Kotlin. "Он простой и не отличается почти". Ну да, как же. Работаю чуть больше месяца, а какие-то базовые вещи о котлине узнаю каждый день. В связи с чем в свободное время стараюсь изучать базу по Котлину. Но появляется такой вот момент: работать над своими проектами времени нет вообще. Пока пришёл к тому, что в один из вечеров выходных вместо отдыха время отдаю проектам. Так что скорость будет черепашья, но хоть что-то.

Какие советы будут? Отказаться от отдыха вообще считаю неправильным, выгорание знакомо и так. Жертвовать учёбой ради проектов тоже не уверен, что стоит, но и проекты хочется развивать 😷

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

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

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

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

​Поиск работы

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

С тех пор я ни разу не искала работу, она сама ищет меня. Каким образом? Однажды, еще в мои доайтишные времена я прочитала в фейсбуке одной знакомой такой совет: «вот вы жалуетесь, что не можете найти работу, а сколько раз можно повторять - заведите уже профиль на linkedin». И хоть мне особо нечем было похвастаться в своем профиле, и хотя я и не искала работу, я всё же его завела и с тех пор периодически вношу туда изменения - записи о новом месте работы, новые скиллы, которые я освоила и так далее.

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

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

После того, как в моём linkedin вместо одной не очень известной компании появилось название этой известной компании, произошел какой-то фурор: рекрутёры стали приходить толпами. Практически каждый день там кто-то предлагает работу. Заходить туда регулярно мне лень, тем более, что для этого нужен VPN, так как доблестный роскомнадзор закрыл доступ на linkedin в России (если что, в браузере Opera есть встроенный vpn). Поэтому я захожу раз в месяц, добавляю в контакты всех рекрутеров, кто прислал приглашение (их уже у меня там наверно штук 500), и на каждое сообщение вежливо отвечаю, мол спасибо за предложение, но я сейчас работу не ищу. Пишут там не только из российских компаний, были предложения из Нидерландов, Германии, с Кипра и США.

Конечно, письмо от рекрутера - это еще не гарантия трудоустройства, но тем не менее пока у меня нет ощущения, что мне угрожает безработица.:)

Что я сделаю, если захочу поменять работу? Можно пойти пассивным путем и ответить кому-нибудь из рекрутеров, что я готова принять участие в собеседовании. А можно сделать и более дерзко, опубликовать пост в духе: «Всем привет! А я тут работу ищу…» - но правда во втором случае, боюсь, рекрутеры налетят как птицы в фильме Хитчкока.

Ваша покорная слуга дала интервью учителю информатики для её проекта, и вот что из этого получилось:
🔽🔽🔽

​​Продолжаем знакомиться с IT профессиями😊

Взяла интервью у Елены, автора канала Программирование для гуманитариев: @it_human


❓ Как называется ваша профессия?

Разработчик ПО

❓Каков график вашей работы?

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

❓Есть ли перерывы во время работы?

Да, когда я не забываю их себе устраивать.

❓ В чём заключаются основные принципы вашей работы, чем вы занимаетесь?

Есть 2 основных направления:

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

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

❓Мог бы школьник, выпускник, работать по вашей специальности при минимальной подготовке?

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

❓Какие предметы в школе стоит изучать более внимательно для вашей профессии?

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

❓В каком программном обеспечении необходимо разбираться?

Нужно уметь работать с Linux, и желательно с Docker. Для работы с кодом нужен git.
Также нужно разбираться в базах данных (например, с PostgreSQL).
Для настройки серверов пригодится Ansible.
Хорошо уметь работать с Grafana (на ней мы смотрим графики, по которым понимаем, что всё работает правильно, или наоборот - сломалось).


❓Приходится ли вам проходить дополнительные обучающие курсы для повышения качества вашей работы?

Я изначально училась только на курсах, поэтому слово "дополнительные" ко мне не очень применимо. 🙂

❓Как часто вы ищете информацию в интернете по работе?

Примерно 90% рабочего времени

❓ Насколько важны компьютер, телефон и другие гаджеты в вашей работе?

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

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

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

❓ В каком диапазоне находится ваша зарплата?

150-200 тыс рублей

💻⌨🖥⌨💻⌨🖥⌨💻⌨🖥

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

Подробно о том, в чём разница между программистом и разработчиком ПО читала тут

Зарплата по России

от 40 до 200 тыс. руб

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

А почему тогда в гайдах переменные называют var1, z/y/x?

Это был вопрос к моему посту о том, что переменные в 1 букву - это плохой стиль.
Почему в гайдах встречается такое? Потому что там приведены небольшие учебные примеры, для разъяснения материала.
А в коде настоящих проектов так не стоит делать.

#плохойкод

Магические строки

Продолжаем разбираться с тем, какой код писать НЕ стоит.

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

Сегодня поговорим о магических строках или строковых литералах в коде.

Пример:
if (name == "alligator")

Вот эта строка "alligator" - и есть магическая.

Что с ней не так, спросите вы? Если это единственное место в коде программы, где она встречается, то, в принципе ничего особо страшного в ней нет.

Но представьте, что вот таких if (name == "alligator") в коде много, и эта строка повторяется в разных местах, скажем, раз 10.
Что тогда может пойти не так? Например, в одном месте вы напишете по ошибке aligator, в другом aligater, в третьем alligator - и синтаксически код будет верным, но он будет давать неправильные результаты в ряде случаев, где вы опечатались. И придется проверять в 10 местах, правильно ли там написана строка.

Или, к примеру, вы используете ctrl + C, ctrl + V - копируете и вставляете этого аллигатора в разные места в коде. В итоге если вы ошибетесь в начале, то 10 раз вставите в код неправильные значения, и потом придется 10 же раз заменять на верные (да, современные текстовые редакторы позволяют это сделать достаточно легко, но зачем, если этого вообще можно избежать?).

Как сделать по-другому? Как и с магическими числами - заведите константы для таких строк. 1 раз в коде программы объявите константу:
ALLIGATOR = "alligator"

Используйте везде в коде эту константу:
if (name == ALLIGATOR)

Если вы ошиблись в строке «alligator», и её надо на что-то исправить - её придётся исправлять ровно 1 раз, в 1 месте - там, где вы объявляли константу, и всё.

В других местах кода незамеченных ошибок не возникнет. Если по ошибке написать, например,
if (name == LIAGITATOR)
- код не запустится, и интерпретатор (или компилятор) выведет ошибку о том, что переменная LIAGITATOR не существует. И так баг будет исправлен на самой ранней стадии, и не проскользнёт незаметно в продакшен.

Что такое классы

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

Предположим вы пишете код, где нужно как-то использовать данные пользователя: возраст, телефон, имя итд. Для этого нужны такие переменные:
user_age, user_phone, user_name

А если пользователей 2 или более, переменных стновится в 2 раза больше:
user1_age, user2_age, user1_phone, user2_phone…

В общем, код превращается в какую-то кашу.

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

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

struct User {
string name;
int age;
string phone;
}

Так мы будем все данные для одного юзера группировать вместе. Например, создадим два пользователя с разными данными:
struct User user1 = {"Маша", 15, "+79161234567"};

struct User user2 = {"Пётр", 23, "+79167654321"};

В итоге у нас в коде не 6 переменных, а 2 - user1 и user2. А «внутри» каждого такого объекта хранятся все нужные данные, и мы можем их получить вот так: user1.name, user2.name.

А что же такое класс? Класс - это тоже тип данных, примерно как struct, только более расширенная версия. В классах хранятся не только сами данные (как в структурках), но и - методы (функции) для работы с этими данными.

Например:

class User {

string name;
int age;
string phone;

function say_hello() {
print(«Hello! My name is {name}»);
}

Таким образом, мы можем не только хранить в классе информацию об имени, возрасте и телефоне юзера, но и использовать метод класса say_hello:
user1.say_hello()
>> Hello! My name is Маша

user2.say_hello()
>> Hello! My name is Пётр

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

https://news.1rj.ru/str/rosfemnadzor/2576

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

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

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

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

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

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

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