Убей в себе IT-шника
13/9/11 16:29![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenПридумал доклад-статью. Мыслей крутилось много, но как начал записывать - они куда-то схлынули, осталось немного флуда.
Коллеги, Вы замечали неудачные паттерны мышления, свойственные в основном айтишникам? Типа неспособности ориентироваться в нечёткой логике.
Если можно, с примерами и своими соображениями :) А я вас в докладе использую :)
Под катом мои соображения.
Конечно, способ складывать 2 и 2 существует только один. Не существует даже таких технических вещей, как “единственно правильный” язык программирования, фотоаппарат, автомобиль. И уж тем более не бывает единственно правильного устройства таких гуманитарных конструкций, как работа, бизнес, человеческое общество.
Яркий пример - какой-то IT-шник на политическом форуме высокомерно заявил о человеческом обществе: “Возможно построить надёжную систему из ненадёжных элементов - читайте фон Неймана”. Сам он его если и читал, то явно не понял. Из ненадёжных элементов, может, и можно - если эти элементы не анализируют саму систему, не выискивают в ней слабину и не занимаются активным противодействием.
Interactions over processes and tools. Почему так сказали? Потому, что люди а) должны помогать друг другу выполнять обязанности, и б) зоны ответственности должны перекрываться. В ситуации “Ты не сделал отчёт”, например, следует сказать “Я не напомнил тебе сделать отчёт”.
Если Вам нужно абсолютно чёткое разделение ответственности - значит, у вас конфликт вроде “- Ты не то делаешь! - Нет, это ты не то делаешь!”. Значит, у вас неэффективный контакт с коллегой/ заказчиком/ начальством, вам нужна какая-то документально закреплённая защита.
Может статься, что инструкцию напишут. И тут оказывается, что по инструкции Вы отвечаете за примерно в пять раз большую зону, чем Вам сейчас кажется. Скажем, за покрытие тестами. А как его сделать, если времени на тесты не дают? Идиотская инструкция! Неправильная!
Корень проблемы - в том, что автору инструкции (архитектору заказчика, например) и правда нужна такая метрика, но цену её достижения он не коммуницировал, потому что не продумал - или потому, что за человеко-часы он вообще не отвечает. А тот, кто отвечает, конечно, не заинтересован выделять людей, у него план горит.
Твитнуто Фаулером: There is an (unfortunate) belief that testers test, programmers code, and the separation of the two disciplines is important.
Документация всех спасёт. Аналитик должен делать правильные документы/(требования), тогда программисту всё будет понятно.
Миф происходит из 1) нежелания вступать в общение, 2) желания переложить ответственность на другого (мы всё делаем, как вы сказали!)
Никто и никогда не может дать полных и непротиворечивых требований на мало-мальски нетривиальную систему.
Порой понять, что от вас хотят, можно только долго общаясь об этом. Фиксируя знания и решения в документации, конечно. Но документация - это не главный инструмент, это - блокнот для памяти. Главный результат - понимание - рождается в общении. Документация - однородный документ, по нему не видно, что для заказчика важно, а что нет. Часто он сам этого не понимает.
Если Вы хотите общаться только через документы - значит, Вы не доверяете партнёру. Значит, Вы хотите ему сказать не “Вот, мы наконец вместе поняли, что тебе нужно”, а “Смотри, зараза, ты же мне сам вот это написал - получай!”. И будете тратить усилия на то, чтобы защититься от него, то есть усугублять недоверие и провоцировать дальнейшие конфликты.
Считает, что если он понял некий общий принцип, то понял всю дисциплину - например, изучил новый фреймворк. “Всё понятно, это как Rails, только на Java”.
И ещё считает возможным поучать других с высоты своего космического понимания. Если он довольно логичен и проворно пользуется гуглом, то такого “Гуглоневежду” бывает довольно трудно уличить в незнании. Помогает прямой вопрос - а что сделал ты.
В то время, как devil in details. “Принципы” - это только модели, а на практике важны различия между моделями и реальностью. “Теоретически, между теорией и практикой нет разницы; на практике, она есть”.
Это частный случай проблемы талантливого ребёнка - он с детства привык, что у него всё получается легко, с пол-пинка, и потом, если что-то получаться перестаёт, он начинает искать проблему в чём угодно - в коде программы, её архитектуре, операционной системе, "этой стране" - только не в себе.
Коллеги, Вы замечали неудачные паттерны мышления, свойственные в основном айтишникам? Типа неспособности ориентироваться в нечёткой логике.
Если можно, с примерами и своими соображениями :) А я вас в докладе использую :)
Под катом мои соображения.
Существует “правильный” способ делать что угодно
Конечно, способ складывать 2 и 2 существует только один. Не существует даже таких технических вещей, как “единственно правильный” язык программирования, фотоаппарат, автомобиль. И уж тем более не бывает единственно правильного устройства таких гуманитарных конструкций, как работа, бизнес, человеческое общество.
Яркий пример - какой-то IT-шник на политическом форуме высокомерно заявил о человеческом обществе: “Возможно построить надёжную систему из ненадёжных элементов - читайте фон Неймана”. Сам он его если и читал, то явно не понял. Из ненадёжных элементов, может, и можно - если эти элементы не анализируют саму систему, не выискивают в ней слабину и не занимаются активным противодействием.
Если прописать процесс с чётким разделением обязанностей, все будут делать то, что надо
Interactions over processes and tools. Почему так сказали? Потому, что люди а) должны помогать друг другу выполнять обязанности, и б) зоны ответственности должны перекрываться. В ситуации “Ты не сделал отчёт”, например, следует сказать “Я не напомнил тебе сделать отчёт”.
Если Вам нужно абсолютно чёткое разделение ответственности - значит, у вас конфликт вроде “- Ты не то делаешь! - Нет, это ты не то делаешь!”. Значит, у вас неэффективный контакт с коллегой/ заказчиком/ начальством, вам нужна какая-то документально закреплённая защита.
Может статься, что инструкцию напишут. И тут оказывается, что по инструкции Вы отвечаете за примерно в пять раз большую зону, чем Вам сейчас кажется. Скажем, за покрытие тестами. А как его сделать, если времени на тесты не дают? Идиотская инструкция! Неправильная!
Корень проблемы - в том, что автору инструкции (архитектору заказчика, например) и правда нужна такая метрика, но цену её достижения он не коммуницировал, потому что не продумал - или потому, что за человеко-часы он вообще не отвечает. А тот, кто отвечает, конечно, не заинтересован выделять людей, у него план горит.
Твитнуто Фаулером: There is an (unfortunate) belief that testers test, programmers code, and the separation of the two disciplines is important.
Документация всех спасёт. Аналитик должен делать правильные документы/(требования), тогда программисту всё будет понятно.
Миф происходит из 1) нежелания вступать в общение, 2) желания переложить ответственность на другого (мы всё делаем, как вы сказали!)
Никто и никогда не может дать полных и непротиворечивых требований на мало-мальски нетривиальную систему.
Порой понять, что от вас хотят, можно только долго общаясь об этом. Фиксируя знания и решения в документации, конечно. Но документация - это не главный инструмент, это - блокнот для памяти. Главный результат - понимание - рождается в общении. Документация - однородный документ, по нему не видно, что для заказчика важно, а что нет. Часто он сам этого не понимает.
Если Вы хотите общаться только через документы - значит, Вы не доверяете партнёру. Значит, Вы хотите ему сказать не “Вот, мы наконец вместе поняли, что тебе нужно”, а “Смотри, зараза, ты же мне сам вот это написал - получай!”. И будете тратить усилия на то, чтобы защититься от него, то есть усугублять недоверие и провоцировать дальнейшие конфликты.
Синдром всезнайки
Считает, что если он понял некий общий принцип, то понял всю дисциплину - например, изучил новый фреймворк. “Всё понятно, это как Rails, только на Java”.
И ещё считает возможным поучать других с высоты своего космического понимания. Если он довольно логичен и проворно пользуется гуглом, то такого “Гуглоневежду” бывает довольно трудно уличить в незнании. Помогает прямой вопрос - а что сделал ты.
В то время, как devil in details. “Принципы” - это только модели, а на практике важны различия между моделями и реальностью. “Теоретически, между теорией и практикой нет разницы; на практике, она есть”.
Это частный случай проблемы талантливого ребёнка - он с детства привык, что у него всё получается легко, с пол-пинка, и потом, если что-то получаться перестаёт, он начинает искать проблему в чём угодно - в коде программы, её архитектуре, операционной системе, "этой стране" - только не в себе.
Tags:
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
13/9/11 13:43 (UTC)Но, с другой стороны, стоит отметить что отчасти именно благодаря таким образу мышления и поведения наша индустрия достаточно быстро прогрессирует.
(no subject)
13/9/11 13:47 (UTC)Более того, математики, которые всё же учёные, привыкли сомневаться в своих словах. У айтишников и с этим проблемы %)
Хехе, "Кризис внимания - двигатель прогресса!"
(no subject)
13/9/11 13:49 (UTC)(no subject)
13/9/11 13:50 (UTC)(no subject)
13/9/11 13:51 (UTC)(no subject)
13/9/11 13:53 (UTC)(no subject)
13/9/11 19:40 (UTC)Убивает напрочь желание подумать, прежде чем сделать. В итоге — код пояляется по строчке в минуту, при нереальном количестве прогонов/тестов.
“Не трогай” — неплохой принцип, но во мне еще жив немного математик, и я примерно 50/50 трогаю или нет :)
Более общий пример — “я лучше сделаю это сам, чем возьму готовое и допилю”. Зависимость потерь имеет степенную зависимость от сложности задачи, а порой и приводит к краху.
В том направлении изыски?
(no subject)
13/9/11 21:29 (UTC)(no subject)
13/9/11 21:31 (UTC)(no subject)
14/9/11 06:59 (UTC)Ну, почему для создания чего-либо мало-мальски сложного человечество использует проектный подход? Почему не избрело ничего более эффективного и работающего.
Адепты принципа приводят аргументы в пользу проектного подхода. Эти аргументы - Опенгеймер и Koroliov. Вы бы еще начальника стройки египедских пирамид вспомнили. Эти примеры говорят о том, что проектный подход работает только в условиях приближенным к боевым. Когда ты участников загоняешь в проект насильно и имеешь полную власть над ними. Но что делать нам, детям мира и цветов?
В современном мире, где будущее уже наступило, проекты со сроком реализации первой фазы (получение первых результатов) больше полугода - обречены. За это время изменятся требования, а инструменты реализации устареют. Если с первой фазой в полгода укладываемся, то дальнейшие фазы - можно смело выбрасывать.
(no subject)
14/9/11 06:59 (UTC)http://mapm.livejournal.com/427833.html
(no subject)
14/9/11 08:13 (UTC)Да и проектный подход вполне работает, чтобы недалеко ходить - у "Эппла" или, скажем, у Шаттлворта с Убунтой.
(no subject)
14/9/11 08:20 (UTC)характерное заявление: "вот мы были разрабатывали систему, а она оказалась такой сложной, давайте сделаем новый проект максимально простым, а TDD, или методологии юзабилити, или шаблоны С++ оставим другим (пусть они набивают себе шышки)". или "вот мы досканально знаем о триггерах в sybase sql, а TDD, принципы юзабилити, шаблоны с++ -- это просто мода" или "мы это уже проходили: изучаешь что-то новое, а потом она перестает употреблятся, лучше мы уж только досканально проверенное будем использовать".
как результат: используются проверенные методики/средства/среды/библиотеки -- т.е. уже очень сильно устаревшие и скорее всего достаточно плохого качества. и далее, создание этакого болотца где все тихо и спокойно, а те жабы, которые квакают не так, просто выпровождаются в другие места.
разработчики действительно разрабатывали сложный проект, но как в анекдоте "--и ребенок у вас один?" ("--пробовал курить, выкурил одну сигарету и мне не понравилось, пробовал пить выпил одну бутылку спиртного и мне не понравилось ..") и потерпели фиаско, поэтому "рисковать" больше такие разработчики не хотят. хотя фактически, неудачи случаются по разным причинам, а вот нежелание изучать новые технологии подходы оно эээ просто от лени. ну лень разработчикам изучать новое, пробовать эксперементировать, набивать шышки, но и находить новые подходы -- "а зачем, если и так все хорошо".
(no subject)
14/9/11 10:15 (UTC)(no subject)
16/9/11 20:48 (UTC)навіть не в мене одного.
звичані люди не розуміють нечітку логіку, хоча нею нібито і користуються,
тому з ними дуже важко спілкуватися.
і ще гірше - гора ресурсу йде і марно:
більше затрати - більше виглядаю ідіотом, що логічно.
(хоча вигідно здаватися придурком, якщо час не тисне)
(no subject)
18/9/11 12:48 (UTC)Это слабая коммуникационная функция :) Я в один момент понял, что надо сообщать не точный факт, а подавать его в понятных собеседнику терминах. Плюс надо привыкнуть разговаривать привычными обычным людям паттернами :D
(no subject)
20/9/11 04:41 (UTC)мій імператив:
існування квантифікаторів "точно", "абсолютно" і т.п.
доводить, що будь-яка фраза - нечітка за замовчуванням.
люди не готові чекати прикидку, аби почути "не знаю, 30% что да",
вони вже на перших літерах кидають "ти што тупак?"
ця фраза звісна така сама нечітка, як і решта людських фраз -
десь на 4/5 істиності у десь 4/5 ситуацій %)
з людьми важко спілкуватись, а мабуть і не варто.
(no subject)
20/9/11 09:04 (UTC)Тут много чего надо участь. Например, такую, вроде, постороннюю вещь, как ранговый потенциал. Если поднять свой ранг, то от тебя сразу начнут хавать то, что раньше не хавали, иногда даже полный бред :D
(no subject)
4/3/12 12:43 (UTC)2) Инженерный рефлекс, на базе опыта: если что-то сделать нетак, плохо, оно или сломается или будет масировано мешать. По этому внутреннее чувство достоверности и надёжности/халтурности, которое мешает воспринимать поведение окружающих и нетехничных сфер, строящееся от прокида или просто лжи.