Comments 201
Чтобы написать самому такой объём, нужно знать и уметь очень много. Принцип качественной статьи: «Своди страницу в абзац, а абзац — в предложение!». Но знаний не хватает, а писать хочется.
Опять же, можно пообсуждать какие-то тезисы, а в случае чего — сослаться на авторитет.
Да и времени для написания статьи требуется меньше. Сочинение пишется дольше изложения.
Поздравляю автора с днем рождения и спасибо за статью.
Я не стал бы так судить о человеке. Не стоит забывать что вы смотрите на всех через призму своего восприятия людей. А в отношении себя могу сказать что мне было интересно прочитать эту выжимку из книги и мне не понадобилось выделять на это много времени. А с временем у меня уже давно проблемы и насобирался большой список того что нужно прочитать, изучить, попробовать. Теперь я могу судить о книге и понять хочу ли я ее прочитать и какой приоритет.
Зона потока — зло.
Странно, свой лучший код я написал именно в «зоне потока», я его называю состояние драйва или «поймал волну». Видимо, потому что такое состояние появляется, когда у тебя в голове сложился весь пазл, ты имеешь полную картинку и превращаешь её в код и самое главное — никто не отвлекает.
Но, в целом, статья очень годная.
Автору душевное спасибо, а так же легкой сдачи заказов и проектов, с днем рождения:)
Просто в такие моменты получается находить решения сложных проблем или увязывать между собой кусочки масштабной системы. И тут поток дает отличный результат.
Вообще такое состояние я отношу к «удержанию абстракций повышенной сложности», т.е. в обычном написании программы, программист удерживает в голове одну или несколько абстракций и перекладывает их на пишущийся код. А в моменты просветления сложность удерживаемой абстракции увеличивается. Где-то даже статья была про это, как бы не на хабре…
1. У вас отсуствует в этот период адекватный фидбек. Программист, можно сказать, становится зашорен и мчится напролом к созданию той картины, которую он нарисовал в своей голове. Это полностью противоречит идее agile разработки, которая предполагает, что вы двигаетесь в работе короткими циклами, постоянно оглядываясь назад и по сторонам чтобы вовремя заметить, что вы свернули где-то не туда.
Опять же, когда человек вдруг вытаскивают из зоны (что обязательно случается рано или поздно) это вызывает у него фрустрацию, а потом еще время на попытки опять в эту зону попасть.
2. Люди, входящие в «зону» становятся трудно достижимыми для их сокомандников. Создание программного продукта это стройка, а не марафон; тут важна возможность быстро обсудить что-то с коллегой, сделать ревью кода, показать прототип и т.п.
2. А зачем мне сокомандники, я спокойно обхожусь без них в течении дня. Поток у меня длится час-два и этого обычно хватает на решение какой-то проблемы. В результате, по вашим словам, у меня складывается ощущение, что вы каждые полчаса устраиваете митинг, чтобы обменяться мнениями. Но это же говорит о слабости членов вашей команды и слабой проработке архитектуры создаваемой системы :)
Agile в данном контексте это не какой-то там SCRUM, а именно сам подход к работке, подразумевающий, что работа бъется на короткие циклы (вплоть до 5 минут). При таком подходе ваш фокус не распыляется, и каждый N минут у вас есть какой-то законченый кусок работы (метод, класс или еще что-то).
По поводу сокомандников тут я вижу проблему в том, что если каждый сидит в зоне потока, то, во-первых, коллеги боятся лишний раз посоветоваться друг с другом, т.к. любой из них может находиться в потоке, а во-вторых, потоки разных людей не синхронизированы, т.е. найти время, когда все члены команды вне потока чтобы провести митинг становится сложно. Имхо, такая ситуация не способствует атмосфере взаимопомощи и командной работы.
Agile в данном контексте это не какой-то там SCRUM, а именно сам подход к работке, подразумевающий, что работа бъется на короткие циклы (вплоть до 5 минут). При таком подходе ваш фокус не распыляется, и каждый N минут у вас есть какой-то законченый кусок работы (метод, класс или еще что-то).
Но при таком подходе вы не увидите/не прогнозируете ни средне-, ни долгосрочную линию работы.
Да и насчет ближней — тоже вопрос.
Давно предполагаю, что фанатичное следование Scrum/Agile зачастую говорит о синдроме дефицита внимания, о неспособности сконцентрироваться хотя бы на пару часов, чтобы рассмотреть задачу в целом.
но практике программисты не видят ничего кроме пятиминуток.
Получается mushroom management с быстрыми короткими движениями между скрамами.
Даже если и видна стратегическая перспектива, то результат, который можно пощупать, нужно показывать к следующему ежедневному скраму, соответственно, работа на перспективу, даже относительно ближайшую, программистами не ведется.
Ну а если при этом еще и времени на планирование выделяется больше, чем по водопаду…
Возможно это индивидуально. Но по опыту вижу что человек работал в потоке, когда коммитет больше 10 файлов за раз (бывает и по 50), а в сообщении коммита не способен нормально описать чем занимался. Обычно такой код проскакиевает код ревью. Но в дальнейшем возникают проблемы с его поддержкой. Так называемая "стрельба дробью". Когда для внесения небольших изменений, в результате неявных зависимостей, нужно перелопачивать все эти файлы.
П.с. по крайней мере, со мной так :)
и самое главное — никто не отвлекает.
Может, ключевой момент в том, что никто не отвлекает? Получается, что у вас Зона, наверняка, ночью. Верно же?
С ночью не угадали. Может быть и утром на свежую голову, бывает и ночером(с 10 до 2) или после прогулки или физической нагрузки, но обязательно должен быть момент когда решение сошлось и надо зафиксировать его в коде.
Хороший программист в состоянии потока остается хорошим программистом, плохой — плохим.
В который раз к утверждению про «поток зло» напоминаю про книжку: Михай Чиксентмихайи, «Поток».
И кому верить? — Фаулер вот тоже авторитет.
Я к чему — ну немного… надоели все эти менеджерские техники и фанатичное им следование или их пропагандирование.
Может быть, лучше учить языки, библиотеки, принципы проектирования, учиться разбивать задачи на интересные подзадачи, и весь такой прочий технический олдскул, а не надеяться на некие техники как культ карго.
Желаю счастья, здоровья и всего всего чего душа пожелает :)
Что то многовато программистов в эти дни родилось, особенно если начать с прекрасной Ады ;)
По всем выше перечисленным пунктам можно полностью согласится, хотя в каждом случае бывают исключения.
Например на счет «нет», вроде думаешь что нет, не справишься, а начал схватил «волну» и в срок успел и глазу приятно :)
НО опять все это исключения, жизнь слишком многогранна что бы могла уместится в простые рамки :)
Проверяется просто: попробуйте внести изменения в ваш код. Если это вызовет боль чуть ниже пояса, — значитЗначит стоит попробовать руками :Dс гибкостью у вас всё плохо.
Вы уволены… :-)
он — быдлокодер и плевал он на C++11, шаблоны проектирования и прочее
Костыльный программист :)
Проблема в том, что желание спроектировать красивую архитектуру часто перерастает в оверинжиниринг. Необузданный перфекционизм — вообще бич воодушевленных (passionate) программистов. Вполне естественно в таких случаях желание руководителей не допускать такого развития событий, но почти всегда это приводит к противоположной крайности.
Просто хорошо.
Которое другие тут же закидывают лозунгами типа «идеальная архитектура», «оверинжениринг» и т.д. и т.п.
Как результат эти закидыватели выглядят, в глазах руководства, как «прагматичные» разработчики «ориетированные на бизнес». Они попадают в лиды и говноподходы продолжают культивироваться.
Итог — имеем то, что имеем…
Тут есть большая разница. "архитектурно слабое решение" нормальное, если у вас не будет необходимости потом бороться с недостатками. Например нам нужно сделать что-то за 2 дня. И мы можем сделать это что-то за два дня, но есть еще нефункциональные требования, нагрузки, безопасность… Мы понимаем что решение, с которым мы можем успеть несет в себе огромные риски. А потому лучше сказать нет, ибо на самом деле эта реализация сродни ложному обещанию: Мы как бы все сделали, но потом придется переделывать. Причем как правило клиент будет больше расстроен тем, что его вовремя не предупредили о рисках.
Другой пример. Попросили вас сделать что-то, что будет использоваться лишь раз. Например — импорт данных из одной системы в другую. Эта операция будет происходить ровно один раз. И объем данных известен. Но разработчик хочет сделать правильно, пишет отдельный компонент, который использует какой-нибудь потоковый парсер, импорт по частям, заботится о производительности решения и т.д. Словом, делает "правильно" и тратит на эту одноразовую штуку в 3 раза больше времени.
То есть по сути, разработчик всегда должен понимать зачем он что делает, и исходя из этого уже оценивать плюсы/минусы принимаемых решений и искать наиболее эффективный вариант.
Ну и слава богу! Валить надо как можно скорее из такой компании, где за выражение экспертного мнения указывают на дверь.
Вы уволены… :-)
Пожалуй, для каких-то работодателей может случиться и так. Но часто такая позиция вызывает уважение. Чуть подробнее в комменте ниже.
Спасибо за статью. С днем рождения!
Я считаю, что поставленные задачи невозможно выполнить качественно и в срок. Многие коллеги «в курилке» согласны со мной. Однако на совещаниях я остаюсь в одиночестве и только я говорю, что все плохо со сроками и плохо с архитектурой. Остальные продолжают уверять менеджмент, что все отлично и все можно сделать.
Получается, что я один и есть «хромая утка», которая постоянно говорит неприятности.
Не очень весело. Для себя решил, пожалуй лучше больше молчать и больше соглашаться.
С днем рождения)
Вот вопрос с зоной потока мне действительно показался спорным… Я наоборот в таком случае облачаюсь в наушники, ставлю телефон на dnd и пишу, пишу, пишу… А на следующий день или через некоторое время делаю ревью с рефакторингом и переписываю какие-то вещи.
Стоит ли совет про скромность и непогрешимость применять к самому Мартину — решайте сами. Давайте парочку других моментов разберём.
«Зона потока — зло». То есть, предлагается делать себя менее счастливым (подробности есть в книге Поток, и да, расшифровка термина у авторов может чуть отличаться, но база общая). Нет, спасибо. Не знаю как у всех, лично мной в состоянии потока реализовано много красивых идей. То, что потом ревью кода стоит сделать — это не вопрос :)
«Понимают интересы работодателя и заказчика.» vs. «Говорите «Нет»».
Оба пункта горячо поддерживаю. Но предлагаемые варианты как говорить «нет» не показывают понимания интересов.
— Это невозможно, на разработку и отладку поиска нужно две недели.
— Нам нужно показать клиенту в пятницу. Давай постараемся.
В этом разговоре накосячили оба участника (можно спорить кто больше). Если ко мне, как к разработчику, придут с задачей и сроками, которые плохо сосуществуют в одной вселенной, я буду разбираться, как можно что-то в них скорректировать. Если я как менеджер приду к разработчику с такой задачей, я объясню цели показа в пятницу — может, в итоге, нужно показать только визуальную часть или вполне подойдёт реализация только типичного сценария.
Вообще говоря, я не люблю слово «невозможно», особенно, когда его говорят сразу после того, как услышали название задачи. Даже для NP-полных задач :) Ведь если разобраться в том, что действительно необходимо сделать, может оказаться, что алгоритм всегда будет работать на малом объёме данных или вполне устраивает приблизительное решение.
P.S. Про «Код должен быть покрыт тестами на 100%» не буду особо комментировать. Надеюсь, все понимают, что 100% покрытие не гарантирует корректность кода.
Фаулер про покрытие тестами: http://martinfowler.com/bliki/TestCoverage.html
Если вы тестируете осознанно и качественно, можно ожидать покрытия в районе 90%. В то же время, покрытие 100% выглядит подозрительно — выглядит так, будто кто-то специально пишет тесты таким образом, чтобы получить высокий процент покрытия, но не задумываясь о том, что он делает.
(If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s. I would be suspicious of anything like 100% — it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.)
Так в чем же ценность анализа покрытия кода тестами? Это просто помогает определить, какие части вашего кода не протестированы.
So what is the value of coverage analysis again? Well it helps you find which bits of your code aren't being tested
Конечно, я не фанат таких условий, но я и сам не вижу альтернатив, как небольшим компаниям в условиях тотальной экономии бюджета пытаться что-то вывести на рынок, когда они даже не знают примет ли народ их решение.
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге (с) баш
Зона потока для меня — это спокойная, почти не отвлекающая музыка, либо её отсутствие и почти полная тишина в студии, при этом я сконцентрирован и все получается хорошо.
С днём рождения! :) Интересно будет прочесть эту книгу.
Если вы работаете 40 часов в неделю, — запланируйте на работу 60 часов. Из них 40 часов вы потратите на работодателя, а оставшиеся 20 — на самообразование.
плохой совет. Хороший должен быть: если работаешь 40 часов в неделю, планируй на работу 30, а оставшиеся 10 на самообразование, в будущем потенциально связанное с тематикой проекта. Ибо твои новые знания втройне окупятся для фирмы.

Больно принципы описанные в статье, и, очевидно, в книге, похожи на законы Дхармы. Быть хорошим программистом сложно! Но интересно.
Еще раз с днем рождения!
От кришнаита и программиста.
Про говорить «нет» — реально ценно, правда чем больше тебе платят тем сложнее это сказать :)
Чем больше тебе платят, тем больше прислушиваются к твоему мнению.
Хотя конечно же всегда есть исключения.
Недавно клиент просить впилить на карту дополнительные виды флажков. Я говорю «нет», объясняю почему, спрашиваю зачем оно надо и предлагаю альтернативное решение. Все счастливы.
А вот донести до человека свою точку зрения — это целое искусство. Бывает, на одно письмо из четырёх строк уходит полчаса.
Не всегда есть возможность сказать "нет", когда заказчик требует необходимый функционал в любом виде, пусть даже с помощью костылей.
P.S.: С днем рождения.
Думаю, такая книга будет полезна как начинающим программистам ( каковым являюсь я), так и опытным.
Александр, Поздравляю Вас С Днем Рождения! Здоровья и удачи Вам во всем.
И если Ваше предложение по книге в силе, то: mikemet@yandex.ru
6. Помогайте и принимайте помощь
Может быть поэтому?!
произведение известное, в рекламе не нуждается
Полагаю так и есть, я слышал о ней, но прочитать руки не доходили. После этого конспекта понял, что книгу всё таки стоит прочитать. Ну и точно есть люди услышавшие о ней в первый раз.
navff с днем рождения )
Если вам предлагают быстрое, но архитектурно слабое решение, ваша обязанность сказать «нет»
Таким образом легко впасть в другую крайность. Заболеть оверинжинирингом. Ваши решения будут супер гибкими, но релиз у вас будет раз в два месяца, а у конкурентов два раза в неделю и вы потеряете клиентов.
Имхо в случае с быстрым и архитектурно слабым решением, ненадо говорить «нет». Нужно найти компромис. Возможно для POC нужно сделать именно так, но обязательно договорится о доп. времени на приведение такого кода в порядок в будущем (тут конечно тоже свои ньюансы...)
В целом легко сказать «нет», но это не отличает проффесионала. Это так же идет в разрез с пунктом ниже о понимании бизнеса клиента и работодателя.
Наша задача — сделать клиенту хорошо. Если я быстро нахреначу ему копипаста с стэковерфлоу, не поняв, как оно работает, в будущем это обернётся большими проблемами.
А вообще, в книге более подробно расписано про «нет» и статья не отражает всего, что написано в оригинале.
Все-же полезно для краткого ознакомления такие статьи. Мне вот интересно. Интересно также и сами мысли после прочтения по поводу книги и около её.
Автора конечно с днюхой.
Спасибо за хорошу статью по правильному распредению времени)Это даже касатеся не только программирования, но и другихотраслей в целом. Картинки доставили。 И самое главное~Поздравляю Вас с Днем Рожденья, Счастья, здоровья, творческих успехов, стабильности и процветания! Пустт все у Вас получится
Я поддерживаю автора статьи, конспекты книг от консультантов очень нужны, так как в них 90% воды, но здравые мысли бывают. Из того, что я читал: "Чистый код", "Рефакторинг", "Шаблоны корпоративных приложений", сейчас больше не вспомню.
Happy birthday . I'll be happy if you send me the book in electrical version:) P.S. I want the book on DC, 12V, 2A. Thanks.
ПУХ… shakandrew
Ну по поводу ночного программирования можно поспорить, уже настолько привык к тому, чтобы кодить ночью, что днём просто нет желания… просто руки не хотят браться за дело.
Так что по-моему это сугубо индивидуальный вопрос.
Не, возможно, где-то в Гугле или МС обеспечивается практически полный эффект присутствия, но наверняка окупается стоимость оборудования для этого хорошо если для топов.
Уже долгое время хочу стать лучше и никак не могу остановиться на этом пути…
С Днём Рождения!!!
С днем рождения. Успехов в работе и жизни. Спасибо за статью!
Пасибо. Норм конспект. Жду продолжения. С днем рождения. Неиссякаемого вдохновения тебе. Моей жене сегодня тоже др.
Каждый кусок кода должен быть протестирован для всех возможных ситуаций. Если это делать вручную, — у вас не будет времени на разработку
Этот человек хоть один автотест написал? Он знает на сколько это трудоемкая задача?
Вообщем, Вы извините, но статья жуткая «вода». Местами уровня папблика вконтакте.
Извиняться перед тестировщиками… Какому мудрецу это вообще могло в голову прийти? Извиняться за то, что нормально? Их профессия, как результат понимания того, что в текущих реалиях без ошибок никак.
Вы же понимаете, что если я до передачи задачи в QA, проверю все возможные тест-кейсы, то после меня эти же кейсы (как минимум) проверят они? Вам не кажется, что это нерационально?
Про стопроцентное покрывание тестами я уже написал, это гиганская работа. По опыту, на написание тестов уходит столько же времения (а то и больше), как на саму фичу.
К тому же, автотесты — не панацея. Как по мне, то они вообще не для этого. Они для того, чтобы программист мог спокойно рефакторить проект. И быстро находить, где и чего он поломал.
Я считаю, мудрый ПМ — это человек, который всегда держит в голове то, что ошибки будут. И выстраивает рабочий процесс, отталкиваясь от этого. Не летает в облаках, не надеется на удачу, не думает, что он сможет заставить программиста писать без ошибок.
Не хочу писать слишком большой комментарий. А так, тут поле не паханное, извините, подобного бреда.
А QA он действительно для другого, он должен проверить что компонент не обрушил нигде функционал неочевидным образом и проверить на разные edge cases.
Не согласен. Грубо говоря, за обрушение части функционала неочевидным образом отвечает Quality часть QA, а вот за то, что реализованная часть функционала работает очевидным (описанным в ТЗ и подобных документах) образом отвечает Acceptance часть.
Не нравится ПМ — у нас свободное общество, где можно менять работу. Ошибки в коде будут, но это исключительная ситуация, когда ваш код не прошёл ваш собственный контроль качества. А если вы пишете в надежде на тестировщиков, — значит вы поступаете непрофессионально.
100% покрытие тестами окупится, когда вам нужно будет изменить что-то в системе. Прогнал тесты и увидел, где сломалось. Если тестов нет, с ростом системы будет расти неуверенность в успехе изменений. Так система превратится в склад устаревшего кода.
Этот человек хоть один автотест написал? Он знает на сколько это трудоемкая задача?
Если вы имеете в виду Роберта Мартина (автора книги), то он написал очень много автотестов, в том числе фреймворк для приемочного тестирования, код которого состоит на 30% из кода тестов. Думаю он знает о чем он говорит. С цитатой которую вы привели я согласен на 200%.
В последний раз при работе в зоне, я казалось поднял с 10% до 80% готовность проекта, а при сборке получил сообщение о неожиданной ошибки и закрытии приложения. Выдвинул и проверил множество теорий, вплоть до ошибки IDE :)
В итоге, на поиск причины ушло непозволительно много времени, а ошибка была весьма глупая, во вложенном цикле делался инкремент к счетчику внешнего цикла, из-за этого данные неверно инициализировались и вообще говорить о дальнейшей работе приложение нет смысла.
Скорей всего этого не случилось, будь я в здравом уме и следил за своими действиями
P.S. С днем рождения (да-да, признаю, этот комментарий здесь только ради этой книги :3 ). Всем добра!
Владимир, С ДНЕМ РОЖДЕНИЯ!!!
Спасибо за конспект. Распечатал некоторые моменты крупным текстом и и расклеил возле рабочего места. С днем рождения, всех благ, удачи, счастья.
С Днём Рождения! ;)
С Днем Рождения!
С Днем Рождения!
Спасибо. Полезно.
С днем рождения! Всех благ и без багов.
<<Рабам нельзя говорить «Нет», а наёмным работникам можно.>>
Прозвучало довольно двояко :)
С днём рожденья!
Интересно.
Спасибо, за хорошую статью. Поздравляю с днем рождения. Желаю развития и творческого вдохновения.
А так во многом откликается, хотя я бы не был столь безапелляционным в высказываниях.
Понятно, что статья — конспект, но все же для меня было бы ценнее услышать насколько это соответствует личному опыту автора с примерами.
А вы не забыли перед тем, как поставить минус посчитать по одному плюсу за остальные пункты, сложить и вывести результат? Я не для оценок пишу, однако, сообщаю на будущее: на подготовку одной такой статьи уходит не меньше 8 часов времени автора + 4 часа времени иллюстратора. Время на прочтение книги не считаю, потому что всё равно бы прочитал.
А ещё, нужно вспомнить, что это конспект книги, а не личное мнение автора. Хотя по части «зона потока — зло», мнение автора статьи совпадает с мнением автора книги.
Я вижу, вы сами пишете на Хабр и, возможно, не помешает немного уважения к другим авторам.
Хороший конспект! Понравился. Со многими вещами абсолютно согласен, остальных просто, наверное, не понял. Нужно углубиться в изучение :)
С днем)
Спасибо за статью и с днем рождения! С удовольствием прочитаю всю книгу
Используют правило «Не навреди». Вашкодтруд должен работать и вы не должны ничего ломать. Конечно, это не каждому под силу, но по мере профессионального роста, количество ошибок в вашемкодетруде будет стремиться к нулю.
Далее про самообучение, работу в коллективе, режим дня, планирование труда, оценка сроков. От врача и математика, до сантехника.
Что касается статьи то статья крайне интересная, было бы вдвойне интересно (для меня как для аналитика) как это можно применить к стадии работы с Заказчиком и проектирования. Все же программистам легче четко оговаривать сроки и условия, поскольку как правило перед ними стоит четкая задача (если исключить те случаи когда программист сам себе аналитик).
И было бы крайне интересно прочесть продолжение)
как это можно применить к стадии работы с Заказчиком и проектирования
Это тип… пару месяцев выясняем требования, пару месяцев проектируем? потом пару недель это кодим, тестируем и по итогу получаем от клиента "это немного не то"?
Все же программистам легче четко оговаривать сроки и условия, поскольку как правило перед ними стоит четкая задача
Программисты должны учавствовать в процессе анализа, поскольку они компетентны говорить "вот это решение будет дорого, но если вот так то дешево". А когда это делают только аналитики, обычно получается не самый оптимальный вариант. Да и фидбэк клиенту проще получать по прототипам каким-нибудь.
С Денриком! Удачи и благополучия!
После прочтения статьи создается впечатление, что идеальный програмист — это такой радужный волшебный единорог. Т.е. его тоже не существует.
Мне вот интересно, когда люди пишут такие книги они учитывают вообще, что каждый программист это живой человек. И, в это трудно поверить, но в своей жизни он не только программирует.
всё это воспринимается с недоумением
Я не понимаю, что именно из вышеперечисленного у взрослого человека должно вызывать недоумение.
Книгу не читал, будет в тему :)
Вот совсем недавно на собственой шкуре понял, что это милое честное пионерское «Я постараюсь» вообще никому добра не делает, а самое неприятное, что в конце концов сам себе оказываешся злым Буратино.
ТС, статья понравилась! С днем рождения, счастья, здоровья, держись там!
От почитателя философии буддизма и начинающего программера C#!
Спасибо за статью!
И да прибудет с автором Нирвана (или хотя бы Самадхи) :)
Очень хороший обзор. С Днём рождения!)
> Используют правило «Не навреди»
Какая-то калька с врачебной клятвы Гиппократа. Причём, мало чем на неё похожая. Что значит «не навреди»? «вы не должны ничего ломать» — вот например ты пишешь робота-парсера, который ходит по сайту ЦБ, и скачивает котировки? Вред? Ну, относительный вред — ведь мы напрягаем серверы ЦБ. ЦБ не загнётся, всё вроде норм. А если это не ЦБ, а какой-нибудь маленький сервачок маленького проекта, с интересной нужной информацией? Ему уже будет вред. Второй пример: ты пришёл к выводу, что надо всё переписывать с нуля. При этом часть функционала потеряется. Это вред? -вред. Твой код сломает что-то? -да, сломает. Правило нарушается? -нарушается.
> Контроль качества не должен ничего найти
Совсем за уши притянуто. Можно месяцы искать в коде ошибки, и выдавать красивый законченный код, а можно отдать код сразу по готовности, и исправить маленькие косяки по мере их обнаружения. Когда задач много, сроки поджимают (не горят, но поджимают), то ты просто не можешь позволить себе тратить много времени на вылизывание кода. (про баланс кода-результата).
Про тестирование примерно то же самое — тесты могут покрывать хоть 100% кода, но это не значит, что код выполняет свою задачу как задумывалось.
> Скромны
Тут какой-то бред. В заголовке говорится «скромны», а в тексте под ним говорится про суровость и обязательное отсутствие чувства юмора.
> Знают свою область
Тоже этот штамп «программист должен писать код в ИТ-отделе». Жизнь меняется, и нужно под неё подстраиваться. Сейчас есть стабильная и очень результативная тенденция иметь своих программистов в каждом отделе. Про это пока не пишут, т.к. все привыкли, что всех программистов надо сажать в одном месте, а всех маркетологов в другом. А когда их садят вместе друг с другом, то отдел маркетологов становится вдруг автоматизированным(программисты автоматизировали маркетинг), а отдел ИТ вдруг продуктивным (маркетологи начали нормально пиарить руководству ИТ-шников).
Автору navff :
> кто поздравит с ДР, тот получит электроверсию книжки в ЛС
А что там с лицензиями? Я надеюсь, вы отправляете лицензионные купленные копии каждому вас поздравившего? Если это не так, то вы становитесь нелегальным распространителем цифрового контента. Вы ведь не зря указали ссылку на озон в самом первом предложении. Получается, вы сейчас пишете: я купил книгу на озоне (за 299р), и делюсь бесплатно с вами на хабре!
Можно много говорить про этику, правильно это или плохо, но награждать не принадлежащим вам контентом(читать — украденным) других людей за какие-либо действия (поздравления в данном случае) — не этично с моей точки зрения.
Некоторые моменты в статье позволили узнать себя, очень интересно было читать. С днём рождения!)))
Ну что ж, спасибо за освещение такой темы. И с днем рождения! Чтоб дела все шли как по маслу — самое главное)
У меня тоже скоро, кстати. Прям под новый год. :D
Правда, в таком состоянии очень просто и легко уйти в over-engineering, но ничего не мешает потом перечитать тонны кода, и поправить, где надо.
Верный признак Зоны, — это когда вы невежливо отвечаете на телефонные звонки и не рады даже хорошим людям.
Вот тут, конечно, надо «включать голову» и держать себя в руках. Так как люди, что ломают твой «поток», конечно, раздражают. Это как любимую кость у собаки начать отнимать — можно остаться покусанным. Или как у наркомана — дозу… В общем, мало кому нравится, когда кайф ломают :) С другой стороны, когда ты отслеживаешь это — бороться с собственным негативом, конечно, легче.
И с днем рождения, да :) Всяческих успехов и роста во всех интересующих сферах :)
Насчёт Зоны потока Мартин не говорил, что это исключительно зло. Он так же приводил пример когда состояние потока уместно — например, когда вы изучаете что-то новое и тренируетесь в этом.
Присоединяюсь к флешмобу :) Владимир, с Днем Рождения! Продолжайте радовать добротными конспектами и да пребудет с вами Сила.
Лучше не просто говорить «нет», а еще объяснить сколько стоить будет «да».
Мы же «профессионалы» и понимаем, что за счет качество можно купить время.
Которым потом расплатимся тем же временем. :-)
—Такое впечатление, что да. Заказчик хочет сферического коня, а коня нет. И привезут только в пятнице, а нужно выкатить версию завтра, потому что выставка, на которую приедет Медведев именно завтра. Так что вместо коня вы ставите заглушку: «тут будет сферический конь».
Жду вторую часть тоже :)
Отличная работа, ждём 2 часть. С днем рождения! И мы не стареем а добавляем + 1 к мудрости. Успехов в начинаниях.
С Днем Рождения! Хороший конспект) Спасибо за старания.
Идеальный программист. Часть 1