LINUX.ORG.RU
ФорумTalks

Как искать удалённую работу на которой не будет ежедневных созвонов?

 


0

1

Насколько мне известно, во многих местах на удалённой работе уже считается естественным проснуться улыбнуться и бежать отчитываться на ежедневный созвон, чтобы поублажать господ-менеджеров.
Для технических работников толку от этих созвонов немного и большую их часть можно заменить на документирование происходящего в таск-трекерах, а лично у меня при вербальном общении в голове вообще мало что остаётся. Мне нужно вдумчиво работать с текстом, чтобы всё обдумать.

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

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

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


Ответ на: комментарий от bdrbt

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

Плохому танцору разрабы мешают. Никогда такого не было и вот - опять.

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

Obezyan
()
Ответ на: комментарий от t3n3t

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

и да, это не «проблемы бизнеса». проблемы бизнеса ты скорее всего даже не понимаешь. они не на твоём уровне вообще. ты решаешь вопросы разработки? вот и решай их. не надо представлять себя правителем вселенной и самым главным в компании.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Во, уже и из разработчиков меня выписали.

сделай пометку в тикете, что ты застрял именно из-за этой проблемы

Вот за такое хочется взять и у… разбить на сабтаски.

и тем более не повод всех поднимать на уши ради какой-то мелочи

Ооо, какая классика - додумываем за сосбеседника и про «всех» и про «какую-то мелочь». Кое-кто проецирует, не? :)

проблемы бизнеса ты скорее всего даже не понимаешь. они не на твоём уровне вообще

На моем, прикинь. Очень даже понимаю.

не надо представлять себя правителем вселенной и самым главным в компании

Когда пустобрехам нечего сказать - они всегда скатываются в крайности ;)

t3n3t
()
Последнее исправление: t3n3t (всего исправлений: 1)
Ответ на: комментарий от t3n3t

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от stave

Ты удивишься, но никого не интересует отчёт - интересуют блокеры.

Блокеры, они в голове. Этих тараканов тоже победили.

Ведь большинство разрабов - лютые социофобы и мы явно видим это по этому топику, и сходить к соседу Васе помочь со стыком - лютая нерешаемая проблема.

В смысле? Тегаешь прямо в задаче и спрашиваешь. Когда у человека будет время он ответит, но обычно это от 5-10 мин до получаса. Можно конечно и в личку, но это нечасто происходит тк все специалисты и понимают что они делают, зачем и как.

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

Чтобы не выгорать используем принцип family first, и уходим в отпуска без вопросов, главное предупредить за неделю и сделать задачи блокирующие других. Я вообще стараюсь почти каждый месяц брать от 4 дней до недели. И пару раз в год по две недели. При таком подходе эффективность остается на высоте и буквально - хочется работать.

Но тут есть нюанс - у нас уже нет ни мидлов, ни джунов. Джунов не было, а мидлы выросли в синьоров.

А вы рассказываете про какой то детский сад.

Ну, как есть. Чтобы достичь этого детского сада мне нужно 10+лет упорно работать и идти к такому положению вещей. Я не работаю в офисе и не работаю по 8 часов в день. Для меня это идиотизм - программист не может держать столько часов концентрацию. Опытные программисты могут работать в потоке до 5-6 часов максимум, потом все. Начинаются залипания в телеграммы, веб серфинг и тд. Так лучше поработать 5-6 часов не отвлекаясь ни на что кроме перерыва на обед и потом идти заниматься своими делами чем 8 часов просиживать штаны имитируя занятость.

Потому что во взрослых командах мы встречаемся, чтобы хоть немного социализироваться в наших удаленках и всегда рады друг друга видеть.

Для социализации у меня есть жена и отпуска.

Obezyan
()
Ответ на: комментарий от t3n3t

а крайности (дёргать всех по любому поводу - вот это крайность) пока скатываешься только ты. другие разработчики никого не теребят, просто пишут тикеты и ждут, когда им ответят. а пока занимаются другими задачами. благо, задач обычно всегда много и можно переключаться между ними по мере обновления их приоритетности. бывает, что какие-то мелкие тикеты вдруг ставят в приоритет и все начинают их быстро фиксить. причём с точки зрения разработчика важно может быть одно, а в большой перспективе может быть важно совсем другое.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

И опять проецируешь собственный опыт на чужой, рассказывая о своих невероятных заслугах, пытаясь принижать окружающих.

проблемы бизнеса ты скорее всего даже не понимаешь

у бизнеса могут быть другие представления о «более важном».

Как я люблю ЛОР за такие моменты :)

t3n3t
()
Ответ на: комментарий от Iron_Bug

дёргать всех по любому поводу - вот это крайность

лида на пять минут

всех

Мде.

не надо представлять себя правителем вселенной и самым главным в компании

Никаких крайностей. Совсем.

t3n3t
()
Ответ на: комментарий от t3n3t

а при чём тут ЛОР вообще? это к ЛОРу никакого отношения не имеет. или ты хочешь сказать, что прозреваешь все планы генерального директора лучше него самого и уже точно знаешь, что там наверху думают о важности конкретных фич в разработке? я просто рассуждаю трезво и исхожу из опыта разработки. конечно, для каждого разработчика его проект - самый важный. но в общей картине приоритетов это, внезапно, может быть совсем не так. даже если технически это что-то важное и сложное, юзерам могут быть нужнее какие-то тупые кнопки в интерфейсе, чем новые фичи в бэкенде, например. без кнопок они топают ножкой, а без фич они живут вполне себе спокойно и не дёргаются.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

а при чём тут ЛОР вообще?

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

или ты хочешь сказать, что прозреваешь все планы генерального директора лучше него самого и уже точно знаешь, что там наверху думают о важности конкретных фич в разработке?

Мне это генеральный директор сообщает лично.

я просто рассуждаю трезво

То-то ты так часто с пятницы на субботу тут «рассуждаешь».

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

Тут комментировать - только портить. Пожалуй, хватит на сегодня :)

t3n3t
()
Последнее исправление: t3n3t (всего исправлений: 1)
Ответ на: комментарий от t3n3t

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от t3n3t

Да-да, напишу-ка я дополнение в апишку, получающую респонзы от соседней команды

Тот кто ставил вам задачу должен был скинуть ссылку на документацию в самой задаче.

вот только что-то оно там не то мне в ответ с их стороны присылает.

Регулярно с таким сталкиваюсь. И обычно эта соседняя команда - сторонняя контора уровня DHL. В таком случае пишется коммент в задаче: @ манагер-нейм, доки неактуальны по вот этому third party api, в этом случае наш манагер кабанчиком дергает их манагера и их манагер выделяет человечка которого добавляют к нам в чат, после чего на вопрос «доки есть? а если найдем?» следует ответ «пацаны не надо стрельбы, отдел маркетинга еще не успел нормально оформить и выложить в общий доступ, там же на 10 языков перевести надо, вот вам драфт в пдф, все работает по нему, мамой клянусь». И таки да, работает.

Т.е. созвоны есть, но на уровне манагеров. Кесарю кесарево. Они созвонились, согласовали, стыканули людей. В последний год вообще большинство контор с кем работаем уже сидит в Asana/Slack и стыковать там можно вообще без созвонов.

Obezyan
()
Ответ на: комментарий от Obezyan

Т.е. созвоны есть, но на уровне манагеров.

Лиды, зачастую, совмещают разработку и манагерство (в т.ч. техревью, скрамы, это вот все). Я примерно это и имел ввиду, но начался хардкор :)

t3n3t
()
Ответ на: комментарий от Iron_Bug

Теть, ты когда на работу устроишься, не забудь юзерам, которые платят, напомнить о том, какие они ламеры и не умеют белье в тазике стирать годами. Лучше сразу на собесе, так быстрее будет.

t3n3t
()
Ответ на: комментарий от Obezyan

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

я хочу писать код, думать головой, реально работать с живым софтом, а не перекладывать бумажки на столе и пялиться в ничего не значащие отчётики манагеров. я понимаю, насколько далека реальная разработка от мира розовых пони с правильными графиками и идеальными дедлайнами. нет, конечно при схеме работы «водопад» можно ещё что-то распланировать. но не «прямо вот вчера», на это требуется время. а сейчас стало модно аякс-аякс - и в продакшен, потом поправим. на «потом» не остаётся времени, технический долг растёт, код начинает превращаться... начинает превращаться... в общем, как часто бывает в современных проектах: типичный дендрофекальный метод, как выразился один человек. мне понравилось название.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от t3n3t

Лиды, зачастую, совмещают разработку и манагерство (в т.ч. техревью, скрамы, это вот все). Я примерно это и имел ввиду, но начался хардкор :)

Либо техлид либо тимлид. Попытки совмещения приводят к возникновению техтима либо лидлида что пагубно сказывается не только на проекте, но и на самом человеке. Я в эту рулетку уже играл, доигрался до позиции техдира и потом год восстанавливался.

Obezyan
()
Ответ на: комментарий от Obezyan

Да это понятно, в теории оно все так, но на практике в МСП чаще «гладко было на бумаге..». И еще не факт что на качественной.

t3n3t
()
Ответ на: комментарий от Obezyan

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

конечно при схеме работы «водопад» можно ещё что-то распланировать.

Правильно поставленный водопад это база. Уделывает любое гибкое и гутаперчивое, даже когда нужно MVP. Наматывать сопли на кулак на ретроспективах интересно первые 10 лет, потом надоедает.

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

Я потому с техдира и ушел в архитекты тк это позволяет не только проектировать саму систему делая СРАЗУ НОРМАЛЬНО, но и писать код оставляя себе сложные (читай - интересные) задачи. Да и постройкой техпроцесса также можно невозбранно заниматься.

Есть кончено архитекты курильщика, которые только рисуют презенташки о там как красиво сунуть кролика в монгу, но это архитекты курильщика.

Из минусов: на постсоветском пространстве до сих пор туго понимают зачем он нужен и как его использовать. Ну и количество языков которые нужно знать или хотя бы понимать увеличивается довольно сильно.

Obezyan
()
Ответ на: комментарий от Iron_Bug

вот если бы меня хоть немного тянуло к общению

Учитывая количество ваших сообщений на форуме, техлидскую норму вы выполняете )

Obezyan
()
Ответ на: комментарий от t3n3t

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от t3n3t

Да это понятно, в теории оно все так, но на практике в МСП чаще «гладко было на бумаге..». И еще не факт что на качественной.

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

Obezyan
()
Ответ на: комментарий от t3n3t

хоть кто-то ИТТ выкупает эту тему

Берёшь лес, и начинаешь в нём жить. Жена приезжает раз в неделю. В 14 созвон на одной работе, в 16 созвон на другой работе, в 21 созвон с 85летней мамой. Попинговал живых, сам показал что ещё жив. Романтика. С 9 до 14 можно и поработать спокойно, накопить вопросов детишкам и бабушкам.

Toxo2 ★★★★
()
Ответ на: комментарий от Obezyan

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

и да, конечно я сразу говорю, что я не юзероориентированный программист

Тогда зачем о них нон-стоп рассуждаешь? У тебя то юзвери, то ламеры, то еще что-нибудь. А платят в конечном счете за твой софт именно они. Только сначала твоему заказчику, который отстегнет лоеру, лоер шефу охраны, шеф охраны парикмахеру.. продолжать? :)

t3n3t
()
Ответ на: комментарий от t3n3t

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

я даже не видела тот пост. просто если кто-то выглядит, как утка, крякает, как утка... в общем, ты звучишь как типичный манагер, а не как разработчик. разработчики обычно всё делают вообще не так. а у тебя манагерские замашки и манагерские методы. типа: у меня проблема, свистать всех наверх, все срочно бросили свои проекты и метнулись сюда! это ненормально, если ты понимаешь, что такое разработка.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Obezyan

дело не в людях. а в том, что разработчикам не дают время на рефаторинг. гонят вперёд, нужны новые фичи, причём нужны вчера. а что при этом код превращается в неподдерживаемую конструкцию из костылей и синей изоленты (в лучшем случае), это манагеров не волнует. им нужен внешний лоск. а внутри там кошмары на улице вязов.

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

а у тебя манагерские замашки и манагерские методы.

«Все что мне не нравится - манагерское», ага :)

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

ЗЫ: «ты звучишь как типичный манагер, а не как разработчик.» - возможно, потому что я вижу общую картину с разных сторон, мм?

t3n3t
()
Последнее исправление: t3n3t (всего исправлений: 1)
Ответ на: комментарий от t3n3t

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от t3n3t

какой опять вопрос? ты строчишь однострочные ответы с переходом на личности. я не вижу вопросов. только глупые утверждения.

и ты говоришь всё то, что программисты терпеть не могут. если они молчат, это не значит, что их это устраивает. просто они часто слишком тактичны, чтобы сказать своё ФУ. а в частной беседе они часто поносят все эти стендап-комик-шоу последними словами. эта двуличность - тоже отдельная проблема. но я не могу призвать всех стать ответственными и громко встать и сказать «нам это не нужно». хотя, по идее, так и нужно делать, чтобы избавиться от подобного идиотизма, от которого все молча страдают.

Iron_Bug ★★★★★
()
Ответ на: комментарий от t3n3t

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

какой опять вопрос?

Буквально в комменте на который ты отвечала:

Примеры замашек и методов будут?


я не вижу вопросов

Лол.

и ты говоришь всё то, что программисты терпеть не могут

Ты там это, напиши уже свод правил для программистов, дабы отличать агнцев от козлищ, это вот все.

если они молчат, это не значит, что их это устраивает. просто они часто слишком тактичны, чтобы сказать своё ФУ. а в частной беседе они часто поносят все эти стендап-комик-шоу последними словами. эта двуличность - тоже отдельная проблема. но я не могу призвать всех стать ответственными и громко встать и сказать «нам это не нужно». хотя, по идее, так и нужно делать, чтобы избавиться от подобного идиотизма, от которого все молча страдают.

Рекомендую все же Аминазин или Циклодол. Вас, барышня, уже конкретно несет.

t3n3t
()
Ответ на: комментарий от Iron_Bug

другого разработчика

Лида. Это его ответственность и обязанность.

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

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

t3n3t
()
Ответ на: комментарий от t3n3t

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

этому ведёт совершенно порочная во всех смыслах практика «скрама»

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

У нас это сначала активно прижилось в ruby разработке (сладкий орбит со вкусом рельсы), а потом уже перекочевала во все остальные языки. В какое-то время показалось что эта мода начинает сходить на нет и логика восторжествует, но потом JS стрельнул дуплетом в ноги интернета и гибкость получила второе дыхание.

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

Obezyan
()
Ответ на: комментарий от Iron_Bug

Ответов на прямо поставленный вопрос так и не последовало. ЧТД.

а я не люблю попсу ни в чём. ни в разработке, ни в медицине

Потому что когда-то давно тебе это сказал какой-то патлач на пяьном гиге, чтобы известно что, забыв тебя на следующее же утро, а ты несешь с собой эту нелепость всю жизнь. Так всегда бывает, даже если в конечном итоге нефорское существо женского пола слушает какой-нибудь Belketre или Mutiilation.

не знаешь - не пиши.

Воистину.

t3n3t
()
Ответ на: комментарий от Obezyan

У нас это сначала активно прижилось в ruby разработке (сладкий орбит со вкусом рельсы)

А вот щас обидно было (нет).

t3n3t
()
Ответ на: комментарий от Obezyan

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Obezyan

Вы описали свою реальность

Только я могу понять вашу и взглянуть на нее со стороны т.к. лет 15 назад был в ней же

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

А вот моя реальность для вас - фантазия, потому что подобного опыта у вас нет.

Да на опыт не жалуюсь, поэтому и назвал фантазией. Про системную архитектуру это ты хорошо упомянул… это многое объясняет.

bdrbt
()
Ответ на: комментарий от n_play

кто-то еще 500-1000 строчек перелопаченных тестов забыл, в которых нужно разбираться или узнать что их нету и вот тут ты попадаешь, хорошо если чуть ли не неделю. а то бывает и больше.

Во-первых, есть простое правило, не мной придуманное, но мне нравится: Если кажется что задачка минут на 20 - пару строчек кода поправить - говоришь 1 час. Если думаешь, что за часик управишься - говоришь 2 часа, если думаешь что задача на пару часов говоришь 4 часа, если задача на пол-дня - день. Если задача выходит за 8 часов рабочего дня - это уже мой личный косяк, задачу надо декомпозировать на несколько задач попроще.

Но если я вижу, что сроки искусственно раздуваются - принимаю меры по-ситуации.

bdrbt
()
Ответ на: комментарий от Iron_Bug

а это потому что ты нихрена не делаешь полезного.

О, ещё одна ванга

если бы делал полезное - не сидел бы и не смотрел на солнышко,

ещё и книжки не читаешь.

а писал код. но ты обычный дармоед,

Ты так говоришь, как будто меня содержишь.

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

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

и да, уволься из компании - и не будет этого минуса каждый день в расходах. это расходы на твоё содержание.

Могу уволится в любой момент, но эта компания будет продолжать меня содержать, это мой пенсионный фонд.

bdrbt
()
Последнее исправление: bdrbt (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

в разработке всё должно быть задокументировано и чётко, как в аптеке, а не просто поболтали, забыли и разошлись

На практике такое редко, во всяком случае, не на моем опыте. Реалии бизнеса таковы, что софт - это дёшево. Причём, это не бизнес плохой, это софтостроение такая отрасль, и в этом её смысл по определению, в генезисе. Даже при наличии всех инструментов, для работы с ТЗ, а также всякие конфлюенсы и проч., даже если процессы оговорены, чтобы всё документировать, всегда команда будет стремиться сэкономить на углах, положиться на человеческую память, потратить время на тестирование, на что угодно, но не на архитектуру, её документирование и проч. К тому же и сами требования частенько написаны на таком языке, который оставляет желать лучшего. То ли человек плохо знает английский, то ли не умеет систематически эти мысли формулировать (и никто рядом не прочтёт его писанину и не поправит). В общем, в итоге софт превращается в паззл, и если софта несколько версий выдержано, соотв. паззл с историей, что только запутывает. Да, ТЗ и сопутствующая документация помогают, но всё равно, чтобы во всём разобраться, надо либо автора кода выписывать, либо разбирать исходники от А до Я.

seiken ★★★★★
()
Ответ на: комментарий от seiken

Теперь представим себе огромную компанию, в которой продукт - это гигантская связка работающих вместе сервисов. Сервисы писались в разное время разными командами на 3-4 различных языках программирования. Между собой общаются через REST API, несколько видов очередей (RabbitMQ, Kafka), напрямую через БД и CDC (debezium’ы разные), файловые системы (от S3 и Ceph до доморощенных решений). Часть систем писалась сторонними подрядчиками. Часть писалась командами, которые создавались, расформировывались, иногда увольнялись полным составом.

Я тут работаю. Компьютерная археология - теперь моё хобби. )

P.S. Но сделано на удивление хорошо. Для большинства вещей есть хотя бы техническая документация, описывающая как сделано (но, к сожалению, не зачем - а это часто не менее важная информация). И несмотря на всю чехарду, что не осталось ни одного из изначальных разработчиков (что удивительно, остались некоторые из менеджеров, которые были с самого начала), оно всё работает и даже развивается.

Chiffchaff
()
Последнее исправление: Chiffchaff (всего исправлений: 1)
Ответ на: комментарий от bdrbt

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

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 2)
Ответ на: комментарий от Reset

На дейликах никто ничего не узнает

Если не узнаёт - проблема того кто дейлик проводит.

Это просто ритуал

Нет это называется, общение, аудиовизуальное, гораздо более быстрое чем ломание пальцев в чатиках.

особенно если к нему в рандомное время подключатся высшее начальство

Если начальство подключается к дейликам разрабов - значит п-ц уже происходит.

bdrbt
()
Ответ на: комментарий от bdrbt

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

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

Выглядите очень жалко.

Obezyan
()
Ответ на: комментарий от Obezyan

Пахнете слабостью

Вымойся, должно помочь.

что мне не понять чайка-менеджмент

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

и в итоге скатились в попытку неумелого психоанализа.

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

bdrbt
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)