Комментарии 236
Хорошая статья, я вас понимаю. ;)
Спасибо. Я вас понимаю, сам такой же :)
Прочитал с удовольствием. Даже добавить нечего :-)
НЛО прилетело и опубликовало эту надпись здесь
Ну да, в статье можно заменить слово программист на слово архитектор или экономист. Все будет справедливо. Но я сам программист и писал для таких же как я. :)
Ради корочек учится всего 1%? Ну это неправда, конечно же. Минимум половина.
может у меня ВУЗ плохой, но ИМХО половина - чтобы в армию не идти, половина - ради корочки. А учатся, чтобы чему-то научиться, не в универах, а самостоятельно.
НЛО прилетело и опубликовало эту надпись здесь
Как я вас понимаю... причем тенденции меня настораживают все больше и больше =(
Не знаю как во всяких там "университетах", а в нормальных универах заставляют думать и учиться учиться ;)
НЛО прилетело и опубликовало эту надпись здесь
ну на мехмате нас учат как надо, но правда не тому, что в последствии пригодится в работе. Может только малая часть...
Вряд ли я буду гнаться за обращением матрицы 2000 на 2000 за 15 секунд а не за 20. Хотя хз.. Это тоже полезно.
Вряд ли я буду гнаться за обращением матрицы 2000 на 2000 за 15 секунд а не за 20. Хотя хз.. Это тоже полезно.
Это дело вкусов\ это(учат "лишнему") вполне нормально и есть у всех. Я скорее всего буду гнаться за обращением. Разные направления. Но как примату мне, например, приходится изучать физику =( А вот топологию (тоже не знаю пригодится или нет но прикольно) изучаю сам.
Полезно хотя бы для поиска идей. Что бы потом можно было увидеть некоторые "аналогии". Интуицию развивает сильно.
Все имхо.
Полезно хотя бы для поиска идей. Что бы потом можно было увидеть некоторые "аналогии". Интуицию развивает сильно.
Все имхо.
И не много народу учитья самостоятельно.
Например я учусь на радиотехе, а само обучаюсь веб-программированию по тихоньку.
Например я учусь на радиотехе, а само обучаюсь веб-программированию по тихоньку.
Скорее всего, имелось ввиду что "отсекаем тех, кто ради корочки, и берем 99% из оставшихся".
Разница в том, что учителя, инжинеры и учёные обычно попадают в коллектив, где они могут понять как устроена реальная жизнь и быстро понимают "почём фунт лиха". Старые отрасли, всё отшлифовано годами.
В случае же с программированием человек может ощущать (а иногда и являться) самым крупным авторитетом (в той или иной области) на предприятии по какому-либо вопросу... Зачастую старших товарищей, способных не просто отмести "гениальную" идею типа переписывания всего на свете на Ruby или OCaml, а сделать это аргументированно (указав на проблемы в использовании языков OCaml и Ruby) - просто нет. А если её "отмели" со слованим "у нас так не принято" без всякой аргументации, то, разумеется, "свежий выпускник" будет считать что ему просто крылья подрезали и что на-самом-то-дело он был, конечно, прав...
В случае же с программированием человек может ощущать (а иногда и являться) самым крупным авторитетом (в той или иной области) на предприятии по какому-либо вопросу... Зачастую старших товарищей, способных не просто отмести "гениальную" идею типа переписывания всего на свете на Ruby или OCaml, а сделать это аргументированно (указав на проблемы в использовании языков OCaml и Ruby) - просто нет. А если её "отмели" со слованим "у нас так не принято" без всякой аргументации, то, разумеется, "свежий выпускник" будет считать что ему просто крылья подрезали и что на-самом-то-дело он был, конечно, прав...
Я так же думаю. По другой причине. У нас инженеров учат делать новые решения, и таким вещам как умение разбираться в чужом коде и поддерживать его не уделяется.
Я пока школьник, только учусь:) И мне всегда казалось недостатком, что я часто использую чужие наработки, думалось, что надо бы все с нуля писать, но так лень:) Может, использование чужих наработок не так уж и плохо и я заблуждаюсь?)
Конечно же, это не плохо. Это необходимо в работе, чтобы по тыщщу раз не изобретать велосипед.
Но на начальном этапе - полезно писать с нуля :)
Но на начальном этапе - полезно писать с нуля :)
Нет, наоборот это очень хорошо, особенно если чужие наработки сделаны профессионально, а вы не занимаетесь плагиатом. Целые сайты посвящены обмену кодом и идеями, например codeproject.com, codeguru.com, да и наш хабр, зачем далеко ходить :) Благодаря им иногда экономится масса времени на изобретении очередного велосипеда.
На самом деле всё не так просто. Программирование - это исскуство, но важно понимать что ты делаешь и для чего. Я сам никогда не работал в банке, но вам я искренне завидую: если вам там задавали вопросы на тему обучения специалистов и серитификации ПО (то есть помогали перестроить карту мира в вашей голове) - это очень полезный опыт.
Но, к сожалению, большая часть приходящих к нам "программистов", прошедших через банки не получала таких объяснений, зато получала по башке за каждое уклонение от заведённого порядка вещей и они твёрдо выучили что должен быть в компании священный свод правил, которые надо соблюдать - и тогда всё будет в порядке. Эти люди, увы, как программисты не состоялись и уже никогда не состоятся. Ибо их отучили программировать. Именно отучили: видно что многие из них, в принципе, могут научиться этому вновь, но... мы не благотворительная контора.
P.S. А технологии... что технологии. Когда мы считали корелляцию между словами в резюме и результатами собеседований, то выяснили что самую большую по модулю корелляцию даёт слово "certified". Не потому что сертификат сам по себе - это плохо. А потому что если кроме кучи сертификатов у человека "за душой" ничего нет, то вряд ли это хороший программист, а если у него есть куча сертификатов и реальные достижения, то список сертификатов в резюме просто не попадает...
Но, к сожалению, большая часть приходящих к нам "программистов", прошедших через банки не получала таких объяснений, зато получала по башке за каждое уклонение от заведённого порядка вещей и они твёрдо выучили что должен быть в компании священный свод правил, которые надо соблюдать - и тогда всё будет в порядке. Эти люди, увы, как программисты не состоялись и уже никогда не состоятся. Ибо их отучили программировать. Именно отучили: видно что многие из них, в принципе, могут научиться этому вновь, но... мы не благотворительная контора.
P.S. А технологии... что технологии. Когда мы считали корелляцию между словами в резюме и результатами собеседований, то выяснили что самую большую по модулю корелляцию даёт слово "certified". Не потому что сертификат сам по себе - это плохо. А потому что если кроме кучи сертификатов у человека "за душой" ничего нет, то вряд ли это хороший программист, а если у него есть куча сертификатов и реальные достижения, то список сертификатов в резюме просто не попадает...
Да, убивать дух и потенцию к творчеству нельзя! Но у кого есть запал,
тот не завянет никогда :) А certified - это и правда первый признак,
что человека надо глубоко капать, прежде чем брать, проверено. :)
тот не завянет никогда :) А certified - это и правда первый признак,
что человека надо глубоко капать, прежде чем брать, проверено. :)
Что касается резюме и корреляций, то наши наблюдения говорят о том, что если в _резюме_ программиста написано среди технологий - фотошоп, то такое резюме почти наверное можно отправлять в топку :). Хотя есть и редкие алмазы - один человек с такой записью делал какуюто заумныую автоматизацию для фотошопа, а не рисовал сайтеги на коленке, как все прочие :)
Скажите пожалуйста, чем объясняется наличие во многих специализированных программах (например те что в банках) исключительно отвратительного интерфейса? Даже то что просто видно на экране заставляет задуматься об удобстве использования такой программой. Понятно, что внутренняя часть очень важна, но это же как отвёртка с сучковатой ручкой. Можно приспособиться, нарастить мазоли в нужных местах и быстро пользоваться таким инструментом. Но удобная ручка повысит производительность и скорость обучения новых сотрудников.
:) Ну вот примерно так и я утверждал. Но самое удивительно, что
удобство - это не ключевой вопрос для компании. Функциональность и
выполнение бизнес задачи - вот ключевой вопрос. Приложения
разрабатываются 3-5 лет, внедряются 2-3 года, используются 10 лет.
Просто физически невозможно переделать приложение ради интерфейса. Да,
приложение кажется "ужасным" с точки зрения текущего момента, но уже
через 1-2 месяца работы вы понимаете, что вводить в фильтре номера
счета %810%_5_% намного эффективнее, чем показывать выпадающий список
из миллиона счетов :)
В общем парятся интерфейсом только те, кто только пришел, а другие
улыбаются и ждут пока они привыкнут. :)
удобство - это не ключевой вопрос для компании. Функциональность и
выполнение бизнес задачи - вот ключевой вопрос. Приложения
разрабатываются 3-5 лет, внедряются 2-3 года, используются 10 лет.
Просто физически невозможно переделать приложение ради интерфейса. Да,
приложение кажется "ужасным" с точки зрения текущего момента, но уже
через 1-2 месяца работы вы понимаете, что вводить в фильтре номера
счета %810%_5_% намного эффективнее, чем показывать выпадающий список
из миллиона счетов :)
В общем парятся интерфейсом только те, кто только пришел, а другие
улыбаются и ждут пока они привыкнут. :)
Сейчас имею удовольствие тестировать подобную программу. В ней не работает Ctrl-F. В ней вообще почти нет горячих клавиш. Масок в поиске тоже нет, как и регулярных выражений. Всё мышкой. Таки это не повод для того, что бы сказать этим программерам "Вон из профессии"?
%810%_5_%А что за такая оригинальная маска? Понятно, что рубли, но зачем "%" и "_"?
% - это любое число символов до или после
_ это один любой символ
:)
Вообще создание программы всегда требует намного больше времени, чем предполагается вначале.
_ это один любой символ
:)
Вообще создание программы всегда требует намного больше времени, чем предполагается вначале.
Вот видите, вы тоже плодите хаос. Почему не "*" и "?"?
Потому что пользователям пофигу, а программистам проще.
Я тоже думаю, что основная проблема во всеобщем пофигизме. В результате одни думаю, что они сделали продукт который вроде работает. А другие просто не подозревают, что есть мир удобных приложений ;)
Похоже, стоит отдельно начать готовить тему "Удобные приложения" :)
Да-да. И начать с пункта "почему соглашение по использованию */? гораздо более правильное, чем %/_". Интересно будет послушать...
*/? наиболее простые маски доступные в windows (это пока базовая ОС на большинстве компов). На самом деле хорошо когда есть вообще хоть какие то маски. Хуже когда в одной программе одни, а в другой другие. Мозг может порой давать сбои :)
В момент когда были введены стандарты %/_ windows не была базовой OS для большинства компов. Даже и близко. Сейчас банковских работников знающих про %/_ - уже миллионы (по всему миру). Мы опять упёрлись в то, что "объективного удобства" не бывает.
Именно так и было :) Сначала был мир, потому Unix, потом SQL, а потом только появился Windows :)
Unix и SQL появились примерно в одно время. Самое начало 70х. Потом из Unix в мир Windows перекочевали */?, а из SEQUEL'я (позже переименованного в SQL) - эти самые %/_ (они и в MSSQL %/_, кстати).
Ух, поразвели дискуссию. А всего-то надо поддержать оба способа, много труда это не займет, пара строчек кода и все. Например, в TCL это делается так:
Аналогичные функции есть во всех языках. Тут я заменяю * на % и ? на _ - и строчка готова для выполнения запроса. А пользователь сам решит, как ему удобнее.
set fstr [regsub -all {\*} $fsrt %]
set fstr [regsub -all {\?} $fstr _]Аналогичные функции есть во всех языках. Тут я заменяю * на % и ? на _ - и строчка готова для выполнения запроса. А пользователь сам решит, как ему удобнее.
Можно долго спорить какие именно должны быть символы и где именно должна быть кнопка особенная. Тем не менее есть общие требования удобства максимальное управление с клавиатуры и не совсем уж дебильное расположение окон. Если в приложении нет поиска по Alt-F (или другой комбинации) то это почти трагедия т.к. мышью ненасчёлкаешься.
Хочется надеяться, что если сейчас вы открыли для себя факт, что программист он не всегда и художник, то в дальнейшем к вам придёт мысль делать красивые и удобные интерфейсы т.к. это правильно и важно. А самое главное хороший интерфейс это не бабло выброшенное на его дизайн, а метод оптимизации процессов.
Хороший интерфейс - это такой интрерфейс, которым удобно пользоваться заказчику и это удобство таки зависит от его привычек в первую голову.
А я вот тоже не подозреваю о существоании такого мира. Просветите, а ? Для справки, приложения, которые я считаю неудобными для себя: MS Office, MS Visual Studio и те, которые я считаю удобными для себя: TeX и Emacs. Если бы существовали какие-то объективно "удобные" приложения, то не было бы этого вечного спора "vi vs emacs". А так - удобными называются те приложения, к которым человек привык. Бывают объективно неудобные приложения (противоречащие возможностям человека), но существование объективно удобных - по-моему фикция.
Об удобстве можно спорить, но программа как минимум должна максимально полно управляться с клавиатуры. К сожалению порой встречаются приложения которые нельзя заменить и в них нет элементарного.
Есть люди, которые пользуются почти исключительно мышью. Хотя для меня пользоваться программой, которая не позволяет обойтись клавиатурой неудобно. В этом смысле есть пример MacOS: вызов меню по Ctrl-F2 мне не кажется удобным, аж никак. Но посмотрите сколько народку кипятком писает от этого дизайна!
Да: в том же Mac'е меню и засунуто-то чёрт-его-знает-куда: наверх экрана. Если у меня HP LP3065 (а у меня на работе именно он), то мне элементарно долго туда "идти" мышью и я хожу по меню с клавиатуры частенько - и тогда хорошо бы иметь меню поближе к окну, на которое это меню воздействует...
Но есть люди, которым это нравится - значит для них это удобно. Правда их назойливое желание объяснить мне что если я не могу пользоваться "супергениальным" интерфейсом MacOS, то проблема во мне и меня надо меня - очень раздражает...
Но есть люди, которым это нравится - значит для них это удобно. Правда их назойливое желание объяснить мне что если я не могу пользоваться "супергениальным" интерфейсом MacOS, то проблема во мне и меня надо меня - очень раздражает...
У Джефа Раскина в "Интерфейс: новые направления в проектировании компьютерных систем" очень хорошо написано по этому поводу.
а вы работает на ЭТОМ мониторе с Маком ?
или это так слова просто чтобы сказать ?
в моем представлении мак это комплекс программы и железки
и в комплексе они работают хорошо
или это так слова просто чтобы сказать ?
в моем представлении мак это комплекс программы и железки
и в комплексе они работают хорошо
Нет - как я уже сказал меня от интерфейса Мака воротит (главным образом от неправильного расположения меню и отсутствия клавиши Del на клавиатуре). Был выбор (собственно и сейчас есть) - я выбрал Linux. Но у нас в конторе есть люди, которые на этом мониторе работают с Маком. Видимо им так удобнее.
P.S. У Apple есть и свой 30" монитор - и картинка на нём выглядит в точности как на HP, так что я не понял разговоров про "комплекс программы и железки"...
P.S. У Apple есть и свой 30" монитор - и картинка на нём выглядит в точности как на HP, так что я не понял разговоров про "комплекс программы и железки"...
про комплекс - я имел в виду что любой гуи в общем случае расчитан на определенный размер интерфейса, и в частности под такой здоровый монитор гуи надо переделывать,
другая идеология нужна.
как пример, Vista явно хочет минимум 1280x1024, на меньшем разрешении она смотрится не интересно ...
а на очень большом - думаю тоже будет ей пользоваться не удобно
другая идеология нужна.
как пример, Vista явно хочет минимум 1280x1024, на меньшем разрешении она смотрится не интересно ...
а на очень большом - думаю тоже будет ей пользоваться не удобно
>отсутствия клавиши Del на клавиатуре
она там есть, не врите.
она там есть, не врите.
меню всегда наверху, его не надо искать.
>мне элементарно долго туда "идти" мышью
вообще меню ни кто практически никогда не пользуется на маках.
вообще меню ни кто практически никогда не пользуется на маках.
Зачем тогда оно там висит и место отнимает ? На работе на 2560x1600 это не так важно, но на OQO я пользуюсь терминалом (где меню действительно не нужно) с отключённым меню. Но как я уже говорил - о вкусах не спорят: нравится вам то, что Стив придумал, ради бога - пользуйте. Только не надо мне объяснять, что в этих сапогах удобно. Жмут они мне. Нога у меня нестандартная, наверное. И уж лучше я буду использовать сапоги, которые мне не жмут, чем ходить с вымученной улыбкой, уж извините...
что такое сtrl+F2?
Да я LaTeX когда-то курсовую писал (численный методы). В то время никогда бы не подумал, что он может кому-то удобен. Пока не написал диплом в Word. Ввод формул это просто ужас. Как в TeX было классно. Опять же уверен для большинства пользователей vi и emacs будут чем то ужасным. Пока они не столкунуться с задачами, которые эти программы решают лучше.
Любое качественное определение оценивается как общее для большинства, иначего говорить об объективности вообще нельзя. Для любого интерфейса найдётся человек, который «привык», «удобно» и «нравится».
Да не я это плодил, Оракл во всем виноват :) Индийские программисты. Ну так у них было придумано.
Это надо спрашивать у создателей стандарта SQL. Насколько я понимаю, эти спецсимволы уже закреплены в стандарте - поэтому они и используются, и не только в Оракле, но и в MS-SQL, и в MySQL, и вобще везде в SQL-запросах.
Собственно, воодить можно и *810*?5?* - просто тогда надо предусматривать замен этих символов на понятные SQL-запросу % и _ . Ничего сверхестественного - просто кому-то было лень вновить это в техзадание при проектировании :)
Собственно, воодить можно и *810*?5?* - просто тогда надо предусматривать замен этих символов на понятные SQL-запросу % и _ . Ничего сверхестественного - просто кому-то было лень вновить это в техзадание при проектировании :)
хмм, странная однако маска =)? не поясните ли "%_":
любое количество символов+1 это как бесконечность+1.
Единственную расшифровку я вижу в виде условия что от 810 до 5 должен стоять 1 или более символов ( а % дает 0 или более символов) и 5 не должно быть последним символом. А это вообще применяемая выборка или так, из головы ?
любое количество символов+1 это как бесконечность+1.
Единственную расшифровку я вижу в виде условия что от 810 до 5 должен стоять 1 или более символов ( а % дает 0 или более символов) и 5 не должно быть последним символом. А это вообще применяемая выборка или так, из головы ?
Интерфейсы, написанные программистами для банковских служащих? =)
> Просто физически невозможно переделать приложение ради интерфейса.
а почему сразу нельзя проектировать приложения с ориентацией на хороший интерфейс? )
> В общем парятся интерфейсом только те, кто только пришел, а
> другие улыбаются и ждут пока они привыкнут.
Все программы, написанные по принципу "мыши пищали, давились, но жрали кактус", успешны лишь до того момента пока на рынок не выйдет грамотный конкурент, ориентированный на конечного пользователя ^)
а почему сразу нельзя проектировать приложения с ориентацией на хороший интерфейс? )
> В общем парятся интерфейсом только те, кто только пришел, а
> другие улыбаются и ждут пока они привыкнут.
Все программы, написанные по принципу "мыши пищали, давились, но жрали кактус", успешны лишь до того момента пока на рынок не выйдет грамотный конкурент, ориентированный на конечного пользователя ^)
> Все программы, написанные по принципу "мыши пищали, давились,
> но жрали кактус", успешны лишь до того момента пока на рынок
> не выйдет грамотный конкурент, ориентированный на конечного
> пользователя ^)
А не выйдет конкурент. Никогда. Порог вхождения в нишу высок черезчур. На рынке энтерпрайз софтдевелопмента заморачиваться юаем реально невыгодно.
Комменты веселые. Авторы считают "проги с уродским интерфейсом" редким и временным явлением.
> но жрали кактус", успешны лишь до того момента пока на рынок
> не выйдет грамотный конкурент, ориентированный на конечного
> пользователя ^)
А не выйдет конкурент. Никогда. Порог вхождения в нишу высок черезчур. На рынке энтерпрайз софтдевелопмента заморачиваться юаем реально невыгодно.
Комменты веселые. Авторы считают "проги с уродским интерфейсом" редким и временным явлением.
Хорший вопрос - половина ответа. Удобная ручка повысит производительность и скорость обучения новых сотрудников. Как правило специализированные программы (типа банковских) меняются не часто, а очень часто. И новые "ручки" в них приходится добавлять так, чтобы они не затронули старых - что, разумеется, приводит к определённой сучковатости. Если переделать интерфейс с нуля, то
1. Потеря эффективности старыми сотрудниками на какое-то время гарантирована (это - потерянные деньги)
2. После переучивания эффективность на какое-то время возрастёт (это - приобретённая прибыль)
3. Через какое-то время проблема вернётся ибо изменения в требованиях никуда не исчезнут...
Иногда аккуратные подсчёты показывают, что пункт 2 всё-таки имеет шанс перекрыть пункт 1 - и тогда программы всё-таки переделывают...
Кроме всего прочего есть такой странный фактор, который со стороны кажется безумием, а на практике - просто необходим: неиспользование мыши. Просто человек может нажать 5-10 кнопок в секунду (в зависимости от квалификации), а щёлкнуть мышкой - один-два раза (и вероятность попасть "не туда" на порядок выше). Потому "странные", "безумные", "ненужные" манипуляции типа открытия/закрытия кучи окошек с помощью Enter'а и Escape'а - зачастую на самом деле лучше, чем "простая и удобная палитра интсрументов"...
P.S. Кстати насчёт палитры инструментов. В Photoshop она, вроде как, есть. Много вы видели художников, которые бы в неё тыкали мышкой ? А в заказной программе делать инструмент, которым не будут прользоваться - попросту расточительно...
1. Потеря эффективности старыми сотрудниками на какое-то время гарантирована (это - потерянные деньги)
2. После переучивания эффективность на какое-то время возрастёт (это - приобретённая прибыль)
3. Через какое-то время проблема вернётся ибо изменения в требованиях никуда не исчезнут...
Иногда аккуратные подсчёты показывают, что пункт 2 всё-таки имеет шанс перекрыть пункт 1 - и тогда программы всё-таки переделывают...
Кроме всего прочего есть такой странный фактор, который со стороны кажется безумием, а на практике - просто необходим: неиспользование мыши. Просто человек может нажать 5-10 кнопок в секунду (в зависимости от квалификации), а щёлкнуть мышкой - один-два раза (и вероятность попасть "не туда" на порядок выше). Потому "странные", "безумные", "ненужные" манипуляции типа открытия/закрытия кучи окошек с помощью Enter'а и Escape'а - зачастую на самом деле лучше, чем "простая и удобная палитра интсрументов"...
P.S. Кстати насчёт палитры инструментов. В Photoshop она, вроде как, есть. Много вы видели художников, которые бы в неё тыкали мышкой ? А в заказной программе делать инструмент, которым не будут прользоваться - попросту расточительно...
Согласен с доводами про 1-3. Обычно еще добавляется 4.
4. Действия 1-3 никак не решают актуальных задач организации, что дает дополнительный голос для тех, кто говорит, что ничего не надо переделывать.
4. Действия 1-3 никак не решают актуальных задач организации, что дает дополнительный голос для тех, кто говорит, что ничего не надо переделывать.
Очень, очень нехороший подход. Ликвидация последствий ошибкок пользователей, вызванных этими самыми "сучками", может выливаться во вполне конкретные деньги.
Я в свое время прошел через ту же ситуацию - десяток мегабайт г*внокода на FoxPro 2.6 со свалкой DBF-файлов общего объема гигабайт под 50 (правда у меня хватило самоконтроля не бросаться это переписывать с нуля) + порядка сотни разбросанных по области неквалифицированных пользователей в ~50 организациях с огромной текучкой кадров. Обстановку совершенно не улучшали постоянные кофликты из-за ошибок пользователей, за которые на организации накладывали штрафы / денежные вычеты. Так вот, после пары месяцев работы над интерфейсом (информационные сообщения, более адекватный порядок обхода полей, горячие клавиши и тому подобное) количество записей, содержащих ошибки, сократилось на два порядка: с нескольких десятков тысяч до нескольких сотен (из ~200 тысяч ежемесячно).
Важно отметить, что до начала правок интерфейса пользователи уже работали с программой в течение примерно полугода, так что уменьшение количества ошибок "привыканием" к программе объяснить трудно.
Я в свое время прошел через ту же ситуацию - десяток мегабайт г*внокода на FoxPro 2.6 со свалкой DBF-файлов общего объема гигабайт под 50 (правда у меня хватило самоконтроля не бросаться это переписывать с нуля) + порядка сотни разбросанных по области неквалифицированных пользователей в ~50 организациях с огромной текучкой кадров. Обстановку совершенно не улучшали постоянные кофликты из-за ошибок пользователей, за которые на организации накладывали штрафы / денежные вычеты. Так вот, после пары месяцев работы над интерфейсом (информационные сообщения, более адекватный порядок обхода полей, горячие клавиши и тому подобное) количество записей, содержащих ошибки, сократилось на два порядка: с нескольких десятков тысяч до нескольких сотен (из ~200 тысяч ежемесячно).
Важно отметить, что до начала правок интерфейса пользователи уже работали с программой в течение примерно полугода, так что уменьшение количества ошибок "привыканием" к программе объяснить трудно.
Про фотошоп не соглашусь. В графических пакетах бывает куда быстрей ткнуть стилусом в пиктограмку, нежели вспоминать хоткей.
Бывает. Но, гораздо чаще, всё-таки удобнее одной рукой держать стило или мыша, а другой, в это время, тыкать по кнопкам.
Тебе всё равно нужно вспоминать где "оно" прячется (на многие кнопки навешано много инструментов). Проще в таком случае через меню. Но тут и такой момент есть: что ж ты за профи, если не можешь запомнить два десяткая сочетаний клавиш ?
Нанимайте квалифицированных сотрудников - кому ни csh ни sqlplus не страшен.
Вы представляете себе разницу в зарплатах человека вводящего цифры и знающего sqlplus?
Представил себе картину, прихожу я в сбербанк оплачивать коммуналку, а там оператор вводит инфу в базу sql запросами. И обратно читает тоже в сыром виде все данные ;)
главное чтоб он попутно sql-сервер не переписывал.
Достаточно умного, что бы понимать, что синтаксис маски поиска - не критерий, при своих 2 символах вообще только ибецилу может быть не понятен, мышка и любые рюшечки - зло, для софта производящего бабло.
И по аналогии, для алтерна.., гуманитариев - оператор в банке ничем не отличается от водителя карьерного самосвала.
И по аналогии, для алтерна.., гуманитариев - оператор в банке ничем не отличается от водителя карьерного самосвала.
Не знаю о каких софтинках Вы говорите, у нас в банчке прекрасный текстовый интерфейс, юзверь ssh-шится на сервер и работат. Никаких рюшечек, гуевинок и протчая берлиберда. Идеальное решение.
А как зовут эту великолепную программу?
АБС «БИС ГРАНТ»
http://www.banksoft.com.ua/index.php?id=7
http://www.banksoft.com.ua/index.php?id=7
Клиентское рабочее место:
Возможны следующие конфигурации рабочего места:
* дисковая станция MS Windows/9x/NT/2000/XP в любой конфигурации;
* дисковая станция Linux в любой конфигурации;
На рабочем месте используются эмуляторы терминала, адаптированные для работы АБС «БИС ГРАНТ»:
* PuTTY (Windows-приложение, защищённый протокол SSH);
* PuTTY (Linux, защищённый протокол SSH);
Сервера - под RHEL
http://www.banksoft.com.ua/index.php?id=78
Возможны следующие конфигурации рабочего места:
* дисковая станция MS Windows/9x/NT/2000/XP в любой конфигурации;
* дисковая станция Linux в любой конфигурации;
На рабочем месте используются эмуляторы терминала, адаптированные для работы АБС «БИС ГРАНТ»:
* PuTTY (Windows-приложение, защищённый протокол SSH);
* PuTTY (Linux, защищённый протокол SSH);
Сервера - под RHEL
http://www.banksoft.com.ua/index.php?id=78
Нее маркетологи как раз считают, что их работа искуство :) они просто об этом не кричат)
Мне кажется, оба качества, которые Вы описываете должны присутствовать. На работе нужно работать и решать поставленную задачу наилучшим образом в данной конкретной ситуации, а не рассуждать о том, как её лучше решить вообще! Отношение к программированию как к искусству позволяет получать определенные базовые знания, которые можно применить в любом (или почти любом) проекте, то есть качественно повышает уровень программиста.
Кстати, судя по профайлу... С Днем Рождения!
Кстати, судя по профайлу... С Днем Рождения!
Прекрасная статья. Единственное, что я бы разбил ее на три части(которые автор сам и выделил): "Программирование как искусство", "Программирование как ремесло" и "Программирование: Ремесло или Искусство?". Зачем, спросите? Затем, что я(и думаю, не только я) бы с удовольствием всё это прочёл :)
Блин, один в один моя история сначала.
Я тоже начинал на 2м курсе с банка, с кучи огромных неоптимизированных баз данных в дбф с безбожно устаревшим фокспрошным или досовским интерфейсом, отчетов, экселя, и того, что штатные кодеры тырили у меня-практиканта код и даже удаляли мои исходники лапшерезкой хз из каких побуждений.
Но, поработав там с год, я забил на айти и пошел по финансово-экономическому профилю. Правда, последние годы все сильнее тянет обратно, к веб-разработке, ибо творить программы — это наркотик. Наверное, так и буду скакать туда-сюда, мультикласс.
Я тоже начинал на 2м курсе с банка, с кучи огромных неоптимизированных баз данных в дбф с безбожно устаревшим фокспрошным или досовским интерфейсом, отчетов, экселя, и того, что штатные кодеры тырили у меня-практиканта код и даже удаляли мои исходники лапшерезкой хз из каких побуждений.
Но, поработав там с год, я забил на айти и пошел по финансово-экономическому профилю. Правда, последние годы все сильнее тянет обратно, к веб-разработке, ибо творить программы — это наркотик. Наверное, так и буду скакать туда-сюда, мультикласс.
Спасибо за статтю! Мне понравилось.
отличный материал просто в точку! спасибо и с днем рождения!
Отличная тема чтобы в пятницу подискутировать с коллегами под бутылочку пивка. Искусство или не искусство. Истина, как всегда, где-то посередине.
Попросите любого художника дорисовать что-то к картине его коллеги :)
Я из маркетологов, работающих в ИТ компаниях, и наблюдаю "творческий процесс программиста" в непосредственной близости и контакте))... Про программистов, находящихся в стадии творческого роста, скажу так, они есть...НО!
"Ему все время хочется учиться, изучать новые технологии, писать на самом новом инструментарии, переписывать приложение на новый язык или версию системы, обновлять свой компьютер, среду разработки, ставить патчи, прошить новую версию bios..."
Только варится "наш" российских программист в собственном соку, точнее в соке своего творческого роста, это процесс можно охарактеризовать так:"искусство ради искусства". И не хочет слышать, что пользователь не знает кнопки Fn...))) "ну как же так! возмущается программист. Я же говорю очевидные вещи!" И вот тут очень сложно доказать программисту, что пользователь-не специалист по кнопкам Fn))))
А вообще, не умение соединять разработку и денежку, неумение коммерциализировать собственные программные продукты - это минус нашего российского образования, то, как учат айтишников (в принципе тоже самое можно сказать про другие области). Ведь выпускники МИТ , например, основали ни один десяток успешных ИТ компаний, запустили стартапы, которые сейчас оцениваются в миллиарды долларов, не всегда был изначальных капитал. Отчего так? и почему программист зачастую не видит продукт "в перспективе", не видит как сделать так, чтобы продукт стал успешен в "реальном мире", тот продукт, который он вроде оттачивает и доводит до совершенства.
"Ему все время хочется учиться, изучать новые технологии, писать на самом новом инструментарии, переписывать приложение на новый язык или версию системы, обновлять свой компьютер, среду разработки, ставить патчи, прошить новую версию bios..."
Только варится "наш" российских программист в собственном соку, точнее в соке своего творческого роста, это процесс можно охарактеризовать так:"искусство ради искусства". И не хочет слышать, что пользователь не знает кнопки Fn...))) "ну как же так! возмущается программист. Я же говорю очевидные вещи!" И вот тут очень сложно доказать программисту, что пользователь-не специалист по кнопкам Fn))))
А вообще, не умение соединять разработку и денежку, неумение коммерциализировать собственные программные продукты - это минус нашего российского образования, то, как учат айтишников (в принципе тоже самое можно сказать про другие области). Ведь выпускники МИТ , например, основали ни один десяток успешных ИТ компаний, запустили стартапы, которые сейчас оцениваются в миллиарды долларов, не всегда был изначальных капитал. Отчего так? и почему программист зачастую не видит продукт "в перспективе", не видит как сделать так, чтобы продукт стал успешен в "реальном мире", тот продукт, который он вроде оттачивает и доводит до совершенства.
Да, очень важно видеть точно цель, уметь быстро и оперативно
адаптироваться, доверять своим коллегам но и требовать от них отдачи.
И этому НУЖНО УЧИТЬ! Само это приходит редко или поздно.
Очень хочется, чтобы Россия славилась не только хорошими программистами, которых запад использует как генераторы идей, но и своими продуктами.
адаптироваться, доверять своим коллегам но и требовать от них отдачи.
И этому НУЖНО УЧИТЬ! Само это приходит редко или поздно.
Очень хочется, чтобы Россия славилась не только хорошими программистами, которых запад использует как генераторы идей, но и своими продуктами.
"Чистый" программист это в первую очередь технический специалист - инженер. В других отраслях поверте, то же самое. В IT заказчик и программист довольно сближены. Например, проекты под заказ, это как костюм, они должны хорошо "сидеть" на заказчике иначе будут проблемы :-). Так вот тех. специалист не думает как продать продукт, правда проблема в то том, что иногда некоторые и не думаю как им пользоваться дургим людям. Если все тех. специалисты будут уметь и главное хотеть заниматься комерцией? то они оставят "маркетологов, работающих в ИТ компаниях," и их компании и побегут организовывать свой стартап, то есть сами для себя будут и маркетологом и заказчиком, и буду предлагать конечный продукт людям. Тут правда есть одна проблема, все же человечество не даром прошло индустриализацию и от мануфактур, семейных подрядов и вольных ремеслеников перешло к фабрикам и заводам :-). То есть для реально крупных проектов нужна организация и разделение труда. Попробуйте намекнуть, что то что разработчик хочет сделать, нужно только ему. И если ему это надо, то может купить этот проект и разрабатывать на свой вкус :-). По моему глупо делать, то что людям не нужно. Другое дело, конечно, если человек уверен в том, что то, что он предлагает нужно людям. Тогда приведите аргументы, доказательства.
Хотелось бы прокомментировать переход от вольных ремесленников к заводам.
Прежде всего, ремесленники не исчезли. Завод лишь способ массового производства сложного продукта. Если продукт уже не так сложен (улучшились средства производства) или не массовый (что-то специализированное, особенно услуги разного рода), то с заводами вполне могут конкурировать маленькие фирмы (причем чаще всего получая средства производства и расходные материалы от заводов).
В России же, по ощущениям, еще слишком мало малого бизнеса.
Прежде всего, ремесленники не исчезли. Завод лишь способ массового производства сложного продукта. Если продукт уже не так сложен (улучшились средства производства) или не массовый (что-то специализированное, особенно услуги разного рода), то с заводами вполне могут конкурировать маленькие фирмы (причем чаще всего получая средства производства и расходные материалы от заводов).
В России же, по ощущениям, еще слишком мало малого бизнеса.
Действительно вспоминая все те жуткие дисциплины которым меня учили нет ни одно, касательно коммерческой стороны программного продукта. Был какой-то курс по организации разработки ПО, лектор из Моторолы читал и все...
Искусство ради Искусства - вот наш удел:)
Искусство ради Искусства - вот наш удел:)
Я могу вам чесно сказать - вы, как "маркетолог, который пытается понять программиста и пользователя" - очень редкий, можно сказать исчезающий вид. Большинство маркетологов которые мне встречались по жизни (может, конечно, жизнь такая) - надутые и самовлюбленные существа, которые просто неспособны что-то осмысливать, зато очень хорошо "гнут пальцы", потому как современное общество создало миф о престижности их профессии (Как в анекдоте про морских свинок - "не имеют отношения ни к морю, ни к свиньям").
Продолжайте стараться понять программиста, а не убедить его что он не прав.
В конце концов нельзя требовать интерфейс или программу, через которую любая умственно отсталая кухарка смогла бы управлять "государством" ("рулить банком" =) ). Должен существовать определенный порог вхождения "в программу", т.е. человек, пусть он даже десять раз директор, должен иметь определенные навыки пользования компьютером, чтобы работать с серьезной программой (или должен иметь секретаршу, которая за него все делает). По-другому - никак. Те же выпускники МИТ, перед тем как основывать стартапы - много и упорно трудились, изучали и технические и финансовые дисциплины.
Для того чтобы "двигать горы" нужна прочная база под ногами, а выпускник ПТУ на базе 7 классов в кресле директора "папенькиного" бизнеса - смешон, какая бы ни была у него зарплата и должность.
Продолжайте стараться понять программиста, а не убедить его что он не прав.
В конце концов нельзя требовать интерфейс или программу, через которую любая умственно отсталая кухарка смогла бы управлять "государством" ("рулить банком" =) ). Должен существовать определенный порог вхождения "в программу", т.е. человек, пусть он даже десять раз директор, должен иметь определенные навыки пользования компьютером, чтобы работать с серьезной программой (или должен иметь секретаршу, которая за него все делает). По-другому - никак. Те же выпускники МИТ, перед тем как основывать стартапы - много и упорно трудились, изучали и технические и финансовые дисциплины.
Для того чтобы "двигать горы" нужна прочная база под ногами, а выпускник ПТУ на базе 7 классов в кресле директора "папенькиного" бизнеса - смешон, какая бы ни была у него зарплата и должность.
"не умение" воощета в месте пишедца, привет маркетологам работающим в ИТ компаниях
НЛО прилетело и опубликовало эту надпись здесь
Может быть, программисты отказывались поддерживать систему вашего приятеля, не потому что считали поддержку чужого, несовместимым со своим искусством? Может быть просто эта конкретная система была ужасной?
Может быть :) Но я не спрашивал его, да и он не мог ничего сказать кроме того, что на ней стоит его бизнес. Не программист он, директор.
Это, собственно, уже ответ. Представь себе что тебя пригласили следить за домом, который как-то стоит, но в нём есть протечки, где-то короткие замыкания, откуда-то сквозит и т.п., а плана, по которому построен дом - нету.
За что ты возьмёшь больше: за поддержание дома в рабочем состоянии или за строительство нового ? В случае если материалы оплатичивает заказчик строительность нового будет в разы дешевле и проще. И в программировании так же - с единственным отличием, что "исходные материалы" в программировании ничего не стоят...
За что ты возьмёшь больше: за поддержание дома в рабочем состоянии или за строительство нового ? В случае если материалы оплатичивает заказчик строительность нового будет в разы дешевле и проще. И в программировании так же - с единственным отличием, что "исходные материалы" в программировании ничего не стоят...
@с единственным отличием, что "исходные материалы" в программировании ничего не стоят...@
и с тем, что нет гарантии что новый дом будет хоть как то стоять...
@В случае если материалы оплатичивает заказчик строительность нового будет в разы дешевле и проще@
Для кого дешевле и для кого проще? По-моему, для программиста.
и с тем, что нет гарантии что новый дом будет хоть как то стоять...
@В случае если материалы оплатичивает заказчик строительность нового будет в разы дешевле и проще@
Для кого дешевле и для кого проще? По-моему, для программиста.
это применимо не только к программированию :)
спасибо, статья отличная на мой взгляд
спасибо, статья отличная на мой взгляд
Великолепно! Спасибо! Статья заставила задуматься :)
Вы правы лишь отчасти. "Новые технологии", слава богу, разрабатываются достаточно умными и профессиональными людьми и цель их - облегчить ваш труд. Да, всегда найдутся кулхацкеры готовые все переписать чуть не под ассемблер, но проблема немного в другом.
Первому бынку вы оказали очень хорошую услугу - вы сделали им задел на будущее. Во втором банке типичная ситуация "жареный петух пока ещё не клюнул". Я работал в компании, которая делала почти-ERP систему на Oracle и Forms. За пресловутые 10 лет система превратилась в кашу, которую невозможно поддерживать, дорабатывать и, что самое главное, практически невозможно переписать, потому что из компании ушли те люди, которое это делали, а никто из вновь пришедших разобраться в эом дерьме не может. И это удел любой системы на устаревшей технологии типа Forms.
Люди, которых вы благодарили в статье держаться за эту технологию, потому что _пока_ они понимают как она работает, потом они уволятся и начнется ад.
Ответ прост, не надо крайностей, не надо 10 лет.
Первому бынку вы оказали очень хорошую услугу - вы сделали им задел на будущее. Во втором банке типичная ситуация "жареный петух пока ещё не клюнул". Я работал в компании, которая делала почти-ERP систему на Oracle и Forms. За пресловутые 10 лет система превратилась в кашу, которую невозможно поддерживать, дорабатывать и, что самое главное, практически невозможно переписать, потому что из компании ушли те люди, которое это делали, а никто из вновь пришедших разобраться в эом дерьме не может. И это удел любой системы на устаревшей технологии типа Forms.
Люди, которых вы благодарили в статье держаться за эту технологию, потому что _пока_ они понимают как она работает, потом они уволятся и начнется ад.
Ответ прост, не надо крайностей, не надо 10 лет.
Да, согласен. Тут нужен баланс. Потому кстати и фох про еще жив и cobol. Но по моему о переходе на новые технологии должен думать тех. директор (или кто-то, но не рядовой программист, но программист может помечтать об этом :-) ) и это должно быть в бюджете компании. А также должна быть посчитана окупаемость все этого предприятия. И если дело стоиящее, то нужно работать, а не держаться за старье.
На самом деле нужно сначала работать, а потом уже считать. Без программистов сколько-нибудь достоверно что-то просчитать не получится. Конечно из 10 человек 9 должны поддерживать работающую систему, но должен быть и 1, который проводит исследования. Ведь тут как и в любом деле вопрос не "если", а "когда".
P.S. Почему производителям автомобилей, самолётов и даже кофеварок не нужно объяснять что есть такое понятие "ресурс модернизации" и что в какой-то момент нужно прекратить улучшать работающую конструкцию и создать что-то новое, а производителям программ в таком праве нередко отказывают ?
P.S. Почему производителям автомобилей, самолётов и даже кофеварок не нужно объяснять что есть такое понятие "ресурс модернизации" и что в какой-то момент нужно прекратить улучшать работающую конструкцию и создать что-то новое, а производителям программ в таком праве нередко отказывают ?
Я имел ввиду немного более общий случай по моему. Например переход с FoxPro 2 на клиент-серверную базу.
Вот например, что я видел в самом начале своей карьеры.
Было небольшое агенство недвижимости (они тогда только набирали силу). У этого агенства была база данных на FoxPro 2, которая отлично справлялась со своей задачей. А именно база данных обектов недвижимости. Написана база была программисто-фрилансером, который написал и ушел, но обещал вернуться (своего айти отдела у них естесвенно не было).
Справлялась пока агенство не раскрутилось и не открыло 2 офиса, каждое утро человек с дискеткой обновлял базу :-). Потом офисов стало 3. Короче все длилось пока уже физически стало нереально держать все в таком виде.
В принципе особых исследований тут не нужно. И так ясно, что нужно было переходить на другую СУБД.
Я думаю во многих фирмах, и с собственным IT отделом, очень часто подобная ситуация возникает. Тут не нужно проводить особых постоянных исследлований.
Это как запущеная бользне. Сначала просто надоедливо напоминает, а потом может и убить.
Вот например, что я видел в самом начале своей карьеры.
Было небольшое агенство недвижимости (они тогда только набирали силу). У этого агенства была база данных на FoxPro 2, которая отлично справлялась со своей задачей. А именно база данных обектов недвижимости. Написана база была программисто-фрилансером, который написал и ушел, но обещал вернуться (своего айти отдела у них естесвенно не было).
Справлялась пока агенство не раскрутилось и не открыло 2 офиса, каждое утро человек с дискеткой обновлял базу :-). Потом офисов стало 3. Короче все длилось пока уже физически стало нереально держать все в таком виде.
В принципе особых исследований тут не нужно. И так ясно, что нужно было переходить на другую СУБД.
Я думаю во многих фирмах, и с собственным IT отделом, очень часто подобная ситуация возникает. Тут не нужно проводить особых постоянных исследлований.
Это как запущеная бользне. Сначала просто надоедливо напоминает, а потом может и убить.
Любопытное мнение. Но вы не правы, на мой взгляд. Точнее мысли верные
безусловно есть, не отвертеться :), но в целом комментарий и оттенок мне
не импонирует.
Сегодня в этом банке работают Forms в части основной системы. Ритейл,
пластик и ряд других систем уже реконструированы. Готовится переход и
главной системы на новое приложение, но тут тоже Forms только виндовый
уже и приложение новое. За 10 лет использование приложение окупило
себя полностью.
Удерживать коллектив, передавать задачу... да, это правильные мысли.
Но степень зависимости должна быть ограниченной, риски должны
управляться.
безусловно есть, не отвертеться :), но в целом комментарий и оттенок мне
не импонирует.
Сегодня в этом банке работают Forms в части основной системы. Ритейл,
пластик и ряд других систем уже реконструированы. Готовится переход и
главной системы на новое приложение, но тут тоже Forms только виндовый
уже и приложение новое. За 10 лет использование приложение окупило
себя полностью.
Удерживать коллектив, передавать задачу... да, это правильные мысли.
Но степень зависимости должна быть ограниченной, риски должны
управляться.
Ну так у вас тоже получается мысли верные, а оттенок - не очень.
Вы, оказывается, переходите всё-таки на новые технологии, но постепенно. Это правильно.
Тода о чём статья? Приходит студент и говорит "да у вас тут кобол. нанимайте ещё четверых все переписываем" и менеджеры "да, да, конечно вот вам миллион"? Ну менеджеры дураки, да так и не бывает, по большому счету.
А в статье такое впечатление, что вот только так и будет. :)
Вы, оказывается, переходите всё-таки на новые технологии, но постепенно. Это правильно.
Тода о чём статья? Приходит студент и говорит "да у вас тут кобол. нанимайте ещё четверых все переписываем" и менеджеры "да, да, конечно вот вам миллион"? Ну менеджеры дураки, да так и не бывает, по большому счету.
А в статье такое впечатление, что вот только так и будет. :)
Да нет, я мне кажется наоборот старался уйти от прямых выводов и суждений, подводя все к общей формуле "профессионализма", понимая, что единой формулы не бывает.
Ну а что "профессионализм"? Я вот поработал над Forms, с удовольствием уволился из этой конторы и действительно не буду больше работать с ними (формсами) даже за два оклада. И при этом я за год работы стал в какой-то мере профессионалом.
Я бы сказал не "профессионализм", а "ответственность". Нужно понимать, какими действиями ты фирму можешь подставить, а какими нет.
Я бы сказал не "профессионализм", а "ответственность". Нужно понимать, какими действиями ты фирму можешь подставить, а какими нет.
> Я работал в компании, которая делала почти-ERP систему на Oracle и Forms.
> И это удел любой системы на устаревшей технологии типа Forms.
Бардак в проекте и инструмент ИМХО никак не релируют.
Крайние варианты а-ля "клеить дырочки в перфоленте с целью редактирования сырцов" не рассматириваем. :)
> И это удел любой системы на устаревшей технологии типа Forms.
Бардак в проекте и инструмент ИМХО никак не релируют.
Крайние варианты а-ля "клеить дырочки в перфоленте с целью редактирования сырцов" не рассматириваем. :)
Не соглашусь. Forms - процедурно-модульная система, которая кроме всего прочего чуть ли не поощряет включение бизнес-функций в представление (это я о Forms 5). Именно в этом её "старость".
Не отрицаю, в абсолютно идеальных условиях при наличии идеальных программистов, которые ведут проект от создания структуры файлов до банкротства, в таких условиях можно написать сколь угодно сложную систему на любом языке, включая брэйнфак :)
Однако, в реальной жизни ERP-система, которая 10 лет строится на процедурном подходе - обречена. Сменится команда, начальство решит "расширить" функционал и т.д.
Не отрицаю, в абсолютно идеальных условиях при наличии идеальных программистов, которые ведут проект от создания структуры файлов до банкротства, в таких условиях можно написать сколь угодно сложную систему на любом языке, включая брэйнфак :)
Однако, в реальной жизни ERP-система, которая 10 лет строится на процедурном подходе - обречена. Сменится команда, начальство решит "расширить" функционал и т.д.
> Forms - процедурно-модульная система, которая кроме всего прочего чуть ли не поощряет включение бизнес-функций в представление (это я о Forms 5). Именно в этом её "старость".
Эх! Уж сколько раз твердили миру: на самом деле нет разницы между объектным и процедурным подходами, есть разница в проектировании и дальнейшем "неуходе от".
> в таких условиях можно написать сколь угодно сложную систему на любом языке, включая брэйнфак :)
В таких случаях обычно предпочитают онофф, ибо брэйнфак обладает ненужной избыточностью :)
Эх! Уж сколько раз твердили миру: на самом деле нет разницы между объектным и процедурным подходами, есть разница в проектировании и дальнейшем "неуходе от".
> в таких условиях можно написать сколь угодно сложную систему на любом языке, включая брэйнфак :)
В таких случаях обычно предпочитают онофф, ибо брэйнфак обладает ненужной избыточностью :)
Да статья интересная, но в некоторых местах спорная. И вообще побуждает интересные дискуссии.
Начет поддержки старого не своего кода. Тут дело не в искусстве. А в мороке и ответвенности. Взялся порддерживать все баги твои. Да, можешь обяснять, что баг этот изночально был, что спроектировали или реализовали, что-то криво. Опятьже если код плохо документирован, несколько раз по быстрому добавлялись фичи (о такое часто бывает), то правка чего-то может привести к непредсказуемым результатам. Тут уже чистый бизнес. Зачем браться за такое неблагодарное и стремное дело, когда можно заработать на другом и гораздо быстрее. Вот такой вот деловой подход.
Начет поддержки старого не своего кода. Тут дело не в искусстве. А в мороке и ответвенности. Взялся порддерживать все баги твои. Да, можешь обяснять, что баг этот изночально был, что спроектировали или реализовали, что-то криво. Опятьже если код плохо документирован, несколько раз по быстрому добавлялись фичи (о такое часто бывает), то правка чего-то может привести к непредсказуемым результатам. Тут уже чистый бизнес. Зачем браться за такое неблагодарное и стремное дело, когда можно заработать на другом и гораздо быстрее. Вот такой вот деловой подход.
Накрыло....
"Если переписывать с нуля - соглашаются за половину зарплаты. Если поддерживать - не соглашаются за две"
"почему мне в университете ни один преподаватель не сказал, что, приходя на работу, мы должны реализовывать бизнес задачу компании наиболее точно и использовать наиболее эффективный инструментарий для этой реализации"
Потому что программист... да что там, любой человек, выбирая себе работу, _никому и ничего не должен_. Представление о том, что выбор профессии налагает некие обязанности - странен. Обязанности налагает контракт с работодателем. Если человек не соглашается за две зарплаты поддерживать чужой продукт - значит, он высоко оценивает собственные шансы найти занятость, более полно соответствующую его представлениям об оплате труда и удовлетворению, получаемому от работы.
Не говоря уже о том, что поддержка чужого кода в большинстве случаев - скука и боль. Нет, не так. БОЛЬ.
Вы же совершенно чудесно изложили несколько success stories, когда свежий взгляд на проблему привел к более эффективному ее решению. Главное, чтобы результат удовлетворял требованиям и ограничениям компании и укладывался в бюджет и сроки. Если при этом он оказывается более емким, элегантным, мощным или масштабируемым, чем предполагалось - тем лучше. Просто в том же Инвестбанке ограничения, налагаемые на решение, оказались более суровыми, чем вам встречались до того - и это тоже вполне нормальная ситуация.
"почему мне в университете ни один преподаватель не сказал, что, приходя на работу, мы должны реализовывать бизнес задачу компании наиболее точно и использовать наиболее эффективный инструментарий для этой реализации"
Потому что программист... да что там, любой человек, выбирая себе работу, _никому и ничего не должен_. Представление о том, что выбор профессии налагает некие обязанности - странен. Обязанности налагает контракт с работодателем. Если человек не соглашается за две зарплаты поддерживать чужой продукт - значит, он высоко оценивает собственные шансы найти занятость, более полно соответствующую его представлениям об оплате труда и удовлетворению, получаемому от работы.
Не говоря уже о том, что поддержка чужого кода в большинстве случаев - скука и боль. Нет, не так. БОЛЬ.
Вы же совершенно чудесно изложили несколько success stories, когда свежий взгляд на проблему привел к более эффективному ее решению. Главное, чтобы результат удовлетворял требованиям и ограничениям компании и укладывался в бюджет и сроки. Если при этом он оказывается более емким, элегантным, мощным или масштабируемым, чем предполагалось - тем лучше. Просто в том же Инвестбанке ограничения, налагаемые на решение, оказались более суровыми, чем вам встречались до того - и это тоже вполне нормальная ситуация.
Статья отличная. Резюме со стороны, если позволите:
программирование (как и любая другая деятельность) есть искусство для мастера (профессионала) с точки зрения новичка, субъективно для мастера же это ремесло, а искусство - то, к чему он стремится далее, новые вершины мастерства.
ps. И С Днем Рожденья! :)
программирование (как и любая другая деятельность) есть искусство для мастера (профессионала) с точки зрения новичка, субъективно для мастера же это ремесло, а искусство - то, к чему он стремится далее, новые вершины мастерства.
ps. И С Днем Рожденья! :)
> Мой приятель, директор крупной компании, жалуется: "Представляешь, не могу найти программиста
> поддерживать работающую систему. Приглашаю, показываю. Если переписывать с нуля - соглашаются
> за половину зарплаты. Если поддерживать - не соглашаются за две".
Что-то не ладное с зарплатами в компании твоего приятеля. Если он платит на уровне рынка, то предлагая удвоенную зарплату он без труда найдет людей, которые будут сопровожадть и дописывать его систему. А вот если он платит половину зарплаты, то удвоенная она выходит как раз на уровне рынка и при прочих равных люди выбирают для себя более интересное место работы - ничего странного, они выбирают место где можно вырости, а это проще при разработке, а не сопровождении. Это подтверждает и точ что они готовы идти за половину - это просто студенты, которым нужно где-то начинать.
> поддерживать работающую систему. Приглашаю, показываю. Если переписывать с нуля - соглашаются
> за половину зарплаты. Если поддерживать - не соглашаются за две".
Что-то не ладное с зарплатами в компании твоего приятеля. Если он платит на уровне рынка, то предлагая удвоенную зарплату он без труда найдет людей, которые будут сопровожадть и дописывать его систему. А вот если он платит половину зарплаты, то удвоенная она выходит как раз на уровне рынка и при прочих равных люди выбирают для себя более интересное место работы - ничего странного, они выбирают место где можно вырости, а это проще при разработке, а не сопровождении. Это подтверждает и точ что они готовы идти за половину - это просто студенты, которым нужно где-то начинать.
Ахахахаха. Вы хоть фильтруйте при чтении. Очередной искусный маркетинговый бред компании Битрикс. Честь и поклон этому выдающемуся писаке ( огромный респект всему отделу Маркетинга компании Битрикс ). Человек как бы говорит: "Да народ че вы велосипеды делаете, ведь есть Битрикс". Могу лишь спросить, почему большое количество заказчиков просит создавать индивидуальные решения под их задачи? почему это делают прошедшие эпоху боев CMS иностранцы? А вы посчитайте стоимость заточки Битрикса под не стандартные задачи клиента, стоимость внедрения этой системы, совокупную стоимость владения и обучения тех.же контентов. Почему Coca-Cola, IBM используют Drupal? Почему KPMG.RU использует typo3? Они глупые? Они не умеют считать деньги?
Почему вы путаете CMS API с CMF ? Почему профессионалы используют именно CMF like CakePHP, Zend и т.д. Почему аналитики предрекают усиление позиций индивидуальных решений и openSource? Нахуй надо было писать Битрикс когда уже были очень сильно развитые Typo3, тот же NetCat. Меня не устраивает Битрикс как с точки зрения стоимости внедрения, так с точки зрения «Хули там писать?” «Очень криво” «ЭЭЭ время теряю” и как заставить это быстро работать.
Я никогда не буду использовать Битрикс, потому что:
1) за красивым интерфейсов скрывается, хреновая архитектура
2) огромные затраты усилий на написание дополнений и решение задач
3) Он КОРЯВЫЙ. Как с точки зрения архитектуры, так и с точки зрения удобства использования, быстродействия и т.д.
4) меня откровенно бесят конструкции типа SELECT a.VALUE FROM b_iblock_element_property a, b_iblock_property b WHERE a.IBLOCK_ELEMENT_ID=(SELECT IBLOCK_ELEMENT_ID FROM b_iblock_element_property WHERE VALUE LIKE '127.0.0.2') AND a.IBLOCK_PROPERTY_ID=b.ID AND b.CODE='STAT_WAY';
и т.д. Будет время разверну.
Кстати почему футурико свой движок делал?
Единственное в чем прав автор. это в том что слишком ничтожен процент хороших программистов.
P.S. Прошу прощения за стилистику некогда красиво мозги срать. Как-нибудь потом статейку захуярю )
Почему вы путаете CMS API с CMF ? Почему профессионалы используют именно CMF like CakePHP, Zend и т.д. Почему аналитики предрекают усиление позиций индивидуальных решений и openSource? Нахуй надо было писать Битрикс когда уже были очень сильно развитые Typo3, тот же NetCat. Меня не устраивает Битрикс как с точки зрения стоимости внедрения, так с точки зрения «Хули там писать?” «Очень криво” «ЭЭЭ время теряю” и как заставить это быстро работать.
Я никогда не буду использовать Битрикс, потому что:
1) за красивым интерфейсов скрывается, хреновая архитектура
2) огромные затраты усилий на написание дополнений и решение задач
3) Он КОРЯВЫЙ. Как с точки зрения архитектуры, так и с точки зрения удобства использования, быстродействия и т.д.
4) меня откровенно бесят конструкции типа SELECT a.VALUE FROM b_iblock_element_property a, b_iblock_property b WHERE a.IBLOCK_ELEMENT_ID=(SELECT IBLOCK_ELEMENT_ID FROM b_iblock_element_property WHERE VALUE LIKE '127.0.0.2') AND a.IBLOCK_PROPERTY_ID=b.ID AND b.CODE='STAT_WAY';
и т.д. Будет время разверну.
Кстати почему футурико свой движок делал?
Единственное в чем прав автор. это в том что слишком ничтожен процент хороших программистов.
P.S. Прошу прощения за стилистику некогда красиво мозги срать. Как-нибудь потом статейку захуярю )
А казалось бы, только мне удалось всех зомбировать, как нашелся человек разумный. :)
Это же БИТРИКС! Помогите, спасите, не читайте, помойте руки!
Вы меня вывели на чистую воду, признаю. :))))
Это же БИТРИКС! Помогите, спасите, не читайте, помойте руки!
Вы меня вывели на чистую воду, признаю. :))))
никто не просит "красиво мозги срать". если бы было написано профессионально и аргументириванно, с вами интересно было бы поспорить, а так это просто унылое говно и брызги слюнями. а вы - скорее всего обиженный конкурент, трусливо-анонимно рефлексирующий на эту мудрую статейку. да, наверняка это пиар, но это очень ненавязчивый пиар, и пост хоть и не открывает америку, но является оригинальным контентом, в котором раскрывается определенный жизненый опыт.
Так ответьте мне аргументировано. Я задал вопросы. Ваши комментарии? И кстати успокоительное прими :-D
нет желания комментировать ваши "корявый", "хреновая архитектура" и прочее, это не аргументы, это смахивает на дешевый холивар. вот если напишете развернуто, с интересом почитаю.
а успокоительное скорее вам нужно, чтобы так не дергаться при види малейшего пиара. посмотрите на топик - люди дискутируют на тему искусства/ремесла в работе, а не о кривизне битрикса.
а успокоительное скорее вам нужно, чтобы так не дергаться при види малейшего пиара. посмотрите на топик - люди дискутируют на тему искусства/ремесла в работе, а не о кривизне битрикса.
Вывели на чисту воду и широко раскрыли всем глаза.
Ну что за унылый бред. Использую друпал, ну пусть и используют. Как и все положительные герои в кино пользуют яблочные ноуты. Вам то что?
Ну что за унылый бред. Использую друпал, ну пусть и используют. Как и все положительные герои в кино пользуют яблочные ноуты. Вам то что?
Совершенно согласен. Статья очень хитро построена - в разные моменты чтения не можешь понять чего хочет сказать автор - то ли что все банки должны десятилетиями работать на dbf и excel, то ли художники в отличие от программистов любят "перерисовывать" чужие картины, то ли студенты глупы, то ли во "взрослой" жизни нет места самообучению.
Я сейчас программирую под БУС и никого в свою веру обращать насильно не собираюсь. Поэтому и пишу, что если вас так это волнует (скрытый пиар, НЛП и гипноз страшного монстра и его главного адепта - тов. Рыжикова, то вы и волнуйтесь. Не нужно здесь холивар устраивать).
Каждый решает сам чем ему на жизнь зарабатывать, а если работаешь, то априори свой инструмен больше всего любишь.
Каждый решает сам чем ему на жизнь зарабатывать, а если работаешь, то априори свой инструмен больше всего любишь.
huiTrix (http://huitrix.habrahabr.ru/)
Зарегистрирован: 30 ноября 2007 13:55
Всего комментариев: 5
Все в этой теме.
Явный провокатор. Зарегистрировался, чтобы слить необоснованный негатив.
Зарегистрирован: 30 ноября 2007 13:55
Всего комментариев: 5
Все в этой теме.
Явный провокатор. Зарегистрировался, чтобы слить необоснованный негатив.
Люди, дайте кармы. Есть что интересного написать, но не могу.
Некоторые хабролюди не очень любят когда попрошайничают. Поэтому прося кармы вы все больше уходите в минус.
Есть следующий способ. Вы пишете что-то интересное и просите что бы кто-то с достаточной кармой разместил ваш пост с указанием автора. Если написанное будет интересно, то вам немного поднимут карму и вы сможете писать уже от нормально.
Есть следующий способ. Вы пишете что-то интересное и просите что бы кто-то с достаточной кармой разместил ваш пост с указанием автора. Если написанное будет интересно, то вам немного поднимут карму и вы сможете писать уже от нормально.
Необходимость попрошайнечества изначально заложена в принципах работы хабра. Чтобы писать что-то интересное нужно поступить либо так, как поступил я, то есть просить карму у всех, либо упрашивать кого-то одного, чтобы он разместил мою публикацию (причем я никого не знаю на хабре). Во втором случае получается, что один человек будет определять, интересно ли будет это всем. И где гарантия, что со своим субъективным взглядом он не ошибется и не отобъет у меня интерес вообще что-либо писать на хабре? Наверное мне лучше вести свои персональный блог, хотя мое стремление принести пользу людям толькает меня попрошайничать. Я удивляюсь почему некоторые хабролюди не очень любят когда попрошайничают. Но хороших людей больше чем плохих, о чем говорит плюс.
Не могу с вами согласиться, но плюс поставил.
Еще в персональные блоги можно постить с кармой не менее -5 ( Хабратопик ).
Вы уже можете и писать топики. У вас кармы достаточно, чтобы "написать интересного". Буду ждать.
У меня тоже нет знакомых на хабре, но живу же!
Будте проще.
Еще в персональные блоги можно постить с кармой не менее -5 ( Хабратопик ).
Вы уже можете и писать топики. У вас кармы достаточно, чтобы "написать интересного". Буду ждать.
У меня тоже нет знакомых на хабре, но живу же!
Будте проще.
Ой Рыжиков, сразу не посмотрел. Огромное к тебе уважение. Реально похорошему завидую. Классно всем мозши пудришь
С Днем Рождения, Сергей! Всег благ и удачи!
Абсолютно, кстати, согласен со статьей, точнее с идеей в нее заложенной.
Сам уже довольно давно в дискуссиях с программистами, да и с представителями многих других профессий, подходил к этому вопросу довольно лаконично: "Если ты получаешь деньги за свою работу - ты зовешься профессионалом, если денег никто не платит - это искусство". Доказательная база вышеозначенного утверждения окружает нас каждый Божий день: за какую сумму недавно была продана на Сотбис очередная "нетленка" Ван Гога или Кандинского или сколько готовы заплатить за твою программу заказчик? Если нет денежного эквивалента своей работе, как основы бизнеса в общем, то можно сколь угодно долго наслаждаться своим творением в одиночку или ждать какого-либо признания, что снова возвращает нас к рассуждениям о монетизации...
Очень часто встречающаяся попытка смешивать искусство и профессионализм чаще всего является попыткой явления "миру" очередного "непризнанного гения", что сразу же наводит на мысли либо о скорой кончине оного, либо же о том, что все вокруг дураки и через лет эдак пятьдесят работы эти будут оцениваться совершенно невообразимыми цифрами. Однако, сие есть тема для отдельного разговора...
Абсолютно, кстати, согласен со статьей, точнее с идеей в нее заложенной.
Сам уже довольно давно в дискуссиях с программистами, да и с представителями многих других профессий, подходил к этому вопросу довольно лаконично: "Если ты получаешь деньги за свою работу - ты зовешься профессионалом, если денег никто не платит - это искусство". Доказательная база вышеозначенного утверждения окружает нас каждый Божий день: за какую сумму недавно была продана на Сотбис очередная "нетленка" Ван Гога или Кандинского или сколько готовы заплатить за твою программу заказчик? Если нет денежного эквивалента своей работе, как основы бизнеса в общем, то можно сколь угодно долго наслаждаться своим творением в одиночку или ждать какого-либо признания, что снова возвращает нас к рассуждениям о монетизации...
Очень часто встречающаяся попытка смешивать искусство и профессионализм чаще всего является попыткой явления "миру" очередного "непризнанного гения", что сразу же наводит на мысли либо о скорой кончине оного, либо же о том, что все вокруг дураки и через лет эдак пятьдесят работы эти будут оцениваться совершенно невообразимыми цифрами. Однако, сие есть тема для отдельного разговора...
Блин, извините, бред ибо "спор о терминах".
Ремеслом называют профессиональный навык, который достаточно быстро и легко приобрести (хотя можно и отточить с годами до совершенства, не в этом дело). А искусством называют такой сложный навык, что оченннь далеко не всем вообще дано его когда-либо приобрести и если не божий дар то уж учится дофига долго.
Так вот программирование в чистом виде (и такое есть - это вакансия мечты для Настоящего Программиста))) - если понимать его как "решение сложных алгоритмических задач", поиск алгоритмов и т.д (а не применение уже изученных надежных паттернов, из которого на 90% состоит коммерческий продукт) - так вот вобщем его действительно можно назвать искусством.
И не стоит считать что какой либо вид искусства - не может быть профессией. Просто "профессионалами" там становятся единицы.
Программирование слишком обширная область знаний, чтобы быть однородной - есть уровень ремесла - его квинтэссенция - это умение работать на конвейере, применять уже изученные знания каждый день (будь-то софт, драйвер или сайт, неважно).
Но есть и другая сфера программирования, задачи, где требуется 99% созидания нового. К сожалению такие задачи или ставятся очень редко (заказчиками, это понятно) или автор ставит себе сам (велика вероятность создания чего-то ненужного)... Так что тут действительно искусство - и талант нужен и везение, вобщем гениальный художник, поэт, программист... )
Ремеслом называют профессиональный навык, который достаточно быстро и легко приобрести (хотя можно и отточить с годами до совершенства, не в этом дело). А искусством называют такой сложный навык, что оченннь далеко не всем вообще дано его когда-либо приобрести и если не божий дар то уж учится дофига долго.
Так вот программирование в чистом виде (и такое есть - это вакансия мечты для Настоящего Программиста))) - если понимать его как "решение сложных алгоритмических задач", поиск алгоритмов и т.д (а не применение уже изученных надежных паттернов, из которого на 90% состоит коммерческий продукт) - так вот вобщем его действительно можно назвать искусством.
И не стоит считать что какой либо вид искусства - не может быть профессией. Просто "профессионалами" там становятся единицы.
Программирование слишком обширная область знаний, чтобы быть однородной - есть уровень ремесла - его квинтэссенция - это умение работать на конвейере, применять уже изученные знания каждый день (будь-то софт, драйвер или сайт, неважно).
Но есть и другая сфера программирования, задачи, где требуется 99% созидания нового. К сожалению такие задачи или ставятся очень редко (заказчиками, это понятно) или автор ставит себе сам (велика вероятность создания чего-то ненужного)... Так что тут действительно искусство - и талант нужен и везение, вобщем гениальный художник, поэт, программист... )
очень верный пост.
хочу добавить, что иногда к людям не приходит понимание этого вопроса. даже совсем не иногда. он бросает работу, идёт искать воплощение своих идеальных целей в другие фирмы/проекты и там не получается. отсюда неудовлютворённость жизнью, процессом, косые взгляды на других и остальные проблемы. а необходимо просто - понять для чего тебе столько "оружия" и найти свою нишу.
да, образование у нас специфическое, широкое. не сравнимо с европейским, где специализированно и разжёвывют. но если наш человек "доходит" до той идеи, что несёт ваша статья - он действительно становится Профессионалом, потому что имеет широкий выбор навыков, технологий и с другой стороны уже видит конечную цель. это не сотрудник - мечта.
хочу добавить, что иногда к людям не приходит понимание этого вопроса. даже совсем не иногда. он бросает работу, идёт искать воплощение своих идеальных целей в другие фирмы/проекты и там не получается. отсюда неудовлютворённость жизнью, процессом, косые взгляды на других и остальные проблемы. а необходимо просто - понять для чего тебе столько "оружия" и найти свою нишу.
да, образование у нас специфическое, широкое. не сравнимо с европейским, где специализированно и разжёвывют. но если наш человек "доходит" до той идеи, что несёт ваша статья - он действительно становится Профессионалом, потому что имеет широкий выбор навыков, технологий и с другой стороны уже видит конечную цель. это не сотрудник - мечта.
незнаю про каких вы прогарммистов говорите... но лично я таким ни когда не было, есть задача, есть требование по реализации, есть ТЗ, по этому и работают. Возможно просто вы не работали сразу же в серьезных компаниях, и у вас в голове была только романтика. И то что вы делали, вы не осозновали важность и значимость ваших решений. Найти программиста, причем качественного - который будет сопровождать ПО не так сложно, может быть вы не умеете искать ? или какие-то не правильные требования при поиске задаете ? поэтому нужные люди и не идут.
Человек, который начинает с того, что есть задача, есть требования по реализации, есть ТЗ, по этому и работают - он вообще не программист ни разу, он ремесленник, в лучшем случае хороший кодер, но не программист. По большому счёту такие люди мало кому нужны, но так как ими проще управлять чем нормальными программистами, то многие компании таких нанимают пачками - потом расхлёбывают...
Заранее прошу прощения, если получится сумбурно - мне давно спать надо было идти, но тема затронута интересная, не удержался.
Факты Вы описали отлично, всё именно так и происходит. А вот выводы из этих фактов Вы сделали, на мой взгляд, некорректные. И проблема в том, что Вы смешиваете в одну кучу несколько совершенно разных понятий.
Факты Вы описали отлично, всё именно так и происходит. А вот выводы из этих фактов Вы сделали, на мой взгляд, некорректные. И проблема в том, что Вы смешиваете в одну кучу несколько совершенно разных понятий.
- Нежелание заниматься конкретной работой [за конкретные деньги] и желание заниматься исключительно искусством. У нас пока рабства (в явной форме) нет, так что если Ваш знакомый директор не может найти работника - значит он неправильно оценивает ситуацию на рынке труда, специфику работы или её реальную стоимость. Либо ищет исполнителей не в той "весовой категории". В общем, к проблеме искусства в программировании его проблема отношения не имеет вообще (хотя проще всего свои ошибки списать на то, что все программисты офигели, мнят себя творцами - вместо того, чтобы молча и недорого убирать Авгиевы конюшни).
- ...программирование, это и творчество, и ремесло, и искусство. Всё верно. Только Вы в статье упустили из виду тот факт, что, как и в любой профессии, существует разделение труда - по опыту, квалификации, таланту наконец. Ремесленник может выполнять простые, однотипные задачи, и выдавать стабильное кол-во работы на выходе. Мастер, хотя теоретически и способен делать то же самое, просто не захочет этим заниматься - он будет решать более сложные задачи, требующие творческого подхода. Но даже он никогда не сможет делать то, что делает художник - создавать произведения искусства. И художника сажать на работу ремесленника ещё более бессмысленно, чем мастера. Требовать от каждого программиста готовности заниматься ремеслом - это такой же бред, как и требовать от каждого программиста создания произведений искусства.
- ...критерием профессионализма программиста является профессиональное выполнение поставленной задачи. Ну, если заменить слово "профессиональное" на что-то типа "систематическое, эффективное и надежное" (во избежание масла маслянного и рекурсивного определения терминов :)), то Вы абсолютно правы. Ошибка же закралась между словом "поставленной" и следующей фразой "Компания ставит задачу..." - здесь подразумевается, что если ты - профессионал - значит ты должен справится с любой задачей, которую перед тобой поставят: скажут чужой код поддерживать, значит ты должен именно этим и заняться, причём "профессионально". А эта идея конфликтует и с описанной выше разницей между профессиональным ремесленником и не менее профессиональным мастером, и с идеей узкой специализации, да и вообще со здравым смыслом. Ставить задачу можно только ремесленникам, мастеру можно только предложить задачу, а художнику вообще до ваших задач дела нет в принципе.
Резюмируя. Да, у нас абсолютное большинство программистов считают себя Мастерами, а не Ремесленниками. (Что, в общем, не так и удивительно, если вспомнить о том, что ремесленников обучают обычно в ПТУ, а программисты как правило учились в университетах и институтах.) Но предлагаемое решение этой проблемы - зомбировать программистов идеей, что если он "профессионал", значит обязан профессионально делать что говорят, даже если это работа Ремесленника - мне не нравится. Есть в этом что-то очень нездоровое, и ничего нормального на этой базе получить не удастся.
Совершенно здоровый подход. И Мастера и Художники обязан справляться с обязанностями ремесленника - иначе какие они, нафиг, Мастера и Художники ? Другое дело что если Мастера посадить за чисто ремесленническую работу, то результат будет фиговый.
На практике почему-то пытаются нанять на работу одного-двух Мастеров и к ним - десятка два Ремесленников. Хотя на самом деле выгоднее для всех будет нанять пяток Мастеров и объяснить им что их работа будет состоять на 20-30% из творчества и на 70-80% - из рутины. Да, средняя зарплата в отделе IT будет выше (может именно этого боятся), но результат - будет гораздо лучше...
На практике почему-то пытаются нанять на работу одного-двух Мастеров и к ним - десятка два Ремесленников. Хотя на самом деле выгоднее для всех будет нанять пяток Мастеров и объяснить им что их работа будет состоять на 20-30% из творчества и на 70-80% - из рутины. Да, средняя зарплата в отделе IT будет выше (может именно этого боятся), но результат - будет гораздо лучше...
протестую.
В первом случае ситуация получается гораздо здоровее для программистов. Вплоть до того, что через некоторое время в фирме будет в два раза больше мастеров, чем было изначально, за счет ремесленников, которые смогут поучится, а не вариться в собственном соку.
В первом случае ситуация получается гораздо здоровее для программистов. Вплоть до того, что через некоторое время в фирме будет в два раза больше мастеров, чем было изначально, за счет ремесленников, которые смогут поучится, а не вариться в собственном соку.
Хорошее замечание.
Не будет. Ремесленник не способен перевоплотиться в мастера. Увы. Это просто разные подходы. Можно (и даже полезно) нанять людей, которые подают надежды и со временем станут мастерами - но это не то же самое, что нанять ремесленников, основное (и чуть ли не единственное) достоинство которых - экономия на зарплате.
тут можно поспорить, но я для экономии времени соглашусь и перефразирую:
нанять пару-тройку Мастеров и к ним с десяток Подмастерий. По деньгам даже не факт что Подмастерья дороже Ремесленников выйдут.
нанять пару-тройку Мастеров и к ним с десяток Подмастерий. По деньгам даже не факт что Подмастерья дороже Ремесленников выйдут.
Такая схема не работает. Чтобы из "подающего надежды" что-то выросло он должен полгода-год работать под плотным контролем Мастера. Как правило больше одного человека за раз опекать не получается. Впрочем через полгода-год плотная опека уже не так нужна и можно опробовать нанять ещё одного, но это уже риск...
Если вы наймете к двум-трём Мастерам десяток Подмастерьев, то есть риск, что большая часть из этого десятка достаточно быстро деградирует в Ремесленников (ибо им жить во многом проще хоть и получают они меньше). И шо тогда с ними делать ? Можно выгнать, конечно, но это слишком жестокий подход: такая схема сознательно калечит куче народу жизнь, потому я её не люблю (хотя многие фирмы такой подход практикуют, да)...
Если вы наймете к двум-трём Мастерам десяток Подмастерьев, то есть риск, что большая часть из этого десятка достаточно быстро деградирует в Ремесленников (ибо им жить во многом проще хоть и получают они меньше). И шо тогда с ними делать ? Можно выгнать, конечно, но это слишком жестокий подход: такая схема сознательно калечит куче народу жизнь, потому я её не люблю (хотя многие фирмы такой подход практикуют, да)...
Согласен. Хочу также заметить по поводу образования. У нас программисты часто люди с высшим образованием, которое по традиции у нас дает мало специальных навыков зато широкий кругозор. Если взять западное образование, то там большинство имеет довольно узкое специальное образование.
Именно. И потом эти "специалисты с узким специальным образованием" идут лесом. Вы думаете в запандных компаниях куча индусов, китайцев и русских (в этом порядке) потому что западное "узкое специальное образование" - суть благо ? Отнюдь. Узкое специальное образование - это высококвалифицированные ремесленники. Которые нужны где угодно, только не в программировании...
:-) Я как человек с нашим образованием, ничего против него не имею. я наоборот за. Навыки прийдут в процессе, тем более если голова есть. Насчет большого количества инастранных программистов, работающих на Западе. С образованием связь есть, но причина всеже не в ИМХО этом.
Возмите любую другую отрасль, не только IT. В Англии куча врачей индусов без гражданства, в этом году там полиции кого-то арестовывала, не помню в чем суть была. Но запомнил, что у них очень большое количество иностранных врачей, а уже мед. персонал вообще сплошь и рядом. Едем дальше. Ирландия, 1999-2001 год, спад экономики, нехватка рабочих рук (именно рабоычих, без маникюра), все ирландцы в США. Но вступает Польша в евросоюз, и как салабон превогодка должна Польша отработать. И едут поляки в Европу, а от туда в Ирландию. К слову скажу, украинцу туда почти не реально на постоянную работу попасть. И пожалуйста сейчас Ирландия на коне. Дублин не могли отремонтировать, никто не хотел идти в рабочие. Сейчас все сверкает. А Польша стартавала компанию: Дома трава зеленее, солнце ярче, вода вкуснее. А работать некому. Кстати Украину тоже ждет. Уже сейчас появилась такая же реклама по телевизору. Короче о чем я. Работоспособные люди едут на Запад и занимают ниши, которые местные не хотят занимать. Зачем работать программистом когда хочется работаь менеджером.
Возмите любую другую отрасль, не только IT. В Англии куча врачей индусов без гражданства, в этом году там полиции кого-то арестовывала, не помню в чем суть была. Но запомнил, что у них очень большое количество иностранных врачей, а уже мед. персонал вообще сплошь и рядом. Едем дальше. Ирландия, 1999-2001 год, спад экономики, нехватка рабочих рук (именно рабоычих, без маникюра), все ирландцы в США. Но вступает Польша в евросоюз, и как салабон превогодка должна Польша отработать. И едут поляки в Европу, а от туда в Ирландию. К слову скажу, украинцу туда почти не реально на постоянную работу попасть. И пожалуйста сейчас Ирландия на коне. Дублин не могли отремонтировать, никто не хотел идти в рабочие. Сейчас все сверкает. А Польша стартавала компанию: Дома трава зеленее, солнце ярче, вода вкуснее. А работать некому. Кстати Украину тоже ждет. Уже сейчас появилась такая же реклама по телевизору. Короче о чем я. Работоспособные люди едут на Запад и занимают ниши, которые местные не хотят занимать. Зачем работать программистом когда хочется работаь менеджером.
Друзья, тут чертовски много всего интересного написали! Я даже поражен составом и качеством ответов! Как-то я всегда не успевал вникнуть в суть сообщества Хабра. Но надо отдать должное идеологам, идеи очень любопытные положены в основу проекта и тут собралась крутая тусовка. :)
Но сегодня у меня ДР, да и работу не отодвинуть в сторону. Мы сегодня погудим чуток и я вернусь в строй, чтобы с клавиатурой в руках продолжить споры. :)
Но сегодня у меня ДР, да и работу не отодвинуть в сторону. Мы сегодня погудим чуток и я вернусь в строй, чтобы с клавиатурой в руках продолжить споры. :)
Мне больше приходится сталкиваться с обратной ситуацией: компания когда-то давно разработала успешный продукт, оригинальные разработчики давно ушли, для поддержки системы и обслуживания большого потока клиентов наняли новых программистов, которые боятся там что-то серьезно менять. В итоге через несколько лет система становится ужасным монстром с никому не понятной архитектурой. Если бы особенно кривые куски переписывать постоянно - все было бы нормально, хотя и более затратно. А если вместо этого в свое время решались исключительно бизнес-задачи, то через 5-10 лет архитектурные проблемы не дадут решать бизнес-задачи и может наступить крупномасштабный кризис.
Когда программист жалуется что все криво - это повод не отмахиваться от него, а подумать. Менеджер может предложить ему больше денег и дальше делать вид что "все нормально", но это работает только до какого-то момента. После этого ни лишние деньги программистам, ни повышение цен уже не позволяют решать бизнес-проблемы.
В нашей области (довольно близкая - issue tracking) есть такой популярный продукт - Atlassian JIRA. Они в течение нескольких лет усиленно забивали на архитектуру и реализовывали бизнес-требования (т.е. что пользователи попросили - то и делаем). Этой весной дело кончилось JRA-1330, ее закрыли как won't fix после 4.5 лет ожидания, обратите внимание на тональность отзывов в начале и в конце.
У них на подходе еще штук 50 высокоприоритетных запросов от пользователей с теми же причинами и перспективами решения - это тоже следствие хронического игнорирования технических проблем руководством. Я подробнее высказывался об этой ситуации в своем блоге и директор по маркетингу Atlassian в целом согласился с моими выводами.
Есть и еще одна причина, по которой менеджеры стремятся поддерживать старый код и блокируют попытки переписать, посмотрите, очень жизненно.
Когда программист жалуется что все криво - это повод не отмахиваться от него, а подумать. Менеджер может предложить ему больше денег и дальше делать вид что "все нормально", но это работает только до какого-то момента. После этого ни лишние деньги программистам, ни повышение цен уже не позволяют решать бизнес-проблемы.
В нашей области (довольно близкая - issue tracking) есть такой популярный продукт - Atlassian JIRA. Они в течение нескольких лет усиленно забивали на архитектуру и реализовывали бизнес-требования (т.е. что пользователи попросили - то и делаем). Этой весной дело кончилось JRA-1330, ее закрыли как won't fix после 4.5 лет ожидания, обратите внимание на тональность отзывов в начале и в конце.
У них на подходе еще штук 50 высокоприоритетных запросов от пользователей с теми же причинами и перспективами решения - это тоже следствие хронического игнорирования технических проблем руководством. Я подробнее высказывался об этой ситуации в своем блоге и директор по маркетингу Atlassian в целом согласился с моими выводами.
Есть и еще одна причина, по которой менеджеры стремятся поддерживать старый код и блокируют попытки переписать, посмотрите, очень жизненно.
Больше всего меня радует когда люди говорят, что это невозможно объяснить начальству. А вы пытались ? Ведь эта "супер-пупер специфическая IT-проблема" стара как мир. Если вы будете долго перестраивать дом - он в конце концов рухнет. Если вы будере переделывать яхту или автомобиль - он начнёт разваливаться. Если вы будете выращивать на поле "то, что требует рынок", не задумываясь о севообороте - у вас через лет 10-15 вообще ничего расти не будет. И так далее. Везде, во всех вещах, которые делает человек есть эта проблема. Но почему-то конструктору или архитектору верят, когда он говорит что "сюда эту хрень не всунуть - нужно перерабатывать весь проект", а программисту нет: обещают уволить и нанять кого-то, кто "сделает то что от него хотят и не будет задавать дурацких вопросов"...
Интересно - почему так ?
Интересно - почему так ?
Я сталкивался с тем, что на начальство давят клиенты - им гораздо сложнее объяснить, что "нельзя". Посмотрите, в JRA-1330 клиентам уже четко сказали "НЕТ", объяснили почему, выслушали матюги, даже кусок моего комментария на тему "почему нельзя" перевели на английский и вывесели на сайте Atlassian, а они все равно предлагаю скинуться/поднять цены - лишь бы сделали.
Что станет с продуктом после реализации field level security и как его потом поддерживать - это проблемы Atlassian. Что делать с JIRA без field level security - это проблема конкретного клиента и желание "купить" решение хорошо понятно.
Что станет с продуктом после реализации field level security и как его потом поддерживать - это проблемы Atlassian. Что делать с JIRA без field level security - это проблема конкретного клиента и желание "купить" решение хорошо понятно.
Да, интересно было почитать - вспомнил как сам испытывал новые технологии за счёт, вообщем-то, работодателя :-)
P.S. Это не самый быстрый рост кармы? Всего за один пост ;-)
P.S. Это не самый быстрый рост кармы? Всего за один пост ;-)
Нет. Рекорд поставил Pchel со своими экспериментами, которые и сейчас занимают первое место по популярности...
слишком много букв. Но с выводами согласен.
Думаю типичный взгляд хорошего менеджера. Вы управляете людьми, они для вас ресурс. Что бы не говорили про индивидуальный подход и пр, все равно ресурс, в этом специфика работы менеджера, и в принципе это правильно. Да фабрика эффективнее и выгоднее чем ручной труд, вот только самые хорошие и дорогие вещи до сих пор ручной сборки. И делают их мастера или художники а не ремесленники. Ремесленники в китае собирают, быстро, удобно, выгодно.
Теперь по теме: профессия программиста творческая по определению, надеюсь с этим никто не спорит. Есть конечно исключения которые превращают программирование в кодинг и так и зависают в этом состоянии навечно, но я не отношу их к программистам. А творчество от слова творить, создавать, созидать НОВОЕ. Чтобы творить нужно уметь использовать опыт предыдущих творцов иначе это застой, повторение, а оно несовместимо с творчеством. Поэтому программирование в наше время прибежище(не единсвенное) людей стремящихся к знаниям, новой информации, если они ее используют то для развития умения, знания. Все остальное применение их умений будет гораздо ниже их уровня. Это правильно, они по другому не умеют. Для вас важен результат, для программистов процесс, поэтому никогда наши представление о профессионализме не совпадут. Пытаясь сделать из программистов "Профессионалов" в вашем понимании, вы убиваете в них программистов, да они станут эффективными и хорошими работниками, но произведения исскуства пишут художники, а не маляры, Двигают науку преимущественно ученые, хотя от инженеров толку на производстве больше.
Просто программирование сейчас на той стадии когда только происходит расслоение на ученых и инженеров, и лучшие относят себя к ученым а работодателю чаще нужны инженеры.
Все это конечно аналогии.
Художник который пишет картину на заказ сделает ее так как он хочет и лишь тему даст заказчик, иначе быть не может. Ведь художник это не просто умение рисовать. А вот маляр покрасит стену так как вы ему скажете. Вы хотите чтобы вашу картину "рисовал" маляр?
Теперь по теме: профессия программиста творческая по определению, надеюсь с этим никто не спорит. Есть конечно исключения которые превращают программирование в кодинг и так и зависают в этом состоянии навечно, но я не отношу их к программистам. А творчество от слова творить, создавать, созидать НОВОЕ. Чтобы творить нужно уметь использовать опыт предыдущих творцов иначе это застой, повторение, а оно несовместимо с творчеством. Поэтому программирование в наше время прибежище(не единсвенное) людей стремящихся к знаниям, новой информации, если они ее используют то для развития умения, знания. Все остальное применение их умений будет гораздо ниже их уровня. Это правильно, они по другому не умеют. Для вас важен результат, для программистов процесс, поэтому никогда наши представление о профессионализме не совпадут. Пытаясь сделать из программистов "Профессионалов" в вашем понимании, вы убиваете в них программистов, да они станут эффективными и хорошими работниками, но произведения исскуства пишут художники, а не маляры, Двигают науку преимущественно ученые, хотя от инженеров толку на производстве больше.
Просто программирование сейчас на той стадии когда только происходит расслоение на ученых и инженеров, и лучшие относят себя к ученым а работодателю чаще нужны инженеры.
Все это конечно аналогии.
Художник который пишет картину на заказ сделает ее так как он хочет и лишь тему даст заказчик, иначе быть не может. Ведь художник это не просто умение рисовать. А вот маляр покрасит стену так как вы ему скажете. Вы хотите чтобы вашу картину "рисовал" маляр?
Написано хорошо это безусловно. Вчитываться в комментарии и начинать дискуссии мне совершенно не хочется. Потому как я пишу код.) Выделю всего лишь пару моментов. Даже один.
Практически незамеченным остался тезис ввёрнутый вами в повествование о "обучении на работе". Вы считаете это не нормальным и чуть ли не аморальным.. Когда программист(тем более без опыта и тем более после университета) приходит в новую фирму и начинает учится за счёт компании, за счёт своего рабочего времени. Это плохо? Никогда. Вся статья по сути построена на этом тезисе. На тезисе о том что программист должен быть обучен "выполнять задачки которые ставит перед ним компания а не заниматься всякой ерундой типа саморазвития". Сейчас получите мои аргументы против.)
Первое и самое важное. Как не меняйте систему образования как ни насилуйте рынок труда.. Все равно программист без опыта будет учиться на своей первой работе. Причём не просто учиться а выбирать продавливая те решения которые считает эффективными. Это нормально. Со временем он либо найдёт решения и будет их поддерживать либо перейдёт в другую компанию имея опыт выбора решений. Что собственно с вами насколько я понял и произошло.) Это нормальный путь развития программиста. И дело не в ремесленничестве, а в получении опыта работы. Я тоже до недавнего времени писал разномастные технологии в резюме. Сейчас там уже конкретные ссылки и конкретные CMF, CMS и проекты.)
Второе. Я открою вам глаза на наш рынок труда... Карьерный рост для программистов возможен либо в составе корпораций, с возможностью получения навыков в данной конкретной технологии, либо путём саморазвития и обучения. то есть В наше время программисты работают не только за бабло но и вынуждены повышать свою стоимость на рынке! Что если говорить о других отраслях далеко не всегда так. Почему? Потому что инструментов и решений меньше раз, потому что отрасли более устоявшиеся два, и что самое важное потому что в других отраслях куда чаще и куда больше вкладываются деньги в развитие навыков сотрудников. И даже не навыков.. Общей квалификации.
Вывод.. Для того что бы ситуация не была такой какой вы её описали как минимум работодателю вкладывать больше в сотрудников.)
Практически незамеченным остался тезис ввёрнутый вами в повествование о "обучении на работе". Вы считаете это не нормальным и чуть ли не аморальным.. Когда программист(тем более без опыта и тем более после университета) приходит в новую фирму и начинает учится за счёт компании, за счёт своего рабочего времени. Это плохо? Никогда. Вся статья по сути построена на этом тезисе. На тезисе о том что программист должен быть обучен "выполнять задачки которые ставит перед ним компания а не заниматься всякой ерундой типа саморазвития". Сейчас получите мои аргументы против.)
Первое и самое важное. Как не меняйте систему образования как ни насилуйте рынок труда.. Все равно программист без опыта будет учиться на своей первой работе. Причём не просто учиться а выбирать продавливая те решения которые считает эффективными. Это нормально. Со временем он либо найдёт решения и будет их поддерживать либо перейдёт в другую компанию имея опыт выбора решений. Что собственно с вами насколько я понял и произошло.) Это нормальный путь развития программиста. И дело не в ремесленничестве, а в получении опыта работы. Я тоже до недавнего времени писал разномастные технологии в резюме. Сейчас там уже конкретные ссылки и конкретные CMF, CMS и проекты.)
Второе. Я открою вам глаза на наш рынок труда... Карьерный рост для программистов возможен либо в составе корпораций, с возможностью получения навыков в данной конкретной технологии, либо путём саморазвития и обучения. то есть В наше время программисты работают не только за бабло но и вынуждены повышать свою стоимость на рынке! Что если говорить о других отраслях далеко не всегда так. Почему? Потому что инструментов и решений меньше раз, потому что отрасли более устоявшиеся два, и что самое важное потому что в других отраслях куда чаще и куда больше вкладываются деньги в развитие навыков сотрудников. И даже не навыков.. Общей квалификации.
Вывод.. Для того что бы ситуация не была такой какой вы её описали как минимум работодателю вкладывать больше в сотрудников.)
Профессионализм выражается в способности найти баланс между ремеслом и искусством - так достигается новый уровень эффективности. :)
Не переживайте так, это временная ситуация. Это сейчас только программисты да дизайнеры считают свою работу искусством. С каждым годом таких профессий будет становится все больше. И постепенно все люди поймут, что делать неинтересную работу нет смысла, ни за какие деньги. Потому что время не купишь ни за какие деньги, и жизнь только одна. И большим корпорациям придётся с этим смирится, потому что никто не даст им другого народа.
Уже сейчас есть корпорации которые это понимают, и которые, по странному совпадению, являются самыми успешными на рынке (Google, Apple)
А самые талантливые программисты создают стартапы, чтобы можно было самим себе ставить задачи и заниматься искусством с утра до вечера.
Уже сейчас есть корпорации которые это понимают, и которые, по странному совпадению, являются самыми успешными на рынке (Google, Apple)
А самые талантливые программисты создают стартапы, чтобы можно было самим себе ставить задачи и заниматься искусством с утра до вечера.
Кстати, отлично подмечено. Полностью соласен. :) Но базовые "ремесленные" навыки никуда не денутся. Просто этот баланс будет постепенно смещаться - это тренд. Впрочем, и сейчас то, сколько зарабатывает человек, во многом зависит от того, как он сам себя позиционирует и на какую работу соглашается, иными словами, от того, какой баланс между ремеслом и искусством он выбрал сам.
>А самые талантливые программисты создают стартапы, чтобы можно было самим себе ставить задачи и
>заниматься искусством с утра до вечера.
Очень идеализированный взгляд. Потому что прежде чем появится возможность "заниматься искусством с утра до вечера" придется пройти семь кругов рутины. И далеко не каждый их осилит. Хотя в целом с мыслью согласен.
>заниматься искусством с утра до вечера.
Очень идеализированный взгляд. Потому что прежде чем появится возможность "заниматься искусством с утра до вечера" придется пройти семь кругов рутины. И далеко не каждый их осилит. Хотя в целом с мыслью согласен.
По-моему как-то слабо применимо для компаний с четкой организацией тех. процессов.
Как говорится, со своим уставом в чужой монастырь.
Если в компании основная программная база построена, скажем, на питоне, и приходит кодер, который настаивает, чтобы переписать все на руби, думается мне, гнать этого кодера будут в шею...
В компаниях, где все правильно организовано, руководитель ставит задачу, исполнитель эту задачу решает, руководитель оценивает решение этой задачи. Вот как раз решение задачи исполнителем и является неким видом искусства. Главное, чтобы программист правильно понимал "красоту кода" — термин, означающий отнюдь не привлекательное форматирование, скажем, отступов. Если программист пишет действительно "красивый": расширяемый, понятный, оптимизированный и т.д. — код, то для него, безусловно это и является искусством. И это отлично!
Но, действительно, встречались мне программисты, которые постоянно хотели что-то дописать на, скажем, C# для системы с web-интерфейсом, написанной на PHP.
Частично, это ошибки руководства, которое не может грамотно обрисовать рамки, внутри которых нужно держать проект. Грамотный кодер знает, что увеличение сущностей — всегда плохо. Переход на новые технологии с попыткой сохранения части функционала на старых технологиях — это смерти подобное, бесполезное увеличение сущностей. Если руководство считает, что может позволить себе полное переписывание проекта, то флаг в руки, никто от этого не пострадает. А в остальных случаях руководство должно донести до исполнителей, что нужно оставаться в определенных рамках.
Как говорится, со своим уставом в чужой монастырь.
Если в компании основная программная база построена, скажем, на питоне, и приходит кодер, который настаивает, чтобы переписать все на руби, думается мне, гнать этого кодера будут в шею...
В компаниях, где все правильно организовано, руководитель ставит задачу, исполнитель эту задачу решает, руководитель оценивает решение этой задачи. Вот как раз решение задачи исполнителем и является неким видом искусства. Главное, чтобы программист правильно понимал "красоту кода" — термин, означающий отнюдь не привлекательное форматирование, скажем, отступов. Если программист пишет действительно "красивый": расширяемый, понятный, оптимизированный и т.д. — код, то для него, безусловно это и является искусством. И это отлично!
Но, действительно, встречались мне программисты, которые постоянно хотели что-то дописать на, скажем, C# для системы с web-интерфейсом, написанной на PHP.
Частично, это ошибки руководства, которое не может грамотно обрисовать рамки, внутри которых нужно держать проект. Грамотный кодер знает, что увеличение сущностей — всегда плохо. Переход на новые технологии с попыткой сохранения части функционала на старых технологиях — это смерти подобное, бесполезное увеличение сущностей. Если руководство считает, что может позволить себе полное переписывание проекта, то флаг в руки, никто от этого не пострадает. А в остальных случаях руководство должно донести до исполнителей, что нужно оставаться в определенных рамках.
Не сказал бы, что в компаниях, в которых задачи ставятся по принципу "руководитель ставит задачу, исполнитель эту задачу решает", процесс построен правильно. Точнее, может это и правильно с точки зрения стандартов и "умных" книжек, но в таких компаниях программистами работают "андроиды" - ведь там даже думать уметь не надо. Нормальный человек хотя бы с минимальными творческими наклонностями там долго не выдержит, и создавать революционные продукты подобные комании не способны в принципе.
В том числе поэтому обычно разделяю на кодеров и программистов тех, кто приходит на собеседование. Человек может не знать нужного языка программирования, но если он умеет думать, то у него больше шансов быть принятым на работу, чем у кандидата, который знает в совершенстве синтаксис языка программирования, но не способен написать хотя бы простую рекурсивную функцию.
В том числе поэтому обычно разделяю на кодеров и программистов тех, кто приходит на собеседование. Человек может не знать нужного языка программирования, но если он умеет думать, то у него больше шансов быть принятым на работу, чем у кандидата, который знает в совершенстве синтаксис языка программирования, но не способен написать хотя бы простую рекурсивную функцию.
Отнюдь. Руководитель говорит, что нужно сделать, а исполнитель решает, как это сделать. Это сохраняет интересы обоих сторон. Руководство идет по своему плану развития, а у исполнителя остается холст для искусства.
Мое личное мнение, что человек очень редко может одновременно придумывать и программировать "революционные продукты". Идеальным сочетанием является тандем, когда руководитель придумывает и продумывает хороший продукт, а исполнитель разделяет взгляды руководства, как это должно работать и получает удовольствие от того, что реализует функционал.
Самая страшная ситуация — это когда программист начинает рисовать иконки, проектировать интерфейсы и т.д. И, если это является проявлением творческих наклонностей, надо такие действия пресекать на корню, потому что ведут они либо к уменьшению качества продукта, либо к увеличению сроков разработки, затраченных на переделки.
То же разделение на "кодеров" и "программеров", о котором вы говорите, является уже практически каноническим. И давно уже все гноят индусов, относя их именно к кодерам, хотя часто не подозревают, что проблема не в их ограниченности полетов мыслей, а в неправильной постановке задачи, и тогда минимальный полет мысли приводит к тому, в чем потом обычно обвиняют Билла Гейтса.
Я полностью согласен, что в неогромных компаниях не должно быть кодеров, а все должны быть программистами, при том, получается, что ведущие программисты часто "скидывают" на подчиненных менее интересные задачи, от чего подчиненные возмущаются, что их считают за кодеров. При том, ни один грамотный ведущий специалист не станет принуждать своих подчиненных писать в определенном стиле, или использовать какие-то полюбившиеся ему библиотеки, оставляя тем самым им место для творчества. Но подчиненные редко понимают и ощущают наличие этой свободы. Им все кажется, что если бы им не "обрезали крылья", то они бы сделали "ух!", и "ах!", и "абалдеть", но на проверку это не совсем так. Если бы оно было так, эти самые подчиненные открывали бы свои фирмы и зарабатывали бы деньги вагонами...
Лично мне кажется, что те рамки, о которых я говорил выше, просто обязаны существовать, иначе будет полный бардак.
Мое личное мнение, что человек очень редко может одновременно придумывать и программировать "революционные продукты". Идеальным сочетанием является тандем, когда руководитель придумывает и продумывает хороший продукт, а исполнитель разделяет взгляды руководства, как это должно работать и получает удовольствие от того, что реализует функционал.
Самая страшная ситуация — это когда программист начинает рисовать иконки, проектировать интерфейсы и т.д. И, если это является проявлением творческих наклонностей, надо такие действия пресекать на корню, потому что ведут они либо к уменьшению качества продукта, либо к увеличению сроков разработки, затраченных на переделки.
То же разделение на "кодеров" и "программеров", о котором вы говорите, является уже практически каноническим. И давно уже все гноят индусов, относя их именно к кодерам, хотя часто не подозревают, что проблема не в их ограниченности полетов мыслей, а в неправильной постановке задачи, и тогда минимальный полет мысли приводит к тому, в чем потом обычно обвиняют Билла Гейтса.
Я полностью согласен, что в неогромных компаниях не должно быть кодеров, а все должны быть программистами, при том, получается, что ведущие программисты часто "скидывают" на подчиненных менее интересные задачи, от чего подчиненные возмущаются, что их считают за кодеров. При том, ни один грамотный ведущий специалист не станет принуждать своих подчиненных писать в определенном стиле, или использовать какие-то полюбившиеся ему библиотеки, оставляя тем самым им место для творчества. Но подчиненные редко понимают и ощущают наличие этой свободы. Им все кажется, что если бы им не "обрезали крылья", то они бы сделали "ух!", и "ах!", и "абалдеть", но на проверку это не совсем так. Если бы оно было так, эти самые подчиненные открывали бы свои фирмы и зарабатывали бы деньги вагонами...
Лично мне кажется, что те рамки, о которых я говорил выше, просто обязаны существовать, иначе будет полный бардак.
Не могу ничего возразить, потому полностью согласен. Я просто для себя решил, что работать на галере программистов, размахивая плеткой над их головами не хочу. Так что я высказал просто свое отношение. Но в сути вопроса у нас расхождений нет - мы друг друга поняли. :)
Для рисования иконок и их расположения на экране нужно художественное чутью, которым программисты редко обладают. Вернее оно у них не такое, как у всех остальных людей. Потому услуги дизайнера обычно являются нелишними. Однако если спроектировать задачу без участия программистов, то, как правило, получается маложизнеспособный уродец.
Как раз проблема с индусами в том, что они используют программу как "холст для исскуства" вместо того чтобы понять что творческая задача, где есть где развернуться программисту - это как раз дизайн системы. А в коде всё должно быть просто, понятно, и, по возможности, без излишних полётов мысли (если написать простой понятный код не получается возможным - нужно вернуться к дизайну).
Интересно - с какого момента компании таки нужны кодеры. И для чего. Google имеет больше 10'000 человек персоналу и вроде пока кодеров на работу по прежнему не набирает (ну или старается не набирать)...
Если ведущий специалист именно "скидывает" задачу на подчинённых - то он стремится превратить их в ремесленников и с этим нужно бороться (или, при невозможности, искать другое место работы). Задача в любом случае должна обговариваться с теми людьми, которые будут потом решённую подчинённым задачу решать - иначе возникнут проблемы "на стыке".
Рамки, разумеется, обязаны существовать, но их выявление - не задача какого-то суперпуперумного архитектора. Человек должен понимать почему эти рамки именно таковы и чего будет стоит их изменение... Человек должен иметь представление о том что он делает и зачем... Если исполнитель этого не понимает - система будет всё время пробуксовывать... Отличный пример есть тут...
Как раз проблема с индусами в том, что они используют программу как "холст для исскуства" вместо того чтобы понять что творческая задача, где есть где развернуться программисту - это как раз дизайн системы. А в коде всё должно быть просто, понятно, и, по возможности, без излишних полётов мысли (если написать простой понятный код не получается возможным - нужно вернуться к дизайну).
Интересно - с какого момента компании таки нужны кодеры. И для чего. Google имеет больше 10'000 человек персоналу и вроде пока кодеров на работу по прежнему не набирает (ну или старается не набирать)...
Если ведущий специалист именно "скидывает" задачу на подчинённых - то он стремится превратить их в ремесленников и с этим нужно бороться (или, при невозможности, искать другое место работы). Задача в любом случае должна обговариваться с теми людьми, которые будут потом решённую подчинённым задачу решать - иначе возникнут проблемы "на стыке".
Рамки, разумеется, обязаны существовать, но их выявление - не задача какого-то суперпуперумного архитектора. Человек должен понимать почему эти рамки именно таковы и чего будет стоит их изменение... Человек должен иметь представление о том что он делает и зачем... Если исполнитель этого не понимает - система будет всё время пробуксовывать... Отличный пример есть тут...
Зато подобные компании могут успешно копировать чужие идеи и за счёт экономии на R&D (не нужно изобретать велосипеж) обходить тех, кто эти идеи впервые выдвинул в конкурентной борьбе. Пример - Microsoft (не путать с Microsoft Research, который является на 100% творческим и выполняет, по сути, одну-единственную задачу: удерживает мозги чтобы они конкурентам не достались).
Человек не способный написать и понять простую рекурсивную функцию - вообще не программист. Скажем можно ли назвать человека программистом если человек не может сказать - больше суток или меньше будет работать простенькая программа в две строки:
long long fib(long long i) { if (i<=0) return 1; return fib(i-1)+fib(i-2); }
main() { printf("%lld\n",fib(80)); }
Человек не способный написать и понять простую рекурсивную функцию - вообще не программист. Скажем можно ли назвать человека программистом если человек не может сказать - больше суток или меньше будет работать простенькая программа в две строки:
long long fib(long long i) { if (i<=0) return 1; return fib(i-1)+fib(i-2); }
main() { printf("%lld\n",fib(80)); }
странно, что никто не вспомнил про процесс РЕФАКТОРИНГА -
это и есть золотая середина - между наивным "Надо все переписать" и бюрократическим "Что работает - не трогать"
маленькими шажками можно уверенно и быстро идти вперед и улучшать продукт
без риска уничтожения целостности системы , давая программистам-архитекторам возможность реализовывать
их творческий потенциал - хоть и не большими частями.
естественно, под термином "маленькие шажки" в рефакторинге я понимаю не только элементарные операции
в программировании (такие как выделение метода, переименование переменной ..)
но и крупные - скажем удаление/добавление целого модудля в проекте,
переход на новую БД, переход на новый движок интерфейса или вообще на другую платформу/другой язык
суть в небольших обдуманных шагах - после каждого из которых система улучшается, но
остается полностью работоспособной и не несет в себе шокирующих изменений для пользователя
Человек так устроен - ему трудно охватить сложную систему целиком. Но маленькими операциями даже очень сложную, безнадежно сложную и запутанную систему можно упростить и распутать.
это и есть золотая середина - между наивным "Надо все переписать" и бюрократическим "Что работает - не трогать"
маленькими шажками можно уверенно и быстро идти вперед и улучшать продукт
без риска уничтожения целостности системы , давая программистам-архитекторам возможность реализовывать
их творческий потенциал - хоть и не большими частями.
естественно, под термином "маленькие шажки" в рефакторинге я понимаю не только элементарные операции
в программировании (такие как выделение метода, переименование переменной ..)
но и крупные - скажем удаление/добавление целого модудля в проекте,
переход на новую БД, переход на новый движок интерфейса или вообще на другую платформу/другой язык
суть в небольших обдуманных шагах - после каждого из которых система улучшается, но
остается полностью работоспособной и не несет в себе шокирующих изменений для пользователя
Человек так устроен - ему трудно охватить сложную систему целиком. Но маленькими операциями даже очень сложную, безнадежно сложную и запутанную систему можно упростить и распутать.
Программирование - искусство!
Автор почему-то прировнял постоянное желание учиться новым технологиям и языкам программирования к искусству. Но ведь это не одно и тоже!
По моему мнению, искусство программирования заключается в создании такого приложения/программы/скрипта, кодом/архитектурой которого можно любоваться, восхищаться и пользоваться бесконечно долго.
Они просты, удобны, понятны и логичны. И от работы с ними пользователи/программисты получают только положительные эмоции. Такие программы всегда надежны, потому что продуманы.
С этим тезисом тоже не согласен! Программист, для которого программирование есть искусство, для него главное конечный результат, конечный пользователь, а не собственное Я (я крут, потому что сделал-таки этот интерфейс на модной технологии AJAX).
Автор почему-то прировнял постоянное желание учиться новым технологиям и языкам программирования к искусству. Но ведь это не одно и тоже!
По моему мнению, искусство программирования заключается в создании такого приложения/программы/скрипта, кодом/архитектурой которого можно любоваться, восхищаться и пользоваться бесконечно долго.
Они просты, удобны, понятны и логичны. И от работы с ними пользователи/программисты получают только положительные эмоции. Такие программы всегда надежны, потому что продуманы.
Результат - это просто как случайный подарок - может случиться, а может и не случиться (вероятность 1/2 :) )
С этим тезисом тоже не согласен! Программист, для которого программирование есть искусство, для него главное конечный результат, конечный пользователь, а не собственное Я (я крут, потому что сделал-таки этот интерфейс на модной технологии AJAX).
По последнему тезису - не согласен. Если главное - конечный пользователь, то это означает переделывание приложения под нужны пользователя, даже если архитектуре станет совсем плохо.
Представь, приносит клиенту картину художник, а тот говорит - не, тут нужно справа еще сантиметров 10 дорисовать, а снизу 5 - обрезать, иначе придется звать кого-нибудь чтоб шкаф подвинули. Ну и что останется от произведения искусства после 10 таких просьб ? :-)
Представь, приносит клиенту картину художник, а тот говорит - не, тут нужно справа еще сантиметров 10 дорисовать, а снизу 5 - обрезать, иначе придется звать кого-нибудь чтоб шкаф подвинули. Ну и что останется от произведения искусства после 10 таких просьб ? :-)
Если главное - конечный пользователь, то это означает переделывание приложения под нужны пользователя, даже если архитектуре станет совсем плохо.
я подразумевал разработку софта, программных продуктов, например, такого как битрикс, скайп.
Представь, приносит клиенту картину художник, а тот говорит - не, тут нужно справа еще сантиметров 10 дорисовать, а снизу 5 - обрезать, иначе придется звать кого-нибудь чтоб шкаф подвинули. Ну и что останется от произведения искусства после 10 таких просьб ? :-)
в случае же с заказным софтом, то "дорисовать или обрезать 5 см" в хорошо спроектированной программе можно легко :)
вот вставить в центр вместо квадрата кружочек уже сложнее, но это уже другой вопрос, несвязанный с программированием :)
может просто учиться - это интереснее, чем "тупо" делать то, что ты умеешь?
друго дело, что нас и вправду учат "учиться", но в итоге не учат тому, что нужно просто взять да и применить то, что ты уже знаешь, в интересах зказчика. в ВУЗах мы всё время учимся в своих интересах, а работать в чужих приходится уже после :)
друго дело, что нас и вправду учат "учиться", но в итоге не учат тому, что нужно просто взять да и применить то, что ты уже знаешь, в интересах зказчика. в ВУЗах мы всё время учимся в своих интересах, а работать в чужих приходится уже после :)
Есть конечно и спорные моменты, но в целом очень точно!
Узнал себя, сижу в думке...
Узнал себя, сижу в думке...
"вечный студент" :)
Скажу один вещь - но пост далеко не откровение :) и в кое-чем даже противоречит себе.
Программист постоянно хочет учится - зачем выдавать это за недостаток? Это как раз то, что отделяет хорошего программиста от плохого, я лучше найму человека с искрой в глазах, чем мутного, но с большим количеством проектов.
Или все мы сразу после окончания университетов, знали про рефакторинг, про связанность и связность кода, про принципы и паттерны применяемых в корпоративных приложениях, про вред преждевременной оптимизации и еще больший вред преждевременной пессимизации, про принципы подстановки Лискоу или SRP и т.д. и т.п.
Обладали ли мы исскуством определить, что дешевле для бизнеса: переписать ее с нуля или попытаться выпрямить и отрефакторить? Можно написать еще про многое другое, но смысла нет, и в этом нет уникальности профессии программиста, хорошие доктора, юристы, экономисты и прочие, также постоянно лопатят горы литературы и внимательно следят за тенденциями в профессиональной сфере.
Ну а то что выгодно работодателю и так понятно, пусть этот чувак сидит на этом фоксе поддерживаю эту угребищную программу еще 10 лет ничему не учась, и хрен он потом куда свалит, так как никому не будет нужен.
И, сорри, если я не прав, но автор оригинального поста, по поведению напоминает новоиспеченного менеджера из программистов. На эту тему тоже много чего написать, но это большая тема для отдельного поста.
И на последок программист должен учится, для того, чтобы не остаться просто быдлокодером на всю жизнь. Выбор есть, читаем Ларри Константайна, Брукса, Макконелла и прочих известных если хотим расти вертикально и Фаулера, Роберта Мартина и многих многих других если хотим рости горизонтально.
Спасибо за внимание :)
Программист постоянно хочет учится - зачем выдавать это за недостаток? Это как раз то, что отделяет хорошего программиста от плохого, я лучше найму человека с искрой в глазах, чем мутного, но с большим количеством проектов.
Или все мы сразу после окончания университетов, знали про рефакторинг, про связанность и связность кода, про принципы и паттерны применяемых в корпоративных приложениях, про вред преждевременной оптимизации и еще больший вред преждевременной пессимизации, про принципы подстановки Лискоу или SRP и т.д. и т.п.
Обладали ли мы исскуством определить, что дешевле для бизнеса: переписать ее с нуля или попытаться выпрямить и отрефакторить? Можно написать еще про многое другое, но смысла нет, и в этом нет уникальности профессии программиста, хорошие доктора, юристы, экономисты и прочие, также постоянно лопатят горы литературы и внимательно следят за тенденциями в профессиональной сфере.
Ну а то что выгодно работодателю и так понятно, пусть этот чувак сидит на этом фоксе поддерживаю эту угребищную программу еще 10 лет ничему не учась, и хрен он потом куда свалит, так как никому не будет нужен.
И, сорри, если я не прав, но автор оригинального поста, по поведению напоминает новоиспеченного менеджера из программистов. На эту тему тоже много чего написать, но это большая тема для отдельного поста.
И на последок программист должен учится, для того, чтобы не остаться просто быдлокодером на всю жизнь. Выбор есть, читаем Ларри Константайна, Брукса, Макконелла и прочих известных если хотим расти вертикально и Фаулера, Роберта Мартина и многих многих других если хотим рости горизонтально.
Спасибо за внимание :)
автора с днём рождения и спасибо за поднятую проблему. сегодня опять будут снится кошмары :-(
кто-то ещё с самого начала и до конца «дожил»?
кто-то ещё с самого начала и до конца «дожил»?
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, есть у нас специфика — мы не являемся центром IT-цивилизации. Крупных именно софтверных контор у нас немного. Да и мелких немного.
Большинство программистов работают там, где написание программ — не профильный бизнес.
Поэтому и распространена у нас форма работы, которую я называю — придворный программист.
Лично мне удалось поработать в истинно софтверной фирме, только когда я перебрался в Москву. Там не было никаких "переписал с нуля".
Большинство программистов работают там, где написание программ — не профильный бизнес.
Поэтому и распространена у нас форма работы, которую я называю — придворный программист.
Лично мне удалось поработать в истинно софтверной фирме, только когда я перебрался в Москву. Там не было никаких "переписал с нуля".
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, очень интересно!
Спасибо автору за интересную статью, а так же комментаторам за множество полезных и интересных ссылок!
Я считаю нужно выбирать золотую середину между самосовершенствованием (творчеством) и решением бизнес задач. Выбирать так, чтобы радовать себя и заказчика результатом выполненной работы, и так, чтобы самому не стоять на месте и развиваться. Так будет "и вашим и нашим" и все будут довольны :)
Я считаю нужно выбирать золотую середину между самосовершенствованием (творчеством) и решением бизнес задач. Выбирать так, чтобы радовать себя и заказчика результатом выполненной работы, и так, чтобы самому не стоять на месте и развиваться. Так будет "и вашим и нашим" и все будут довольны :)
Статья правильная. Но вылью ложку желчи на общую эйфорию, дабы не считали эти мысли откровением ;)
В свое время Игорь Ашманов заслужил много респектов написав свои "Правила Ашманова" (http://www.ashmanov.com/pap/ashrul.phtml и http://www.ashmanov.com/pap/ashrul2/), где лаконично и емко описал и творческую природу мотивации программистов и частый ее конфликт с интересами компании и проектов. Кроме этой мысли, Ашманов еще много других умных мыслей и выводов сделал в своих текстах. Да и сам Ашманов тоже не первый автор на данную тему - есть несколько прекрасных американских книг про "дрессировку котов", т.е. работу с программистами и отраслевую специфику.
Вообще же, отдельную поучительную статью можно расписать из каждого абзаца правил Ашманова или статей Джоэля Спольски, например. В данном случае Сергей идет не столько путем Ашманова, сколько по его следам - подбирает его общеизвестные тезисы и дает им примеры из своей жизни. А так хочется откровения получить от личного опыта Рыжикова, а не старые макароны под новым соусом! ;)
И вообще освещение мифов, проблем и догм о работе программистов гарантированно приносит успех авторам, даже, если выводы этих статей известны и очевидны. ;)
В свое время Игорь Ашманов заслужил много респектов написав свои "Правила Ашманова" (http://www.ashmanov.com/pap/ashrul.phtml и http://www.ashmanov.com/pap/ashrul2/), где лаконично и емко описал и творческую природу мотивации программистов и частый ее конфликт с интересами компании и проектов. Кроме этой мысли, Ашманов еще много других умных мыслей и выводов сделал в своих текстах. Да и сам Ашманов тоже не первый автор на данную тему - есть несколько прекрасных американских книг про "дрессировку котов", т.е. работу с программистами и отраслевую специфику.
Вообще же, отдельную поучительную статью можно расписать из каждого абзаца правил Ашманова или статей Джоэля Спольски, например. В данном случае Сергей идет не столько путем Ашманова, сколько по его следам - подбирает его общеизвестные тезисы и дает им примеры из своей жизни. А так хочется откровения получить от личного опыта Рыжикова, а не старые макароны под новым соусом! ;)
И вообще освещение мифов, проблем и догм о работе программистов гарантированно приносит успех авторам, даже, если выводы этих статей известны и очевидны. ;)
статья отличная! спасибо.
может пишу не туда и не в тему,
но все же хотел обратить внимание на один продукт, а точнее битрикс.
я работал с ним примерно 1-2 года, и понял что в него много вложено очень много труда,
много что реализовано, но как для программиста он имеет недочёты, поэтому хотел бы посоветовать взглянуть на паттерн программирования MVC (model-view-controll). Для примеров это RoR (rubyonrails)
и/или CakePHP. Было бы не плохо его организовать в это ключе, думаю стало бы удобнее и для программеров))
может пишу не туда и не в тему,
но все же хотел обратить внимание на один продукт, а точнее битрикс.
я работал с ним примерно 1-2 года, и понял что в него много вложено очень много труда,
много что реализовано, но как для программиста он имеет недочёты, поэтому хотел бы посоветовать взглянуть на паттерн программирования MVC (model-view-controll). Для примеров это RoR (rubyonrails)
и/или CakePHP. Было бы не плохо его организовать в это ключе, думаю стало бы удобнее и для программеров))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программирование как искусство