/ фото Sistema Bibliotecario Vimercatese CC
Практически каждая крупная организация нанимает в свой штат разработчиков программного обеспечения. При этом только треть из них заняты непосредственно в бизнесе, связанном с ИТ. Но вне зависимости от того, где они работают: в фармацевтической компании, образовательной или рекламной сферах, они остаются программистами.
Работа в команде – ответственное занятие, поскольку в этом случае люди отвечают не только за себя, но и за окружающих, они общаются, помогают друг другу. Как бы это ни было банально, ключом к продуктивному общению между людьми всегда является вежливость и взаимоуважение. Однако все же есть определенный список фраз, которые – даже когда они звучат вежливо и корректно – не стоит употреблять в разговоре с разработчиками и тестировщиками, если вы их коллега, заказчик, «владелец» или руководитель проекта.
1. «Можешь закончить тестирование поскорее?»
Тестирование должно проводиться вдумчиво и тщательно, чтобы не пропустить критичные недоработки. Хорошее тестирование – залог качественного продукта. Разумеется, есть инструменты для ускорения процесса (вот несколько туториалов по автоматизации тестов, предложенные резидентами Stack Exchange), однако, даже автоматизированные тесты приходится поддерживать и постоянно модифицировать.
В идеале тестирование начинается еще на этапе проектирования продукта и продолжается до самого релиза, а дизайнеры и разработчики плотно взаимодействуют с тестировщиками. Если в вашей компании происходит иначе, то, поздравляем, вы узнали рецепт задержек, ошибок и недостатка бюджета (вот еще несколько вещей, которые не любят слышать тестировщики).
2. «У меня нет времени читать баг-репорт, опиши проблему в двух словах»
Тестировщики (по крайней мере, хорошие) тратят много времени и усилий на составление баг-репортов, досконально прописывая все шаги, необходимые для воспроизведения ошибки. Подобное небрежное отношение руководителя или разработчика приводит не только к бесполезной трате времени инженера по тестированию, но и другим серьезным проблемам. Всегда читайте баг-репорты!
Не стоит недооценивать этот совет: однажды я имел неосторожность высказать что-то подобное. На тот момент я был молодым специалистом и не имел особого веса в коллективе. Естественно, я услышал заветные два слова, но не про суть багов, а про себя любимого… На то, чтобы восстановить нормальные отношения с тестировщиком ушло не меньше недели.
3. «Обещай мне, что здесь нет багов»
Роль тестировщика – это не «контроль качества», а «содействие в достижении качества». Задача тестировщика – не проверить, что продукт реализован без ошибок, а убедиться в том, что он удовлетворяет (или не удовлетворяет) определенным требованиям компании.
В бизнесе есть поговорка: «Обещай меньше, делай больше», потому не стоит гнаться за 100% покрытием кода, необходимо сосредотачиваться на качестве проводимых тестов.
Оставьте экстравагантные обещания отделу продаж и маркетинга – пусть они этим занимаются. Тестируйте продукты с привязкой к реальности. Кстати, по теме QA есть несколько подкастов, на которые вам стоит обратить внимание.
4. «Оставь это, я потом сам доделаю»
Эта ошибка встречается сплошь и рядом. Иногда, чтобы завершить задачку побыстрее, вы берете все в свои руки, не ожидая, пока разработчик разберется в проблеме самостоятельно. Мы советуем вам перестать так делать. Старайтесь выступать в качестве наставника и тренируйте специалистов, чтобы их навыки росли вместе с компанией. Иногда это может казаться страшно неудобным, но в перспективе такой подход очень вам поможет.
Хороший лидер отличается, в первую очередь, тем, что способен вырастить себе замену. Если все делать за своих сотрудников, они так ничему и не научатся. Как владелец проекта, вы должны просчитывать ситуацию наперед. Что если завтра я заболею? Если команда может самостоятельно решать проблемы, ничего страшного не произойдет.
Однако важно избегать ситуаций, когда старшие разработчики выступают менторами большого числа джуниоров, из-за чего у них не остается времени на другие задачи. В таких случаях стоит назначить некоего посредника, который бы занимался менторством и обращался к старшим коллегам только по сложным вопросам. Также хорошим решением будет написать собственную документацию и обучающие курсы (здесь вы найдете пару практических советов).
Важно: старайтесь делиться «вкусными» и интересными заданиями с подчиненными. За это они вас полюбят.
5. «У меня небольшой вопрос…»
Фраза не самая удачная. Даже если вопрос действительно окажется коротким, ответ на него таковым может и не быть. Попробуйте поинтересоваться для начала, есть ли у коллеги время (сейчас или в будущем) вам обстоятельно ответить. Дайте собеседнику возможность отказаться от немедленного ответа и выделить для вас свободное время в будущем.
Если дело срочное, то этим правилом можно пренебречь, но старайтесь не поступать так слишком часто. Вы же не хотите стать менеджером, который кричал: «Волки!».
6. «Я пошел домой» (относится к менеджеру проектов)
Если вкратце, то главная задача менеджера проекта заключается в том, чтобы следить за выполнением работ. Когда процесс стопорится, сотрудники опускают руки или переводят стрелки друг на друга за ошибки, в работу вступает PM, который разбирается в ситуации и находит путь для движения вперед.
Важно быть солидарным со своей командой. Проводите с ними время. Разработчики задержались, чтобы поскорее закончить важный проект? Вам тоже стоит быть на месте – не деморализуйте ваших людей. Сила команды в единстве, поддержке и уважении. Не стоит бросать разработчиков на произвол судьбы в трудный момент.
7. «Вот он сделает это быстрее тебя»
Каждый работает со своей скоростью и имеет собственные сильные и слабые стороны. Кто-то выполняет задачи быстро, а кому-то нужно время подумать. Однако стоит понимать, что зачастую скорость – это противоположность качеству и затратам.
Обращайте внимание не на скорость работы, а на способность «предсказывать», сколько времени потребуется на выполнение задачи. Главное – это то, насколько объективно коллега оценивает свои возможности.
8. «Я смотрю, ты уже давно не пишешь код»
В программировании не декларировано количество времени, необходимое для создания строчки кода. Только что написанная функция иногда может требовать время на переосмысление, поэтому если разработчик уже несколько часов ничего не делает, то он не обязательно уснул (такая вероятность есть, но она крайне мала), он может искать информацию на форумах и в справочниках или думать, какие изменения стоит внести в код.
9. «Что ты делаешь целый день?»
Тема, вытекающая из предыдущего пункта. Хороший программист привыкает задавать себе вопрос «Как мне сделать X хорошо?» вместо «Как мне сделать X?». При этом 95% времени разработчика уходит на размышления о том, как надежно внедрить решение и согласовать его с текущей архитектурой. Остальная часть рабочего дня – это написание кода. Ну, иногда, еще пинг-понг и чтение новостных сайтов, таких как Reddit или Хабр.
Если человек уже несколько часов не пишет код, это не означает, что он ничего не делает, скорее всего, он ищет красивое и грамотное решение. Рекомендуем почитать эту статью, в которой рассказывается, почему не стоит оценивать работу программиста только по «внешнему виду».
10. «Эта задачка под силу даже студенту, просто возьми шаблон»
Выдав «студенту» важные задачи, вы рискуете заплатить в два раза больше, если придется все переделывать. По своему опыту мы в 1cloud можем сказать, что разработчиков очень раздражает, когда заказчик или руководитель дает оценку сложности задачи и трудозатрат на разработку, основываясь на своем субъективном опыте. При этом довольно часто руководитель не обладает профильными знаниями в разработке, но пытается навязывать разработчику свою оценку.
В целом стоит избегать любых неаккуратных фраз при оценке сроков и сложности разработки. Например, фраза «Это плевая задача, пара часов максимум...», высказанная самим разработчиком, говорит о том, что задача, скорее всего, действительно будет сделана оперативно.
Если же подобное суждение исходит от менеджера или заказчика, возникает неприятный эффект: разработчику вполне может показаться, что, называя задачу «плевой», заказчик заранее обесценивает его труд. Так что обязательно привлекайте разработчиков и тестировщиков к оценке трудозатрат, не пытайтесь решить за них, как быстро они могут сделать ту или иную работу.
11. «Глянь вот это, надо срочно сделать…»
Работа программиста сравнима с работой людей искусства. Программист сосредотачивается на задаче, как художник, и держит в голове очень сложную картину. Когда вы прерываете его размышления «срочными» делами, он «выпадает» из потока. Согласно исследованиям, чтобы вернуться в состояние концентрации, человеку требуется не менее 15 минут (почитайте статью о том, как работать в потоке), поэтому отвлечение крайне раздражает.
Руководителям стоит попытаться выстроить работу таким образом, чтобы утром выдавать задачи, а вечером – принимать готовый результат, лишний раз не отвлекая команду в середине дня и позволяя каждому трудиться в собственном темпе. Необходимо обеспечить коллегам тишину во время рабочего дня [и речь, скорее, не о гробовом молчании и/или запрете на прослушивание музыки в наушниках, а об отсутствии раздражающих разговоров] – эффективность их труда будет гораздо выше.
12. «Никакого рефакторинга, продукт нужен сегодня!»
Чем больше в коде «костылей», тем меньше он нравится программистам, и тем меньше с ним хочется работать, особенно тогда, когда его не дают переписать. Если не следить за состоянием кодовой базы, «грязи» становится так много, что любые изменения приходится вносить с применением хаков. Это ведет к загниванию проекта.
Работа над кодом напоминает игру «Дженга», когда игроки по очереди достают блоки из основания башни и кладут их на верх, делая башню всё более высокой и все менее устойчивой. Так вот, чтобы башня не упала, требуется время на внесение изменений. Предоставьте команде один день в неделю на рефакторинг, иначе однажды проект придется переписывать с нуля. Рефакторинг способен повысить не только читаемость кода, но и его производительность, что сделает счастливее и ваших клиентов.
13. «Как ты стал разработчиком? Мне бы найти какую-нибудь подработку на лето для племянника/знакомого/и т.д.»
Этот вопрос чаще всего задают люди, имеющие отдаленное представление о создании программных продуктов. Они считают, что современные технологии позволяют написать программу буквально за пару кликов мышки. Да, вспомогательные сервисы упрощают работу программисту, но для неопытного человека популярный фреймворк может показаться [и неизбежно покажется] темным лесом.
По этим причинам найти подработку на лето вряд ли удастся. А вот за 6–7 месяцев, при должном усердии, вполне реально самостоятельно приобрести начальные навыки (с помощью онлайн-курсов, изучения с открытых проектов и так далее), достаточные для работы. Однако это зависит от целевого языка программирования и вакантного места.
Главное – помнить, что работа программиста – не столько профессия, сколько образ жизни. Обучение в университете, самообразование, хобби и, что немаловажно, страсть – ключевые составляющие успеха в этой сфере.
В своей трудовой деятельности мы, пожалуй, столкнулись почти со всеми перечисленными ситуациями. И любая из них может легко выбить разработчика/тестировщика из колеи. Конечно же, бессмысленно «устанавливать запрет» на какие-то слова – важно просто понимать, что вы хотите донести до коллеги, и к каким последствиям такое решение или поступок приведет.
Поэтому в процессе разработки IaaS-провайдера 1cloud мы стремимся к тому, чтобы все специалисты, в том числе и разработчики, обладали довольно большой степенью свободы в проекте и несли ответственность за результат по принятым решениям. Это позволяет менеджерам и разработчикам чувствовать себя одной командой и оперативно решать любые спорные или скользкие моменты в личном общении – когда все сотрудники понимают, что их труд значим, их мнение учитывается, недопонимания в процессе разработки получается избежать – даже если «запретная фраза» и произносится.
P.S. Мы стараемся делиться не только собственным опытом работы над сервисом по предоставлению виртуальной инфраструктуры 1cloud, но и рассказывать о смежных областях знаний в нашем блоге на Хабре. Не забывайте подписываться на обновления, друзья!
Комментарии (42)
bobermai
05.07.2016 12:00+1C точки зрения человека, который пытается быть хорошим PM (и с т.з. PMBoK) п.6 некорректен, а точнее — описывает плохого PM.
Хороший не столько следит за выполнением работ, сколько перед началом работ составляет вменяемый план работ и действия на случаи отклонения от этого плана. Если все внезапно пошло не так, и надо срочно придумывать, что делать — это факап PM'а.
В реальности, конечно, все чуть сложнее и в небольших конторах с т.з. руководства часто PM еще и продажник, тестер, немного тимлид и еще и курьер по совместителству.
ad1Dima
05.07.2016 13:35Пункт про другое. Если у вас дедлайн и разработчикам приходится задержаться, то PM должен задерживаться вместе с ними, в конце концов это его ответственность.
Если не перевру, bobuk вообще предлагал приходить раньше самого первого разраба команды и у ходить позже последнего. Но это как-то перебор.bobermai
05.07.2016 13:51+2Я писал про первую часть, которая некорректно описывает роль PM'а. Если внезапно выясняется, что сдавать проект завтра, а работы осталось по оптимистичным оценкам на три дня — это, естественно, косяк PM'а. Поскольку в проекте протяженностью более недели эта динамика должна быть ясна сильно раньше.
«Приходить раньше первого и уходить после последнего» — это уже что-то из серии «Здесь мерилом работы считают усталость» вместо «Work smart, not hard». Любой член команды должен работать над проектом столько, сколько требуется для его выполнения. Соответственно, пока проект идет по графику — PM уделяет ему столько времени, сколько для этого требуется. Если что-то идет не так — он, естественно, должен потратить больше времени. Но не потому, «чтобы разработчикам не было обидно», а чтобы понять, откуда возникли проблемы, разработать план решения и его реализовать. А то и дизайнера надо заставлять сверхурочно сидеть, несмотря на то, что его работа уже месяц как закончена — иначе программисты обижаются.
terrier
05.07.2016 20:11C точки зрения человека, который пытается быть хорошим PM (и с т.з. PMBoK) п.6 некорректен, а точнее — описывает плохого PM. Хороший не столько следит за выполнением работ, сколько перед началом работ составляет вменяемый план работ и действия на случаи отклонения от этого плана.
Опасное заблужение именно для wannabe-пиэма. PM, конечно же должен составить план, но предполагать, что там прописаны действия на все случаи жизни — опасная наивность. Более того, изменения первоначального плана будут обязательно.
В большинстве компаний PM должен держать руку на пульсе ежедневно и именно что быть готовым импровизировать на ходуbobermai
06.07.2016 11:53Я где-то писал про то, что после написания плана PM самоустраняется? По-моему, я писал только о том, что отклонения должны быть замечены еще до того, как они приводят к серьезным проблемам, и уже на этом этапе предпринимаются корректирующие действия. Для этого, кстати, неамловажен вменяемый фидбек от остальных членов команды. И их понимание того, что желание знать степень готовности задачи — это не придирка «почему так медленно» и не попытка лишить премии, а как раз та самая попытка поиска отклонений.
terrier
06.07.2016 11:57отклонения должны быть замечены еще до того, как они приводят к серьезным проблемам
И именно для этого нужно следить за выполнением работ в ежедневном режиме. При этом понятно, что пытаться прописать в плане все возможные неполадки и подземные стуки неразумно.
NeverIn
12.07.2016 14:10Очень понравилась статья и особенно пункт «в работу вступает PM, который разбирается в ситуации и находит путь для движения вперед.» разгребать конюшни обычно никто не желает.
dmitriylyalyuev
05.07.2016 12:38+3Некоторым ПМ стоит эти фразы на лбу вытатуировать, чтоб в зеркале каждый раз читали.
Спасибо!
oldcastor
05.07.2016 13:43Полезно, логично, спасибо. Вроде очевидные вещи, но опыт позволяет выразить их четко и ясно. Я бы так не смог.
adeptoleg
05.07.2016 13:43+1п.11 Особенно злободневен. А в общем жаль что ситуацию особо изменить сложно так как подавляющие большинство реагирует на проблему только если это касается именно его. [sarcasm_mode_on]Надо бы ивенты какие то с бесплатными печенками проводить где это всё рассказывать по 3 раза на дню, желательно до, вовремя, после и вместо еды[sarcasm_mode_off]
michael_vostrikov
05.07.2016 13:49+1Кто-то выполняет задачи быстро, а кому-то нужно время подумать.
«Я смотрю, ты уже давно не пишешь код»
Я бы добавил, что стоит оценивать не столько сам факт или время работы, сколько результат за некоторое достаточно большое время.
Потому что результат зависит не от одного действия, а от их совокупности. Работать 9 часов с перерывами обычно более продуктивно, чем без них.
Обращайте внимание не на скорость работы, а на способность «предсказывать», сколько времени потребуется на выполнение задачи. Главное – это то, насколько объективно коллега оценивает свои возможности.
Это не всегда работает, надо учитывать контекст. Если программисту дают задачу исправить ошибку в той части приложения, которой он до этого никогда не занимался, он вряд ли сможет дать правильную оценку, разве что наугад сказать.
Pe4enie
05.07.2016 14:33+1Если программисту дают задачу исправить ошибку в той части приложения, которой он до этого никогда не занимался, он вряд ли сможет дать правильную оценку, разве что наугад сказать.
Тогда об этом надо так и сказать — «Я до этого никогда не занимался этой частью проекта, поэтому не смогу дать адекватную оценку трудозатрат на эту задачу». Очень часто бывает, что человек не хочет показаться плохим специалистом и говорит что-то вроде «да ерунда, разберусь, за день сделаю», а результата нет и через месяц.
POPSuL
05.07.2016 16:48А иногда бывает дают задачу "добавить еще один фильтр для поиска", скажешь "ну, уйдет дня три на изучение всего что там написано, ну и +- пол дня на реализацию", а тебе в ответ "да там всего-то одно поле ввода добавить" и ведь никто не имеет представления о том, как внутри устроен поиск, как устроена БД, как устроена программная часть...
У меня вот сейчас примерно такая же ситуация. Один человек пилил проект (очень критичный) год, за неделю до отпуска решили этот проект запустить, запустили, оказалось что там, уж простите, нихуя толком не работает, а мне сейчас это допиливать… И многие думают "да чё там поле ввода добавить", при том, что ни дающие задачи, ни я — не имеют совершенно никакого представления о том как все это работает, и то, какой там говнокод...
samizdam
05.07.2016 18:42А бывает подзабудешь какую-нибудь часть системы, в которую год никто не заглядывал…
И берёшь задачу с чувством, что день-то точно потратишь пока разберёшься куда впилить, и возможно ли вообще, или придётся переписывать килобайты кода…
Ан-нет, оказывается тестами эта часть была покрыта хорошо, open-closed соблюдён, задел на расширяемость уже есть. один интерфейсик заимплементил за часик, и всё само зафурчало. Красота.
michael_vostrikov
05.07.2016 18:06Все так, мне просто подумалось, что какой-нибудь менеджер начитается таких советов и будет на основе них принимать решение, кого из новых разработчиков оставить после испытательного срока. Новые работники обычно не уточняют, что раньше не занимались проектом, это и так подразумевается.
niklisto
06.07.2016 11:54Программеры чаще всего так и говорят. А вот реальный ответ на такую фразу одного из директоров довольно крупной компании: «Что значит не можешь? В этих процедурах что, select'ы другие какие-то? Делай давай! Быстро!»
punkkk
05.07.2016 17:21+1Никогда не задумывался особо на счет подобных фраз, но вообще и впрямь жизненно. Теперь немного неловко за некоторые моменты общения с тестировщиками, но теперь буду знать, спасибо.
Am0ralist
05.07.2016 20:09Вот только иногда разработчики не начинают исправлять ошибки, пока их конкретно носом не тыкнешь в то, что это ДЕЙСТВИТЕЛЬНО делается быстро.
Из примера — нам поставили какую-то стороннюю многометровую либу для печати HTML, которая не корректно работала на одном XP. Я за несколько часов набросал свой вариант решения, после того, как разрабы отказались делать сами что-либо (причем ссылались на ТЗ, за что мне пришлось их еще тыкать, что в ТЗ XP — прописан).
В результате, через день-два после небольшого перебранки в почте — я продемонстрировал свой exe на с++, наше руководство прописало им живительных люлей, после чего они таки взяли и написали все сами, при этом заодно заново собрав все шишки, которые по пути выявились, вместо того, чтоб взять использовать готовое.
Другой пример, что в другой компании до сих пор баг с тем, что они не обнуляют переменные перед повторными расчетами. Суть в том, что два разных материала могут зависеть друг от друга, причем увеличение одного уменьшает другой. Естественно, что количество не может быть отрицательным, поэтому в этом случае его обнуляют. Только явно тем, что суммируют с тем же числом, противоположным по знаку. После чего, если ты уменьшаешь первый материал, то второй начинает увеличиваться уже от нуля, то есть он продолжает суммироваться с числом, равным по значению предыдущему округлению. Ошибки полтора года. Меня никто не убедит, что это — гигантское количество времени на исправление.
Так что да, заказчикам иногда приходится указывать программистам, что некоторые моменты — делаются действительно быстро.
playnet
05.07.2016 21:51+1После фразы «Обучение в университете» стал искать тег «перевод». Чтобы стать хорошим программистом, университет не нужен, там максимум «учат учиться». А необходимо — желание и стремление научиться, чему всякие курсы помогут.
Fedcomp
06.07.2016 11:05по мне так наоборот курсы дают быстрый старт, но в итоге разработчик не знает откуда «курс это узнал». Т.е разработчику дали знания но не сказали где искать новые, а так как он их находил не сам то он тоже не знает.
Muxto
06.07.2016 13:56Согласен.
Нормальный (сознательно не говорю — хороший) программист обязан знать курс «Архитектура ЭВМ», «Операционные системы», «Основы вычислительных сетей», «Базы данных», и хорошо бы еще теорию компиляторов.
Иначе это не разработчик, а непонятно кто, с кашей в голове.
Siper
07.07.2016 11:49Это как минимум. Хорошо бы уметь грамотно составлять требования и техническую документацию, понимать методологии разработки и тестирования, правовые аспекты, уметь планировать проекты, читать документацию на англ языке, знать основные алгоритмы и структуры данных, ОО-дизайн и параллельное программирование. Всему этому в обязательном порядке учат в российских университетах последние лет 20 точно, а также многим другим фундаметальным вещам которые нужны пусть не всем, но необходимы топовым программистам/архитекторам.
Fedcomp
08.07.2016 11:37Мне кажется это уже на сеньора тянет.
Siper
08.07.2016 22:32Это Junior, ибо все что я перечислил выше — это лишь теоретические знания)
Senior приходит с опытом практического проектирования, работы в команде, знаниями среды, фреймфорков, систем контроля версий. А также способностью адекватно взаимодействовать с менджментом (напрямую, а не через другого Senior'а). Соответсвенно Senior'а подготовить в университете увы никак не получится.
121212121
05.07.2016 22:02+1Все эти вещи не нужно говорить и дизайнерам, и верстальщикам… да кому угодно.
Зависит от того, кто будет автором статьи.
CTAPOBEP
06.07.2016 11:41+1Хорошая статья. Жаль, что такие статьи никто кроме программистов не читает.
Ckomop0x
06.07.2016 14:01Отличная статья, спасибо! Добавил в закладки, чтобы можно было делиться ссылкой, когда начинают задавать подобные вопросы.
diagonal
06.07.2016 15:10+3Добавлю личную историю к пункту №8.
Много лет назад я работала в филиале одной крупной международной компании. Наш отдел делал программный продукт, который на то время был самым сильным в своей области. Его интерфейс был чуть лучше текстового, а опции чуть более продвинутые, чем базовые, включались setenv-ами. Этот интерфейс возник лет за десять до описываемых событий, когда один исследователь решил поковыряться в этой области, и с тех пор не сильно изменился.
Однажды начальству пришло в голову, что неплохо бы сделать нормальный GUI. Эту работу поручили мне. До этого я интерфейсы никогда не разрабатывала. Зато я была прекрасно знакома с программой, в т. ч. как пользователь, и у меня была сильная вера в свои силы.
Я составила список опций базовых/ продвинутых/ очень продвинутых. Опции искала grep-ом в коде, нашла более 200, опросила разработчиков компонент по поводу незнакомых. Долго рисовала эскизы GUI, придумывала визуализацию логов. Потом я пыталась получить мнение членов отдела о моем проекте GUI.
Где-то через неделю после напряженной работы начальник спросил меня:
— Как, ты еще не написала ни строчки кода?
foxmuldercp
15.07.2016 11:02Я пишу панель управления хостингом, основанную на идее контейнеризации, собрав косяки двух топовых платных и нескольких бесплатных панелей управления хостингом в боевом использовании за несколько лет от технической поддержки до хостмастера.
Так вот, я потратил вечера нескольких месяцев, чтобы написать только скриптовую часть, на полгода вообще эту задачу выбросил из головы, и только через полгода я засел за теорию, планирование ТЗ и функционала панели. Обрисовал несколько блокнотов, и только этой зимой сел за RoR и начал писать саму панель управления.
indestructable
Спасибо, хорошая статья. О мелочах, которые сам человек не замечает, но которые могут сильно раздражать окружающих.
1cloud
Стараемся обращать внимание на мелочи :)
sajtpro
дьявол как раз скрывается в мелочах.
il--ya
Интересно, за что минусы? Кому-то почудилось тут возражение?
Идиоматическое выражение "The devil is in details" означает лишь, что мелочи имеют большое значение.
sajtpro
Это волновые минусаторы. Один ставит минус, другой ставит потому что, кто то уже поставил.
Mithgol
Мрачно подозреваю, что это антиклерикалисты.