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

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

Но откуда студенты получают те самые практические навыки, спросите вы? Ответ кроется в наших разработчиках, которые на совершенно добровольных началах выступают в роли консультантов, делают code review для ребят и просто делятся своим опытом. Причём участвуют в этой деятельности исключительно senior девелоперы. Вот с ними-то (спустя уже 3 выпуска из академии) мы и решили побеседовать, чтобы узнать:

• Зачем они тратят своё ценное время на студентов?
• Каково это — быть ментором новичка?
• Как/зачем/почему жить с legacy-кодом?
• Чего не хватает современному образованию?
• Зачем люди идут в разработку коробочных продуктов?

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

Действующие лица:

Александр Баранов — Руководитель разработки решения Veeam Backup & Replication.
Артём Григорьев — Experienced Developer.
Дмитрий Бабушкин — Senior Developer.
Кирилл Лукьянов — Руководитель отдела разработки по направлению Hyper-V, Project leader по-простому.
Филипп Гузеев — Experienced Developer.

Как родилась идея Veeam Academy?

Александр — Идея была совместная. В ходе многочисленных собеседований возникло понимание, чего же не хватает кандидатам. К нам приходит много джунов (junior developer). Как правило, это люди, недавно закончившие институт, с опытом работы около 1 года или вовсе без него. Как правило, им не хватает практики. Значит, надо что-то сделать, чтобы этот дефицит если и не ликвидировать полностью, то хотя бы устранить основные пробелы. Мы стали думать, как уместить наш имеющийся опыт в сжатые двух- или трёхмесячные курсы — это и стало началом.

Курсы по алгоритмам и структурам данных, которые должны читаться на математических факультетах, сами по себе неплохие. Проблема в том, что зачастую они идут в отрыве от практического применения в разработке, поэтому усваиваются не очень хорошо. Мы же пытаемся немного структурировать эти знания и дать пощупать на практике, как оно работает. Причём не просто “как работает технология”, а как работает процесс в целом: как работает команда, как распределяются задачи, как синхронизировать участников команды и т.д.

Как ты попал в Академию?

Артём — Предложили поучаствовать в Академии как ревьюеру, я подумал: “Почему нет?”, заодно освежу свои знания и получу опыт выступлений. Это был мой первый опыт чуть ли не с университета, так что я очень волновался.

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

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

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

Чем ты занимался в Академии?

Дмитрий — Готовил вопросы для онлайн-тестирования, занимался отбором и собеседованием студентов, а также выступал ментором для части студентов.

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

Филипп — В Академии я был и есть в качестве ментора — человека, который ревьюит код студентов и направляет их на путь истинный, давая всякие советы.

Не жалеешь о затраченном времени?

Дмитрий — Нет, конечно. Я помог взять на работу трёх талантливых ребят, пусть даже и в соседние отделы, но в конечном итоге у нас одна большая команда, семья, если хотите. Чем больше людей в соседнем отделе, тем меньше они будут скидывать на нас свои задачи =)

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

Почему ты стал ментором?

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

Филипп — Ничего не происходит просто так. Например, люди в Академию приходят не просто так, а, например, чтобы занять потом какое-то место в команде. А роль менторства в том числе — подобрать в команду валидного человека.

Чего не хватает современным студентам?

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

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

Но, я думаю, это — следствие отсутствия практики. Теории вокруг достаточно, но в университетах, как правило, дают это очень однобоко. Например, в C# берут task, async вызовы, и разбирают их. Это механизм удобный, но не позволяет заглянуть под капот. Студент сам должен пойти и начать разбираться, но почти никто так не делает. Любознательность — штука хорошая, но зачастую на неё банально не хватает времени.

Чего такого интересного в ревью студенческого кода?

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

Студенты писали на седьмом шарпе, в семнадцатой студии, соответственно, были какие-то моменты, с которыми я ещё не сталкивался на практике. Например async/await.

Ревью кода — это, скажем так, практика написания хорошего кода. Ты, когда пишешь сам, непроизвольно думаешь: “Ну тут можно подзабить, тут получше, тут похуже, тут потом переделаю и т.д.”. А когда ты смотришь чужой код, у тебя нет ограничения, что тебе надо починить 10 багов до обеда. И ты можешь спокойно вникнуть, где плохо, где можно сделать получше, а где совсем переделать. Это помогает взглянуть на процесс написания кода со стороны, и в будущем проще решать проблемы а-ля как сделать схему вызовов, ответственность классов и т.д.

Что ты ждёшь от студента на собеседовании?

Дмитрий — Хочу увидеть его подход. Приходят люди, говорят, что читали, например, Рихтера. Я Рихтера не читал, но, когда начинаешь с ними говорить, становится очевидно, что они нашли там ответ на какой-то свой вопрос и всё — т.е. они его не читали [вдумчиво]. Книжку-то они пролистали, но им не интересно то, о чём он пишет, не интересно, как устроен .Net Framework внутри. Это допустимый подход, если ты уже состоявшийся специалист. Но если ты увидел C# на первом курсе и начал отмахиваться от каких-то деталей реализации, от того, как всё устроено под капотом, это гарантия того, что ты начнёшь наступать на грабли. А если к этому моменту ты попадёшь в командный проект, это неизбежно скажется на твоём результате. Тебя все будут ругать, у тебя упадёт мотивация и встанет вопрос о дальнейшей работе.

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

Сложно научить писать код “правильно и как нам надо”?

Филипп — Тут нельзя сказать “ты делаешь правильно — или неправильно”. Нет такого понятия. Ты делаешь поддерживаемый код либо ты делаешь неподдерживаемый код. Допустим, у тебя задача за 5 часов на хакатоне набросать какой-то проект. И, естественно, ты не будешь думать о какой-то красоте архитектуры и красоте кода. “Наляпаешь”, чтобы работало — и это правильно. С другой стороны, если ты работаешь в энтерпрайзе [крупной компании — ред.], то у тебя есть выделенное время на задачи и определённые требования к коду, и это то, к чему мы стремимся и что мы ищем.

Александр — Тут две ситуации. Если человек уже занимался чем-то подобным в другой продуктовой компании, то вольётся он относительно легко. Рынок стандартизирует процессы.
Другое дело, когда уже есть опыт, но ты занимался несколько другим вещами. Тут встаёт вопрос “Как ты хочешь дальше развиваться?” Если твоя цель — это работа в крупной компании, переезд в другую страну, то придётся перетерпеть период ломки. Это как личный автомобиль после общественного транспорта (или наоборот): сначала больно и грустно, но потом становится очень комфортно и удобно.

Дмитрий — На самом деле, если у человека минимальный уровень скилла, “ломать” его не приходится. А вот когда приходят опытные программисты, у них уже есть свой набор практик, свой code style, который может расходиться с нашим — и начинаются разговоры “А почему вы запрещаете использовать мне var’ы? У меня же такой хороший код, ни одного типа не видно, и всё как должно быть в функциональном программировании”. Вот с такими людьми уже сложней.
А если это студент, пусть даже последнего курса, с десятком проектов на гитхабе — он просто не успел ещё приобрести каких-то порочных практик. Ну, а работать с совсем “чистыми” людьми — сплошное удовольствие.

Студенты могут приятно удивлять?

Артём — Скажем так, иногда бывали ситуации, что открываешь код, а там везде конструкции, которые ты ни разу ещё не видел. Приходилось вместе с ними садиться, и разбираться, как их правильно использовать. Бывало, что я и сам не с первого раза понимал правильно.

Veeam Academy была полезна лично для тебя?

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

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

Узнаёшь в том числе много нового и о себе, а это самое главное.

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

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

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

Enterprise разработка — это всегда про legacy?

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

Другой вопрос, как разные компании могут к этому подходить.

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

Постепенно код омолаживается, но это всё в руках разработчика. Можно забить болт, решить текущую проблему и, возможно, для компании этого будет достаточно, т.к. конечная цель в виде работающего продукта будет достигнута. Ну, а что внутри… Есть куча историй в интернете, особенно про зарю геймдева, там когда только классы в С++ появились… код открываешь — там классы, в каждом куча инклудов. Понятно, что сейчас бы это назвали вполне конкретным словом.

Но в целом, с легаси кодом надо уметь жить. Его не надо бояться.

Дмитрий — Legacy код, естественно, присутствует и, естественно, с ним надо как-то жить. Но живёшь с ним не от безысходности, а потому что его нет смысла трогать. Чаще всего legacy код — это какие-то уже отлаженные компоненты, пусть даже написанные на каком-то там .Net 2.0 Они работают годами, нет никакого нового функционала, который надо в них вносить — и зачем их трогать, если они работают и работают нормально?

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

А что касается Академии — этот проект в том числе позволяет нам идти в ногу со временем. Приходят новые ребята, они активно следят за новинками мира C#, .Net и т.д. Им нравятся какие-то новые конструкции, “синтаксический сахар” из последних версий. И, фактически, через своих тимлидов они форсят [продвигают] эти конструкции в проект. Да, это может вызвать сопротивление, люди могут не принять это сразу, но это всё временно и, если в новом фреймворке пришла действительно полезная фича, она войдёт в процесс.

Филипп — Приходится иметь дело с тем, что написано 10 лет назад. От этого никуда не уйдёшь. Естественно, мы стремимся обновлять свой стек, но у нас в разработке 180 проектов, несколько миллионов строк кода было написано за это время, и очень сложно просто взять и перепрыгнуть это. Надо понимать и как-то принять это.

Александр — Как-то читал презентацию Mercedes Benz о том, почему они такие консервативные и внедряют технологии с определённым лагом. Ответ простой: всё, что не идёт на пользу клиенту, идёт “в ведро”. Enterprise-разработка идёт по тому-же принципу. Первыми “жертвами” новой технологии должны быть аналитики, разработчики, тестовая лаба или кто угодно, но не клиент. Любая технология перед тем, как появиться в продукте, должна быть обкатана. Снаружи это выглядит как legacy, но изнутри это не так. Просто всё современное мы должны сначала протестировать “на кошечках” и только потом применить в жизни.

Артём — И да, и нет. Нашему продукту 10 лет, поэтому legacy у нас много, но это не значит, что мы слепо тащим старые компоненты и ничего с ними не делаем. Бывает, что и полностью переписываем.

Тогда как проходит внедрение новых фич?

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

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

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

Как быть с пылкостью джунов и их стремлением всё улучшить?

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

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

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

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

Как джуниору быть с легаси?

Филипп — Во-первых, нельзя говорить, что эти вещи прям совсем устарели. Есть всякие прям “ноу-хау”, ок, мы работаем во многом без них. Но в любом случае человек у нас научится правильному подходу к организации кода и проектированию. Это никуда не денется.
Работать с legacy мы тоже научим. Это тоже очень важный скилл. Нельзя думать, что ты придёшь и начнёшь проектировать лучшую систему на свете. Нет. Чаще всего, приходя в enterprise, ты попадаешь на готовый продукт. Ты будешь или его вести [работать с имеющимся кодом — ред.], или заниматься разработкой [новых компонентов — ред.].

Дмитрий — А его туда никто и не пустит. У разработчиков всегда есть огромный backlog [перечень задач, в том числе отложенных — ред.], аналитики постоянно накидывают новые фичи, и юным дарованиям лучше писать новый код. Естественно, его придётся как-то интегрировать со старым кодом, но это настолько тонкая прослойка в работе, что она не успеет вызвать какое-то отвращение.

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

Так, может, лучше начать в стартапе?

Александр — Enterprise-решения рассчитаны на долгую эксплуатацию на предприятиях, где работают тысячи человек. Это значит, что приложение должно быть надёжным, соответствовать текущим тенденциям и быть совместимо с присутствующими на рынке архитектурами, вплоть до масштабов стран. Разработка коробочного софта в той или иной степени позволяет ознакомиться со всеми этими технологиями и понять, что такое “архитектурно хорошо”, а что такое “неплохо”. Делается это на основе опыта компаний, работающих в enterprise[-секторе]. Чтобы войти в этот сектор, компании требуется немалое время, чтобы доказать миру, что она делает продукты, соответствующие этим требованиям. Например, Veeam шел к этому примерно 5 лет, от SMB [small & medium businesses — ред.] до Enterprise. Приходя в enterprise[-разработку], ты можешь быть уверен, что идёшь в организацию, которая доказала рынку свою адекватность. А значит, она использует адекватные технологии, адекватные методы и стандарты качества.

Поэтому выбрать очень просто. Как правило, успешные стартапы делают выходцы из enterprise. Тут есть такая особенность: выступая гарантом качества и стабильности, enterprise “поворотлив”, как баржа. А рынок движется несколько быстрее, и когда между ними возникает лаг, эту нишу заполняют стартапы. И появляются они не на голом месте, а исходя из опыта бывших сотрудников этого самого enterprise, которые смогли увидеть эту нишу. Отсюда моя рекомендация: хотя-бы 5 лет поработать в крупной (лучше международной) организации, набраться опыта и знаний, а уже после понять, как развиваться дальше. Или идти в стартап продвигать новые идеи и технологии, или оставаться растить карьеру.

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

Кирилл — Здесь от человека зависит. Есть такие люди, которым нравится всё самое новое взять, сложить из кирпичиков какое-то решение, которое устроит и его, и заказчика.
Продуктовая компания [т.е. разрабатывающая собственный продукт — ред.] на входе будет выглядеть как стартап. Человек не знает проблемную область, и для него всё новое.

Какие плюсы у продуктовых компаний? Обычно они достаточно большие, у них есть продукты, приносящие стабильный доход. Вот, вероятно, стабильная зарплата — хороший признак. Второй момент: в продуктовых компаниях люди дольше работают на одном проекте, и у них образуется более глубокая экспертиза в этой области. Здесь плюсом выступает общение с опытными коллегами.

Есть такое мнение, что надо раз в 2-3 года менять работу. Да, в рамках работы над одной фичой за это время ты изучишь её досконально. Но, например у нас в Veeam, даже в рамках одной команды очень большой стек технологий, и если устал работать над чем-то одним, всегда можно переключиться на что-то другое. Есть практика перехода в другую команду — т.е. сотрудник будет оставаться в компании, но у него будут меняться задачи, чтобы не наступило выгорание и мы не теряли ценные кадры.

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

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

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

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

Есть ли жизнь после enterprise?

Кирилл — В продуктовых компаниях медленно всё меняется, это правда. Но, привыкнув к такому, можно сказать, “тяжелому научному проектированию”, ты так и продолжишь писать.

Артём — Жизнь есть. Я какие-то маленькие проекты разрабатываю чисто для себя и могу применить какие-то подходы из больших продуктов. Какие-то мне кажутся слишком громоздкими, и приходится писать “велосипеды”. Это от человека зависит. Если он просто ходит на работу писать код 8 часов, и вне этого программирование его не интересует, то ему всё это экспериментаторство и не нужно. А если человек энтузиаст, никаких проблем у него не возникнет.

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

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

Кому точно не надо идти в разработку коробочного софта?

Артём — Точно не надо идти тем, кто любит переписать половину продукта в середине цикла разработки. У нас развитие происходит постепенно, эволюционно. А если хочется всегда пробовать что-то новое, то такие люди нужны, но в очень ограниченном количестве.

Просто надо согласовывать свои желания с тем, что требуется общему делу. Есть у тебя идея — это замечательно, но ты не знаешь картину в целом. Для начала надо обсудить её с коллегами, с аналитиками, понять, какие будут плюсы от внедрения. Если плюсы окажутся достаточными, тебе всегда разрешат начать внедрение. А если ты просто придумал что-то, что отложит релиз на полгода, конечно, никто тебе не даст всё бросить и начать “пилить” [писать код — ред.]. В конце концов, клиенты платят деньги за работающий продукт, а не за эксперименты разработчиков. Так что оценке своих действий тоже надо учиться.

Табы или пробелы?

Артём — Конечно, пробелы. С ними удобнее.

Дмитрий — Безусловно, табы, которые конвертируются в пробелы.

Александр — Четыре пробела. Исторически табуляция в разных редакторах показывалась по-разному, и текст может поплыть. Лет 15 назад в каком-то гайде прям увидел совет, что, мол, поменяйте настройки Студии [Microsoft Visual Studio — ред.], чтобы вместо табов ставилось четыре пробела, ну и как-то отложилось в голове с тех пор.

Филипп — Табы, конечно.

Кирилл — Холивар, да, но я предпочитаю пробелы. Я отношу себя не только к высокоуровневым разработчикам, и когда пишешь низкоуровневый код, часто не ставишь себе всякие Студии, а пишешь банально в блокноте. И когда тут табуляции, а там пробелы, то начинаются всякие косяки с выравниванием кода, ну и зачем это надо.

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