Комментарии 113
Даже не поспоришь…
>>Настоящие рок-звёзды сдают проекты до намеченного срока и дешевле отведённого бюджета, и это именно то, в чём нуждается бизнес
Пошел ставить новую фразу на screensaver :) просто и очень сильно сказано
Пошел ставить новую фразу на screensaver :) просто и очень сильно сказано
никогда не получалось сдать раньше сроков :(
соответственно, второй пункт вступал в силу автоматически
соответственно, второй пункт вступал в силу автоматически
… И если нашему работодателю требуется софт для управления платёжными ваучерами, то он должен получить именно его, а не «систему, основанную на плагинах с масштабируемыми и распознаваемыми в реал-тайме шаблонами UI» или в необходимости чего там ещё мы сами себя убедим.
Чуть не расплакался. Помниццо принимал участие в проекте одном, который в итоге держа нагрузку в сотни раз большую чем расчетная, а также очень масштабируемом, но свет он увидел уже после того как пришлось попрощаться с работодателем (сам ушел, по собственному желанию)
Чуть не расплакался. Помниццо принимал участие в проекте одном, который в итоге держа нагрузку в сотни раз большую чем расчетная, а также очень масштабируемом, но свет он увидел уже после того как пришлось попрощаться с работодателем (сам ушел, по собственному желанию)
По-моему, нужно просто активно использовать свои наработки, а ещё рефакторить, рефакторить и рефакторить. Тогда даже от одного вида гармонично сложенного кода будет тепло на душе.
Про рефакторинг, случай из жизни.
Дано:
и как в анекдоте — Петрович, смари! Новые индуктивности от Epcos, с нашими «самомотайками» не сравнить! 1 % КПД! Заказываем? итд. итп.
В итоге.
20 итераций промышленного образца и контора благополучно профукала бюджеты. )
Дано:
- команда разработчиков некого электронного устройства;
- устройство, очень энергонасыщенное (в объеме 3 пачек сигарет почти 1 кВт.);
- увлекающийся усовершенствованиями генеральный директор.
и как в анекдоте — Петрович, смари! Новые индуктивности от Epcos, с нашими «самомотайками» не сравнить! 1 % КПД! Заказываем? итд. итп.
В итоге.
20 итераций промышленного образца и контора благополучно профукала бюджеты. )
Это из другой оперы. Рефакторинг ПО никак не нарушает работу системы (если нарушает — это не рефакторинг), естественно, он должен проводиться в окружении тестов. Тесты выполняются почти мгновенно (если запускать их избирательно), каждый день проводятся глобальные дымовые тесты… Короче, чего я вам теорию пересказываю, её можно где угодно вычитать. И там же, скорее всего, будет приведены практические показатели — чёткий и ясный код быстрее писать, легче сопровождать и он быстрее работает (зачастую), следовательно если рефакторинг позволяет снизить затраты, то выход за рамки бюджета = ошибка в требованиях. В любом случае, рефакторинг должен быть не время от времени (ой, ё-маё, что это он понаписал?), а постоянным.
Плавно мысль перетекает в бравое TDD. В пику традиционному «программированию по требованиям» TDD даёт больше fun'а. Это не значит, что традиционное программирование скучное и нудное занятие. Я просто думаю, что автор статьи не на своём месте находится (возможно, нет перспектив роста или ещё что), короче ему просто нужно сменить обстановку :)
Вообще, как и любое творческое занятие, программирование требует подпитки эмоциональных сил. Тут можно подглядеть методы у дизайнеров, например, была неплохая статья Как нарисовать пятый в этом году сайт строительной компании и сохранить интерес к работе.
Плавно мысль перетекает в бравое TDD. В пику традиционному «программированию по требованиям» TDD даёт больше fun'а. Это не значит, что традиционное программирование скучное и нудное занятие. Я просто думаю, что автор статьи не на своём месте находится (возможно, нет перспектив роста или ещё что), короче ему просто нужно сменить обстановку :)
Вообще, как и любое творческое занятие, программирование требует подпитки эмоциональных сил. Тут можно подглядеть методы у дизайнеров, например, была неплохая статья Как нарисовать пятый в этом году сайт строительной компании и сохранить интерес к работе.
А может выложить свои наработки в opensource? Одна голова хорошо, а две лучше…
Если только совсем свои. Внутреннее ПО бухгалтерской компании врядли стоит выкладывать в общий доступ:)
А вот участие в OpenSource проектах зачастую полезно. Это ведь общение с единомышленниками, решение интересных задач, может быть даже в каком-то роде социалистическое соревнование (кто лучше напишет код).
А может автору просто пора в отпуск на Гаваи:))
А вот участие в OpenSource проектах зачастую полезно. Это ведь общение с единомышленниками, решение интересных задач, может быть даже в каком-то роде социалистическое соревнование (кто лучше напишет код).
А может автору просто пора в отпуск на Гаваи:))
Совершенно верно камрад! Грамотно проектировать, быстро «кодить» на одной ноге ;-) и рефакторить, рефакторить, рефакторить.
Недавно в одном разделе системы заказчик попросил срочно поменять представление данных и источник данных. Я сначала подумал о двухнедельном сроке выполнении этой задачи, но в итоге был затрачен только ОДИН «вечер» (изменение запроса, добавление пары строчек в модулях, пара строк в интерфейсе, плюс пара новых картинка и строчка в конфигурационном файле). Тогда я сказал — это КЛЕВО, это ЧУДО, это ГАРМОНИКА! А на следующее утро вместо графика работ показывали тестовую версию реализованных пожеланий заказчика.
Недавно в одном разделе системы заказчик попросил срочно поменять представление данных и источник данных. Я сначала подумал о двухнедельном сроке выполнении этой задачи, но в итоге был затрачен только ОДИН «вечер» (изменение запроса, добавление пары строчек в модулях, пара строк в интерфейсе, плюс пара новых картинка и строчка в конфигурационном файле). Тогда я сказал — это КЛЕВО, это ЧУДО, это ГАРМОНИКА! А на следующее утро вместо графика работ показывали тестовую версию реализованных пожеланий заказчика.
Программирование уверенно идет (или уже пришло?) к конвейеру Генри Форда. Согласен с основными мыслями автора, но, думаю, стоит дополнить, что писать «потрясающе-элегантный, умопомрачительно-инновационный код» нужно хотя бы для себя. Иначе в итоге единственным удовлетворением от работы будут зеленые бумажки. А это хоть и крайне нужная вещь, но явно недостаточная для счастливой жизни вообще и развития себя как специалиста в частности.
7. Найдите себе другую работу.
Все верно.
В процессе кодинга в итоге от него отказался — в команде программистов должен быть кто-то, кому фиолетово (хотя бы внешне) что творится с обратной стороны UI. В итоге, действительно, пока сам программировал, то валил все сроки ради очередной красивости — ладно внешней, а то внутренней. А когда наконец то надавал себе по рукам и перестал писать строки кода (немного принципиальных концептов может быть, каюсь, грешен) то разница между ожидаемым и достигнутым не превышает 10%.
Все верно.
В процессе кодинга в итоге от него отказался — в команде программистов должен быть кто-то, кому фиолетово (хотя бы внешне) что творится с обратной стороны UI. В итоге, действительно, пока сам программировал, то валил все сроки ради очередной красивости — ладно внешней, а то внутренней. А когда наконец то надавал себе по рукам и перестал писать строки кода (немного принципиальных концептов может быть, каюсь, грешен) то разница между ожидаемым и достигнутым не превышает 10%.
Очень хороший и приятно читаемый перевод, в отличие от многих других. Респект.
не показывать эту статью унылым менеджерам и унылым руководителям!!!
не дадим себя превратить в винтики, и серую массу мы не китайцы и японцы!
:)
а вообще демогогия это как обычно, великолепно написана, да, но пустышка.
насмотрелся я на «довольных» программистов, жалкое и унылое зрелище. но довольное.
но и спасибо автору и переводчику — нахватался замечательных фраз :)
не дадим себя превратить в винтики, и серую массу мы не китайцы и японцы!
:)
а вообще демогогия это как обычно, великолепно написана, да, но пустышка.
насмотрелся я на «довольных» программистов, жалкое и унылое зрелище. но довольное.
но и спасибо автору и переводчику — нахватался замечательных фраз :)
Отчасти верно… Очень верно.
По большому счету, клиент меряет состояние продукта двумя показателями: работает — не работает.
А что там внутри, ему не важно. Другой вопрос, а вдруг в перспективе будет расширение? Только вот на практике, пока не одному проекту, выполненному с возможностью гибкого масштабирования, таковое в глобальном масштабе не понадобилось…
Грусто, все это, товарищи. Грустно.
По большому счету, клиент меряет состояние продукта двумя показателями: работает — не работает.
А что там внутри, ему не важно. Другой вопрос, а вдруг в перспективе будет расширение? Только вот на практике, пока не одному проекту, выполненному с возможностью гибкого масштабирования, таковое в глобальном масштабе не понадобилось…
Грусто, все это, товарищи. Грустно.
НЛО прилетело и опубликовало эту надпись здесь
Последний абзац подтверждается жизнью.
Вы просто неимоверно чертовски правы в целом! Последний абзац отличное резюме всего сказанного.
А слова о том, что «возможно вы достигли максимума на этой работе»… в свое время я его не достиг, но четко увидел, где он находится, потому и перестал программировать сам.
А еще часть общей идеи, которая, к сожалению, не каждому понятна долгое время — это то, что программирование — это, скорее, больше рутина, нежели «искусство и постоянно что-то новое». Многие же хотят видеть себя «художниками» в своей профессии, и отсюда множество несогласных, сорванных проектов и стереотип о том, что программеры ничего и никогда не смыслят (и не могут смыслить) в бизнесе, а также «обиженные» программеры, считающие, что «да эти руководители, итить их в качельку, нихрена не понимают в нашей работе и технологиях». А я думаю, что по причинам, озвученным в топике, они просто никак «не договорятся».
А слова о том, что «возможно вы достигли максимума на этой работе»… в свое время я его не достиг, но четко увидел, где он находится, потому и перестал программировать сам.
А еще часть общей идеи, которая, к сожалению, не каждому понятна долгое время — это то, что программирование — это, скорее, больше рутина, нежели «искусство и постоянно что-то новое». Многие же хотят видеть себя «художниками» в своей профессии, и отсюда множество несогласных, сорванных проектов и стереотип о том, что программеры ничего и никогда не смыслят (и не могут смыслить) в бизнесе, а также «обиженные» программеры, считающие, что «да эти руководители, итить их в качельку, нихрена не понимают в нашей работе и технологиях». А я думаю, что по причинам, озвученным в топике, они просто никак «не договорятся».
Самый важный из семи пунктов — первый: изучайте бизнес. В большинстве случаев заказчик плохо представляет, что ему надо, и дословное соблюдение его требований ведет к унылому малоосмысленному набору бизнес-правил и унылому коду. Обычно заказчика можно убедить, что ему нужно нечто более элегантное.
И то что к сожалению не всем программистам дано. Обычно идет изготовление «по техзаданию», что заканчивается разочарованием с обоих сторон.
Для начала вам придётся его убедить в необходимости заплатить вам за изучение его бизнеса. Обычно на этом пункте все заканчивается :)
Бизнес и прикладную психологию, а лучше даже клиническую психиатрию!
Перевод отличный :)
хм, все в наших руках и даже самый скучный софт можно сделать с изюменкой и удовольствием.
приведу пример.
как то раз у меня была задача сделать некую статистику для манагеров, у этой статистики была веб-морда (выбор параметров и вывод результата в нескольких таблицах).
я всегда стараюсь подходить творчески к любой задаче. в общем сделал я эту статистику — все ок. потом подумал и сделал там такую фишку — все HTML элементы двигались в беспорядочном направлении, включая элементы ввода.
в итоге это выглядело так: та статистика, которую заказывали манагеры + еле заметная ссылка на «продвинутую» версию :)
мы ржали всем техдепартаментом) поверьте, это мне доставило массу положительных эмоций и удовлетворения.
пример может немного утрированный, но суть в том, чтобы проявлять свою инициативу, а не делать задачу для галочки
в любой «скучной» задаче, как правило много рутинной работы, но что мешает Вам разработать новые методы, которые сократят рутину — в этом то и весь интерес и смак программирования :)
ИМХО
приведу пример.
как то раз у меня была задача сделать некую статистику для манагеров, у этой статистики была веб-морда (выбор параметров и вывод результата в нескольких таблицах).
я всегда стараюсь подходить творчески к любой задаче. в общем сделал я эту статистику — все ок. потом подумал и сделал там такую фишку — все HTML элементы двигались в беспорядочном направлении, включая элементы ввода.
в итоге это выглядело так: та статистика, которую заказывали манагеры + еле заметная ссылка на «продвинутую» версию :)
мы ржали всем техдепартаментом) поверьте, это мне доставило массу положительных эмоций и удовлетворения.
пример может немного утрированный, но суть в том, чтобы проявлять свою инициативу, а не делать задачу для галочки
в любой «скучной» задаче, как правило много рутинной работы, но что мешает Вам разработать новые методы, которые сократят рутину — в этом то и весь интерес и смак программирования :)
ИМХО
Так там про это и написано :) Что вместо того чтобы уныло и точно делать ровно то, что просят, программисты начинают извращаться.
НЛО прилетело и опубликовало эту надпись здесь
Заказчик ставит вам ТЗ. То, что он не описал в ТЗ, его волновать не должно. Босс опять же может обговорить с вами предстоящую реализацию, но если ему требуется пост-фактум вам говорить, что вы что-то «не так» сделали, то либо что-то не так с вами — непрофессиональное опасное решение или еще не привыкли к принятым в конторе каким-то стандартам и т.п. — или что-то не так с конторой.В любом случае это неверная ситуация.
И вообще я-то пока еще за творческий подход, просто уточняю, что в статье как раз упомянуто то, что вы пытаетесь предлагать)))
И вообще я-то пока еще за творческий подход, просто уточняю, что в статье как раз упомянуто то, что вы пытаетесь предлагать)))
НЛО прилетело и опубликовало эту надпись здесь
Ну так это надо либо обговаривать заранее, если это принципиально, либо принимать как стандарт в конторе, либо как бы оставлять на усмотрение программиста. Если сначала это оставляют вам на откуп, а потом пеняют за «не такую» реализацию, то надо идти к начальству и говорить — давайте сразу пропишем все принципиальные моменты, чтобы в следующие раз ко мне не было таких претензий. Это как раз на мой взгляд абсолютно правильно и логично.
Все верно) Про несчем не согласиться)
Но идеология маштабируемости и сложности забита в наших головах!(
Но идеология маштабируемости и сложности забита в наших головах!(
И я поражен этой страшной болезнью…
То есть все плохо и беспросветно? Ну спасибо, автор стаьи, чтоб ты в аду варился((
Ну вот… теперь унылая и скучная работа разработчика будет казаться ещё более унылой и скучной
Каким бы унылым это не казалось, наша работа состоит исключительно в том, чтобы принести прибыль работодателю, а не удовлетворение нам. Вот, что означает быть профессионалом.
Золотые слова! Можно сколько угодно рвать на себе волосы и орать про китайские и японские винтики, а также «серую массу», но надо четко разделять понятие «профессионализм» и «оригинальность». Если кто-то считает, что написание кода, приносящего прибыль работодателю/заказчику, — это погрязание в серой массе, вы безусловно оригинал, однако не стоит при этом рассчитывать на звание профессионала.
И еще про японские винтики. Я видел, как в Японии выполняют свою работу, например, обычные смотрители ж/д станций или заправщики вендор-машин… Иначе как совершенством их стиль работы не назовешь. После этого мне стыдно говорить о рутинности моей программисткой деятельности. У программиста, занимающегося даже самой скучной программисткой деятельностью, пространство для достижения совершенства в тысячи раз больше, чем у заправщика вендор-машин. По-моему, программистам поря поумерить то, что Фрэнсис Фукуяма называет «тимосом».
Золотые слова! Можно сколько угодно рвать на себе волосы и орать про китайские и японские винтики, а также «серую массу», но надо четко разделять понятие «профессионализм» и «оригинальность». Если кто-то считает, что написание кода, приносящего прибыль работодателю/заказчику, — это погрязание в серой массе, вы безусловно оригинал, однако не стоит при этом рассчитывать на звание профессионала.
И еще про японские винтики. Я видел, как в Японии выполняют свою работу, например, обычные смотрители ж/д станций или заправщики вендор-машин… Иначе как совершенством их стиль работы не назовешь. После этого мне стыдно говорить о рутинности моей программисткой деятельности. У программиста, занимающегося даже самой скучной программисткой деятельностью, пространство для достижения совершенства в тысячи раз больше, чем у заправщика вендор-машин. По-моему, программистам поря поумерить то, что Фрэнсис Фукуяма называет «тимосом».
Не хочууу писать скучные программы :(
> В конце дня
В конце концов
В целом хороший перевод и статья интересная, спасибо!
В конце концов
В целом хороший перевод и статья интересная, спасибо!
Вообще интересно: применение паттернов, TDD и прочего, должно приводить к экономии времени, но если человек до этого их не использовал, то начав программировать с ними, он потратит большую часть драгоценного времени на их изучение, чем на код полезный заказчику.
ИМХО, стоит начать с quick&dirty кода, постепенно проводя рефакторинг от проекта к проекту (все-равно общих моментов у многих проектов полно) в итоге и придем к очень элегантному коду.
ИМХО, стоит начать с quick&dirty кода, постепенно проводя рефакторинг от проекта к проекту (все-равно общих моментов у многих проектов полно) в итоге и придем к очень элегантному коду.
Только вряд ли нормальный заказчик захочет быть объектом эксперимента. «Тренируйтесь лучше на кошках» (С)
П.с. Представьте себя у зубного врача с подобным подходом.
П.с. Представьте себя у зубного врача с подобным подходом.
Ну собственно, я про это и говорю. Лучше делать все итеративно, то есть работаешь над одним проектов и уже в процессе понимаешь, как можно было сделать лучше, но применяешь это только в следующем проекте.
а что делать? врачами знаете ли тоже сразу не становятся. и рано или поздно те же интерны начинают ставить эксперименты на живых пациентах, точнее тренироваться.
Так же как и парикмахеры и прочие специальности.
Так же как и парикмахеры и прочие специальности.
Во-первых, практиканты делают всё под контролем опытного врача.
Во-вторых, нормальный пациент предпочтет лечиться у профессионального врача, а не у практиканта, благо видно сразу, к кому приходишь лечиться.
А в примере с парикмахерами — я знаю, где меня могут постричь за 40 рублей (практиканты), но стригусь обычно за 200-250… А туда, где за 40 я не пойду. Потому что хоть и дешевле, но не хочу быть учебным пособием.
Во-вторых, нормальный пациент предпочтет лечиться у профессионального врача, а не у практиканта, благо видно сразу, к кому приходишь лечиться.
А в примере с парикмахерами — я знаю, где меня могут постричь за 40 рублей (практиканты), но стригусь обычно за 200-250… А туда, где за 40 я не пойду. Потому что хоть и дешевле, но не хочу быть учебным пособием.
а я знаю тайное знание где за 120 стригут не практиканты )))
но да не в этом дело.
Дело в том, что у программистов не развито практически чувство старшего мастера.
Мы все сами с усами. И сами рвёмся в бой с пылким взором!
В итоге и получается то, что получается.
Просто автор пишет о следствиях, тогда как давно пора задуматься о причинах и способах устранения их из ИТшной проф. области.
но да не в этом дело.
Дело в том, что у программистов не развито практически чувство старшего мастера.
Мы все сами с усами. И сами рвёмся в бой с пылким взором!
В итоге и получается то, что получается.
Просто автор пишет о следствиях, тогда как давно пора задуматься о причинах и способах устранения их из ИТшной проф. области.
Всё правильно.
И мне кажется, что 90% программистов придут к этому пониманию, но спустя лет пять программирования «на заказчика». А оставшиеся 10% останутся в вечных «экспериментаторах», будут придумывать что-то инновационное, но никогда не станут профессиональными _разработчиками_.
И теперь вопрос — как найти программиста, который подпишется под статьей? :)
Мне очень нужен хороший RubyOnRails-программист, который понимает и принимает всё вышесказанное :)
Rак его отличить от программиста, который в проекте «на ходу» меняет языки программирован, подходы, шаблонизаторы, и т.п.? Опытным путем слишком затратно…
И мне кажется, что 90% программистов придут к этому пониманию, но спустя лет пять программирования «на заказчика». А оставшиеся 10% останутся в вечных «экспериментаторах», будут придумывать что-то инновационное, но никогда не станут профессиональными _разработчиками_.
И теперь вопрос — как найти программиста, который подпишется под статьей? :)
Мне очень нужен хороший RubyOnRails-программист, который понимает и принимает всё вышесказанное :)
Rак его отличить от программиста, который в проекте «на ходу» меняет языки программирован, подходы, шаблонизаторы, и т.п.? Опытным путем слишком затратно…
В статье банальности, на которые все закрывают глаза и не хотят видеть, но, по себе сужу, чесно следуют.
Автор написал именно то, в чем я убедился. Респект.
Программирование это не исскуство, программирование это ремесло.
Программирование это не исскуство, программирование это ремесло.
Может быть это просто две разные вещи? :)
Взять, например, кондитеров. Для тех, кто печёт московские плюшки это, может и ремесло, но для истинных кулинаров это искусство.
Взять, например, кондитеров. Для тех, кто печёт московские плюшки это, может и ремесло, но для истинных кулинаров это искусство.
Возможно. Но автор статьи какбы про это и пишет. Зачем нужны истинные кулинары, чтобы печь московские плюшки? Истинным кулинарам нужно тогда быть одиночками и писать свои программы, которые изменят мир и сделают его менее скучным и более вкусным. К сожаление, для индустрии в целом, занимающейся производством плюшек, сегодня нужны скорее автоматы чтобы эти самые плюшки готовить быстрее и больше, чтобы покушать могли все.
такое же ремесло как писать картины, например
чтобы построить дом художники мало будут полезны, скорее нужны инженеры и архитекторы… ну и строители естественно.
В строительстве дома и программисты мало пользы принесут :)
Но всетаки ИМХО строительство дома ближе к программированию чем писание картин :-)
НЛО прилетело и опубликовало эту надпись здесь
Все верно, только когда нам нужно строить дом, а дом нам нужно в ИТ строить практически постоянно, то нет иного выхода как сооружать трехмерный принтер из программистов, архитекторов и тестировщиков, которые собственно будут по накатанной работать. Это скучно, не спорю, но заказчику нужен дом, а не остров, который будет и летать и плавать и при этом вместо обычных жителей на нем смогут жить только лапутяне.
ИМХО самая толковая статья на хабре за последнюю неделю. Программирование ради программирования должно существовать только как академическая дисциплина для интересующихся. Нет НИКАКОЙ связи между качеством кода и качеством продукта в целом. Обывателю наплевать как программа написана — хоть стадом обезъян котороые танцевали на клавиатуре. Главное что бы продукт:
1) не сильно глючил
2) не тормозил
3) выполнял ожидаемые от него функции.
Всякие там рефакторинги, реорганизации, усложнения кода ради никому не нужной гибкости — только для «астронавтов проектирования»
Практика показывает что в 80% случаем рефакторинг себя не оправдывает — проще и быстрее ( и дешевле) нагородить хаков поместу нежели перепроэктировать ради получения той же функциональности.
1) не сильно глючил
2) не тормозил
3) выполнял ожидаемые от него функции.
Всякие там рефакторинги, реорганизации, усложнения кода ради никому не нужной гибкости — только для «астронавтов проектирования»
Практика показывает что в 80% случаем рефакторинг себя не оправдывает — проще и быстрее ( и дешевле) нагородить хаков поместу нежели перепроэктировать ради получения той же функциональности.
Для начала ознакомьтесь с понятием, у вас сильная каша в этом вопросе.
Я не описываю понятие рефакторинга — я описываю результат его применения для конечного пользователя и продукта. К рефакторингу зачастую приходят когда архитектура раздувается и новая фича никак не хочет встраиваться в текущую архитектуру. Тогда начинаются обсуждения в духе: все плохо, давайте перепишем, будет кода в 2 раза меньше, а скорость в 2 раза больше и при этом новые фичи будут встраиватся почти на шару.
И подобная картина может повторятся раз в 3 — 4 месяца (по мере продвижения продукта с нечетким фичелистом).
Так вот, как правило подобная ерунда приводит только одному — увеличению сроков разработки.
И подобная картина может повторятся раз в 3 — 4 месяца (по мере продвижения продукта с нечетким фичелистом).
Так вот, как правило подобная ерунда приводит только одному — увеличению сроков разработки.
Это и есть каша. Рефакторинг не проводится время от времени (вернее, конечно, может, но тогда и будет всё как вы описали). Плюс рефакторинг кода — это одно, изменение архитектуры — это другое. А изменение требований — третье. Хороший рефакторинг быстро окупается. А неправильные требования — самая дорогая ошибка.
>> чтобы принести прибыль работодателю, а не удовлетворение нам.
ИМХО работа профессионального програмиста должна удовлетворять клиента, а профессионализм маркетолога — продать ее с максимальной прибылью.
И еще, я сразу предупреждаю школьников — в информатие есть место творчеству в начале и в конце. А посредине есть место только упорству и пунктуальности. Надеюсь они это понимают, когда выбирают профессию.
ИМХО работа профессионального програмиста должна удовлетворять клиента, а профессионализм маркетолога — продать ее с максимальной прибылью.
И еще, я сразу предупреждаю школьников — в информатие есть место творчеству в начале и в конце. А посредине есть место только упорству и пунктуальности. Надеюсь они это понимают, когда выбирают профессию.
НЛО прилетело и опубликовало эту надпись здесь
У вас хорошо получаются переводы; и темы вы выбираете очень интересные! Спасибо! Надеюсь, на продолжение.
И еще, все верно, но… насчет третьего правила: почему моя любимая — медик, каждый год на пару недель обкладывается «учебниками», сдает очередные квалификационные экзамены, ей присуждают более высокую степень, прибавляют в зарплате и все это в рабочее время за счет работодателя? И в многих других сферах — это норма.
Потому, что от её навыков зависит человеческое здоровье.
Вообще, и программисты могут повышать квалификацию за счёт работодателя. Главное объяснить этому работодателю, что ему же выгоднее отправлять сотрудника на семинары для повышения производительности труда.
Вообще, и программисты могут повышать квалификацию за счёт работодателя. Главное объяснить этому работодателю, что ему же выгоднее отправлять сотрудника на семинары для повышения производительности труда.
Ххехехех… попадалась статья про ошибки, допущенные при программировании медицинских приборов. Что-то там переполнилось, в результате прибор превысил требуемую интенсивность рентгеновского излучения в стопицот раз, поциент помер через несколько дней. Это если совсем буквально подходить к вопросу о том, от чьих навыков зависит здоровье :)
Если кому интересно: Therac-25
ru.wikipedia.org/wiki/Therac-25
ru.wikipedia.org/wiki/Therac-25
Довольствуйся тем, что есть.
Обходись тем, что умеешь.
Может быть идеальный программист должен быть буддистом?
Обходись тем, что умеешь.
Может быть идеальный программист должен быть буддистом?
Жалко, ресурс ru.thedailywtf.org с подобными переводами загнулся.
Может автору данного перевода just for fun захочится помочь ребятам с вышеуказанного ресурса в переводе? ;)
Может автору данного перевода just for fun захочится помочь ребятам с вышеуказанного ресурса в переводе? ;)
нуу… несколько не соглашусь.
в боевой работе не стоит использовать то, что ещё не научился делать идеально. А если научился — то во-первых уже отдаёшь себе отчёт когда это действительно нужно а когда нет, и во-вторых если это нужно это в любом случае принесёт пользу.
Так, TDD очень сильно ускоряет разработку одного круга задач, не так сильно других и может совсем замедлить остальные. Догадаться, не посидев с TDD годик изначально — невозможно.
Но рынок (бизнес) стоит во главе стола — это в любом случае правда. Все это знают кроме самих программистов =).
в боевой работе не стоит использовать то, что ещё не научился делать идеально. А если научился — то во-первых уже отдаёшь себе отчёт когда это действительно нужно а когда нет, и во-вторых если это нужно это в любом случае принесёт пользу.
Так, TDD очень сильно ускоряет разработку одного круга задач, не так сильно других и может совсем замедлить остальные. Догадаться, не посидев с TDD годик изначально — невозможно.
Но рынок (бизнес) стоит во главе стола — это в любом случае правда. Все это знают кроме самих программистов =).
Вообще-то бизнес — это дело. А не рынок, заработок или заказы, или ещё-какая-то-непонятная-хренотень. А дело у каждого может быть своё и может быть разное. И некоторые дела требуют творчества. Собственно, вы можете быть столяром и собирать столы в IKEA на скорость, а можете вырезать статуэтки из дерева. Почему от программистов нужно требовать иного мировозрения? Ну, не хочет человек рутиной заниматься, ну, и фиг с ним. Если он может себе на жизнь не рутиной, так это же прекрасно.
А морали читать с призывами ко всем понижать уровень креативности в работе — это как-то совсем не здорово, imho. Если человек не может успешно креативничать, он сам это скоро поймёт. А если может, то зачем его останавливать?
А морали читать с призывами ко всем понижать уровень креативности в работе — это как-то совсем не здорово, imho. Если человек не может успешно креативничать, он сам это скоро поймёт. А если может, то зачем его останавливать?
В мемориз однозначно. Красивые фразы из текста распечатаю и повешу на стены, как мотиватор и прозреватор для сотрудников :)
очень перекликается с Эффективным программистом
В принципе, все очень логично, бизнесу нужен результат в минимальные сроки при минимальных расходах.
Творчеству уделяем свободное время и получаем кайф и скилы:)
В принципе, все очень логично, бизнесу нужен результат в минимальные сроки при минимальных расходах.
Творчеству уделяем свободное время и получаем кайф и скилы:)
А вообще, есть такая (порой даже весьма занятная) книга по теме. 'Рабы Майкрософта' называется.
Программист — это профессия, которая делает человека счастливым и свободным. Конечно лишь в том случае, если человек — программист по призванию, а не потому, что «так получилось».
Программист, который любит и умеет программировать, волен делать почти что угодно. Именно потому, что угодно обычно создавать «секси» программы. Такие штуки всегда делаются с душой и качественно. И они всегда востребованы.
За примерами далеок ходить не надо: digg, twitter, qip, plentyoffish.com, youtube, myspace и многие многи другие, о которых меньше слышно, но которые делают своих авторов не менее счастливыми. В качестве более земного пример могу привести проект total influence. Afaik, автор начал писать игруху, потому что было интересно. А сейчас ему за это платят.
В общем всё в наших руках. А унылый софт для складского учёта пусть пишут те, кто не согласен :)
Программист, который любит и умеет программировать, волен делать почти что угодно. Именно потому, что угодно обычно создавать «секси» программы. Такие штуки всегда делаются с душой и качественно. И они всегда востребованы.
За примерами далеок ходить не надо: digg, twitter, qip, plentyoffish.com, youtube, myspace и многие многи другие, о которых меньше слышно, но которые делают своих авторов не менее счастливыми. В качестве более земного пример могу привести проект total influence. Afaik, автор начал писать игруху, потому что было интересно. А сейчас ему за это платят.
В общем всё в наших руках. А унылый софт для складского учёта пусть пишут те, кто не согласен :)
Это только со стороны кажется, что главное — идея. Любой, кто довёл хоть один проект с нуля до продакшена, знает, что главное — это реализация. Программистом быть хорошо, потому что реализовать свою идею можно даже в одиночку. А уж в коллективе ещё из двух-трёх увлечённых подельников — тем более.
НЛО прилетело и опубликовало эту надпись здесь
помнится, один из основателей google(Брин или Пейдж, не помню) говорил, что порядка 20% ресурсов компании уходит в инновации в деятельности. Есть чему поучиться. Т.е. порядка 20-40% личных ресурсов можно/нужно тратить создание sexy-прог. Другими словами — найти свою золотую середину.
Разработка — процесс, в котором нет предела совершенству. Будь это скучный внутрикорпоративный софт или какой-нить мега-супер-твиттер, которым пользуются миллионы. Поэтому всегда можно писать лучше, красивее, быстрее и качественнее. Налаживать процессы разработки, улучшать интерфейс, использовать прогрессивные технологии и т.п.
Короче, что я хочу сказать: дело не в унылости софта, а в унылости разработчика, если ему работа не в радость.
Короче, что я хочу сказать: дело не в унылости софта, а в унылости разработчика, если ему работа не в радость.
И согласна, и не согласна одновременно. «Кодеры-ремесленники» и «программисты-художники» — это только две стороны одной медали. И, чтобы не чувствовать себя «винтиком», никто не запрещает их совмещать.
К примеру, у меня три основных заказчика. первый — это как раз из статьи, типа «пофигу, КАК, но побыстрее и поприбыльнее». Второй — полная противоположность, даёт интересные задания с новаторскими технологиями. А у третьего делаю мелкие правки в коде. Соответственно, не страдает ни интерес, ни портфолио, ни кошелёк… страдает периодически разве что время, но здесь, думаю, многим не привыкать кодить по ночам. И когда мне надоедает чувствовать себя тем самым «винтиком», я просто берусь за более интересные проекты.
Я к чему это пишу… у менеджеров своя правда, у нас — своя. Менеджеру ВЫГОДНО сделать нас «винтиками», купить нас с потрохами на полный день, выжимать из нас все соки, не давая даже повышать квалификацию, а когда придут новые технологии, выкинуть нас, как использованную одноразовую посуду. Не ведитесь, господа. Пусть они думают, что мы играем по их правилам, но на деле МЫ продаём им свои услуги, и, в конечном итоге, нам решать. что да как, и, если мы уважаем себя, мы выгадаем и время на саморазвитие, и более интересные проекты. Да, «семь пятниц на неделе» и бесконечные рефакторинги в production-коде — это плохо. Но, в конце концов, никто же не заставляет только этим и заниматься… ;)
К примеру, у меня три основных заказчика. первый — это как раз из статьи, типа «пофигу, КАК, но побыстрее и поприбыльнее». Второй — полная противоположность, даёт интересные задания с новаторскими технологиями. А у третьего делаю мелкие правки в коде. Соответственно, не страдает ни интерес, ни портфолио, ни кошелёк… страдает периодически разве что время, но здесь, думаю, многим не привыкать кодить по ночам. И когда мне надоедает чувствовать себя тем самым «винтиком», я просто берусь за более интересные проекты.
Я к чему это пишу… у менеджеров своя правда, у нас — своя. Менеджеру ВЫГОДНО сделать нас «винтиками», купить нас с потрохами на полный день, выжимать из нас все соки, не давая даже повышать квалификацию, а когда придут новые технологии, выкинуть нас, как использованную одноразовую посуду. Не ведитесь, господа. Пусть они думают, что мы играем по их правилам, но на деле МЫ продаём им свои услуги, и, в конечном итоге, нам решать. что да как, и, если мы уважаем себя, мы выгадаем и время на саморазвитие, и более интересные проекты. Да, «семь пятниц на неделе» и бесконечные рефакторинги в production-коде — это плохо. Но, в конце концов, никто же не заставляет только этим и заниматься… ;)
Я раньше часто менял проекты, искал только интересные, теперь использую работу тупо ради денег, интерес сохраняю для своих личных проектов и для open source, можна сказать что я здался, но так как то проще работать. И все довольны и жена и босс и я
НЛО прилетело и опубликовало эту надпись здесь
5 пункт вообще, аж прослезился… Есть такое и частенько думаешь — а вот бы кнопочку, чтобы хоп — и написала все :-D
Когдато г-н Кармак писал для своего брата по-моему ( давно было могу перепутать ) блокнот. Потом исходники выложили в инет.
Там есть кусок, отвечающий за инициализайию канваса для печати, представляющий собой нечто вроде:
ourCanvas.height = 0; // auto;
ourCanvas.width = 0; //auto;
И так строчек 20, гдето на 10 комменты //auto пропадают, а в конце написан коммент, вольный перевод которого звучит примерно так «уфф… ну вроде мы обошли все подводные камни, подложенные нам господами от Микрософт» :-D
Когдато г-н Кармак писал для своего брата по-моему ( давно было могу перепутать ) блокнот. Потом исходники выложили в инет.
Там есть кусок, отвечающий за инициализайию канваса для печати, представляющий собой нечто вроде:
ourCanvas.height = 0; // auto;
ourCanvas.width = 0; //auto;
И так строчек 20, гдето на 10 комменты //auto пропадают, а в конце написан коммент, вольный перевод которого звучит примерно так «уфф… ну вроде мы обошли все подводные камни, подложенные нам господами от Микрософт» :-D
в целом верно всё написано, и способность выбрать наиболее эффективный способ реализации адекватный поставленной задачи (сложность, сроки и т.п.) это признак профессионала.
Но есть одно НО.
Есть задачи в которых требования меняются со временем. Увеличивается нагрузка посещаемостью, требования по оформлению и т.д. и т.п.
И чертовски обидно когда приходят и говорят «что же ты зараза сделал всё так плохо, что вот N месяцев спустя у нас ничего не работает». Упуская момент что N месяцев оно всё работало, а сейчас изменились бизнесс требования.
Архитекторов, например, не заставляют перестроить здание в краткие сроки через пару лет, существенно изменяя изначальные требования.
Текст написан с одной стороны, и да, нужно быть профессионалом и не увлекаться, когда речь идёт о реальном проекте, реальных деньгах и ограниченном времени.
Однако, к ИТ специалистам, как к футболистам и политикам, есть такое отношение со стороны народа, что народ всегда знает как сделать лучше. Что фигнёй мы занимаемся и сложного-то ничего в работе нет.
Вот это заблуждение так же надо искоренять из работодателей, заказчиков и менеджеров. Тогда будут и повышения квалификации и нормальное отношение программистов к выполнению своих обязанностей, без чрезмерного увлечения технологиями.
У нас же в ИТ порой каждый менеджер «знает как лучше» и «знает как быстрее», о чём обязательно уведомляет программиста, рассказывает ему своё мнение, заставляет выслушать, отъедая тем самым рабочее время, а потом ещё за это же время пеняет, что мол не уложился, дурью маялся.
Но есть одно НО.
Есть задачи в которых требования меняются со временем. Увеличивается нагрузка посещаемостью, требования по оформлению и т.д. и т.п.
И чертовски обидно когда приходят и говорят «что же ты зараза сделал всё так плохо, что вот N месяцев спустя у нас ничего не работает». Упуская момент что N месяцев оно всё работало, а сейчас изменились бизнесс требования.
Архитекторов, например, не заставляют перестроить здание в краткие сроки через пару лет, существенно изменяя изначальные требования.
Текст написан с одной стороны, и да, нужно быть профессионалом и не увлекаться, когда речь идёт о реальном проекте, реальных деньгах и ограниченном времени.
Однако, к ИТ специалистам, как к футболистам и политикам, есть такое отношение со стороны народа, что народ всегда знает как сделать лучше. Что фигнёй мы занимаемся и сложного-то ничего в работе нет.
Вот это заблуждение так же надо искоренять из работодателей, заказчиков и менеджеров. Тогда будут и повышения квалификации и нормальное отношение программистов к выполнению своих обязанностей, без чрезмерного увлечения технологиями.
У нас же в ИТ порой каждый менеджер «знает как лучше» и «знает как быстрее», о чём обязательно уведомляет программиста, рассказывает ему своё мнение, заставляет выслушать, отъедая тем самым рабочее время, а потом ещё за это же время пеняет, что мол не уложился, дурью маялся.
Интересно вот что — этот перевод статьи о том, что «Программирование — отстой» — залайкали многие читатели Хабра.
Когда же я говорил о том же: habrahabr.ru/post/218727/ — меня заговнили.
В чем же дело? Двойные стандарты? Или дело в том, что эта статья не касается личности программиста?
В любом случае, я рад, что появляются такие статьи, как эта, или как моя, где людям открывают глаза на эту бездонную пучину под названием «программирование». Скольких молодых людей оно съест, проглотит и переварит, покак до них дойдет, что программирование — отстой.
Когда же я говорил о том же: habrahabr.ru/post/218727/ — меня заговнили.
В чем же дело? Двойные стандарты? Или дело в том, что эта статья не касается личности программиста?
В любом случае, я рад, что появляются такие статьи, как эта, или как моя, где людям открывают глаза на эту бездонную пучину под названием «программирование». Скольких молодых людей оно съест, проглотит и переварит, покак до них дойдет, что программирование — отстой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программирование — отстой! Или что-то вроде того