Comments 60
Если изменить в статье профессию «программист» на любую другую — ничего не изменится. Человеки они такие: есть те, кто делает свою работу относительно хорошо (их мало), и есть остальные.
И да, и нет.
Специфика работы программиста (как и любого работника в динамичной области) еще и в том, что ему постоянно нужно быть на гребне волны, так сказать, постоянно следить за изменениями и новшествами.
Водителю троллейбуса, например, достаточно получить соответствующую категорию и разрешение на перевозку людей (ну или что там). От того, будет ли он подробно знать устройство троллейбуса и понимать принципы его функционирования, качество его работы сильно не изменится
Специфика работы программиста (как и любого работника в динамичной области) еще и в том, что ему постоянно нужно быть на гребне волны, так сказать, постоянно следить за изменениями и новшествами.
Водителю троллейбуса, например, достаточно получить соответствующую категорию и разрешение на перевозку людей (ну или что там). От того, будет ли он подробно знать устройство троллейбуса и понимать принципы его функционирования, качество его работы сильно не изменится
Не совсем так. Программирование — пожалуй, одна из не многих областей знаний, где не получится схитрить. Что вы программируете — то вы и получаете. В той же физике, химии, математике схитрить выйдет, заметят/не заметят — не суть важно, важно то, что можно схитрить. В программировании — не выйдет.
Интересно, как это вы схитрите в физике или математике? Прессе рассказать в других словах, понятных обывателю, или утаить информацию/коммерческий секрет получится, но схитрить нет.
Элементарно.
Ссылаетесь на что-то, чего вы вообще не знаете. При этом, работает оно или нет — вообще не известно. В программировании такой фокус не выйдет. Схитрить не получится.
Можно обобщить на всё и вся, ссылки на «незнание» допускаются везде и всеми. В программировании это приводит сразу же к катастрофе. В не программировании глядишь и не заметят, а даже если и заметят — не факт, что сразу будут реагировать. А может и вообще не будут реагировать. Зачем? Оглядитесь вокруг — все что вас окружает так или иначе сделано через одно место. Именно потому, что можно хитрить на всех этапах, например производства чего бы то ни было, или исследованиях, тех же физических и т.д…
Ссылаетесь на что-то, чего вы вообще не знаете. При этом, работает оно или нет — вообще не известно. В программировании такой фокус не выйдет. Схитрить не получится.
Можно обобщить на всё и вся, ссылки на «незнание» допускаются везде и всеми. В программировании это приводит сразу же к катастрофе. В не программировании глядишь и не заметят, а даже если и заметят — не факт, что сразу будут реагировать. А может и вообще не будут реагировать. Зачем? Оглядитесь вокруг — все что вас окружает так или иначе сделано через одно место. Именно потому, что можно хитрить на всех этапах, например производства чего бы то ни было, или исследованиях, тех же физических и т.д…
Вообще то совсем наоборот. Вы можете в программировании написать полную хрень которая как то еле будет работать, но которую невозможно будет ни прочесть ни исправить, ни использовать в другом месте. А в физике или химии неправильно рассчитаете и у вас все сразу накроется медным тазом. Вам никакие ссылки не помогут синтезировать новый материал или собрать определенную конструкцию если вы не понимаете что делаете.
Вы можете в программировании написать полную хрень которая как то еле будет работать, но которую невозможно будет ни прочесть ни исправить, ни использовать в другом месте.Это и есть пример формулировки «схитрить не получится».
А в физике или химии неправильно рассчитаете и у вас все сразу накроется медным тазом.Да не парьтесь и подгоните результат. В физике это простительно, у них тоже дедлайны. И хитрить можно. Даже нужно. Затем, по прошествии времени можно подправить «результат». Такое на каждом шагу и везде. То что эксперимент вообще иногда не согласуется с расчетами и притягивают одно к другому — это вообще в порядке вещей. Это и есть еще один пример хитрости. И т.д…
Такое на каждом шагу и везде.Это точно о физике, а не о школьных лабораторных работах?
эксперимент вообще иногда не согласуется с расчетами и притягивают одно к другому — это вообще в порядке вещейТеперь я в этом уверен.
Простите, но InterceptorTSK частично прав.
Акцент делается на ученых, которые в целом специалисты в своей области, причем очень известные. Ошибки в которых их уловили не перечеркивают все их работы, но отдельные локальные утверждения очень даже.
Кроме того осмелюсь напомнить что очень много научных опытов нельзя повторить.
При этом я не стану утверждать что программисты белые и пушистые, сам на днях нашел у себя ошибку благородя которой нивелировалась другая ошибка (я такой: «о, сдесь же не правильно», исправляю… и программа перестает работать в другом месте).
Элементарно.Целая книга о том как ученые используют вещи которые не понимают.
Ссылаетесь на что-то, чего вы вообще не знаете.
Акцент делается на ученых, которые в целом специалисты в своей области, причем очень известные. Ошибки в которых их уловили не перечеркивают все их работы, но отдельные локальные утверждения очень даже.
Кроме того осмелюсь напомнить что очень много научных опытов нельзя повторить.
При этом я не стану утверждать что программисты белые и пушистые, сам на днях нашел у себя ошибку благородя которой нивелировалась другая ошибка (я такой: «о, сдесь же не правильно», исправляю… и программа перестает работать в другом месте).
Целая книга о том как ученые используют вещи которые не понимают
Вы бы хоть немного ознакомились с приведенной вами книгой. Она в основном про гуманитариев — психологов, философов, социологов, которые бессмысленно используют в своих текстах технические термины для придания им некой наукообразности в глазах невежественной аудитории. При чем тут физики и математики?
Да, извиняюсь, немного от ученых точных наук перескочил к ученым гуманитариям. Но аудитория этих людей пусть и невежественная в топологии и теории множеств, но в общем образованная и передовая в своей области науки.
Вот еще вспомнил пример тот что всем нам ближе — Крис Касперски:
Но при этом это лучший автор статей что мне встречались и исключительно его статьи зажгли во мне IT огонь. Пусть земля ему будет пухом.
___________________________
(по самой статье которую мы комментируем) С другой стороны лично я люблю язык С потому что я хочу знать каждый символ
Вот еще вспомнил пример тот что всем нам ближе — Крис Касперски:
Скажу честно — я не люблю ее [свою книгу]. Я презираю себя за нее, за то как я ее писал. Нормальные мыщъх'и так книги не пишут! Только в одной главе The Svin обнаружил столько ошибок...Конкретно указанную книгу я не читал, но находил у него эпические ошибки в статьях, пробовал писать на forum.xakep.ru
но никому не было дела.
Сначала написал самые простые и очевидные, потому как боялся что сам ошибаюсь, но не восприняли вообще никак.
Дальше не стал писать, но ошибки были местами фундаментальные.
1. Крис Касперски всегда прав.
2. Если он не прав смотри п.1.
Дальше не стал писать, но ошибки были местами фундаментальные.
Но при этом это лучший автор статей что мне встречались и исключительно его статьи зажгли во мне IT огонь. Пусть земля ему будет пухом.
___________________________
(по самой статье которую мы комментируем) С другой стороны лично я люблю язык С потому что я хочу знать каждый символ
Знаешь ли ты все, что можно, про каждое слово и каждый символ на каждой странице своего кода?Потому что меня воротит от языков в которых возможны например переопределения [особенно операторов], потому что я писал на них и был
программистом — отстой(Не говорю что все кто на таких языках пишут — отстой, я тогда был совсем новичком, но в сложных языках программирования сложнее понимать всю структуру.)
и не имел ни малейшего представления о том, что делаю
В физике можно продать бестопливный генератор лохам, но можно и огрести, если бритоголовые ребята с толстыми шеями закроют двери ангара до тех пор, пока новый счастливый владелец не проверит свежеприобретённое устройство, а в программировании недотестированный код вполне может работать и даже долго, пока в один прекрасный момент беспилотный троллейбус хохоча не уедет в закат.
Т.е. шлепать «пидалью» по пускачам и надеяться на чудо — это нормально? Ровно так же вы «матку» выдерете у любого грузовика по незнанию… Извините, но вы не правы. Если вы пойдете рулить троллейбусом, то пожалуй иметь базовые знания электротехники нужно. Иначе вас слесари в гараже «научат».
И будет такой водитель троллейбуса постоянно гоняться с маршрутками, трясти людей, регулярно терять свои штанги на разветвителях — как 90% водителей троллейбуса.
Те же, кто действительно хорошо знает правила дорожного движения, постоянно следит за их изменениями, постоянно следит за новшествами на своем маршруте — единицы.
То есть как и во всей статье, вы уезжаете в сторону, так и в этом комментарии, вы почему-то решили, что водитель троллейбуса должен уметь его чинить.
Те же, кто действительно хорошо знает правила дорожного движения, постоянно следит за их изменениями, постоянно следит за новшествами на своем маршруте — единицы.
То есть как и во всей статье, вы уезжаете в сторону, так и в этом комментарии, вы почему-то решили, что водитель троллейбуса должен уметь его чинить.
КДПВ выглядит некрасиво, конечно и я бы лучше вынес проверки в отдельную функцию, возвращающую код/текст ошибки, но ничего сложного или нечитаемого там нет. Вот когда пишут if на шести строках, с вызовом функций внутри условий в расчете на то, что в некоторых случаях до вызова дело не дойдет, или когда в функции пользуются переменной с областью видимости local, которая объявлена в одной из (!) вызывающих функций, или когда плюют на принципы ООП и пишут вызов типа parent.parent.parent.functionName(parent.data), вот тогда хочется минуя стадию дискуссии сразу перейти к насилию. Но опять же, это не потому, что люди не понимали, что делали — они-то отлично понимали и у них все работало. Просто для них задача совместной разработки или будущей поддержки продукта не стояла.
> Знаешь ли ты все, что можно, про каждое слово и каждый символ на каждой странице своего кода?
> Прочел ли ты и полностью понял документацию к каждой функции, которую используешь?
> Обладаешь ли ты превосходным представлением о базовых принципах разработки ПО – настолько хорошим, что ты мог бы объяснить его начинающим программистам в своей организации?
> Понимаешь ли ты, как функционирует каждый компонент компьютера, и как они работают вместе?
> Понимаешь ли ты историю развития компьютеров и то, как они будут развиваться дальше, чтобы понять, как твой код будет исполнен на компьютерах, созданных в будущем?
> Знаешь ли ты историю языков программирования, чтобы понимать, как язык, который ты используешь развивался, и почему он работает именно так?
> Понимаешь ли ты другие языки программирования, другие подходы к программированию и типы компьютеров, отличные от того, что ты используешь, чтобы понимать, какой инструмент лучше всего подходит для каждой задачи?
Да. Да. Да. Да. Да. Да. Да.
А ещё я знаю, что такое дедлайн, и поэтому все эти знания летят в топку, когда нужно уложиться по времени.
> Прочел ли ты и полностью понял документацию к каждой функции, которую используешь?
> Обладаешь ли ты превосходным представлением о базовых принципах разработки ПО – настолько хорошим, что ты мог бы объяснить его начинающим программистам в своей организации?
> Понимаешь ли ты, как функционирует каждый компонент компьютера, и как они работают вместе?
> Понимаешь ли ты историю развития компьютеров и то, как они будут развиваться дальше, чтобы понять, как твой код будет исполнен на компьютерах, созданных в будущем?
> Знаешь ли ты историю языков программирования, чтобы понимать, как язык, который ты используешь развивался, и почему он работает именно так?
> Понимаешь ли ты другие языки программирования, другие подходы к программированию и типы компьютеров, отличные от того, что ты используешь, чтобы понимать, какой инструмент лучше всего подходит для каждой задачи?
Да. Да. Да. Да. Да. Да. Да.
А ещё я знаю, что такое дедлайн, и поэтому все эти знания летят в топку, когда нужно уложиться по времени.
На практике очень ценятся «плохие» программисты, которые могут взять и написать что-то быстро, не читая всей документации по всем используемым функциям и не задумываясь о том, как будет этот код выполнятся на устройствах будущего. И ещё они дешевле и универсальнее.
Видимо есть смысл вообще разбить программистов на категории и перестать сравнивать. Иногда нужны слесари, а иногда фрезеровщики, никто не не будет говорить, что хороший слесарь тот, кто умеет фрезеровать.
Видимо есть смысл вообще разбить программистов на категории и перестать сравнивать. Иногда нужны слесари, а иногда фрезеровщики, никто не не будет говорить, что хороший слесарь тот, кто умеет фрезеровать.
Вот если бы все не только молча в тряпочку трэшак кодить умели ПОД дэдлайн и указку менеджера, но хотя бы иногда могли вставить свое веское слово на тему, почему за такой дэдлайн менеджера следует кастрировать и почаще напоминать о том, что такое мастерство и качество (желательно — делом), то электронный мир был бы в среднем уютнее.
А так, прикрываться табличкой с надписью «а я то что, это всё — дэдлайн» — много ума не надо.
Как минимум для «профессионалов с большим опытом и большими амбициями» такое оправдание не канает. А именно так себя позиционируют, к примеру, львиная доля Микрософта из недр которого потом выползает то, что выползает… страшное, не причесанное на костылях и кренится во все стороны одновременно.
Помельче примеров — так вообще тьма! Куда не сунься — везде хотя бы один баг обнаружишь, который стыдно было не заметить до релиза и еще более стыдно — не поправить при первой же возможности, т.к. чепуха.
P.S.: А мой любимый контр-пример — это Far. Ни единого кривого слова в его адрес не слетело с моих губ за 10+ лет использования. Хотя баги там есть, судя по патч-нотам.
А так, прикрываться табличкой с надписью «а я то что, это всё — дэдлайн» — много ума не надо.
Как минимум для «профессионалов с большим опытом и большими амбициями» такое оправдание не канает. А именно так себя позиционируют, к примеру, львиная доля Микрософта из недр которого потом выползает то, что выползает… страшное, не причесанное на костылях и кренится во все стороны одновременно.
Помельче примеров — так вообще тьма! Куда не сунься — везде хотя бы один баг обнаружишь, который стыдно было не заметить до релиза и еще более стыдно — не поправить при первой же возможности, т.к. чепуха.
P.S.: А мой любимый контр-пример — это Far. Ни единого кривого слова в его адрес не слетело с моих губ за 10+ лет использования. Хотя баги там есть, судя по патч-нотам.
Вот, кстати, молодой человек сказал о вопросе, о котором ранее никто даже и не задумался.
Дедлайн — сроки — заказ — оплата — коммерческая разработка.
Колоссальную разницу в качестве работы программиста будет играть вопрос: собственная инициатива, или коммерческая разработка? В первом случае как ни крути, человек будет старатся сделать что-то с душой.
Во втором, разрабатывая «очередной интернет-магазин с необычным функционалом», коих собирает по 2 в месяц на протяжении уже 3х лет работы, явно будет принебрегать лишними проверками, пониманием особенностей заказа, и т.п.
Здесь человеческий фактор играет немаловажную роль — я бы не готов был вкладывать душу в каждый проект своего начальника, и его заказчика плохо понимающего свои пожелания.
Дедлайн — сроки — заказ — оплата — коммерческая разработка.
Колоссальную разницу в качестве работы программиста будет играть вопрос: собственная инициатива, или коммерческая разработка? В первом случае как ни крути, человек будет старатся сделать что-то с душой.
Во втором, разрабатывая «очередной интернет-магазин с необычным функционалом», коих собирает по 2 в месяц на протяжении уже 3х лет работы, явно будет принебрегать лишними проверками, пониманием особенностей заказа, и т.п.
Здесь человеческий фактор играет немаловажную роль — я бы не готов был вкладывать душу в каждый проект своего начальника, и его заказчика плохо понимающего свои пожелания.
Конечно, очень многие факторы играют роль, и мотивация и заинтересновонность разработчика здесь, на мой взгляд, в первом ряду.
Вообще автор оригинальной статьи, на мой взгляд, очень идеализирует. В реальной жизни, конечно, существуют и другие приоритеты, кроме качества непосредственно кода.
И как сказал комментатор выше, с чем я согласен, все упирается в требования заказчика. Ему то без разницы, как код написан, ему важен только функционал и ничего кроме. Так что качество кода важно, по сути, только для дальнейшей его поддержки.
Но с другой стороны ограничения по времени/бюджету сами по себе никого не заставляют говнокодить. Можно писать грамотный и чистый код и в рамках не очень "красивой" задачи.
Имхо, основную мысль нужно понимать не как "написание кода без понимания теоретических осонов = говнокод", а скорее как "чем глубже ты знаешь теоретическую базу, тем стабильнее и продуктивнее работают твои программы"
UFO just landed and posted this here
UFO just landed and posted this here
Давайте не будем путать теплое с мягким. Постоянно развиваться и иметь широкий кругозор — это одно. А быть дотошным специалистом всех перечисленных направлениях — это недостижимый идеал.
Как говорил наш преподаватель в институте: «Инженер не должен знать все. Он должен знать, где про это написано, и уметь разобраться».
Если человек в силу должностных обязанностей 90% времени занимается написанием и оптимизацией алгоритмов обработки данных под конкретную платформу, зачем ему тратить время на подробное изучение других платформ?
Как говорил наш преподаватель в институте: «Инженер не должен знать все. Он должен знать, где про это написано, и уметь разобраться».
Если человек в силу должностных обязанностей 90% времени занимается написанием и оптимизацией алгоритмов обработки данных под конкретную платформу, зачем ему тратить время на подробное изучение других платформ?
Давным-давно я написал статью на тему «Почему компьютеры – отстой» (в итоге получившую названия «Компьютеры» и «Что не так с компьютерами» [в оригинале ссылка тоже битая — прим. переводчика]web.archive.org: What’s Wrong With Computers
UFO just landed and posted this here
К статье не хватает ссылки на изложенные простым языком «принципы разработки ПО» (хотя бы на один из стандартов), а также ссылки на исследование, в котором был бы ответ на вопрос «можно ли действительно понять эти принципы без пары лет опыта интенсивной самостоятельной разработки».
ИМХО.
ИМХО.
Ну из песни слов не вибросишь, в оригинале ссылок не было.
Но если интересно, от себя добавлю.
По принципам: solid, grasp например, первое, что приходит в голову, а также книга Фаулера про архитектуру
По поводу
можно ли действительно понять эти принципы без пары лет опыта интенсивной самостоятельной разработки
в статье явно написано — нет, вряд ли
Не понимаю как перечисленные пункты вообще относятся к хорошему программированию. Мне кажется, они никак не помешают написать кучу говнокода который еле работает.
Господа, знаете «почему программисты отстой» на самом деле? Потому что они это и сами прекрасно понимают, без посторонней помощи. А те кто не понимают — вообще не программисты.
То что вы говорите говорит и автор статьи. Только он еще добавляет, что без этого ничего кроме говнокода у вас не получится.
Вы понимаете как функционирует AC97 или предсказатель ветвления? У 90% функций которые я использую например нет никакой документации, неужели у вас не так и у вас есть доки на абсолютно любые функции? И как можно предсказать развитие компьютеров в будущем? Где то есть курсы ясновидения? И зачем это делать?
Знаешь ли ты все, что можно, про каждое слово и каждый символ на каждой странице своего кода?
Я не знаю как у автора, но у меня нет «своего» кода, как и большинства других программистов. Продукты разрабатываются в команде, а знать каждую строчку из миллиона строк твоего проекта не только невозможно, но и не нужно.
Понимаешь ли ты, как функционирует каждый компонент компьютера, и как они работают вместе?
Зачем мне это, если я не пишу драйвера? Может мне еще надо понять все тонкости схемотехники? Или же что конкретно происходит на квантовом уровне? Вся суть программирования в абстракции, нужно ориентироваться в уровне абстракции на котором ты работаешь.
Знаешь ли ты историю языков программирования, чтобы понимать, как язык, который ты используешь развивался, и почему он работает именно так?
Для многих языков ответ «потому что». Знать альтернативные подходы иногда полезно, но это ортогонально истории.
Ну и главное:
Не то, чтобы языки программирования были слишком сложными (хотя это так
Это не так, если ты не пытаешься блеснуть перед коллегами своими уникальными знаниями стандарта и использовать экзотические конструкции.
UFO just landed and posted this here
Я не могу удержаться…
Рассуждения школьника, о том как можно прекрасно устроить мир!
Здесь все «прекрасно»,
Можно прямо по цитатам разбирать :)
«Знаешь ли ты все, что можно, про каждое слово и каждый символ на каждой странице своего кода?
Прочел ли ты и полностью понял документацию к каждой функции, которую используешь?
Понимаешь ли ты, как функционирует каждый компонент компьютера, и как они работают вместе?
Понимаешь ли ты историю развития компьютеров и то, как они будут развиваться дальше, чтобы понять, как твой код будет исполнен на компьютерах, созданных в будущем?
Знаешь ли ты историю языков программирования, чтобы понимать, как язык, который ты используешь развивался, и почему он работает именно так?
»
Рассуждения школьника, о том как можно прекрасно устроить мир!
Здесь все «прекрасно»,
Можно прямо по цитатам разбирать :)
«Знаешь ли ты все, что можно, про каждое слово и каждый символ на каждой странице своего кода?
Прочел ли ты и полностью понял документацию к каждой функции, которую используешь?
Понимаешь ли ты, как функционирует каждый компонент компьютера, и как они работают вместе?
Понимаешь ли ты историю развития компьютеров и то, как они будут развиваться дальше, чтобы понять, как твой код будет исполнен на компьютерах, созданных в будущем?
Знаешь ли ты историю языков программирования, чтобы понимать, как язык, который ты используешь развивался, и почему он работает именно так?
»
Даже и не знаю. Автор с 2002 работает айтишником, 8 лет проработал архитектором, а с 2011 работает в гугл. Может его идеи и "попахивают" идеализмом, но это точно не рассуждения школьника.
Хотя сама статья 2009 года, когда он еще не работал в гугл и всего 5 лет пробыл архитектором, так что можно споконо обвинить его в школьном восприятии, если угодно.
Обычно люди избавляются от такого в первые 3-5 лет…
Хотя — судя по его деятельности и книге, это такой «тонкий» троллинг школоты и перфекционистов, с целью привлечь внимание к своей персоне/книге/статьям :)
Хотя — судя по его деятельности и книге, это такой «тонкий» троллинг школоты и перфекционистов, с целью привлечь внимание к своей персоне/книге/статьям :)
Мне кажется он просто банально не понимает что именно делает плохого программиста хорошим. Сам он может и прекрасный программист и может увидеть хорошо человек программирует или плохо. Но что именно заставляет человека плохо кодить, вот очень сомневаюсь что знание истории языков программирования к этому относится.
Сидишь такой, весь из себя хороший программист, собаку съел за 15 лет программирования, все принципы и теорию знаешь, пишешь на жабе, но знаешь как отличается работа кешей у процессоров Интела и АМД, и…
Говоришь такой менеджеру:
— Эту фичу надо писать месяц.
А он такой в ответ:
— Через две недели внедрение. Продали Очень Крупному Заказчику за много миллионов.
— Не успеем нормально сделать!
— Ночами сидите, но сделайте чтобы можно было начать внедрять!
— Но…
— Уволю нахрен! Контора закроется, если не внедрим!
И вы ещё спрашиваете, откуда столько говнокода в приличных на вид конторах…
Действительно, откуда?
Говоришь такой менеджеру:
— Эту фичу надо писать месяц.
А он такой в ответ:
— Через две недели внедрение. Продали Очень Крупному Заказчику за много миллионов.
— Не успеем нормально сделать!
— Ночами сидите, но сделайте чтобы можно было начать внедрять!
— Но…
— Уволю нахрен! Контора закроется, если не внедрим!
И вы ещё спрашиваете, откуда столько говнокода в приличных на вид конторах…
Действительно, откуда?
Вообще так и должно быть:)
Ведь деньги берутся именно оттуда заказчик ->контора-> программист.
И порой внутреннее качество оказывается пофиг.
Ведь деньги берутся именно оттуда заказчик ->контора-> программист.
И порой внутреннее качество оказывается пофиг.
Если бы заказчик знал, что за говнокод ему продают, он бы его не покупал. Но он не знает. На том и основывается бизнес
ну, плохое планирование и недостаток времени на подумать обычно выливается в отложенный факап, когда под весом накопленного объёма говнокода (ну или технического долга) вся система начинает вдруг разваливаться.
Я всеми руками и ногами за хороший, продуманный код, но в таких суждениях, кмк, налицо ошибка выжившего (точнее невыжившего). Я не уверен насчет слова «обычно» и не удивлюсь, если как раз в большинстве случаев такой подход себя оправдывает и оказывается более выгодным, нежели вылизанные архитектуры и идеальный код. Однако статистики, увы, нет.
Где-то в этой цепочке болтается маркетинг с «я угадаю эту мелодию с 3х нот».
Основной причиной является многократное ускорение написания программ, заимствование библиотек и фреймворки, нагромождение ошибок одного разработчика на ошибки взаимодействия с api библиотекой и разрабатываемой программы другим разработчиком.
Необоснованное усложнение пришло во встроенные системы с микроконтроллерами, туда упрямо лезет .NET
Правда ресурсы уже нужны не маленькие по микроконтроллерным меркам 256кб и более оперативки, чтоб «поморгать» светодиодом или быстро «наваять» отрисовку красивых окошек, на сенсорном ЖКИ экране.
Просто скорость разработки и скрытая (на простых задачах) простота использования компенсируется пофизическимприродным законам сохранения всех энергий (тут убавилась, там прибавилось)увеличением ошибок и уменьшения надёжности функционирования
Вследствие этого и появляются отстойные программисты.
Необоснованное усложнение пришло во встроенные системы с микроконтроллерами, туда упрямо лезет .NET
Правда ресурсы уже нужны не маленькие по микроконтроллерным меркам 256кб и более оперативки, чтоб «поморгать» светодиодом или быстро «наваять» отрисовку красивых окошек, на сенсорном ЖКИ экране.
Просто скорость разработки и скрытая (на простых задачах) простота использования компенсируется по
Вследствие этого и появляются отстойные программисты.
Я бы на основе данного мнения, развил тему до более общей — специалистов с высоким уровнем теоретической подготовки мало. А по моему мнению много и не нужно.
Есть уровень ПТУ — возьми лопату, воткни под углом 45 градусов, нажми на черенок, вытащи, откинь, повтори.
Есть уровень ВУЗ — лопата имеет такую форму, потому что; надо втыкать под углом 45 градусов, потому что и т.д.
Есть уровень НИИ — надо изобрести лопату получше, надо улучшить методику использования лопат.
Очевидно, что работников уровня ПТУ должно быть больше уровня ВУЗ, которого в свою очередь больше уровня НИИ.
В нашем неидеальном мире какой-то ПТУшник в силу природной любознательности, узнает некую часть знаний уровня ВУЗа и начинает применять свою лопату более оптимально. В итоге работник работает лучше, но зарплату требует все еще ниже чем уровень ВУЗа. У заказчика создается ложное ощущение о необходимой пропорции ПТУшников/ВУшников/НИИшников на рабочих местах того или иного уровня.
Или, например, водитель — если он знает теорию ДВС, то будет применять правильные техники вождения для экономии топлива. А разгон на средних оборотах с почти полным нажатием на педаль газа — не является, на первый взгляд, естественным выбором. Или поворот рулевого колеса в сторону заноса, отпуск педали тормоза при сносе и т.п. Навыки профессионального вождения не просто механически отрабатываются, а часто должны быть поняты и приняты на причинно-следственном теоретическом уровне.
По моему мнению, большинство конфликтов при обсуждении работы программистов появляются по причине молодости самой профессии. В обществе нет устоявшегося понимания, что программисты бывают очень разные. Да что там программисты! Кроме программистов есть тестировщики, дизайнеры, архитекторы и много других специализацией, ролей так или иначе задействованных в разработке программного обеспечения.
Профессии строителей десятки тысяч лет. И, кстати, именно это профессию я считаю самую близкой к разработке ПО и по классификации специалистов и по методологии проведения работ.
И от хорошего штукатура не требуют знания фундаментальной химии или физики материалов с которыми он работает. От каменщика не требуют знания наизусть показателей твердости материалов.
Да, есть хороший и плохой плиточник, кровельщик и т.д. Но, обычно все сводится к тому, что работник соблюдает или не соблюдает технологию проводимых работ. Вот где критерий хороший/плохой. А не выгодный/невыгодный (за меньшие деньги качественнее и больше и т.п.)
Точно так же и в разработке ПО. Подавляющая часть работы может и должна производится по тем или иным существующим технологиям узкими прикладными специалистами. Только в строительстве заказчик более точно понимает последствия несоблюдения технологий, а в разработке ПО может часто быть ситуация, когда заказчик даже не знает, что есть какие-то технологии разработки.
И опять же, если на вашей работе от вас не требуют соблюдения технологий, нет аудита процессов и кода, нет сложных процедур тестирования, это не значит что этого нигде нет. Просто в большинстве случаев этого сейчас не требуется. Пройдет время и жить станет лучше, жить станет веселее.
Есть уровень ПТУ — возьми лопату, воткни под углом 45 градусов, нажми на черенок, вытащи, откинь, повтори.
Есть уровень ВУЗ — лопата имеет такую форму, потому что; надо втыкать под углом 45 градусов, потому что и т.д.
Есть уровень НИИ — надо изобрести лопату получше, надо улучшить методику использования лопат.
Очевидно, что работников уровня ПТУ должно быть больше уровня ВУЗ, которого в свою очередь больше уровня НИИ.
В нашем неидеальном мире какой-то ПТУшник в силу природной любознательности, узнает некую часть знаний уровня ВУЗа и начинает применять свою лопату более оптимально. В итоге работник работает лучше, но зарплату требует все еще ниже чем уровень ВУЗа. У заказчика создается ложное ощущение о необходимой пропорции ПТУшников/ВУшников/НИИшников на рабочих местах того или иного уровня.
Или, например, водитель — если он знает теорию ДВС, то будет применять правильные техники вождения для экономии топлива. А разгон на средних оборотах с почти полным нажатием на педаль газа — не является, на первый взгляд, естественным выбором. Или поворот рулевого колеса в сторону заноса, отпуск педали тормоза при сносе и т.п. Навыки профессионального вождения не просто механически отрабатываются, а часто должны быть поняты и приняты на причинно-следственном теоретическом уровне.
По моему мнению, большинство конфликтов при обсуждении работы программистов появляются по причине молодости самой профессии. В обществе нет устоявшегося понимания, что программисты бывают очень разные. Да что там программисты! Кроме программистов есть тестировщики, дизайнеры, архитекторы и много других специализацией, ролей так или иначе задействованных в разработке программного обеспечения.
Профессии строителей десятки тысяч лет. И, кстати, именно это профессию я считаю самую близкой к разработке ПО и по классификации специалистов и по методологии проведения работ.
И от хорошего штукатура не требуют знания фундаментальной химии или физики материалов с которыми он работает. От каменщика не требуют знания наизусть показателей твердости материалов.
Да, есть хороший и плохой плиточник, кровельщик и т.д. Но, обычно все сводится к тому, что работник соблюдает или не соблюдает технологию проводимых работ. Вот где критерий хороший/плохой. А не выгодный/невыгодный (за меньшие деньги качественнее и больше и т.п.)
Точно так же и в разработке ПО. Подавляющая часть работы может и должна производится по тем или иным существующим технологиям узкими прикладными специалистами. Только в строительстве заказчик более точно понимает последствия несоблюдения технологий, а в разработке ПО может часто быть ситуация, когда заказчик даже не знает, что есть какие-то технологии разработки.
И опять же, если на вашей работе от вас не требуют соблюдения технологий, нет аудита процессов и кода, нет сложных процедур тестирования, это не значит что этого нигде нет. Просто в большинстве случаев этого сейчас не требуется. Пройдет время и жить станет лучше, жить станет веселее.
Есть слабое место в этой аналогии. Принципиально в лопате ничего не менялось в течение многих поколений. А мир IT развивается так быстро, что знания устаревают с чудовищной скоростью. На это накладываются проблемы нехватки специалистов, из-за которых хорошие специалисты предпочитают работать, а не преподавать. В итоге получается, что в ВУЗ-ах изучают замшелую древность у людей, далеких не то, что от современного программирования, а порой и от программирования вообще.
И немного личного опыта. Нет более раздражающих работников, чем выпускники ВУЗ-ов — они не только ничего не умеют, но пребывают в иллюзии, что умеют и обладают годами оттренированным паскудством — привычкой писать код так, словно его можно сдать, получить зачет и забыть навсегда.
И немного личного опыта. Нет более раздражающих работников, чем выпускники ВУЗ-ов — они не только ничего не умеют, но пребывают в иллюзии, что умеют и обладают годами оттренированным паскудством — привычкой писать код так, словно его можно сдать, получить зачет и забыть навсегда.
Да, именно молодость а, как следствие, быстрый рост являются преградами для качественнго развития разработчиков.
Но строительство тоже не стоит на месте — химия и физика дарят новые материалы и новые способы применения старых. Компьютеры дарят новые средства моделирования архитекторам. Новые задачи — новые решения.
А вот по поводу быстрого устаревания знаний я бы не согласился. Знания либо есть, либо нет. Есть возможно неактуальные технологии. Но даже в программировании есть много чего базового и фундаментального, т.е. архитектура вычислительных машин принципиально давно не менялась, а задачи ими решаемые, точно также в большинстве своем консервативные.
По поводу тех же выпускников ВУЗов — вы, наверное, имеете в виду выпускников постсоветских нетоповых вузов. Я бы их и вузами то не называл. Надо ранжировать работников в мировом масштабе и понимать кто на какую роль в разработке может претендовать.
Но строительство тоже не стоит на месте — химия и физика дарят новые материалы и новые способы применения старых. Компьютеры дарят новые средства моделирования архитекторам. Новые задачи — новые решения.
А вот по поводу быстрого устаревания знаний я бы не согласился. Знания либо есть, либо нет. Есть возможно неактуальные технологии. Но даже в программировании есть много чего базового и фундаментального, т.е. архитектура вычислительных машин принципиально давно не менялась, а задачи ими решаемые, точно также в большинстве своем консервативные.
По поводу тех же выпускников ВУЗов — вы, наверное, имеете в виду выпускников постсоветских нетоповых вузов. Я бы их и вузами то не называл. Надо ранжировать работников в мировом масштабе и понимать кто на какую роль в разработке может претендовать.
Архитектура вычислительных машин к программированию имеет не больше отношения, чем концепция огня, известная с доисторических времен, к ракетостроению.
Насчет консервативных задач. Я приведу простой пример в рамках такой тривиальной задачи, как гостевая лента. Что может быть проще?
1997: Запрос — запуск скрипта — выполнение и ответ — смерть скрипта. Сообщения хранятся где-нибудь просто в текстовом файле, но при тысяче запросов в сутки это совершенно некритично. Все, что нужно знать программисту — чуть-чуть HTML и любой язык — C, Perl, PHP (он тогда совсем новым был) — без разницы.
2000: Количество запросов выросло на порядок, поменялась концепция, теперь скрипт запускается и ждет передачи данных от веб-сервера, отвечает ему и снова ждет. Выросло быстродействие, но и резко появились новые проблемы — нужно следить за тем, чтобы каждый новый цикл скрипт начинал чисто.
Хранение данных постепенно отдается на откуп СУБД, самопальные форматы вымирают. Программисту придется изучить работу с базами данных хотя бы на уровне CRUD. Появляются новые риски — SQL injection и XSS. Пользователи требуют добавить возможность менять цвет и размеры шрифтов, а также хотят себе отдельные профили и аватарки.
2005: Количество запросов выросло еще на порядок. Появляются действительно многоядерные сервера, начинается работа с потоками и целая гора проблем с этим связанная, а базы данных начинают работать в кластерах. Ужесточаются претензии к качеству — это в нулевых сайт мог спокойно лежать полдня и к этому все относились с пониманием. В жизнь разработчиков постепенно начинает просачиваться Ajax. Вместо перерисовки страницы целиком можно менять лишь отдельные ее элементы, что создает очередную гору проблем. Теперь нашему программисту нужно еще и неплохо знать Javascript. Template Tookit отходит на второй план, а на первый выходит XSLT, который сам по себе тянет на отдельный язык. Появляются фреймворки. И XML, который пихают всюду.
2010. XML уступает место более вменяемым форматам типа Json.
Ajax — стандарт, но реализуется с помощью различных библиотек и фреймворков, коих десятки со своими особенностями и версиями. Добавляется кроссавторизация — пользователь должен иметь возможность зайти с помощью аккаунтов в соц. сетях, а их целая пачка. А за ней и интеграция со сторонними сервисами — рассылать уведомления, например. Чтобы выжать еще немного производительности, в ход начинают идти nosql-базы данных типа Memcached. Пользователи хотят постить картинки и с этим связано множество интересных проблем.
2015г.: В «гостевой ленте» давно уже можно прикреплять анимированные картинки, которые сервер сам конвертирует в mp4. Автоматически опознаются ссылки из youtube и аналогичных сервисов, в ряде случаев делается префетч ссылок и пререндер страницы (чтобы пользователь мог увидеть что по ссылке до того, как на нее кликнет). И многое, многое другое.
Версию из 97г. можно сделать за вечер. Это тривиальная по современным меркам задача.
Версию из 2015г. коллектив разработчиков будет делать и отлаживать полгода.
Так вот, никакие знания из 97г. вам сегодня не помогут. Более того, с большой долей вероятности они еще и мешать вам будут, заставляя героически изобретать велосипед и плодить костыли.
Насчет консервативных задач. Я приведу простой пример в рамках такой тривиальной задачи, как гостевая лента. Что может быть проще?
1997: Запрос — запуск скрипта — выполнение и ответ — смерть скрипта. Сообщения хранятся где-нибудь просто в текстовом файле, но при тысяче запросов в сутки это совершенно некритично. Все, что нужно знать программисту — чуть-чуть HTML и любой язык — C, Perl, PHP (он тогда совсем новым был) — без разницы.
2000: Количество запросов выросло на порядок, поменялась концепция, теперь скрипт запускается и ждет передачи данных от веб-сервера, отвечает ему и снова ждет. Выросло быстродействие, но и резко появились новые проблемы — нужно следить за тем, чтобы каждый новый цикл скрипт начинал чисто.
Хранение данных постепенно отдается на откуп СУБД, самопальные форматы вымирают. Программисту придется изучить работу с базами данных хотя бы на уровне CRUD. Появляются новые риски — SQL injection и XSS. Пользователи требуют добавить возможность менять цвет и размеры шрифтов, а также хотят себе отдельные профили и аватарки.
2005: Количество запросов выросло еще на порядок. Появляются действительно многоядерные сервера, начинается работа с потоками и целая гора проблем с этим связанная, а базы данных начинают работать в кластерах. Ужесточаются претензии к качеству — это в нулевых сайт мог спокойно лежать полдня и к этому все относились с пониманием. В жизнь разработчиков постепенно начинает просачиваться Ajax. Вместо перерисовки страницы целиком можно менять лишь отдельные ее элементы, что создает очередную гору проблем. Теперь нашему программисту нужно еще и неплохо знать Javascript. Template Tookit отходит на второй план, а на первый выходит XSLT, который сам по себе тянет на отдельный язык. Появляются фреймворки. И XML, который пихают всюду.
2010. XML уступает место более вменяемым форматам типа Json.
Ajax — стандарт, но реализуется с помощью различных библиотек и фреймворков, коих десятки со своими особенностями и версиями. Добавляется кроссавторизация — пользователь должен иметь возможность зайти с помощью аккаунтов в соц. сетях, а их целая пачка. А за ней и интеграция со сторонними сервисами — рассылать уведомления, например. Чтобы выжать еще немного производительности, в ход начинают идти nosql-базы данных типа Memcached. Пользователи хотят постить картинки и с этим связано множество интересных проблем.
2015г.: В «гостевой ленте» давно уже можно прикреплять анимированные картинки, которые сервер сам конвертирует в mp4. Автоматически опознаются ссылки из youtube и аналогичных сервисов, в ряде случаев делается префетч ссылок и пререндер страницы (чтобы пользователь мог увидеть что по ссылке до того, как на нее кликнет). И многое, многое другое.
Версию из 97г. можно сделать за вечер. Это тривиальная по современным меркам задача.
Версию из 2015г. коллектив разработчиков будет делать и отлаживать полгода.
Так вот, никакие знания из 97г. вам сегодня не помогут. Более того, с большой долей вероятности они еще и мешать вам будут, заставляя героически изобретать велосипед и плодить костыли.
Нет более раздражающих работников, чем выпускники ВУЗ-ов — они не только ничего не умеют, но пребывают в иллюзии, что умеют и обладают годами оттренированным паскудством — привычкой писать код так, словно его можно сдать, получить зачет и забыть навсегда.
И ведь ты действительно прав, точно такое же встречал и многократно.
Дайте ссылку на оригинал статьи, пожалуйста.
Sign up to leave a comment.
Почему программисты — отстой