Comments 174
В белорусском языке есть красивое слово — перемога
перамога вроде бы
По клавишам пальцы бегут,
Но мыслей несытная свора
Забыться никак не дают
Был молод, а ныне к закату
Текут моей жизни года.
И хоть получаю зарплату,
Не жду ничего, никогда.
Вот смотрите, снижение скорости когнитивных процессов обычно происходит годам к 50 — 60. И тут есть как негативные факторы, вроде болезней или образа жизни, когда большую часть времени человек проводит, почесывая пах, и развалившись на диване, так и позитивные, вроде постоянного самообразования, поддержания физического тонуса упражнениями. То есть, влияние возраста преувеличено.
С другой стороны, беспокоить может вопрос о скорости обучения и как следствие постоянное отставание от «молодых и дерзких». Но это, опять таки, следствие когнитивных искажений. Если условно разделить программирование на компетенции, позволяющие поддерживать актуальный уровень профессионализма, то можно отметить следующие навыки и знания: во-первых, знание синтаксиса и API тех или иных библиотек языка, во-вторых, умение моделировать абстракции и связи между ними (читай архитектуру), ну и в третьих, способность поддерживать эти знания в актуальном состоянии.
Первое достигается практикой и, неожиданно, чтением документации. И практикой. Тут возраст вообще не играет никакой роли.
Со вторым дела обстоят чуть сложнее, в том плане, что все вроде бы понятно, но что делать, не вполне ясно. Фактически это означает чтение книг о тех или иных парадигмах программирования, алгоритмах, паттернах и антипаттернах. Применение этого на практике. Ну и чтобы все это ложилось на благодатную почву, имеет смысл удобрить ее Computer Science. Благо, информации — куча. Я, например, просвещаюсь на Лекториум. И самое радостное, парадигм, да и вообще фундаментальных знаний, конечное количество. А важно тут вот что, если человек не просто сидел, почесывая пах, а на протяжении жизни хоть как-то самообразовывался, то у него не возникнет проблем с освоением абстракций и парадигм. Способность мозга к моделированию не линейная, а кумулятивная. Для примера, попробуйте открыть учебник по любому предмету класс эдак за 7. Фактически, это брошюра на 150 страниц, которая читается за вечер. Чему там учить целый год? Но это особенность нашей психики, когда человек моложе, его «банк моделей» не такой большой, чем старше человек, тем у него больше возможностей к опосредованному осознанию. Это чем-то напоминает алиасы. Когда мозг собирает понимание новой модели, через кусочки уже понятых, через аналогии. Мне, например, именно расширение своих способностей к абстрактному мышлению и моделированию, представляется самым трудным. Но и тут, я вижу определенные плюсы в том, что меня не накрывает гормональной волной, которая толкает совокуплять все что движется (по крайней мере не так сильно как в 18). То есть, позволяет выстроить процесс самообучения более последовательно.
Ну, и как только синтаксис будет изучен, а новая книжка с описанием архитектуры будет восприниматься легко даже при чтении по диагонали, для поддержки знаний и навыков необходимо будет всего лишь читать draft'ы, обсуждения на git'е, ну и хабр, естественно.
Единственное, что может потребовать усилий, так это убедить сотрудника hr отдела, что вы более чем подходите для этой должности. И если ни ваша компетентность, ни низкая мобильность в плане смены места работы, ни ваша предрасположенность к открытому обсуждению сложностей не могут перевесить чашу весов конкретного hr'а, то стоит задуматься, а действительно ли вы хотите работать в такой компании, и уж точно не стоит экстраполировать один случай предвзятости на все компании.
Сейчас мне это представляется так, но тут может сказаться недостаток опыта.
Способность стройно и развернуто излагать свои мысли на недостижимом для меня уровне. Это уже жирный плюс в карму и подписка. Публикуйте статьи в копилку портфолио.
Последуйте моему примеру, скопируйте какой-нибудь популярный проект. Через ступеньку юниора можно просто перепрыгнуть. Навыки приходят очень быстро на практических занятиях. Опять же лишняя строка портфолио.
Резюме — это набор ключевых, чтобы пройти буфер HR, и попасть к технарям, которые принимают решение о трудоустройстве. А там уже очень пригодится портфолио.
Помимо знаний синтаксиса и алгоритмов, важен накопленный об'ем индекса информации в предметной области. Меня раньше называли "мудрый филин" по этому параметру.
Прорешал несколько курсов на stepic.org (C++, Java, Python ...), по двум получил сертификаты (по Java даже с отличием). Хотел бы дальше развиваться по ветке Java. Буду признателен, если кто-нибудь посоветует минимум объёма знаний по Java для устройства на позицию Juniora. То есть не в общем, а вот если бы вы проводили собеседование, то на какие вопросы нужно обязательно ответить и какие задачи решить, чтобы быть принятым?
Для рабочей визы за бугром тоже требуется диплом. На перспективу. Вы уже в лучшем положении!
Смотря в какой стране. Я без диплома работаю в Нидерландах. И плевали они на наши корочки.
Интересно узнать подробности. По рабочей визе?
Вот описание одной части обучения:
Там очень много задач.
Во первых прокачиваешься по теме, которую прошел.
Во вторых набор кода. Там бывает задачи идут подряд, и можно вроде скопипастить с предыдущей задачи часть кода, но специально набиваю, вспоминаю заново. Реально чувствуется как запоминается лучше.
Мне 40 лет. 18 лет сисадмин. Пытаюсь свитчиться в dev-ы.
Есть компании, которые смотрят на знания технологий аля чем отличается абстрактный класс от интерфейса, зачем нужны синглтоны или аннотации в Spring, как работает сборщик мусора в Java.
Есть те, кто любит спрашивать алгоритмы и структуры данных, например, расскажите, как устроена хэш-таблица внутри.
Не забывайте про общую адекватность, не впадайте в негатив, если чего-то не знаете, будьте честны.
Все получится.
Удачи.
Разница, как правило, в том, что для Junior'a окей ответить не на все вопросы или не ответить глубоко, а просто знать, что вот есть такая штука и примерно понимать, зачем это нужно.
Есть вопросы, которые бессмысленно спрашивать у начинающих, например, про архитектуру, организацию деплоймента, анализ ошибок.
А все остальное — можно.
Хм, может написать небольшую статью на тему программерских интервью, интересно будет?
Ну, понимаете, есть довольно большое количество мест, где вопросы задают не потому, что им надо от кандидата именно это, а потому, что сами знают на них ответы :). Поэтому junior или нет — не особо важно. Чем отличается абстрактный класс от интерфейса не важно вообще никому, кроме проектировщиков внешних интерфейсов библиотек (да и знать там нечего — интерфейс, это, в первую очередь, контракт, а абстрактный класс — это один из способов реализации некоторой идеи, остальное — следствия этого). Как устроен хэш-мап не нужно никому тоже, но это вопрос очень популярный, поэтому изучите его хорошенько — на хабре были статьи и по исходникам можно полазить. С точки зрения претендента это хоть и бесполезный, но очень хороший вопрос — он предсказуемый, несложный и путём небольшой манипуляции можно подтолкнуть интервьюера вам его задать :), потом блестяще ответить и получить благоприятное от себя впечатление. Вокруг этого вопроса есть несколько связанных предсказуемых, которые тоже нужно выучить и успешно переводить интервьюера с одного на другой (да он и сам это сделает) — я имею в виду про hashCode и equals — когда их надо переопределять, зачем и почему и то и другое вместе.
А совет ходить на собеседования абсолютно правильный, это даст вам и психологический опыт и направление что подучить — запоминайте вопросы, потом их тщательно изучайте.
Про то как работает сборщик мусора — не парьтесь. Современные устроены довольно сложно и за редким исключением знание это вам ничего не даст. Поэтому с практической точки зрения прочитайте что-нибудь про какой-нибудь простой вариант сборки мусора и на вопрос так и отвечайте, — реальный сборщик сложный и их периодически меняют/улучшают, поэтому как устроен текущий реальный не знаю, но могу рассказать как мог бы быть устроен один из вариантов простого сборщика мусора. А лучше пара — тогда есть повод продолжить беседу в сторону сравнения вариантов и обсуждения недостатков.
Тоже самое. в 27 с подачи XaocCPS узнал c# + asp.net mvc, последние 5 лет в админ в хостингах, пишу свою панель управления хостингом приложений на рельсах. первый важный кусок по управлению доменами уже проходит внутреннее тестирование, скоро буду выпускать в дикий мир :)
сейчас мне 33.
Регулярно ловлю себя на мысли, что яйца курицу не учат.
Молодые охотнее помогают, в стремлении к доминированию.
Кстати, это один из основных рисков найма «возрастных» членов команды — что они просто не впишутся.
Не обладая техническими компетенциями, они могут все равно стремиться занять лидерскую позицию, потому что жизненного опыта у них больше.
Возможна и обратная история, когда они зажимаются, их Эго начинает страдать.
Например, они накосячили и им что-то объясняют, это воспринимается, как нравоучение.
Или когда повышают более молодого коллегу, который как бы еще «зелен».
Не уходите в негатив и все получится, удачи вам!
Регулярно ловлю себя на мысли, что яйца курицу не учат.
Приходилось работать вместе с более старшими, так и собеседовать более старших.
Так вот, обычно дело обстояло немного не так. Не яйца курицу не учат, а курица наотрез отказывается воспринимать яйцо.
Просишь человека вежливо, не ссылаться из базового класса на функционал класса, который его наследует. "Да. Понял. Окей" и продолжает делать по-своему.
Просишь не лепить цепь вызовов один за другим или хотя бы пояснить комментарием, что это за лютое колдунство он написал в одну строчку. "Да. Понял. Хорошо" и продолжает по-старому.
Полное отсутствие любого желания что-нибудь улучшить или хотя бы понять, почему от него хотят читаемый структурированный код.
Дедушка на собеседовании, когда его попросили написать код с определёнными требованиями, вообще чуть не набросился на нас с криками, что он всегда работает по своему и что даже своему текущему работодателю не позволяет указывать, как ему писать код. Естественно ему вежливо отказали.
Практически всё старшее поколение, с которым я имел дело, страдало от какой-то косности ума и неприятия новизны. Я не верю, что это неизбежно, скорее всего это результат отношения к себе, когда ты смолоду ищешь зону комфорта, не приучая себя постоянно учиться, а всегда пытаешь найти костыль, чтобы убежать от лишней работы. В итоге, когда ум уже не такой быстрый появляется страх всего нового, на что требуется тратить время.
Если вы, будучи в почтенном для кодера возрасте, этим не страдаете, то думаю вас с радостью примут во многие коллективы.
Страдаю, конечно. Я тоже из костей и мяса. Стараюсь не винить себя за косяки, но делать выводы на будущее.
Также значительный эффект — giver-taker и взаимотношения в модели Дрейфуса.
Таким образом отсутствие понимания проблемы коммуникации, мотивации ее преодоления и просто опыта и желания обмены знаниями между представителями разных категорий (в обе стороны!) — делают сотрудничество неэффективным или невозможным, как следствие — низко-производительным или даже таким, как описано с басне «Лебедь, рак и щука».
Что-то странно звучит. У вас запрещено использование абстрактных базовых классов?
Я еще не стар, но уже и молодым себя не считаю. Часть новых технологий и изменений мне нравятся, часть я считаю «шумом», которые потеряет популярность раньше, чем я очередную итерацию завершу. Я например помню истерию относительно патернов и модели предметной области, монструозные диаграммы классов, запутаный код. Потом пришла мода на микро сервисы и максимально простые модели. И тоже прошла. Но людей приверженных разным школам осталось полно, хуже всего когда кто-то свято верит в свой подход. Мол вот если будем использовать анемичные модели, то все, успех гарантирован. Или там ТДД залог успеха. А кто-то все еще делает водопад и согласовывает по месяцу ТЗ на компонент которые за месяц можно написать, продать, переписать и еще раз продать. Когда-то и я бросался в омут холиваров разных методологий и технологий, сейчас я отношусь к этому вопросу по спокойней, мое личное мнение — это вообще все не важно, по всем методологиям полно как успехов так и провалов.
С другой стороны, конечно есть зона комфорта, я вот при наличии выбора и куска хлеба не пойду в команду, в которой фигурную скобку пишут не на той строке, что я привык. Думаю что переборчивость зависит от сложности поиска работы, если сложности нет — начинаешь перебирать, если очень нужна — готов на почти все. И это справедливо для любого возраста.
Я вижу только один правильный ответ. Своё дело — свои правила. Всё остальное — снова наступать на горло песне. Если оглянуться назад, то КПД моей безудержной энергии ничтожен.
Расслабьтесь. Сейчас, чтобы переставить все фигурные скобки в проекте, вам нужно нажать пару кнопок в решарпере. Точно так же легко сделать так, чтобы вы просто не могли сбилдить пока скобка не окажется там, где надо :)
Напомнило рассказ основателя SPB Software. Когда он взялся за проект на Java, ничего о ней не зная, но уверенно обещая решить все проблемы заказчика, когда остальные претенденты рассказывали лишь о себе-любимых.
Я тоже программлю, но я инженер проектировщик. Программлю в основном для хоббийных проектов, ну и по работе чутка. И понимаю что профессионально программить вряд ли смогу. Т.к. понимаю, что для программы которая будет для широкого круга пользователей это должна быть программа совершенно другого уровня. Но вот дать тз на разработку или сделать прототип программы с замудренным алгоритмом, это пожалуйста.
Я пробовал фриланс, когда ещё не было такого слова. Вернул долги за первую машину. Если постоянный заказчик и долгоиграющий жирный проект (фактически удалённый офис), тогда может быть.
У меня работа налажена, в том чиле за счёт программирования.
Есть ещё фриланс в части проектирования, несколько заказчиков которые переодически дают работу. Основной доход конечно даёт основная работа. Но фриланс тоже дает очень ощутимую прибавку. Я не готов полностью уходить во фриланс, пока оборот не составит 500-800 тыс руб. Пока он в районе 100-150 тыс, из них моих денег 40-50%.
Так что варианты для Вас есть…
Например устроится на постоянную работу не связанную с программированием, но в которой вы специалист.
Но которая позволит быть относительно свободным.
Кстати. Одно время маячила безумная идея устроиться персональным водителем. Много свободного времени в мягком кресле с ноутбуком.
Представляю себе какие широкие возможности в области фриланса есть у ночных сторожей
А первая работа была — ночной сторож. Ибо можно было диалапом пользоваться, единственная возможность в интернетах посидеть была. Телепортом книги покачать.
Дежурным по давлению в котельную — еще попробуй устроиться. Козырное было место. Не знаю, как сейчас.
Да все это не так впечатлительно звучит как «лежу на гамаке на Бали, фрилансю», но все это имеет место быть при разных обстоятельствах, взглядах на жизнь.
А вот с котельными другое дело, оператор диспетчер котельной, энергосети, электростанции нормальное место, где как-раз и нужна спокойная аналитическая работа. Некоторые виртуально знакомые создатели сайтов как-раз такие диспетчеры. Один на АЭС работает, суть работы смотреть за лампочкой, загорится красным действовать по инструкции. Работа вообще ни как не мешает наполнять и поддерживать его сайт. Может даже лучше, разнообразие к виртуальной жизни.
Там где в принципе можно свои знания приложить.
Зы. Так и думал что будут коменты про сторожей и охранников, кстати еще кладовщики есть.
В вашем случае фриланс — это почти свой бизнес. Перевести лошадку с рыси на галоп.
Объема заказов пока нету хорошего…
Нужен объем на 20-30 млн руб, тогда есть смысл, делать свою контору и уходить.
Даже на объем 5-8 млн руб, даже дергаться нету смысла, ведь с этих денег, мне достанется 40-50%
Но есть другие идеи…
http://forum.dwg.ru/showthread.php?p=1625178#post1625178
Заценил, прикольно! И про донаты мне нравится идея, нужна правильная подача.
Примерно в 2011 году залипал на сериале Тинькова — Секреты Бизнеса. Тетенька таскала шмотки из Китая, потом поставила 1С, и само попёрло. Почти в каждой серии подобные истории. Какой-то простой шаг приводит к мультипликации бизнеса.
Я тоже питерский, только уже 10 лет в скитаниях. :)
Т.к. понимаю, что для программы которая будет для широкого круга пользователей это должна быть программа совершенно другого уровня.
Это только один из миров, есть и другие, где могут быть нужны сложные программы, которые не тиражируются а пишутся для решения проблем ~1 заказчика (внутреннего или внешнего — не суть).
Кстати вот именно сейчас работаю над одной перспективной разработкой.
http://forum.dwg.ru/showthread.php?t=138766
А не подскажете дешевый способ 3D сканирования моделей для последующей 3D печати. Kinect вроде такое умеет, но очень сомневаюсь в точности его замеров.
https://www.youtube.com/watch?v=MEy8AgiRYwo
Ценник смущает, вот нашел гуманный вариант:
https://www.youtube.com/watch?v=iRP3fwSSiQk
На сегодняшний день выполняю небольшие задачки на фрилансе(парсер, бот) в свободное от основной работы время. Пройти буфер HR тоже не удается)) Чтобы иметь в своём резюме какой-либо значимый проект, нужно уже быть в команде — один в поле не воин. Лично у меня выработались набор навыков, которые позволяют мне быстро освоить новое направление — я научился учиться. И мне нравится программировать.
Тогда Вам нужно заняться IoT — именно там есть перспективное сочетание низкоуровневого железа и программирования. Возможно даже — заняться этим именно как электронщику и проектировать такие вот устройства, например для изготовления в Китае.
Но для успешной работы потребуются либо навыки анализа рынков и экономиста-производственника — либо коллеги с такими профессиями в единой команде — без этого далеко не уедешь. Ах да — коллеги-юристы и переводчики, тоже будут нужны — так как ориентироваться только на малый российский рынок не стоит а в мире законы везде разные.
И уже предвкушаю каково будет проходить собеседование на позицию junior'а и работать бок о бок с тем, кому 18.
Сам занимаюсь только 4 месяца и попал на бесплатные курсы от одной компании, которая после курсов нанимает некоторых на позиции Джунов. Так вот, среди тех, кто захотел и прошёл тестовые задания достаточно людей за 30.
Пройти буфер HR тоже не удается
Буфер не всегда в виде HR.
У нас, скажем, на присланное резюме смотрят в том числе и технические специалисты (тим-лиды как минимум), а потом принимается решение стоит звать на собеседование или не стоит.
Хотя, думаю, может это зависит от конторы и поставленного процесса.
Выручило то что
— в DSP области очень сложно найти специалистов,
— здесь многие старые знания в электронике просто трансформируются в свой дискретный вариант,
— в интернете куча шикарнейших лекций по математике и программированию (MIT, Стэнфорд, Беркли..)
Начал изучать программирование еще в школе по книгам. Писал программы в тетрадке и проверял, по возможности, на компьютере у соседа. В колледже только купил компьютер (386 кажется).
В начале нулевых, когда закончил колледж, преподавал visual basic на компьютерных курсах для школьников. Потом несколько лет работал сисадмином на заводе.
Несколько раз поступал в универ и бросал. Так что высшего образования так и не получил.
К концу нулевых уволился с завода, снова занялся программированием и ушел во фриланс.
Сейчас 34 года, решил завести второго ребенка. Несколько лет интересуюсь психологией и вот в прошлом году поступил в институт на психфак.
Сколько помню, почти всегда занимался тем, что интересно и приносит удовольствие (как процесс, так и результат).
Одним из полезных навыков в современном мире, на мой взгляд является умение обучаться и переучиваться.
Не вижу смысла ограничивать себя возрастом и прекращать учиться — кругом слишком много всего интересного.
Раневская, кажется говорила: «Жизнь — затяжной прыжок из п… ды в могилу». А потом кто-то дополнил эту фразу: «и смысл жизни — прожить этот прыжок как можно радостнее».
Опять же, субъективно. Многие такой взгляд на жизнь не разделяют и предпочитают заниматься все время чем-то одним, чему обучились когда-то давно.
Лично я считаю, что любой человек это инструмент. Молоток, если хотите. Молоток по выколачиванию прибыли. Смысл в том, что ты получаешь часть прибыли, которая появляется в результате твоей работы как человека-инструмента. Надо это понимать и отталкиваться от этого. Если делая свою работу, ты способен принести прибыль, вопросы о возрасте отпадают сами собой, но остаются вопросы конкуренции в аспекте здоровья. Многим пожилым людям сложно выдерживать интеллектуальную конкуренцию с молодыми. Мозг уже не так быстро работает, новая информация усваивается тяжелее, стрессоустойчивость ниже, концентрация меньше.
Ну даже не знаю. Зачем пытаться конкурировать с кем то? Это с самого начала ставит тебя в позицию догоняющего. ИМХО, но у возраста есть куча своих преимуществ которых никогда не будет у 18 летних. Усидчивость, терпение и желание разобраться и понять, а не тупо нагуглить решение, вставить и забыть. Современная молодеж застряла в складывании кубиков и любой шаг в сторону от собирания библиотек вызывает у них разрыв шаблона. Наблюдал такое не раз.
Самому 40 и работаю водителем, что никоим образом не мешает мне кодить долгими зимними вечерами в свое удовольствие. Подумывал устроиться програмером, но не готов к дауншифтингу по зарплате. Семья просто не поймет.
Много катаюсь по трассе, слушаю по рации разговоры дальнобойщиков. ЗП у них сопоставимы с уровнем очень среднего разработчика.
У меня есть сосед. Диплом 20-ти летней выдержки, по специальности не работал. Сбежал из Украины на заработки в Минск. Контроллером ОТК на сборке Кадиллаков. ЗП — $500. Контракт заканчивается. Убедил начать. Как минимум, ничего не потеряет. Посадил рядом стажером, этот проект реализовал под его наблюдением. Сорвал голос, проговаривая каждый свой шаг. Чем дальше, тем мне интереснее. А у него все меньше горел взгляд. И сдался.
Я несколько раз выгорал за все время, но что-нибудь пилить напильником — это моя базовая потребность. Найдите способ перейти Рубикон. Кстати, в 2003-ем на полгода нашел отдушину питерским ночным бомбилой.
Еще раз пересмотрел среднии зарплаты и как то даже сениор с опытом лет 10 не дотягивает до моего годового заработка. Особенно если учесть что живу я в деревне и никуда не хочу переезжать. Так что не понятно какой рубикон мне нужно переходить и главное зачем. Если можно тихо мирно в свое удовольствие собирать свой вариант hal9000 :)
Я вижу в тексте уже три причины оставить всё, как есть.
Спасибо, что разрешили. Программист, это ж орфография прежде всего! Но в целом ваше поведение это все что нужно знать о професиональных програмистах. :)
3 причины оставить всё как есть из вашего коментария
- сениор с опытом лет 10 не дотягивает до моего годового заработка
- живу я в деревне и никуда не хочу переезжать
- можно тихо мирно в свое удовольствие собирать свой вариант hal9000
Вы, похоже, поняли его как-то по другому.
Так и вопрос. Зачем внезапно нужно становится професиональным програмистом? Автор как бы подал все под соусом что кто не стал програмистом, тот вообще ничего в жизни не достоин. Бред же.
А насчет смены профессии… моя учительница в АСТУП в 70 лет вышла на пенсию. Пошла вахтером в дом культуры. и через два года стала там главным администратором. Так что, если мозги есть, то и в 70 можно новую профессию освоить.
Лет десять практиковал подобный способ профессионального роста — не засиживаться на одном месте больше, чем год-полтора. Только меня никто не сманивал, искал целенаправленно сам.
В советском лексиконе было много ярлыков, которые можно на меня повесить: спекулянт, барыга, цеховик, бомбила, тунеядец, бомж, карьерист etc.
Уверяю вас, от моего ухода не пострадал ни один проект. А может даже выиграл.
В целом это спор о терминах, конечно. Просто терминология разная.
Уход основных участников (трое из шести) — это было бы очень критично.
hardcore
Опять-таки, не очень понятны слова «первый релиз». Это примерно как "осетрина второй свежести". В АСУТП релиз один. Это переход из опытно-промышленной в промышленную эксплуатацию. А до того — от полугода до двух лет опытной и опытно-промышленной эксплуатации.
В опытную — можно и MVP запустить, если нужно. Но… вы согласитесь покупать MVP вместо автомобиля или стиральной машины? :-)
Что касается сроков, то на какой-нибудь Северстали или НорНикеле переговоры о создании системы занимают 2-3 года. Это ещё до подписания договора.
Ещё раз убеждаюсь, что АСУТП и настоящее программирование — это два разных мира.
Фильтр — это такая огромная дура на ножках. Под фильтром — рабочие места четырех человек. Один был в туалете, один в курилке, двое удрали из под падающего фильтра.
Но как мы были рады. что ни одной нашей подписи на решении запускаться без автоматики не было. А уж как рады заводчане, что обошлось без человеческих жертв…
Ещё раз убеждаюсь, что АСУТП и настоящее программирование — это два разных мира.
Может хватит это старательно постулировать? Просто другой из миров ПО, где-то в районе остального embedded. И говнокода в нём может быть тоже выше крыши, в зависимости от критичности задачи и имеющихся рисков.
Ошибки в работе той же вентиляции обычно не несут рисков жизни и здоровью людей, вот там и заморачиваются гораздо меньше. Ну и ущерб обычно более-менее локализован (воздухопроводы, калориферы, затопленные технические помещения).
Другое дело какая-нибудь пожарка, где ошибка в нормальном случае обернётся штрафом, в более весёлом — затоплением этажа, и до человеческих жертв в плохом раскладе.
В некоторых областях АСУТП можно ещё большие масштабы разрушений и жертв найти. Суть от этого не меняется, просто другие риски.
В общем, разработка ПО или ПАКов — она в общем-то едина. От крайности типа "вывести продукт технологичного стартапа на рынок за три месяца, т. к. дату запуска уже анонсировали", где нужен некоторый минимальный уровень качества, чтобы оно вообще как-то заработало (т. е. классический херак-херак и в продакшн). И до встроенного ПО для life-critical систем, где за надёжность готовы платить (в том числе сроками выхода на рынок/внедрения). Кому-то три года кажутся огромным сроком, а кому-то и ~10 лет очень неплохо, например, если это авионика.
Ошибки в работе той же вентиляции обычно не несут рисков жизни и здоровью людей
См. пост выше. Цементный фильтр — это как раз вентиляционная система. Но то, что фильтр упал без жертв — это чудо.
Суть от этого не меняется, просто другие риски
Ну как вам сказать… Если сильно обобщать, то и проектирование жилых домов — та же самая инженерия. А если не обобщать, то миров получается не 5, а намного больше. Та же авионика — вообще отдельный мир.
Собственно, если поработаете в АСУТП — увидите отличия.
Судя по вашей ссылке, АСУТП и АСУ относится к внутреннему ПО
Никто не говорил, что список от Joel'а будет полным. Оно обладает чертами как внутреннего ПО, так и embedded. В зависимости от требований какие-то части вполне могут переиспользоваться и продаваться как типовые решения, которые на месте проходят конфигурирование и пуско-наладку.
Собственно, если поработаете в АСУТП — увидите отличия.
Спасибо, поработал уже. Мне эта область не по душе. Куда ближе некоторые другие, где сейчас и работаю.
- Это внутреннее ПО, функциональность важнее простоты использования
- Разработчик АСУТП должен понимать автоматизируемый техпроцессс на уровне заводских технологов с 20летним стажем (лучше — ещё лучше)
- Отказы оборудования штатно учитываются софтом (это особенность российского АСУТП, американцы обходятся без этого)
- В целом АСУТП очень близко к DIY, но DIY за деньги. Отсюда большие отличия от настоящего программирования, но близость к разного рода колхозным решениям
Это внутреннее ПО, функциональность важнее простоты использования
Это довольно часто актуально и в других немассовых продуктах, когда софт используется относительно узкой аудиторией. И в "ширпотребном" (в терминологии Спольски) софте типа, скажем, разных CAD/CAM, медицинского софта, кучи банковского и учётного софта, среди написанного программистами для программистов и куче других областей. Это не особое дискриминирующее отличие АСУТП. Это отличие массового софта рассчитанного на широкую аудиторию от специализированного.
Разработчик АСУТП должен понимать автоматизируемый техпроцессс на уровне заводских технологов с 20летним стажем (лучше — ещё лучше)
Это применимо для многих областей автоматизации. Понимание домена — важный фактор при разработке любого сложного софта. Иначе он окажется куда менее полезным "пользователю".
В целом АСУТП очень близко к DIY, но DIY за деньги. Отсюда большие отличия от настоящего программирования, но близость к разного рода колхозным решениям
Тоже по разному ведь бывает. Кто-то фигачит, скажем, свой протокол, а кто-то использует условно-человеческий bacnet и стандартные библиотеки для имплементации. Аналогично на более низком уровне, кто-то каждый раз пишет условный кусок управления трёхходовиком или пид-регулятор, а кто-то использует библиотеку, поставляемую вендором, для тех же задач.
Повторное использование, конечно, значительно меньше, чем в каком-нибудь вебе, который вы, похоже, считаете единственной областью "настоящего программирования", но тоже присутствует у многих. Говорю на примере работы преимущественно в области HVAC с проектами на базе разных ПЛК от Segnetics, TAC/SE, Carel, Necos/Danfoss (возможно, кого забыл).
Насчет понимания предметной области — зайдите на сайт любого интернет-магазина. И сравните с сайтом Мосигры (среднее время на сайте 20 минут). Опыт показывает, что в 99% случаев сайт интернет-магазина и программируется и наполняется без понимания предметной области. И ничего, работают, торгуют.
Колхозить — это достигать нужного результата самым эффективным путем. Когда заказчик — мы сами, то мы знаем, что нам нужно (а что — не нужно). В этой ситуации не нужны лишние заделы на случай неожиданного изменения ТЗ. Примерно так и в АСУТП, ТЗ известно и в ближайшие лет 10 модернизация не потребуется (ну или известно что именно потребуется менять).
А вот к велосипедам (vs повторное использование) это уже имеет лишь косвенное отношение. Велосипеды хороши в узких нишах, где универсальные решения слабее. И именно из точного понимания ниши вытекает возможность нагородить свой велосипед и выиграть по характеристикам до нескольких тысяч раз.
Что касается веба — это типичный пример настоящего программирования, когда никто, включая заказчика не знает, чего захочется через год. Потому все нужно делать универсально, расширяемо, с возможностью. выпуска новых версий в течении десятков лет.
В АСУТП все наоборот. Первый релиз — зачастую последний, ТЗ — четко очерчено…
Насчет релиза — насколько я понял в вашей терминологии это передача проекта в опытно-промышленную эксплуатацию, если на этот момент все ключевые части готовы, остается только наладка и мелочи, то в целом человек может с чистой совестью уходить.
Если кратко, то добавление людей — это горизонтальное масштабирование. вОно ускоряет лишь на определенных классах задач. А на других классах разбиение системы на мелкие части лишь увеличивает трудоемкость.
Хороший пример — конвейер. Конвейерная сборка — не быстрее ручной, она эффективна лишь для массового производства за счет уменьшения требований к персоналу. Но для выпуска одной машины время переналадки конвейера огромно, а вот ручная сборка позволяет собирать разные модели почти с той же скоростью, что и одинаковые.
Хорошее разделение идет на подсистемы, которых обычно не так много (5-10, не больше). А вот написание подсистемы — это аналог конвейера. Деление подсистемы на части (мелкие модули) увеличивает и объем спецификаций и объем кода.
В опытно-промышленной эксплуатации, если все хорошо — то, действительно, можно ничего не делать. Следить за системой и править редкие баги. Но, если ошиблись в какой-то ключевой характеристике (скажем в производительности), то нужна вся исходная команда, чтобы исправить ошибку. Потому, что самый тяжелый вариант — это изменение архитектуры.
Было бы отлично если бы вы написали статью на этот счет, с особенностями работы в АСУТП.
Если я пишу интерфейс один — это 2*10= 20 дней. Если я отдаю эту работу 10 людям, то каждому из них потребуется недели три на обучение и библиотеке и тому, откуда брать данные для таблиц. То есть каждый затратит 21+2= 23 дня, а я эти три недели обучения буду занят на 50% объяснениями. То есть мои затраты — 0.5 на 21 — 10.5.
Итак, 20 дней для одного человека и 23*10+10.5 = 240.5 дней для команды из 10 людей. То есть в 12 раз больше трудоемкости.
Со сбором информации ещё хуже. Прежде чем писать работу с контроллером, надо прочитать документацию. А это полка на английском. И читалась она примерно полгода.
А статью. про этот проект напишу. Она уже давно начата, но все времени нет дописать.
Неужели в мире столько разных МК, что нужно про каждый читать по пол года?
Неужели в мире столько разных МК, что нужно про каждый читать по пол года?
Одному программисту при разработке ПО для пульта управления телеком надоело читать по полке доков по полгода и он пришёл к руководству с заявлением на увольнение.
А у руководства сидел и пил чай Гослинг (последнее время который проводил в посещении всяческих конференций). Выслушав причину увольнения, Гослинг предложил программисту писать код для этого пульта (для разношерстных МК, которые предлагались для реализации в железе этого пульта) на одном языке.
Так родилась… Java. ©
И как раз пульты я бы писал на форте.
P.S. По другой легенде java придумали для кофеварок.
«Новый язык и фреймворк» — это где-то тысяча страниц. С учетом скорости чтения на русском 50 страниц в день — как раз за 3 недели и получится.
Неужели в мире столько разных МК, что нужно про каждый читать по пол года?
Что вы называет МК? Микрокалькулятор? У нас ПЛК
Все от задачи зависит.
Если у вас задача написать программу на ПЛК — то вам много читать и не нужно: стандартный Ladder и всё. Конфигурирование ввода-вывода сделают старшие коллеги.
А если у вас задача, как у нас (грубо говоря мы делали отладчик для любых программ на этом контроллере) — то да, нужно знать весь контроллер, причем до принятия архитектурных решений.
Какой-нибудь оптимизатор кода или статический анализатор — это были мелкие добавки к тому, что мы делали.
Основное — это запись всех переключений входов и выходов с возможностью проиграть, что происходит в потрохах ladder. И не просто проиграть, а по изменению состояния выхода просчитать, какой вход привел к такому изменению. Причем просчитывали — в 99.7-99.9%.
Ну вот вам аналог для JS. У вас на сайте есть индикатор, который меняет цвет на красный. Использую код сайта и запись того, что делал пользователь и что пришло по сети (AJAX), определите, что вызвало изменение цвета индикатора. При этом код сайта — любой.
Чувствуете, что вам потребуется совсем иной уровень знания языка и аппаратуры?
Мне не понятно зачем делать новые микроконтроллеры и ПЛК, которые на 100% отличаются от старых, я понимаю можно добавить что-то новое, или просто сделать мощнеее\надежнее и тд. Но так чтоб перечитывать по 5000 страниц каждый раз? А заказчиков не напрягает платить за эти 250 дней чтения? Он не просит — возьмите то с чем работали и сэкономим пару лет?
Чем больше вас читаю, тем больше удивляюсь вашему опыту.
А заказчиков не напрягает платить за эти 250 дней чтения?
Вы не понимаете экономику. Цена остановки стана 35-40 тысяч долларов, улетевшие в брак. Столько стоил рулон стали. Цена проекта — 3-4 рулона стали. Что лучше заказчику? Сэкономить 1 рулон на разработке или экономить несколько рулонов каждый год из-за того, что мы с головой влезли в задачу?
На таких проектах стоимость обычно фиксированная. В отличие от сроков. Раза в полтора-два они растягиваются.
Откуда могут браться каждый раз новые технически сложные задачи?
Из жизни. Я с 17 лет участвую в очень интересных проектах. А вот типовых — как-то не было.
Следующая задача была совсем чудесатая. Современная газовая котельная работает в предвзрывном режиме. То есть без автоматики котел или тухнет или взрывается. И вот на НорНикеле буржуи поставили эту саму современную котельную. А тут кризис 98ого года. Буржуям не заплатили и они уехали на этапе пусконалдки. Оборудование смотнтирование, а софт… частично удален, частично не настроен, документация стерта…
Переговоры шли 3 года. 3 года НорНикель (не самое маленькое предприятие, вообще-то) искал, кто же возьмется за этот гибельный проект. Вы полгода хотите сэкономить, а тут переговоры 3 года шли. :-)
Не могу удержаться от цитаты: "Рекомендации ведущих фирм по автоматизации сводились к предложению демонтировать контроллеры, заменив их на применяемые в теплоэнергетике РФ."
Но в итоге — сделали. На имеющихся контроллерах. В основном — ради того, чтобы влезть в теплоэнергетику (это такой тесный рынок, куда тяжело пробиться).
Т.е. по сути программирование это рутина, если-бы не выходили новые языки и платформы — то там и учить нечего было бы.
Вам лет 20 что ли? Детский сад, штаны на лямках…
Если вы автоматизируете техпроцесс — вы должны сами знать его на уровне заводских технологов с 20 летним стажем. Потому что иначе — какой толк от автоматики, если она пасует в сложных или редких ситуациях?
Так что любая прикладная разработка — это огромное изучение предметной области. И не только её.
Но так чтоб перечитывать по 5000 страниц каждый раз?
Знаете, что бывает, если не читать? Из недавнего. Ядро Cortex-M7, SoC STM32F7. Суммарный объем документации — те же 5 тысяч страниц. Не почитали, ибо решили, что опыта с STM32F4 хватит.
В итоге — нарвались. Cortex-M7 допускает невыровненный доступ (чтение-запись слова по нечетному адресу). Соответственно библиотека была сконфигурирована с учетом разрешения невыровненного доступа. Но, как оказалось, невыровненный доступ работает не с любой областью памяти. Нарвались на memcpy в область батарейного ОЗУ. Ну кто мог подумать, что memcpy захочет писать слово по нечетному адресу!
Хорошо ещё, что нашли это до отправки прибора. Попал бы прибор с такой багой (а баг плавающий) на беспилотник, для перевозки которого нужны два фургона — было бы сильно стыдно.
Внешне баг выражался в том, что при загрузке настроек с одними значениями — настройки грузились, а с другими — нет. Как оказалась, в memcpy была жутко сильная магия, и что он делал — зависело от длины копируемого.
Так что — лучше прочесть.
Ради интереса можете посмотреть сколько новых публикаций по .net или java, и дело не в том что они умирают, а в том что там особо и писать не про что.
Ну кому-то писать нечего, а человек, писавший у нас экранную библиотеку — стал соавтором языка Котлин. И опять, не могу удержаться от цитаты:
— Давай я всю историю расскажу. Пришёл Сергей Дмитриев и говорит: «Знаете, мне кажется, нам надо что-то интересное сделать. IDE, тулинг — это всё понятно, а что бы такого сделать, чтобы вывести компанию на новый уровень?» И Дима yole Жемеров ляпнул: «А давайте язык программирования сделаем!»
Так что это для вас пока что ничего нового не видно. Мне вот было бы интересно скрестить форт с JVM и JIT-компиляцией. То есть попробовать сделать, чтобы язык четвертого поколения работал со скоростью языков третьего поколения. Если интересно — могу как-нибудь рассказать, что такое язык четвертого поколения.
Пол года читать про контроллер звучит совершенно не реально.
Да ладно?
Монетоприемники и купюроприемники, карточные терминалы — пару месяцев «курить мануалы» под новую модель, что бы сделать прототип с основным функционалом, имея за плечами опыт разработки в этой сфере лет 5.
Это не из «пластилина и палок» лепить MVP за два месяца
Но глаза боятся
А чего такого? Никто не осудит! :)
Эх, как же откликается статья. Саи ушел из чистого ИТ лет 17 назад. Сейчас почти 40 и понял, что хочу обратно. Но не в админство, а во фронтендеры. Для начала. И не в офис, а либо в удаленку, либо во фриланс. Пока осваивать новое получается плохо. И основное ограничение, совсем не в ухудшении свойств соображалки. Самая большая проблема — банальный быт. Когда ты уже врос в устоявшуюся систему и есть работа (пусть не любимая), но ее надо делать и после нее часто выжат как лимон; когда есть жена и ребенок, котрых хочется видеть не по 15 минут в день и которые тоже хотят чтобы муж/папа уделял им бОЛьшее время; когда есть новая квартира/ипотека которую надо обустраивать/оплачивать; когда болеют постаревшие родители и бросаешь все неосновное, когда надо помогать. Когда… да навалом этих когда у каждого. Из-за всех этих "когда" уже не получается вечерами просиживать над книжками/за компом, как это было ранее. И переползание на новые рельсы происходит очень медленно. Часто на новое выделяется максимум час рано утром, пока твои спят. Или не выделяется вообще, т.к. из-за житейских дел накануне лег далеко заполночь и не можешь оторвать себя от подушки. Быт и система в которую врос — вот основная проблема. Это не преграда, но "груз", с которым идешь гораздо медленнее. И с этим приходится примиряться.
Вера в успех
История скорее не забавная, а поучительная.
Было это года четыре назад. Лето. Жара нещадная. А я начал на своём участке делать подвал. Так как дело было в строительный бум, то помощников найти не удалось: все заняты до осени (даже подростки 14-18 лет куда-то делись). А подвал нужен и очень. Если читатель никогда подолгу не сидел на дне здоровенной глиняной ямы в солнечный день, то передам ощущение: пустыня Сахара в безветренный день. Спустя пару недель таких работ чувствую: «Всё. Сдаюсь».
И тут на краю ямы появился старичок, пасший коз. Оценив мои проблемы, он поведал свою историю.
Дело было после войны. Было ему 16 лет и задумал он жениться. А чтобы было куда молодую жену привезти — нужен свой дом (он же мужчина!) Землю для строительства раздавали всем желающим, а вот со стройматериалами — беда. Все лимиты расходовались на восстановление заводов. Купил он в итоге мелкого шлака (у нас в Туле металлургический завод), добыл где-то не-то известь, не то даже цемент и начал лепить кирпичи. Каждый день он вставал в 4 утра и до 7 формовал кирпичи. Потом шёл на работу. После работы — вечерняя школа. И так 2 года. А через два года он за неделю сложил из этих кирпичей домик (соседи помогали всей улицей. Единение Народа-Победителя действительно было, чтобы там в учебниках по истории изданных на средства американских грантодателей не писали), где он и прожил до глубокой старости со своей женой. Своё хозяйство: огород, козы. Благодать.
P.S. После разговора с ним, окрылённый чужим успехом (у него даже материала не было, а он целый дом построил!), доложил я очередной ряд кирпича и поехал домой. А по дороге выяснил, куда делись все мои потенциальные помощники. В автобусе ехала целая компания ребят (17-20 лет). И один из них выклянчивал у своей матери деньги: «Мам, ну мам! Дай мне денег! Сегодня же День Пива! Вся Тула будет на Площади! Я свою девушку хочу пригласить! А то только через компьютер общаемся, как маленькие!»
Отличная история, спасибо! У меня в качестве такого старичка выступает желание заниматься любимым делом и быть больше с семьей. Зажолбало 5 дней в неделю просыпаться с мыслью "блииин, опять на работу...". Так как четко помню период, когда мысль была "Хо-хо, на работу скорей! Я же вчера еще вот с этимм и этим не разобрался!"
Быт и система в которую врос — вот основная проблема. Это не преграда, но "груз", с которым идешь гораздо медленнее.
В этом смысле мне очень нравится фильм "Марсианин". Любой новый удар судьбы — это просто изменившийся контекст для принятия новых решений.
Сейчас обитаю в Минске. Снимаю комнату в котедже. Соседи-алкоголики, чтоб жизнь малиной не казалась. Тёплый гараж в подвале. Кладовка для накопленных пожитков. Баня. Участок с яблонями-грушами. Поставил старенький караван на вечную стоянку — летом вместо дачи, комфорт на нужном уровне: кондей, холодильник, спутник, вай-фай. Свой лучший код пока не написал, но все условия подготовил. Скоро май.
Отлично пишите!
Привет вам из Минска.
И удачи. Она вам, похоже, нужна.
Недавно узнал, что даже в Америке 12 лет стажа приравнивают к диплому. В Европе меньше.
А могу я попросить уважаемого автора дать ссылку на источник сей информации?
Гуглил — не нашёл. Хотя, допускаю, что не так спрашивал.
Здравствуйте. мне 40. И я быдлокодер. [одобряющие, но тихие апплодисменты].
но лучше попробовать, чем лежать на диване.
Лучше «попробовать» что? Какая цель? KPI какой?
Если не рассматриваем действия «non profit», то Активы по результатам действия должны быть не меньше, чем в начале.
Мечта о собственном свечном заводике требует нарабатывать навыки во всех смежных областях, от сисадмина до UX-дизайнера. Маркетинг — это отдельная моя большая страсть (Котлера в ранней юности прочитал).
Плох тот солдат, как говорится. Своё-то есть, конечно. Давно живу. Но хотелось бы наработать практику на живых проектах — когда варишься в собственном соку, то отстаешь от жизни.
Случайно нашел в этой теме свой комментарий: "Мне 40 лет. 18 лет сисадмин. Пытаюсь свитчиться в dev-ы.". Вот он https://habr.com/ru/articles/323460/#comment_10109658
Кароче все получилось, я разраб уже 6 лет. Теперь уже 3,5 года на удалёнке ))
Как вернуться в кодеры, когда за сорок