Pull to refresh

Comments 174

В белорусском языке есть красивое слово — перемога

перамога вроде бы

Перемога — это в украинском.
Перамога, я — белорус

А я и русский, и украинский, и белорусский. Потому путаюсь в показаниях. :)

Главное что бы соседи по жилищу, «не зрадилы»
Мерцает экран монитора,
По клавишам пальцы бегут,
Но мыслей несытная свора
Забыться никак не дают

Был молод, а ныне к закату
Текут моей жизни года.
И хоть получаю зарплату,
Не жду ничего, никогда.
И хоть получаю зарплату,

Уже нет, сегодня уволен "по соглашению сторон".

Мне вот сейчас 27 и взбрело в голову стать программистом, да еще и без высшего образования. Уже третий месяц пошел, как занимаюсь этим. И уже предвкушаю каково будет проходить собеседование на позицию junior'а и работать бок о бок с тем, кому 18. Но это, знаете, игры разума. В том смысле, что действительно проблемой может стать предвзятость некоторых работодателей. И да, чем дальше, тем грустнее, что самому уже не 18. Но и все, других хоть сколько-нибудь существенных проблем я не вижу.
Вот смотрите, снижение скорости когнитивных процессов обычно происходит годам к 50 — 60. И тут есть как негативные факторы, вроде болезней или образа жизни, когда большую часть времени человек проводит, почесывая пах, и развалившись на диване, так и позитивные, вроде постоянного самообразования, поддержания физического тонуса упражнениями. То есть, влияние возраста преувеличено.
С другой стороны, беспокоить может вопрос о скорости обучения и как следствие постоянное отставание от «молодых и дерзких». Но это, опять таки, следствие когнитивных искажений. Если условно разделить программирование на компетенции, позволяющие поддерживать актуальный уровень профессионализма, то можно отметить следующие навыки и знания: во-первых, знание синтаксиса и API тех или иных библиотек языка, во-вторых, умение моделировать абстракции и связи между ними (читай архитектуру), ну и в третьих, способность поддерживать эти знания в актуальном состоянии.
Первое достигается практикой и, неожиданно, чтением документации. И практикой. Тут возраст вообще не играет никакой роли.
Со вторым дела обстоят чуть сложнее, в том плане, что все вроде бы понятно, но что делать, не вполне ясно. Фактически это означает чтение книг о тех или иных парадигмах программирования, алгоритмах, паттернах и антипаттернах. Применение этого на практике. Ну и чтобы все это ложилось на благодатную почву, имеет смысл удобрить ее Computer Science. Благо, информации — куча. Я, например, просвещаюсь на Лекториум. И самое радостное, парадигм, да и вообще фундаментальных знаний, конечное количество. А важно тут вот что, если человек не просто сидел, почесывая пах, а на протяжении жизни хоть как-то самообразовывался, то у него не возникнет проблем с освоением абстракций и парадигм. Способность мозга к моделированию не линейная, а кумулятивная. Для примера, попробуйте открыть учебник по любому предмету класс эдак за 7. Фактически, это брошюра на 150 страниц, которая читается за вечер. Чему там учить целый год? Но это особенность нашей психики, когда человек моложе, его «банк моделей» не такой большой, чем старше человек, тем у него больше возможностей к опосредованному осознанию. Это чем-то напоминает алиасы. Когда мозг собирает понимание новой модели, через кусочки уже понятых, через аналогии. Мне, например, именно расширение своих способностей к абстрактному мышлению и моделированию, представляется самым трудным. Но и тут, я вижу определенные плюсы в том, что меня не накрывает гормональной волной, которая толкает совокуплять все что движется (по крайней мере не так сильно как в 18). То есть, позволяет выстроить процесс самообучения более последовательно.
Ну, и как только синтаксис будет изучен, а новая книжка с описанием архитектуры будет восприниматься легко даже при чтении по диагонали, для поддержки знаний и навыков необходимо будет всего лишь читать draft'ы, обсуждения на git'е, ну и хабр, естественно.
Единственное, что может потребовать усилий, так это убедить сотрудника hr отдела, что вы более чем подходите для этой должности. И если ни ваша компетентность, ни низкая мобильность в плане смены места работы, ни ваша предрасположенность к открытому обсуждению сложностей не могут перевесить чашу весов конкретного hr'а, то стоит задуматься, а действительно ли вы хотите работать в такой компании, и уж точно не стоит экстраполировать один случай предвзятости на все компании.
Сейчас мне это представляется так, но тут может сказаться недостаток опыта.

Способность стройно и развернуто излагать свои мысли на недостижимом для меня уровне. Это уже жирный плюс в карму и подписка. Публикуйте статьи в копилку портфолио.


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


Резюме — это набор ключевых, чтобы пройти буфер HR, и попасть к технарям, которые принимают решение о трудоустройстве. А там уже очень пригодится портфолио.


Помимо знаний синтаксиса и алгоритмов, важен накопленный об'ем индекса информации в предметной области. Меня раньше называли "мудрый филин" по этому параметру.

Немного похожая ситуация. Мне 38, есть высшее техническое. В отрасли, где я работаю, упадок. Хочу переквалифицироваться в программисты. В свободное время программирую на Delphi/Lazarus. Написал несколько расчётных программ, две из которых продаю. В бесплатные версии программ встроил «крутилки» баннеров, серверную часть подсчёта стистики сваял на php.

Прорешал несколько курсов на stepic.org (C++, Java, Python ...), по двум получил сертификаты (по Java даже с отличием). Хотел бы дальше развиваться по ветке Java. Буду признателен, если кто-нибудь посоветует минимум объёма знаний по Java для устройства на позицию Juniora. То есть не в общем, а вот если бы вы проводили собеседование, то на какие вопросы нужно обязательно ответить и какие задачи решить, чтобы быть принятым?

Для рабочей визы за бугром тоже требуется диплом. На перспективу. Вы уже в лучшем положении!

Смотря в какой стране. Я без диплома работаю в Нидерландах. И плевали они на наши корочки.

Интересно узнать подробности. По рабочей визе?

Да, рабочая на пять лет. Фирма сделала все бумаги, даже шмот перевезла и на первое время пять штук дала на съем жилья. У них так принято. И да, еще возили на собеседования меня вместе с женой за их счет.
Хотелось бы узнать по-подробнее — как попали туда, на чем пишете.
Андроид, просто резюме отправил. Подробности написал выше. До сих пор в шоке, хотя год уже прошел.

Да уж, чудеса случаются :)

Ну не совсем чудеса, тут в компании из двух тысяч разработчиков — русскоязычных треть. Нидерланды вообще прикольная страна, все местные по-английски разговаривают, проблем с общением нет совершенно.
UFO just landed and posted this here
Нет, программирую для десктопа, так как использую программы в своей работе.
Попробуйте взглянуть на JavaRush. Там есть всё необходимое для устройства на позицию Java-Junior'а.
С предубеждением отношусь к платным курсам, но, возможно, воспользуюсь вашим советом. Спасибо.
Там до 10 уровня бесплатно, этого вполне хватит понять нужно ли оно вам.
В том-то и дело, что потратишь время и деньги на курсы, а потом приходишь устраиваться на вакансию, а там «Владеете Git'ом? — Нет. — До свидания.» Курсы подготовят по Java, но не сделают готового Junior'а.
На самом деле, там большой стек изучаемых технологий, не буду больше описывать все плюсы JavaRush'а (мне за это не платят =)).

Вот описание одной части обучения:
image
Думаю, вы правы. По описанию курс стоящий.
Мое мнение — первых 11 бесплатных уровней хватит для старта.
Там очень много задач.
Во первых прокачиваешься по теме, которую прошел.
Во вторых набор кода. Там бывает задачи идут подряд, и можно вроде скопипастить с предыдущей задачи часть кода, но специально набиваю, вспоминаю заново. Реально чувствуется как запоминается лучше.
Мне 40 лет. 18 лет сисадмин. Пытаюсь свитчиться в dev-ы.
Такого списка нет, просто рассылайте резюме и ходите на собеседования.
Есть компании, которые смотрят на знания технологий аля чем отличается абстрактный класс от интерфейса, зачем нужны синглтоны или аннотации в Spring, как работает сборщик мусора в Java.
Есть те, кто любит спрашивать алгоритмы и структуры данных, например, расскажите, как устроена хэш-таблица внутри.
Не забывайте про общую адекватность, не впадайте в негатив, если чего-то не знаете, будьте честны.
Все получится.
Удачи.
Это точно вопросы на Junior'a? Что-то сложноваты на первый взгляд. С ходу без гугла смогу ответить разве что про абстрактный класс и интерфейс.
Конечно, зависит от компании.
Разница, как правило, в том, что для Junior'a окей ответить не на все вопросы или не ответить глубоко, а просто знать, что вот есть такая штука и примерно понимать, зачем это нужно.
Есть вопросы, которые бессмысленно спрашивать у начинающих, например, про архитектуру, организацию деплоймента, анализ ошибок.
А все остальное — можно.
Хм, может написать небольшую статью на тему программерских интервью, интересно будет?

Ну, понимаете, есть довольно большое количество мест, где вопросы задают не потому, что им надо от кандидата именно это, а потому, что сами знают на них ответы :). Поэтому junior или нет — не особо важно. Чем отличается абстрактный класс от интерфейса не важно вообще никому, кроме проектировщиков внешних интерфейсов библиотек (да и знать там нечего — интерфейс, это, в первую очередь, контракт, а абстрактный класс — это один из способов реализации некоторой идеи, остальное — следствия этого). Как устроен хэш-мап не нужно никому тоже, но это вопрос очень популярный, поэтому изучите его хорошенько — на хабре были статьи и по исходникам можно полазить. С точки зрения претендента это хоть и бесполезный, но очень хороший вопрос — он предсказуемый, несложный и путём небольшой манипуляции можно подтолкнуть интервьюера вам его задать :), потом блестяще ответить и получить благоприятное от себя впечатление. Вокруг этого вопроса есть несколько связанных предсказуемых, которые тоже нужно выучить и успешно переводить интервьюера с одного на другой (да он и сам это сделает) — я имею в виду про hashCode и equals — когда их надо переопределять, зачем и почему и то и другое вместе.
А совет ходить на собеседования абсолютно правильный, это даст вам и психологический опыт и направление что подучить — запоминайте вопросы, потом их тщательно изучайте.
Про то как работает сборщик мусора — не парьтесь. Современные устроены довольно сложно и за редким исключением знание это вам ничего не даст. Поэтому с практической точки зрения прочитайте что-нибудь про какой-нибудь простой вариант сборки мусора и на вопрос так и отвечайте, — реальный сборщик сложный и их периодически меняют/улучшают, поэтому как устроен текущий реальный не знаю, но могу рассказать как мог бы быть устроен один из вариантов простого сборщика мусора. А лучше пара — тогда есть повод продолжить беседу в сторону сравнения вариантов и обсуждения недостатков.

Спасибо за ответ. Постараюсь подготовиться по этим вещам перед собеседованием.
Я бы только предостерёг от тупого заучивания, я лично сразу вижу, когда есть база, когда человек пытался эту базу получить (но ещё не получил), и когда человек тупо заучил, без системы, без понимания. Соглашусь, что для джуниора это всё довольно малокритично (а много где и вообще база не особо нужна), тем не менее более правильное слово не «учить», а «разобраться».
UFO just landed and posted this here

Тоже самое. в 27 с подачи XaocCPS узнал c# + asp.net mvc, последние 5 лет в админ в хостингах, пишу свою панель управления хостингом приложений на рельсах. первый важный кусок по управлению доменами уже проходит внутреннее тестирование, скоро буду выпускать в дикий мир :)
сейчас мне 33.

Самое сложное в таком возрасте — забыть о разнице лет и начать перенимать знания и опыт у более молодого и опытного коллеги. Без наставника постигать мастерство написания кода гораздо сложнее.
Многие недооценивают навыки общения в команде.
Кстати, это один из основных рисков найма «возрастных» членов команды — что они просто не впишутся.
Не обладая техническими компетенциями, они могут все равно стремиться занять лидерскую позицию, потому что жизненного опыта у них больше.
Возможна и обратная история, когда они зажимаются, их Эго начинает страдать.
Например, они накосячили и им что-то объясняют, это воспринимается, как нравоучение.
Или когда повышают более молодого коллегу, который как бы еще «зелен».
Не уходите в негатив и все получится, удачи вам!
Регулярно ловлю себя на мысли, что яйца курицу не учат.

Приходилось работать вместе с более старшими, так и собеседовать более старших.


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


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


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


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


Дедушка на собеседовании, когда его попросили написать код с определёнными требованиями, вообще чуть не набросился на нас с криками, что он всегда работает по своему и что даже своему текущему работодателю не позволяет указывать, как ему писать код. Естественно ему вежливо отказали.


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


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

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

Думаю вопрос не столько в возрасте, а в характере — программисты в диапазоне 25-40 лет ведут себя в среднем одинаково («Некоторые с возрастом мудреют, другие — просто стареют»). Я бы на цели и мотивацию больше обращал внимание.

Также значительный эффект — giver-taker и взаимотношения в модели Дрейфуса.
В этом хорошем переводе описания модели Дрейфуса к сожалению не упоминается важный аспект взаимоотношений между людьми из этих разных категорий: различный уровень понимания предмета и способов решения связанных с ним задач, создают трудно-преодолимый барьер при коммуникации или передаче знаний. По этому действительно продуктивный тим-лид или архитектор это чаще удача, чем норма — не редко в архитекторы «записываются» разработчики со стажем и завышенными амбициями (якобы «заслужившие» таким образом право говорить другим — как и что нужно делать), а тим-лиды ограничиваются административным координированием задач команды и «защитой» разработчиков от высоких требований заказчика/тестеров/менеджеров/итд
Таким образом отсутствие понимания проблемы коммуникации, мотивации ее преодоления и просто опыта и желания обмены знаниями между представителями разных категорий (в обе стороны!) — делают сотрудничество неэффективным или невозможным, как следствие — низко-производительным или даже таким, как описано с басне «Лебедь, рак и щука».
«Просишь человека вежливо, не ссылаться из базового класса на функционал класса, который его наследует. „
Что-то странно звучит. У вас запрещено использование абстрактных базовых классов?
(ИМХО, по результатам собеседований возраста 35+) Проблемы в основном у тех, кто работал с одной технологией или был единственным погромистом на предприятии (самый ад) — там в полный рост Великие Велосипеды и Знание Великой Истины, труЪ дедушек не собеседовал (52 — максимум был и как раз не был ужасом).

Со "звёздами" тяжело безотносительно возраста.

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

Я еще не стар, но уже и молодым себя не считаю. Часть новых технологий и изменений мне нравятся, часть я считаю «шумом», которые потеряет популярность раньше, чем я очередную итерацию завершу. Я например помню истерию относительно патернов и модели предметной области, монструозные диаграммы классов, запутаный код. Потом пришла мода на микро сервисы и максимально простые модели. И тоже прошла. Но людей приверженных разным школам осталось полно, хуже всего когда кто-то свято верит в свой подход. Мол вот если будем использовать анемичные модели, то все, успех гарантирован. Или там ТДД залог успеха. А кто-то все еще делает водопад и согласовывает по месяцу ТЗ на компонент которые за месяц можно написать, продать, переписать и еще раз продать. Когда-то и я бросался в омут холиваров разных методологий и технологий, сейчас я отношусь к этому вопросу по спокойней, мое личное мнение — это вообще все не важно, по всем методологиям полно как успехов так и провалов.

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

Я вижу только один правильный ответ. Своё дело — свои правила. Всё остальное — снова наступать на горло песне. Если оглянуться назад, то КПД моей безудержной энергии ничтожен.

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

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

Напомнило рассказ основателя SPB Software. Когда он взялся за проект на Java, ничего о ней не зная, но уверенно обещая решить все проблемы заказчика, когда остальные претенденты рассказывали лишь о себе-любимых.

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

Пассионарии находят себе применение. Этот пример меня вдохновляет.

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

Я пробовал фриланс, когда ещё не было такого слова. Вернул долги за первую машину. Если постоянный заказчик и долгоиграющий жирный проект (фактически удалённый офис), тогда может быть.

Тут как бы фишка в том, что на основной работе я руководитель группы.
У меня работа налажена, в том чиле за счёт программирования.
Есть ещё фриланс в части проектирования, несколько заказчиков которые переодически дают работу. Основной доход конечно даёт основная работа. Но фриланс тоже дает очень ощутимую прибавку. Я не готов полностью уходить во фриланс, пока оборот не составит 500-800 тыс руб. Пока он в районе 100-150 тыс, из них моих денег 40-50%.
Так что варианты для Вас есть…
Например устроится на постоянную работу не связанную с программированием, но в которой вы специалист.
Но которая позволит быть относительно свободным.

Кстати. Одно время маячила безумная идея устроиться персональным водителем. Много свободного времени в мягком кресле с ноутбуком.

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

https://pp.userapi.com/c836333/v836333239/6515/mWw85lKZsA8.jpg

Начинал изучать веб-программирование и фрилансить работая оператором на заправке, ночами уйма времени. У каждого свои условия, главное пользоваться предоставленными возможностями.
А первая работа была — ночной сторож. Ибо можно было диалапом пользоваться, единственная возможность в интернетах посидеть была. Телепортом книги покачать.

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

Сейчас мне это пока и давно не надо. Ну а что будет дальше — увидим. Но кстати насчет водительства проскакивала идея что так можно было бы сменить сидение в офисе на нечто более подвижное, но может очень попозже. С наличием мобильного интернета это не такая и дурная идея. Совмещение любви к компьютерам, интернетам и дороги, интересный опыт может получиться.
Да все это не так впечатлительно звучит как «лежу на гамаке на Бали, фрилансю», но все это имеет место быть при разных обстоятельствах, взглядах на жизнь.
Насчет водительства не уверен, что хорошая идея. По моим наблюдениям, математики или программисты становятся более склонны к рассеянности, что недопустимо на дороге. Нужно некоторое время, чтобы переключится с абстрактного мышления на уровень простой реакции, когда думаешь «спинным мозгом», набором быстрых шаблонов. Даже когда уже за рулем, может неожиданно придти в голову решение, над которым думал ранее до этого и отвлечь от дороги. Интересно, наблюдали ли остальные такой эффект.

А вот с котельными другое дело, оператор диспетчер котельной, энергосети, электростанции нормальное место, где как-раз и нужна спокойная аналитическая работа. Некоторые виртуально знакомые создатели сайтов как-раз такие диспетчеры. Один на АЭС работает, суть работы смотреть за лампочкой, загорится красным действовать по инструкции. Работа вообще ни как не мешает наполнять и поддерживать его сайт. Может даже лучше, разнообразие к виртуальной жизни.
Думаю все таки лучше, что нибудь связанное с инженерными специальностями лучше подошло бы или с производством.
Там где в принципе можно свои знания приложить.
Зы. Так и думал что будут коменты про сторожей и охранников, кстати еще кладовщики есть.
Таким образом мы закономерно пришли к фрилансеру, работающему из дома.

Тут вопрос в переключении рода деятельности. Я пробовал кодить 312 часов в месяц, закончилось всё выгоранием.

В вашем случае фриланс — это почти свой бизнес. Перевести лошадку с рыси на галоп.

comerc
Объема заказов пока нету хорошего…
Нужен объем на 20-30 млн руб, тогда есть смысл, делать свою контору и уходить.
Даже на объем 5-8 млн руб, даже дергаться нету смысла, ведь с этих денег, мне достанется 40-50%
Но есть другие идеи…
http://forum.dwg.ru/showthread.php?p=1625178#post1625178

Заценил, прикольно! И про донаты мне нравится идея, нужна правильная подача.


Примерно в 2011 году залипал на сериале Тинькова — Секреты Бизнеса. Тетенька таскала шмотки из Китая, потом поставила 1С, и само попёрло. Почти в каждой серии подобные истории. Какой-то простой шаг приводит к мультипликации бизнеса.


Я тоже питерский, только уже 10 лет в скитаниях. :)

ХЗ…
Я сейчас понимаю, что сам не справлюсь с андроид приложением и с разработкой сайта на котором это тоже можно было бы крутить.
Плюс еще есть идея как делать 3d гифки из стереокартинок автоматически…
Подобные ресурсы есть но там надо делать карту глубин и т.д.
Т.к. понимаю, что для программы которая будет для широкого круга пользователей это должна быть программа совершенно другого уровня.

Это только один из миров, есть и другие, где могут быть нужны сложные программы, которые не тиражируются а пишутся для решения проблем ~1 заказчика (внутреннего или внешнего — не суть).

Согласен, но очень много моих программ, требуют доработки.
Кстати вот именно сейчас работаю над одной перспективной разработкой.
http://forum.dwg.ru/showthread.php?t=138766

А не подскажете дешевый способ 3D сканирования моделей для последующей 3D печати. Kinect вроде такое умеет, но очень сомневаюсь в точности его замеров.

Так David же…
https://www.youtube.com/watch?v=MEy8AgiRYwo
Да там самому собрать из подручных материалов можно.
У меня штуки 3 ардуинки валяются, одноплатников 3 штуки, есть и сервы и. Шаговый.

У мну руки заточены под клаву.

Аналогичная ситуация. Мне 35 и основная работа не связана с программированием, но, поскольку к этому тянет с детства(победы на олимпиадах по информатике в школе), уже много лет пытаюсь перейти в эту сферу. Когда я оканчивал школу, на наш местный ФАВТ конкурс был 10 чел. на место, поэтому пришлось пойти в электронщики. Потом, много лет спустя на одном из форумов электронищиков натолкнулся на книжку по программированию микроконтроллеров AVR — и тут понеслось!) Ассемблер, С++(благо базовые навыки были уже со школы — олимпиады!), Delphi. Потом появилась платка Raspberry Pi — разобрался с python. Приятным открытием стал факт, что на python можно писать не только скрипты на малинку, но и сложные серверные приложения. Ах да, параллельно изучил Android выпустив в playMarket пару приложений.
На сегодняшний день выполняю небольшие задачки на фрилансе(парсер, бот) в свободное от основной работы время. Пройти буфер HR тоже не удается)) Чтобы иметь в своём резюме какой-либо значимый проект, нужно уже быть в команде — один в поле не воин. Лично у меня выработались набор навыков, которые позволяют мне быстро освоить новое направление — я научился учиться. И мне нравится программировать.
Когда хочется освоить новую технологию (например React), то лучший метод обучения — это копирование существующего проекта с использованием требуемой технологии. Как минимум, для портфолио на GitHub.

тынц

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

Здесь два пути — либо вступить в команду либо собрать свою. Первый — не оставляю попытки, но, как уже писал, HR. Второй — Чтобы собрать свою команду и правильно её вести, нужно посмотреть как это всё работает изнутри, т.е. возвращаемся к п.1.
Либо «учиться» для примерного понимания процессов и собирать команду. И искать таких-же…

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

И уже предвкушаю каково будет проходить собеседование на позицию junior'а и работать бок о бок с тем, кому 18.

Сам занимаюсь только 4 месяца и попал на бесплатные курсы от одной компании, которая после курсов нанимает некоторых на позиции Джунов. Так вот, среди тех, кто захотел и прошёл тестовые задания достаточно людей за 30.
Пройти буфер HR тоже не удается

Буфер не всегда в виде HR.
У нас, скажем, на присланное резюме смотрят в том числе и технические специалисты (тим-лиды как минимум), а потом принимается решение стоит звать на собеседование или не стоит.
Хотя, думаю, может это зависит от конторы и поставленного процесса.
Я стал программистом в 50+++
Выручило то что
— в DSP области очень сложно найти специалистов,
— здесь многие старые знания в электронике просто трансформируются в свой дискретный вариант,
— в интернете куча шикарнейших лекций по математике и программированию (MIT, Стэнфорд, Беркли..)

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

Ждать до 50? :)
Хабр — это прежде всего очень сильно прошаренная публика…
Упоминание о MIT6.00 — первый курс лекций в интернете, который я прошел — я встретил на Хабре.
В таких курсах есть системность, причем обязательно надо про-решать и все задаваемые задачки…
По моему мнению, возраст — это чисто психологическое ограничение.
Начал изучать программирование еще в школе по книгам. Писал программы в тетрадке и проверял, по возможности, на компьютере у соседа. В колледже только купил компьютер (386 кажется).
В начале нулевых, когда закончил колледж, преподавал visual basic на компьютерных курсах для школьников. Потом несколько лет работал сисадмином на заводе.
Несколько раз поступал в универ и бросал. Так что высшего образования так и не получил.
К концу нулевых уволился с завода, снова занялся программированием и ушел во фриланс.
Сейчас 34 года, решил завести второго ребенка. Несколько лет интересуюсь психологией и вот в прошлом году поступил в институт на психфак.
Сколько помню, почти всегда занимался тем, что интересно и приносит удовольствие (как процесс, так и результат).
Одним из полезных навыков в современном мире, на мой взгляд является умение обучаться и переучиваться.
Не вижу смысла ограничивать себя возрастом и прекращать учиться — кругом слишком много всего интересного.
Раневская, кажется говорила: «Жизнь — затяжной прыжок из п… ды в могилу». А потом кто-то дополнил эту фразу: «и смысл жизни — прожить этот прыжок как можно радостнее».
Опять же, субъективно. Многие такой взгляд на жизнь не разделяют и предпочитают заниматься все время чем-то одним, чему обучились когда-то давно.
к нам на курсы пришел мужчина, ему 48, все норм

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

Ну даже не знаю. Зачем пытаться конкурировать с кем то? Это с самого начала ставит тебя в позицию догоняющего. ИМХО, но у возраста есть куча своих преимуществ которых никогда не будет у 18 летних. Усидчивость, терпение и желание разобраться и понять, а не тупо нагуглить решение, вставить и забыть. Современная молодеж застряла в складывании кубиков и любой шаг в сторону от собирания библиотек вызывает у них разрыв шаблона. Наблюдал такое не раз.
Самому 40 и работаю водителем, что никоим образом не мешает мне кодить долгими зимними вечерами в свое удовольствие. Подумывал устроиться програмером, но не готов к дауншифтингу по зарплате. Семья просто не поймет.

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


У меня есть сосед. Диплом 20-ти летней выдержки, по специальности не работал. Сбежал из Украины на заработки в Минск. Контроллером ОТК на сборке Кадиллаков. ЗП — $500. Контракт заканчивается. Убедил начать. Как минимум, ничего не потеряет. Посадил рядом стажером, этот проект реализовал под его наблюдением. Сорвал голос, проговаривая каждый свой шаг. Чем дальше, тем мне интереснее. А у него все меньше горел взгляд. И сдался.


Я несколько раз выгорал за все время, но что-нибудь пилить напильником — это моя базовая потребность. Найдите способ перейти Рубикон. Кстати, в 2003-ем на полгода нашел отдушину питерским ночным бомбилой.

Еще раз пересмотрел среднии зарплаты и как то даже сениор с опытом лет 10 не дотягивает до моего годового заработка. Особенно если учесть что живу я в деревне и никуда не хочу переезжать. Так что не понятно какой рубикон мне нужно переходить и главное зачем. Если можно тихо мирно в свое удовольствие собирать свой вариант hal9000 :)

Я вижу в тексте уже три причины оставить всё, как есть.

Спасибо, что разрешили. Программист, это ж орфография прежде всего! Но в целом ваше поведение это все что нужно знать о професиональных програмистах. :)

3 причины оставить всё как есть из вашего коментария


  1. сениор с опытом лет 10 не дотягивает до моего годового заработка
  2. живу я в деревне и никуда не хочу переезжать
  3. можно тихо мирно в свое удовольствие собирать свой вариант hal9000

Вы, похоже, поняли его как-то по другому.

Так и вопрос. Зачем внезапно нужно становится професиональным програмистом? Автор как бы подал все под соусом что кто не стал програмистом, тот вообще ничего в жизни не достоин. Бред же.

Я ни чего такого в его статье не увидел, возможно это ваше субъективное восприятие. Автор рассказывает историю своей жизни, ни кого ни к чему не призывает и не осуждает.
Мне 50. диплом я показывал всего один раз в жизни, в 17 лет, при устройстве оператором ЭВМ. Это был диплом об окончании школы. Дальше меня уже больше 30 лет переманивают. Первый раз переманили через два месяца работы оператором ЕС 1022 — на позицию джуниора. Ну и пошло-поехало.

А насчет смены профессии… моя учительница в АСТУП в 70 лет вышла на пенсию. Пошла вахтером в дом культуры. и через два года стала там главным администратором. Так что, если мозги есть, то и в 70 можно новую профессию освоить.

Лет десять практиковал подобный способ профессионального роста — не засиживаться на одном месте больше, чем год-полтора. Только меня никто не сманивал, искал целенаправленно сам.

Если не путаю, во времена моего детства это называлось бегунок. :-)
Такого человека называли — летун, а бегунок это обходной лист.

В советском лексиконе было много ярлыков, которые можно на меня повесить: спекулянт, барыга, цеховик, бомбила, тунеядец, бомж, карьерист etc.

Все равно, уходить до окончания проекта — это себе карму портить.

Уверяю вас, от моего ухода не пострадал ни один проект. А может даже выиграл.

Если находишь лучшее себе применение, все только выигрывают.

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

В целом это спор о терминах, конечно. Просто терминология разная.
Главный вопрос сколько это длится, если больше года, то можно со спокойной душой менять работу. Если больше года — для меня это уже категория «бесконечности».
Ну вот проект, о котором я все не могу дописать пост — это порядка 10 человеко-лет и примерно 3 года работы. Вторая установка того же софта — полгода (и того и того).

Уход основных участников (трое из шести) — это было бы очень критично.

Несомненно, но человеческие жизни первичны, а работа вторична. Если нужно столь долго удерживать персонал — то нужно хорошо их мотивировать. Я бы не стал осуждать людей за уход в таком случае, за 3-5 лет может очень многое изменится. Банально может машина сбить. Это очень опасное мероприятие как по мне.
По мне, так 10 человеко-лет — это немного. Бывают проекты и больше. А вместо пяти джуниоров лучше взять одного «незаменимого» сеньора. Ну и оплачивать его так, чтобы не ушел.
С человеко годами у меня проблем нет, есть вопрос касательно размера команды, 3 года до первого релиза имхо очень долго. В современном мире это просто ужас как долго, за это время целая отрасль может закрыться, или новая открыться. Один сеньор это одна точка отказа, лучше собрать нормальную команду которая справится за год.
Если 9 беременных женщин собрать вместе — ребенок через месяц не родится. Очень советую почитать эту книжку. Там есть и хороший пример, как 10 сеньоров пытались заменить на 700 «нормальных» программистов, и как это решение затянуло сроки.

Опять-таки, не очень понятны слова «первый релиз». Это примерно как "осетрина второй свежести". В АСУТП релиз один. Это переход из опытно-промышленной в промышленную эксплуатацию. А до того — от полугода до двух лет опытной и опытно-промышленной эксплуатации.

В опытную — можно и MVP запустить, если нужно. Но… вы согласитесь покупать MVP вместо автомобиля или стиральной машины? :-)

Что касается сроков, то на какой-нибудь Северстали или НорНикеле переговоры о создании системы занимают 2-3 года. Это ещё до подписания договора.

Ещё раз убеждаюсь, что АСУТП и настоящее программирование — это два разных мира.

P.S. В качестве бонуса - история о спешке.
Один цементный завод решил запустить цементные фильтры до готовности софта (примерно на полгода-год раньше). В итоге не уследили за очисткой и фильтр упал под собственным весом.

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

Но как мы были рады. что ни одной нашей подписи на решении запускаться без автоматики не было. А уж как рады заводчане, что обошлось без человеческих жертв…

Ещё раз убеждаюсь, что АСУТП и настоящее программирование — это два разных мира.

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


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


Другое дело какая-нибудь пожарка, где ошибка в нормальном случае обернётся штрафом, в более весёлом — затоплением этажа, и до человеческих жертв в плохом раскладе.


В некоторых областях АСУТП можно ещё большие масштабы разрушений и жертв найти. Суть от этого не меняется, просто другие риски.


В общем, разработка ПО или ПАКов — она в общем-то едина. От крайности типа "вывести продукт технологичного стартапа на рынок за три месяца, т. к. дату запуска уже анонсировали", где нужен некоторый минимальный уровень качества, чтобы оно вообще как-то заработало (т. е. классический херак-херак и в продакшн). И до встроенного ПО для life-critical систем, где за надёжность готовы платить (в том числе сроками выхода на рынок/внедрения). Кому-то три года кажутся огромным сроком, а кому-то и ~10 лет очень неплохо, например, если это авионика.

Судя по вашей ссылке, АСУТП и АСУ относится к внутреннему ПО

Ошибки в работе той же вентиляции обычно не несут рисков жизни и здоровью людей

См. пост выше. Цементный фильтр — это как раз вентиляционная система. Но то, что фильтр упал без жертв — это чудо.

Суть от этого не меняется, просто другие риски

Ну как вам сказать… Если сильно обобщать, то и проектирование жилых домов — та же самая инженерия. А если не обобщать, то миров получается не 5, а намного больше. Та же авионика — вообще отдельный мир.

Собственно, если поработаете в АСУТП — увидите отличия.
Судя по вашей ссылке, АСУТП и АСУ относится к внутреннему ПО

Никто не говорил, что список от Joel'а будет полным. Оно обладает чертами как внутреннего ПО, так и embedded. В зависимости от требований какие-то части вполне могут переиспользоваться и продаваться как типовые решения, которые на месте проходят конфигурирование и пуско-наладку.


Собственно, если поработаете в АСУТП — увидите отличия.

Спасибо, поработал уже. Мне эта область не по душе. Куда ближе некоторые другие, где сейчас и работаю.

Про отличия конфигурирования от программирования можно книги писать… Вон 1С — конфигурируется или программируется? :-)

А что не по душе — ну так на вкус и цвет все фломастеры разные.
Собственно отличия АСУТП от настоящего программирования примерно такие:

  • Это внутреннее ПО, функциональность важнее простоты использования
  • Разработчик АСУТП должен понимать автоматизируемый техпроцессс на уровне заводских технологов с 20летним стажем (лучше — ещё лучше)
  • Отказы оборудования штатно учитываются софтом (это особенность российского АСУТП, американцы обходятся без этого)
  • В целом АСУТП очень близко к DIY, но DIY за деньги. Отсюда большие отличия от настоящего программирования, но близость к разного рода колхозным решениям
Это внутреннее ПО, функциональность важнее простоты использования

Это довольно часто актуально и в других немассовых продуктах, когда софт используется относительно узкой аудиторией. И в "ширпотребном" (в терминологии Спольски) софте типа, скажем, разных CAD/CAM, медицинского софта, кучи банковского и учётного софта, среди написанного программистами для программистов и куче других областей. Это не особое дискриминирующее отличие АСУТП. Это отличие массового софта рассчитанного на широкую аудиторию от специализированного.


Разработчик АСУТП должен понимать автоматизируемый техпроцессс на уровне заводских технологов с 20летним стажем (лучше — ещё лучше)

Это применимо для многих областей автоматизации. Понимание домена — важный фактор при разработке любого сложного софта. Иначе он окажется куда менее полезным "пользователю".


В целом АСУТП очень близко к DIY, но DIY за деньги. Отсюда большие отличия от настоящего программирования, но близость к разного рода колхозным решениям

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


Повторное использование, конечно, значительно меньше, чем в каком-нибудь вебе, который вы, похоже, считаете единственной областью "настоящего программирования", но тоже присутствует у многих. Говорю на примере работы преимущественно в области HVAC с проектами на базе разных ПЛК от Segnetics, TAC/SE, Carel, Necos/Danfoss (возможно, кого забыл).

Тиражируемое ПО — это все-таки не совсем АСУТП. Это некий конструктор, конфигурированием и/или программированием которого мы получаем АСУТП.

Насчет понимания предметной области — зайдите на сайт любого интернет-магазина. И сравните с сайтом Мосигры (среднее время на сайте 20 минут). Опыт показывает, что в 99% случаев сайт интернет-магазина и программируется и наполняется без понимания предметной области. И ничего, работают, торгуют.

Колхозить — это достигать нужного результата самым эффективным путем. Когда заказчик — мы сами, то мы знаем, что нам нужно (а что — не нужно). В этой ситуации не нужны лишние заделы на случай неожиданного изменения ТЗ. Примерно так и в АСУТП, ТЗ известно и в ближайшие лет 10 модернизация не потребуется (ну или известно что именно потребуется менять).

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

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

В АСУТП все наоборот. Первый релиз — зачастую последний, ТЗ — четко очерчено…
Любую идею можно довести до абсурда, себе на радость и людям на потеху. Если вы утверждаете что ваш проект нельзя сделать быстрее при использовании большего количества качественных ресурсов — я не стану с вами спорить, вы несомненно ближе к вашей задаче, чем я. Но я нахожу это странным, почти всегда можно разбить систему на более мелкие кубики и раздать работу на большее количество рук. Важные блоки оставлять на супер синьоров, попроще отдавать синьорам по проще. Вариант взять джуниоров как основную рабочую силу я не предлагал и не одобряю, задача джуниора учиться и выполнять рутину, количество джуниоров решение больше кадровое, чем продиктовано самой задачей.

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

Не могу удержаться от видеоцитаты



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

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

Хорошее разделение идет на подсистемы, которых обычно не так много (5-10, не больше). А вот написание подсистемы — это аналог конвейера. Деление подсистемы на части (мелкие модули) увеличивает и объем спецификаций и объем кода.

В опытно-промышленной эксплуатации, если все хорошо — то, действительно, можно ничего не делать. Следить за системой и править редкие баги. Но, если ошиблись в какой-то ключевой характеристике (скажем в производительности), то нужна вся исходная команда, чтобы исправить ошибку. Потому, что самый тяжелый вариант — это изменение архитектуры.
Да само собой, только вот если построить график роста суммарной производительности труда, от количества персонала, то будет виден перегиб в точке, после которой новые люди только мешают. Если ваша команда в 6 человек как раз находится в этой точке — то все супер. Но для меня это выглядит странным, возможно потому, что я не работал в АСУТП, в обычных проектах на 10 человеко лет, очень часто можно набрать больше народу и что-б локтями не толкались. Часто есть модули которые вообще легко делить, например интерфейс пользователям, всякие там отчеты, веб страницы, разные способы уведомления. Как по мне любую задачу можно разделить на 4 класса задач: сбор, хранение, анализ, вывод информации. Сбор, хранение и вывод можно легко пилить и раздавать, анализ лучше поручить небольшому количеству людей. Если у вас там анализа 80% то это уже какая-то ядерная физика выходит. Пока что это все выглядит очень странно и не понятно, хотя вполне вероятно что вы правы.
Было бы отлично если бы вы написали статью на этот счет, с особенностями работы в АСУТП.
Ну давайте посчитаем. Интерфейс пользователя — это десяток таблиц, примерно по 2 дня на таблицу. Ну и библиотека, позволяющая быстро писать таблицы с сортировкой и поиском — её писал отдельный человек.

Если я пишу интерфейс один — это 2*10= 20 дней. Если я отдаю эту работу 10 людям, то каждому из них потребуется недели три на обучение и библиотеке и тому, откуда брать данные для таблиц. То есть каждый затратит 21+2= 23 дня, а я эти три недели обучения буду занят на 50% объяснениями. То есть мои затраты — 0.5 на 21 — 10.5.

Итак, 20 дней для одного человека и 23*10+10.5 = 240.5 дней для команды из 10 людей. То есть в 12 раз больше трудоемкости.

Со сбором информации ещё хуже. Прежде чем писать работу с контроллером, надо прочитать документацию. А это полка на английском. И читалась она примерно полгода.

А статью. про этот проект напишу. Она уже давно начата, но все времени нет дописать.
За три недели можно выучить новый язык и фреймворк. Пол года читать про контроллер звучит совершенно не реально. В моей практике обычно ввод в курс дела это около 4-8 часов самостоятельного изучения по готовому коду без комментариев и подсказок. Про мк не берусь судить, но тоже звучит дико, за пол года можно взять стерильного студента и обучить как мне кажется, а если это синьор с опытом, то ему наверное и вообще ни чего читать не нужно.
Неужели в мире столько разных МК, что нужно про каждый читать по пол года?
u010602
Неужели в мире столько разных МК, что нужно про каждый читать по пол года?

Одному программисту при разработке ПО для пульта управления телеком надоело читать по полке доков по полгода и он пришёл к руководству с заявлением на увольнение.

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

Так родилась… Java. ©
Ну давайте посчитаем. У меня средняя скорость чтения (и запоминания) технического текста на английском — 20 страниц в день. Документация по контроллеру — порядка 5000 страниц. Итого — 250 дней. Пример: CPU software — 670 страниц, CPU harware — 423 страницы, а вообще-то док много. Примеры по чуть другому контролеру — наш устарел за 15 лет.

«Новый язык и фреймворк» — это где-то тысяча страниц. С учетом скорости чтения на русском 50 страниц в день — как раз за 3 недели и получится.

Неужели в мире столько разных МК, что нужно про каждый читать по пол года?

Что вы называет МК? Микрокалькулятор? У нас ПЛК

Все от задачи зависит.

Если у вас задача написать программу на ПЛК — то вам много читать и не нужно: стандартный Ladder и всё. Конфигурирование ввода-вывода сделают старшие коллеги.

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

Какой-нибудь оптимизатор кода или статический анализатор — это были мелкие добавки к тому, что мы делали.

Основное — это запись всех переключений входов и выходов с возможностью проиграть, что происходит в потрохах ladder. И не просто проиграть, а по изменению состояния выхода просчитать, какой вход привел к такому изменению. Причем просчитывали — в 99.7-99.9%.

Ну вот вам аналог для JS. У вас на сайте есть индикатор, который меняет цвет на красный. Использую код сайта и запись того, что делал пользователь и что пришло по сети (AJAX), определите, что вызвало изменение цвета индикатора. При этом код сайта — любой.

Чувствуете, что вам потребуется совсем иной уровень знания языка и аппаратуры?
Везде бывают сложные технически и архитектурно задачи, но они редкие и их можно использовать повторно. Условно говоря после создания вашего продвинутого дебаггера\логгера его можно использовать везде, на каждом объекте. Откуда могут браться каждый раз новые технически сложные задачи? Другими словами в прикладном программировании есть патерны и типовые подходы, не сказать что они сильно сложные, можно придумать самому можно взять готовые из книг, и они покрывают 90% задач. Т.е. по сути программирование это рутина, если-бы не выходили новые языки и платформы — то там и учить нечего было бы. Ради интереса можете посмотреть сколько новых публикаций по .net или java, и дело не в том что они умирают, а в том что там особо и писать не про что. Я вот ни разу еще не испытал необходимости задать новый вопрос на форуме или еще где. На любой вопрос — уже есть ответ. И наверное так у любого языка старше 5 лет.
Мне не понятно зачем делать новые микроконтроллеры и ПЛК, которые на 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 за два месяца
Программист — рабочая лошадка любого проекта. И проблемы «профессионального роста», это больше не вопрос к самого программисту, а к тому, какой работой он занимается. Здесь кроется какой то «парадокс». Если программист занимается тем чем нравится — это не приносит карьерного роста и денег. Я работал с многими программистами в связке, по реализации проектов. И как то для себя понял, что чем разнообразнее проекты, чем больше НЕ стандартных заданий (от исправления кода, до запила «костылей) тем программист становится более опытным. И по мне, все равно все сводится к тому, на сколько изящным будет решение технической задачи, с помощью программинга. В конечном итоге, высококлассный программист это человек, который четко понимает что он может сделать, и какие ресурсы для этого понадобится.
Судорожно рука тянется к ASM
Но глаза боятся

А чего такого? Никто не осудит! :)

Пофиг на мнения других.
Как писал Крис Касперски каждый ASM имеет свои специфики.
TASM, FASM, NASM и прочие имеют только им своественные команды.
Так что скачав с интернета сорцы на асме в первую очередь нужно догадываться под какой транслятор писалось.
В кодах обьяснений обычно нет.
Как-то так...

Хе, это ещё всё x86, и, если правильно помню, все в intel-нотации. На x86 ещё встречается gas (благо отличить просто, но регулярно переключаться очень раздражает). А ещё есть огромный мир за пределами x86 и amd64, а там свои ассемблеры.

Ага особенно формат синтаксиса AT&T

Я начал изучать программирование второй раз в 26, после 10-летнего перерыва. Первые два года мог что-то делать только один день в неделю, дальше плавились мозги. Потом начал искать работу, два года мыкался и однажды более-менее повезло, нормально трудоустроился. Потихоньку втянулся, еще за год освоил jQuery ajax и еще за год sql-оператор join. Потом два года развивал и углублял навыки, не переставая читать хабр. Создал вконтакте группу по программированию. Теперь работаю ведущим разработчиком.
Мне очень понравились задачки на sql-ex
Там же есть теория.
Ну если по рабочей необходимости писать только один join раз в два-три месяца, то быстро все забывается и как следует сразу не закрепляется. В течение года приходилось подглядывать в справку.

Эх, как же откликается статья. Саи ушел из чистого ИТ лет 17 назад. Сейчас почти 40 и понял, что хочу обратно. Но не в админство, а во фронтендеры. Для начала. И не в офис, а либо в удаленку, либо во фриланс. Пока осваивать новое получается плохо. И основное ограничение, совсем не в ухудшении свойств соображалки. Самая большая проблема — банальный быт. Когда ты уже врос в устоявшуюся систему и есть работа (пусть не любимая), но ее надо делать и после нее часто выжат как лимон; когда есть жена и ребенок, котрых хочется видеть не по 15 минут в день и которые тоже хотят чтобы муж/папа уделял им бОЛьшее время; когда есть новая квартира/ипотека которую надо обустраивать/оплачивать; когда болеют постаревшие родители и бросаешь все неосновное, когда надо помогать. Когда… да навалом этих когда у каждого. Из-за всех этих "когда" уже не получается вечерами просиживать над книжками/за компом, как это было ранее. И переползание на новые рельсы происходит очень медленно. Часто на новое выделяется максимум час рано утром, пока твои спят. Или не выделяется вообще, т.к. из-за житейских дел накануне лег далеко заполночь и не можешь оторвать себя от подушки. Быт и система в которую врос — вот основная проблема. Это не преграда, но "груз", с которым идешь гораздо медленнее. И с этим приходится примиряться.

Всегда вспоминаю эту историю (скомунизженно с просторов рунета)
Вера в успех

История скорее не забавная, а поучительная.

Было это года четыре назад. Лето. Жара нещадная. А я начал на своём участке делать подвал. Так как дело было в строительный бум, то помощников найти не удалось: все заняты до осени (даже подростки 14-18 лет куда-то делись). А подвал нужен и очень. Если читатель никогда подолгу не сидел на дне здоровенной глиняной ямы в солнечный день, то передам ощущение: пустыня Сахара в безветренный день. Спустя пару недель таких работ чувствую: «Всё. Сдаюсь».

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

Дело было после войны. Было ему 16 лет и задумал он жениться. А чтобы было куда молодую жену привезти — нужен свой дом (он же мужчина!) Землю для строительства раздавали всем желающим, а вот со стройматериалами — беда. Все лимиты расходовались на восстановление заводов. Купил он в итоге мелкого шлака (у нас в Туле металлургический завод), добыл где-то не-то известь, не то даже цемент и начал лепить кирпичи. Каждый день он вставал в 4 утра и до 7 формовал кирпичи. Потом шёл на работу. После работы — вечерняя школа. И так 2 года. А через два года он за неделю сложил из этих кирпичей домик (соседи помогали всей улицей. Единение Народа-Победителя действительно было, чтобы там в учебниках по истории изданных на средства американских грантодателей не писали), где он и прожил до глубокой старости со своей женой. Своё хозяйство: огород, козы. Благодать.

P.S. После разговора с ним, окрылённый чужим успехом (у него даже материала не было, а он целый дом построил!), доложил я очередной ряд кирпича и поехал домой. А по дороге выяснил, куда делись все мои потенциальные помощники. В автобусе ехала целая компания ребят (17-20 лет). И один из них выклянчивал у своей матери деньги: «Мам, ну мам! Дай мне денег! Сегодня же День Пива! Вся Тула будет на Площади! Я свою девушку хочу пригласить! А то только через компьютер общаемся, как маленькие!»

Отличная история, спасибо! У меня в качестве такого старичка выступает желание заниматься любимым делом и быть больше с семьей. Зажолбало 5 дней в неделю просыпаться с мыслью "блииин, опять на работу...". Так как четко помню период, когда мысль была "Хо-хо, на работу скорей! Я же вчера еще вот с этимм и этим не разобрался!"

Быт и система в которую врос — вот основная проблема. Это не преграда, но "груз", с которым идешь гораздо медленнее.

В этом смысле мне очень нравится фильм "Марсианин". Любой новый удар судьбы — это просто изменившийся контекст для принятия новых решений.

а интерфейс — функция состояния :)
(в идеологии react-redux)
Сейчас обитаю в Минске. Снимаю комнату в котедже. Соседи-алкоголики, чтоб жизнь малиной не казалась. Тёплый гараж в подвале. Кладовка для накопленных пожитков. Баня. Участок с яблонями-грушами. Поставил старенький караван на вечную стоянку — летом вместо дачи, комфорт на нужном уровне: кондей, холодильник, спутник, вай-фай. Свой лучший код пока не написал, но все условия подготовил. Скоро май.


Отлично пишите!
Привет вам из Минска.

И удачи. Она вам, похоже, нужна.

Удача — такая приятная барышня, что всем нужна. Спасибо.

Недавно узнал, что даже в Америке 12 лет стажа приравнивают к диплому. В Европе меньше.


А могу я попросить уважаемого автора дать ссылку на источник сей информации?
Гуглил — не нашёл. Хотя, допускаю, что не так спрашивал.
ЕМНИП там даже меньше опыта требуется, нет?

Я не помню. Совсем недавно наткнулся.

Не будте дебилами, у меня бывший колега ломанулся из программаторов в бизнес. Решил покупать участки и строить дома на продажу. Итог: денег нет, так как в этом секторе бешанная конкуренция, перспектив роста нет, так как не денег, в профессию вернуться не может из-за долгого перерыва. Воет на луну.
Клуб анонимных быдлокодеров:
Здравствуйте. мне 40. И я быдлокодер. [одобряющие, но тихие апплодисменты].
да не. скорее хочу присоединиться к клубу.
У меня тоже караван 99, но дачу пока строю. Вместо кодинга предлагаю подумать сделать что-то свое, софт, сервис, сайт, железо.
Создание своего продукта или услуги требует не столько технических навыков, сколько маркетинговых
Согласен, но лучше попробовать, чем лежать на диване.
Цель — план — исполнение — результат — коррекция ошибок — следущая цель -…
но лучше попробовать, чем лежать на диване.

Лучше «попробовать» что? Какая цель? KPI какой?
Если не рассматриваем действия «non profit», то Активы по результатам действия должны быть не меньше, чем в начале.

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

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

Случайно нашел в этой теме свой комментарий: "Мне 40 лет. 18 лет сисадмин. Пытаюсь свитчиться в dev-ы.". Вот он https://habr.com/ru/articles/323460/#comment_10109658
Кароче все получилось, я разраб уже 6 лет. Теперь уже 3,5 года на удалёнке ))

Sign up to leave a comment.

Articles

Change theme settings