
Комментарии 8
Вообще-то самая здравая идея - это применять программирование к повседневной деятельности. Потому что оно - инструмент: само по себе не шьет, не жнет, и не кует. Понятно, что будут специалисты, которые концентрируются именно на написании программ общего назначения и фреймворков. Но вообще-то чистые программисты в нормальной обстановке не нужны в таких количествах. На предприятии моих родителей прямо говорили: проще научить радиоинженера программировать, чем программисту объяснить методику расчета СВЧ-антенн... :-)
Программисту непросто объяснить методику расчёта и совершенно невозможно написать формулы либо ТЗ. Но скажите, на чьей стороне здесь проблема?
Проблема в том, что прямое решение уравнений Максвелла для электромагнитного поля (этакая "теория всего") - запретительно дорого (в смысле вычислений) даже сейчас, а тем более в 70-80е. В результате, радиотехника СВЧ распадается на локальные теории для разных задач, имеющие свои границы применимости. И для того, чтобы применять (или не применять) определенную формулу - надо понимать физику процесса. Плюс понимание ограничений технологических процессов, чтобы был не только теоретический результат, но и в серии выход годного... И в сухом итоге - то, что написано выше: проще готового инженера-радиотехника научить фортрану (или прости господи, бейсику) - чем пытаться объяснить все эти теоретические и практические материи чистому программисту... Ну или расписывать программу на естественном языке, так чтобы программист работал чисто переводчиком (типа вайб-кодинг, только все участники - живые люди). Но в последнем случае тупо получается что та же самая работа будет дороже (две зарплаты вместо одной), дольше (время на взаимные коммуникации), и скорее всего - хуже.
я также примерно так начинал. потом погрузился в контроллеры, асутп, и т.д. и т.п)) деньги не космические, зато любимое дело.
Вы на правильном пути. Удачи!
я в советское еще время наблюдал, когда прикладное программирование у инженеров было обязательным навыком - кто не умел составить расчетную программу, считался профнепригодным. И для меня шоком стало в 2010-х, что, оказывается, можно было окончить факультет АСУ и понятия не иметь, что такое цикл.
Сам давно подбираюсь к швейной машинке жены - Yuki, там есть вход для управления и загрузок программок, поковырял интернет - программуля для создания своих программ или для загрузки каких-то шаблонов вышивок стоит аж 70 тыр, вот жду, периодически пингую тырнетик этим вопросом, пока не ломанут или не дадут на форумаз какое-то относительно ясное указание, как ухватиться за хвостик задачи передать умной машинке программу.
Полностью поддерживаю! Сам увлекаюсь программированием и совмещаю основную деятельность.
Но все же посоветовал бы пройти какие-нибудь курсы, например full stack, разобраться докером и гитхабом. Это сразу выводит на совершенно новый уровень, пуcть даже и оставаясь программистом-любителем исключительно для себя или коллег. Начинаешь получать настоящий восторг, когда твои программы написаны с учетом современных паттернов и четко структурированы. На обеде твои коллеги предлагают что-то улучшить, а ты сразу же в ходе разговора можешь добавить новую хитрую «фичу», потому что у тебя есть четкая логика и структура в программе, а для основных функций написаны тесты, и ты уверен, что они уже не слетят. И до конца обеда уже все готово.
И совершенно верно - лучше тебя твои бизнес-процессы никто не знает, и профессиональной команде программистов/аналитиков зачастую довольно сложно объяснить, что от них требуется, т.к. у них в твоих вопросах чисто бытовой опыт. В моей практике было, когда сроки контракта были исчерпаны и его пришлось расторгать из-за разного понимания понятия «проверка», которое на различных этапах обозначало совершенно разные функции. Это как слово (сахар) «песок», и ты ждешь кулинарный миксер, а на приемку исполнитель приволок бетономешалку, да еще чайную ложечку самовольно заменил на лопату, полагая, что заказчик дебил.
на неком малом, любительском уровне и получать с этого пользу
Несомненно, но когда такое становится одним из весомых аргументов в пользу обучения сложному и времязатратному ремеслу, то несомненно есть какой-то кризис или просто метаморфозы отрасли, после которых она уже никогда не будет прежней...
Инженер должен уметь делать рассчеты - это его определение. Не все рассчеты легко запрограммировать, инженерные задачи часто бывают слишком сложными, чтобы их можно бы запросто запрограммировать "на коленке", как правило, есть специализированный софт, который пройдя проверки, был признан годным для решения конкретной инженерной задачи.
Переписать рядовому инженеру, занятому оперативной рутиной на предприятии, такую программу вряд ли возможно. Ну, конечно, какую-то python-автоматизацию или Excel-автоматизацию той самой рутины можно и написать.
Но не надо забывать, что инженерное дело ответственное, и каждая самодельная, да и не только самодельная программа может нести в себе определенную опасность.
Любительское программирование, как оптимизация рабочих процессов