Я, в отличии от него, лычек сеньора не ношу, и стаж разработки у меня на пару лет поменьше, да и профильного образования, у меня, если честно, нет. Но вот проблем у меня с базовым интересом к работе не было, и мне кажется — причина в несколько ином восприятии реальности.
Статья для широкого круга читателей.
RE: Чрезмерная сложность
Отдельная тема — это господин Джаваскрипт с его бесчисленными фреймворками. Я честно не понимаю, как можно было изобрести СТОЛЬКО штуковин для инструмента, которому нужно просто нарисовать формочки на веб-страницы и время от времени отправлять запрос на бекенд. Хорошо, что я занимаюсь бэкендом.
На примере фронтенда (да и не только его) хорошо заметно, как мы ходим по кругу: давайте всю логику выполнять на стороне сервера -> а давайте теперь на стороне клиента -> а давайте теперь снова на сервере и так до бесконечности. Давайте фронтенд и бекенд писать на одном языке -> а давайте теперь на разных -> а давайте снова на одном. Давайте сделаем схемы для форматов данных -> схемы только для старпёров -> а не, схемы нужны всё таки. Один мой кореш перепиливает свою опенсорсную библиотеку с yaml на xml, просто потому, что там есть схемы и это очень здорово, когда клепаешь огромный конфиг, а IDE, осведомленная о XSD сама может выполнить за тебя половину работы. Из вышесказанного вытекает следующая проблема
Безусловно, приятно манипулировать простыми системами. Я понимаю ту магию, когда ты понимаешь, как это работает до мельчайших деталей: когда спускаешься на уровень ассемблера и машинного кода, и когда идешь еще глубже — туда, где процессор представляет собой ряды логических вентилей.
Текущая ситуация такова, что мейнстримовые разработки и в ПО и в железе процессоров уже очень далеки от кристального понимания того, как это работает, отдельно взятым человеком: процессоры полны генерированной логики, разноуровневого кеша и предсказателей ветвления настолько, что баги в них не то, что не замечаются, а даже не предполагаются целыми командами разработчиков, и цветут настолько буйным цветом, что прорываются в своих эффектах на уровень пользователя. Кроме того, мы вынуждены тащить за собой огромный багаж старых функций, обеспечивая тем самым обратную совместимость, иначе выиграем в скорости и простоте, но проиграем в работе того, под что это железо изначально разрабатывалось.
С софтом та же ситуация: понимание, и тем более написание ассемблерных инструкций осталось лишь в узко-специализированных областях, а в том, что живет и крутится в непосредственной близости от пользователя, безраздельно царят фреймворки и слои абстракции.
С точки зрения человека, желающего контролировать свой код и машину — это плохо. С точки зрения пользователя — хорошо, так как упрощает понимание, работы и путь от идеи к продукту. Цена, которую платим мы за это желание пользователей — то, что растущие мощности процессоров тут же сжираются сложностью программ, которая, вроде бы, ничем не обоснована, и не несет никаких плюсов (вэээээлью, как говорили на моем предыдущем месте работы).
Однако, если копнуть глубже, окажется, что мы меняем эти ресурсы на увеличение аудитории за счет упрощения взаимодействия. Если раньше терминалы заказа авиабилетов требовали знания сокращений, понимания, как работают авиакомпании и навыка работы с текстовым терминалом, то теперь любой пользователь заходит на условный Aviasales, и подбирает себе дешевый билет по сложному маршруту без особого геморроя.
Нельзя сделать понятный среднему человеку интерфейс на текстовом терминале, потому что понятность интерфейса — это и разрешение монитора, и приятные картинки, которые не пугают мозг, и красивые шрифты, и подсказки, всплывающие при наведении на кнопку, и сенсорный интерфейс.
А еще, возможность тестировать все эти фишки, ориентируясь на поведение пользователя. Работая по waterfall, вы выкатываете релиз раз в год, собирая отзывы на текущую версию весь год. До какой-то стадии интерфейса вы идете десять лет, десять релизов. Выкатывая мелкие исправления и тестируя их тут же, вы придете к той же стадии через год-полтора. Но такая работы требует другого темпа, других инструментов и технологий, и отказа от некоторых вещей. В честности, от вылизывания кода: все должно работать сейчас, потому что того требует процесс такого темпа.
Взамен, эта сумасшедшая гонка за новыми фичами дарит нам растущую пользовательскую базу: чем проще нажимаются кнопки, тем больше людей смогут их нажать, а растущая пользовательская база несет деньги не только в ваши зарплаты, но и в разработку нового железа. Чем больше людей смогут продуктивно пользоваться смартфоном, тем больше его купят, тем лучше будет железо в следующей версии. То, что мы тут же размениваем это железо не на полеты на марс, а на растущую аудиторию… ну, это можно сравнить с компанией, которая вкладывает весь заработок в развитие, а не в дивиденды и прибыль в годовом отчете. Только вот вы почему-то оправдываете, когда так делают Маск и Безос, но не можете оправдать индустрию.
Хорошо это или плохо — можно спорить. С одной стороны качество ПО, с другой — постоянный прогресс в железе, аудитория и большие зарплаты в индустрии. Я, пожалуй, выберу второе (хоть и предпочел бы сбавить темп), но пойму людей, которые выберут первое.
Но объединит нас одно — мы ничего не сможем с этим сделать.
RE: Слишком много всего
Но даже плотная работа с определенным ЯП или, к примеру, СУБД в своей компании иногда не дает возможности оставаться в тренде, т.к. технологии устаревают раньше, чем их успевают применять. Даже джава сейчас релизится со скоростью фаерфокса.
Благодаря бесконечному потоку быстроустаревающих знаний многие из нас чувствуют себя вечными студентами или самозванцами, неважно сколько систем ты реально построил. И это очень на руку HRам и работодателям — ведь легко можно сбить твою ЗП парой заковыристых вопросов. Такой вид крысиных бегов HRы политкорректно называют саморазвитием.
То, что инструментов много — это логическое продолжение предыдущего пункта. Когда в области много энергии, это позволяет тратить лишнюю энергию на тестирование гипотез, часть из которых окажется провальными, часть засохнет, а вот часть ляжет в основу новых стандартов индустрии. Жалобы на хаос подобны жалобам на неэффективность эволюции, которая зачем-то создала кучу видов, огромная часть из которых тихо вымерла, и еще большая часть не очень успешна, и прозябает в узком ареале. Неужели нельзя было сразу создать человека, который может выжить хоть на северном полюсе, хоть в пустыне, несмотря на то, что сам довольно хилый — бегает небыстро, когтей нет, зубы маленькие и тупые, угол обзора небольшой.
На результат эволюции хорошо смотреть со стороны, и удивляться про себя, какой долгий путь потребовался для создания вполне очевидного преимущества — гибких пальцем и развитого мозга.
Но вот в самом начале пути результат был совсем не так однозначен: динозавры-то тоже когда-то царили на земле безраздельно, и живи биржевые аналитики в их времена, мало бы кто поставил на каких-то млекопитающих крысок против этого явного фаворита.
Отходы в виде «неправильных» инструментов — это постоянный спутник того пути, что ведет на вершину.
RE: Программист должен быть бизнес-аналитиком & Собеседования
Собеседования
Это самый важный и горячо любимый мною вид спецдисциплины. Ведь по факту именно от этого зависит будешь ли ты спать на старом продавленном диване в арендованой однушке где-то за МКАДом, или же придется укрываться картонкой лежа на теплотрассе под мостом. Если в начале моей карьеры собеседование было чем-то типа разговора по-душам, то сейчас это больше напоминает экзамен. Возможно это связано с тем, что в те времена не было таких огромных зарплат и толп желающих войти в айти или просто мода, я не знаю. Но факт в том, что придя на собеседование на позицию старшего разраба, с огромной долей вероятности ты столкнешься с задачками, приправлеными вопросами-викториной. “Ну-ка реши на бумажке задачку, которую мы вчера стащили с leetcode. Ошибся на единичку в граничном условии? Фууууу лох! Не знаешь, как работает %methodName% в моднейшем %frameworkName%. Кто его вообще сюда пустил? Охрана!” Никого больше не волнует, что твоя голова устроена по-другому и ты не можешь в стрессе под презрительно-снисходительным взглядом высоколобых ботанов быстро и без ошибок наваять алгоритм под задачу, над которой ты и подумать ещё не успел. Как и то сколько за твоей спиной километров кода и продакшон-систем. Хорошо хоть вопросы-головоломки сдохли, и на том спасибо.
Да нет, не должен конечно. Но в условиях необходимости быстрой проверки гипотез, гораздо продуктивнее это делать в той же голове, которая принимает решения о архитектуре, просто потому что накладных расходов меньше: надо не два дня совещаться, а час подумать. Умеете в предметную область — молодец, спи на продавленном диване. Не умеешь — тебя ждут в тех областях, где надежность важнее прогресса: космос, медицина, военка, системы сигнальной связи. Эти области есть, и они ничуть не менее важны фронтенда. Правда, платят меньше. Такой уж перекос на рынке, который бы и я бы хотел исправить, но это нечто, что выше не только человека, но и большинства компаний.
Кстати, этот же фактор позволяет несколько свысока посматривать на HR с заковыристыми вопросами, вплоть до «не знаю я, чего пристали, давайте уже с техдиром пообщаемся». Не хотите быть аналитиком, а хотите писать код по готовому вылизанному ТЗ? См. выше — другие области для вас: хорошие программисты, не делающие ошибок и качественно и грамотно реализующие ТЗ тоже очень нужны.
RE: Айтишники
Собственно разработчики и сочувствующие. Вопреки стереотипам — в большинстве своём не ортодоксальные ботаны, а вполне себе нормальные ребята. Вот только как правило говорить с ними не о чем. Все разговоры во внерабочее время сводятся к работе. А как иначе, если ты вынужден круглосуточно вызубривать всю эту техномуть? Мой совет — держитесь подальше от ребят в клетчатых рубашках с рюкзаками, иначе можете заработать летальную дозу скуки. Многие из них ходят на работу не работать, а играть в игрушки. Давайте изобретем велосипед, давайте прикрутим новый фреймворк (и будем по ночам разгребать ад на проде) и непременно бросим всё на полпути, потому что эта игрушка надоела, к тому же новые завезли. Зато потом будем дуть щеки и рассказывать на конференциях, как мы победили проблему, которую сами же и создали. PROFIT! Эти люди так же легко ведутся на всякую чушь типа “интересных задач” и “сложных систем” (в айти культ сложных систем, поэтому калькулятор без десятка микросервисов сейчас построить нельзя), что в переводе на человеческий означает ковыряние в прокисшем дерьме мамонта, но за меньшие деньги, тем самым снижая ЗП по отрасли. Как в анекдоте “- Папа, а что мы сегодня будем кушать? — Ничего, сынок, я работаю над интересными задачами в дружном коллективе.”
Проджект-менеджеры. Честно говоря, за 10 лет я так и не понял кто такие проджект-манагеры и зачем они нужны. В совершенно разных конторах это выглядело примерно так: вот там пачка задач, разберитесь чего там и как и вот до такого-то числа сделайте. А я пошел возьму латте у хипстеров на первом этаже и напишу в инстаграме какой сегодня тяжелый день. Только однажды я видал чувака, который строил все эти скучные графики, жонглировал задачами и был нашим помощником, а не просто классным парнем, который не смог в программирование, но айтишную ЗП очень хочется.
Вайтишники. Нежно любимая многими категория. Благодаря их демпингу толковые и идейные джуны не могут въехать в индустрию — в погоне за длинным рублем, многие вкатывальщики готовы работать вообще бесплатно.
Про остальных умолчим.
Скучные разработчики, которые говорят только о работе? Странно, мне кажутся скучными те, кто хочет спокойно пилить код по готовому ТЗ с 9 до 18. Мы оба не правы, но я немного о другом: такая организация ума, при которой задача крутится в голове постоянно, дает весомый буст к скорости разработки и проверки гипотез. Чуть за грань, и там маячит выгорание, но это вопрос контроля ментального здоровья. Что не отменяет того факта, что некоторые компании (не будем показывать пальцем на тех, кто оплачивает сотрудникам такси после 22 часов, стимулируя задерживаться на работе) поняв, что горящий сотрудник работает лучше, предоставляют все условия для этого горения.
Проджекты? Вы просто не умеете их готовить. Проджект — это универсальный инструмент: с одной стороны, он берет на себя волшебные пинки для программистов (программист, предоставленный сам себе, переключается на производство приколюх для себя любимого), а с другой стороны, архитекторы и тимлиды могут сбрасывать на него львиную долю организаторской работы по организации встреч, поддержании актуальности графика, отчетам о проделанной работы, рутинной коммуникации с заказчиком и так далее.
RE: Бизнес
Тем кому важно как — чтобы внутри было всё красиво и правильно.
Тем кому важно что — те люди, которым важна суть продукта, который они делают.
Обычно в разработчике содержатся обе эти категории, просто в разных пропорциях.
Для обоих из них у меня есть печальные новости.
Для первой категории — с точки зрения зарабатывания денег абсолютно неважно насколько правильная архитектура выбрана и насколько красив код. Точно так же как и на всю эту вашу безопасность, лучшие практики, etc. Можно навтыкать костылей, заработать бабок, а дальше тот манагер, который всё это учинил спрыгивает на соседнюю шлюпку “получать новый опыт”, а команда ночами разгребает конюшни.
Для второй категории — 90% из вас делает то, что уже давно сделано другими. За редким исключением, все ваши продукты глубоко вторичны. Но тем не менее, ушлые дельцы пытаются придать “идейность” очередной платежной системе, онлайн-банку и тому подобному. Я сам все это проходил, и надо сказать, гораздо легче работать, когда у тебя есть четкий ответ на вопрос “зачем всё это нужно”. Все эти “менятели” мира почему-то забывают сказать, что изменение мира происходит как побочный результат зарабатывания денег, а не наоборот. Тяжело менять мир, когда к твоему виску приставлено дуло дробовика совета директоров, а на шею накинута удавка акционеров. Как по мне фраза “мы работаем для того, чтобы заработать денег” звучит гораздо честнее. Другое дело, что если сейчас сказать HRу, что ты работаешь на работе за деньги, то 146% получишь в ответ недоуменный взгляд и что-то типа “Вы нам не подходите, нам нужны увлеченные люди, которым важны саморазвитие и интересные задачи”.
Так уж случилось, что человек придумал деньги. Сделали это не в текущем поколении, и даже не сто лет назад. Деньги показали себя отличным инструментов для организации разнородного общества с разными понятиями о прекрасном и разными желаниями входящих в него людей.
Вы можете попробовать изобрести что-то другое, но пока что-то ничего кардинально лучше не придумали. Есть, конечно, мотивация типа социальной поддержки и командного духа, но первая — производная от денег, которые переварило государство, а второе — приправа, а не основное блюдо. В крайнем случае, десерт.
За вашу работу вам платят деньги. Если ваша работа не приносит денег — простите, она не нужна бизнесу. Грубо, знаю. Давайте попробуем мягче.
Бизнесу нужны деньги. Бизнес — это организация, которая зарабатывает деньги. Если вам не дают денег на то, что вы считаете нужным — значит, вы не показали, как эта штука принесет бизнесу еще больше денег. Научитесь обосновывать трату ресурсов, докажите, что это приносит пользу, пусть даже долгосрочную, и ресурсы будут. Бизнес и ЛПР бизнесу в этом плане гораздо адекватнее среднего человека, правда: там где человек будет жаться купить проездной на пол-года за десять тысяч, потому что это так много денег, и предпочтет покупать каждый месяц проездной за две тысячи, бизнеса интересует лишь одна цифра — прибыль на вложенные деньги. 16% прибыли? Берем! Нет денег, но можно взять кредит на эту траты за 5%? Берем!
Если в некой компании не удается обосновать ревью кода, потому что их код живет три месяца, после чего заменяется новым, то бегите оттуда, что вы там делаете? Есть огромное количество компаний, для которых ревью кода и рефакторинг — важные компоненты процесса. А первая компания сосредоточена на проверке гипотез, а не на кодинге: это тоже нормально, и позволяет найти новую нишу, в которой можно вырасти, заматереть, накопить жирок и начать практиковать ревью и рефакторинг.
Не стоит осуждать дизайнера, который строит домик из игрушечных кирпичей, не скрепляя их раствором: жить в этом домике хомячку, и задача этого дома — протестировать гипотезу внешнего вида, а не служить домом. И даже если этот дизайнер готов платить вам за то, что вы помогаете ему строить его игрушечный домик, не брызгайте на него слюной на то, что нужен раствор и котлован, а устройтесь в нормальные строители.
RE: Здоровье
Пожалуй, это единственный пункт, на который мне нечего полноценно ответить. Кроме того, что в моем мире человек обладает волей и разумом, и если считает, что ему не надо поднимать тяжести, то он не будет их поднимать.
Комментарии (46)
bm13kk
06.12.2019 01:12+1Обычно Вас интересно читать.
С одной стороны я понимаю Вашу точку зрения и частично ее разделяю. Есть что есть и оно даже работает.
С другой стороны — программирование это не производство. Как бы не пытались его зделать производством.
Программирование это управление сложностью. И мы продвигаемся в этом направлении. Но ключевая проблема остается без внимания. Количество слоев обстракции растет експоненцияально и у нас нет ничего (ни инструментов, ни методик) чтобы ими управлять. Не отдельно взятыми абстракциями — а всей стопкой.
И рано или поздно эта стопка пройдет какой-то критический размер и сколлапсирует. И нам всем прийдется это разгребать.
ИМХО то что интел не может починить свою безопастность — первые ласточки. По слухам там еще несколько дыр еще не опубликованных. Возможно именно по безопастности и произойдет взрыв. Мы, как программисты, знаем что взломать можно абсолютно все. Но рано или поздно это поймет большинство. А за ними, что хуже, политики. И вот тогда ситуация полностью уйдет из под нашего контроля.
somebody4
06.12.2019 01:19Количество слоев обстракции растет експоненцияально и у нас нет ничего (ни инструментов, ни методик) чтобы ими управлять.
Мне кажется есть — стандартизация. Но пока ещё не наигрались в фиолетовые кнопочки.Мы, как программисты, знаем что взломать можно абсолютно все.
Как хакеры — с натяжкой, как программисты — спорное утверждение. Как программисты — мы знаем что пишем так что можно сломать.И вот тогда ситуация полностью уйдет из под нашего контроля.
Из под какого контроля? Какой у программиста контроль? Контроль писать так что можно сломать?bm13kk
06.12.2019 01:41> Мне кажется есть — стандартизация
она касается только одного слоя абстракциии. В лучшем случае между двумя абстракциями.
> Как хакеры — с натяжкой, как программисты — спорное утверждение
не умеем, а знаем.
> Какой у программиста контроль?
Никакого. А вот у профсоюзов или коммитетов (хз как перевести bar в данном контекста) уже не мало.somebody4
06.12.2019 19:38на касается только одного слоя абстракциии. В лучшем случае между двумя абстракциями.
Вам конечно виднее, но если присмотритесь поближе к инженерным решениям и областям деятельности, сразу увидете причины для этого.
Одни программисты кто в лес, кто по дрова. Это пословица какая-то получаетсяПлохому программисту «абстракции» мешают.
Потому что еще не выросли из детских штанишек. Всё ещё в стадии ремесленников, а не инженеров.
не умеем, а знаем
На ленте.ру прочитали что «взломать можно абсолютно все»? Или «знаем», но «не умеем»? Детский лепет какой-то.
Никакого. А вот у профсоюзов или коммитетов (хз как перевести bar в данном контекста) уже не мало.
Вы профсоюзный деятель? Вы писали «ситуация полностью уйдет из под нашего контроля». Тогда «вашего» правильно получается.
Программист состоящий в профсоюзе — сейчас это нонсенс. Только если работает в компании в которой есть общий профсоюзный договор. Профессиям с более-менее высокими интелектуальными требованиями и высоким входным порогом, нету экономических причин для создания профсоюзов. Это не про программистов, а вообще обо всех. Не то что я против профсоюзов, но такова реальность.bm13kk
09.12.2019 12:35> Вам конечно виднее,… сразу увидете причины для этого
погодите. Я не критикую стандартизацию и не говорю что она не нужна. Я говорю что она принципиально не подходит для управлением количеством слоев абстракции.
> Плохому программисту «абстракции» мешают.
где вы нашли этот бред? Я такого не мог написать нигде и никогда.
> Детский лепет какой-то.
безопастники на моих проектах почему-то находят дыры, а не рассказывают что «могут».
> Программист состоящий в профсоюзе
Вы пишите в разрезе зарплат. Я писал про другой разрез.
faoriu
06.12.2019 01:25Вообще говоря подходы к написанию надежного кода практикуются ещё со времён первых Шаттлов. Другое дело что большинству менеджеров пока важнее добавлять свистелки.
bm13kk
06.12.2019 01:44> Вообще говоря подходы к написанию надежного кода практикуются ещё со времён первых Шаттлов.
При всем при этом условия изменились. Создатели первых шатлов разрабатывали все слои абстракции начиная с железа и заканчивая психологией пользователя.
Как бы мы не ругали скупость создателей машин и самолетов — я сомневаюсь что они вообще могут написать весь необходимый код на том же уровне. Как минимум — у них там уже несколько операционок.faoriu
06.12.2019 13:47В современной винде строк кода примерно на порядок больше, чем в прошивке Шаттла. С другой стороны, команда разработки софта там была небольшой, а инструменты — гораздо менее удобными, чем современные. Кроме того, добавление фич зачастую идёт по принципу «лишь бы было», вместо улучшения надёжности, стабильности и быстродействия — при том, что большинству пользователей хватает и Windows 7 с Word 2003.
Whuthering
06.12.2019 19:23Вообще говоря подходы к написанию надежного кода практикуются ещё со времён первых Шаттлов. Другое дело что большинству менеджеров пока важнее добавлять свистелки.
Проблема не в свистелках и менеджерах, проблема в том, что разработка с учетом техник «безопасного кодирования» и всего что вокруг этого (типа верификации, сертификации) в итоге выходит очень дорого по деньгам. А большинство покупателей, увы, голосует рублём (точнее, долларом), и часто не готово платить в 10 раз дороже за «надежность» и «безопасность».faoriu
07.12.2019 00:01Рентабельность IT компаний чересчур завышена: если бы были регуляции, обязывающие всё тщательно проверять, то им бы просто пришлось поумерить аппетиты — конкуренция-то никуда не денется. А высокая рентабельность и триллионные капитализации образуются в том числе за счёт того, что IT компании привыкли перекладывать издержки-экстерналии, образующиеся из-за использования глючного, медленного и уязвимого ПО, на конечных пользователей: всех как-то приучили, что если ты поймал вирус — «сам виноват«, если тормозит система — «купи новое железо», упала система — «просто переустанови её», накатил обновление, из-за которого перестал работать критичный софт — «сам дурак, надо было проверить на виртуалке» и тп.
vvzvlad Автор
06.12.2019 19:27И рано или поздно эта стопка пройдет какой-то критический размер и сколлапсирует. И нам всем придётся это разгребать.
Ну, возможно. Это обычный процесс и ничего с ним нельзя сделать, рост-кризис-изменение-рост.
Ну, например, динозавры. Вырастив огромных существ на доступных ресурсах, эволюция зашла в тупик: дальше изменяться некуда, для более высокой высоты надо спуститься с текущей горки, а зачем это делать, если пока норм. А когда стало не норм — шанс получили другие классы существ, и оказалось, что теплокровные млекопитающие более эффективные: стабильная температура позволила поднять тактовую частоту мозга и остальных систем, быстрый метаболизм позволил выделить на мозг достаточно энергии, чтобы эффект от мышления начал приносить качественно новую пользу.
Am0ralist
06.12.2019 20:14А когда стало не норм — шанс получили другие классы существ, и оказалось, что теплокровные млекопитающие более эффективные: стабильная температура позволила поднять тактовую частоту мозга и остальных систем, быстрый метаболизм позволил выделить на мозг достаточно энергии, чтобы эффект от мышления начал приносить качественно новую пользу.
Так сейчас вроде же как считают, что таки у них была стабильная температура и весьма высокий метаболизм.vvzvlad Автор
06.12.2019 22:10Ну, значит что-то другое сыграло роль. Я скорее про то, что качественно иной рост зачастую прекрасно развивается на обломках старого мира.
bm13kk
09.12.2019 12:39Спасибо что ответили.
Вы сейчас пишити с точки зрения наших потомков. «Век назад програмисты были не сильно умны и не видили этой очевидной проблемы. Эта проблема разрослась до размеров коллапса и теперь мы знаем что нужно ...»
Я пишу с точки зрения того, кто почти наверняка этот кризис будут непосредственно переживать. Как и Вы. Зачем мне массовые увольнения по всей индустрии и резкое падение зарплат во всем мире?
faoriu
06.12.2019 01:30Если раньше терминалы заказа авиабилетов требовали знания сокращений, понимания, как работают авиакомпании и навыка работы с текстовым терминалом, то теперь любой пользователь заходит на условный Aviasales
То есть гигабайты фреймворков сейчас уходят на то, чтобы пользователь мог тыкать кнопочки и менюшки на сайтах? Но позвольте: кнопочки и менюшки ничем принципиально не изменились с 80х годов, когда графические ОС умещались на паре-тройке дискет.
vladkorotnev
06.12.2019 03:51Ну как же не изменились — стали круглее, чтобы бедный юзверь не порезался глазами об острые углы; цветастее, чтобы ему не приходилось напрягать межушный ганглий для чтения надписей; крупнее, чтобы ему не приходилось целиться для нажатия.
А так как больше всего денег приносят именно юзвери, не умеющие в чтение, прицеливание и боящиеся острых углов, в силу своей банальной численности, то это и пользуется спросом.vvzvlad Автор
06.12.2019 19:21+1Ваше пренебрежение к юзерам, которые не хотят пользоваться плохими интерфейсами мне непонятно: без них у нас бы до сих пор были менфреймы, дисплеи 80х70 и программы на фортране или си.
Assimilator
07.12.2019 01:55vvzvlad Автор
08.12.2019 02:31Эм. Я вам могу и перфокарты использующиеся найти. Только это не отменяет того, что вы читаете этот сайт с LCD-экрана с 32-битным цветом и разрешением, которое не очень давно никому даже не снилось. И хорошо, если это разрешение экрана не телефона, который вы держите в руке.
glestwid
07.12.2019 11:40А так как больше всего денег приносят именно юзвери, не умеющие в чтение, прицеливание и боящиеся острых углов, в силу своей банальной численности
С учетом того, что процентов 70 капиталов планеты принадлежит 5% населения это кажется сомнительным.faoriu
07.12.2019 12:44Им принадлежит столько денег как раз потому, что они не приносят их кому-то другому :)
perlestius
06.12.2019 07:58+1Неужели нельзя было сразу создать человека, который может выжить хоть на северном полюсе, хоть в пустыне, несмотря на то, что сам довольно хилый — бегает небыстро, когтей нет, зубы маленькие и тупые, угол обзора небольшой.
Не очень удачный пример. Намного убедительнее в плане выживаемости смотрелась бы тихоходка
MooNDeaR
06.12.2019 10:05+2Забавно, что первоначально, автор сетует на то, что программирование из инженерной профессии превратилось в какую-то маркетинговую машину по зарабатыванию денег. Вы на протяжении всей статьи, в сущности, подтверждаете его точку зрения и вся разница в том, что вы говорите: "да, так и надо".
Не буду утверждать, кто из вас прав, а кто нет, мне просто ближе точка зрения автора оригинальной статьи. Мне кажется забавным тот факт, что программирование — единственная "инженерная" область, в которой техническое совершенство не является конкурентным преимуществом.
Если взять какие-нибудь "обычные" инженерные вещи вроде автомобилестроения или даже обычного строительства, то можно увидеть, что работа над техническим совершенством частей составляющих "продукт" (автомобиль, строительство, производство ЦПУ etc) приводит к улучшению конкурентоспособности "продукта" (сниженное потребление бензина, более долговечные конструкции зданий, сниженное энергопотребление). Такое положение вещей приводит к тому, что цели инженеров (делать крутые штуки и улучшать мир) и бизнеса (извлекать прибыль) совпадают.
В программировании наблюдается какой-то обратный процесс. Херачим говнокод, с говнокостылями, приправим электроном и вот у нас чатик размером гигабайт (привет Slack). Получается, что интересы программистов (писать "хорошие" стабильные системы) и интересы бизнеса расходятся в корне.
Интересно и то, что судя по тем книгам что я читал (мне почти 27, я не застал начало эпохи программирования, пришлось читать об эпохе 80-х из книг), такая ситуация была не всегда. Во времена ограниченных ресурсов, программисты занимались тем, чем и должны — повышали технологическое совершенство софта. А потом началось, где-то в начале двухтысячных началась "hardware лихорадка". Нам (программистам) дали слишком много ресурсов и мы всё просрали. Просто мы не успели придумать, чем бы это железо нагрузить.
Бизнесы еще не успели осознать какие объемы данных можно теперь обрабатывать, поэтому появились х**яторы, которые решили задачи бизнеса самым дубовым способом — и это работало, потому что железо вывозило. С тех пор, мы разгребаем последствия :)
olartamonov
06.12.2019 11:42+2Получается, что интересы программистов (писать «хорошие» стабильные системы) и интересы бизнеса расходятся в корне
Нет, не расходятся. Точнее, вы неправильно понимаете интересы программстов.
Большой процент программистов выдаёт на-гора плохо написанный говнокод, потому что другого не умеет и уметь особо не хочет (у меня вот хит месяца — вместо одной функции на 30 строк с тремя параметрами человек нагенерировал десяток функций и 300+ строк копипастом, захардкодив эти параметры во всех практически возможных комбинациях. Следующим шагом, разумеется, нашёл ошибку, в половине копипасты её исправил, в другой забыл. Вы думаете, зелёный джун? Нет, десять лет опыта, профессиональный разработчик встраиваемого ПО для серьёзной промышленной автоматики).
Бизнес этих программистов нанимает, во-первых, потому, что других тупо мало, во-вторых, потому, что оценить качество кода постороннему человеку намного сложнее, чем качество автомобиля — а до состояния «у меня работает» программисты свои поделия доводить таки научились.
При этом такие вещи, как QA, code review и т.п., по сути внедрены как раз бизнесом. И вот здесь интересы бизнеса и программистов действительно расходятся ;)
Mogwaika
06.12.2019 18:01А код с захардкоженными параметрами не работает быстрее в некоторых случаях? Иногда даже разворачивание цикла быстрее работает.
А ошибки копипасты везде бывают, нужно проверять внимательнее…olartamonov
06.12.2019 22:26Конкретно этот код — это вывод на графический монохромный ЖК по SPI, случающийся раз в секунду. Плюс-минус десять микросекунд в его производительности не волновали ровным счётом никого, а вот минус триста строк кода, минус три килобайта прошивки и минус все ошибки копипасты разом после сведения этой простыни к вызову одной функции с тремя параметрами — многих.
Int_13h
06.12.2019 16:10Такое положение вещей приводит к тому, что цели инженеров (делать крутые штуки и улучшать мир) и бизнеса (извлекать прибыль) совпадают.
Получается, что интересы программистов (писать «хорошие» стабильные системы) и интересы бизнеса расходятся в корне.
Цели работника и бизнеса совпадают! Цель бизнеса — получение максимальной прибыли при минимизации издержек. Цель работника точно такая же — получение максимальной прибыли (зарплаты) при минимизации издержек (усилия, рабочее время, и т.д.).
Просто в других отраслях уже давно дошли до того, что надо как то контроллировать процесс производства и качество конечной продукции. Или бить рублем, если не хотят по хорошему.
Представьте себе, что приходится жить в доме, в котором постоянно течет крыша, ветер задувает в щели в стенах, свет может сам по себе выключиться в любой момент и неизвестно когда включится. И это продолжается изо дня в день, хотя каждый день приходит мастер и исправляет, исправляет, исправляет. А как насчет автомобиля, который после каждого технического обслуживания начинает ехать на 10% медленнее, но при этом начинает потреблять на 10% больше бензина. Зато в последнее ТО появилась симпатичная подсветка приборной панели, а фары теперь мигают при виде хозяина. Но надо отдать должное, в предыдущее ТО наконец стала закрываться водительская дверь, хоть это и не работало с завода. Но теперь не окрывается багажник. Но это естественный процесс, мы работаем над этим, пользователю надо немного потерпеть. И вообще, есть же лицензионное соглашение, где мы снимаем с себя всю ответственность.
ilammy
06.12.2019 10:58(Упс, промахнулся. Это ответ MooNDeaR на комментарий выше.)
[с "обычными" инженерными вещами] работа над техническим совершенством частей составляющих "продукт" [...] приводит к улучшению конкурентоспособности "продукта"
Не совсем. Дело в том, что для «обычных» вещей фаза производства экземляра имеет вполне себе существенную стоимость, а затраты по эксплуатации этого экземпляра перекладываются на покупателя. В случае с программным обеспечением же затраты на производство экзепляра околонулевые, большая часть расходов вызвана по сути конструкторской деятельностью. Кроме того, с программным обеспечением очень популярен подход, когда прямые затраты по эксплуатации несёт не конечный покупатель — подход software as a service. Поэтому динамика у софта и автомобилей немного отличается.
Если инженер-проектировщик автомобиля захочет использовать какую-то технически крутую деталь, которая улучшит мир (например, волшебный поглотитель свинцовых выбросов), но это увеличит стоимость производства и потребует значительных капитальных вложений, то бизнес его вряд ли за это наградит. В то же время, эксплуатационные расходы в какой-то мере можно поднимать, если это снизит издержки производства — до тех пор, пока владельцы автомобилей согласны платить из своего кармана за удобство для бизнеса и развитие инженеров, которые получают возможность стремиться к техническому совершенству, не особо оглядываясь.
В случае с программным обеспечением решения инженеров слабо влияют на собственно производство, а современные системы делают эксплуатацию сравнительно дешёвой (можно писать слек, жрущий гигабайты, потому что пользователи терпят). Поэтому бизнес волнуют расходы в единственном месте, которое их генерирует — на этапах проектирования и конструирования, во многом состоящих из творчества, где технически крутые штуки очень соблазнительны для инженеров. А замена уже спроектированных и работающих, но менее крутых штух обходится в копеечку для бизнеса, который собственно заказывает музыку.
Pafnutyi
06.12.2019 13:35С автомобилестроением легковым особенно ситуация даже хуже, там инженеров заставляют делать всё плохо — заранее вкладывать неизбежные поломки. На рынке уже нет моторов которые могут проехать дольше 150ткм без капиталки ))))
Max173
06.12.2019 12:09-1До чего ж обидно быть Вайтишником)) что ни статься, то — камень в огород по поводу демпинга( что, кстати, таки правда, тк сам — презренный ватишник по началу готовый работать за еду0). Ну а в плане разнообразия технологий, тоя согласен с автором, что сейчас мы на первобытном уровне в плане ПО и идет естественный отбор в плане технологий. Через лет 20-50 все будем смеяться по поводу «лучших практик» нашего времени))
Oxoron
07.12.2019 14:19До чего ж обидно быть Вайтишником)) что ни статься, то — камень в огород по поводу демпинга
Иронично, что на хабре регулярно проскакивают эмоции вроде «да я уже на втором курсе вкалывал в конторке за еду и опыт». Но еще более иронично, что приличный процент комментаторов работает на фрилансе, ругая вкалывающих за еду индусов, и в тоже время демпингуя относительно американских\английских разработчиков.
archi_sova
06.12.2019 18:09Если честно, меня самого посетила мысль «хайпнуть» на антипосте. Ну, а так если честно, то складно получилось. Спасибо! +
engine9
06.12.2019 18:20>… теперь любой пользователь заходит на условный Aviasales, и подбирает себе дешевый билет по сложному маршруту без особого геморроя.
Странный аргумент, налицо ведь не ограничения технологической платформы, а недоработка в части UI/UX. При желании можно сделать чисто текстовый интерфейс выбора билетов, сверхминималистичный и основанный на диалогах.
vvzvlad Автор
06.12.2019 19:18Это именно ограничение технологической платформы: для человекопонятного интерфейса на диалогах он должен быть похож на общение с человеком.
Это значит языки, правильные склонения, подсказки, умение повторять три раза одно и то же и подсвечивать явные ошибки, например, когда прилет раньше вылета, а разница между рейсами на пересадке всего час.
Значит, много памяти, много логики, UTF-8, строки и примитивы работы со строками, легкость написания и изучения ЯП (потому что проще взять выпускника вуза и научить его писать бизнес-код, чем отдавать программиста в вуз) и так далее. Значит, какой-нибудь питон. А питон невозможен без быстрых процессоров и оверхеда по памяти.
Нет, конечно, можно написать такую логику и на С/ASM, но это настолько сложно и дорого, что выгоднее написать минималистичную систему и посадить девочек-операторов, отдав часть бизнес-логики им в мозг.
Как только цена разработки каждого уровня человекопонятности интерфейса падает достаточно, этот уровень пишут, не особо обращая внимание на костыли и конкретные проблемы подхода и языка. Просто потому, что это дает аудиторию и буст к разработке.Assimilator
07.12.2019 02:11Существует огромная разница между читабельностью и бесполезными фичами. Какой-нибудь drop-down на три стандартных опции, обновляющиеся раз в пятилетку, раньше грузился на рефреше, теперь вкорячен на JS/JQ, с асинхронной загрузкой трёх опций из (!!!) датабазы. Я бы понял многоязычность, но её там не росло.
piton_nsk
06.12.2019 23:48-1Если ваша работа не приносит денег — простите, она не нужна бизнесу
Всегда было интересно сколько денег бизнесу приносит уборщица. Или бухгалтерия.
бизнеса интересует лишь одна цифра — прибыль на вложенные деньги.
Сколько прибыли Абрамовичу принесла его знаменитая яхта?vvzvlad Автор
07.12.2019 01:00Всегда было интересно сколько денег бизнесу приносит уборщица. Или бухгалтерия.
Уборщица приносит бизнесу ровно столько денег, сколько у него станет меньше после того, как половина разработчиков уйдет из-за грязи на полу и необходимости выкидывать мусор, а клиенты будут осторожнее заключать договора в кабинете, в котором немного пахнет несвежим мусором. Много она денег приносит, в общем. Но из-за того, что убираться просто, и квалификации это занятие не требует, зарплаты уборщиц относительно разработчиков маленькие.
Бухгалтерия приносит столько денег, сколько составляет разница между 10 договорами, которые заключает лично директор, и 100, которые может оформить и сопроводить пять бухгалтеров.
Сколько прибыли Абрамовичу принесла его знаменитая яхта?
Понятия не имею. Но она либо была развлечением, и тогда о прибыли говорить странно — это не бизнес, а просто хотелки человека, который хочет и может потратить деньги на что-то приятное, либо бизнесом — и тогда можно рассуждать о том, почему она была убыточная формально, и какую функцию она выполняла (возможно, она впечатляла потенциальных партнеров).
piton_nsk
07.12.2019 12:21-2Получается что уборщица приносит денег больше разработчика (давайте предположим что организация занимается разработкой ПО). Если равномерно распределить для простоты картины, получается 50% денег приносит уборщица. А вот бухгалтерия приносит денег где-то уже 90% — пусть договора будут примерно одинаковые опять же для простоты. Еще до разработчиков не добрались, а уже получается больше ста процентов. А ведь есть еще менеджмент, сейлзы, девопсы, QA. Вам не кажется что тут что-то не так? Вообще комментарий был не к тому, что уборщица или бухгалтерия не нужна. Смысл был в том, что крайне редко можно посчитать сколько приносит денег отдельный член трудового коллектива.
это не бизнес, а просто хотелки человека, который хочет и может потратить деньги на что-то приятное
Хотелки человека и в бизнесе имеют место быть. Захотелось, не знаю, зеркало в полный рост на ресепшене, взял и сделал. Не особо задумываясь о том, сколько именно оно принесет денег. Потому что есть внутренняя уверенность что это круто, привлекательно и вообще полезно. Есть ли вообще люди, которые высчитывали сколько прибыли принесет покупка того или иного офисного кресла? Да и есть ли способ это сделать? Думаю вы очень сильно упрощаете мотивацию людей.vvzvlad Автор
08.12.2019 02:28Еще до разработчиков не добрались, а уже получается больше ста процентов. А ведь есть еще менеджмент, сейлзы, девопсы, QA. Вам не кажется что тут что-то не так?
Нет, не кажется. Мы же говорим о том, сколько некий процесс отнимает от прибыли, а она меняется на каждом шаге. Отсутствие уборщицы уменьшит прибыль на 50%, отсутствие бухгалтерии уменьшит оставшуюся еще на 90.
Ну, и никто не мешает отнимать больше 100 процентов — это означает, что задолго до достижения целевого -400% прибыль компании станет равна нулю. Уменьшалась бы и далее, но некуда.
Смысл был в том, что крайне редко можно посчитать сколько приносит денег отдельный член трудового коллектива.
Да нет, посчитать можно. Ценность, например, бухгалтера — это сэкономленное время основателя. Бизнес основателя в одно лицо приносит 1м рублей в месяц, при этом на бухгалтерскую работу он тратит 20%. После того, как он нанял бухгалтера — он тратит на это 2%. Бухгалтер стоит 100к. 1 000 000/100*(20-2)=180 000, значит приносит он 80к, причем неважно, ищет основатель компании в это свободное время новых клиентов или отдыхает — это уже вопрос того, куда эти 80к тратятся.
Стоимость разрабов считается через проекты.
Во всех крупных компаниях есть внутренняя валюта — человеко-часы средств производства, тобишь, разработчиков. Они считаются как зарплата+налоги+стоимость страховок/тренажерных залов+стоимость аренды места+амортизация оборудования+зарплата начальников. Это стоимость человека, то, во сколько он обходится компании. Дальше считаем часы, которые он тратит на проекты, и зная стоимость проектов, понимаем прибыль от человека. Стоит человек, к примеру, 22к/день, делает проект два месяца, проект стоит полтора миллиона. (1500000-(22000*20*2))/2=310к в месяц он заработал родной компании.
Хотелки человека и в бизнесе имеют место быть. Захотелось, не знаю, зеркало в полный рост на ресепшене, взял и сделал. Не особо задумываясь о том, сколько именно оно принесет денег. Потому что есть внутренняя уверенность что это круто, привлекательно и вообще полезно.
Вы путаете траты «на красоту» и «потому что захотелось» и целевые затраты, которые должны окупаться. Первое — это не бизнес, это просто утилизация «лишних» денег, которыми можно улучшать условия, а можно просто делать красиво. Есть у нас миллион денег на обустройство офиса — можно купить кресла, микроволновку и холодильник. Нет — значит, на старых креслах пусть сидят. Это в некоторых случаях имеет эффект, но проявляется он, по большему счету, только в крупных компаниях, когда люди осознанно хотят в Яндекс/Гугл, потому что у них офисы красивые, переговорки удобные, а на кухне бесплатные печеньки. Если вы компания с 10 сотрудниками и офисом на 40кв.м., то есть у вас микроволновка, нет у вас ее — всем пофигу, и на прибыль это не влияет: никто не придет к вам из-за ее наличия и никто не уйдет из-за отсутствия. Разве что сотрудники будут дольше на обед ходить. Поставить можно, но исключительно из-за удобства или внутренней уверенности что полезно, но окупаемости ждать бессмысленно — это не фактор, добавляющий ценности и не оборудование, приносящее прибыль. Ну, хоть 5 минут сотрудника каждый день, приносящего 200к стоят 2к, не факт, что он их потратит на работу.
Но возможность поставить микроволновку она появляется исключительно потому, что она добавляет к CAPEX 10к и 20 рублей к OPEX, что в целом, на фоне CAPEX-а на офис в 1м и OPEX-a на него же в 50к немного несущественно.
Однако, пытаясь потратить суммы, которые сравнимы с оборотом или прибылью, но не считая окупаемость для них, вы быстро прогорите и закроетесь нафиг. Если ИП с прибылью в 1м решит снять тратить на офис столько же, сколько условный Яндекс, то к нему, безусловно, придут пара человек, которым важен офис. Но вот только эти пара человек совсем не поднимут прибыль на стоимость офиса, и через месяц станет грустно, потому что офис стоит больше, чем вся его прибыль.
ardraeiss
Сломав или просто поцарапав руку — ты умеренно здраво(когда адреналин сойдёт) оцениваешь состояние и принимаешь решение лечить.
Здоровье же мозга не в последнюю очередь влияет на способность этого самого мозга оценивать собственное здоровье. И, соответственно, вовремя видеть начало входа в и здраво принимать решения по выходу из — что и мешает "но это вопрос контроля ментального здоровья" без наличия опыта. Да и при наличии непросто.
Особенно когда горение ещё и поощрается, а негорение открыто ставится минусом.
Ну и плюс стигматизация/убеждение "я не псих же, ко всяким копающимся в голове ходить!"/"выдумка это всё, прорвёмся"/"пахать надо больше, не будет времени на глупости".
vvzvlad Автор
Про здоровье мозга вы, мне кажется, преувеличиваете: повредиться разумом от выгорания до такой степени, чтобы не заметить этого самого выгорания… Вряд ли.
По поводу же всего остального — у многих профессий существуют профессиональные заболевания. В куче из этих профессий для их предотвращения ничего не делается, и даже поощряется. Ну, вот и в IT теперь, помимо туннельного синдрома еще и это. Так себе ситуация, но не мы первые и не мы последние.
ardraeiss
Заметить то можно. Вот с поиском выхода всё куда хуже, потому что мозг к этому моменту уже несколько заклинен в сложившейся ситуации.
И это если понимать, что именно следует замечать — а вокруг звучат убеждения вплоть до "выгорание выдумали лентяи" и "заведи семью, возьми ипотеку, родите ребёнка — и как рукой выгорание снимет!". Звучало на Хабре буквально недавно в каких-то из близких к выгоранию тем; да и в просто жизни встречалось
Crazyvlad
Профессиональное выгорание существовало задолго до ИТ. И методы борьбы с этими явлением давно известны.
berez
Экий у вас идеальный мир с летающими понями…
Повредиться разумом человек может безо всяких выгораний. Просто «повреждения» бывают сильно разные, и вовсе не обязательно человека в психушку увозят. Бывают просто граждане с очень специфичными завихрениями в картине мира. Причем у кого-то эти завихрения так и остаются милыми безобидными завихрениями, а кто-то начинает бункер рыть в подвале многоэтажки, спасаясь от рептилоидов.
Что касается «не получится не заметить» — вы сильно, ну прямо вот вообще очень сильно, недооцениваете защитные механизмы мозга. Во-первых, «съезжание крыши» происходит постепенно, и человек так же постепенно обрастает защитными «коленными рефлексами» при столкновениях с суровой реальностью. Во-вторых, людям и в нормальных-то обстоятельствах бывает трудно оценить свое поведение со стороны, а представьте, каково человеку, которого окружают агенты инопланетян, успешно маскирующиеся под людей…