​​Алгоритмы не нужны?

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

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

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

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

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

«Питончик все сделает»?

Да, он сделает, но какой ценой?

Успехов!

Грокинг – это полное постижение чего-либо в результате глубокого целостного исследования, ещё одно значение «разбираться», «глубоко понимать».

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

Легендарный ученый Роберт Седжвик стал соавтором не менее легендарного курса в двух частях по алгоритмам на Coursera. Курс затрагивает не только основные структуры и алгоритмы, но и более редкие и сложные.

На Stepik тоже есть пару хороших курсов от русскоговорящих авторов. Курс "Алгоритмы: теория и практика. Структуры данных" от Computer Science Center и курс курс от Mail.ru.

В свое время мне было сложно проходить эти курсы, поэтому я решил поискать более легкий материал для начала. Я его нашел в книге "Грокаем алгоритмы". С картиночками, шутками и простыми объяснениями алгоритмы и структуры данных мне дались намного легче.

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

Успехов!

Пути разработчика неисповедимы.

Есть ли жизнь после получения ачивки Senior?

Конечно, есть.

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

Первый путь - это стать рок-звездой программирования. Этот путь подойдет Вам, если программировать и творить новые продукты вам нравится больше, чем говорить с людьми. После Senior Developer можно стать Tech Lead, а затем и податься архитектором. В крупных компаниях уникальный технических специалистов могут называют Distinguished Engineer и очень уважают и ценят. Зарплаты таких людей могут превышать зарплаты их менеджеров.

Второй путь - стать управленцем. Если Вы любите общаться с людми, налаживать процессы и организовывать работы, то это Ваш путь. Team Lead -> Engineering Manager и т.д. Идя по этой ветке, можно стать Project или Product Manager'ом. А затем можно стать VP of Engineering, а может быть даже и CEO - все в Ваших руках.

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

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

Успехов!

​​Алфавит.

Нас, айтишников, очень любят сравнивать с буквами английского алфавита.

20-30 назад большинство IT-специалистов имели навыки формы "I" ("I-shaped"). Эти люди оттачивали глубокую и конкретную область знаний. С созданием новых технологий такие сотрудники стали менее эффективны и более затратны для бизнеса, поэтому компании стали чаще нанимать "T-образных" людей.

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

Сейчас в эру DevOps, SRE и других модных слов появляются люди, обладающие "Pi-shaped" и "Comb-shaped" навыками. Такие люди работают в хороших компаниях, решают интересные задачи и получают большой компенсационный пакет. В общем, живут счастливо.

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

Успехов!

Библия.

Фредерик Филиппс Брукс – американский менеджер, инженер и ученый. Он руководил разработкой операционной системы OS/360. В 1975 году, обобщая опыт этой работы, написал книгу "Мифический человеко-месяц".

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

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

Википедия говорит, что англоязычный журнал PC World поместил книгу Брукса на первое место в списке «Десять IT-книг, которые стыдно признать, что не читал» . Согласно опросу нескольких тысяч членов сообщества StackOverflow, книга вошла в десятку наиболее влиятельных книг по программированию всех времён.

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

Успехов!

​​Карьерный совет.

Келси Хайтауэр - это самый известный Developer Advocate из Google, один из основных контрибьюторов в Kubernetes и просто крутой спикер.

Kubernetes - это одна из самых хайповых технологии последних 2-3 лет (даже больше, чем около machine learning технологии!). Но k8s популярен не только из-за PR машины Google, но и потому что у него лучшая функциональность для работы с контейнеризированными приложениями.

Так что вряд ли лицом всего этого является человек, к мнению которого не стоит прислушаться. Да и совет действительно стоящий.

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

Успехов!

Кампьюча саенс.

Open Source Society University создал полный путь получения образования по Computer Science.

Да, диплом Вы не получите, но это может стать тем фундаментом, на котором вы построите все свои скиллы.

Бесплатно. Без регистрации. Без СМС.

https://github.com/ossu/computer-science

Как выбрать ВУЗ?
#выбрать_вуз

Мой друг побывал на дне открытых дверей IT факультета Высшей школы экономики в Петербурге. Этот факультет остатки легендарного СПБАУ, после внутренних проблем и переезда одной части преподавателей в Вышку, а другой части в СПБГУ.

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

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

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

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

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

Успехов!

P.S. Не реклама.
P.S.S. Если хотите написать отзыв на свой универ, то напишите, пожалуйста, нам на @it_intern_author

Стажировки. Петербург.

В Петербургском Dell EMC открыти 2 стажировки:
- Angular:
- https://spb.hh.ru/vacancy/35566931
- https://spb.hh.ru/vacancy/35614574
- Java - https://spb.hh.ru/vacancy/35567066

Успехов!

Изоляция с пользой.

Список бесплатных предложений SaaS, PaaS и IaaS для вашей лабораторной, курсовой или даже стартапа!

https://github.com/ripienaar/free-for-dev

Даниил Пугач - "Современный WebDev. Основные тренды."

Спикер рассказывает почему он выбрал веб-разработку, какие инструменты использует и как работать в команде.

Рекомендуем всем тем, кто хочет писать под веб.

https://vk.com/video-41603819_456239045

Учитесь программировать, создавая настоящие приложения.

Легендарная компания JetBrains запустила свою платформу для изучения программирования. Сейчас можно учить Java, Python и Kotlin. Скоро появятся учебные курсы по Android, Frontend и Data Science.

Она бесплатна, но, возможно, станет платной. Цитата с сайта академии:
В текущей версии (EAP) JetBrains Academy предоставляется абсолютно бесплатно. Мы сообщим вам, когда появятся варианты лицензирования. Возможности бесплатного использования (например, пробный период) будут доступны после выпуска лицензий.

Не упустите шанс поучиться бесплатно! Успехов!

https://www.jetbrains.com/ru-ru/academy

Верим, что со временем у нас будет даже лучшего этого!

Во имя любви к физике

16 мая 2011 года Уолтер Левин, заслуженный профессор MIT в отставке, вернулся в свой старый лекционный зал, чтобы провести последнюю лекцию, которая была приурочена к публикации его новой книги «FOR THE LOVE OF PHYSICS: From the End of the Rainbow to the Edge Of Time — A Journey Through the Wonders of Physics», написанной совместно с Уорреном Гольдштейном.

«Эта книга раскрывает перед нами незаурядный интеллект Уолтера Левина, его страсть к физике и блестящий навык преподавания. Надеюсь, благодаря ей еще больше людей узнает об этом потрясающем преподавателе и учёном» — Билл Гейтс

Лекция — чистое наслаждение:
https://www.youtube.com/watch?v=iLhl0wMY_uI

Как готовился Левин:

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

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

За неделю до лекции прогоняю ее в пустой аудитории — тут уже понятнее, как организовать мои 50 минут.

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

В MIT студентов не задержишь — они встают со звонком, им ведь и на другие лекции идти. Поэтому нужно уложиться ровно в 50 минут. Возьмите любую мою лекцию: они все от 49 до 51 минуты, не дольше. У меня всегда очень точный план, и я каждые 5 минут сверяю свои пометки в лекции с часами, которые стоят на столе. Если я отстал на минуту, я это отслежу, если две, я уже знаю, что нужно поторопиться, если на три, то все, времени не нагнать. Вот так… нельзя заставлять других так мучатся. (интервью)

The Project Phoenix.

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

Недавно прочитал "Проект Феникс". Это бизнес-роман о том как Билл Палмер, получивший повышение до вице-президента по IT, изменил IT-подразделение и повлиял на улучшения бизнесс процессов корпорации.

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

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

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

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

Про все это написано в этой книге. Однозначно советуем прочитать.

Успехов!

https://www.ozon.ru/context/detail/id/32211144/

Самое смешное описание вакансии, которое когда-либо я читал:
https://hh.ru/vacancy/38235336

Как победить прокрастинацию?

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

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

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

- Минимизировать отвлечение:
фокус, выключенные уведомления, отдельная зона для работы и учебы, т.д.

Подробности и способы следовать этому можно найти в докладе, на скорость 1.5х очень хорошо заходит ;)

Успехов!

https://www.youtube.com/watch?v=fWR5SFhBUWc

Бесплатные курсы.

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

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

Например, курс "Жизнь программиста" рассказывает про виды компаний и какие знания нужны каждому программисту.

Я убежден, что обучение программирования должно начинаться со знакомством с Linux, работой в консоли и Git, поэтому рекомендую пройти курсы "Основы командной строки" и "Системы контроля версий (GIT)".

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

Успехов!

@it_intern

#нереклама

Create More - Consume Less!

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

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

Употребив "новое знание" необходимо создать нечто описывающие это "знание". Заметка, пост или видео должно содержать четкое и понятное объяснение нового.

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

Мне нравится идея создания базы знаний. Я давно делал подобное - конспектировал, писал заметки в Trello и в Evernote.

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

@it_intern

P.S. Мы также завели паблик в ВК. Там будут выходить старые, новые и эксклюзивные посты. Подписывайтесь!

12 шагов к лучшему коду.

Джоэл Спольски известный IT-специалист, работавший на Microsoft Office, Trello, Stack Overflow, Glitch. В далеком 2000 году он опубликовал статью "The Joel Test: 12 Steps to Better Code".

Это трехминутный тест команды программистов о качестве и скорости их работы. 12 простых, но глубоких вопросов.

Если Вы и Ваша команда набирает 12 ответов "да" - это отлично, 11 - терпимо, но меньше 10 - ужасно. Топовые компании и топовые команды получают 12 баллов. Это делает их топовыми и создает разницу между качественными и популярными продуктами и остальными.

Ниже наш вольный перевод с некоторыми комментариями.

1. Используете ли вы систему контроля версий?

Совместная работа программистов становится трудозатратной и ненадежной без системы контроля версий (Version Control System - VCS). Без нее сложнее узнать кто и что делает, найти ошибки и сделать откат изменений, вызвавших баги. Плюсом к этому добавляется невозможность потерять весь код, т.к. VCS обычно распределенны.

2. Можете ли вы сделать билд за один шаг?

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

3. Делаете ли вы ежедневные билды?

Это нужно, чтобы проверить работоспособность проекта.

Я бы добавил сюда Continuous Integration (CI). Чем больше автоматизированных проверок и тестов запускается, тем качественнее получается продукт и быстрее находятся проблемы.

4. Если у вас список багов?

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

5. Исправляете ли вы баги перед написанием нового кода?

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

Баги чинятся за нелинейное и непредсказуемое время - новый код пишется за почти предсказуемое время.

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

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

6. Актуальное ли ваше расписание?

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

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

7. Есть ли у вас спецификации?

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

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

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

8. Спокойные ли условия работы программистов?

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

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

Лучшие инструменты делают программистов счастливее и в конечном счете продуктивнее.

Именно поэтому многие компании тратят большие деньги на технику и программы для разработки ПО.

10. Есть ли у вас тестировщики?

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

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

11. Пишут ли код кандидаты во время собеседования?

Крутое резюме и ответ на сложные вопросы не всегда покажут навык кандидата. Но написание небольшого фрагмента кода это покажет.

Продолжение предыдущего поста...

12. Тестируете ли вы удобство использования?

Надо попросить кого-нибудь поиспользовать ваше творение, чтобы сделать его понятнее для пользователя. Если попросить 5 человек сделать это, то это может решить 95% проблем. Особенно это касается GUI.

Моя набрала 11 баллов. Будем исправляться.

Попробуете этот тест у себя в команде?