Вы приступаете к чтению статьи с высокой концентрацией советов. Учиться у предшественников – хороший способ добиться успеха, но здесь мы часто забываем о важной оговорке. Практически любой совет работает только в определенном контексте, но дается обычно без каких-либо указаний на него.
«Да просто повысьте цены!» — говорит компания, которая уже двадцать лет на рынке и первые годы продавала продукт за копейки, чтобы привлечь клиентов и прийти к успеху. «Нужно всё реализовать в микросервисах», — говорит компания, которая по-быстрому сколотила монолит, набрала несколько тысяч пользователей и метнулась к микросервисам, когда начались проблемы с масштабированием.
Без понимания контекста советы теряют смысл или, хуже того, приносят вред. Если бы люди из примеров выше последовали своим собственным советам в начале пути, то, вероятно, пожалели бы этом. Этой ловушки сложно избежать. Мы представляем собой кульминацию своего опыта, но при этом смотрим на него через призму настоящего.
Так что дам вам немного контекста, который породил мои советы. Первую половину своей карьеры я провел в роли программиста, работающего на различные небольшие компании и стартапы, затем ушел в консалтинг и работал на несколько очень крупных организаций. Потом создал компанию Simple Thread, которая выросла с двух сотрудников до двадцати пяти. Десять лет назад мы работали в основном с малым и средним бизнесом, сейчас среди наших клиентов есть представители и малого, и крупного бизнеса.
Советы я даю с позиции человека, который:
Приобретенный за последние двадцать лет опыт сформировал мои взгляды на разработку и привел меня к некоторым выводам – я попытался скомпоновать их в удобоваримый список, в котором вы, надеюсь, найдете что-то ценное для себя.
Перейдем к списку.
«В смысле ты не знаешь, что такое BGP?», «Ты что, никогда не слышал о Rust?». Едва ли не каждому доводилось выслушивать такие вопросы, пожалуй, даже слишком часто. Многие из нас любят разработку ПО именно по той причине, что мы готовы учиться всю жизнь, а в этой сфере куда ни посмотри, везде простирается панорама знаний, и ее границы расширяются с каждым днём. Из этого следует, что можно провести целые десятилетия за работой в некоторой области, и у тебя всё равно обнаружатся существенные расхождения в знаниях с человеком, который десятилетиями занимался примерно тем же самым. Чем быстрее вы придете к этой мысли, тем скорее сумеете выбраться из синдрома самозванца и начнете находить радость в самообразовании и обучении других.
Знаю, сейчас это уже звучит как банальность, но большинство разработчиков не соглашается с такими заявлениями из-за того, что те, как им кажется, обесценивают их усилия. Как по мне, ничего подобного. Напротив, они подчеркивают, в какой сложной, не поддающейся законам рациональности среде нам приходится работать и как это усложняет наши задачи. Можно спроектировать самый технически продвинутый продукт на свете и не найти ни одного желающего его использовать. Подобное случается часто. Проектирование по большей части завязано на том, чтобы слушать других, и зачастую нам приходится быть программистом, медиумом и антропологом одновременно. Вложения в процесс проектирования (будь это создание особой команды по UX или просто отработка собственных навыков) окупаются с лихвой. Ведь, если вы возьмете в работу не тот продукт, какой следовало, как вообще рассчитать издержки? Это обойдется гораздо дороже впустую потраченных часов программирования.
Хорошие разработчики ПО глубоко продумывают тот пользовательский опыт, который формирует их код. Возможно, они описывают это в иных выражениях, но о чем бы ни шла речь – о внешнем API, программном API, пользовательском интерфейсе, протоколе, о любом интерфейсе вообще – хорошие разработчики прикидывают, кто будет им пользоваться, в каких целях, как именно и что будет иметь наибольшее значение для этих людей. В основе качественного пользовательского опыта лежит именно внимание к потребностям.
Что тут скажешь, программистам без кода никуда. Попросите человека любой профессии решить какую-нибудь проблему, и он отдаст предпочтение тому способу, на котором собаку съел. Это в человеческой природе. Большинство программистов всегда будут склоняться к тому, чтобы писать код, особенно если менее техническое решение не очевидно. То же относится и к коду, не требующему поддержки. Технические команды имеют склонность изобретать велосипед, даже когда вокруг уже целая куча этих велосипедов. Тут нужно выдерживать баланс – есть много доводов в пользу доморощенных инструментов, но остерегайтесь нездорового синдрома «это не здесь придумано».
Основная задача любого программиста – создавать ценность. Понимают это очень немногие, а по-настоящему проникаются идеей и вовсе единицы. Если проникнуться по-настоящему, это приведет к тому, что вы иначе будете подходить к решению проблем и иначе воспринимать свои инструменты. Если вы искренне убеждены, что продукт должен служить предполагаемому исходу, то будете действительно готовы искать «нужный инструмент для конкретной задачи». В некоторых случаях это вообще не ПО.
Есть люди, которые ныряют в проблему с головой и немедленно начинают строчить код. Есть и такие, которых тянет до бесконечности собирать информацию и впадать в аналитический паралич. Если вы из последних, поставьте себе дедлайн, и, когда он наступит, принимайтесь за проработку решений. За этим занятием вы быстро получите дополнительную информацию, что поможет в итерировании наилучшего решения.
С этим моментом мне приходится непросто теперь, когда новые обязанности уводят меня дальше и дальше от повседневных обязанностей разработчика. Держать руку на пульсе экосистемы инструментов для разработчиков – это огромный объем работы, но иначе нельзя прийти к пониманию, каков спектр возможностей. Если вы не понимаете, что в рамках некоторой экосистемы возможно и что доступно, то обнаружите, что не способны вывести разумное решение для какой бы то ни было проблемы, кроме самых примитивных. Если вкратце: остерегайтесь людей, которые уже давно не писали код, но при этом проектируют системы.
У Бьёрна Страуструпа есть такая цитата:
Это верно и применительно к любой крупной системе. Нет никакой «правильной» архитектуры, вы никогда полностью не рассчитаетесь по техническому долгу, не спроектируете идеальный интерфейс, тесты всегда будут не поспевать. Это не повод никогда не пытаться ничего улучшить, это моя попытка дать вам другой угол обзора. Не зацикливайтесь на элегантности и безукоризненности, лучше стремитесь к непрерывному улучшению и к созданию жизнеспособной системы, с которой команде приятно работать и которая стабильно что-то дает людям.
Никогда не упускайте возможность поставить под вопрос допущения и подходы из разряда «мы так всегда делали». К вам присоединился новый сотрудник? Внимательно отслеживайте, что приводит его в недоумение и какие вопросы он задает. Поступил невразумительный запрос на новую функциональность? Убедитесь, что понимаете ее назначение и то, откуда берется такое желание. Если внятного ответа нет, продолжайте задавать вопросы, пока не разберетесь.
10x-программисты – это дурацкий миф. Сама идея, что кто-то способен за день выдать то, на что у умелого, трудолюбивого работника со схожим опытом займет две недели – чистая глупость. Видал я программистов, которые выдают тебе в десять раз больше кода, чем прочие – потом за ними приходится в десять раз дольше править. 10x-программистом можно стать только в том случае, если тебя сравнивают с 0.1x-программистами. То есть с теми, кто просиживает без дела, не интересуется обратной связью, не проводит тесты, не учитывает крайние случаи… И то, что в команду может затесаться такой вот 0.1x-программист, должно занимать нас гораздо сильнее, чем поиски мифического 10x-программиста.
Мало что беспокоит меня так, как сениор, у которого нет собственного мнения об инструментах, с которыми он работает, или подхода к разработке. Уж лучше пусть изложит взгляды, которые я буду яростно оспаривать, чем покажет полное их отсутствие. Если вы пользуетесь инструментами и не испытываете к ним целого диапазона добрых и недобрых чувств, значит, вам недостает опыта. Вам нужно изучать другие языки, библиотеки, парадигмы. Один из самых скоростных способов подтянуть навыки – активно выяснять, как ваши задачи выполняются другим набором техник и инструментов.
Поговорить об инновациях люди очень любят, но на деле обычно хотят, чтоб дешево и сердито плюс с элементом новизны. Если вы выдаете что-то по-настоящему инновационное, что изменит весь порядок их действий, будьте готовы к преимущественно негативной обратной связи. Если же у вас есть вера в продукт и убеждение, что он изменит ситуацию к лучшему, настраивайтесь на длительную схватку.
Я повидал много систем, где основным механизмом защиты целостности данных была надежда на лучшее. В подобных системах любое отклонение с прямого пути приводит к расщеплению или загрязнению данных. В будущем работа с такими данными может обернуться сущим кошмаром. Не забывайте: ваши данные с большой долей вероятности переживут кодовую базу. Не жалейте сил на то, чтобы держать их в порядке и чистоте, это окупится в долгосрочной перспективе.
Старые технологии, которые не теряют актуальности до сих пор – это не динозавры, а акулы. Они так эффективны в решении проблем, что смогли уцелеть перед лицом резких изменений, которые то и дело происходят в мире технологий. Не выступайте против этих технологий и заменяйте их только если на то есть очень веские причины. Такие инструменты не отличаются броскостью и не вызывают энтузиазма, но успешно справляются со своей задачей и берегут вас от бессонных ночей.
На свете есть множество программистов, которые не станут высказываться, пока их не спросят. Никогда не предполагайте, что человеку, который не суёт своё мнение вам под нос, нечего добавить к обсуждению. Нередко бывает так, что именно тех, кто громче всего кричит, меньше всего стоит слушать. Разговаривайте с окружающими, просите у них совета и обратной связи. Вы об этом не пожалеете.
Программистам нужно на регулярной основе вести блог или ежедневник, работать над документацией – в общем, заниматься чем-то, что будет оттачивать их навыки письменной речи. Письменное изложение помогает нам обдумывать проблемы и учит правильно доносить свои мысли до команды и даже до самого себя в будущем. Хорошая письменная речь – один из ключевых навыков, которые должен освоить любой разработчик.
В наши дни все стремятся перейти на Agile, но по сути, это ведь сводится к тому, чтобы делать работу небольшими порциями, выносить уроки и итерировать. Если кто-то пытается напихать в эту концепцию еще кучу всего дополнительного, то, скорее всего, хочет денег. Я не говорю, что людям не нужна подотчетность и помощь, чтобы перейти на такую схему работы, но часто ли вы слышите, как сотрудники вашей любимой технологической компании или крупного проекта с открытым кодом хвалятся своим замечательным Scrum-процессом? Внедряйте процессы по минимуму, пока не убедитесь, что нужно добавить еще что-то. Доверяйте своей команде, и она вас не подведет.
Если человек никак не соприкасается с результатом своей работы, он начнет испытывать к ней меньше интереса. По-моему, это почти тавтология. Именно по этой причине кроссфункциональные команды так хорошо себя показывают, а DevOps получил такую популярность. Дело тут не только в передачах и неэффективных практиках, ключевым является то, что одни и те же работники ведут процесс от начала до конца и полностью отвечают за выдачу ценности. Дайте группе увлеченных людей полный контроль над проектированием, разработкой и выпуском программного продукта (да и вообще чего угодно), и результаты будут потрясающими.
Собеседования гораздо продуктивнее тратить на то, чтобы понять, что за человек перед вами и есть ли у него интерес к определенной области знания. Пытаться разведать, как он покажет себя в командной работе – бессмысленное занятие. И, уж поверьте мне, ум и эрудиция не дают никаких гарантий, что перед вами хороший командный игрок. Никто не станет сообщать вам на собеседовании, что намерен быть безответственным, жестоким, напыщенным или вечным опоздуном на всех собраниях. Некоторые утверждают, что, мол, «считывают сигналы». «Если он спрашивает об отгулах на первом собеседовании, значит, на работе вообще появляться не будет!» Но это всё чушь собачья. С такими сигналами вы просто гадаете на кофейной гуще и отказываете хорошим специалистам.
С самого начала множество сил может толкать вас к тому, чтобы сделать систему масштабнее. Распределение бюджета, неспособность решить, что из функциональности урезать, желание выстроить систему «в наилучшем виде». Всё это оказывает на нас сильное давление, заставляя раздувать систему. Этому следует сопротивляться. В процессе создания системы вы узнаете столько нового, что в итоге итерируете к версии, которая будет гораздо лучше любой из тех, что вы могли бы спроектировать изначально. Почему-то многих очень сложно убедить в верности этого тезиса.
habr.com
«Да просто повысьте цены!» — говорит компания, которая уже двадцать лет на рынке и первые годы продавала продукт за копейки, чтобы привлечь клиентов и прийти к успеху. «Нужно всё реализовать в микросервисах», — говорит компания, которая по-быстрому сколотила монолит, набрала несколько тысяч пользователей и метнулась к микросервисам, когда начались проблемы с масштабированием.
Без понимания контекста советы теряют смысл или, хуже того, приносят вред. Если бы люди из примеров выше последовали своим собственным советам в начале пути, то, вероятно, пожалели бы этом. Этой ловушки сложно избежать. Мы представляем собой кульминацию своего опыта, но при этом смотрим на него через призму настоящего.
Так что дам вам немного контекста, который породил мои советы. Первую половину своей карьеры я провел в роли программиста, работающего на различные небольшие компании и стартапы, затем ушел в консалтинг и работал на несколько очень крупных организаций. Потом создал компанию Simple Thread, которая выросла с двух сотрудников до двадцати пяти. Десять лет назад мы работали в основном с малым и средним бизнесом, сейчас среди наших клиентов есть представители и малого, и крупного бизнеса.
Советы я даю с позиции человека, который:
- почти всегда работал в составе маленьких, компактных команд с ограниченными ресурсами;
- ценит рабочие продукты выше, чем конкретные инструменты;
- постоянно начинает новые проекты, но при этом поддерживает несколько старых систем;
- ставит продуктивную работу программистов выше многих других соображений.
Приобретенный за последние двадцать лет опыт сформировал мои взгляды на разработку и привел меня к некоторым выводам – я попытался скомпоновать их в удобоваримый список, в котором вы, надеюсь, найдете что-то ценное для себя.
Перейдем к списку.
1. Я до сих пор многого не знаю
«В смысле ты не знаешь, что такое BGP?», «Ты что, никогда не слышал о Rust?». Едва ли не каждому доводилось выслушивать такие вопросы, пожалуй, даже слишком часто. Многие из нас любят разработку ПО именно по той причине, что мы готовы учиться всю жизнь, а в этой сфере куда ни посмотри, везде простирается панорама знаний, и ее границы расширяются с каждым днём. Из этого следует, что можно провести целые десятилетия за работой в некоторой области, и у тебя всё равно обнаружатся существенные расхождения в знаниях с человеком, который десятилетиями занимался примерно тем же самым. Чем быстрее вы придете к этой мысли, тем скорее сумеете выбраться из синдрома самозванца и начнете находить радость в самообразовании и обучении других.
2. Самое сложное в разработке – разрабатывать именно то, что требуется
Знаю, сейчас это уже звучит как банальность, но большинство разработчиков не соглашается с такими заявлениями из-за того, что те, как им кажется, обесценивают их усилия. Как по мне, ничего подобного. Напротив, они подчеркивают, в какой сложной, не поддающейся законам рациональности среде нам приходится работать и как это усложняет наши задачи. Можно спроектировать самый технически продвинутый продукт на свете и не найти ни одного желающего его использовать. Подобное случается часто. Проектирование по большей части завязано на том, чтобы слушать других, и зачастую нам приходится быть программистом, медиумом и антропологом одновременно. Вложения в процесс проектирования (будь это создание особой команды по UX или просто отработка собственных навыков) окупаются с лихвой. Ведь, если вы возьмете в работу не тот продукт, какой следовало, как вообще рассчитать издержки? Это обойдется гораздо дороже впустую потраченных часов программирования.
3. Лучшие программисты мыслят как проектировщики
Хорошие разработчики ПО глубоко продумывают тот пользовательский опыт, который формирует их код. Возможно, они описывают это в иных выражениях, но о чем бы ни шла речь – о внешнем API, программном API, пользовательском интерфейсе, протоколе, о любом интерфейсе вообще – хорошие разработчики прикидывают, кто будет им пользоваться, в каких целях, как именно и что будет иметь наибольшее значение для этих людей. В основе качественного пользовательского опыта лежит именно внимание к потребностям.
4. Лучший код – это отсутствие кода или хотя бы необходимости его поддерживать
Что тут скажешь, программистам без кода никуда. Попросите человека любой профессии решить какую-нибудь проблему, и он отдаст предпочтение тому способу, на котором собаку съел. Это в человеческой природе. Большинство программистов всегда будут склоняться к тому, чтобы писать код, особенно если менее техническое решение не очевидно. То же относится и к коду, не требующему поддержки. Технические команды имеют склонность изобретать велосипед, даже когда вокруг уже целая куча этих велосипедов. Тут нужно выдерживать баланс – есть много доводов в пользу доморощенных инструментов, но остерегайтесь нездорового синдрома «это не здесь придумано».
5. ПО – это не конечная цель, а способ ее достижения
Основная задача любого программиста – создавать ценность. Понимают это очень немногие, а по-настоящему проникаются идеей и вовсе единицы. Если проникнуться по-настоящему, это приведет к тому, что вы иначе будете подходить к решению проблем и иначе воспринимать свои инструменты. Если вы искренне убеждены, что продукт должен служить предполагаемому исходу, то будете действительно готовы искать «нужный инструмент для конкретной задачи». В некоторых случаях это вообще не ПО.
6. Иногда нужно прекратить затачивать косу и уже покосить что-нибудь
Есть люди, которые ныряют в проблему с головой и немедленно начинают строчить код. Есть и такие, которых тянет до бесконечности собирать информацию и впадать в аналитический паралич. Если вы из последних, поставьте себе дедлайн, и, когда он наступит, принимайтесь за проработку решений. За этим занятием вы быстро получите дополнительную информацию, что поможет в итерировании наилучшего решения.
7. Если у вас нет ясного представления о возможностях, вы не сможете толково спроектировать систему
С этим моментом мне приходится непросто теперь, когда новые обязанности уводят меня дальше и дальше от повседневных обязанностей разработчика. Держать руку на пульсе экосистемы инструментов для разработчиков – это огромный объем работы, но иначе нельзя прийти к пониманию, каков спектр возможностей. Если вы не понимаете, что в рамках некоторой экосистемы возможно и что доступно, то обнаружите, что не способны вывести разумное решение для какой бы то ни было проблемы, кроме самых примитивных. Если вкратце: остерегайтесь людей, которые уже давно не писали код, но при этом проектируют системы.
8. В конечном счете, любая система – отстой, смиритесь
У Бьёрна Страуструпа есть такая цитата:
Это верно и применительно к любой крупной системе. Нет никакой «правильной» архитектуры, вы никогда полностью не рассчитаетесь по техническому долгу, не спроектируете идеальный интерфейс, тесты всегда будут не поспевать. Это не повод никогда не пытаться ничего улучшить, это моя попытка дать вам другой угол обзора. Не зацикливайтесь на элегантности и безукоризненности, лучше стремитесь к непрерывному улучшению и к созданию жизнеспособной системы, с которой команде приятно работать и которая стабильно что-то дает людям.
9. Вопрос «почему?» всегда звучит слишком редко
Никогда не упускайте возможность поставить под вопрос допущения и подходы из разряда «мы так всегда делали». К вам присоединился новый сотрудник? Внимательно отслеживайте, что приводит его в недоумение и какие вопросы он задает. Поступил невразумительный запрос на новую функциональность? Убедитесь, что понимаете ее назначение и то, откуда берется такое желание. Если внятного ответа нет, продолжайте задавать вопросы, пока не разберетесь.
10. Нам нужно меньше искать 10x-программистов и больше избегать 0.1x-программистов
10x-программисты – это дурацкий миф. Сама идея, что кто-то способен за день выдать то, на что у умелого, трудолюбивого работника со схожим опытом займет две недели – чистая глупость. Видал я программистов, которые выдают тебе в десять раз больше кода, чем прочие – потом за ними приходится в десять раз дольше править. 10x-программистом можно стать только в том случае, если тебя сравнивают с 0.1x-программистами. То есть с теми, кто просиживает без дела, не интересуется обратной связью, не проводит тесты, не учитывает крайние случаи… И то, что в команду может затесаться такой вот 0.1x-программист, должно занимать нас гораздо сильнее, чем поиски мифического 10x-программиста.
11. Одно из ключевых различий между джуниором и сениором – сложившиеся мнения о том, как должно быть
Мало что беспокоит меня так, как сениор, у которого нет собственного мнения об инструментах, с которыми он работает, или подхода к разработке. Уж лучше пусть изложит взгляды, которые я буду яростно оспаривать, чем покажет полное их отсутствие. Если вы пользуетесь инструментами и не испытываете к ним целого диапазона добрых и недобрых чувств, значит, вам недостает опыта. Вам нужно изучать другие языки, библиотеки, парадигмы. Один из самых скоростных способов подтянуть навыки – активно выяснять, как ваши задачи выполняются другим набором техник и инструментов.
12. Люди на самом деле не хотят инноваций
Поговорить об инновациях люди очень любят, но на деле обычно хотят, чтоб дешево и сердито плюс с элементом новизны. Если вы выдаете что-то по-настоящему инновационное, что изменит весь порядок их действий, будьте готовы к преимущественно негативной обратной связи. Если же у вас есть вера в продукт и убеждение, что он изменит ситуацию к лучшему, настраивайтесь на длительную схватку.
13. Данные – самая важная часть вашей системы
Я повидал много систем, где основным механизмом защиты целостности данных была надежда на лучшее. В подобных системах любое отклонение с прямого пути приводит к расщеплению или загрязнению данных. В будущем работа с такими данными может обернуться сущим кошмаром. Не забывайте: ваши данные с большой долей вероятности переживут кодовую базу. Не жалейте сил на то, чтобы держать их в порядке и чистоте, это окупится в долгосрочной перспективе.
14. Ищите технологических акул
Старые технологии, которые не теряют актуальности до сих пор – это не динозавры, а акулы. Они так эффективны в решении проблем, что смогли уцелеть перед лицом резких изменений, которые то и дело происходят в мире технологий. Не выступайте против этих технологий и заменяйте их только если на то есть очень веские причины. Такие инструменты не отличаются броскостью и не вызывают энтузиазма, но успешно справляются со своей задачей и берегут вас от бессонных ночей.
15. Не путайте скромность с невежеством
На свете есть множество программистов, которые не станут высказываться, пока их не спросят. Никогда не предполагайте, что человеку, который не суёт своё мнение вам под нос, нечего добавить к обсуждению. Нередко бывает так, что именно тех, кто громче всего кричит, меньше всего стоит слушать. Разговаривайте с окружающими, просите у них совета и обратной связи. Вы об этом не пожалеете.
16. Программистам следует регулярно писать
Программистам нужно на регулярной основе вести блог или ежедневник, работать над документацией – в общем, заниматься чем-то, что будет оттачивать их навыки письменной речи. Письменное изложение помогает нам обдумывать проблемы и учит правильно доносить свои мысли до команды и даже до самого себя в будущем. Хорошая письменная речь – один из ключевых навыков, которые должен освоить любой разработчик.
17. Соблюдайте минимализм в процессах
В наши дни все стремятся перейти на Agile, но по сути, это ведь сводится к тому, чтобы делать работу небольшими порциями, выносить уроки и итерировать. Если кто-то пытается напихать в эту концепцию еще кучу всего дополнительного, то, скорее всего, хочет денег. Я не говорю, что людям не нужна подотчетность и помощь, чтобы перейти на такую схему работы, но часто ли вы слышите, как сотрудники вашей любимой технологической компании или крупного проекта с открытым кодом хвалятся своим замечательным Scrum-процессом? Внедряйте процессы по минимуму, пока не убедитесь, что нужно добавить еще что-то. Доверяйте своей команде, и она вас не подведет.
18. Программистам, как и всем людям, нужно ощущать причастность
Если человек никак не соприкасается с результатом своей работы, он начнет испытывать к ней меньше интереса. По-моему, это почти тавтология. Именно по этой причине кроссфункциональные команды так хорошо себя показывают, а DevOps получил такую популярность. Дело тут не только в передачах и неэффективных практиках, ключевым является то, что одни и те же работники ведут процесс от начала до конца и полностью отвечают за выдачу ценности. Дайте группе увлеченных людей полный контроль над проектированием, разработкой и выпуском программного продукта (да и вообще чего угодно), и результаты будут потрясающими.
19. Собеседования почти ничего не говорят о том, каким членом команды будет кандидат
Собеседования гораздо продуктивнее тратить на то, чтобы понять, что за человек перед вами и есть ли у него интерес к определенной области знания. Пытаться разведать, как он покажет себя в командной работе – бессмысленное занятие. И, уж поверьте мне, ум и эрудиция не дают никаких гарантий, что перед вами хороший командный игрок. Никто не станет сообщать вам на собеседовании, что намерен быть безответственным, жестоким, напыщенным или вечным опоздуном на всех собраниях. Некоторые утверждают, что, мол, «считывают сигналы». «Если он спрашивает об отгулах на первом собеседовании, значит, на работе вообще появляться не будет!» Но это всё чушь собачья. С такими сигналами вы просто гадаете на кофейной гуще и отказываете хорошим специалистам.
20. Всегда старайтесь сделать систему покомпактнее
С самого начала множество сил может толкать вас к тому, чтобы сделать систему масштабнее. Распределение бюджета, неспособность решить, что из функциональности урезать, желание выстроить систему «в наилучшем виде». Всё это оказывает на нас сильное давление, заставляя раздувать систему. Этому следует сопротивляться. В процессе создания системы вы узнаете столько нового, что в итоге итерируете к версии, которая будет гораздо лучше любой из тех, что вы могли бы спроектировать изначально. Почему-то многих очень сложно убедить в верности этого тезиса.
20 уроков, которые я вынес из 20 лет работы программистом
Вы приступаете к чтению статьи с высокой концентрацией советов. Учиться у предшественников – хороший способ добиться успеха, но здесь мы часто забываем о важной оговорке. Практически любой совет...
habr.com