×Закрыть

Стиль мышления «да щас по-быстрому разберёмся» vs. «так, надо основательно разобраться»

Вы когда-нибудь сталкивались с тем, что у вас стиль мышления один, а в команде преобладает другой?

Например, вы предпочитаете делать всё тщательно и надёжно, с полным пониманием и контролем того, что и как работает, а ваш коллега — шустрый «ковбой», который всегда готов по-быстрому всё сделать а потом по-быстрому всё пофиксить (а фиксить будет что).
Или наоборот, вы «ковбой», а ваш коллега неторопливый и аккуратный «зануда».

Пробовали освоить другой стиль мышления так, чтобы получилось эффективно в нём работать?
Или прийти из своей любимой крайности к идеальной середине.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

делегируй (ц)

не умеешь в тяп-ляп, а надо — отдай задачу «ковбою», потом до ума доведешь.
не умеешь в основательно сделать — отдай «зануде»

Будет лучше, если тот, кто тяп-лям будет делать еще быстрее, а тот кто делает медленно и качественно будет делать еще качественнее — тогда останется только набрать в команду и тех и других и они будут дополнять друг друга. Веселуха начинается, когда кастомер прямым текстом говорит, что ему нужны только тяп-ляпчики

Середини не існує? Коли робиться швидко те що можна швидко, або коли обєктивно треба швидко, і якісно, коли є можливість чи необхідність робити якісно. Така собі оптимізація, але і не тяп ляп.

я предлагаю определить свои сильные стороны и развивать их. Конечно можно балансировать — лишь бы не остаться середнячком, делая задачи недостаточно быстро и при этом недостаточно качественно

Може й так. Я пропонував якраз таки розвиватися щоб було вміння робити якісно, але також розуміти потреби, коли варто відрізати речі які не так критичні і зробити швидше, при необхідності.

полфичи задеплоенно, правда, с багами.
полфичи даже близко не готово,разраб обещает закончить в следующем месяце.
заказчик ебёт всех.
FIN

Не будут, проект развалится в течение года, если одна группа не исключит другую

Интересная тема. Но мне кажется подобный вопрос может возникать только для небольших задач в которых понятно с чего начать и весь ход. Я считаю что сам думаю быстро, но обычно долго обкатываю задачу в голове (иногда месяцами), варианты решения, структуры данных, и возможные проблемы. Если участок не вызывает вопросов в решаемости, то это уже даже не интересно. Тут можно садиться и писать. Или кому-то поручить. Улучшения уже по ходу. В зависимости от времени и необходимости. Торопыги в серьезных задачах обычно в пролете. Выход (если вообще он состоится) получается недостойного качества.

Приходится довольно часто переключаться между двумя подходами :)
А критерий довольно простой — если задача на раз, то понятное дело, что надо кяух-каях.
Если же планируется надолго ... то сначала обычно тоже кяух-каях (но с вдумчивыми комментариями к коммитам), а потом — рефакторинг. Не только потому, что надабыстра, но и потому, что часто задача уточнятся в процессе решения.

Это самое что ни на есть по-быстрому

Это самое что ни на есть по-быстрому

Если «по-быстрому» понимать буквально.
Вот только где сейчас в ИТ бывает по-медленному в таком понимании?

есть проекты, на которых хотят качество, а не абы быстрее

Да, например у Ле(б)ледева — «долго, дорого, охуенно».
Правда — если верить Тинькову — выходит «долго и ахуенно дорого»

Те рабочие отношения, которые у нас пропагандируются как «западные» и «прогрессивные», предполагают отсутствие личной и присутствие командной ответственности. Согласитесь, вокруг Вас никогда никто не станет выяснять, сколько кто произвел багов. Просто записи в Джире.
Отсюда следует, что тот, кто делает «ща по-быстрому», со всех сторон в плюсе: он успел к сроку, менеджер им доволен, у него всегда есть, что рапортовать (чуть-чуть кода и много багфикса).
А Вы — всегда в минусе: в срок не успеваете (потому что покер плэнинг решил, что Вы справитесь за 60% времени), комитов мало. А если еще и на галере, то Вас просто сожрут, потому что клиенту не забилишь весь тот багфикс.
Переходите в продукт (не стартап). Там Ваши качества оценят выше. Я, например, от 10% до 30% времени, которое уходит на новую функциональность, трачу под будущее использование компонентов. Потом просто сидишь и наслаждаешься, как «неожиданно» возникшие запросы, быстро решаются при помощи «а что, тут и такое уже есть?!» Уже не знаю, сколько человеко-месяцев это помогло сэкономить.
Правда, особо в деньгах это не отражается ))) Но недовольных нет.

Те, кто планируют — тащатся от своих способностей «предвидеть». Как раз они все запутывают на проекте. Дело в том, что в квантово-механической вселенной не существует точных значений, только приблизительные, только вероятностные.

Вы говорите, судя по всему, об аутсорсе, где у клиентов одни требования. Я говорю о продукте, где все расписано на полгода-год вперед, и требования немного другие. Топикстартеру советовал или грести, укрепляя молодежный дух команды, не выбиваясь из модного тренда, или переходить в продукт, где он сможет получать моральное удовлетворение от хорошо проделанной работы.

ух, ты. хочу в продукт, где расписано на полгода-год вперед и не меняется совсем неожиданно

Значит, мне повезло с двумя.

воу, есть один вариант. правда, надо будет менять специализацию и эммигрировать, но это ж того стоит!

но это ж того стоит!

Слова «Я працюю в НАСА» будь кого заворожують

Секурити чек не пройдешь.
Или пройдешь лет через 10 после паспорта.
Всегда умиляют фразы типа «иди в НАСА».

Я говорю о продукте, где все расписано на полгода-год вперед, и требования немного другие.

и что делают в продукте когда расписания на полгода-год начинают не совпадать с реальностью а требования #внезапно расплываться кстати вы об каких «требованиях» речь?

ЗЫ: из свежих требований департамента кадров самого что ни на есть «продукта»

— Experience with one or more general purpose programming languages including but not limited to: C/C++, C#, Python, JavaScript, Java, Go, Objective-C and/or Swift.
— Knowledge of Django or similar web frameworks, AWS Lambda, and RDBMS

... я так подозреваю последнюю строчку уже попизже дописали слегка разочаровавшись видимо в «требованиях» соотв. одной первой только ))

что делают в продукте когда расписания на полгода-год начинают не совпадать с реальностью а требования #внезапно расплываться

По-моему, это означает, что продукт (или нововведения в продукте) сильно опоздал на рынок. Или поторопился. Обычно это случается в стартапах, в которые нужно идти только(!) ради денег и забить на все свои принципы.
В таком случае нет смысла, конечно, продолжать. Думаю, бизнес и так потеряет кучу денег. Наверное, каких-то аналитиков и менеджеров лишат премии.
Я же не говорю, что разработчик, стремясь делать все так, чтобы ему самому нравилось, не успевал. Он должен давать реальные эстимейты. И, конечно, не быть последним, на кого все свалят. Все начинается с идеи (или потребностей пользователей) и анализа рынка. Разработчик — такой же ресурс, как кредитная линия. Можно получить ее «за углом» под грабительские проценты. Зато без лишних вопросов. А можно подготовить бизнес-план, нанять консультантов и получить дешевый кредит.
Есть разные проекты. Под любой склад характера у разработчика )

у тебя довольно пространные представления за «продукт» чувак ))

Он должен давать реальные эстимейты.

и за процессы разработки «продукта» тоже ))

По-моему, это означает, что продукт (или нововведения в продукте) сильно опоздал на рынок. Или поторопился. Обычно это случается в стартапах, в которые нужно идти только(!) ради денег и забить на все свои принципы.

Нашему продукту 20 лет устойчивого роста. Такие ситуации с перепланированием происходят постоянно, но затрагивает каждая не более где-то 1/20 от всего продукта, обычно меньше.

Список требований — какой-то random. :-)

а как по-вашему выглядит «список требований на вакансию software engineer продуктовой компании»? )) или как вообще по-вашему выглядит «software engineering в продуктовой компании» вообще? ))

Количество разнонаправленных технологий — как правило заметно меньше.
Соседство C# и Java — это всегда выглядит странно. Соседство C++ и Java — тоже странноватое, хотя в принципе реалистично. Python + Java — ну, может быть.
Но когда все 4 вместе — это что за нафиг вообще? :-))
Ещё и Go туда, чтобы совсем нескучно было. Наверное, стали пробовать перейти на микросервисы, по принципу «кто в лес, кто по дрова». :-))

Или там адское legacy с зоопарком технологий, или текст вакансии составляли не технические люди с проекта, а девочка-рекрутёр, которая просто знает набор ключевых слов.

JS и Swift — OK, веб-морда и мобильный клиент, принимается. Но вообще-то заниматься этим всем будет не один человек. Ведь не один же, там же команда сидит, а то и не одна, или как? Или там не в меру эффективный менеджер считает, что «ты ж программист», и всё это навешают на одного человека?

адское legacy с зоопарком технологий
текст вакансии составляли не технические люди с проекта
Ведь не один же, там же команда сидит, а то и не одна, или как?

=>

как вообще по-вашему выглядит «software engineering в продуктовой компании» вообще?
как вообще по-вашему выглядит «software engineering в продуктовой компании» вообще?

Там сидите вы. Пишете на C#, Java, Go, JS, C++ одновременно. Делаете всё очень быстро. Каждый язык вы освоили за пару выходных.
Однажды вы решили найти себе коллег, чтобы у вас была команда, — и вас искренне удивляет: «В смысле? Чего они все — кто на Java, кто на Python, почти каждый знает не больше 2-3 языков, и многие даже не full-stack. А когда им говоришь разобраться за выходные с очередной технологией, они как-то напрягаются, — что с ними всеми не так?».
:-))

Там сидите вы.

да нет мы как раз вольнонаёмный приходящий эксперт по подписке который приходит и видит код си++ написанный на джаваскрипт но на то он и эксперт чтобы помнить ещё старинное «программист на фортран может писать на любом языке как на фортран» (к) (тм)

они как-то напрягаются

так что мы как раз не напрягаемся по крайней мере здесь ))

но «несколько напрягаемся» ржучи до коликов в животе и попе когда приходит очередной чудо и начинает заливать за «эльфийский продукт против бездуховного аутсорса».

потому и спрашиваю прямо хотя скорее риторически

как вообще по-вашему выглядит «software engineering в продуктовой компании» вообще?

Я работаю в аутсорсе. Что там в продуктовых — могу только представлять, как было бы хорошо, или вспоминать небольшой кусок прошлого, как там было чёрт знает что.

и что делают в продукте когда расписания на полгода-год начинают не совпадать с реальностью

плачут. работают по выходным.

и что делают в продукте когда расписания на полгода-год начинают не совпадать с реальностью а требования #внезапно расплываться

Перепланируют?

ЗЫ: из свежих требований департамента кадров самого что ни на есть «продукта»

«Имя, сестра, имя!»

«Имя, сестра, имя!»

имя им легион! (к) (тм)

Так запутывают, что аж делают один мерж в мастер, все зелененькое и идут пить пиво, вместо того, чтобы бегать с полыхающей жопой, как нормальные люди.

Я, например, от 10% до 30% времени, которое уходит на новую функциональность, трачу под будущее использование компонентов. Потом просто сидишь и наслаждаешься, как «неожиданно» возникшие запросы, быстро решаются при помощи «а что, тут и такое уже есть?!» Уже не знаю, сколько человеко-месяцев это помогло сэкономить.

Это помогло сэкономить время именно вам, индивидуально, потому что решения свои вы не документируете (или документируете?), а ваш ход мыслей может сильно отличаться от хода мыслей другого человека.
Он придумал бы всё по-другому.
То есть если вы не документируете код, который для вас (и только для вас) является sefl-explanatory, то другой человек потратит много сил и времени, чтобы понять ваш ход мыслей, чтобы на основе ваших наработок сделать всё в рамках тех же идей.
Или сделает по-своему, а следующий сделает ещё по-своему, что приумножит хаос в проекте.

Стараюсь писать документацию с примерами по основным решениям. В остальном я и остальные, кто что-то придумывает, пишем в том стиле, который уже де-факто сложился вокруг Реакта. Поэтому, даже если кто-то видит наш проект в первый раз, уже через неделю свободно использует наши наработки.
Я говорю о готовом компоненте или библиотеке. Тому, кто это использует, крайне редко понадобится лезть во внутренности. У него будет апи. Хочет — использует. Не хочет — пытается потратить деньги заказчика на свой дубликат, за что бывает порицаем.
Опять же. В аутсорсе стремятся, чтобы все знали систему полностью. Сегодня Вы метод модифицируете. Завтра — Вася пришел и все переделал. В продукте стараются удержать инженера, который лучше знает свою часть системы, а, значит, может эффективнее ее менять при необходимости.
Еще лучше, если Вы будете единственным, кто определяет, как будут выглядеть внутренности проекта. Проще найти такой проект, чем пытаться ужиться с несовпадающей командой.
Никто не говорит, что Вы мыслите неправильно. Просто факты такие, что большинству нужно «ща по-быстрому», но не 100%. И если это airbnb, например, то там можно 10 лет выпускать багованую, неповоротливую программу с зачатками юзабилити и дизайна. Все схавают. А если это другой сервис, то, возможно, разбегутся. Если менеджеры правильно оценивают низкую лояльность аудитории, понадобится Ваш качественный код.

Надо вырабатывать в себе стиль «быстро и тщательно». С подкреплением тщательности, в виде хороших интеграционных тестов.

Анекдот про художника который не мог продать свои картины

И еще о баг драйвен. Что легче? Написать безошибочный код или заставить юзеров ходить строем (только определенными путями графа)?

Один таинственный вассал путями графа обошёл

Пробовали освоить другой стиль мышления так, чтобы получилось эффективно в нём работать?

Ну если привык разбираться, а менеджер требует лепить говнокод по-быстрому, то что бы работать «на отвали» много усилий не надо. В отличии от ситуации, когда привык говнокодить, а вдруг каким-то чудом попал на «проект мечты» где все делают по-уму. Если думать не привык — то это быстро не вылечить. Поэтому формошлеперов и не любят!
Другое дело что если хочешь делать хорошо, а заставляют — быстро, то это вызывает внутренний конфликт и отрицательное отношение к работе. С другой стороны отсутствие мотивации только помогает работать «на отвали».

Или прийти из своей любимой крайности к идеальной середине.

«Идеальная середина» — она у каждого своя. Работа хорошего руководителя как раз в том, что бы каждый подчиненный работал в удобном ему режиме. А управлять нужно распределением задач и оплаты.

Имхо, думание это процесс улавливания из будущего всей этой херни. Да, можно сначала «увидеть» все возможные катастрофы, а потом стараться их не допустить. Вот только тогда возникает вопрос: если вы увидели в будущем катастрофу и на основе этого замотивировались на некий поиск решения, а потом (кур-ла-ла!) решение нашлось, но бах! катастрофа канула в небытие... А где тогда ваша мотивированность теперь? Что вы помните о решении теперь, когда нет причины? (Да, пардоньте, она из возможного будущего, вот только мозгу это как бы похер) И решение забывается, дабы не запарадоксило все вокруг. А дальше — больше. Решение забылось? Катастрофа обнаружилась. Мы снова замотивированы ибо мысль. И бежим к компу. Ибо вдохновение. Вот это и есть обдумывание интереснейшей проблемы. Вот этот весь колдовской балаган. Эта не то цикличность, но скорее вибро-мастурбация мозга (ибо дофамин струями на базальные ядра) И все это неправильно. Вот возьмем к примеру армию. Там думать запрещено. Устав думает за солдата. Нужно не думать, а делать начало начала. А еще лучше начало начала начала. А потом не думать, а делать дальше уже середину начала начала. Нам надо проблему максимально в реальность вытащить чтобы решение максимально было зафиксировано в реальности с помощью хоть какой-то реализации. Этим и занимается «быстро-быстро» стиль. Кстати, баги лучше всего исправляют квантовики затейники.

катастрофа канула в небытие... А где тогда ваша мотивированность теперь?

Всё в порядке с ней, никуда она не денется.

Что вы помните о решении теперь, когда нет причины?

Всё помню. Я же не в бессознательном бреду придумывал решение, а трезво и осмысленно.

Что вы помните о решении теперь, когда нет причины?
Всё помню. Я же не в бессознательном бреду придумывал решение, а трезво и осмысленно.

Я думаю по другому. Более того, если решение искать от катастрофы, тогда найденное решение — сто пудов — может эту самую катастрофу тем или иным неявным образом спровоцировать — иначе откуда оно вообще возьмется в потенциальности?

Решение делается, исходя из задачи и из необходимости обеспечить надёжную работу.

Потому ищут и платят больше инженерам, которые не дают самолёту взорваться, вместо тех которые проектируют на основе обломков

Вообще-то эти «стили» мышления работают на уровне ситуаций. А в команде друг друга просто уравновешивают. Как только один начинает гнуть в сторону hуяк-hуяк, у него тут же возникают оппоненты «а кто будет прошлое hуяк допиливать»?

Я больше скажу, НЕТ золотой середины, ЕСТЬ серебрянные крайности. И золотая ЛЕНЬ между ними, занимающая 90% персонала, но готовая К МОБИЛИЗАЦИИ в одну или другую сторону.

Эффективное управление сводится к формированию потока НА ГРАНИ мобилизации, при котором ситуация искрит, но не происходит короткого замыкания в тупость. Это позволяет ситуационно мобилизовать команду в РАЗНЫХ направлениях, при этом сохраняя готовность принимать быстрые ОБЩИЕ решения.

Видел когда-нибудь как электрошокер работает? Так вот, чтобы работать, искрить ему не обязательно. Искры ему чтобы сбрасывать перезаряд. Так энергозатратнее, но зато скорость работы выше, и когда нужен ток — схема готова выдать И напряжение, И требуемый ток.

С точки зрения использования персонала, на энергозатратность не просто плюют, наоборот, её ДОБИВАЮТСЯ. Даже если часть системы пашет вхолостую. Только лишь затем, чтобы тормозящие тренды не взяли верх, чтобы не формировались конфликты ради роста ЧСВ, но чтобы при этом не выжигался ресурс поведенческих цепей блокировки — что как правило творит БЮРОКРАТИЯ.

Простой пример: Какой-нибудь «да-щас-по-быстрому» решает ввести наказания за опоздания. И все приходят вовремя, ну на крайняк до 5 минут задержатся. А результат — работоспособность ниже в 5-10 раз. Почему?

Когда зачитался мега-крутым коментом... Что касается прошлого куяк. А зачем новые-то? Когда старые еще тут. Отсюда — пусть допиливает поставивший новую задачу. Детальное планирование безнадежно и чем детальнее тем безнадежнее. Ибо все слоями и хаотически падает сверху. Ибо так устроены человеки — рэндом структурируют. Куяки это квантовые выпадения из реальности по мосту Эйнштейна Розена (знаю что спорно) и самое лучшее подождать пока они рассосутся сами. Быстро реализуются вещи надежные и стабильные. Флоатинг точки напротив будет менять каждая... каждый кому внезапно припечет. И от этого их нестабильность будет порождать вокруг них тьму войны (как в варкрафте — пока герой вблизи вроде чего-то понятно, стоит уйти подальше и там уже толпы орков, о которых мы ничего не знаем) Если посмотреть сверху мы увидим красивые и уверенные линии на месте стабильности и смазанные нечеткие мазки на месте куяков. Отчего они так трудно исправляются? Их семантическая консистенция требует сбора неких контекстов которых у разработчика сразу нет.

Адизес всё расписал ещё лет 30 назад. Поверь, ничегошеньки с тех пор не поменялось. Доминанты поведения всё те же.

НЕТ золотой середины, ЕСТЬ серебрянные крайности. И золотая ЛЕНЬ между ними, занимающая 90% персонала, но готовая К МОБИЛИЗАЦИИ в одну или другую сторону.

:))

По быстрому и фиксить. Bug Driving Dev Proc

Стиль мышления меняется от задачи к задаче в зависимости от нескольких факторов:

— важности и масштаба задачи;

— контекста (если для «тщательно и надежно» нужно перелопатить кучу легаси, что в данный момент не нужно, то иногда проще воткнуть костыль и порефакторить все вместе впоследствии);

— степени подгорания жoпы со сроками.

Ой как трудно опредилить масштаб задачи

Подписаться на комментарии