ORM — зло, т.к. пытается «впихнуть не впихуемое».
Т.е. создать «универсальный преобразователь» из РМД в ООМД.
Пока модели простые, все замечательно, по мере усложнения модели начинают вылазить не стыковки.
Т.к. бизнес сущность обычно не может быть выражена один в один в виде таблицы РМД.
Да.
Для этого планерки и вводятся.
Чтобы показать в какой «точке проекта» находится сотрудник.
Это просто еще один способ «контроля/мониторинга» проекта, ну и «дисциплинирует» сотрудника.
Т.е. каждый раз ему нужно демонстрировать прогресс.
Как минимум показать, что он хотя бы «лежал в сторону цели» :-)
ИМХО менеджер вообще не должен быть инициатором совещания.
Для мониторинга текущего состояния у него должны быть утренные планерки.
Где просто каждый участник проекта отмечает «свои координаты», что сделал, что будет делать.
Инициатива совещаний должна быть снизу.
Т.е., например разработчик в команде столкнулся с проблемой, которую в одиночку не может решить.
Чаще всего это когда проблема не в его зоне ответственности.
Тогда да совещание нужно, чтобы решить проблему или наметить путь решения проблемы.
На самом деле вариант только один — смириться.
Переезд не вариант. Ибо жена/ребенок/ипотека.
Кого-то что-то заставлять, мне нужна от людей помощь/содействие.
И не хотелось бы их заставлять делать.
Т.к. это надо мне, а не им.
Поэтому и говорю, что это неудобство.
Не надо сопротивляться своему желанию!
Хочется поболтать — поболтайте! ;-)
А так…
Лично меня в опенспейсе напрягала духота.
Особенно когда сидишь далеко от окна.
Где-то ч/з час-два работы хотелось спать сильно.
Зимой вообще жесть. Даже окно открыть нельзя, т.к. многим «дует».
Вот и ходишь постоянно к кофейному автомату…
Так и сейчас каждый сотрудник на связи.
Я работаю удаленно, а остальная команда в офисе в другом городе.
Но все равно, есть лаг при «запросе».
Который в офисе стремился к нулю.
Да ну, open space это клево!
Всегда можно потрепать языком.
Обсудить все начиная от политики, заканчивая кто что вчера ел.
Попить чай/кофе с коллегами. Заказать пиццу.
Ну а поработать можно всегда дома в спокойной обстановке… :-)
Сейчас работаю удаленно.
Сложность для меня это проблемы с коммуникацией.
Если что-то надо «срочно» узнать/спросить.
Приходится писать в трех мессенджерах и эл. почте.
То что в офисе решается за 5 минут, удаленно решается около часа и больше.
А так, по шуму, концентрации и пр. разницы нет.
Недавно родился сын, но он мне мешает, не больше чем коллеги в офисе.
Как минимум, если надо сосредоточиться есть наушники и музыка.
Пример атомный проект СССР и США.
Где возглавляли/управляли те у кого не всегда был опыт научных разработок и создание атомной промышленности :-)
Тут дело все в делегировании и кадровой политике.
Хороший руководитель найдет тех, кто может решать поставленные задачи и обеспечит им условия для работы.
В ваших словах противоречие — «назначает сроки», " Если совещаются по срокам, он туда не идёт.".
Ну как бы архитектор, по вашему, ответственен за сроки.
Т.к. он их поставил и это его зона ответственности.
И при этом он не идет на совещание по срокам.
Обычно на таких совещаниях (если они с заказчиками) можно «отстоять» свои сроки.
Девятое правило, это типичная отрицательная спираль развития.
Вместо того, чтобы привлекать хороших специалистов (условиями работы, проектами и т.д.), отсеивают «плохих».
Большой простор для «подковерных игр» и создания «серпентария».
:-)
Ну как бы примеры есть.
Вчера расстреливал врагов народа, сегодня испытал атомную бомбу <:o)
Иметь опыт разработки для руководителя разработчика желательно, но по моему не обязательно.
Главное, чтобы понимал, что делают программисты.
А этого можно добиться не имея практических навыков.
ИМХО любые тесты/задачи проверяют, то что вы умете/знаете ответы на конкретные тесты и задачи.
К мышлению это очень слабо относиться.
Например я уже знал решения для половины ваших задач.
А то что не знал легко нагуглил.
Сейчас, когда информация находится на кончике пальцев, только на испытательном сроке можно понять — может человек работать или нет.
P.S. Код с комментариями очень трудно читать. Т.к. «все лгут», а уж комментарии особенно.
Вместо кучи комментариев, я бы предпочел хотя бы 50% покрытие unit-тестами. :-)
Здравствуйте.
А были случат когда для клиента все инстансы нужного микросервиса уходили в бан?
Насколько я понимаю, от этого должен защитить механизм circuit breaker.
Но он работает «с лагом», поэтому возможна ли такая ситуация.
Можно было сказать проще.
Индустрия программирование еще не достигла уровня индустриальной промышленности.
А болтается где-то на уровне мануфактуры/кустарного производства.
:-)
Т.е. создать «универсальный преобразователь» из РМД в ООМД.
Пока модели простые, все замечательно, по мере усложнения модели начинают вылазить не стыковки.
Т.к. бизнес сущность обычно не может быть выражена один в один в виде таблицы РМД.
Для этого планерки и вводятся.
Чтобы показать в какой «точке проекта» находится сотрудник.
Это просто еще один способ «контроля/мониторинга» проекта, ну и «дисциплинирует» сотрудника.
Т.е. каждый раз ему нужно демонстрировать прогресс.
Как минимум показать, что он хотя бы «лежал в сторону цели» :-)
Для мониторинга текущего состояния у него должны быть утренные планерки.
Где просто каждый участник проекта отмечает «свои координаты», что сделал, что будет делать.
Инициатива совещаний должна быть снизу.
Т.е., например разработчик в команде столкнулся с проблемой, которую в одиночку не может решить.
Чаще всего это когда проблема не в его зоне ответственности.
Тогда да совещание нужно, чтобы решить проблему или наметить путь решения проблемы.
Переезд не вариант. Ибо жена/ребенок/ипотека.
Кого-то что-то заставлять, мне нужна от людей помощь/содействие.
И не хотелось бы их заставлять делать.
Т.к. это надо мне, а не им.
Поэтому и говорю, что это неудобство.
Хочется поболтать — поболтайте! ;-)
А так…
Лично меня в опенспейсе напрягала духота.
Особенно когда сидишь далеко от окна.
Где-то ч/з час-два работы хотелось спать сильно.
Зимой вообще жесть. Даже окно открыть нельзя, т.к. многим «дует».
Вот и ходишь постоянно к кофейному автомату…
Я работаю удаленно, а остальная команда в офисе в другом городе.
Но все равно, есть лаг при «запросе».
Который в офисе стремился к нулю.
Всегда можно потрепать языком.
Обсудить все начиная от политики, заканчивая кто что вчера ел.
Попить чай/кофе с коллегами. Заказать пиццу.
Ну а поработать можно всегда дома в спокойной обстановке… :-)
Сейчас работаю удаленно.
Сложность для меня это проблемы с коммуникацией.
Если что-то надо «срочно» узнать/спросить.
Приходится писать в трех мессенджерах и эл. почте.
То что в офисе решается за 5 минут, удаленно решается около часа и больше.
А так, по шуму, концентрации и пр. разницы нет.
Недавно родился сын, но он мне мешает, не больше чем коллеги в офисе.
Как минимум, если надо сосредоточиться есть наушники и музыка.
Пипл то хавает. :-)
Где возглавляли/управляли те у кого не всегда был опыт научных разработок и создание атомной промышленности :-)
Тут дело все в делегировании и кадровой политике.
Хороший руководитель найдет тех, кто может решать поставленные задачи и обеспечит им условия для работы.
Ну как бы архитектор, по вашему, ответственен за сроки.
Т.к. он их поставил и это его зона ответственности.
И при этом он не идет на совещание по срокам.
Обычно на таких совещаниях (если они с заказчиками) можно «отстоять» свои сроки.
Вместо того, чтобы привлекать хороших специалистов (условиями работы, проектами и т.д.), отсеивают «плохих».
Большой простор для «подковерных игр» и создания «серпентария».
:-)
Вчера расстреливал врагов народа, сегодня испытал атомную бомбу <:o)
Иметь опыт разработки для руководителя разработчика желательно, но по моему не обязательно.
Главное, чтобы понимал, что делают программисты.
А этого можно добиться не имея практических навыков.
К мышлению это очень слабо относиться.
Например я уже знал решения для половины ваших задач.
А то что не знал легко нагуглил.
Сейчас, когда информация находится на кончике пальцев, только на испытательном сроке можно понять — может человек работать или нет.
P.S. Код с комментариями очень трудно читать. Т.к. «все лгут», а уж комментарии особенно.
Вместо кучи комментариев, я бы предпочел хотя бы 50% покрытие unit-тестами. :-)
Не надо с прокрастинацией бороться!
Ей надо наслаждаться!
<:o)
А были случат когда для клиента все инстансы нужного микросервиса уходили в бан?
Насколько я понимаю, от этого должен защитить механизм circuit breaker.
Но он работает «с лагом», поэтому возможна ли такая ситуация.
<:o)
Индустрия программирование еще не достигла уровня индустриальной промышленности.
А болтается где-то на уровне мануфактуры/кустарного производства.
:-)