Comments 161
Я тоже программист в возрасте, и полностью согласен со всеми пунктами.
Вот только на «этот вопрос Quora» я бы ответил иначе. Ну честно говоря мне тупо надоело работать вообще. в принципе. Но с другой стороны если выбирать меньшее зло я конечно предпочту писать код (но с течением времени, этот процесс занимает все меньшую и меньшую долю моей работы)
Согласен с Вами. Мне вот с возрастом стало интересно работать руками. Мастерить, осваивать деревообработку, металлообработку. что то конструировать и тд и тп.
Из смежного - схемотехника проектировать и делать устройства автоматизации. И разработка тут уже как хобби. Интересно смотреть и изучать что то новое, наблюдать, как достаются древние технологии, с них сдувается пыль и продается неискушенному молодому поколению как "аналоговнет"...
Есть нехватка единомышленников в своих хобби, так как в одного долго проводить все работы. от железа до полноценной комплексной системы. Некоторые задачи хочется делегировать :-)
Мне 50, автор просто опубликовал мои мысли :)
Там речь про 40 лет. А 40 это ещё не возраст, в котором ты начинаешь лежать в сторону кладбища. 40 это когда только начинаешь рефлексировать на тему: "Ну вооот, уже старый.... Ой, и дефки глядят насквозь будто нет меня.... Вон и турникет в метро показал '40', издевается, суууука.....". А потом приходишь на работу и рвёшь молодых просто за счёт того что уже знаешь как оно будет, как надо чтобы было и просто совершаешь меньше лишних движений :)
Похожие чувства с автором этих пунктов. Выработал для себя правило "Сам не сделаешь — никто не сделает". Это касается и документации, и тестов, и банальной проверки на null 😁
> Выработал для себя правило "Сам не сделаешь — никто не сделает".
"Если хочешь что - то сделать хорошо, сделай сам!" (с) Фердинанд Порше. У нас более известно, как высказывание Зорга из "Пятого элемента".
... и джокера
Зависит от поколения ))) Я вот не знал, кто такой Джокер, до тех пора, пока меня не напугали, что актер, который его гениально по словам пугавших сыграл - Хит Леджер - не двинул кони от передоза снотворным, которое я сам иногда в бессонницу пользую. А кто такой Зорг и Гэри Олдмен мне точно рассказвать не надо )))
Сам иду в сторону 40 и со многими пунктами согласен, но ваше утверждение может заблочить многие возможности для карьерного роста. Потому что в любом случае не получится всё делать самому, а уметь грамотно делегировать надо уметь.
некоторые произвольные соображения от сорокалетнего программиста
А я без малого семидесятилетний программист с почти пятидесятилетним стажем и тоже согласен со всеми пунктами.
Может читал не внимательно.... "в возрасте" - это сколько? А то у меня в команде есть один "в возрасте" (он так считает), так ему 36 :)
вот некоторые произвольные соображения от сорокалетнего программиста
Это про 40. В оригинале он не в возрасте, а стареющий (aging), но правка понятная: в заголовке "стареющий" заходит не очень
"в возрасте" — это сколько?
fun isAged(age: Int) = age > 29
open class AgeAnswerer(private val env: Environment) : HumanAnswerer<Mental, Audio>, TemporalAware { fun isAged(age: Int):
return env.isHumanAgeSoMuchForIntensiveWork()
}
А как эту функцию потом из памяти выковырять, чтобы к ней обратиться?
29 секунд от Рождества UNIX? ;)
С точки зрения программирования, хотелось бы число заменить константой, но так хочется пожить.
P.S. Тоже с теплом вспоминаю, как 20 лет назад на rsdn обсуждали тему о том, что после 30 программировать невозможно.
На форте ещё короче: 29 >
Ну по сути - пусть считает. На самом деле ему ещё расти и расти до "в возрасте".
Мне за 45, согласен со всеми, примите в клуб, братцы :)
Согласен на 146%.
— пункт про Руководства людьми. — С возрастом стал больше любить руководить людьми.
— пункт про вызовы — Не люблю непонятных задач.
P.s. Жаль пункты не пронумерованы. Неудобно ссылаться.
А вот после 15 лет на удалёнке вернуться в офис, кажется, не такая уж и плохая идея. Хотя бы ради общения. Потому что, да: «Как бы это ни выглядело на первый взгляд, проблема всегда в людях»
Я после трех лет на удаленке вернулся в офис, и был так счастлив, что готов был людей обнимать.
Пришёл в офис спустя 8 лет удалёнки
Сначала думал, что это будет испытанием, но каждый день тороплюсь в офис. Даже завтракать перестал)
Но хотя я мб нерепрезентативен, так как наш офис ну очень крутой. Люди туда на выходных приходят потусить
Правильные мысли, согласен с автором
Мне 37 и я только разгоняюсь
теперь с удовольствием меню план действий, если меня смущает запах кода или пропадает аппетит.
Официант! В моем супе - баг!
Если по сути - больше похоже на хотелки, всплывшие вследствие самопознания. К реальным условиям работы имеют весьма призрачное отношение.
Мне 55 лет. Согласен с большинством пунктов.
Программирую уже 3 неделю, согласен на все 100
Вот только поменьше бы этого нарциссизма. Ведь я стал успешен, как никогда. Я универсал. Ответственность - это моё второе "я". Моя предсказуемость улучшилась. Я постоянно учусь новому, но не кидаюсь за новинками. Буээээээ<исходит на радугу>
нет здесь нарциссизма. Ретроспектива обычная.
Ведь я стал успешен, как никогда. Я универсал. Ответственность - это моё второе "я". Моя предсказуемость улучшилась. Я постоянно учусь новому, но не кидаюсь за новинками.
Зачем перевирать то, что написал автор?
Он же не сравнивает себя с другими, и не говорит, что лучше других. Он сравнивает себя с самим собой, и проводит ретроспективу, как он изменился, чему научился.
"Я шел впереди всех, высокий и стройный..."
Я бы добавил еще пункт про то, что в разработке нет догм. И бизнес платит, чтобы его проблему решили наиболее эффективным способом. Не "правильным", а эффективным.
Если вам хочется написать микросервисное распределенное докер-кубер-чудо - бейте себя по рукам линейкой. Если хочется многопоточный монолит - тоже бейте. Тоже линейкой. И за код с душком бейте. А за идеальный, структурированный, понятный, легко поддерживаемый, покрытый тестами, документированный код бейте молотком.
Потому что идеальный он только в вашей голове и только по вашему мнению. А за эту виртуальную идеальность бизнес заплатил реальными деньгами. Реальным временем. И не факт, что вот это все было действительно нужно. Особенно, когда вы перейдете на другой проект или в другую компанию.
Сначала сходите к бизнесу, и поймите его боль. Вы работаете, чтобы эту боль облегчить.
бейте себя по рукам линейкой
тоже бейте. Тоже линейкой
бейте молотком
Многовато мазохизма. Какая-то попытка достичь "идеальной неидеальности".
Потому что идеальный он только в вашей голове и только по вашему мнению
а еще только до внесения первых изменений. Но с другой стороны есть понятие "достаточно хороший код", которое включает в себя тесты, удобство развертывания и конфигурации. Так что ничего нет плохого в микросервисном распределенном чуде, если оно удобно. Про многопоточный монолит - кхм, серверные приложения в большинстве случаев многопоточны, и это нормально.
Эх, боюсь, не донес я мысль.
Хотите пример из жизни?
Прямо сейчас ребята из Мин Цифры слепили на коленке поделку в виде csv файликов, куда кое-кто из нас сможет внести свои паспортные данные и отправить через Госуслуги.
Как считаете, в текущей обстановке им лучше наг...кодить обмен данными через csv, или же пару недель рожать "достаточно хорошее" решение, а потом еще пару недель его обкатывать? Ну там, с тестами, удобством развертывания и конфигурации?
Рабочий код сам по себе не является ценностью. Не может быть абстрактно "достаточно хорошего" кода. Как и "плохого". Он важен как инструмент для решения бизнес-задач. Что нормально, а что нет, диктуется целом рядом нефункциональных требований и ограничений.
Разработчики постоянно попадают в ловушку своего прошлого опыта, в ловушку своего "знания" как на самом деле надо разрабатывать. Кто-то стремится к идеалу, кто-то к золотой середине качества. Но даже такие, казалось бы, важные атрибуты качества, как эффективность, надежность, сопровождаемость не являются безусловно важными.
Потребности бизнеса диктуют, какой должна быть система. А не наоборот.
ну так поделку в виде csv файлов (кстати, с каких пор csv-файлы это что-то плохое?) тоже нужно как-то где-то деплойнуть, ничего при этом не сломав, и хотя бы простейшие тесты должны быть о том, что этот файл вообще читается, нормально парсится с учетом экранирования/обкавычивания, подпись проверяется, что там нет крякозябр из-за не той кодировки, что прочитанные данные нормально ложатся в базу и/или уходят в отраслевую ГИС в том формате, в котором она работает (и что там крякозябр тоже нет), правда ведь?
Я думаю, вы и сами не хотели бы получить мобилизационное по той причине, что в минобороны от минцифры данные ушли в cp1251, которая думает, что она utf-8, например.
с каких пор csv-файлы это что-то плохое?
Приблизительно всегда так было. 100500 диалектов, чтобы правильно прочитать - нужно знать, что в нем написано.
ну так это обычная метаинформация, такая же, как кодировка.
Я кстати извиняюсь, кодировка - это теперь моя больная тема. 3 года назад писал софт для государства, и вот мне в качестве тестовых данных для разработки прислали файлы в cp1251, причем никакой (!) метаинформации о кодировке не было, все чисто на соглашении. Ну и короче я ее вынес в конфиг. На тестовом стенде внезапно (!) оказалось, что половина файлов в 1251, другая половина в utf-8, причем из них половина с byte order mark, а другая без, ну и выяснилось это путем копания в hex-редакторе, конечно же, так как никто ничего не знал. Я, матерясь, налепил костыль с определением кодировки (не 100%, конечно же, но хоть так), и с горем пополам прошли тестирование. На проде оказалась utf-16-le (little, мать ее, endian!), причем выяснилось это тоже путем копания в hex-редакторе и тупо сопоставлением размера файла.
Искренне сочувствую. Всё ждём наступления XXI века.
Наверное, единственная хорошая вещь в том, что я покинул Россию в марте, это то, что мне не придется больше воевать с кириллицей :)
utf-8, utf-16, utf-16-le вполне себе интернациональны, так же, как и расширенный ascii
Это понятно, но за десять лет практики у меня боль была только с кириллицей. Ну, еще раз было покрашились скрипты в Европе, оказалось, они десятичную запятую используют вместо точки. Но то легко было поправить. А пока я работал в России, у меня прям ощутимый кусок времени уходил на борьбу с крокозябрами, которые регулярно вылезали вместо кириллицы. Почему-то, латиница так себя не вела в том же коде.
потому что латиница везде, кроме utf-16, кодируется одними и теми же байтами
Я думаю, вы и сами не хотели бы получить мобилизационное по той причине, что в минобороны от минцифры данные ушли в cp1251, которая думает, что она utf-8, например
Не хотел бы. Но увы, это более чем реально. Наши hr, например, сломали кодировку, когда решили в эксельке заполнить данные о ЮЛ.
Я не утверждаю, что фигак-фигак и в продакшен - правльно. Я привел крайний, редкий, пограничный пример, когда скорость важнее всего, и когда это оправдано.
Если вы разрабатываете софт для марсохода стоимостью 10млрд , который должен еще уметь дистанционно самообновляться - там, вероятно, будут другие приоритеты.
Я утверждаю, что нет догм.
Разумеется, нарушать "общепринятые" нормы можно только тогда, когда у вас есть достаточный опыт в разработке и архитектуре. Когда вы точно знаете, что делаете, и зачем. И ответить на эти вопросы можно только выяснив потребности бизнеса.
Сначала моя задача - собрать функциональные и не функциональные требования (да, хорошо бы этим занимались специально обученные люди, но они есть не везде)
А потом уже предложить варианты решений. Не наоборот.
Потому что помимо надежности и сопровождаемости есть и другие аспекты.
И я пытался сказать, что корреляция других атрибутов качества с реальными потребностями часто не учитываются при разработке, и либо продалбываются, либо наоборот, бизнес платит за то, чтот не нужно.
в живой разработке частенько бывает не "или", а "и": из говна и палок, и далеко не "еще вчера"
Вы ничего не объясните бизнесу! Бизнес руководствуется понятиями "тыжпрограммист". И бизнес, с очень большой долей вероятности (хотя бы на основании собственной, очень широкой, выборки), предпочтёт критерий "быстро", критериям "дёшево" и "качественно".
Ну или ещё частенько встречается такая мантра как "давайте сейчас по быстренькому запустим хоть как-нибудь, а потом уже неспешно сделаем всё по уму"...))
А для удовлетворения собственного перфекционизма и освоения новых технологий у каждого зрелого программиста есть один или несколько пет-проектов, находящихся в состоянии перманентного долгостроя))
Я, как немножко предприниматель, могу сказать, что такая стратегия - сейчас из спичек и желудей, но быстро, а потом перепишем с нуля - бывает рациональной. Это иногда контринтуитивно, уходит намного больше времени и ресурсов, страдает мораль разработчиков, что немаловажно, но в перспективе выходит гораздо лучше. Самое неприятное, что "тыжменеджер", который принимает решение, может быть мудрым аксакалом, а может быть самоуверенным дурнем, и это не определишь. А разработчик не хочет, не может и не должен лезть в бизнес стратегии.
Я, как немножко предприниматель, могу сказать, что такая стратегия - сейчас из спичек и желудей, но быстро, а потом перепишем с нуля - бывает рациональной.
Пока ты вылизываешь свой код до идеала - конкурент захватит рынок сляпанным на коленке аналогом, после чего будет не торопясь фиксить баги (с) наш директор
Да, я об этом. Это не всегда так работает, но довольно часто. Для того, чтобы понять, и нужен нормальный менеджер, а иначе бы все конторы состояли бы из одних разработчиков.
да необязательно даже конкурент захватит рынок. Тупо функционал может оказаться никому не нужным, и это лучше выяснить поскорее. Плюс бизнес-требования все равно уточнятся и дополнятся, так что лучше их прощупывать на поделке из говна и палок, которую выбросить не сильно жалко
стратегия - сейчас из спичек и желудей, но быстро, а потом перепишем с нуля - бывает рациональной
Воистину! Пример. К нам (в фирму, занимавшуюся системной интеграцией) пришёл заказчик и говорит: "У меня есть месяц времени, и за этот месяц мы должны хоть тушкой, хоть чучелком, но выйти в прод. Потом уже будем строить по-настоящему....". Обычный проектный цикл у нас был месяца 3-4. Ну, мы поскребли затылок, прикинули туда-сюда и согласились. Проект был успешно реализован. Естественно:
мы максимально упростили все свои процессы, оборудование не заказывали за рубежом, а выискивали то что есть на складах (заодно помогли другому клиенту продать технику, закупленную под проект, который не состоялся), естественно, оно было не оптимальным, зато в наличии; чертежи/схемы тоже были сделаны максимально упрощённо из-за чего инженерам пришлось работать практически вместе с монтажниками, на месте разрешая все непонятки - зато быстро;
заказчик пришёл с пониманием что ему придётся купить два проекта: "тушку" и настоящий.
С тех пор все подобные временные решения мы называли "тушка". И надо сказать, спрос на такие вещи на рынке был, просто раньше мы об этом не знали :)
Надо сказать что тушка - вещь весьма полезная. Помимо того что она позволяет раньше запуститься, ещё:
её можно использовать как резерв к основной системе (ну точнее как резерв резерва :));
ей можно расширить основную систему если это срочно потребовалось, т.е. использовать тушку по основному назначению;
на ней можно проводить всякие опыты по расширению бизнеса;
в конце концов её можно просто продать очередному страждущему (мы иногда собирали тушки в кейсах на колёсиках, благодаря чему её можно было легко разобрать и собрать на новом месте).
Мне кажется, вы сейчас описали метод разработки Lean :)
собирали тушки в кейсах на колёсикаха можно пример?
Поиск "flight rack case", "touring rack".
Корпус принципиально бывает двух видов:
алюминиевый каркас с усиленными углами; стенки:
лёгкий сотовый пластик;
прочная фанера, которую не проткнуть, например, углом другого кейса при перевозке;
цельнолитой из 2-слойного высокопрочного пластика (легче, но габаритнее).
Рэковые рейки (к которым крепится оборудование) могут:
жёстко крепиться к корпусу/каркасу;
вывешиваться внутри каркаса на амортизаторах.
По брэндам/продавцам не подскажу т.к. давно уже другим занимаюсь. Картинки для примера.
Примеров полного проекта у меня, конечно нет :)
Но меня занесло ненадолго поработать в одну телеком-компанию и я там поучаствовал в модернизации их комплекса. Ну и я по старой памяти предложил прежде чем вертеть гайки, сначала помоделировать на компухтере. Расчехлил свой старый САПР и размял пальчики :) Их реакция: "0_о, а шо, так можно было?!!"
Пара примеров чертежей
Конечно, "настоящий проект несколько сложнее. Обычно это ~300 неповторяющихся позиций в спецификации, 3-4 помещения с оборудованием, кабельные трассы и вот это всё. Бывают и крупные проекты - это 3-4 этажа с оборудованием :) Но такие всегда бьются на системы, которые представляют собой обычные проекты. Как говорится, большой проект - такой же как маленький, просто большой :)
В целом, проект системной интеграции имеет такие особенности:
мы не разрабатываем оборудование и ПО, а закупаем готовое, наша задача - собрать и настроить всё вместе чтобы оно решало задачи заказчика;
иногда нам требуется какой-то специфичный прибор (например, преобразователь интерфейса или особенная панель управления) - тогда мы заказываем его у местного производителя; так как он прекрасно погружён в предметную область, ему не требуется детального ТЗ "до последнего бита": описываем назначение устройства, м.б. какой-то эскиз, ссылки на примерно похожие аналоги, на протоколы обмена и всё; далее совместно впиливаем прибор в комплекс, дорабатывая
рашпилемпо месту;максимум что мы делаем сами это какая-нибудь панелька (1U бланк) с кнопкой (из Чип-Дипа);
не, ну бывало - делали что-то на МК, но просто "потому что можем", на неответственный участок и без каких-либо гарантий :)
Особенность нашей предметной области в том что нам не требовалось сдавать проекты по ГОСТ (как строителям или энергетикам), поэтому мы основной упор делали на простоту и понятность. Понятно нам, понятно монтажникам ( а они у нас свои), понятно заказчику - значит хорошие доки! Заказчик у нас профессиональный, в технике разбирается не хуже нас, поэтому со временем сложились определённые традиции в оформлении проектов, которым мы все вместе следовали (хотя, конечно, мы старались делать максимально близко к ЕСКД чтобы не совсем уж от балды).
Обычный проект состоял из:
~ десятка чертежей А0 (или больше) плюс нескольких помельче со схемами, общими видами стоек, пультов (рабочих мест) с врисованными человечками (понятна доступность органов управления, обозначены зоны видимости/слышимости), планов расположения оборудования и кабельных каналов с привязкой к помещениям;
спецификации (перечня оборудования и расходки); оборудование, понятно расписывается подробно, вкл. все опции - так как оно пойдёт в заказ, расходка по-разному: иногда одной строкой "кабели-разъёмы-инструмент-прочее", иногда подробно "до болта";
таблицы соединений (кабельные журналы) мы обычно не делали: монтажники у нас умные, умеют работать по схемам, заказчику на особо надо, а нам (разрабам) и подавно; но иногда нас просили их сделать, тогда мы делегировали эту работу монтажникам, они отлично справлялись :)
но некоторые части удобно выполнить именно в виде таблицы, а не схемы, например, соединение частей комплекса между собой или IT-шный коммутатор - патч - портебители: тогда схема превращается просто в кучу параллельных линий и смысл в ней теряется - удобнее сделать таблицу;
текстовых документов у нас особо не было опять же в силу особенностей взаимоотношения с заказчиком: всем и так всё понятно; писали пояснительную записку, больше "на отвали"; ТЗ обычно писали совместными усилиями т.к. его требовалось прикладывать к договору;
расчёты - ну разве что потребляемую мощность посчитать.
Простите за нескромный вопрос, но сколько вам лет и работали ли вы в команде?
К сожалению, интересы бизнеса и сотрудника чаще всего разные. При переходе в другую компанию через какое-то время обычному разработчику будет гораздо проще продать свои хард скилы, чем умение решать проблемы говном и палками. Потому что про бизнес value на интервью можно рассказать красивую сказку, а вот умение пользоваться докер-кубер-чудом относительно легко проверяется и без опыта на проде не сильно котируется.
Я постарше и согласен со многим, но парное решение/фиксинг сложных, заковыристых мест парой, если рядом с тобой тоже хороший профи, ускоряет процесс раз 10, если не больше. Но не скажу, что программировать парой надо постоянно.
Соответственно, и освоение «новых технологий» идёт немножко по другому. Пока молодёжь учит новое, я вспоминаю, где я уже с таким работал и как оно там было устроено.
Да, а работу фиг найдёшь — это правда. Только не из-за возраста, а из-за кретинизма рекрутёров. Что-то типа такого:
— Сколько у вас лет опыта работы с Celery?
— Лет? Применял несколько раз, по необходимости. Не каждый раз она нужна.
— Нет, нам нужен человек минимум с 4-мя годами работы с Celery.
— Почему с 4-мя, а не 3-мя или 5-ю? Что такого магического в этой цифре?
— Такие у нас требования. Вы нам не подходите.
Насчёт парного программирования. Не могу сказать, что это общий случай, но я своими глазами наблюдал, как две работающих в паре «бабушки» (как мне тогда казалось) за год наваяли на Клиппере программу полного расчёта себестоимости выпуска изделий (а там и нормирование и технологические карты, и завязки на станки, стоимость вспомогательных и покупных и уйма всего прочего). И изделия были немаленькие — размерами в сотни метров с десятками тысяч составляющих. Потом эти дамы ушли и пришла молодёжь со знанием современных технологий. Молодёжь на протяжении 15-ти лет сделала два подхода, чтобы переписать эту программу на современный лад. Сначала одна молодёжь, потом другая. Когда я последний раз был на том заводе — до сих пор работал клипперовский вариант 20-летней давности.
Я, похоже, недостаточно ясно выразился. Они сидели за одним компом. Пока одна программировала - другая наблюдала. И, разумеется, они постоянно обсуждали, как лучше сделать ту или иную штуку.
Насчёт предметной области полностью согласен. Знания о том, как работает производство там были. К тому же, у обеих высшее образование по специальности "прикладная математика". И оптимизация алгоритмов наверно, делалась ещё в голове, до этапа ввода в комп.
Такие у нас требования. Вы нам не подходите.
Элементарно же. Формально поставленный фильтр работает автоматически и без услилий. Рано или поздно кто-то его пройдет.
неоптимальность формальных фильтров очевидна.
Потому что фактически неформальных фильтров так же много, гораздо больше даже чем формальных. Например, если человек нужен в офис малой транспортной доступности, то автоматически выпадают практически все, кто живет далеко. И в реальности формальный фильтр не проходит никто, так как время не бесконечно. Время, выделенное на поиск проходит, а фильтр никто не прошел. Начинаются поиски со снятием тех или иных фильтров или возвратом к зафильтрованным кандидатам - это еще время и усилия. Времени в итоге тратится больше, чем при неформальном подходе. Такой расчет всегда попытка взять рынок "на хапок". А вдруг? С первого же раза идеальный кандидат...
Пардон коллеги, 4 года с celery будет только через 4 года :)))
"Резюме просто не смотрят из-за возраста..."
Такими ВСЕ будем, а вот про опыт и умения нужно сейчас (лучше даже вчера) беспокоиться.
Резюме просто не смотрят из-за возраста
Это делают недалёкие люди. Сам я никогда не смотрел и не смотрю ни на возраст ни на бумажки. Смотрел, что может человек. А сам на протяжении 50 лет продолжаю программировать, где для удовольствия, а где и по заказу.
такие профи на вес золота должны быть…
Вот потому что "на вес золота" их и не берут. Overqualified, так сказать. Берут то что "на вес люминя, ну, может меди"
Золотейшие слова! Как программист в возрасте программисту в возрасте говорю ))
Коллеги, со всем согласен, но для меня проблема - заставить работать подчиненного на полную мощность. Мне кажется, что у меня нет такого объема задач - я за всех все напишу за неделю и это грустно.
кроме того иногда задачу отдавать жалко..... бесит
"Если сравнивать с более молодыми версиями себя, то, по ощущениям, я на пике. ..., я сейчас умею гораздо больше, чем пятнадцать лет назад, и, надеюсь, гораздо меньше, чем буду уметь через пятнадцать лет" - забавно автор надеется быть в середине возрастающей функции, но по ощущениям ожидает спад
так как все люди разные, то элементарная логика должна бы автору подсказать, что чьё-то видение ситуации не обязано описывать его ситуацию.
как минимум я ваша противоположность, с возрастом я НЕ стал меньше программировать, но я потерял интерес к задачам как к работе, я программирую исключительно для себя любимого и для удовольствия. А на работе пусть молодые кодят как сумасшедшие всякую чушь. И на мой взгляд это логично. Если посмотреть на лучшие умы человечества занимающиеся программированием, то они тоже ушли от кодинга как такового, они скорее занимаются научным программированием (и многие преподают), это куда интереснее, а долбёжка миллиарда ООПэшных конструкций - это для "молодых и перспективных".
Ценится, в первую очередь, профессионализм, а не молодость. Хотя и у нее есть масса достоинств. Автору - респект, уважение и пожелания успехов.
Желание руководить людьми упало до рекордного минимума.
Это следствие "если хочешь сделать хорошо - сделай сам".
Вот когда подчиненные под твоим руководством сдадут крутую фичу, которую в одиночку не осилить - вот тогда прочувствуешь эмоциональный подъем.
Я понял, что если вместо религии принять планету за сервер с миллиардами виртуальных машин, то принципиально ничего не изменится.
Никогда не понимал, за что некоторые люди так не любят слово «фуллстек».
Потому что фуллстеки это вечные середнячки (в лучшем случае). Невозможно на глубоком уровне понимать и фронт и бек. А некоторые еще параллельно за мобильную разработку берутся, и за DevOps - в итоге время и опыт размазывается тонким слоем по всем областям.
С точки зрения создания своего стартапа это отличный путь, но с точки зрения построения карьеры в большом проекте, с большой командой и с большими зарплатами - такое себе.
Я раньше тоже так думал, а сейчас мне все больше кажется, что хороший инженер с чем угодно разберётся. Концепции везде очень похожие, отличаются только детали.
Ага. Только никому не нужны хорошие инженеры. В большинстве объявлений о найме требуются программисты с годами опыта работы в каком-то одном фреймворке.
Имено для этого и нужны общеобразовательные предметы в ВУЗах, чтобы инженер мог разобраться с максимально возможным количеством частных вопросов.
Молодежь в этом смысле не радует. Мне тут на днях студент из МИРЭА доказывал, что раз я умею сортировку написать руками, то я непрофессионал, отстал от жизни, потому что есть библиотеки, и пользоваться надо ими, а у меня в голове куча бесполезной информации. На вопрос, что он будет делать, если столкнется с тем, что нужной библиотеки нет или нужной функции нет, не нашелся что ответить, но "надо изучать новые технологии".
только сегодня у меня в гостях был "линуксоид-разработчик", который не умеет настраивать сетевой интерфейс и не знает что такое виртуализация. Зарплата у него примерно в 7-8 раз больше моей. Сейчас как раз время дилетантов.
Разработчику эти сисадминские премудрости как правило не нужны. Зато он знает то, за что платят деньги.
я правильно понимаю что во всех ситуациях когда ему нужно вбить статический IP он будет вызывать специалиста даже для личного железа? что-то я не вижу смысла НЕ знать такую сложную "премудрость". Даже больше бы сказал, пока изучаешь ОС как таковую так или иначе изучаешь и базовые админские манипуляции - прописать IP, прокси, IMAP и много чего еще.
Не помню уже, когда последний раз доводилось прописывать IMAP, аж олдскулы свело ;) Да и статический IP прописывать нужно примерно никогда. А когда действительно нужно.. Вы же не думаете, что разработчик действительно неспособен вбить 4 группы цифр в окошко Network Manager? Он этого не делал, потому что не нужно было ;)
Если бы умение вписать IP адрес ценилось - соотношение зарплат было бы совсем другим.
Да и статический IP прописывать нужно примерно никогда
Ограниченный мира вокруг вас вы принимаете за сам мир - это неправильно.
Вы же не думаете, что разработчик действительно неспособен вбить 4 группы цифр в окошко Network Manager?
Окошко? Ограниченный мир вокруг вас стал еще меньше.
Если бы умение вписать IP адрес ценилось - соотношение зарплат было бы совсем другим
Причем тут зарплаты?
Я знаю пару человек которые не в состоянии сделать архив ZIP, уж не знаю что именно у них вызывает проблемы, хотя окружение настроено. Такие люди из категории "потому что не нужно" всегда попадают в категорию "идиоты".
Ограниченный кусочек мира, где необходимо эти ip куда-то прописывать, не нужно принимать за весь мир ;)
Причем тут зарплаты?
Надо же привести как то умения к общему знаменателю.
не умеет настраивать сетевой интерфейс и не знает что такое
виртуализация. Зарплата у него примерно в 7-8 раз больше моей.
Умение настраивать сетевой интерфейс ценится 7 раз дешевле, чем умение кодить. В одном из фрагментов мира так.
По моему опыту, фулстеки - самые грамотные ребята, которые понимают то, как работает система целиком, а не только маленькую ее часть. И также по-моему опыту, хорошие программисты достаточно хороши во всем, а плохие плохи даже в своей специализации.
те, кого вы описали, действительно крутые ребята, но.. бОльшая часть фулстеков сеньоров находится на уровне мидла и на фронте, и на беке(свой опыт).
Если они находятся на уровне мидла и на фронте, и на беке, то они, очевидно, мидлы, а не сеньоры
"очевидно" в данном случае не корректно. тк фулстек и бек с фронтом по отдельности - разные профессии, и да, критерии на них разные. не могу сказать насколько они отличаются, но по моему опыту те, кто считает себя фулстак сеньором, не сильно отличается от мидла как в беке, так и в фронте
Фулстек и бек с фронтом по отдельности - разные профессии
Что дальше? Поделим фронтендеров на HTML developers, CSS developers и Frontend-JS developers?
Это не отдельные профессии, а по-прежнему разработка, но само понятие "фулл-стэка" противоречит одному из основополагающих принципов, причем не только именно в разработке - Single Responsibility. Поэтому я скорее поддержу мнение о том, что "Senior Full-Stack" - это по миддлу и на фронте, и на бэке.
"Специалист знает все больше и больше о все меньшем и меньшем, в в конечном счете знает все ни о чем."
но с точки зрения построения карьеры в большом проекте, с большой командой и с большими зарплатами - такое себе.
А что это даст-то, этот большой проект? Карьера программиста обычно сильно дольше чем большинство проектов, если конечно нет желания сидеть где нибудь в военке и 50 лет писать на алголе потому что это надежно. Даже те что еще существуют, с тех что я начинал 15 лет назад, и которые я знал как свои пять пальцев, над которыми работала не одна тысяча человек, сейчас в большинстве своем уже уходят или ушли в out of support, на их место пришли новые.
с точки зрения построения карьеры в большом проекте, с большой командой и с большими зарплатами - такое себе.
С точки зрения построения карьеры - это топ. Фулстек лучше всего подходит на роль лида или CTO. Я тут недавно собеседовал React-разработчиков. У была в конце секция вопросов о всём. О блокчейне, о базах, о деплое, о бэкапах, о синтаксисах языка, о том, как фронт делается на других платформах - qt, Android, iOs и т.д. К моему удивлению большинство толковых фронт разработчиков этим не интересуются. Это нормально. Но как вы думаете, можно ли такого человека поставить рулить проектом?
Фулстек лучше всего подходит на роль лида или CTO
Менеджерские позиции в первую очередь требуют хороших навыков коммуникации. Если они есть - человек и из бека станет тимлидом. Если их нет - то и из фуллстека не станет.
Глупости. Если вы закончили школу с тройкой по русскому - у вас есть достаточные коммуникативные навыки. А вот без хадр скиллов вы не сможете ничем управлять. Это будет лишь иллюзия управления. Как вы будете тренировать команду, если сами не занимались спортом? Давать советы по лечению, если не врач? А слаживать работу профессиональных покеристов, если сами не играли на высоком уровне?
Если вы не разбираетесь в чём-то, то вы можете выступать в роли заказчика, по принципу, а сделайте мне это пожалуйста, сколько это будет стоить? Вам будут называть, сколько это стоит, в людях, деньгах, времени, а вы будете спорить и соглашаться. Но это не называется управление. Отсюда и рождаются шутки, что попугайчика научили говорить: "Ну что там?", и его повысили до менеджера.
Ну, и ещё в дополнение. Один мой знакомый программист говорил, что не любит начальников технарей. У них реально надо работать :)
ну, во первых, в крупных компаниях может быть и не один лид, и вполне возможно разделение на лида управляющего беком и лида управляющего фронтом, но тут немного не так. фулстек - полноценный фронт и бек разработчик, однако для лида нужно лишь понимание концепций и возможностей того, на чем пишут люди с фронта. но это же не полноценный разраб, так ведь?
Все так, но есть и обратная сторона. В частности последние несколько лет столкнулся с тем, что голова откровенно сопротивляется разбираться в бизнес процессах, воспринимая это как абсолютно ненужные и бесполезные знания. Ведь сколько до этого было проектов и голова забита всякой их спецификой. Вот нафига мне сейчас знания о том в каком порядке и при каких условиях подаются вагоны на сортировочную горку или что такое счет NNNN в бухгалтерской книге и почему он пассивный.... В итоге бывает: "блин, ты у нас уже три года работаешь, а до сих пор не знаешь почему ИП-ник не может запрашивать эти данные?" А для тебя это самый ИП-ник это всего лишь объект Юзверь с нужным набором атрибутов на которого повешены нужные ему роли в универсальной подсистеме раздачи ролей, которую ты написал еще на начальной стадии проекта несколько лет назад... И почему именно эти роли, именно такие и именно сейчас - вот вообще не интересно.
Совершенно верно - всё помнить просто невозможно.
В этом случае может помогать хорошее документирование проекта.
Либо просто в коде, либо в системах ведения задач.
Вот нафига мне сейчас знания о том в каком порядке и при каких условиях подаются вагоны на сортировочную горку
Если Вы пишете программу для автоматизации маневровой работы, то как без этого можно обойтись?
не пробовали на проект ввести аналитика? Они именно для этого и нужны. Чтобы программисты думали о коде, а он - о специфике проекта.
Как у них же в их книжках написано - программист это очень дорогой ресурс, а БА дешевле, поэтому лучше снять непрофильные задачи с программиста
Согласен со всем, за исключением того что новые технологии мне все еще не менее интересны чем раньше :)
...совместная работа с людьми, у которых можно чему-то поучиться – отличный источник мотивации...
...постоянно учусь чему-то новому...
И тут же:
Понятия не имею, насколько эффективно парное программирование. Выяснять это нет ни малейшего желания.
Любые модные новинки в сфере разработки я по умолчанию воспринимаю со скепсисом.
...не могу сказать о преимуществах подхода, когда людей собирают в одной комнате, чтобы решить проблему.
Человек не в состоянии понять, что такое мозговой штурм и как это работает? Или это про бесполезные совещания?
Люблю начинать с чувством, что не уверен, как решить эту проблему.
Но при этом
Производительность у меня стала намного более предсказуемой.
Раньше я всегда доводил дело до конца, теперь с удовольствием меню план действий, если меня смущает запах кода или пропадает аппетит.
Как-то всё неоднозначненько. Перевод может такой или это просто я придираюсь и никакой противоречивости нет?
Конечно, каждому своё, но управление людьми - имхо, это тот самый навык, который приходит именно с возрастом. Уже есть понимание того, что обычно не стоит "на скаку в карьер" бросаться на тикеты. Правильно объяснить и делегировать задачу может быть часто эффективнее, чем начать решать её самому.
Программирование - это наркотик)) Хочется самому, а не чтобы кто то за тебя это делал. Вот отчёты за меня писать я бы с удовольствием делегировал.
Мне - 59.
Практически все про меня (кое-где с мелкими оговорками).
Подтверждаю.
Автор везучий, если у него такое понимание "мясистой задачи". У меня мясистая это пара месяцев и я их ненавижу
Мне 54 года, программистом стал в 40, до этого работал на административных должностях, в области радиотехники. Я ничем не отличаюсь от своих молодых собратьев. Я на общих основаниях прохожу собеседования, если нужно освоить новый фреймфорк, я его осваиваю. Получить какую то новую, из неизведанного задачу, я только за, спросить совета у более юного коллеги, если я вижу что он знает тему лучше чем я, да не вопрос. У меня как и у многих есть Pet-проект, связанный с разработкой SDR-радио, я также стремлюсь участвовать в open source проектах. Может я и чем то отличаюсь от более молодых коллег, так это уровнем сахара и артериальным давлением :). Индустрия скоро начнет массово получать 50 - 60 летних программистов, которые хотят и могут кодить. Почему им не работать программистами, если они этого хотят и соответствуют требованиям работодателя?
может потому что в 1990 году я ассемблер изучал за месяц, а потом просто кодил, а сейчас я месяц кодю, а потом вспоминаю - зачем? Я не представляю как сегодня я могу изучить новый фреймворк за адекватное время, лет 5 назад хотел освоить питон, но прочитав 50 страниц уже не смог решить задания, потому что забыл что было раньше. Тот же C# сейчас пользуюсь в обнимку с MSDN и на уровне не дальше Бейсика 80 года, потому что всего так много что в голову просто не влезает.
А я вот тоже немолодой уже дядька 40+, но мне до сих пор нравятся новые подходы, аджайл-команды, дэйлики-митинги-митапы. В молодости очень много программировал парно - это всегда было офигенно. Ну а так - да, некоторые стареют раньше.
Тоже программист уже примерно такого же возраста. Но некоторые пункты - точно не про меня, но всех их можно свести в одну категорию: заниматься этим не то, чтобы пропало желание, но порой скучно, вследствие чего есть желание развиваться уже в других областях. Помимо прочего, именно как разработчик, уже давно ощущаю себя оверквалом на большинстве мест работы по найму. Ни одна задача не уже не вызывает вопросов: а как ее сделать. Все решение видно сходу. Однако некоторые задачи порой все равно бывают интересными хотя бы из тех соображений, которые были автором озвучены: показать молодняку, как надо.
Но минус всей этой истории в том, что действительно зная, как надо, все сложнее становится работать с коллегами, планка качества кода которых ниже твоей. Это, конечно, отдельная очень дискутивная тема: бизнес vs техдолг. Но с кодом посредственного качества работать уже в принципе не берусь. Если, конечно, это не какие-то разовые задачи.
Поэтому лично для себя, если не учитывать развитие в совершенно иных отраслях, или же собственный бизнес, развитие в сфере разработки уже вижу больше в направлении образования/менторства. А если что и писать, то уже только какие-то собственные проекты.
Откровение.
44, и в точку по многим пунктам. Я на пике, мозг шустёр как никогда, плюс много времени экономится на интуиции (которая вроде как компиляция опыта?). 10 лет программирования и архитектуры, 4 года девопса, 8+ дата сайенс, ну и пара заходов в менеджмент - но с неизменным возвращением к коду. Работа интересна и многогранна и надеюсь таковой и останется.
Могу поделиться ощущениями своего опыта программирования и руководителя IT компанией. Программированием занимался в общей сложности лет, примерно, 25. Руководил компанией 13 лет. Руководить полностью разонравилось. Программировать разонравилось на 50%.
В настоящий момент занимаюсь исследованиями, разработка есть, но её свожу к минимуму.
Наблюдения программиста в возрасте