Микола Сарри

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

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

Главные роли в любом проекте играют архитектор и менеджер продукта.

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

Блуждая по интернету, можно заметить одну интересную особенность. Все парадигмы программирования воспринимаются людьми совершенно спокойно. Про процедурное программирование говорят спокойно и про модульное. Декларативное программирование — никаких бурь, волнений или холиваров. Функциональное — то же самое. И только вокруг ООП не утихают бури. Одни визжат от него в восторге, другие, наоборот, хаят.

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

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

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

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

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

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

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

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

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

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

История Agile берет свое начало в феврале 2001 года, когда был опубликован документ под названием Agile Manifesto. Текст документа состоит из очевидных философских формул («простота — искусство не делать лишнюю работу») и ряда спорных утверждений (лучшие технические требования, дизайн и архитектура получаются у самоорганизованных команд).