Комментарии 70
Прочитайте манифест об Agile и вы поймёте что никогда не работали по Agile! На самом деле в РФ, Agile встречается крайне редко. Часто это Совок-руководитель + Kanban. По тому, что Agile сложен в понимании для менеджмента. Хотя об этом стоит сожалеть так, как лучше Agile никто, ничего, ещё не придумал.
Вы все же наверно имели в виду Scrum, а не Agile
Лучшая методология- Agile в его классическом виде. Scrum и Kanban это популярные примеси в Agile которые уводят от его от классического вида.
Согласен с посылом, но есть нюанс. Agile — НЕ методология и НЕ методика. Манифест не может быть методологией или методикой уже потому хотя бы, что он — всего лишь декларация принципов и целей, но никак не способов (методов) реализации и достижения этих принципов и целей.
Scrum/Kanban — это как раз частные методики. А проблема тех компаний, которые громко и гордо трубят о своей “эджайловости”, заключается — на мой взгляд — в убеждённости их менеджмента, что эти (или ещё какие более другие) частные методики и есть собственно Agile.
А как вы определяете методологию
Agile среди прочего говорит: нужно проводить оценку в сторипоинтах оценивая сложность задачи, потом начать реализовывать и посмотреть сколько сторипоинтов может реализовать команда за спринт и через несколько итераций можно будет прогнозировать сроки реализации проекта, при этом реализация должна быть в лучших практиках программирования (надёжность, поддерживаемость, масштабируемость) - это описание методов работы с проектом, следовательно методология. Scrum говорит о проведении дейли и ретроспективы для сверки часов в команде - это в принципе важно. Kanban говорит про удобство использовать доску с тикетами, бэклог и дедлайны. Дедлайны не коррелируются с Agile потому, что задача должна оценивать не в часах, а в единицах сложности - сторипоинтах. Тут появляется проблема менеджеров - они должны сами сначала определить дедлайны проекты, потом всех усадить в галеру и погонять стремлением соблюдать дедлайны. Потом появляются вопросы поддержки когда. В тоже время Agile говорит как сделать поддерживаемых и качественный код, но без дедлайнов с примерным сроками, т.е. оценить задачи по сложности и в процессе движения определить время выхода реализации и сроки поставки кода, а не наоборот.
Да вы сами не понимаете agile, судя по вашим словам. Поделитесь-ка с нами, что есть agile в чистом классическом виде, а я пока посмеюсь. Канбан, скрам - это все якобы практические методики, как следовать по agile пути. Но ведь agile понятие совсем молодое. А канбан существует уже очень давно. Даже скрам раньше agile появился. Вы ради интереса почитайте историю, а не только манифест. Историю скрама, историю развития канбан, откуда agile понятие появилось, как его постулаты на горнолыжном курорте в юте сформировали пара десятков разработчиков на расслабоне под коктельчиками. А потом уже что-то пишите.
А где с этим можно ознакомиться?
На пикабу сходите посмеяться!
Об истории.
Кабан придуман менеджерами для менеджеров в автоконцерне тоёта. Менеджеры любят круглый столы пиджаки и галстуки и менеджеры тоёта были при полном параде когда думали про принципа Канбан. Agile придуман программистами в стенах компьютерных лабораторий исследовательских институтов для программистами, а озвучен и сформулирован был на горном курорте потому, что программисты любят свободную атмосферу, свободную одежду и творчество - поэтому сформулировал принципы Agile для других программистов в свободной, непринуждённо атмосфере. Как я уже отметил кабан был придуман на автозавода.
Итак, стоит отметить что в производство авто и ПО нет ничего общего. Применяя канбан в разработке по менеджер лепит горбатого применяя чуждую методологию для исследовательской, творческой работы. В тоже время если тех дир внедрил Agile в работу своей команды он применил методику сформулированную наиболее опытными программистами мира, разработанную программистами для программистов и предусмотренную непосредственно для разработки ПО.
О скрам. Скрам подразумевает ежедневные дейли - ничего в этом плохого нет, это применимо к любой сфере.
Как бы такая история.
Я чёт не понял, а чем программистам не подходит принцип "толкай правые карточки"?
И не поймете, потому что этому товарищу не нужна логика в его вере. Там такие предрасудки и невежество, что я даже отвечать не буду. Пусть и дальше верит в великий и неведомый agile. Кто я такой, чтобы мешать ему. Лично мне, как менеджеру, куда больше импонирует японская философия кайдзен и lean-подход. А уж по какой методологии вести проект это не самое главное, все зависит от проекта. На поддержку канбан, на мелкий разовый проектик waterfall, на длинный проект без конца и края - скрам. А еще многое зависит от компании-разработчика. То что хорошо подходит продуктовой разработке, плохо подходит аутсорсеру. И наоборот. Т.к там цели не совпадают. И метрики успеха разные. Поэтому часто в работе применяются гибриды. Каскад для оценки и планирования, скрам - для работы, это очень частый пример. Или псевдо-аджайл (потому что так клиент попросил и в целом это модно).
Статья переводная и состояние Agile в РФ автор оригинала полагаю учитывал менее всего. Возможно проблема интернациональна?
Время, когда программой, которую записал на дискету, можно пользоваться годами прошло. Теперь нужно постоянно обновлять ПО. Частично это обусловлено тем, что нужно удалять уязвимости, но, я думаю, что большая часть изменений или из-за денег (так как изменения приносят деньги всем, кто занят или связан с разработкой) или из-за того, что изначально плохо понимали, что хотели получить в итоге.
Для B2C отрасли вот это "плохо понимали, что хотели получить" - практически неизбежность. Потому что ТЗ пишут одни, а пользуются (и приносят деньги) - другие. Причём эти другие влёгкую могут взять продукт и начать использовать его совершенно не так, как задумано было.
И хотя в арсенале продуктовых аналитиков и менеджеров куча инструментов и методик, подход "дай живым людям попользоваться и посмотри, как именно они будут это делать" в итоге оказывается оптимальным.
Не забывайте, что это всего лишь точка зрения автора в переводе. Я вот не согласен. Всегда было и будет по закону Парето: 80/20.
Где-то в пути мы забыли о мастерстве программирования
Да не забыли, что вы такое говорите.. Просто не каждому оно требуется, вот вам для сравнения массив дерева:
Один мастер из сотни тысяч наберется терпения и сделает такое. В том числе и для души. Остальные 99.999 будут клепать табуреты и тумбочки, чтобы удовлетворить нужды массового потребителя.
Встречный (и довольно спорный) вопрос: кто заработает больше в единицу времени?
Ложная дихотомия "вычурный сверхдорогой кич" vs "убогий стол из ДСП". Можно делать и просто и стильно и качественно и для массового потребителя, как делает Ikea.
Убогих столов из ДСП в мире программ тоже полно, это те, что и сделаны наспех, и качеством не блещут. ИКЕА тут скорее занимает нишу "выглядит красиво, но как сделано - лучше не знать". А есть программы, подобные такому вот вычурному столу. Делались долго, под конкретного заказчика. Выверялась каждая строчка, каждая заковырка. Но и пользуется результатом кто-то один, готовый оплатить единолично много месяцев труда команды программистов. Кто-то, кого вы даже не знаете.
Оба варианта должны иметь место, навряд ли кто захочет ждать 10 лет программу, в которой ни единого бага. Возьмут с полки то, что есть сейчас, и начнут привыкать к своему столу из ИКЕА.
Добавлением третьей опции вы превратили ложную дихотомию в ложную же... трихотомию (?). Спектр тут практически непрерывный, причём распределение мастеров по нему зеркалит распределение клиентов - иначе мастерам быстро становится нечего есть.
И да, в ПО то же самое. Сами кривые распределения разные, но принцип тот же.
Тут в точку, прав на все сто. От нас, людей, потребителей и пользователей зависит все. Нужен бы был нам всем качественный продукт, ценили бы мы себя больше и не засоряли все вокруг дешевым ширпотребом - и был бы качественный продукт. С душой.
Не поднимаю, конечно, вопрос финансового благополучия людей и остального, но смысл ясен.
Заработает, конечно, штамповщик массового шлака. Так теперь, увы, все работают.
А как человек без профильного ИТ образования способен отличить качество софта?
Если качество софта не видно снаружи - значит оно не так и важно.
Даже если этот некачественный софт управляет самолётом в котором вы летите со своей семьёй?
Намёк на то, что самолёт упадёт? Так это и есть "видно снаружи".
Ошибка может произойти внезапно или послужить базисом для крупномасштабного взлома или катастрофы (как с боингом 737 МАХ).
А еще как было, например с одним взломом соцсетки для знакомств и измен, когда утекшая БД переписки стала причиной множества семейных драм и буквально смертей.
Там до поры до времени тоже было всё окей и не видно проблем для конечного пользователя.
Еще раз хочется упомянуть, что в таких сложных вопросах как качество и безопасность ПО не может быть простых формул и ответов. И тем более простые аналогии не могут быть базисом для аргументации.
Так же, как человек не сведущий в химии или лабораторных методах анализа способен отличить качество воды - с помощью органов чувств.
Если пускаться в софистику по полной и считать, что человек способен при помощи чувств отличить вредное от не вредного, то не существовало бы алкоголизма.
Я немного о другом. Для пользователя, который не лезет в дебри кода, качество софта определяется тем, как оно выглядит. Как функционирует. То есть, с помощью органов чувств определяет, насколько для него приемлемо качество продукта.
Если, к примеру, программа для воспроизведения mp3-файлов умеет менять внешний вид, в нее встроен эквалайзер, есть удобные меню для поиска и выбора файлов и она не дергается при работе с длинными композициями, то это хорошая программа. И пофиг, какой там код.
Вода для него или вкусная, или нет. Или прозрачная, или нет.
В случае с самолетом и его софтом - здесь речь о другом качестве софта, его безопасности. Это уже на глаз не определить (как, скажем, содержание в воде вредных бактерий или солей тяжелых металлов). Нужны лабораторные анализы. Но и об этом простой пользователь задумываться не будет, пока не рухнет самолет или пока он не отравится водой. В такой ситуации ему стоит довериться поставщику услуг, т.е. авиакомпании или водоочистной станции. Вот они уже должны копать глубже.
Ну так вы себя же и опровергли, человек не способен отличить качество воды, если там будут соли тяжелых металлов :)
Ладно, я думаю, что стоит сойтись на том, что аналогии не могут быть доказательством, тем более в таких комплексных вопросах как оценка ПО. Которое само по себе сложнейший конгломерат абстракций.
1) Человек подходит к крану, наливает себе воду. Вода на вид прозрачная, запахов посторонних не обнаружено. Выпил, отравился. Вывод - вода плохая. Без лабораторных исследований понять этого было нельзя.
2) Человек заходит в самолет, садится на свое место. Место на вид чистое, опрятное. Самолет новенький блестящий. Все в нем управляется системой "Умный самолет 2.0". Нажал кнопку с изображением стюарда, чтобы вызвать стюарда. Пришел пилот, дал леща. Потом еще в аэропорту прибытия полиция скрутила. Вывод - софт плохой. Без лабораторных исследований понять этого было нельзя.
Выглядит такой пылесборник очень непрактично кстати. При всём уважении ко вложенному в это времени неизвестного мастера :-)
Если мастер работает в одиночку, то он больше заработает на супер сложном изделии - будет делать его пол года, а потом продаст на Сотбис. Высококлассные столяры именно так и делают.
Если это крупная фабрика, то ей выгоднее фигачить дспшно-пластиковле дерьмо, чем дешевле, тем выгоднее.
Очень много если. Вполне может, что этот мастер живёт в глуши в деревне, полгода делает это изделие, а продавать его там некому...
Да даже работая в Москве - продать такой дорогой стол - не простая задача, нужно уметь его продавать, иметь продавцов, или раскрученное имя (которое из воздуха не появляется).
Я уже давно (по сути с детства) по чуть-чуть интересуюсь сторядным делом. Какое то время даже тусовался на тематических форумах, например на woodcraftsman. Там, как и везде, большинство это новички. Но те мастера, которые дейтсвительно топовые, иногда выкладывают фотки своих работ и прямым текстом пишут "продавать буду на Сотбис". Да, у них есть контакты агентов и дистрибьюторов такого рода аукционов. Но жить этот мастер вполне может и в деревне и раз в пол года мотаться до Москвы, чтобы передать своё изделие дистрибьютору.
Ну а раскрученное имя в любом деле важно - и в столярном, и в IT, и в медицине, и в юриспруденции.
Очень много встречаю программистов из числа "высшее образование программисту не нужно". В подавляющем большинстве их код ужасен. Про оптимизацию можно и не говорить. А недавнее засилие генеративных ии вообще разучит их думать. Талантов очень мало.
Селективное восприятие, склонность к подтверждению своей точки зрения и т. д...
У вас репрезентативная выборка или так, ощущения?
В точку. Неистово плюсую под вопли вайтишников?
Очень много встречаю программистов из числа "высшее образование программисту не нужно".
Достаточно часто встречал программистов с ВО, которые никогда не слышали про Чистый код и учили определения SOLID для того чтоб пройти собеседование.
Думаю в качестве кода и ВО нет корреляций. Так как тот же SOLID и Чистый код, Чистую архитектуру там не изучают.
Однако ВО несомненно полезно для расширения кругозора и понимания в какую сторону грести для решения задач.
мой опыт говорит, что ВО это не про показатель наличия знаний у человека, а про то что, человек прошел государственную валидацию знаний/навыков предоставленных учебным заведением.
я самоучка в разработке, видел код человеков с ВО и он был ужасным. Меня это шокировало, не понимал, как так, что человек с ВО может такое делать.
Мне что-то кажется, что изначально стоит вспомнить про искажение воспоминаний по принципу "раньше девки были краше, пиво холоднее, а трава зеленее (и это явно не про газон)". Что научно и математически легко объяснимо ошибкой "выжившего", так как горы плохого кода просто давно пропали и никем не ранятся. А тот, что выжил - получен в результате многолетней доработки напильником. Поэтому на этом уже комментарий можно было закончить, но я решил написать еще.
Agile здесь вообще не причем. Все очень просто. Agile это ТОЛЬКО ценности и манифест, которые определяют, точку отсчета для пронимания, что такое хорошо, а что такое плохо. И все :) Другое дело, что чтобы это осознать надо время и опыт. Не сам факт, что Agile - это именно это, а как его применять. Поэтому часто Agile подменяется ритуалами, карго-культом, и всем остальным. А дальше уже клиника и неинтересно.
В принципе, методология разработки не сильно влияет на код. К примеру, я с удовольствием почитаю того, кто мне обоснует, почему именно Agile рекомендует "ввязаться в бой" до того, как прошло согласование правил именования, принципов работы со сложными типами, методы логирования, обработку исключение и вообще, архитектуру решения с нефункциональными требованиями. Если мы о качестве кода, то это именно то, как в нем реализованы НЕФУНКЦИОНАЛЬНЫЕ требования, а не бизнес логика. Да, бизнес логика тоже важна, есть баги и все остальное. Но они исправляются и довольно таки быстро, если все остальное ОК. А вот если были похерены НЕФУНКЦИОНАЛЬНЫЕ требования - то почти точно получим говнокод, которые чисто по случайности работает, пока не набежало много юзеров, либо пока не пошел рост проекта. А причем тут методология?
Почему выходит плохо? Да все просто. Частично есть ответы в статье, но как-то не с тем акцентом.
Во-первых, есть вторая истина, которая гласит "кол-во интеллекта константно, а население растет" :) Чуда нет, и ИТ-курсы не делают из людей программистов. Кто считает, что делают - вам к закону Больших чисел. Количество реально хороших спецов невелико, плюс важно собрать их так, чтобы закрыть все ключевые компетенции хотя бы по одному разу. А это значит, что бедут говно код, так как ну а что еще можно получить. И кстати раньше было тоже самое :)
Во-вторых, коммерческая разработка - это всегда про сроки, которые жмут все кто может. Вот никогда не бывает (опять же, закон Больших чисел для тех, кто думает по другому), чтобы все шло неспеша, всем платили деньги и не говорили - когда. Иногда для разнообразия могут не сжать сроки, а накинуть скоуп.
В-третьих - мало денег. Предыдущий пункт был про время, этот про деньги. Это те две вещи, которых не хватает всегда. Соотетственно если их не хватает, надо чем-то компенсировать. Это либо оплата спецов, вместо которых набрали людей, готовых работать за миску супа, либо зажали сроки.
В-четвертых - контрактинг. Ну а как? Вы ж когда девушку "гуляете", то не рассказываете прямо, что цель секс и возможно много раз. Можно потрындеть о высоких (или хотя бы отвлеченных) материях, как-то там подать себя покрасивше ... так и с заказчиком. Если ему сразу сказать, что проект на два года, куча нервов, будет результат так себе и уж точно рынок ему не завоевать - он вас не купит и возьмет кого-то другого, кто ему красиво поездит по ушам, продав полгода и все золото мира, которое он сможет заработать на новом продукте. А почему? Так блин, конкуренция. Не зря говорят, есть компании, где сейлы стараются не шариться там, где тусит деливери. Одни продали, бонус в карман и окучивать следующую жертву. А деливери потом пропихивает "жопу в форточку". И там было, есть и будет. Всегда и в любой отрасли. Конечно не все так плохо и цинично, но в реале все продают мираж, а потом стараются до него добежать.
И совсем мелочь. Давление backlog'a. Вот тут странно. Поясню. Если мы идем спринтами, то в работу было взято столько, сколько влезло. Вопрос, почему влезло больше? Тут же ж не спишешь на большой проект, где можно промахнуться. Тут уже классические две недели, работа идет, все известно. Откуда давление? Если конечно заказчик хочет больше - это уже вопрос к тому, кто ему чего обещает и к структуре контракта. Но в целом, тут никто не заставляет рожать ежа против шерсти каждые две недели, если конечно сами исполнители не хотят. Конечно заказчик хотел другого, ему что-то обещали. Но устраивать аврал за авралом смысла нет.
--------------
Короче чуваки, делается свое дело хорошо и не берите дургого в голову, а тяжелого в руки :)
Все верно. По мастерство в точку. Наступила эра фреймворковых программистов. Почитайте на Хабре статьи об алгоритмах. Любой комментарий, любая статья от программистов, включая сеньоров, посвящена тому, что....... алгоритмы не нужны. Люди буквально истерят когда слышат "алгоритмы". А если ты олимпиадник они готовы сожрать тебя заживо. Я до сих пор не понимаю, как эта идиотократия оказалась возможной?! Лет 10 назад программирование и алгоритмика считались тождественными понятиями. Теперь идёт буквально борьба с алгоритмами.
У меня коллега - олимпиадник. Говорит, что так писать, как он пишут на олимпиадах, в обычной работе нельзя.
А ещё алгоритмы - это лишь малый кусок работы программиста. Есть ещё куча всего с чем знание алгоритмов не поможет. Например кэширование, архитектура, организация поддержки, работа с бд, протокол http, git, уточнение требований, тестирование производительности, тестирование корректности и т.д. и т.п. Работая с джунами я узнал как много можно не знать.
Вот системное мышление, логика, обучаемость - программисту точно нужны. Возможно написание алгоритмов их развивают.
Думаю хейт не на алгоритмы, а на их переоценённость, т.к. большинство просто не сталкивается в своей работе с необходимостью балансировать красно-чёрные деревья.
А истина, как обычно, где-то рядом между "отрицать алгоритмы" и "задрачивать литкод".
В среднем достаточно знать о том, какие алгоритмы бывают, что можно, что нельзя, какие у них ограничения.
Ну и конечно, знание алгоритмов нужно там, где нужно знание алгоритмов.
Что в вашем понимании алгоритм? Любая задача решается через алгоритм. Декомпозиция задачи, алгоритмизация. Не? Или разговор про какие то стандартные, шаблонные алгоритмы? Я, например, сейчас много встречаю программистов не знающих и не умеющих проводить декомпозицию задачи, разрабатывать алгоритмы. Они сразу в код. Потом черт ногу сломит.
Согласен с тем, что программа - алгоритм.
В комментарии под алгоритмами я понимаю знания необходимые для решения олимпиадных задач.
Обход графов, динамическое программирование, пересечение многоугольников, балансировка деревьев, эмуляция состояния регистров процессора, рекурсивный алгоритмы, топологическая сортировка и т.п.
В этом и ваша проблема. У меня коллега, НЕ олимпиадник. Полтора месяца пытался сделать задачу. Целый сеньор. Сроки сорвались, проект даже до MVP не дошел. Много читал, чтобы решить проблему, но вот беда - он даже не знал, что надо гуглить. Потому что как ни странно ваш тезис - алгоритмы про решение олимпиадных задач - абсолютно нелепый. Алгоритмы придумали из бизнес задач, а на олимпиадах дают упрощённые мат модель реальных задач. И вот сеньор не увидел эту мат модель, вернее не смог клиентскую постановку задачи свести к известной задаче. Это была NP задача, которую никто не увидел. Никто из профессиональных перекладывателей джсонов. Компания упустила жирного Лида. И таких задач полно. Просто когда тупо не знаешь, не можешь это увидеть и даже никаких идей не возникает, что именно гуглить и надо ли гуглить. Начинается хаотичное барахтанье в луже догадок.
Не раз видел подобное в разных компаниях за 14 лет у коллег не олимпиадников.
Действительно, мы не знаем того, чего не знаем. Но я и не спорю, ибо уже писал:
В среднем достаточно знать о том, какие алгоритмы бывают, что можно, что нельзя, какие у них ограничения.
Ну и конечно, знание алгоритмов нужно там, где нужно знание алгоритмов.
Просто не нужно уходить в крайности.
А почему мы не требуем от программистов умения расчёта статистики в A/B экспериментах? Или знания линейной алгебры? Или знания алгоритмов машинного обучения? Численных методов решения дифуров в конце концов?
В большей степени я согласен с автором. Особенно если посмотреть на курсы и школы программирования. где менее чем за пол года клянутся сделать из вас крутым программистом. Даже если вы в айти полный ноль.
Дают в лучшем случае немного основы языка и сразу дают фреймворк. В итоге у нас недоразработчик получается.
Или классическое обучение на программиста. дают кучу всего.. но на выходе совсем не актуальный специалист. который по факту ничего не знает, а обучали его технологиям начала 2000х.
А это потому, что преподавание это сложный труд, за который мало платят. И я не про курсы, а про классическое образование. Там есть 3 основных вопроса:
Кому преподавать
Что преподавать
Как преподавать
И не основной, но тоже важный - как долго преподавать.
И раз в несколько лет должна собираться рабочая группа, которая должна пересматривать программу обучения. Это делается. Другое дело, как это делается, и кто входит в эту рабочую группу. А должны входить туда:
Педагоги-эксперты, знающие как работает обучение у людей. Это непрофильные спецы, но они отлично знают, как информацию о предмете сделать знанием. Это их работа. Там универсальные методики, знание мозга, мышления и т.п. Они помогают сформировать методику обучения (отвечая на вопрос Как учить)
Педагоги, профильные спецы, чья программа обучения и пересматривается. Они могут дать дельные советы из практики обучения. Что работает, что нет, какие проблемы встречаются, как они их пытаются решать.
Программисты-инженеры (подставь любую профессию), заслуженные эксперты в своей области. Т.е. люди с большим опытом реальной разработки, со статьями, выступлениями на профильных мероприятиях. Они могут подсказать, какие практические знания нужны молодым спецам. И рассказать о важных трендах в отрасли. Отвечают на вопрос Что учить.
Чиновники, обладающие статистикой и информацией о нуждах государства. Они лишь задают вектор, говоря кто нужен, в каких количествах и как быстро. А также контролируют, чтобы все инициативы влезли в бюджет. Запрашивают средства дополнительно, если не хватает. Не пытаясь сходу ограничить все инициативы, но напоминая о существующих ограничениях. И не лезут дальше.
По факту, эти группы собираются редко, а входят в них не самые сильные спецы, да и кто его знает, кто в них входит. Поэтому и учат у нас какой-нибудь ассемблер, ни разу не написав пару-тройку драйверов на разные и реальные устройства. Или какие-нибудь протоколы, в отрыве от практики. И т.д. Т.е. либо устаревшие языки и инструменты используют, либо в полном отрыве от реальной практики. А чаще всего и то и другое вместе.
А ведь потом решения этой группы ещё надо и в жизнь претворить. Программу обучения изменить, возможно закупить что-то надо, самим преподам обучиться и т.д.
Ещё у вузов должно быть право голоса, они могут не обновлять программу. Но должны явно предупредить об этом абитуриентов. Мол программа на этом курсе от 2015 года. Зато обновить могут другое направление, которое вуз считает для себя важнее. Почему так? Да потому что денег на все не хватит.
А ещё сами преподаватели редко совершенствуются. Потому что нет нормальной системы поощрения, а также на это банально не выделяется время. Учи дома. Не в рабочее время. Зачем учить, если зп не поменяется, да ещё тратить личное время на это? Кароче, много проблем в образовании. И решение многих из них требует много денег. А деньги у нас выделять на такие вещи не очень любят. Выделяют лишь тогда, когда уже жопа наступает.
Наше общество плохо умеет отстаивать такие вещи. Хотя бы потому, что основная масса народа не понимает и особо не видит в этом проблемы. А те кто видят, их мало и они не способны достучаться до общества и объяснить им суть. И не только объяснить, но и сказать, а что делать то? Я не про митинги и т.п. бесполезную хрень. А про правовые способы. Они существуют, просто ими не умеют пользоваться. Типа возьми и обратись к своему депутату в думе. Они же представители. Это их работа. Сотни, тысячи обращений на одну тему каждому депутату - заставят их пошевелиться. А ещё можно обращения делать и в то же министерство образования, петицию бахнуть и т.д. Куча способов есть.
Сейчас такие инициативы, редко доходят до реализации, не имея массовой поддержки народа и их представителей (депутатов). У нас общество в этом плане пассивное, и не имеет желания управлять своей судьбой. Как-то так.
P.s. что-то меня занесло, сорри)
Когда нас обучали в ВУЗе на "древнем" С, то говорили "Какая разница на чем писать". И я в целом согласна с этой позицией. ВУЗ не может дать глубинные знания узких областей. Да и зачем это. Мы выпустились, и кто кем стал в итоге. ВУЗ учит думать, алгоритмически мыслить. Я столько раз видела, что чел просто ТЗ в код перевести правильно не может - не сосчитать... Да и те же дипломные работы далеко не всегда на тех языках, что преподают. Берешь и разбираешься.
У нас неактуальных специалистов на последних курсах разбирали.
@WebPeople Простите, веткой ошибся. Это вам:
Учи дома. Не в рабочее время. Зачем учить, если зп не поменяется, да ещё тратить личное время на это?
Может быть затем, что в таком случае появится шанс прыгнуть чуть выше? Стать заметным настолько, что найдут и предложат перейти в другое заведение с большей зп?
У преподавателей, насколько я знаю, с этим не так хорошо, как у программистов. Если программист, учась, вкладывается в себя – то преподаватель вкладывается в общество, и прямой выгоды может не получить (а косвенную получат его дети или даже внуки).
Да, похоже вы правы. Смутно представляю себе, чем отличается хороший преподаватель от плохого. С позиции потребителя его услуг все понятно, тут оно на поверхности. Нравится нам, как человек излагает материал, насколько легко после его лекций запомнить и понять сказанное - он хороший. Это если отбросить химию, которая на этапе знакомства может повлиять.
А что такое хороший/плохой преподаватель с точки зрения коллег?
программист, учась, вкладывается в себя – то преподаватель вкладывается в общество
Не понимаю, простите.. Мне кажется, что любой человек, учась, вкладывается в себя, расширяя границы возможностей, ну или просто тренируя мозги.
Обычно хороший преподаватель имеет публикации, свои методические наработки, своих учеников, приросших где-то рядом и своих преподавателей, часть из которых осели где-то сверху по карьерной лестнице. На разные странные активности к хорошим преподавателям стоят очереди, а к плохим загоняют палкой. Много других мелочей, и всё это сводится в цельную картину, которая довольно очевидна всем причастным.
А ещё сами преподаватели редко совершенствуются. Потому что нет нормальной системы поощрения, а также на это банально не выделяется время.
На разные странные активности к хорошим преподавателям стоят очереди
Значит система поощрений все-таки есть? Т.е. преподаватель, который готов потратить чуть больше времени на доп образование для себя, может в итоге это монетизировать?
Система поощрения, что дает сейчас государство - слезы, по крайней мере в регионах так точно. Там плюшки в основном косвенно получают. Типа, кому первому компьютер в класс? После директора и т.п. Либо любимчикам, либо таким вот топовым учителям. Плюс очереди на репетиторство. Родители пытаются своих деток именно к этому учителю протолкнуть, а значит и детки там чаще всего не отбросы (простите за такое грубое выражение, конечно же, дети это цветы жизни), с ними морально легче работать и т.д. Это все трудно назвать системой поощрений. К тому же, если педагог начинает тратить много времени на самообразование, написание методик и т.п. - у него не остается времени на всякие там репетиторства. А значит и дохода нет... как-то так. А получиться ли монетизировать методику обучения - большой вопрос. А если не учиться, то со временем, педагог не то что теряет квалификацию, скорее "костенеет", гибкость теряет, с трудом приспосабливается к новым технологиям и т.п. вещам.
Неофициальный признак - к хорошему учителю ученики на встречи приезжают даже спустя десятки лет. Сам таких учителей видел. Т.е. выпускники ценят заслуги этого педагога даже спустя долгие годы. А официальные признаки - показатели высокие, наличие методик авторских, книг, методичек, статей, звания (типа Заслуженный учитель России), ученная степень и т.п.
А нет такого, что эта гонка не только в создании ПО? Скажем, одежда, инструменты, гаджеты, машины? Сломалось - купил новую, ну в крайнем случае привёл в рабочее состояние, пока не станет проще купить новую. Обычно тут упоминают про "планируемое устаревание". Но не во всех же областях это валидно. Какие-то вещи специально делаются на века. Например мейнфреймы в банкинге)))
Автор, возможно есть смысл, когда описываешь проблему, избегать слов "никогда, всегда и все". Поверьте, хватает вполне адекватных проектов (вне РФ таких точно достаточно).
Мне кажется в статье нужно убрать agile. Из-за этого комментаторы выше начали придираться без понимания смысла статьи. Без разницы по каким правилам/методикам работаете, посыл в том, что насколько внедрённый продукт будет удобен и поддерживаемым в течении следующих 10лет.
качество кода низкое, особенно в последнее время
Здесь нужен линейный график примерно той же степени осмысленности, что у всяких инвестиционных продаванов, только не бесконечно восходящий, а бесконечно убывающий (пикирующий в последнее время). Естественно, без обоснования сколь-нибудь репрезентативными данными и даже намека на исследования.
и даже в правительстве
Сенатором или вице-президентом? В оригинале (знать бы, что из этого оригинал на самом деле) такая-же неуклюжая ерунда, слегка низводящая общий пафос.
В некоем воображаемом, аморфном "agile" перегружают задачами? Пишут как попало? Код проектов и отзывы участников последних крупных проектов, написанных под каскадом с релизами раз в три года в студию!
Джуну не дают "больше времени" на то, чтобы "вылизать" те полторы говнофункции, которые ему доверили наковырять? Молитесь на того лида, который в состоянии сообразить и настоять на прекращении бессмысленных ковыряний в чем-то никому не нужном. Так-то конечно джуну с мидлом виднее, на что нужно потратить ближайшие полгода, но прочие глупцы-то не в курсе истинной природы вещей.
Очень отзывается!
На мой взгляд Мастерство крайне важно в коде, претендующем на частое повторное использование. Например, библиотеках базовых функций, фреймворках и т.п. Это фундамент всего остального и когда он выполнен Мастерски, то даже новичкам и "загнанным коням" не всегда удастся его испортить в конечном продукте. А если этот фундамент кривой, то даже тем кто стремиться к Мастерству приходится на его основе лепить франкенштейнов.
Публикации
Где-то в дороге мы забыли о мастерстве программирования