Опять пожаловаться на начальника ...

[Komissar]

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

My heart goes out to you, NtNet!

[NtNet]

Sorry mistakes, using Latin alphabet (no access to RU sites)

Update:
Boss полностию переписал мои код на свои лад.
Провела ету ноч изучая его, раз мои получается что забракован.

Как обешала, пишу сначала алгоритм которому следовала я, потом босса новии алгоритм.

Задача: смоделироват епизоди пациентов, в течение 12 месяцев после их поступления в болницу
(на Программу); И посчитат уникалное кол-во пациентов + днеи их болезнеи, представит данние за
опредиленни период (Fiscal Year 2019-20).

Дано: таблица вступления пациентов на Программу – SSAS.ClientsEpisodes
таблица реалних еписодов (болезнеи) – WHMHSA.ClientEpisodes


Algorithm 1 (implemented by NtNet):

1. In SSAS.ClientEpisodes (Program table) ограничит дати поступления (AdmissionDate), дати виписки (DischargeDate) периодами FY (BOP / EOP)
– таким образом, чтоби видат толко наложения (intersections) – AdmissionDate / DischargeDate vs BOP / EOP
(see screenshot below, developed by NtNet).
Чтоби исклучит варианти (non intersections) применит такое условие – ето case 5, 6 on the picture:
WHERE
NOT ( ( (ssas_epi.AdmissionDate < @BOP) AND (ssas_epi.DischargeDate < @BOP) ) OR ( (ssas_epi.AdmissionDate > @EOP) AND (ssas_epi.DischargeDate > @EOP) ) )

Расчитат recent 12 months from DischargeDate – Dateadd function И исклучит случаи когда AdmissionDate > Recent_12_Months_Date
(иначе получается что наша "Recent12MonthsDate table" вклучает не сушествуюшие Program Episodes)

Занести данни код в table valued function (tvf)


2. K WHMHSA.ClientEpisodes – tablica s realnimi episodami boleznei JOIN tvf from #1
Видат Upd_DischargeDate (updated, т.к добавлена проверка – если нет discharge, то ограночит текушеи датои – Getdate () ),
Recent_12_Months_Date as [Upd_AdmissionDate] from SSAS.ClientsEpisodes; BeginDate, EndDate from WHMHSA.ClientEpisodes,
– дати реалних еписодов
Ограничит BeginDate / EndDate - BOP / EOP – т.к ми ишем число болезнеи за FY (BOP/EOP)

Проверит соотношение Upd_DischargeDate – Upd_AdmissionDate (1) vs Begindate / EndDate (2) – Где рассчитат все возможние наложения (intersections) между (1) И (2)
Их всего 4, абсолутно аналогично картинке ниже.
И посчитат разницу днеи с помошиу IIF(Datediff ….., as following:
([BeginDate] >= [Upd_AdmissionDate]) AND ([Upd_EndDate] >= [Upd_DischargeDate]) to
[Upd_DischargeDate] - [Upd_BeginDate] = kol-vo dnei AS [Dif1]

И так дале – еше 3 варианта - write code on SQL.

COUNT(DISTINCT ClientID)
SUM ([Dif1] + [Dif2] + [Dif3] + [Dif4])



Algorithm 2 (created and implemented by the boss):

1. In SSAS.ClientEpisodes ogranichivaem AdmissionDate, DischargeDate by BOP / EOP As [AdmissionDateBOP] / [DischargeDateEOP],
где если AdmissionDate < BOP, to BOP / DischargeDate > EOP to EOP


2. For testing purposes (that’s I don’t understand why we need this) calculating Length of Stay – between AdmissionDate & DischargeDateEOP = LOS


3. Calculating [AdmissionDate_12_Month_Prior]
By subtracting 365 days from the [DischargeDateEOP]
If this difference date is less than the AdmissionDate, then we use the AdmissionDate (makes sense)

– the 1st part of this step I completely don’t understand. Why calculate 12 Month Prior the Admission Date by subtracting from the DischargeDate, and not from the AdmissionDate?


4. For the [DischargeDate_12_Months_Prior] he just used DischargeDateEOP

- Also makes no sense for me…
I think if we need 12 Months Prior DischargeDate then we should calculate it off of the DischargeDate (like Datediff), and not just take DischargeDateEOP as it is…



5. Calculating Length of Stay within 12 Months – by subtracting [DischargeDate_12_Months_Prior] - [AdmissionDate_12_Month_Prior]
I оставляем толко те еписоди где 12MonthsLOS >=365

- Я считау что надо оставлят толко где = 365, т к ми анализируем 12 months (1 yr period)…


6. Создаем tvf для етого кода


7. JOIN it to WHMHSA.ClientEpisodes как у меня
И далше по аналогии со мнои, толко оперируя своими полями
(ето изучу on Monday)



Итог – отправила сегодня ночиу данние которие boss насчитал в етои сложнои чсти И свои в 1и части – где “Prior 12 Months”

[vdfs]

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

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

[observer_ca]

3. Calculating [AdmissionDate_12_Month_Prior]
By subtracting 365 days from the [DischargeDateEOP]
If this difference date is less than the AdmissionDate, then we use the AdmissionDate (makes sense)

– the 1st part of this step I completely don’t understand. Why calculate 12 Month Prior the Admission Date by subtracting from the DischargeDate, and not from the AdmissionDate?


4. For the [DischargeDate_12_Months_Prior] he just used DischargeDateEOP

- Also makes no sense for me…
I think if we need 12 Months Prior DischargeDate then we should calculate it off of the DischargeDate (like Datediff), and not just take DischargeDateEOP as it is…



5. Calculating Length of Stay within 12 Months – by subtracting [DischargeDate_12_Months_Prior] - [AdmissionDate_12_Month_Prior]
I оставляем толко те еписоди где 12MonthsLOS >=365

- Я считау что надо оставлят толко где = 365, т к ми анализируем 12 months (1 yr period)…

Я, конечно, ни разу не Data Analyst, но похоже Ваш босс находит последние 12 месяцев от момента выписки. Т.е. если пациент провёл условные 2 года, то берётся второй год, а не первый - потому и расчёт от даты выписки. По этой логике в пункте 3 он гарантировано получает 365 дней или меньше. Вы правы по пункту 5, там должно быть просто равенство; но по вычислению из пункта 3 больше 365 никогда не будет.

Upd. Your boss’ naming convention does not help - to say the least

[NtNet]

Ваш босс находит последние 12 месяцев от момента выписки. Т.е. если пациент провёл условные 2 года, то берётся второй год, а не первый - потому и расчёт от даты выписки

Ага, спасибо за разъяснение...
Т.е получается он считает Recent 12 Months from DischargeDate.
Но и я в своем коде считаю эти самые recent 12 months...
Но у меня получается 34 records на выходе, а у него 51.
Наверное потому что он больше разных условий там ставит (например, ограничивает AdmissionDate / DischarheDate BOP / EOP (хотя по логике если ограничивать, то наоборот, меньше должно быть записей)
Ну и другие разные условия применяет, что я не написала у себя ...))

[NtNet]

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

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

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

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

Тут так -

Менять я и так 100% буду, через эти месяцы что я написала. Хочу еще по некоторым пунктам, языкам и тулсам потренироваться

Насчет ночных мучений - не совсем так ))
Я люблю работать ночью
Днем могу и спать и уйти по делам и тд
Нет строго режима и работаю 60-80% из дома. Пятница в 90% полностью свободна при full time - после 12 дня никто толком не работает и предпочитаем по 10-12 часов неск дней в неделю.

Остальное правда!
Начальник с одной стороеы очень хороший девелопер и многому научил меня и тд
А с другой - ну ооочень специфический dude ... Мне супер тяжело на этих митингах. Он тараторит, абсолютно совершенно никогда не слушая что я говорю в ответ или когда спрашиваю что-то.
Если вот такая задача, исходящая из его кода или таблицы, то я выцарапываю requirements неделями иногда.
Он в идеале хочет чтобы я как он - сама эти requirements понимала.

Еще - я оч плохо понимаю быструю речь (на любом языке). Привыкла работать thru emails. А он наоборот может только разговаривать, читать в принципе не любит ... Доп трудности с пониманием

(На прошлой работе у меня была прекрасный РМ - она была точно как я по способу мышления и по восприятию инфы!)
Мы с ней тратили 40 мин в пару недель и у меня была прозрачная цель в проекте
Но там было легко, только в осн MsAccess и salecforce и парочка простеньких автоматизаций с моей стороны и все.


Насчет рынка - не совсем соглашусь
Просто тут на привете наверное мало людей с работой в БД и зп там ниже конечно чем 500-700к, но в р-не 200 вроде можно

А так даже аналистом- никогда не было проблем с рынком. Они в каждой дырке требуются!
Я хочу дальше или db developer или data engineer
Analyst там мало $$. Сайнтист там надо больше math related knowledge и tools владеть и в идеале PHD
Я не люблю математику, не интересно и могу заниматься ей только как узко прикладное к чему либо!

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

- Core Demographics data entry form
Db design, ms access

- EHR Chart Review project
Db design, sql code, power bi visualisation, sql scripts for ssis etl automation
Ms access form development for EHR Chart Entry Form

- Client Satisfaction Survey
Db design, sql code, power bi visualisation, sql scripts for ssis etl automation
Ms excel, vba for form development for CSS Entry Form

- Psychiatric reports
(Забыла название)
Db design, sql, power bi

Это только те что я на 90-95 % разрабатывала сама, с небольшими консультациями и советами со стороны начальника. Пару раз по внешнему дизайну; и в одной из форме ввода данных он 1 раз только помог с кодом
Мы пару выходных писали его, я свой и он свой вариант и всё-таки выбрали его из-за лучшей функциональности ))

Это не считая остальных проектов где я или только интерфейс создавала в отчётах или доделывала после его кода, поддержка - в dax power bi, sass, sql

Поэтому думаю это не плохой опыт, особенно по сравн с моим предыдущим 4 годами чисто Аксеса
Думаю если не будет кирдыка, то работу на нужную мне сумму и тайтл найду

[vdfs]

Просто тут на привете наверное мало людей с работой в БД и зп там ниже конечно чем 500-700к, но в р-не 200 вроде можно

Вот я на привете, и я существенно меньше, чем 200, зарабатываю. Эти все космические суммы больше к SFBA / Seattle / NYC применимы, где и недвижимость космическая. Да и выпендрежников хватает, тоже.

Желаю удачи в поисках!

[NtNet]

Просто тут на привете наверное мало людей с работой в БД и зп там ниже конечно чем 500-700к, но в р-не 200 вроде можно

Вот я на привете, и я существенно меньше, чем 200, зарабатываю. Эти все космические суммы больше к SFBA / Seattle / NYC применимы, где и недвижимость космическая. Да и выпендрежников хватает, тоже.

Желаю удачи в поисках!

Так я как раз тут.
В силиконовке, бей арии

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

Но почему бы и нет если можно
Смотрю по личным обстоятельствам

Спасибо!!! Удача понадобится. )

[valchkou]

Как обешала, пишу сначала алгоритм которому следовала я, потом босса новии алгоритм.

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

[NtNet]

Как обешала, пишу сначала алгоритм которому следовала я, потом босса новии алгоритм.

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

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

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

Но моя цель взять что можно технически, а потом свалить на "более счастливые поля охоты" ))

[Сабина]

Что хочу сказать по данному вопросу ... чем дальше тем мудрее и все больше прихожу к выводу что какие то несогласия с коллегами и начальником будут всегда. Вопрос как с этим жить ?
Если вкратце то :
1) сначала надо определиться настолько ли разногласия необратимые что с ними нельзя жить?
2) подумать готовы ли вы меняться сами. То есть согласны ли на компромисс и какой?
2) если необратимые и на компромисс не согласны ни разу , то лучше сразу искать другую работу, людей вряд ли поменяете, тем более начальников, а это ваша жизнь. Ну и типа zip it up пока ничего не нашли
3) если готовы на компромисс, то найдите тот самый sweet spot где и волки сыты и овцы целы. Ну или попробуйте найти.

Посмотрите на себя со стороны, не выглядите ли вы героем, который «против всей планеты»? Увы, но у русскоязычных нередко репутация что они везде идут с лозунгом «мы наш мы новый мир построим». Объективно это может сильно расходиться с опытом другим коллег или тем что начальнику нужно deliver. Простой пример : нужно deliver in 3 months, а вы предлагаете «реорганизовать Рабкрин» и просите под это полгода, потому что «так правильно». Это неправильно . С точки зрения business goals , которые вам не видны например, а начальнику видны.

В общем жить в гармонии с рабочим коллективом - это тоже умение. Если вам подходит компенсация, график, технологии, you name it, то нет смысла лезть в бутылку, не подумав о правильных компромиссах.
Если наоборот вас все там напрягает, нет смысла терпеть.

Выглядеть как «один в поле воин»- дело неблагодарное по любому и карму портит

Успехов вам в разруливании ваших проблем с начальником

[Мальчик-Одуванчик]

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

[NtNet]

Что хочу сказать по данному вопросу ... чем дальше тем мудрее и все больше прихожу к выводу что какие то несогласия с коллегами и начальником будут всегда. Вопрос как с этим жить ?
Если вкратце то :
1) сначала надо определиться настолько ли разногласия необратимые что с ними нельзя жить?
2) подумать готовы ли вы меняться сами. То есть согласны ли на компромисс и какой?
2) если необратимые и на компромисс не согласны ни разу , то лучше сразу искать другую работу, людей вряд ли поменяете, тем более начальников, а это ваша жизнь. Ну и типа zip it up пока ничего не нашли
3) если готовы на компромисс, то найдите тот самый sweet spot где и волки сыты и овцы целы. Ну или попробуйте найти.

Посмотрите на себя со стороны, не выглядите ли вы героем, который «против всей планеты»? Увы, но у русскоязычных нередко репутация что они везде идут с лозунгом «мы наш мы новый мир построим». Объективно это может сильно расходиться с опытом другим коллег или тем что начальнику нужно deliver. Простой пример : нужно deliver in 3 months, а вы предлагаете «реорганизовать Рабкрин» и просите под это полгода, потому что «так правильно». Это неправильно . С точки зрения business goals , которые вам не видны например, а начальнику видны.

В общем жить в гармонии с рабочим коллективом - это тоже умение. Если вам подходит компенсация, график, технологии, you name it, то нет смысла лезть в бутылку, не подумав о правильных компромиссах.
Если наоборот вас все там напрягает, нет смысла терпеть.

Выглядеть как «один в поле воин»- дело неблагодарное по любому и карму портит

Успехов вам в разруливании ваших проблем с начальником

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

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

Зп категорически не устраивает, но я после еще неск мес личного тренинга + рабочего тренинга буду уже искать новую работу.

График, отпуска и в общем атмосфера устраивает. Атмосфера не на 100%, но на 60 точно.
В смысле что у меня были и более совместимые со мной команды и бизнесы интересные лично мне
Но с т зр технического опыта и знаний эта работа для меня супер ценна. Одна из самых ценных пока. Я чётко знаю зачем здесь и что дальше

А написала - просто на эмоциях, чтобы их "слить" сюда, а не на сотрудников ))

[Сабина]

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

Это мне ? Если вы так прочли, написанное мной - то вам да

[Сабина]

Я чётко знаю зачем здесь и что дальше
А написала - просто на эмоциях, чтобы их "слить" сюда, а не на сотрудников ))

Тогда все остальное приложиться.

[ARARAT.]

А почему нельзя считать, что работа ето всего лишь работа и не пытаться "жить" там...
У меня никогда не возникает никаких проблем именно потому, что выше.
Некоторые даже удивляются, типа етот же манагер ведь просто ужас-ужас, а ты с ним в ладах. Он не любит брать отвественность за свои ошибки и валит все на других и т.д. и т.п.
Я отвечаю, просто потому, что у меня с ним чисто рабочие отношения, я не развожу никаких сплетень и мне все равно на его "качества", только работа, все протокулируется мною и как что просто напросто "вот ваше первоначальное задание", получите и распишитесь. Ему некуда деваться просто, ответ: "Ой я забыл наверно... Я думал..." Мой ответ "В слeдущий раз не забывайте..."

[nyekimov]

А почему нельзя считать, что работа ето всего лишь работа и не пытаться "жить" там...
У меня никогда не возникает никаких проблем именно потому, что выше.
Некоторые даже удивляются, типа етот же манагер ведь просто ужас-ужас, а ты с ним в ладах. Он не любит брать отвественность за свои ошибки и валит все на других и т.д. и т.п.
Я отвечаю, просто потому, что у меня с ним чисто рабочие отношения, я не развожу никаких сплетень и мне все равно на его "качества", только работа, все протокулируется мною и как что просто напросто "вот ваше первоначальное задание", получите и распишитесь. Ему некуда деваться просто, ответ: "Ой я забыл наверно... Я думал..." Мой ответ "В слeдущий раз не забывайте..."

Люди критику воспринимают по разному раз. Затем начальники бывают разные, на ваше - «вот ваше первоначальное задание» ушлый менеджер может сказать - я же потом сказал поменять? Нет? Говорю вот сейчас иди переделывай.
А ещё ушлее могут даже добавить - чего то если не нравится, тебя никто тут не держит. И тут можно сглотнуть - всего лишь работа. А можно найти того, с кем разговор будет слаженней. Ведь в первую очередь от communication зависит насколько вырастет ваша зарплата при след ревью. В итоге все выливается тупо в бабки.
Но сам я больше сторонник того, что при любом communication можно найти подход. А если совсем слабый менеджер, то либо менять внутри компании; либо компанию. В Америке менять компанию уметь финансово выгодно, ну до тех пор пока не дорастёте до точки комфорта.

[ARARAT.]

А почему нельзя считать, что работа ето всего лишь работа и не пытаться "жить" там...
У меня никогда не возникает никаких проблем именно потому, что выше.
Некоторые даже удивляются, типа етот же манагер ведь просто ужас-ужас, а ты с ним в ладах. Он не любит брать отвественность за свои ошибки и валит все на других и т.д. и т.п.
Я отвечаю, просто потому, что у меня с ним чисто рабочие отношения, я не развожу никаких сплетень и мне все равно на его "качества", только работа, все протокулируется мною и как что просто напросто "вот ваше первоначальное задание", получите и распишитесь. Ему некуда деваться просто, ответ: "Ой я забыл наверно... Я думал..." Мой ответ "В слeдущий раз не забывайте..."

Люди критику воспринимают по разному раз. Затем начальники бывают разные, на ваше - «вот ваше первоначальное задание» ушлый менеджер может сказать - я же потом сказал поменять? Нет? Говорю вот сейчас иди переделывай.

Я достаю первоначальный job order и говорю изменяй и я переделаю(ето моя работа) с новым dead line и новым временем на изменение(иногда столько же сколько было первоначально, если изменяются главные условия задачи), no problems...
Что-бы было все задокументированно, не его словами, а его подписью.
Они "обучаются" при етом очень быстро, так как blame могут делать только себя, а не кого то другого...

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

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

[nyekimov]

А почему нельзя считать, что работа ето всего лишь работа и не пытаться "жить" там...
У меня никогда не возникает никаких проблем именно потому, что выше.
Некоторые даже удивляются, типа етот же манагер ведь просто ужас-ужас, а ты с ним в ладах. Он не любит брать отвественность за свои ошибки и валит все на других и т.д. и т.п.
Я отвечаю, просто потому, что у меня с ним чисто рабочие отношения, я не развожу никаких сплетень и мне все равно на его "качества", только работа, все протокулируется мною и как что просто напросто "вот ваше первоначальное задание", получите и распишитесь. Ему некуда деваться просто, ответ: "Ой я забыл наверно... Я думал..." Мой ответ "В слeдущий раз не забывайте..."

Люди критику воспринимают по разному раз. Затем начальники бывают разные, на ваше - «вот ваше первоначальное задание» ушлый менеджер может сказать - я же потом сказал поменять? Нет? Говорю вот сейчас иди переделывай.

Я достаю первоначальный job order и говорю изменяй и я переделаю(ето моя работа) с новым dead line и новым временем на изменение(иногда столько же сколько было первоначально, если изменяются главные условия задачи), no problems...
Что-бы было все задокументированно, не его словами, а его подписью.
Они "обучаются" при етом очень быстро, так как blame могут делать только себя, а не кого то другого...

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

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

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

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

[ARARAT.]

А почему нельзя считать, что работа ето всего лишь работа и не пытаться "жить" там...
У меня никогда не возникает никаких проблем именно потому, что выше.
Некоторые даже удивляются, типа етот же манагер ведь просто ужас-ужас, а ты с ним в ладах. Он не любит брать отвественность за свои ошибки и валит все на других и т.д. и т.п.
Я отвечаю, просто потому, что у меня с ним чисто рабочие отношения, я не развожу никаких сплетень и мне все равно на его "качества", только работа, все протокулируется мною и как что просто напросто "вот ваше первоначальное задание", получите и распишитесь. Ему некуда деваться просто, ответ: "Ой я забыл наверно... Я думал..." Мой ответ "В слeдущий раз не забывайте..."

Люди критику воспринимают по разному раз. Затем начальники бывают разные, на ваше - «вот ваше первоначальное задание» ушлый менеджер может сказать - я же потом сказал поменять? Нет? Говорю вот сейчас иди переделывай.

Я достаю первоначальный job order и говорю изменяй и я переделаю(ето моя работа) с новым dead line и новым временем на изменение(иногда столько же сколько было первоначально, если изменяются главные условия задачи), no problems...
Что-бы было все задокументированно, не его словами, а его подписью.
Они "обучаются" при етом очень быстро, так как blame могут делать только себя, а не кого то другого...

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

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

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

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

+1 в принципе согласен...
Ну я естественно обобщенно говорю... В крупной ето как сейчас у нас, сверху ставят задачу в общем, вы хотим вот "ето облако" в конечном итоге, идет обсуждение, что ето "облако" должно из себя представлять, дальше спускает ниже после разбивки и вот тут начинаешь реально работать... У нас обычно нас включают во весь треад от самого облака, до низа. Т.е. мы знаем кто что хотел, ето все через емаил сначало и затем уже job orders based on whole email tread.
Т.е. все задокументированно с самого начало до низа, исполнение job order тоже детально каждый step прописывается исполнителем(если комплексная задача конечно), если надо отправляешься на етот самый tread и вносишь/запрашиваешь изменение, вот ето сделать нельзя или потребует еще и ето и ето...
Короче все идет не разговорно, а документированно...

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

[Херовимчик]

Все сомнительные вопросы нужно обсуждать письменно. Все что сказано устно на митинге, to follow up on a meeting discussion we are going to do a, b, c ... is it correct or I missing something?
Потом очень сложно в бутылку лезть

[vdfs]

Tread это нечто другое. Как вы код-то пишете для работы с потоками.

[Сабина]

Requirements надо собирать по крупицам - это неправильно и для большой фирмы и для маленькой . Начальник в этом смысле конечно может помочь enforce some rules.
Но это нормальный начальник, с опытом, с умением организовать cross team interactions чтобы собрать requirements и поставить правильного человека сделать хороший дизайн , РОС прежде чем всем бежать кодировать.
Именно в большом коллективе, где команды разбивают функционал на куски ( поддержка большого веб-сайта например) видно какой в каждом тиме начальник - по количеству багов, production incidents, по тому сколько этот тим проводит времени resolving prod oncall etc.
То есть суть начальника размером команды или компании не определяется как мне кажется

[nyekimov]

Requirements надо собирать по крупицам - это неправильно и для большой фирмы и для маленькой . Начальник в этом смысле конечно может помочь enforce some rules.
Но это нормальный начальник, с опытом, с умением организовать cross team interactions чтобы собрать requirements и поставить правильного человека сделать хороший дизайн , РОС прежде чем всем бежать кодировать.
Именно в большом коллективе, где команды разбивают функционал на куски ( поддержка большого веб-сайта например) видно какой в каждом тиме начальник - по количеству багов, production incidents, по тому сколько этот тим проводит времени resolving prod oncall etc.
То есть суть начальника размером команды или компании не определяется как мне кажется

Нет ну может у вас в компании может быть один начальник; который все держит в своих руках, но бывает еще и так, что есть пару человек, которые разбирают самые главные детали как Лиды, а дальше работает команда, иначе зачем команды нужны? Зачем вообще весь agile с постоянным фидбеком.
У нас больше ценится то, что каждый сениор может взять кусок и вникнуть во все детали, если нашёл какой edge case, и о нем как то забыли ввиду того, что система очень большая. То сениор должен сам найти ответ, задействовав нужных людей. Кое где роль утончения и документирования требований выполняет бизнес аналитик, но кое где их просто упростили.
На самой первой фирме консалтин шопе задачи давали уже разжеванные, все требования записаны. Только edge cases изредка вылезали в qa стадии. Хотя приложения там были элементарные и небольшие. Ну и оплата была намного ниже, чем в корпах, где у человека должен быть сильный опыт, чтобы просто въехать как работают модули между собой и быть готовым фиксить даже сторонний модуль, если он ломается где то на моменте интеграции. А модулей этих может быть просто дремучий лес, ведь разные Модули ещё писались в разное время.

[Херовимчик]

Но это нормальный начальник, с опытом, с умением организовать cross team interactions чтобы собрать requirements и поставить правильного человека сделать хороший дизайн , РОС прежде чем всем бежать кодировать.

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