Сегодня мы начинаем серию публикаций новых мастер-классов Технопарка. И первая из них — мастер-класс Алексея Рыбака на свободную тему, в котором он поделился со студентами соображениями о том, чем работа в реальной жизни отличается от учебы. Видео смотрите на нашем сайте, а адаптированную расшифровку — ниже.
Я работаю в компании Badoo достаточно долго, и на моих глазах этот проект из маленького стартапа превратился в большую компанию с сотнями инженеров и тысячным парком серверов, распределенных по нескольким дата-центрам. Сейчас я хотел бы рассказать о том, что считаю достаточно интересным для студентов, выбравших профессию программиста.
Не буду рассказывать о современных трендах и о том сегодня важно и нужно — об этом вам многие могут рассказать. Вместо этого поговорим о некой общечеловеческой адаптации бывших студентов к работе, которую каждый человек проходит в течение одного, а порой и нескольких лет. Процесс этот достаточно болезненный, и далеко не все «правильно» проходят эту адаптацию. Именно эта тема должна больше интересовать студентов и выпускников, чем какие-то модные технологические фишки. Хотя о них мы тоже поговорим, когда коснемся темы самообразования.
![](https://habrastorage.org/r/w780q1/files/c15/124/3e0/c151243e033744efb25c75780bd08a4d.jpg)
Мы заканчиваем вуз с некоторым багажом, который включает в себя представление о своем положении в этом мире, некую систему ценностей. И в первые годы работы этот багаж хорошо заметен для окружающих: как правило, у молодого сотрудника система ценностей несколько смещена. Давайте рассмотрим, почему.
Учеба задает определенный ритм. Экзамены заставляют интенсивно работать, пока мы учимся. Хотя в разных вузах учатся по-разному. Я, например, учился в университете приблизительно так: от сессии до сессии достаточно расслабленно, а во время сессии, наоборот, с многократной нагрузкой. Некоторые преподаватели старались делать промежуточные коллоквиумы, задавали дополнительные работы, что поддерживало некоторый ритм, но по-настоящему интенсивная нагрузка была всего дважды в год. В промежутках же все учились, как могли.
Дальше — экзамен. Также вещь достаточно простая. Уже на первом или втором курсе я взял старый мамин халат, отрезал от него кусочек размером с лист А4, вшил в пиджак и «бомбил» все билеты. Конечно, при этом я продумывал их, тратил время на подготовку. Закончил я с отличием. Подготовка «бомб» очень сильно помогала и понять тему, и запомнить. Но это и близко не похоже на то, что ожидало меня потом, когда я начал работать. В вузе, по большому счету, все решено за вас — ритм вашего обучения полностью определяется извне. Но как только вы начнете работать, все изменится.
Теперь о том, чему учили. Меня не учили computer science, базу пришлось подтягивать самостоятельно. А это, в первую очередь, алгоритмы разного уровня сложности. Мне казалось, что каждому IT-специалисту следует хорошо разбираться в алгоритмах. Но жизнь показала, что это не так. Работ, где действительно необходимо быть специалистом в создании алгоритмов, не так много. Почти все, что сегодня требуется — знать базовые алгоритмы и уметь, читая текст программы, определить его алгоритмическую сложность.
Следующий момент — отношение к программе как к тексту. Когда мы только-только начинаем работать, то рассматриваем свои программы, в первую очередь, не как что-то, что выполняет машина, а просто как текст. И заботимся о том, чтобы текст был красивый и чистый. Ничего плохого в этом нет. Но если при этом основными ценностями для нас является красота, а не удобство декомпозиции, легкость понимания или взаимодействие программы с железом, то работать будет достаточно сложно. Я знаю людей, которые меняли работу, аргументируя это тем, что «компания плохая, потому что я сделал клевое приложение, очень красивое и классное. Но оно затормозило в production, пришли ко мне. Почему ко мне? Админ пусть выясняет, почему она затормозила. Пускай железо купят или еще что-то придумают». Это наглядный пример смещения системы ценностей. Программист должен писать такой код, который будет работать оптимально. А если окажется, что он работает не оптимально, то именно программист должен в этом разобраться.
Во время обучения я задавался вопросами: «Какие программисты самые крутые? Кого принимает на работу какая-нибудь суперкорпорация?». Тогда думал, что в первую очередь берут олимпиадников. Разумеется, ничего плохого в этом нет, но победы на олимпиадах имеют опосредованное отношение к работе. Да, олимпиадники могут в стрессовой обстановке за короткое время решать сложные задачи. Замечательно, что практически у каждого серьезного вуза есть не одна, а несколько команд олимпиадников. В результате жесткого отбора на верхушке пирамиды оказываются достойные люди. Но у этого процесса есть и минусы:
Современное общество навязывает нам эгоцентрическую систему ценностей. Произведения искусства, научные открытия — все это создается яркими личностями, и часто абсолютно индивидуально. Но при производстве программного обеспечения (и не только) дело обстоит совсем иначе: успех почти каждого проекта зависит от усилий групп людей, коллективов, а не одиночек. Пока ты учишься в вузе, у тебя создается впечатление, что никакой коллаборации нет. Думаешь, что можно уехать на необитаемый остров, заниматься там наукой, писать гениальные программы, творить шедевры, и взаимодействовать с кем-либо совершенно необязательно.
Последние пару столетий общество становится все более однородным с точки зрения образования и гражданских прав. Многие, возможно, сочтут это утверждение спорным, но в целом можно сказать, что общество становится все более гуманным. А в последние несколько десятилетий набирает популярность идея ультра-либерализма, согласно которой государство рассматривается исключительно как институт для обслуживания своих граждан. В целом достаточно красивая идея, но есть опасение, что работает она только при небольших масштабах, в однородных обществах, в общем, с множеством оговорок. Однако многие из нас, обладая неким представлением о том, что хорошо и что плохо, каким должно быть идеальное государство и как внешний мир должен относиться к нам, проецируют это ви̒дение на компании, в которые приходят работать. Это большая ошибка. Только при очень больших масштабах можно относиться к своей компании как к государству, и ожидать, что она будет взаимодействовать с вами так же, как государство.
![](https://habrastorage.org/r/w780q1/files/ef6/8b2/0a3/ef68b20a30e34c6c851bb47fa1122d52.jpg)
Следующий момент. За последние 20 лет благодаря интернету сформировались и получили очень сильное развитие разного рода сообщества по интересам. Люди создают новые языки, среды программирования, компоненты. Как правило, эти общества создаются не вокруг каких-то компаний или учебных заведений, а вокруг энтузиастов. И некоторые из таких сообществ декларируют весьма сомнительные ценности. Вот в Perl-coобществе есть такая расхожая фраза: «We will encourage you to develop the three great virtues of a programmer: laziness, impatience and hubris» («Мы призываем вас развивать три самых важных добродетели программиста: лень, нетерпеливость и гордыню»). Звучит весьма странно. При этом автору фразы, Ларри Уоллу, пришлось в свое время долго объяснять, что именно он имел в виду и почему выбрал эти, в общем-то, не самые положительные качества. Но это было давно. А дальше случилось вот что. Не уверен, связано одно с другим или нет, но это сообщество вместо того, чтобы развивать язык Perl, решило создать машину для всех языков программирования и через нее сделать Perl 6. За несколько лет у проекта сменилось несколько архитекторов, а сообщество Perl раскололось на прагматиков, оставшихся на Perl 5, и на странных людей, которые фактически завели проект в тупик. (Примечание: если быть предельно точным, в сентябре 2015 г. появляется что-то похожее на стабильный релиз, но, во-первых, неясно, насколько он готов для продакшн использования, и, во-вторых, прошло более 15 лет, за которые сообщество perl-разработчиков весьма оскуднело.)
В первые послевузовские годы я понял, что на собеседованиях задают вопросы, не имеющие к работе никакого отношения. Самый странный был такой: «Как вы относитесь к творчеству Карлоса Кастанеды?». Я ответил: «Никак не отношусь. Знаю, что такой человек есть, но извините». Мне же нравится спрашивать на собеседовании о том, что такое «плохой программист». На первый взгляд, тоже довольно странный вопрос, но он хотя бы предполагает некий диалог, потому что человек будет вынужден раскрыть свои ценности, рассказать, что хорошо, а что плохо. Ответ на вопрос «Что такое хороший программист» более-менее предсказуем — тут можно использовать какие-то клише. А что такое плохой? Что тебя смущает, что не нравится? Это очень полезно знать.
Когда я начал работать, то вдруг узнал, что во многих компаниях личные качества ценятся едва ли не больше профессиональных. Очень часто можно было услышать, что нужен не «классный программист» или «классный кодер», а «вменяемый человек». Это было новое для меня требование. Я даже слышал, что в ряде компаний применяли достаточно странные для меня тогда мотивационные схемы: существовал коэффициент доброжелательности, то есть сотрудники регулярно получали оценку за доброжелательность — от этого зависел размер премии. Звучит как утопия, но это реальность. Такие компании действительно были, а может и сейчас есть.
Вы можете быть супер-продуктивны, но в любом проекте приходится взаимодействовать с другими членами команды. И все неудачи и потери в большом проекте случаются не по причине чьей-то болезни или из-за того, что кто-то проспал. Обычно корень многих проблем в том, что кто-то с кем-то не сработался. Люди не договорились при выборе очень важного компонента, не договорились о каких-то правилах, и затем каждый начал тянуть одеяло на себя. Поэтому в большом проекте очень важно прокачивать такой скилл, как сотрудничество. Это не то же самое, что доброжелательность, хотя они и взаимосвязаны. Речь о том, что большой проект должен жить годами, но этому сильно мешает наш эгоцентричный багаж в виде смещенной системы ценностей.
По мнению наших инженеров из Лондона, хорошим программистом можно назвать человека, который пишет правильный, хороший, легко читаемый код, с хорошим дизайном, который понимает все компоненты, за которые отвечает команда. Также к признакам хорошего программиста относится легкость совместной работы с ним. Очень большое значение играет конструктивность code review — рецензии на код от коллеги. В больших компаниях никакой код не закоммитится в репозиторий, если ваш коллега его не посмотрит. Если же код не соответствует стандартам, или вообще с ним что-то не так, то коллега должен дать не троллинговый фидбэк, а пояснить, что не соответствует и почему, и дать какие-то рекомендации. То есть диалог должен быть конструктивным. Это отчасти свидетельствует и о доброжелательности.
Также среди качеств хорошего программиста выделяли то, что человек должен быть эффективен на совещаниях. Это тоже очень интересно. Казалось бы, как можно быть неэффективным на встречах с коллегами? Мы собрались, чтобы что-то обсудить. Но, начав работать в компании, вы поймете, что некоторые собрания отнимают огромное количество времени только потому, что люди не могут принять решение или отсутствует ведущий, который управлял бы процессом обсуждения. Поэтому в ряде agile-сценариев используются стэндап-митинги — собрания стоя. Из-за того, что люди устают долго стоять, они стараются как можно быстрее выработать общее решение. Как правило, быть эффективным означает действовать в направлении, где, может быть, вам что-то и не нравится, но вы точно знаете, что добьетесь своего за определенный период времени. Вам нужно научиться планировать и прогнозировать затраты, выбирать менее рискованные пути. Например, если вы хотите использовать новую интересную технологию (которую вы никогда не использовали), а сроки сжаты, то лучше не рисковать, а выбрать решение на основе проверенных технологий.
К признакам хорошего программиста относится и продуктивное времяпрепровождение в офисе. Мне казалось, что в офисе человек работает восемь часов. Это очень оптимистично. Существует масса отвлекающих факторов, иногда даже просто необходимо отвлечься, что-то прочитать, поизучать. В результате именно на продуктивную работу тратится значительно меньше восьми часов.
Одно из самых главных качеств хорошего программиста состоит в том, что, работая в команде, программист ответственно относится к дедлайнам. Следует как минимум заранее предупреждать коллег о том, что процесс разработки идет не совсем так, как задумано, чтобы команда что-то перестроила, поменяла какие-то задачи, была готова. Не надо терпеть до самого конца, а потом в момент дедлайна сказать: «А у меня еще ничего не готово». Нужно планировать свою работу, выполнять обещания, адекватно оценивать сроки.
Все эти ценности очень просты, они кажутся тривиальными. Но когда я начинал работать, то моя собственная система ценностей во многом не совпадала с перечисленными критериями хорошего программиста.
В любом процессе очень здорово найти какую-то модель, построить ее, найти и попробовать какие-то атрибуты, покрутить их и посмотреть, как меняется модель. Давайте в качестве такого атрибута возьмем размеры программы и время ее жизни. А в качестве модели предлагаю рассмотреть программистов. Начнем с программиста-одиночки, который сделал что-то полезное. Он понял, что у пользователя есть какая-то проблема, спроектировал интерфейс, запрограммировал необходимый функционал и выложил куда-то.
Давайте изменим наш атрибут: пусть приложение у нас будет побольше, и живет подольше. Появляются проблемы с качеством. Когда программа маленькая, то вероятность появления багов не очень велика. Но с расширением кодовой базы и увеличением срока эксплуатации риск обнаружения багов сильно возрастает. Если наш гипотетический программист делает мобильное приложение, то возникает масса дополнительных проблем, связанных, например, с разнообразием устройств. На каждой модели продукт должен работать одинаково, но вполне может оказаться, что на каком-то планшете или смартфоне приложение работает неверно. И ради сохранения лояльности пользователей нужно как можно скорее эту проблему решить.
Иногда бывает так, что после релиза нужно исправить сразу несколько ошибок. Даже если вы один, то хоть разорвись, а исправлять надо. И пока вы решаете одну проблему, люди ругаются из-за других. Значит, появляется команда — несколько человек.
Теперь оказывается важным разрабатывать таким образом, чтобы было легко вносить изменения, чтобы код был понятен. Чтобы ваши коллеги могли быстро разобраться в вашем коде и при необходимости внести изменения. Если с кодом работает несколько человек, то нужно заранее договориться обо всех процедурах внесения нового и исправления старого.
Если вы создали веб-приложение, и оно получило достаточное количество пользователей, то необходимо обеспечить его круглосуточную работоспособность. Это означает, что нужно выстраивать инфраструктуру саппорта, причем он должен быть максимально простым. Если вы создаете приложение с множеством функций, то это уже другой уровень сложности — у вас появляется несколько групп разработчиков, каждой из которых надо определить свое направление, наладить взаимосвязь между группами и т.д. Итак, ступени масштабирования таковы:
При переходе от одной ступени к другой на первый план выходят иные требования, отношение к тем или иным вещам сильно меняется. То, что действует на малом масштабе, на большом может вообще не работать или даже оказаться вредным. В свое время осознание этого пришло ко мне не сразу, и стало для меня достаточно большим открытием. Я проходил адаптацию к новой системе ценностей. Думаю, что через это проходят практически все бывшие студенты, начинающие работать.
Перед крупными компаниями стоит вопрос: как помочь новым сотрудникам максимально быстро адаптироваться, как построить нужную культуру? В принципе, эта проблема существует при взаимодействии с любым сообществом. Вы можете принять текущие потребности членов этого сообщества и попытаться добиться своих целей, что-то скрыв, кем-то манипулируя. Или же честно сказать: «Ребята, вы жили неправильно. Надо делать вот так. С одной стороны, театр, с другой — академия». Поэтому многие компании специально пропагандируют внутри своих коллективов систему ценностей, собственное понимание того, что такое хороший сотрудник.
Хочу привести пример из реальной жизни. Где-то в начале 2000-х годов утекает в сеть большая презентация компании Netflix, смысл которой таков: «Мы будем относиться к нашим сотрудникам как к полностью сформировавшимся взрослым людям (fully formed adults), и при отклонении от нашего представления будем объяснять: ребята, нас это не устраивает». И приводились примеры того, каким критериям должны удовлетворять сотрудники. Все вращалось вокруг приоритетов. В большой компании бывает много сложных ситуаций, когда отсутствует очевидно правильное решение, но нужно выбирать какую-то сторону. Как поступить? Например, если вы выбираете между тем, что нужно лично вам, и тем, что нужно вашей группе, то выбирать следует интересы группы, потому что продукт создает именно группа, а не лично вы. А иногда выбор стоит между интересами группы и потребностями компании в целом. Если группа развивала продукт, но по какой-то причине его нужно изменить не так, как вам казалось правильным, попытайтесь посмотреть на это с точки зрения всей компании. Делая сложный выбор, в первую очередь старайтесь понять, что нужно компании. Как только компания достигает определенного размера, велик риск возникновения дедовщины или каких-то привилегированных команд, которые занимаются очень интересными задачами, а всякое барахло отдают новичкам. Такое поведение неприемлемо, если компания хочет создать здоровую культуру.
Еще один из постулатов той же презентации Netflix: «Do not tolerate brilliant jerks» («Не терпите гениев, если они ведут себя как придурки»). Каким бы одаренным не был сотрудник, но если он не сработается с людьми, то с ним придется попрощаться.
Следующий момент. Любая компания выделяет определенные бюджеты, и тут есть два подхода: либо вы начинаете это регулировать, либо говорите: «Все взрослые люди. Мы не будем придумывать кучу правил на все случаи жизни, но вы просто будете тратить эти деньги, словно они ваши собственные». Приведу пример. Ряд сотрудников переезжает работать из Москвы в Лондон. Самый простой способ отчитаться за потраченные средства — предоставить чеки. Но их может быть очень много, ведь возможно много мелких трат. Для этого надо выделить человека, который будет потом с этими чеками разбираться. А можно сделать иначе: «Вот тебе сумма, ты можешь распоряжаться ею как угодно, не отчитывайся, просто с мелочью к нам не приходи». В результате компании не нужно тратить время на проверку каждого чека, при этом мы экономим на транзакционных расходах, так как сотрудники не будут приходить за деньгами на мелкие расходы.
Хочу упомянуть правило «50 на 50». Когда стоит выбор, кто должен понести финансовые или временные расходы, кто должен нести ответственность, зачастую сотрудники считают, что все расходы должна нести компания. Простой пример. Мы с коллегами часто ездим на конференции и перемещаемся между офисами в разных странах — на это уходит очень много времени. Правило «50 на 50» очень простое: можно потратить на перелет весь рабочий день (я поехал в командировку — это же работа), а можно полдня поработать, а полдня потратить на поездку. Ты прилетишь чуть позже, поселишься в гостиницу ближе к вечеру, но от тебя не убудет. 50% времени поработал, 50% забрал от этого времени на перелет.
Это помогает избавиться от многих прописанных правил. Можно сказать: «Ребята, мы взрослые люди — давайте относиться ответственно друг к другу, к компании и к затратам. Если все зарегулировать, то это не пойдет на пользу внутренней культуре компании. Множество правил — очень утомительно».
Во многих компаниях сотрудникам говорят: «Работая у нас, можешь без опасений ходить на собеседования. Продай себя дороже, чем ты получаешь. Узнай, какая сейчас ситуация на рынке — именно это определяет твою заработную плату. Если у тебя есть какие-то уникальные навыки, скорее всего, они будут востребованы. Ходи по рынку — это абсолютно нормально. Если тебе предложат больше, чем платим мы, — поднимем зарплату, если захотим удержать. Если нет, то мы с тобой попрощаемся. Мы за тебя не очень хотим держаться, ты получил куда больше денег. Все, в общем-то, счастливы. Привет».
Такой подход достаточно действенен. Разумеется, не следует рассказывать всем про то, как вы вчера были там, сегодня тут — это не очень хорошо влияет на коллектив. Но имейте в виду, что ходить по рынку надо, чтобы понимать текущую ситуацию.
Ведь человеческая психология устроена так, что, сколько бы вы денег ни получали, в какой-то момент вам начнет казаться, что вам недоплачивают. Особенно часто такая мысль приходит в голову, когда человек вдруг узнает, что в другой компании платят больше. «Так нас тут обманывают! На самом деле вон, какие зарплаты классные». То есть вывод делается по одному измерению, без какой-либо адекватной статистики. Поэтому все, что может сделать работодатель, это сказать: «Сходи в другие места, узнай, пойми, действительно ли это средняя ситуация вообще или для самых одаренных. Посмотрим, сделают ли тебе предложение, может, ты действительно столько стоишь».
Подводя итог вышесказанному: избавляйтесь от старого багажа, смотрите по сторонам, взаимодействуйте с людьми, создавайте совместный проект, прочувствуйте, что сила именно в коллаборации и коммуникации. Научиться работать в команде — это задание №1, особенно если вы уже начали работать.
По оси X отложено абстрактное «внешнее давление», которое, как правило, исходит от вашей компании, от коллег, от начальства. На оси Y обозначена ваша продуктивность. Два варианта графика: «без детонации» и «с детонацией». Если кто-то или что-то вас подталкивает — это хорошо. Обычно это помогает увеличить вашу продуктивность. Другое дело, что есть некоторый психологический предел, для всех разный. И если его пересечь, то ничего хорошего не получится: либо продуктивность просто снизится, либо снизится скачкообразно, очень сильно. Увеличивать продуктивность — значит управлять собой. Управлять собой — это:
По сути это четыре функции любого менеджмента, это верно для управления и коллективом, и государством. Постарайтесь чуть-чуть иначе посмотреть на то, что вы делаете. И как только вы поймете, каковы были цели и как вы их достигли, можете задать вопрос: что можно было бы сделать для более быстрого их достижения? Попробуйте этим начать заниматься как можно раньше.
Самодисциплина и самоконтроль связаны со стрессом — ведь приходится заставлять себя что-то выполнять в ограниченное время. А есть люди, которые вообще не хотят заставлять себя делать что-либо. Когда их подталкивают извне, они воспринимают это как агрессию, и вместо того, чтобы измениться, уходят, убегают. Про убегание я потом расскажу подробнее.
Чтобы облегчить себе и коллегам задачу планирования целей, можно воспользоваться принципом S.M.A.R.T.
Для программистов самая большая проблема — срок. Есть даже такие, кто говорит: «Ребята, давайте вести разработку таким образом, чтобы у нас просто не было дедлайнов. Дедлайны — это стресс». Наверное, такие люди чего-то достигают в жизни, но я убежден, что при таком подходе незапланированных потерь может оказаться достаточно много. Если вы действительно хотите быть продуктивными, каждая ваша цель должна определяться каким-то сроком. Вы можете этот срок сорвать, но тогда сможете задать себе вопрос: «Почему я не выполнил в срок? Насколько я его не выполнил? Что я мог сделать для того, чтобы выполнить вовремя?». А если вы обозначили срок приблизительно, то вы будете его передвигать без какой-либо рефлексии, без самосовершенствования.
В разработке больших проектов самое главное, чтобы у разных компонентов была слабая связанность. Так и с постановкой целей для себя. Чем меньше у вас связанность, тем меньше вероятность того, что за счет торможения или неработоспособности одного компонента забуксует достижение всех остальных целей и задач. Если вы строите какие-то сложные планы и понимаете, что у вас есть сложные взаимосвязи, то можете декомпозировать и переработать список целей.
Зачастую мы попадаем в ловушку своего оптимизма: «Окей, давайте двигаться вперед. Мы какие-то вещи не до конца понимаем, но мы совершенно точно с этим справимся, мы это сделаем». Такой подход — вижу цель, не вижу препятствий — очень важен. Но если быть чрезмерным оптимистом, то у вас в планах появляются некие серые зоны, про которые вы говорите: «Хрен его знает, как это сделать». И неважно, о чем именно будет идти речь: о производительности, о качестве, о поддержке и т.д. Потом окажется, что эта серая зона является камнем преткновения для запуска чего-то большого. Поэтому в планировании очень важно, чтобы этих серых зон не было, либо должен быть кто-то, кто полностью отвечает за серые зоны и гарантирует выполнение этой части работы в определенный срок.
Когда руководитель пришел и поставил вам какую-то задачу — это переключение ответственности. И все, чего он хочет в данной ситуации — чтобы это переключение прошло максимально четко, чтобы не было недопонимания: руководитель думает, что ответственность переключена, работы начались, а у вас появилась масса вопросов, и вы ждете их разъяснения, а за работу еще никто не принимался. В такой ситуации часто происходит перекладывание ответственности друг на друга — непонятно это, непонятно то. Такое бывает не только между руководителем и подчиненным, но и между коллегами. Подобные ситуации неприятны и приводят к временным и эмоциональным потерям. Самое главное — уловить и побороть в себе желание «отбить» передачу ответственности. Если вы действительно что-то хотите уточнить, то задайте все вопросы, а потом скажите: «Да, я принял задачу и иду делать».
Но руководитель хочет не только этого. Он хочет, чтобы вы сами приходили к нему. Очень часто люди говорят: «От меня ничего никому не нужно. Я тут сижу себе спокойно, что-нибудь изучаю». Вы не представляете, сколько руководителей поддержало бы какие-нибудь ваши новые начинания или идеи, если бы вы пришли и доказали, что они действительно нужны. Огромное количество хороших проектов делается на энтузиазме, потому что они родились в вашей голове. И единственное, о чем нужно договориться на берегу — будет ли это востребовано. Чтобы руководитель вам не сказал: «Слушай, по такой-то причине мы это не можем делать».
Очень рекомендую вам с самого начала быть инициативными. Инициатива наказуема в армии, а в обычной жизни огромное количество руководителей мечтает, чтобы вы с ноги открыли дверь и заявили: «Слушай, я придумал такую классную штуку». Вам предоставят возможности, и вы будете счастливы, занимаясь своей работой. Обратная ситуация: есть какая-то проблема, а вы о ней молчите — это приведет к упущенным возможностям. Достаточно просто поговорить, обсудить, сравнить ценности, что-то поменять, перебросить вас на другой проект, помочь вам в чем-то. Но если вы молчите, то у проекта может появиться много проблем.
Конечно, есть и объективные проблемы, с которыми ничего сделать, скорее всего, нельзя. Во-первых, это так называемое «переключение контекста». Объясню на примере многозадачности в операционных системах. Многозадачность ведь есть даже на одном ядре — для этого нужно просто вытеснять один процесс и загружать другой. Некая условная программа-ядро отвечает за работу нескольких параллельных процессов. Разобьем все время на некие кванты и дадим каждому процессу по одному кванту. Переключение выполняемых процессов называется переключением контекста. Но, например, бывают ситуации, когда у вас есть много одновременно живущих процессов, внутри которых инициируется большое количество переключений. То есть переключения могут сильно влиять на производительность системы.
Погружаясь в работу в начале дня, вы не сразу выходите на пик производительности. Спустя какое-то время звонит телефон, подходит коллега, мигает мессенджер, пришло письмо — вы переключаетесь, что-то делаете. Но даже если это заняло минуту, вернувшись к прежней задаче, вам придется вспомнить что-то, снова погрузиться, а на это уходит время. Можно сказать, что это аналог переключения контекста.
Что с этим делать? Уменьшать количество переключений между задачами, договариваться с коллегами и руководством об изменении каких-то процедур, чтобы реже отвлекаться от выполняемых задач. Отключайте всякие уведомления, проверяйте почту по расписанию или хотя бы реже.
Следующий объективный фактор — когда вам в работе приходится сталкиваться с совершенно неизвестными вещами. Возникает естественное отторжение: «Ну, не до конца мне понятна история. Мне надо знать это, это и вот это». А задача, скорее всего, предполагает творческий подход — что вы додумаете какие-то вещи сами, а не отпихнете задачу. Как на уроках физики иногда можно услышать от преподавателя: дано все, что есть. То есть сам строй модель и сам решай, что тебе нужно, а что нет. Это замечательные задачки, не бойтесь их, вы можете сами додумать условия из общих соображений и исправить ситуацию.
А теперь о том, что исправить практически невозможно.
Наконец, давайте вернемся к «убеганию»: когда нам что-то не нравится, и мы пытаемся этого избежать. Бывают разные случаи. Например: «Я не хочу разрабатывать пользовательский интерфейс, хочу заниматься бэкендом». Такое убегание допустимо, если человек обладает особенными способностями в системном программировании, если он хочет прокачиваться как devops и т.д. Во многих компаниях есть небольшое количество людей, занимающихся либо задачами из области системного программирования, либо автоматизирующих выкладку, release engineering и т.д. Но таких задач не очень много. К тому же, такое убегание чревато сидением в «пыльном углу», потому что в большинстве компаний главная ценность — это сделать продукт, то есть удовлетворить пользователя. Если вы не желаете заниматься пользовательским интерфейсом, вы убегаете от продукта, то есть начинаете заниматься побочными вещами. Это в некотором смысле принижает вашу ценность для компании.
Следующий вариант убегания: «Слишком много контроля, слишком давят, я так не хочу. Я хочу работать из дома». Есть много команд, которые работают на удаленке. Кажется, что так работать удобнее, эффективнее и комфортнее. Но нужно понимать, что если вам комфортно, то совершенно не факт, что вы максимально продуктивны. Если нет контроля, то скорее всего, нет и эффективности. Если вам в голову пришла мысль об удаленной работе, то я бы очень порекомендовал поговорить с руководителем. Может быть, вам удастся найти какие-то более эффективные способы взаимодействия.
Программисты жутко не любят контроль. Несмотря на то, что это важно, что контроль все равно будет, программисты этого очень и очень не любят. А самый страшный сон программиста — если его производительность начнут измерять в количестве строк кода. Но какие-то вещи, как ни странно, можно померить в строках кода! Например, покрытие тестами, как сильно увеличивается покрытие со временем у разных команд, какая команда молодец, а какая — не очень. Или перед каким-то большим релизом можно померить скорость внесения новых строк кода в репозиторий, чтобы оценить, действительно ли бóльшая часть изменений касается баг-фиксинга, или все-таки команда по-прежнему коммитит новые фичи. В последнем случае большая вероятность, что релиз было бы разумно чуть-чуть передвинуть, если это возможно, конечно.
Даже при работе с условно попсовыми технологиями есть очень много вещей, которые можно прокачивать. Например, вы работаете с базой данных MySQL. Изучите, как она работает внутри, какова ее архитектура, как оптимизировать запросы, как сделать вашу схему эффективной на большом количестве данных? Всего перечисленного хватит на год самообучения, если не на два. И это станет очень полезным скиллом для вас, потому что вы научитесь создавать приложения совершенно иного уровня.
Зачастую, когда программист только-только начинает свою карьеру, он говорит: «О, блин, шаблоны программирования! Я буду применять такие-то шаблоны. Я буду писать объективно-ориентированный код, который у меня через слой ORM автоматически будет превращаться в SQL, моя ORM-тулза будет автоматически работать со всеми data storage». Или, «Блин, почему мы пишем на этом языке? Смотрите, за углом есть другой клевый язык». Или вот цитата с Хабра: «Я люблю Python таким, какой он есть — шустрый, лаконичный, имеет из-под коробки очень много полезных вещей. Например, можно узнать, является ли число полиморфом всего в одну строку». Множество языков, паттерны, ORM — это все не самое важное, и я бы посоветовал изучать другие вещи.
Для начала, как зарабатываются деньги в вашей компании. Это сразу же вам даст понимание, что компании важно, а что нет — хотя бы на общем уровне. Это поможет соотнести ценности компании со своими собственными.
Далее изучите принятые в вашей компании стандарты и подходы. Например, как налажена работа с ошибками. Код должен быть написан так, чтобы в случае возникновения ошибки можно было поднять всю необходимую информацию и найти причину. Но иногда код пишется так, что вообще непонятно, что произошло. Вы знаете, что была проблема, а в чем — непонятно. Иногда логи вообще не собираются, никто на них не смотрит. В любой компании вырабатывается определенный стиль работы с ошибками. Вам нужно изучить его и соответствовать ему.
Научитесь общаться — онлайн и на совещаниях. Иногда нам кажется, что онлайн можно себе позволить какой-то другой стиль общения — не надо так делать. Научитесь быть максимально полезным на совещаниях, направляйте совещания в конструктивное русло.
Следующий очень важный скилл — научиться быстро делать пилотную версию. Когда мы беремся за разработку, в нас иногда срабатывает перфекционист: «Лучше потрачу побольше времени, но сделаю все классно». На самом деле важно сделать пилот как можно быстрее, пусть даже с костылями, потом их можно всегда переделать. Но вы потратите много времени на создание пилота, а потом окажется, что он не нужен — будет очень обидно.
Изучайте не новые языки программирования, а инфраструктуру, связанную с вашей работой. Я не призываю вас становиться системными администраторами, но вы можете стать сисадмином хотя бы localhost’а — это откроет вам массу возможностей.
Если вы работаете с базой данных, то здесь есть очень много направлений, — узнайте, как она работает, как ее настраивать, прочитайте руководство для системного администратора. Любое такое погружение даст вам понимание того, как устроена база данных, как ее готовить.
И, наконец, самое важное: где бы и на каком бы девайсе ваша программа ни работала, проблемы с производительностью будут всегда. Желательно уметь разобраться, что влияет на производительность и как можно ускорить работу приложения.
Мы хотим их изучать, это наша потребность, мы хотим внедрять их в наши продукты. Но одно дело — когда мы делаем приложение для себя, другое — когда мы предлагаем какие-то новые технологии в коллективе. Очень многие конфликты возникают именно из-за того, что мы понадеялись на использование какой-то технологии, а нам по каким-то причинам не разрешили ее внедрять, поэтому требуется что-то переписать, что-то переделать. Так вот чтобы избежать подобных конфликтов, рекомендую просто посмотреть на новую технологию с такой стороны: любое изменение имеет определенную стоимость и определенные риски — так устроена жизнь. При замене одной технологии на другую или при выборе одной технологии из нескольких тоже есть риск. Эти риски очень простые: возросшая сложность, закрытость или открытость технологии со всеми вытекающими последствиями вроде обучения, стоимости поддержки, наличия и полноты документации.
Также есть понятие качества. Технология может быть очень классной, но может сильно зависеть от сопровождения. Если это один человек, то все зависит от его личностных качеств. Например, насколько быстро он будет реагировать на сообщения о багах. Даже такие вещи нужно учитывать при выборе технологии. Наконец, важное значение имеют разные зависимости, когда одна технология зависит от наличия или работоспособности другой технологии или продукта. Чем сложнее система, тем больше выше вероятность сбоев. Чем больше зависимостей, тем хуже.
Теперь финансовый вопрос: есть стоимость перехода и стоимость поддержки. Вы писали на одном языке, предлагаете перейти на другой. Как правило, язык просто так не сменить, есть некая машина, она куда-то встроена. И тот продукт или сервис, куда она встроена, может хорошо работать для одного сообщества просто потому, что оно больше. Или из-за того, что его в продакшене вкривь и вкось использовали много больших компаний, и все выявленные баги уже исправлены. В сфере server side поддержка — почти половина той работы, которую выполняет большая организация. Поэтому стоимость поддержки важна не меньше, чем стоимость разработки.
Если вы предлагаете какую-то новую технологию, то вам нужно заручиться поддержкой достаточного числа коллег. В больших компаниях есть правило: «Мы разрабатываем на разных языках, но в стандартный набор попадают лишь те языки, на которых разрабатывает не менее определенного количества человек». Почему ставится такое ограничение? Часто бывает так, что какой-то сотрудник инициирует миграцию на другой язык, начинает всех перетаскивать, а посреди разработки вдруг теряет интерес и уходит. Проект оказывается в совершенно разваленном состоянии, потому что главный энтузиаст ушел, а другие программисты этим языком владеют еще плохо.
Есть такое понятие, как «технический долг». Если вы ориентированы на максимально быстрый выпуск продукта, то у вас растет технический долг. Очень важно понимать: если вы выбираете решение между костыльным, правильным и хорошим, то костыльное решение увеличит технический долг. В этом случае поместите задачу в backlog. Когда вы будете посвободнее в плане фич, достаньте ее, сделайте рефакторинг. Если же с самого начала пытаться сделать все хорошо и правильно, то, возможно, ваш продукт будет уже никому не нужен к моменту завершения.
Рекомендую читать, в первую очередь, блоги программистов и разработчиков. И как можно быстрее выходить на людей, которые могут стать для вас наставниками. Пока у вас есть возможность и желание читать — читайте больше. Потом жизнь сложится так, что, скорее всего, у вас не будет оставаться ни времени, ни желания. Поэтому чем больше прочитаете сейчас, тем лучше. Что касается книг, то их великое множество (1, 2, 3, 4). Сейчас навскидку могу выделить пять книг:
Желаю всем студентам так построить свою будущую работу, чтобы вам было максимально комфортно, и чтобы вы эффективно и быстро влились в реальные процессы на вашем будущем месте работы.
Я работаю в компании Badoo достаточно долго, и на моих глазах этот проект из маленького стартапа превратился в большую компанию с сотнями инженеров и тысячным парком серверов, распределенных по нескольким дата-центрам. Сейчас я хотел бы рассказать о том, что считаю достаточно интересным для студентов, выбравших профессию программиста.
Не буду рассказывать о современных трендах и о том сегодня важно и нужно — об этом вам многие могут рассказать. Вместо этого поговорим о некой общечеловеческой адаптации бывших студентов к работе, которую каждый человек проходит в течение одного, а порой и нескольких лет. Процесс этот достаточно болезненный, и далеко не все «правильно» проходят эту адаптацию. Именно эта тема должна больше интересовать студентов и выпускников, чем какие-то модные технологические фишки. Хотя о них мы тоже поговорим, когда коснемся темы самообразования.
![](https://habrastorage.org/files/c15/124/3e0/c151243e033744efb25c75780bd08a4d.jpg)
Багаж
Мы заканчиваем вуз с некоторым багажом, который включает в себя представление о своем положении в этом мире, некую систему ценностей. И в первые годы работы этот багаж хорошо заметен для окружающих: как правило, у молодого сотрудника система ценностей несколько смещена. Давайте рассмотрим, почему.
Учеба задает определенный ритм. Экзамены заставляют интенсивно работать, пока мы учимся. Хотя в разных вузах учатся по-разному. Я, например, учился в университете приблизительно так: от сессии до сессии достаточно расслабленно, а во время сессии, наоборот, с многократной нагрузкой. Некоторые преподаватели старались делать промежуточные коллоквиумы, задавали дополнительные работы, что поддерживало некоторый ритм, но по-настоящему интенсивная нагрузка была всего дважды в год. В промежутках же все учились, как могли.
Дальше — экзамен. Также вещь достаточно простая. Уже на первом или втором курсе я взял старый мамин халат, отрезал от него кусочек размером с лист А4, вшил в пиджак и «бомбил» все билеты. Конечно, при этом я продумывал их, тратил время на подготовку. Закончил я с отличием. Подготовка «бомб» очень сильно помогала и понять тему, и запомнить. Но это и близко не похоже на то, что ожидало меня потом, когда я начал работать. В вузе, по большому счету, все решено за вас — ритм вашего обучения полностью определяется извне. Но как только вы начнете работать, все изменится.
Теперь о том, чему учили. Меня не учили computer science, базу пришлось подтягивать самостоятельно. А это, в первую очередь, алгоритмы разного уровня сложности. Мне казалось, что каждому IT-специалисту следует хорошо разбираться в алгоритмах. Но жизнь показала, что это не так. Работ, где действительно необходимо быть специалистом в создании алгоритмов, не так много. Почти все, что сегодня требуется — знать базовые алгоритмы и уметь, читая текст программы, определить его алгоритмическую сложность.
Следующий момент — отношение к программе как к тексту. Когда мы только-только начинаем работать, то рассматриваем свои программы, в первую очередь, не как что-то, что выполняет машина, а просто как текст. И заботимся о том, чтобы текст был красивый и чистый. Ничего плохого в этом нет. Но если при этом основными ценностями для нас является красота, а не удобство декомпозиции, легкость понимания или взаимодействие программы с железом, то работать будет достаточно сложно. Я знаю людей, которые меняли работу, аргументируя это тем, что «компания плохая, потому что я сделал клевое приложение, очень красивое и классное. Но оно затормозило в production, пришли ко мне. Почему ко мне? Админ пусть выясняет, почему она затормозила. Пускай железо купят или еще что-то придумают». Это наглядный пример смещения системы ценностей. Программист должен писать такой код, который будет работать оптимально. А если окажется, что он работает не оптимально, то именно программист должен в этом разобраться.
Во время обучения я задавался вопросами: «Какие программисты самые крутые? Кого принимает на работу какая-нибудь суперкорпорация?». Тогда думал, что в первую очередь берут олимпиадников. Разумеется, ничего плохого в этом нет, но победы на олимпиадах имеют опосредованное отношение к работе. Да, олимпиадники могут в стрессовой обстановке за короткое время решать сложные задачи. Замечательно, что практически у каждого серьезного вуза есть не одна, а несколько команд олимпиадников. В результате жесткого отбора на верхушке пирамиды оказываются достойные люди. Но у этого процесса есть и минусы:
- ребята решают крайне специфические задачи, которые в реальности встречаются КРАЙНЕ редко — их не более 1%;
- плохо то, что делают они это за очень короткое время. Да, это показатель недюжинных способностей и стрессоустойчивости, но в жизни приложения обычно пишутся не в такие короткие временные интервалы, и не в одиночку.
Смещенная система ценностей
Современное общество навязывает нам эгоцентрическую систему ценностей. Произведения искусства, научные открытия — все это создается яркими личностями, и часто абсолютно индивидуально. Но при производстве программного обеспечения (и не только) дело обстоит совсем иначе: успех почти каждого проекта зависит от усилий групп людей, коллективов, а не одиночек. Пока ты учишься в вузе, у тебя создается впечатление, что никакой коллаборации нет. Думаешь, что можно уехать на необитаемый остров, заниматься там наукой, писать гениальные программы, творить шедевры, и взаимодействовать с кем-либо совершенно необязательно.
Последние пару столетий общество становится все более однородным с точки зрения образования и гражданских прав. Многие, возможно, сочтут это утверждение спорным, но в целом можно сказать, что общество становится все более гуманным. А в последние несколько десятилетий набирает популярность идея ультра-либерализма, согласно которой государство рассматривается исключительно как институт для обслуживания своих граждан. В целом достаточно красивая идея, но есть опасение, что работает она только при небольших масштабах, в однородных обществах, в общем, с множеством оговорок. Однако многие из нас, обладая неким представлением о том, что хорошо и что плохо, каким должно быть идеальное государство и как внешний мир должен относиться к нам, проецируют это ви̒дение на компании, в которые приходят работать. Это большая ошибка. Только при очень больших масштабах можно относиться к своей компании как к государству, и ожидать, что она будет взаимодействовать с вами так же, как государство.
![](https://habrastorage.org/files/ef6/8b2/0a3/ef68b20a30e34c6c851bb47fa1122d52.jpg)
Следующий момент. За последние 20 лет благодаря интернету сформировались и получили очень сильное развитие разного рода сообщества по интересам. Люди создают новые языки, среды программирования, компоненты. Как правило, эти общества создаются не вокруг каких-то компаний или учебных заведений, а вокруг энтузиастов. И некоторые из таких сообществ декларируют весьма сомнительные ценности. Вот в Perl-coобществе есть такая расхожая фраза: «We will encourage you to develop the three great virtues of a programmer: laziness, impatience and hubris» («Мы призываем вас развивать три самых важных добродетели программиста: лень, нетерпеливость и гордыню»). Звучит весьма странно. При этом автору фразы, Ларри Уоллу, пришлось в свое время долго объяснять, что именно он имел в виду и почему выбрал эти, в общем-то, не самые положительные качества. Но это было давно. А дальше случилось вот что. Не уверен, связано одно с другим или нет, но это сообщество вместо того, чтобы развивать язык Perl, решило создать машину для всех языков программирования и через нее сделать Perl 6. За несколько лет у проекта сменилось несколько архитекторов, а сообщество Perl раскололось на прагматиков, оставшихся на Perl 5, и на странных людей, которые фактически завели проект в тупик. (Примечание: если быть предельно точным, в сентябре 2015 г. появляется что-то похожее на стабильный релиз, но, во-первых, неясно, насколько он готов для продакшн использования, и, во-вторых, прошло более 15 лет, за которые сообщество perl-разработчиков весьма оскуднело.)
В первые послевузовские годы я понял, что на собеседованиях задают вопросы, не имеющие к работе никакого отношения. Самый странный был такой: «Как вы относитесь к творчеству Карлоса Кастанеды?». Я ответил: «Никак не отношусь. Знаю, что такой человек есть, но извините». Мне же нравится спрашивать на собеседовании о том, что такое «плохой программист». На первый взгляд, тоже довольно странный вопрос, но он хотя бы предполагает некий диалог, потому что человек будет вынужден раскрыть свои ценности, рассказать, что хорошо, а что плохо. Ответ на вопрос «Что такое хороший программист» более-менее предсказуем — тут можно использовать какие-то клише. А что такое плохой? Что тебя смущает, что не нравится? Это очень полезно знать.
Коллектив
Когда я начал работать, то вдруг узнал, что во многих компаниях личные качества ценятся едва ли не больше профессиональных. Очень часто можно было услышать, что нужен не «классный программист» или «классный кодер», а «вменяемый человек». Это было новое для меня требование. Я даже слышал, что в ряде компаний применяли достаточно странные для меня тогда мотивационные схемы: существовал коэффициент доброжелательности, то есть сотрудники регулярно получали оценку за доброжелательность — от этого зависел размер премии. Звучит как утопия, но это реальность. Такие компании действительно были, а может и сейчас есть.
Вы можете быть супер-продуктивны, но в любом проекте приходится взаимодействовать с другими членами команды. И все неудачи и потери в большом проекте случаются не по причине чьей-то болезни или из-за того, что кто-то проспал. Обычно корень многих проблем в том, что кто-то с кем-то не сработался. Люди не договорились при выборе очень важного компонента, не договорились о каких-то правилах, и затем каждый начал тянуть одеяло на себя. Поэтому в большом проекте очень важно прокачивать такой скилл, как сотрудничество. Это не то же самое, что доброжелательность, хотя они и взаимосвязаны. Речь о том, что большой проект должен жить годами, но этому сильно мешает наш эгоцентричный багаж в виде смещенной системы ценностей.
Что такое хороший программист?
По мнению наших инженеров из Лондона, хорошим программистом можно назвать человека, который пишет правильный, хороший, легко читаемый код, с хорошим дизайном, который понимает все компоненты, за которые отвечает команда. Также к признакам хорошего программиста относится легкость совместной работы с ним. Очень большое значение играет конструктивность code review — рецензии на код от коллеги. В больших компаниях никакой код не закоммитится в репозиторий, если ваш коллега его не посмотрит. Если же код не соответствует стандартам, или вообще с ним что-то не так, то коллега должен дать не троллинговый фидбэк, а пояснить, что не соответствует и почему, и дать какие-то рекомендации. То есть диалог должен быть конструктивным. Это отчасти свидетельствует и о доброжелательности.
Также среди качеств хорошего программиста выделяли то, что человек должен быть эффективен на совещаниях. Это тоже очень интересно. Казалось бы, как можно быть неэффективным на встречах с коллегами? Мы собрались, чтобы что-то обсудить. Но, начав работать в компании, вы поймете, что некоторые собрания отнимают огромное количество времени только потому, что люди не могут принять решение или отсутствует ведущий, который управлял бы процессом обсуждения. Поэтому в ряде agile-сценариев используются стэндап-митинги — собрания стоя. Из-за того, что люди устают долго стоять, они стараются как можно быстрее выработать общее решение. Как правило, быть эффективным означает действовать в направлении, где, может быть, вам что-то и не нравится, но вы точно знаете, что добьетесь своего за определенный период времени. Вам нужно научиться планировать и прогнозировать затраты, выбирать менее рискованные пути. Например, если вы хотите использовать новую интересную технологию (которую вы никогда не использовали), а сроки сжаты, то лучше не рисковать, а выбрать решение на основе проверенных технологий.
К признакам хорошего программиста относится и продуктивное времяпрепровождение в офисе. Мне казалось, что в офисе человек работает восемь часов. Это очень оптимистично. Существует масса отвлекающих факторов, иногда даже просто необходимо отвлечься, что-то прочитать, поизучать. В результате именно на продуктивную работу тратится значительно меньше восьми часов.
Одно из самых главных качеств хорошего программиста состоит в том, что, работая в команде, программист ответственно относится к дедлайнам. Следует как минимум заранее предупреждать коллег о том, что процесс разработки идет не совсем так, как задумано, чтобы команда что-то перестроила, поменяла какие-то задачи, была готова. Не надо терпеть до самого конца, а потом в момент дедлайна сказать: «А у меня еще ничего не готово». Нужно планировать свою работу, выполнять обещания, адекватно оценивать сроки.
Все эти ценности очень просты, они кажутся тривиальными. Но когда я начинал работать, то моя собственная система ценностей во многом не совпадала с перечисленными критериями хорошего программиста.
В любом процессе очень здорово найти какую-то модель, построить ее, найти и попробовать какие-то атрибуты, покрутить их и посмотреть, как меняется модель. Давайте в качестве такого атрибута возьмем размеры программы и время ее жизни. А в качестве модели предлагаю рассмотреть программистов. Начнем с программиста-одиночки, который сделал что-то полезное. Он понял, что у пользователя есть какая-то проблема, спроектировал интерфейс, запрограммировал необходимый функционал и выложил куда-то.
Давайте изменим наш атрибут: пусть приложение у нас будет побольше, и живет подольше. Появляются проблемы с качеством. Когда программа маленькая, то вероятность появления багов не очень велика. Но с расширением кодовой базы и увеличением срока эксплуатации риск обнаружения багов сильно возрастает. Если наш гипотетический программист делает мобильное приложение, то возникает масса дополнительных проблем, связанных, например, с разнообразием устройств. На каждой модели продукт должен работать одинаково, но вполне может оказаться, что на каком-то планшете или смартфоне приложение работает неверно. И ради сохранения лояльности пользователей нужно как можно скорее эту проблему решить.
Иногда бывает так, что после релиза нужно исправить сразу несколько ошибок. Даже если вы один, то хоть разорвись, а исправлять надо. И пока вы решаете одну проблему, люди ругаются из-за других. Значит, появляется команда — несколько человек.
Теперь оказывается важным разрабатывать таким образом, чтобы было легко вносить изменения, чтобы код был понятен. Чтобы ваши коллеги могли быстро разобраться в вашем коде и при необходимости внести изменения. Если с кодом работает несколько человек, то нужно заранее договориться обо всех процедурах внесения нового и исправления старого.
Особенности «взрослой» разработки
Если вы создали веб-приложение, и оно получило достаточное количество пользователей, то необходимо обеспечить его круглосуточную работоспособность. Это означает, что нужно выстраивать инфраструктуру саппорта, причем он должен быть максимально простым. Если вы создаете приложение с множеством функций, то это уже другой уровень сложности — у вас появляется несколько групп разработчиков, каждой из которых надо определить свое направление, наладить взаимосвязь между группами и т.д. Итак, ступени масштабирования таковы:
- программист-одиночка;
- небольшая команда/отдел (5-7 человек);
- несколько групп/команд, которые взаимодействуют друг с другом;
- компания, состоящая из департаментов, состоящих из групп.
При переходе от одной ступени к другой на первый план выходят иные требования, отношение к тем или иным вещам сильно меняется. То, что действует на малом масштабе, на большом может вообще не работать или даже оказаться вредным. В свое время осознание этого пришло ко мне не сразу, и стало для меня достаточно большим открытием. Я проходил адаптацию к новой системе ценностей. Думаю, что через это проходят практически все бывшие студенты, начинающие работать.
Работа в коллективе
Перед крупными компаниями стоит вопрос: как помочь новым сотрудникам максимально быстро адаптироваться, как построить нужную культуру? В принципе, эта проблема существует при взаимодействии с любым сообществом. Вы можете принять текущие потребности членов этого сообщества и попытаться добиться своих целей, что-то скрыв, кем-то манипулируя. Или же честно сказать: «Ребята, вы жили неправильно. Надо делать вот так. С одной стороны, театр, с другой — академия». Поэтому многие компании специально пропагандируют внутри своих коллективов систему ценностей, собственное понимание того, что такое хороший сотрудник.
Хочу привести пример из реальной жизни. Где-то в начале 2000-х годов утекает в сеть большая презентация компании Netflix, смысл которой таков: «Мы будем относиться к нашим сотрудникам как к полностью сформировавшимся взрослым людям (fully formed adults), и при отклонении от нашего представления будем объяснять: ребята, нас это не устраивает». И приводились примеры того, каким критериям должны удовлетворять сотрудники. Все вращалось вокруг приоритетов. В большой компании бывает много сложных ситуаций, когда отсутствует очевидно правильное решение, но нужно выбирать какую-то сторону. Как поступить? Например, если вы выбираете между тем, что нужно лично вам, и тем, что нужно вашей группе, то выбирать следует интересы группы, потому что продукт создает именно группа, а не лично вы. А иногда выбор стоит между интересами группы и потребностями компании в целом. Если группа развивала продукт, но по какой-то причине его нужно изменить не так, как вам казалось правильным, попытайтесь посмотреть на это с точки зрения всей компании. Делая сложный выбор, в первую очередь старайтесь понять, что нужно компании. Как только компания достигает определенного размера, велик риск возникновения дедовщины или каких-то привилегированных команд, которые занимаются очень интересными задачами, а всякое барахло отдают новичкам. Такое поведение неприемлемо, если компания хочет создать здоровую культуру.
Еще один из постулатов той же презентации Netflix: «Do not tolerate brilliant jerks» («Не терпите гениев, если они ведут себя как придурки»). Каким бы одаренным не был сотрудник, но если он не сработается с людьми, то с ним придется попрощаться.
Следующий момент. Любая компания выделяет определенные бюджеты, и тут есть два подхода: либо вы начинаете это регулировать, либо говорите: «Все взрослые люди. Мы не будем придумывать кучу правил на все случаи жизни, но вы просто будете тратить эти деньги, словно они ваши собственные». Приведу пример. Ряд сотрудников переезжает работать из Москвы в Лондон. Самый простой способ отчитаться за потраченные средства — предоставить чеки. Но их может быть очень много, ведь возможно много мелких трат. Для этого надо выделить человека, который будет потом с этими чеками разбираться. А можно сделать иначе: «Вот тебе сумма, ты можешь распоряжаться ею как угодно, не отчитывайся, просто с мелочью к нам не приходи». В результате компании не нужно тратить время на проверку каждого чека, при этом мы экономим на транзакционных расходах, так как сотрудники не будут приходить за деньгами на мелкие расходы.
Хочу упомянуть правило «50 на 50». Когда стоит выбор, кто должен понести финансовые или временные расходы, кто должен нести ответственность, зачастую сотрудники считают, что все расходы должна нести компания. Простой пример. Мы с коллегами часто ездим на конференции и перемещаемся между офисами в разных странах — на это уходит очень много времени. Правило «50 на 50» очень простое: можно потратить на перелет весь рабочий день (я поехал в командировку — это же работа), а можно полдня поработать, а полдня потратить на поездку. Ты прилетишь чуть позже, поселишься в гостиницу ближе к вечеру, но от тебя не убудет. 50% времени поработал, 50% забрал от этого времени на перелет.
Это помогает избавиться от многих прописанных правил. Можно сказать: «Ребята, мы взрослые люди — давайте относиться ответственно друг к другу, к компании и к затратам. Если все зарегулировать, то это не пойдет на пользу внутренней культуре компании. Множество правил — очень утомительно».
Поиск лучшей доли
Во многих компаниях сотрудникам говорят: «Работая у нас, можешь без опасений ходить на собеседования. Продай себя дороже, чем ты получаешь. Узнай, какая сейчас ситуация на рынке — именно это определяет твою заработную плату. Если у тебя есть какие-то уникальные навыки, скорее всего, они будут востребованы. Ходи по рынку — это абсолютно нормально. Если тебе предложат больше, чем платим мы, — поднимем зарплату, если захотим удержать. Если нет, то мы с тобой попрощаемся. Мы за тебя не очень хотим держаться, ты получил куда больше денег. Все, в общем-то, счастливы. Привет».
Такой подход достаточно действенен. Разумеется, не следует рассказывать всем про то, как вы вчера были там, сегодня тут — это не очень хорошо влияет на коллектив. Но имейте в виду, что ходить по рынку надо, чтобы понимать текущую ситуацию.
Ведь человеческая психология устроена так, что, сколько бы вы денег ни получали, в какой-то момент вам начнет казаться, что вам недоплачивают. Особенно часто такая мысль приходит в голову, когда человек вдруг узнает, что в другой компании платят больше. «Так нас тут обманывают! На самом деле вон, какие зарплаты классные». То есть вывод делается по одному измерению, без какой-либо адекватной статистики. Поэтому все, что может сделать работодатель, это сказать: «Сходи в другие места, узнай, пойми, действительно ли это средняя ситуация вообще или для самых одаренных. Посмотрим, сделают ли тебе предложение, может, ты действительно столько стоишь».
Подводя итог вышесказанному: избавляйтесь от старого багажа, смотрите по сторонам, взаимодействуйте с людьми, создавайте совместный проект, прочувствуйте, что сила именно в коллаборации и коммуникации. Научиться работать в команде — это задание №1, особенно если вы уже начали работать.
Личная продуктивность
![](https://habrastorage.org/files/e10/5c5/621/e105c56215234bd680f3ae2475d6c2b9.png)
По оси X отложено абстрактное «внешнее давление», которое, как правило, исходит от вашей компании, от коллег, от начальства. На оси Y обозначена ваша продуктивность. Два варианта графика: «без детонации» и «с детонацией». Если кто-то или что-то вас подталкивает — это хорошо. Обычно это помогает увеличить вашу продуктивность. Другое дело, что есть некоторый психологический предел, для всех разный. И если его пересечь, то ничего хорошего не получится: либо продуктивность просто снизится, либо снизится скачкообразно, очень сильно. Увеличивать продуктивность — значит управлять собой. Управлять собой — это:
- планирование: составить для себя план целей, которых необходимо достигнуть. Нельзя быть продуктивным, если целей нет;
- организация: если что-то мешает выполнению плана — убрать или поменять;
- мотивация: необходимо мотивировать себя;
- контроль: отслеживать результат в промежуточных точках.
По сути это четыре функции любого менеджмента, это верно для управления и коллективом, и государством. Постарайтесь чуть-чуть иначе посмотреть на то, что вы делаете. И как только вы поймете, каковы были цели и как вы их достигли, можете задать вопрос: что можно было бы сделать для более быстрого их достижения? Попробуйте этим начать заниматься как можно раньше.
Самодисциплина и самоконтроль связаны со стрессом — ведь приходится заставлять себя что-то выполнять в ограниченное время. А есть люди, которые вообще не хотят заставлять себя делать что-либо. Когда их подталкивают извне, они воспринимают это как агрессию, и вместо того, чтобы измениться, уходят, убегают. Про убегание я потом расскажу подробнее.
Чтобы облегчить себе и коллегам задачу планирования целей, можно воспользоваться принципом S.M.A.R.T.
- S — specific. Каждая цель должна быть определенная. То есть конкретно вот здесь нам нужно сделать вот этого.
- M — measurable. Цель должна быть измеряемой. Пример плохой постановки цели — улучшить покрытие кода. «Ну что, ребята, вы улучшали?» — «Улучшали» — «Улучшили?» — «Улучшили» — «А как?». Правильная формулировка — «Увеличить покрытие кода тестами с 50 до 55%.
- A — achievable. Цель должна быть достижимой — это очевидно. Можно поставить себе глобальную цель: стать очень богатым через год. Но, скорее всего, цель должна представлять собой небольшое количество подцелей, какое-то количество конкретных шагов, и чем более реалистичными они будут, тем больше у вас воспитается позитивное отношение к этому методу.
- R — relevant. Намечая какие-то задачи, необходимо отдавать себе отчет, что их выполнение поможет вам достичь поставленных целей.
- T — time-related. Любая цель должна иметь некий дедлайн — срок, к которому все должно быть сделано. Из всех пяти пунктов этот — самый важный.
Для программистов самая большая проблема — срок. Есть даже такие, кто говорит: «Ребята, давайте вести разработку таким образом, чтобы у нас просто не было дедлайнов. Дедлайны — это стресс». Наверное, такие люди чего-то достигают в жизни, но я убежден, что при таком подходе незапланированных потерь может оказаться достаточно много. Если вы действительно хотите быть продуктивными, каждая ваша цель должна определяться каким-то сроком. Вы можете этот срок сорвать, но тогда сможете задать себе вопрос: «Почему я не выполнил в срок? Насколько я его не выполнил? Что я мог сделать для того, чтобы выполнить вовремя?». А если вы обозначили срок приблизительно, то вы будете его передвигать без какой-либо рефлексии, без самосовершенствования.
В разработке больших проектов самое главное, чтобы у разных компонентов была слабая связанность. Так и с постановкой целей для себя. Чем меньше у вас связанность, тем меньше вероятность того, что за счет торможения или неработоспособности одного компонента забуксует достижение всех остальных целей и задач. Если вы строите какие-то сложные планы и понимаете, что у вас есть сложные взаимосвязи, то можете декомпозировать и переработать список целей.
Зачастую мы попадаем в ловушку своего оптимизма: «Окей, давайте двигаться вперед. Мы какие-то вещи не до конца понимаем, но мы совершенно точно с этим справимся, мы это сделаем». Такой подход — вижу цель, не вижу препятствий — очень важен. Но если быть чрезмерным оптимистом, то у вас в планах появляются некие серые зоны, про которые вы говорите: «Хрен его знает, как это сделать». И неважно, о чем именно будет идти речь: о производительности, о качестве, о поддержке и т.д. Потом окажется, что эта серая зона является камнем преткновения для запуска чего-то большого. Поэтому в планировании очень важно, чтобы этих серых зон не было, либо должен быть кто-то, кто полностью отвечает за серые зоны и гарантирует выполнение этой части работы в определенный срок.
Взаимодействие с руководителем
Когда руководитель пришел и поставил вам какую-то задачу — это переключение ответственности. И все, чего он хочет в данной ситуации — чтобы это переключение прошло максимально четко, чтобы не было недопонимания: руководитель думает, что ответственность переключена, работы начались, а у вас появилась масса вопросов, и вы ждете их разъяснения, а за работу еще никто не принимался. В такой ситуации часто происходит перекладывание ответственности друг на друга — непонятно это, непонятно то. Такое бывает не только между руководителем и подчиненным, но и между коллегами. Подобные ситуации неприятны и приводят к временным и эмоциональным потерям. Самое главное — уловить и побороть в себе желание «отбить» передачу ответственности. Если вы действительно что-то хотите уточнить, то задайте все вопросы, а потом скажите: «Да, я принял задачу и иду делать».
Но руководитель хочет не только этого. Он хочет, чтобы вы сами приходили к нему. Очень часто люди говорят: «От меня ничего никому не нужно. Я тут сижу себе спокойно, что-нибудь изучаю». Вы не представляете, сколько руководителей поддержало бы какие-нибудь ваши новые начинания или идеи, если бы вы пришли и доказали, что они действительно нужны. Огромное количество хороших проектов делается на энтузиазме, потому что они родились в вашей голове. И единственное, о чем нужно договориться на берегу — будет ли это востребовано. Чтобы руководитель вам не сказал: «Слушай, по такой-то причине мы это не можем делать».
Очень рекомендую вам с самого начала быть инициативными. Инициатива наказуема в армии, а в обычной жизни огромное количество руководителей мечтает, чтобы вы с ноги открыли дверь и заявили: «Слушай, я придумал такую классную штуку». Вам предоставят возможности, и вы будете счастливы, занимаясь своей работой. Обратная ситуация: есть какая-то проблема, а вы о ней молчите — это приведет к упущенным возможностям. Достаточно просто поговорить, обсудить, сравнить ценности, что-то поменять, перебросить вас на другой проект, помочь вам в чем-то. Но если вы молчите, то у проекта может появиться много проблем.
Конечно, есть и объективные проблемы, с которыми ничего сделать, скорее всего, нельзя. Во-первых, это так называемое «переключение контекста». Объясню на примере многозадачности в операционных системах. Многозадачность ведь есть даже на одном ядре — для этого нужно просто вытеснять один процесс и загружать другой. Некая условная программа-ядро отвечает за работу нескольких параллельных процессов. Разобьем все время на некие кванты и дадим каждому процессу по одному кванту. Переключение выполняемых процессов называется переключением контекста. Но, например, бывают ситуации, когда у вас есть много одновременно живущих процессов, внутри которых инициируется большое количество переключений. То есть переключения могут сильно влиять на производительность системы.
Погружаясь в работу в начале дня, вы не сразу выходите на пик производительности. Спустя какое-то время звонит телефон, подходит коллега, мигает мессенджер, пришло письмо — вы переключаетесь, что-то делаете. Но даже если это заняло минуту, вернувшись к прежней задаче, вам придется вспомнить что-то, снова погрузиться, а на это уходит время. Можно сказать, что это аналог переключения контекста.
Что с этим делать? Уменьшать количество переключений между задачами, договариваться с коллегами и руководством об изменении каких-то процедур, чтобы реже отвлекаться от выполняемых задач. Отключайте всякие уведомления, проверяйте почту по расписанию или хотя бы реже.
Следующий объективный фактор — когда вам в работе приходится сталкиваться с совершенно неизвестными вещами. Возникает естественное отторжение: «Ну, не до конца мне понятна история. Мне надо знать это, это и вот это». А задача, скорее всего, предполагает творческий подход — что вы додумаете какие-то вещи сами, а не отпихнете задачу. Как на уроках физики иногда можно услышать от преподавателя: дано все, что есть. То есть сам строй модель и сам решай, что тебе нужно, а что нет. Это замечательные задачки, не бойтесь их, вы можете сами додумать условия из общих соображений и исправить ситуацию.
А теперь о том, что исправить практически невозможно.
- В больших компаниях продуктовые менеджеры — это, как правило, не те, кто непосредственно пишет код и придумывает приложения, поэтому к вам может идти поток постоянно меняющихся требований. Нужно уметь разговаривать с такими людьми. Самая распространенная ошибка приблизительно такая: человек, который ставит задачу, предполагает, что он сделал лишь небольшое изменение и сроки от этого не поменяются. «Подумаешь, где-то вот здесь рядом с маленьким сайтом вырос маленький интернет-магазин. Полно же интернет-магазинов. Наверняка есть что-то готовое. Прикрутить — полчаса работы». Очень важно, чтобы все изменения вносились в режиме диалога. Чтобы культура в компании подразумевала, что все участники сядут и признают, что внесение изменений, скорее всего, приведет к сдвигу сроков.
- Бывает так, что у вас очень жесткий дедлайн и просто необходимо успеть к такому-то числу. Это значит, что нужно провести реприоритезацию задач. Проблема объективная, как с ней бороться — более-менее понятно, но это одна из самых распространенных и сложных стрессовых ситуаций, в которых просто нужно научиться жить.
Об убегании
![](https://habrastorage.org/files/a21/018/dca/a21018dcac0b4d5fb177affe82778db1.png)
Следующий вариант убегания: «Слишком много контроля, слишком давят, я так не хочу. Я хочу работать из дома». Есть много команд, которые работают на удаленке. Кажется, что так работать удобнее, эффективнее и комфортнее. Но нужно понимать, что если вам комфортно, то совершенно не факт, что вы максимально продуктивны. Если нет контроля, то скорее всего, нет и эффективности. Если вам в голову пришла мысль об удаленной работе, то я бы очень порекомендовал поговорить с руководителем. Может быть, вам удастся найти какие-то более эффективные способы взаимодействия.
Измерение строками
Программисты жутко не любят контроль. Несмотря на то, что это важно, что контроль все равно будет, программисты этого очень и очень не любят. А самый страшный сон программиста — если его производительность начнут измерять в количестве строк кода. Но какие-то вещи, как ни странно, можно померить в строках кода! Например, покрытие тестами, как сильно увеличивается покрытие со временем у разных команд, какая команда молодец, а какая — не очень. Или перед каким-то большим релизом можно померить скорость внесения новых строк кода в репозиторий, чтобы оценить, действительно ли бóльшая часть изменений касается баг-фиксинга, или все-таки команда по-прежнему коммитит новые фичи. В последнем случае большая вероятность, что релиз было бы разумно чуть-чуть передвинуть, если это возможно, конечно.
Самообучение
Даже при работе с условно попсовыми технологиями есть очень много вещей, которые можно прокачивать. Например, вы работаете с базой данных MySQL. Изучите, как она работает внутри, какова ее архитектура, как оптимизировать запросы, как сделать вашу схему эффективной на большом количестве данных? Всего перечисленного хватит на год самообучения, если не на два. И это станет очень полезным скиллом для вас, потому что вы научитесь создавать приложения совершенно иного уровня.
Зачастую, когда программист только-только начинает свою карьеру, он говорит: «О, блин, шаблоны программирования! Я буду применять такие-то шаблоны. Я буду писать объективно-ориентированный код, который у меня через слой ORM автоматически будет превращаться в SQL, моя ORM-тулза будет автоматически работать со всеми data storage». Или, «Блин, почему мы пишем на этом языке? Смотрите, за углом есть другой клевый язык». Или вот цитата с Хабра: «Я люблю Python таким, какой он есть — шустрый, лаконичный, имеет из-под коробки очень много полезных вещей. Например, можно узнать, является ли число полиморфом всего в одну строку». Множество языков, паттерны, ORM — это все не самое важное, и я бы посоветовал изучать другие вещи.
Для начала, как зарабатываются деньги в вашей компании. Это сразу же вам даст понимание, что компании важно, а что нет — хотя бы на общем уровне. Это поможет соотнести ценности компании со своими собственными.
Далее изучите принятые в вашей компании стандарты и подходы. Например, как налажена работа с ошибками. Код должен быть написан так, чтобы в случае возникновения ошибки можно было поднять всю необходимую информацию и найти причину. Но иногда код пишется так, что вообще непонятно, что произошло. Вы знаете, что была проблема, а в чем — непонятно. Иногда логи вообще не собираются, никто на них не смотрит. В любой компании вырабатывается определенный стиль работы с ошибками. Вам нужно изучить его и соответствовать ему.
Научитесь общаться — онлайн и на совещаниях. Иногда нам кажется, что онлайн можно себе позволить какой-то другой стиль общения — не надо так делать. Научитесь быть максимально полезным на совещаниях, направляйте совещания в конструктивное русло.
Следующий очень важный скилл — научиться быстро делать пилотную версию. Когда мы беремся за разработку, в нас иногда срабатывает перфекционист: «Лучше потрачу побольше времени, но сделаю все классно». На самом деле важно сделать пилот как можно быстрее, пусть даже с костылями, потом их можно всегда переделать. Но вы потратите много времени на создание пилота, а потом окажется, что он не нужен — будет очень обидно.
Изучайте не новые языки программирования, а инфраструктуру, связанную с вашей работой. Я не призываю вас становиться системными администраторами, но вы можете стать сисадмином хотя бы localhost’а — это откроет вам массу возможностей.
Если вы работаете с базой данных, то здесь есть очень много направлений, — узнайте, как она работает, как ее настраивать, прочитайте руководство для системного администратора. Любое такое погружение даст вам понимание того, как устроена база данных, как ее готовить.
И, наконец, самое важное: где бы и на каком бы девайсе ваша программа ни работала, проблемы с производительностью будут всегда. Желательно уметь разобраться, что влияет на производительность и как можно ускорить работу приложения.
Новые технологии
Мы хотим их изучать, это наша потребность, мы хотим внедрять их в наши продукты. Но одно дело — когда мы делаем приложение для себя, другое — когда мы предлагаем какие-то новые технологии в коллективе. Очень многие конфликты возникают именно из-за того, что мы понадеялись на использование какой-то технологии, а нам по каким-то причинам не разрешили ее внедрять, поэтому требуется что-то переписать, что-то переделать. Так вот чтобы избежать подобных конфликтов, рекомендую просто посмотреть на новую технологию с такой стороны: любое изменение имеет определенную стоимость и определенные риски — так устроена жизнь. При замене одной технологии на другую или при выборе одной технологии из нескольких тоже есть риск. Эти риски очень простые: возросшая сложность, закрытость или открытость технологии со всеми вытекающими последствиями вроде обучения, стоимости поддержки, наличия и полноты документации.
Также есть понятие качества. Технология может быть очень классной, но может сильно зависеть от сопровождения. Если это один человек, то все зависит от его личностных качеств. Например, насколько быстро он будет реагировать на сообщения о багах. Даже такие вещи нужно учитывать при выборе технологии. Наконец, важное значение имеют разные зависимости, когда одна технология зависит от наличия или работоспособности другой технологии или продукта. Чем сложнее система, тем больше выше вероятность сбоев. Чем больше зависимостей, тем хуже.
Теперь финансовый вопрос: есть стоимость перехода и стоимость поддержки. Вы писали на одном языке, предлагаете перейти на другой. Как правило, язык просто так не сменить, есть некая машина, она куда-то встроена. И тот продукт или сервис, куда она встроена, может хорошо работать для одного сообщества просто потому, что оно больше. Или из-за того, что его в продакшене вкривь и вкось использовали много больших компаний, и все выявленные баги уже исправлены. В сфере server side поддержка — почти половина той работы, которую выполняет большая организация. Поэтому стоимость поддержки важна не меньше, чем стоимость разработки.
Если вы предлагаете какую-то новую технологию, то вам нужно заручиться поддержкой достаточного числа коллег. В больших компаниях есть правило: «Мы разрабатываем на разных языках, но в стандартный набор попадают лишь те языки, на которых разрабатывает не менее определенного количества человек». Почему ставится такое ограничение? Часто бывает так, что какой-то сотрудник инициирует миграцию на другой язык, начинает всех перетаскивать, а посреди разработки вдруг теряет интерес и уходит. Проект оказывается в совершенно разваленном состоянии, потому что главный энтузиаст ушел, а другие программисты этим языком владеют еще плохо.
Есть такое понятие, как «технический долг». Если вы ориентированы на максимально быстрый выпуск продукта, то у вас растет технический долг. Очень важно понимать: если вы выбираете решение между костыльным, правильным и хорошим, то костыльное решение увеличит технический долг. В этом случае поместите задачу в backlog. Когда вы будете посвободнее в плане фич, достаньте ее, сделайте рефакторинг. Если же с самого начала пытаться сделать все хорошо и правильно, то, возможно, ваш продукт будет уже никому не нужен к моменту завершения.
Что читать
Рекомендую читать, в первую очередь, блоги программистов и разработчиков. И как можно быстрее выходить на людей, которые могут стать для вас наставниками. Пока у вас есть возможность и желание читать — читайте больше. Потом жизнь сложится так, что, скорее всего, у вас не будет оставаться ни времени, ни желания. Поэтому чем больше прочитаете сейчас, тем лучше. Что касается книг, то их великое множество (1, 2, 3, 4). Сейчас навскидку могу выделить пять книг:
- «Введение в теорию баз данных». Автор — Дейт. Очень многие программисты работают с SQL, но при этом не знают какие-то фундаментальные вещи.
- «Практика программирования». Авторы — Пайк и Керниган. Там много примеров на C, но она достаточно простая. И если у вас не было курса computer science, то эта книжка поможет заполнить пробелы. Очень хорошая и очень простая книга.
- «Мифический человеко-месяц». Очень хорошая книжка. Она устарела, на самом деле, но, тем не менее, очень многие вещи и по сей день актуальны.
- «От хорошего к великому». Автор — Коллинз. Книга про то, что такое хорошие компании, что такое великие компании, чем они отличаются. Очень интересное и субъективное видение, основанное на непротиворечивой интерпретации реальных экспериментальных данных.
- «Дзен и искусство ухода за мотоциклом». Книга вообще не про IT, не про программирование, но про отношение к технике. История человека, который совершает путешествие на мотоцикле, сам его ремонтирует и очень много пишет о том, как он это делает, как перебирает, что важно в уходе за мотоциклом. Все те ценности, которые человек скрупулезно выписывает, можно перенести на любую технику, и на отношение к софту, и на роль системного администратора, и на роль QA.
Желаю всем студентам так построить свою будущую работу, чтобы вам было максимально комфортно, и чтобы вы эффективно и быстро влились в реальные процессы на вашем будущем месте работы.