Получи случайную криптовалюту за регистрацию!

#люди В очередной раз прочитав очередной пост на Хабре про о | Человек и машина

#люди

В очередной раз прочитав очередной пост на Хабре про очередное (неудачное?) собеседование в очередную Большую Техническую Компанию, а также комментарии к ней, где люди в очередной раз заявляют о преимуществе простого и понятного кода со сложностью O(n^2) над сложным кодом со сложностью O(logn), я думаю пора поговорить о такой важной в нашей индустрии теме как дальновидность.

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

Как вы догадались, эти две ипостаси на работе друг с другом не пересекаются. И слава Богу.

Режим “…, …, и в продакшон” - это этакий кризисный режим работы в условиях цейтнот: катиться надо сейчас, времени думать нет, time to market, impact assessment, blast radius, workaround, и много других прикольных словообразований. А все потому что тут принимается решение: сделать плохо, но запуститься, либо сделать хорошо, но никогда. И бизнес (собственно ваш - вы же мамкин предприниматель) не готов ждать.

И никогда не будет, так уж он устроен. Другое дело, когда вы оказываетесь погруженным в масштаб… Нет, не так.

В МАСШТАБ.

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

Как сказал мой шеф: “Мы проектируем крышу без дома. В нашей профессии так можно, если мы все правильно предусмотрим.”

Поэтому прежде чем я напишу свои злополучные 5-10 строчек кода, я проведу пару часов на разных звонках и телемостах, чтобы каждый был доволен.

Мне с ними еще интегрироваться потом.

Причем здесь сложность алгоритма? Ну вот пример: вы, внезапно - фронтендер. Запуск вашей компании планируется в понедельник, сейчас пятница, бекендеры не успевают выкатить для вас GraphQL, который эффективно и дешево выдаст нужные данные. У вас два пути - отложить релиз, или воспользоваться уже legacy REST, выкидывая с десяток запросов с клиента при загрузке страницы.

Очевидно, вы пойдете на тот самый архитектурный tradeoff и пожертвуете производительностью продукта в угоду time to market. Заводите себе задачу на рефакторинг, планируете к ней вернуться, когда завезут GraphQL Спойлер - вы скорее уволитесь, чем отрефакторите, но это неважно, потому что когда это станет проблемой (если когда-то и станет), ваша голова будет болеть совсем о другом.

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

Да и алгоритмические интервью для того и нужны. Сначала пишете быстро, но плохо. Затем, собираете волю в кулак и пишете сложно, но эффективно. Сигналы получены, интервьюер счастлив, до скорых встреч.