Нет. Вот есть сервис. Его считали "маленьким и неважным". Допустим, он получал прогноз погоды(придумайте другой пример, это неважно), чтобы показать его в кабинете клиента. Вот вы сделали компонент и забыли. И все работало 2 года. Документацию вы решили не писать, тестами решили не покрывать, да и вообще на все забили, сделали "чтобы работало". И вот сейчас оно сломалось. Отсутствие тестов и документации определенно стало техническим долгом, который теперь имеет свое воплощение во времени работы программистов и деньгах компании.
Технический долг это про "снизить стоимость сейчас" и "заплатить потом". Это он и есть.
По той же причине, почему в каждом макдональдсе должны быть одинаковые граммовки, форма и бизнес-процессы. Это называется стандарты. Когда любая группа людей вырастает до определенного масштаба стандарты просто необходимы. Типичный enterprise-проект - банковская система. Ядро написано на Java в 2004 году. Какие-то части переписали на новые версии языка, какие-то нет, сама система обросла дополнительными сервисами на PHP, потом появились сервисы на NodeJS, появились консумеры АПИ, находящиеся вне компании. Система становится все сложнее и сложнее и вот ее поддерживает уже 400 программистов. Если в таких системах начинаешь отходить от стандартов хоть на шаг, то все неизбежно и очень быстро приходит в хаос. Сегодня вам всем дружно очевидно "что и как делает эта штука", а через 5 лет команда сменилась целиком уже несколько раз. А документации нет. А ведь было очевидно. И вот вы тратите кучу времени и денег просто чтобы понять что это вообще такое. Да и каждый член команды тот же час начнет трактовать почти все случаи как "это не супер важно" или "это же очевидно", "да я тут только одну строчку поменял, ревью можно не делать". Единственное исключение - когда вы пишите стандарт на то, в каких случаях можно и нужно отходить от стандартов. И то каждый будет интерпретировать все по-своему. Это обычная проблема в любых проектах на которых работает много людей, не только программирование. Одно дело построить дачу и совершенно другое строить Бурдж-Халифа. Да, иногда при причесывании всех под одну гребенку бывает так, что самым умным приходится отрезать голову, но в случае с кровавым enterprise важнее скорее стабильное качество и прогнозируемость релизов, нежели некая нерегулярная краткосрочная "скорость" за счет технического долга.
Не могу говорить о тех местах, где вы работаете, но почти везде где работал я - существовал процесс постановки и обсуждения задач, смысл которого для разработчика и заключается в том, чтобы узнать все, что необходимо о задаче. Чем выше уровень разработчика, тем важнее для него вопрос: "Зачем эта задача бизнесу". Я, как тимлид и технический директор нередко сталкивался с тем, что более простое и дешевое решение задачи лежит вообще не в плоскости разработки. В современных командах вопросы "зачем", "что", "почему" и "как" решаются, как правило между продакт-менеджером и руководителем разработки. Это что касается небольших команд. Что касается enterprise-разработки, я надеюсь, не нужно объяснять, почему Code-Review должно проходить каждый раз, почему нужно докапываться до мелочей и вкусовщины, почему нужно документировать даже очевидные узлы и так далее.
Так-то оно так, но в целом советы в духе: "Хорошо быть богатым и здоровым, а быть бедным и больным - плохо". Проблемы возникают не потому, что программистам и менеджерам только дай волю лишнюю работу поделать. Нет, проблема в том, что чаще всего определить что является важным, а что нет крайне сложно. А еще бывает так, что сегодня что-то важно, а уже завтра нет и наоборот.
Ну вот это утверждение, на котором строится вся статья - явно очень спорное. Кому нужен код, который не работает? Кому нужен код, который легко изменять, но не решает свои задачи? Зачем нужно изменять код, который хорошо решает свою задачу? Из неверного посыла сформирована статья.
Вообще посыл о том, что программист это человек, который пишет код, а программирование === написание кода - очень вредно и для вас и для читателя. Это приведет вас в карьерный тупик. Программист должен решать задачи бизнеса, используя для этого, в том числе, разработку ПО. Задача программиста - не КОД. Задача программиста - решение бизнес-задачи. Иногда решение заключается в том, чтобы НЕ ПИСАТЬ КОД вообще.
Хорошо, что написали статью. Полностью согласен. Имею опыт и в крупных компаниях с десятками команд и в быстрорастущих стартапах и в совсем молодых. Польностью согласен с мыслями. Сколько стрел и мечей уже было сломано в спорах с бизнесом и коллегами на эту тему.... Про DDD, конечно, жирненько получилось, если не читать комментарии, можно и не понять мысль
Я много нанимал людей и устраивался на работу сам. В целом со статьей согласен, но на всякий случай продублирую, что все сильно зависит от размера компании. Одно дело, когда тебе надо закрыть 2-3-10 позиций и лид может поговорить с каждым кандидатом "по душам" и другое дело, когда тебе надо закрыть 100 позиций и у тебя тысячи кандидатов. Для меня вопросы на собеседовании являются лакмусовой бумажкой того, какая команда сидит на той стороне, что за компания и какой там менеджмент. Особенно устраиваясь на более менеджерские позиции это становится критически важно. Если меня с более чем 10 летним подтвержденным бэкграундом на позицию CTO просят разливать воду по ведрам неподходящего размера, или объяснять отличия абстрактного класса от интерфейса, мы скорее всего заведомо не подходим друг другу.
Тоже так думал до тех пор пока не оказался в страшной ситуации микроменджмента со стороны некомпетентного руководителя, который к тому же брал на себя непосредственно технические решения(в которых он тоже не понимал) и не прислушивался к тому, что я говорил, что так делать нельзя, не надо и это приведет к еще большим проблемам. И вот, ты уже по 4 часа в день сидишь с ним в зуме, делаешь какую-то лютую дичь. И платят тебе чуть больше, чем на прошлом месте, вот только эмоциональных ресурсов это жрет в 100 раз больше. Протянул 2 года, но когда все-таки ушел - огромная гора свалилась с моих плеч.
Какой неправильный по итогу совет вы сочинили) Правильный был бы: "Могу порекомендовать поискать друзей, которые уже работают программистами и попросить их дать начальству рекомендацию взять вас на работу". И это действительно нормальный рабочий совет)
Все идет так. Нужно понимать, что джуновских резюме сотни тысяч. На одну вакансию откликаются сотни. Чтобы тебя позвали, твое резюме должно быть чуть лучше, чем у других.
Разве другие этапы интервью не показывают ли владение человека каким-либо языком программирования? Ну типа live coding какой-нибудь, или тестовое задание. Да и вообще странно, человек идет в MAANG и не может показать публичный код, который он написал? Такое бывает? Я не то что в MAANG не работал, я даже в Яндекс и Тинькофф ни разу не собеседоваля, но могу столько кода на своем гитхабе показать - учитаешься.
Сами по себе, в отрыве от их маркетинга и продаж курсы не вредны. Но и сильно полезными я бы их тоже не называл) Польза есть, но в пересчете на единицу вложенных денег и потраченного времени она существенно ниже банального чтения книг.
Если вы не доходите до этапа собеседования, значит ваша основная проблема кроется в том, как составлено ваше резюме. Возможно, вам стоит обратиться за консультацией к HR-специалисту и проработать с ним резюме. 40 лет не приговор. Как и 50 и даже 60. Хотя, бесспорно, все становится намнооого сложнее
Тоже никогда не понимал этого устремления работать в Яндекс и Тинькофф... Часто говорят что это "хорошая строчка в резюме", но мне с моими 10 годами опыта хоть убей не ясно, чем же эта строчка в резюме хороша.
Если есть три джуна, один с дипломом МГУ, я даже смотреть внутрь резюме остальных не стану.
Ой, опасная у вас позиция. Я чаще нанимаю людей вообще без профильного образования, но с большим желанием и стремлением. И несколько раз мне "сверху" подсовывали джунов из МФТИ, МГУ и Бауманки. И только один раз это был успешный опыт.
Мне почему-то казалось, что в алгоритмическом интервью на обратной стороне провода должен быть тоже какой-то разработчик. И в моем понимании любой разработчик способен понять псевдокод. Также мне казалось, что помимо компилируется\не компилируется и проходит ли оно тест-кейсы на таких интервью в основном смотрят на "ход мысли" кандидата.
Как минимум - умение и желаение шлепать формы. Вот я когда искал первую работу - пришел на собеседование и рассказал: "Вот смотрите, я сделал вот этот сайтец для эммигрантов из Чехии сам. А вот я в свободное время делаю браузерную игру! Смотрите какие здесь кнопочки! А вот я сделал форму через которую записывал домашние задания в универе, глядите, здесь валидация работает через AJAX, а сервер сделан на PHP". И почему-то не испытал вообще никакой проблемы в поиске первой работы. Ни диплома, ни курсов никаких не оканчивал.
У вас странное представление об обучении, вузах, курсах и IT в целом. Меня выгнали со второго курса универа и я просто пошел на стажировку программистом(потому что хотел стать программистом). За месяц досрочно закончил стажировку и стал джуном. Через 6 месяцев устроился в другую компанию на middle позицию. Через полтора года получал по верхней планке вилки разработчиков. В чем посыл? 1) Работодателю ПО БАРАБАНУ какой ВУЗ и какие курсы вы закончили. Даже если он пишет, что ему важно, чтобы у вас был Master Degree in CS. Просто поверьте, бизнесу насрать, какой у вас degree. Ему важно сколько денег вы ему принесете, что умеете и как уживетесь с коллективом. 2) Если ты хочешь работать программистом - нет никакого смысла идти работать тестировщиком или в службу поддержки. Это просто разные специальности. И там и там есть свой вертикальный рост. Но суть работы вот прям вообще не похожа. После того, как меня отчислили из института я сразу пошел работать программистом. А мой однокурсник продолжал учиться, закончил, не смог найти работу программистом и устроился тестировщиком. 3 года проработал тестировщиком и только спустя 3 года понял, что для того, чтобы работать программистом нужно программировать. Просто потерял 3 года и после озарения освежил знания и пошел по стандартному пути: стажировка -> джун.
Отсюда и советы:
1) Литкод нафиг никому не упал. Начни программировать. Работаешь на складе? Ну напиши программу, которая облегчит учет товаров. Не хочешь помогать складу? Сделай для себя проект. А потом еще один. Отложи пару раз деньги с обеда и купи себе дешевый VPS на котором попробуешь этот проект запустить. Общайся в интернете с программистами, спрашивай вопросы, отвечай на вопросы других. 2) Найди стажировку. Да, денег платят мало, или вообще не платят. Но смысл в приобретении опыта. Без опыта найти работу сложно. И это очень легко объяснить с позиции работодателя. И касается это вовсе не только IT. У юристов\экономистов и бухгалтеров все тоже самое.
Нет. Вот есть сервис. Его считали "маленьким и неважным". Допустим, он получал прогноз погоды(придумайте другой пример, это неважно), чтобы показать его в кабинете клиента. Вот вы сделали компонент и забыли. И все работало 2 года. Документацию вы решили не писать, тестами решили не покрывать, да и вообще на все забили, сделали "чтобы работало".
И вот сейчас оно сломалось.
Отсутствие тестов и документации определенно стало техническим долгом, который теперь имеет свое воплощение во времени работы программистов и деньгах компании.
Технический долг это про "снизить стоимость сейчас" и "заплатить потом". Это он и есть.
По той же причине, почему в каждом макдональдсе должны быть одинаковые граммовки, форма и бизнес-процессы. Это называется стандарты. Когда любая группа людей вырастает до определенного масштаба стандарты просто необходимы. Типичный enterprise-проект - банковская система. Ядро написано на Java в 2004 году. Какие-то части переписали на новые версии языка, какие-то нет, сама система обросла дополнительными сервисами на PHP, потом появились сервисы на NodeJS, появились консумеры АПИ, находящиеся вне компании. Система становится все сложнее и сложнее и вот ее поддерживает уже 400 программистов. Если в таких системах начинаешь отходить от стандартов хоть на шаг, то все неизбежно и очень быстро приходит в хаос. Сегодня вам всем дружно очевидно "что и как делает эта штука", а через 5 лет команда сменилась целиком уже несколько раз. А документации нет. А ведь было очевидно. И вот вы тратите кучу времени и денег просто чтобы понять что это вообще такое. Да и каждый член команды тот же час начнет трактовать почти все случаи как "это не супер важно" или "это же очевидно", "да я тут только одну строчку поменял, ревью можно не делать". Единственное исключение - когда вы пишите стандарт на то, в каких случаях можно и нужно отходить от стандартов. И то каждый будет интерпретировать все по-своему.
Это обычная проблема в любых проектах на которых работает много людей, не только программирование. Одно дело построить дачу и совершенно другое строить Бурдж-Халифа.
Да, иногда при причесывании всех под одну гребенку бывает так, что самым умным приходится отрезать голову, но в случае с кровавым enterprise важнее скорее стабильное качество и прогнозируемость релизов, нежели некая нерегулярная краткосрочная "скорость" за счет технического долга.
Не могу говорить о тех местах, где вы работаете, но почти везде где работал я - существовал процесс постановки и обсуждения задач, смысл которого для разработчика и заключается в том, чтобы узнать все, что необходимо о задаче. Чем выше уровень разработчика, тем важнее для него вопрос: "Зачем эта задача бизнесу". Я, как тимлид и технический директор нередко сталкивался с тем, что более простое и дешевое решение задачи лежит вообще не в плоскости разработки.
В современных командах вопросы "зачем", "что", "почему" и "как" решаются, как правило между продакт-менеджером и руководителем разработки. Это что касается небольших команд.
Что касается enterprise-разработки, я надеюсь, не нужно объяснять, почему Code-Review должно проходить каждый раз, почему нужно докапываться до мелочей и вкусовщины, почему нужно документировать даже очевидные узлы и так далее.
Так-то оно так, но в целом советы в духе: "Хорошо быть богатым и здоровым, а быть бедным и больным - плохо".
Проблемы возникают не потому, что программистам и менеджерам только дай волю лишнюю работу поделать. Нет, проблема в том, что чаще всего определить что является важным, а что нет крайне сложно. А еще бывает так, что сегодня что-то важно, а уже завтра нет и наоборот.
Ну вот это утверждение, на котором строится вся статья - явно очень спорное. Кому нужен код, который не работает? Кому нужен код, который легко изменять, но не решает свои задачи? Зачем нужно изменять код, который хорошо решает свою задачу? Из неверного посыла сформирована статья.
Вообще посыл о том, что программист это человек, который пишет код, а программирование === написание кода - очень вредно и для вас и для читателя. Это приведет вас в карьерный тупик. Программист должен решать задачи бизнеса, используя для этого, в том числе, разработку ПО. Задача программиста - не КОД. Задача программиста - решение бизнес-задачи. Иногда решение заключается в том, чтобы НЕ ПИСАТЬ КОД вообще.
Я так понял, в 2008
Хорошо, что написали статью. Полностью согласен. Имею опыт и в крупных компаниях с десятками команд и в быстрорастущих стартапах и в совсем молодых. Польностью согласен с мыслями. Сколько стрел и мечей уже было сломано в спорах с бизнесом и коллегами на эту тему.... Про DDD, конечно, жирненько получилось, если не читать комментарии, можно и не понять мысль
Я много нанимал людей и устраивался на работу сам. В целом со статьей согласен, но на всякий случай продублирую, что все сильно зависит от размера компании. Одно дело, когда тебе надо закрыть 2-3-10 позиций и лид может поговорить с каждым кандидатом "по душам" и другое дело, когда тебе надо закрыть 100 позиций и у тебя тысячи кандидатов.
Для меня вопросы на собеседовании являются лакмусовой бумажкой того, какая команда сидит на той стороне, что за компания и какой там менеджмент. Особенно устраиваясь на более менеджерские позиции это становится критически важно.
Если меня с более чем 10 летним подтвержденным бэкграундом на позицию CTO просят разливать воду по ведрам неподходящего размера, или объяснять отличия абстрактного класса от интерфейса, мы скорее всего заведомо не подходим друг другу.
Тоже так думал до тех пор пока не оказался в страшной ситуации микроменджмента со стороны некомпетентного руководителя, который к тому же брал на себя непосредственно технические решения(в которых он тоже не понимал) и не прислушивался к тому, что я говорил, что так делать нельзя, не надо и это приведет к еще большим проблемам.
И вот, ты уже по 4 часа в день сидишь с ним в зуме, делаешь какую-то лютую дичь. И платят тебе чуть больше, чем на прошлом месте, вот только эмоциональных ресурсов это жрет в 100 раз больше. Протянул 2 года, но когда все-таки ушел - огромная гора свалилась с моих плеч.
Какой неправильный по итогу совет вы сочинили) Правильный был бы: "Могу порекомендовать поискать друзей, которые уже работают программистами и попросить их дать начальству рекомендацию взять вас на работу". И это действительно нормальный рабочий совет)
Все идет так. Нужно понимать, что джуновских резюме сотни тысяч. На одну вакансию откликаются сотни. Чтобы тебя позвали, твое резюме должно быть чуть лучше, чем у других.
Разве другие этапы интервью не показывают ли владение человека каким-либо языком программирования? Ну типа live coding какой-нибудь, или тестовое задание. Да и вообще странно, человек идет в MAANG и не может показать публичный код, который он написал? Такое бывает? Я не то что в MAANG не работал, я даже в Яндекс и Тинькофф ни разу не собеседоваля, но могу столько кода на своем гитхабе показать - учитаешься.
Сами по себе, в отрыве от их маркетинга и продаж курсы не вредны. Но и сильно полезными я бы их тоже не называл) Польза есть, но в пересчете на единицу вложенных денег и потраченного времени она существенно ниже банального чтения книг.
Если вы не доходите до этапа собеседования, значит ваша основная проблема кроется в том, как составлено ваше резюме. Возможно, вам стоит обратиться за консультацией к HR-специалисту и проработать с ним резюме. 40 лет не приговор. Как и 50 и даже 60. Хотя, бесспорно, все становится намнооого сложнее
От математике никуда не укрыться) И всегда можно было формально "зазубрить", а хотелось именно понять и не обманывать ни себя ни преподавателей
Тоже никогда не понимал этого устремления работать в Яндекс и Тинькофф... Часто говорят что это "хорошая строчка в резюме", но мне с моими 10 годами опыта хоть убей не ясно, чем же эта строчка в резюме хороша.
Ой, опасная у вас позиция. Я чаще нанимаю людей вообще без профильного образования, но с большим желанием и стремлением. И несколько раз мне "сверху" подсовывали джунов из МФТИ, МГУ и Бауманки. И только один раз это был успешный опыт.
Мне почему-то казалось, что в алгоритмическом интервью на обратной стороне провода должен быть тоже какой-то разработчик. И в моем понимании любой разработчик способен понять псевдокод. Также мне казалось, что помимо компилируется\не компилируется и проходит ли оно тест-кейсы на таких интервью в основном смотрят на "ход мысли" кандидата.
Как минимум - умение и желаение шлепать формы. Вот я когда искал первую работу - пришел на собеседование и рассказал: "Вот смотрите, я сделал вот этот сайтец для эммигрантов из Чехии сам. А вот я в свободное время делаю браузерную игру! Смотрите какие здесь кнопочки! А вот я сделал форму через которую записывал домашние задания в универе, глядите, здесь валидация работает через AJAX, а сервер сделан на PHP". И почему-то не испытал вообще никакой проблемы в поиске первой работы. Ни диплома, ни курсов никаких не оканчивал.
У вас странное представление об обучении, вузах, курсах и IT в целом. Меня выгнали со второго курса универа и я просто пошел на стажировку программистом(потому что хотел стать программистом). За месяц досрочно закончил стажировку и стал джуном. Через 6 месяцев устроился в другую компанию на middle позицию. Через полтора года получал по верхней планке вилки разработчиков.
В чем посыл?
1) Работодателю ПО БАРАБАНУ какой ВУЗ и какие курсы вы закончили. Даже если он пишет, что ему важно, чтобы у вас был Master Degree in CS. Просто поверьте, бизнесу насрать, какой у вас degree. Ему важно сколько денег вы ему принесете, что умеете и как уживетесь с коллективом.
2) Если ты хочешь работать программистом - нет никакого смысла идти работать тестировщиком или в службу поддержки. Это просто разные специальности. И там и там есть свой вертикальный рост. Но суть работы вот прям вообще не похожа. После того, как меня отчислили из института я сразу пошел работать программистом. А мой однокурсник продолжал учиться, закончил, не смог найти работу программистом и устроился тестировщиком. 3 года проработал тестировщиком и только спустя 3 года понял, что для того, чтобы работать программистом нужно программировать. Просто потерял 3 года и после озарения освежил знания и пошел по стандартному пути: стажировка -> джун.
Отсюда и советы:
1) Литкод нафиг никому не упал. Начни программировать. Работаешь на складе? Ну напиши программу, которая облегчит учет товаров. Не хочешь помогать складу? Сделай для себя проект. А потом еще один. Отложи пару раз деньги с обеда и купи себе дешевый VPS на котором попробуешь этот проект запустить. Общайся в интернете с программистами, спрашивай вопросы, отвечай на вопросы других.
2) Найди стажировку. Да, денег платят мало, или вообще не платят. Но смысл в приобретении опыта. Без опыта найти работу сложно. И это очень легко объяснить с позиции работодателя. И касается это вовсе не только IT. У юристов\экономистов и бухгалтеров все тоже самое.