В какой компаниях и отраслях программирования ценят не быстрое, не модное, а работающее как часы?

Question

[beem7]

На текущей работе меня не устраивают:

- Поспешность. Фигак-фигак и в продакшн. Пришел утром на планерку без сделанного - сразу задумались об увольнении. Пофиг, что ты через полдня сдашь, но лучшее.

- Эстетство, а не тщательность. Считают, что код должен быть легкочитаемым, все должно быть кратко, по-модному сделано, ну и DRY, конечно. Новых членов команды иногда дрючат за код-стайл. Но... все как-то наполовину. Идеальный кодстайл все равно соблюдать не получается. И нету единых правил по кодстайлу на все случаи жизни. А сам факт, что я настолько заморачиваюсь, наводит коллег на мысль - не заняться ли мне вместо кода моим психическим здоровьем. Между тем по своей природе я именно стараюсь все делать предельно тщательно... хотя зачастую и не очень красиво, и уж тем более не модно. Насчет читаемости - судя по всему прочитать без труда я могу гораздо более сложный код, чем мои коллеги.

- Баги. Никто их не любит. Но и не делает ничего для того, чтобы их не было. Юнит-тесты весьма неполноценны. Тем более никто не проверяет код вручную как следует. Код на ревью смотрят на предмет вышеописанной "красоты", дикостью кажется им юзать ревью для поиска каких-то багов.
По их словам, на это уйдет целая вечность. Хотя я сам делаю такой ревью минут за 10-30.
Также, по их словам, нет смысла делать что-то особенное для поиска багов, потому что "баги все равно будут". Однако у меня есть опыт работы с заказчиками без команды, и точно могу сказать, что если баги искать, то серьезных багов не будет вообще (за год работы ни одного, а без проверок - несколько), а мелких почти не будет. Даже если делать все в спешке, все равно проверки спасут от любых существенных багов. Я не представляю, как можно не искать баги. Многие из них ведь просто по невнимательности допускаются.

- Любовь к новизне. Я предвзято отношусь к новым инструментам, новым версиям. Например, ненавижу язык Rust - он призван заменить C++, но он же совсем на него не похож! К чему бардак такой разводить? Сегодня еще и узнал, что в последних версиях Rust сломали обратную совместимость, хотя обещали, что она будет всегда. Такие вот случаи просто вымораживают меня. И их тоже вымораживают - но они все равно неустанно обновляют все до новейших версий. Тогда как я гораздо более сдержан в этом.

И насколько я знаю, такое почти во всех компаниях и во всех разновидностях продуктов.
А где не так?

Comments

[Roman K]

Юношеский максимализм из всех щелей. Либо у тебя на работе лютые макаки, либо у тебя синдром
Д'Артаньяна. А вот за раст обидно, идеальный язык.

[beem7]

Roman Kitaev,

Юношеский максимализм из всех щелей

Так я вроде не говорил, что я сильно хороший. Разве что по части багов: там уже просто очевидно, что если чего-то не любишь, то наверное надо с этим бороться, а если кто-то так не делает, то наверно он не очень умный. Ну и в чем тут максимализм? Тем более упомянул свой реальный опыт, где действительно удалось кол-во багов сильно сократить.

Либо у тебя на работе лютые макаки

Макакой считается тот, кто пишет некрасивый код, по-тупому. У нас в команде вообще-то таких нету, но если придираться, то это буду я, а не они.
А вот как организована сама разработка (надо ли все-таки баги искать специально и т.д.) тут можно поспорить, у меня ли это лучше или у них.

А вот за раст обидно, идеальный язык.

Breaking change это конкретная подстава. В C++ такое хоть раз было?
Ну и вообще это сыроватый язык.
А еще он очень мало на C++ похож.

Answer 1

[Сергей Горностаев]

В корпоративном секторе, особенно банковском.

Comments

[beem7]

Можно примеры компаний? И желательно хотя бы краткое описание, из которого видно, как именно там все это выглядит.

[Сергей Горностаев]

beem7, IBM, Amazon, Netflix, Walmart, Ozon, Сбер, Альфабанк, Тинькофф и т.д. и т.п. Системы пишутся годами, а потом используются десятилетиями. При разработке ставка делается прежде всего на надёжность, сопровождаемость и лёгкость найма специалистов. Всё предельно чётко, выверено и стандартизировано. Крупный бизнес деньги считать умеет.

[beem7]

Сергей Горностаев, про лёгкость найма звучит пугающе) это как раз у меня начальство вечно похваляется тем, что меня легко выкинуть и заменить. И то, что я 5 лет тут уже работаю, для них ничего не значит. Ну создал вместе с ними проекты, но они прибыль не принесли (у нас все убыточное и держится на инвесторах). Ну знаю хорошо многое в их кухне - но возьмут другого миддла взамен меня, будут его как меня таскать по разным частям проекта, и он с ничего не понимающей рожей сначала будет тупить и офигевать от потока инфы, а потом освоится и тоже что-то сможет как-то пилить.

Крупный бизнес деньги считать умеет.

Как это понять? Опять-таки, у нас тоже скупость. Как раз у нас и скупость и расчётливость. Именно потому что убыточно и держится на инвесторах. А мне, к слову, это весьма чуждо. Я сам когда что-либо делаю своё, то достаточно щедр, равно как и терпелив в плане сроков. Деньги считать НЕ люблю. Главное - качество.

[Сергей Горностаев]

beem7,

Как это понять?

Стоит отличать скупость от предприимчивости. Не будет тот же Walmart переписывать системы на модных технологиях, если не будет иметь на руках чёткого экономического обоснования того, что каждый вложенный цент принесёт доллар. Зато будет вкладывать ресурсы в архитектуру, читаемость кода, в тесты и прочее, так как знают, что баги - это убытки.

[Северное Сияние]

Всё верно. Сидишь в банке, не напрягаешься, пишешь на легаси, а новые проекты можно и на современных технологиях. Ни сроков, ни дедлайнов. Психика сохраняется более-менее.

Как вспомню иные места работы - та уж нет, лучше тогда водилой устроиться, чем опять каждый день стрессовать.

[Игорь]

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

p.s. не исключает конечно наличие исключений, но попробуй еще угадай где оно есть

[Сергей Горностаев]

Игорь, я прямо сейчас работаю в Сбере. И мне есть с чем сравнивать, за двадцать лет много где и с кем успел поработать.

[Сергей Горностаев]

Северное Сияние, у нас есть сроки и дедлайны, просто они намного разумнее, чем в ритейле например. Овертаймить приходится редко, только когда меняются интеграции без сохранения обратной совместимости.

[Сергей Нижний Новгород]

Сергей Горностаев, насчет нетфликса не согласен. Там зависит от проекта. Ибо было интервью с парнем, что работал в отделе обслуживающем маркетинг нетфликса, он говорил, что там дикие сроки, дикие переработки и жуткое выгорание под таким стрессом;

[Сергей Горностаев]

Сергей Нижний Новгород, в целом как и везде. В банках тоже есть так называемые "перспективные проекты", которые работают в режиме стартапчиков, со всеми вытекающими.

Answer 2

[Валентин]

Прошивки телекоммуникационных устройств, корп сектор, встраиваемся техника, автопром. Если там будет ошибка, придётся отзывать партию. Из примеров наших что сейчас на слуху - инфотекс и код безопасности.

Comments

[beem7]

Так и знал, что я ближе к реальным системам, чем виртуальным. :)
Но увы, в России таких компаний мало, да и по профессии я программист (хотя и инженером мог бы работать, даже несколькими разными сразу, но диплома нет).

[Валентин]

beem7, чем уже специализация, чем вы становитесь профессиональнее, тем меньше подходящих контор. Под мою специализацию вообще четыре компании на РФ.
А так ещё есть ведомственные устройства, камеры фотовидеофиксации, вендинговые устройства, терминалы дистанционной оплаты (да те же банкоматы и паркоматы), бытовая техника (телевизоры например)... присмотритесь, варианты есть

[Северное Сияние]

автопром

ржу

Answer 3

[Василий Банников]

Не совсем понял, в какой вы сфере работаете, но предположу, что вам нужно:
1. Качество результата > Скорости написания.
Тут хочу уточнить, что обычно нормальные люди требуют соблюдения дедлайнов: если сказал, что сдашь в день X, а потом ещё неделю после дня X что-то дописываешь до своего идеала - это не ок.

2. Чёткий кодстайл, подкреплённый конфигами, линтерами и прочим
3. Системную борьбу с багами
4. Без Rust

Вообще по заголовку:
- Банки (и вообще финтех, когда баг привлечёт к большим штрафам либо убыткам)
Если банк - в идеале попасть в отдел с каким-нибудь древним мейнфреймом, который обрабатывает транзакции.
- Медицина
- Транспорт
- Оружие (в идеале ядерное)
- Промышленность (заводы, станки, роботы и прочее. Чем больше вреда здоровью нанесёт баг - тем жёстче правила написания кода)
Если без фанатизма - просто крупные продуктовые компании с устоявшимися практиками (при этом надо попасть в какой-то давно существующий продукт, а не стартап)

PS:

Я предвзято отношусь к новым инструментам, новым версиям.

А зря на самом деле. Обновления призваны улучшить жизнь. В том же кейсе с растом - брекинг чендж был необходим. Да и для самого раста это норма - язык ещё молодой.
PPS: напишите потом, в какую компанию попадёте - я не хочу с вами работать в будущем.

Comments

[Валентин]

PPS: напишите потом, в какую компанию попадёте - я не хочу с вами работать в будущем.

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

[beem7]

Тут хочу уточнить, что обычно нормальные люди требуют соблюдения дедлайнов

Чего ради? Или такой вопрос не ставится, а просто формальность? Не надо писать, что конкуренты уже подсуетятся, сделают быстрее и прочее. Ну не всегда это так. В 2017 году один мне мозги делал, что надо быстро, а то конкуренты обгонят. На тот момент было 2 уже работавших и раскрученных конкурента. Новых не появилось до сих пор. А эти 2 сильно стухли и много плохих отзывов получают.

4. Без Rust

Я его как пример привел. Действительно гадость. Но не он же один - гадость. Питон тоже плох. Питон плох тем, что сильно отличается от большинства других языков, даже не Си-подобный, библиотеки тоже порой реализованы странно, при этом у него нет весомых преимуществ ни в одной из областей. Ладно, когда кодовая база уже написана целиком на питоне - тут просто ничего поделать нельзя (я бы и такое с радостью переписал, но никто не оплатит сотни нефти ради этого) - но когда питон притаскивают в проект на какие-нибудь скрипты деплоя или юниттесты, в проект, где все остальное написано на чем-то другом, то за такую "змеефилию" надо заражать глистами, ящитаю. А вместо питона надо юзать node.js. И для всяких скриптов тоже.

А зря на самом деле. Обновления призваны улучшить жизнь.

Но требуют лишние телодвижения, а в случае багов способны конкретно ухудшить.
Смотря какие обновления. Если новое API добавили, то это норм. Ну не хочешь, не юзай. Я, кстати, обычно хочу, если это C++. А если ломают старое - то плохо.

Да и для самого раста это норма - язык ещё молодой.

А в молодом C++ такое было?

я не хочу с вами работать в будущем

Если вы сеньор и выше, то правильно делаете. Я миддл, то есть по отношению к вам я был бы галерный раб, так вот я отвратительный галерный раб. Кроме вышеперечисленного еще люблю выносить мозг всем. В данном случае имеется в виду, что делаю это именно целенаправленно.

[beem7]

Валентин, да не, если он выше миддла (а я миддл) то реально все плохо. Потому что галерный раб из меня - из рук вон.

[Василий Банников]

Валентин, это легко можно найти на моём аккаунте в хабр-карьере)

[Василий Банников]

beem7,

Чего ради?

Я специально добавил приставку "нормальные" и упомянул "если сказал, что сдашь в день X".
Это просто нужно для планирования - чтобы не продолбать сроки из-за нехватки ресурсов.

питон ... даже не си-подобный

Думаю, вам лучше не показывать haskell в такой ситуации, там вообще ужас.

при этом у него нет весомых преимуществ ни в одной из областей

Но при этом и другие языки не могут занять его нишу. Это и есть его преимущество.

но когда питон притаскивают в проект на какие-нибудь скрипты деплоя или юниттесты

Юниты в 99% случаев пишутся на исходном языке. Не юниты пишутся на том, на чём удобнее. Видимо в этом случае удобнее было на питоне.

А вместо питона надо юзать node.js. И для всяких скриптов тоже.

Крайне спорный момент, надо рассматривать конкретные случаи. Лично мне кажется, что питон будет всё-таки удобнее ноды.

А в молодом C++ такое было?

Если честно - не знаю. Молодой C++ и не ставил себе тех целей, что ставил раст. Иначе бы в C++ сразу бы отказались от обратной совместимости с си (имхо)

Если вы сеньор и выше, то правильно делаете.

Пока ещё нет )

то есть по отношению к вам я был бы галерный раб

Кажется, у вас непонимание термина "галера". Ну и сеньёр не всегда руководитель.

[beem7]

Василий Банников,

Это просто нужно для планирования - чтобы не продолбать сроки из-за нехватки ресурсов.

А жесткие сроки опять-таки зачем? Немецкая оборонка (разумеется, в мирное время) разрабатывает танки по 30 лет. Если в этих танках есть ПО (а оно наверное там есть), то зачем ставить сроки сделать все за неделю?

Но при этом и другие языки не могут занять его нишу. Это и есть его преимущество.

Нишу мелких скриптов, как эти юнит-тесты, легко могут. Тот же Node.js. Кто-то предпочел бы PHP...
Микросервисов (и не микро- тоже, ну всякие там flask, django) - легко может что угодно занять, начиная от Node.js и заканчивая C++, если иметь соответствующие разработки в сфере HTTP-фреймворков (а я и такое встречал).

Юниты в 99% случаев пишутся на исходном языке. Не юниты пишутся на том, на чём удобнее.

А правильно писать их на том языке, на котором будет дергаться код.
Ну если это тот самый сервис на C++, а дергаться он будет браузером на JS, то:
- в идеале юнит-тесты должны быть на браузерном JS, тогда не будет такого, что автор сервиса сделал в нем прием по HTTP данных в неком формате, тестировщик написал на это тест на питоне и тот работает, а потом оказалось, что фронт-енд под это не написать, потому что такие данные не может отправить браузерный XHR и все что на его основе.
- ну или хотя бы на Node.js, чтобы не вводить лишний язык. Почему не на C++? Потому что тесты относятся к "внешней группе", так сказать. Надо, чтобы их мог прогнать не только автор кода, но и член команды, которая будет писать фронт-енд, дергающий этот сервис - а фронт-енд на JS.

Видимо в этом случае удобнее было на питоне.

Нет. HTTP-запрос можно в любом языке отправить. И чекнуть разные значения в ответном JSON тоже. Питон в этом плане ничуть не лучше Node.js.

Кажется, у вас непонимание термина "галера". Ну и сеньёр не всегда руководитель.

Но судя по компании, где я работаю, сеньор всегда ценится больше и это минимальная должность с которой обращаются по-человечески - не ставят вечно вопрос об увольнении, не наваливают кучу работы и т.д. Похоже, сеньора нельзя уволить или выжить из команды, ибо это отразится на репутации перед инвесторами (весь процесс на виду у них), а вот джуна или миддла, особенно без диплома и особенно "вайтишника" (если понимаете, кто это такой) - запросто.

[Василий Банников]

beem7,

зачем ставить сроки сделать все за неделю?

Я же говорю - для планирования и предсказуемости. Нет никакого смысла в планировании и предсказаниях, если они никогда не сбываются.
Например допустим что у нас галера и пришёл заказчик:
Менеджер идёт к разработчикам и уточняет, когда они закончат свои задачи и смогут приступить к новым.
Потом просит оценить затраты времени.
Потом менеджер берхт эту оценку и идёт заключать договор с заказчиком "так-то так-то. Вот мы оцениваем ваши проект в такой-то срок. Обязуемся выполнить к такому-то дедлайну, иначе неустойка x% от стоимости".

Про юниты я это и имел в виду.

Ну видимо тут всё-таки автору тестов было удобнее на питоне.

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

Правда не во всех галерах так

[beem7]

Василий Банников,

Потом менеджер берхт эту оценку и идёт заключать договор с заказчиком "так-то так-то. Вот мы оцениваем ваши проект в такой-то срок. Обязуемся выполнить к такому-то дедлайну, иначе неустойка x% от стоимости".

Мысли глобально. А заказчику зачем этот дедлайн в таком жестком виде? Я уже два проекта тебе в пример привел - сначала некий проект приложения. потом проект танка и входящих в него программных модулей. Во всех этих проектах не было надобности в жестких дедлайнах.

Ну видимо тут всё-таки автору тестов было удобнее на питоне.

Питоны и прочие глисты в нашей команде живут в сеньоре. Если бы этот сеньор написал эти тесты и всегда только он их писал, то хз, может даже оно и норм (ведь уволить его трудно и вряд ли потом их придется писать мне), и радость от того, что тесты на мой код пишет сам сеньор как жалкий студент, перекрыла бы страх, что в процессе написания тестов он обнаружит у меня не сделанное в срок или некую ошибку, за которую мне будет выговор.
Но он, сука, заставил их писать меня. На питоне. Итого у меня: C++, JS, Python.

[Василий Банников]

beem7,

Во всех этих проектах не было надобности в жестких дедлайнах.

Это только так кажется. Я же уже третий раз повторяю - это нужно для планирования. Без планирования ты не можешь нормально распределить ресурсы.
Вот на примере того же танка - пусть есть разработчики какой-нибудь системы наведения башни (я не специалист в танках) и есть разработчики самой башни.
Разработчики башни заявили "мы разработаем спецификацию API управления башней в сроку X"
Менеджер проекта берёт этот срок и планирует "так. Значит до срока X пусть разработчики системы наведения делают что-то ещё, а потом они должны освободиться и сесть изучать спецификацию"
В итоге к сроку X разработчики башни ещё нифига не сделали. А у разработчиков системы наведения работы нет - в итоге команда простаивает, а простой = траты денег.
Если бы разработчики башни заранее предупредили МП о задержке - простой, возможно, удалось бы минимизировать.

[Fafhrd]

Василий Банников,

Потом менеджер берхт эту оценку и идёт заключать договор с заказчиком "так-то так-то. Вот мы оцениваем ваши проект в такой-то срок. Обязуемся выполнить к такому-то дедлайну, иначе неустойка x% от стоимости

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

[beem7]

Василий Банников, опять мыслишь недостаточно глобально.

Разработчики системы наведения, во-первых, могут начать изучать API еще до того, как оно полностью релизнуто. И даже должны. Потому что "изучение" - это тема, на которую обычно специально времени не выделяют, и как только они официально получат API, в первый же день они должны будут уже что-то на нем сделать и отчитаться на планерке. А изучить API менее чем за день может быть нереально.

Во-вторых, могут делать что-то еще, пока не готово API.

В-третьих, это армия, HK G11 мне в зад! Простой в армии - это что есть? На блицкриг против России дано 6 месяцев, а армия захватила Россию за 3 месяца, мало того, еще и выполнила в этот срок другое задание - скормить Гвидо ван Россума анаконде. А дальше что? Простой.

В-четвертых, что, если команда таки всего одна?

[Северное Сияние]

А зря на самом деле. Обновления призваны улучшить жизнь.

чушь собачья
эти обновления только гробят всю индустрию, заставляя разработчиков как белка в колесе крутиться
если ты еще вчера из яйца вылупился, то не надо писать вещи, которые являются истиной только на хаброчке

нормальные люди требуют соблюдения дедлайнов: если сказал, что сдашь в день X, а потом ещё неделю после дня X что-то дописываешь до своего идеала - это не ок.

это чувак, который плитку кладет или кирпич может сказать объективно о дедлайнах, а в разработке дедлайн -- полнейшая глупость, ибо профессия не шаблонная и не поддается точной оценке

напишите потом, в какую компанию попадёте - я не хочу с вами работать в будущем.

с вами я бы тоже не стал работать. очередной фанатик

[Василий Банников]

beem7, а они не могут. Те задачи переложили на другой срок/другие команды. И они не могут делать ничего другого кроме как сидеть и чаи пить.
А документация не готова вообще ни в каком виде.
Ну и военный сектор - не армия и вообще пример абстрактный.

А если не одна?

[Вячеслав Шиндин]

Более 15 лет в разработке, но не могу вспомнить чтоб я так же когда-либо ныл а плане претензий менеджмента по поводу соблюдения сроков, качества кода и т.д. к себе.
Как раз таки понимаю, что когда на меня давят сверху, то вероятно где-то и моя вина в этом, и нужно проанализировать что я делаю не так, а не скидывать вину на других.

[beem7]

Вячеслав Шиндин, может у тебя руководство нормальное. И если 15 лет, то джуном\миддлом ты был довольно давно, тогда технологии были проще, доллар стоил 30 руб, кризисов не было...
А в моем случае, я уже устал анализировать, в чем же моя проблема, и пришел к тому, что просто сплю я по ночам, в этом и проблема неуспеваний, а надо бы работать без сна :)

[beem7]

Василий Банников,

А документация не готова вообще ни в каком виде.

А почему так работают, что сначала API целиком пишут, потом документацию целиком? А если их цунами смоет аккурат по окончанию API, то кому-то придется весь код разобрать, прежде чем хоть какую-то инфу дать пользователям API? Я например делаю это параллельно.

[Василий Банников]

beem7, ну это ж абстрактный пример, камон. Просто придумал абстрактную блокирующую задачу, без которой нельзя продолжать работу.
Ну и блокеры могут не только между команд возникать, но и между отдельными разработчиками.

[Василий Банников]

Северное Сияние, ну раз обновления гробят индустрию - почему тогда все не пишут на том же коболе, например? Вот уж язык не обременённый новыми версиями

[beem7]

Василий Банников, только вот первый пример проекта (приложение из 2017 года) разрабатывался одним человеком. Мной.

[beem7]

Василий Банников,

ну раз обновления гробят индустрию - почему тогда все не пишут на том же коболе, например?

Про гробят сильно преувеличено. Даже если "создают постоянные баги. которые мешают юзерам и не сразу фиксятся", то это еще "не гробят". "Гробят" - это когда проекты разоряются. А чтобы они не разорялись, могут быть нужны вовсе не те вещи, которые нужны для идеального качества, надежности и т.д. В этом и есть причина того почему всё везде такое неидеальное.

[Василий Банников]

beem7, если вы в заказной разработке, то видимо проблема в менеджере, который наобещал какой-то срок на основе ваших же рассказов о том, сколько вам нужно времени

[beem7]

Василий Банников, нет, проблема в тех кто этот срок требует с менеджера. Ну наобещал, ну не успели, дальше-то что?

[Василий Банников]

beem7, а в чём тогда смысл сроков, если их игнорировать? А если в договоре сроки зафиксированы?

[beem7]

Василий Банников, ну типа "вероятно, к 25 апреля это будет". Если не выходит к 25 апреля, то к 15 апреля. Разумеется, такое не должно быть многократно и надо именно сразу на 15 апреля перенести, а не говорить каждый день: "завтра, завтра, завтра" и так вплоть до 15 апреля.
А вообще да, мало смысла. Далеко не везде стоит так уж торопиться. Лучше перепроверить и т.д.

[Вячеслав Шиндин]

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

[beem7]

Вячеслав Шиндин, ничего личного, но ты написал полнейшую чушь.

когда ты находишься постоянно в зоне дискомфорта

... ты выгораешь.

когда всё гладко и ровно, ты деградируешь или топчешься на месте

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

на тебя сверху давят, значит есть какая-то проблема, попытайся её понять и устранить, извлекай из этого пользу

Проблемой может быть твоя потребность в сне и отдыхе. Есть и такие "давильщики". Устранить? Возможно наверное, но потом будет кароси или просто инвалидность, скажем в результате инсульта.

[Вячеслав Шиндин]

beem7, какие-то отмазки.
Более 15 лет работаю в сфере программирования, был момент когда выгорел после 4 лет работы в этой сфере, это было в 2009ом, но я переосмыслил своё отношение к работе и через пол года вернулся в строй.
Сейчас довольно часто приходится сталкиваться с проектами, которые нужно вытаскивать из хренового положения после разработчиков, которые как только сталкиваются с проблемами, не пытаются их решить а бегут в другие конторы.

[beem7]

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

Ну, если денег совсем мало, то проект пойдет искать одиночку-исполнителя на фриланс. И кстати, это тоже тот вариант, когда по-настоящему хорошо программист не может сделать. Ну вот хотят они за 50 тыр получить то, за что обычно платят 100 тыр, а то и 200 тыр. Ну не может программист в таком случае выдать качественный результат. Это проблема , и ее никак не решить. А если они платят за это не 50, а всего лишь 10 тыр (да, бывает и такое) то у него возникнет вообще проблемища: как можно прожить на 10 тыр все те человеко-часы, которые он на эту работу потратит. И как ты это решать будешь, не бросив такого заказчика?)))))

А вот если денег побольше у проекта, то ему надо адекватно их распределять. А он может распределять их неадекватно. Тимлиду - 200, сеньору - 150, джуниору - 50. А как правильно? Тимлиду - 0, сеньору - 0. Знаешь, почему? Потому что за то, что человек лид или сеньор, не надо вообще ничего платить. Надо платить за работу. А если только "за стаж" платить, то будет такой тимлид или сеньор, который за эти деньги вообще нихрена работать не будет, а только ставить задачи джуниору, и выносить ему мозг, когда тот не успевает. Как думаешь, может 1 человек работать за 3 и при этом нормально себя чувствовать? Чтобы это проверить, попробуй поработать в 3 проектах, пусть даже нормальных, в каждом из которых ты делаешь работу только за 1 человека. У тебя получится работать в 2 таких проектах, если ты будешь работать 14 часов в сутки. Все 3 проекта ты теоретически успеешь, если будешь работать 20 часов в сутки. Практически ты уже через месяц такой работы станешь нуждаться в том японском будильнике, который убегает в угол, потому что обычный тебя уже не разбудит. То есть выгоришь насквозь, и будешь уволен. Я, кстати, в таком режиме проработал целых 3 месяца, ну а потом таки выгорел насквозь. Давай, смейся над написанным.

P. S.
Для программиста с 15 летним стажем ты дилетантоват и розово-очковат. По тебе скорее скажешь, что 15 лет - это твой возраст. Вот в 15 лет я действительно думал, что работа программиста - это рай и никак иначе... Нет, программировать я уже тогда умел. А вот видеть в людях и работах говно - еще нет.

[Вячеслав Шиндин]

beem7, странно слышать такое про себя. У меня диплом по государственному образовательному стандарту "Программное обеспечение вычислительной техники и автоматизированных систем" был получен с похвальной грамотой за особые успехи в изучении информатики и программирования. Участвовал в различных олимпиадах по программированию: районных, городских, региональных, международных. Занимал призовые места. Участвовал в летних школах по программированию от ИСИ СО РАН. Посещал воскресные курсы по решению олимпиадных задач и т.д. И большую часть времени после получения диплома я варюсь в коммерческой разработке (в том числе и в гос. проектах), развиваюсь, читаю книги и экспериментирую в после рабочее время, в отличии от большинства коллег, которые ровно в 18:00 тикают с офиса. На данный момент моя должность "Ведущий инженер-программист".

[beem7]

Вячеслав Шиндин, ну и опять ты на школьника и студента похож. Какие-то олимпиады, летние школы, дипломы. Только студент и будет этим хвастаться... Или человек с мозгом студента. А про работу, и про то, чем же обусловлена святая уверенность в правоте любых сеньоров и лидов, - ни слова. Разве что упоминание о каких-то "гос. проектах". Ну, я тоже в гос. проекте однажды работал, но не хвастаюсь этим, да и особо нечем там хвастаться, негос. проекты в моем случае были сложнее намного.
Может тебе повезло с сеньорами, лидами. Но факт тот, что реальность ты не знаешь.

[Вячеслав Шиндин]

beem7, Про дипломы и прочее я упомянул только потому, что эта информация должна была донести о том, как человек относится к делу в целом. В работе проявляю такое же усердие, как и когда-то проявлял в учёбе. Дело не в дипломах, я в своём первом сообщении лишь вскользь упомянул о своём стаже, лишь для того, что бы было понятно, что я не с луны свалился и имею некоторый опыт. Вы же тут же зацепились за это и начали пытаться что-то доказать мне о том кто я и где моё место, при том, что сами не заметили даже что изначальный вопрос поставленный Вами содержит ошибку (это уже сигналит о вашей не внимательности), это во-первых. Во-вторых, с деловым этикетом похоже Вы тоже не в ладах, т.к. чувствуется в Ваших сообщениях какая-то агрессия и не уважение.
А по поводу Вашего изначального вопроса:

В какой компаниях и отраслях программирования ценят не быстрое, не модное, а работающее как часы?

Один мой давний знакомый программист и преподаватель информатики в НГУ говорил мне по поводу допущения багов в таких системах, которые должны работать как часы о том, что цена бага в данном случае - это человеческие жизни. Он тогда занимался разработкой, если не ошибаюсь, как-то связанной с диспетчеризацией европейского железнодорожного транспорта. Сейчас он работает в OpenLink Virtuoso и состоит в рабочей группе консорциума W3C по части семантической паутины (Semantic Web). Попробуйте у него пособеседуйтесь, https://www.linkedin.com/in/ivanmikhailov/

[beem7]

Вячеслав Шиндин,

У говорил мне по поводу допущения багов в таких системах, которые должны работать как часы о том, что цена бага в данном случае - это человеческие жизни

Вот видишь. А ты к ошибке в моем вопросе придрался. Да, я не очень проверяю свои посты на отсутствие ошибок. И деловой этикет у меня тоже такой - где надо - там на высоте, где нет - там вот как с тобой.

Answer 4

[nApoBo3]

Обычно у таких компании есть другие недостатки. Это то, что их системы представляют из себя крайне сложный в поддержке легаси код, с большим кол-во сомнительных архитектурных решений или сложных оптимизаций. Плюс кучей дублирующего кода и паутиной зависимостей, поскольку часто проще написать рядом, чем разобраться с написанным.

Comments

[beem7]

с большим кол-во сомнительных архитектурных решений или сложных оптимизаций.

Это, наверное, для меня норм.

Плюс кучей дублирующего кода и паутиной зависимостей, поскольку часто проще написать рядом, чем разобраться с написанным.

Это вряд ли. Лишних сущностей не люблю. А, собственно, с чего бы там так было? В моем вопросе среди прочего есть точка зрения, что нечитаемого кода вообще не очень-то и бывает. Ну так и что тогда мешает разобраться?

[nApoBo3]

beem7, не читаемый код это не код который невозможно прочитать. Это код который в следствии использования сложных конструкции, циклов, ветвлений и декомпозиции требует для своего анализа держать в голове существенный участок, что приводит к значительному падению скорости работы с таким кодом, а так же растет вероятность ошибок. Часто программисты начинают частично дублировать функционал такого кода в своих "зонах" ответственности, поскольку проще написать самому кусок, чем внести изменения ничего не сломав.

[beem7]

nApoBo3, не мой подход. Во всяк. случае если спешки нет. Или предусмотрена проверка проделанной работы и отведено на нее время. А я написал, что предпочитаю именно когда это так.

Answer 5

[Владимир Коротенко]

Смотрите AUTOSAR и MISRA

Кроме этого не упомянули медицину и науку.

Но сразу хочу заметить, там такой лохматый легаси что вот эти машинки еще используются
https://ru.wikipedia.org/wiki/IBM_System/390

Answer 6

[Пума Тайланд]

Да везде где продакшен дорогой, упало там на полчаса все потеряли сто тысяч баксов и сразу всем накрутили кто любит сразу в продакшен

Answer 7

[Северное Сияние]

В Яндекс вбей "Выбор правильного места работы или как работая программистом не умереть от инфаркта", или ссылка в моем профиле, там найдешь, на сайте. И вообще тот сайт почитай, много нового поймешь для себя.

В какой компаниях и отраслях программирования ценят не быстрое, не модное, а работающее как часы?

везде, где нет промышленного программирования. Как только оно появилось, разработка на заказ, скажем так - вся индустрия катится в УГ.

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

Comments

[beem7]

Несколько радикальный подход у тебя.

Я не люблю работать мало. Все пункты в списке не столько про спешку, сколько про саму организацию работы в команде. Когда я работаю напрямую с заказчиком, я тоже делаю много, делаю быстро. Но:
- меня никто не увольняет за локальные неуспевания. Я сам прекрасно понимаю, что они плохи. В команде я это тоже понимаю. Однако руководство команды считает нужным вставить свои пять пендалей.
- к коду никто не пристает. Опять же, я избегаю нарушений DRY и других нехороших вещей. Но когда без этого никак - значит оно будет, пока я его не исправлю, и никто не скажет "ну да, дедлайн неделю назад, но ты сделай вот здесь нормально, здесь, здесь, здесь и здесь".
- по багам я сам решаю. Если мне норм, чтобы меня в них заказчик тыкал носом, то не проверяю. Если же эту часть кода нужно проверять хорошо, иначе можно устроить такое, что у заказчика все рухнет и он может больше не захотеть со мной работать - то я проверяю, нахожу на это время, нахожу на это силы и локальные дедлайны не заставляют меня экономить на проверках.
- новые технологии, новые версии зависимостей я внедряю обычно тогда, когда я это хочу. Или когда это прям необходимо. Как правило это терпит сколько-то времени, а не делается спонтанно.