Да, люди, выдавленные ею из компании, нашли себе хорошие места для дальнейшей работы. Пострадала компания в целом и конкретные команды, которых лишили классных руководителей. Некоторые команды особенно жаль, потому что вместо опытных эффективных директоров они получили дурачков, вообще не понимающих реалии разработки софта (но при этом действующих в интересах той тёти).
Тётку не уволили, тётка с тех пор захватила ещё больше власти. Компания пока тоже не развалилась. Всё-таки это транснациональная корпорация, и одна тётка её не развалит, даже если это будет CEO. Но тем не менее, постепенная деградация идёт. Адекватных людей всё меньше, инноваций нет, акции стабильно снижаются уже несколько лет
Про задачки, приближенные к практике, я согласен. Сам постоянно даю такие. Собственно, задача, которую кандидат отказался брать на дом, была такой. Я специально придумал её таким образом, чтобы она была творческой и приближенной к реальным потребностям конторы.
Но на мой вкус, модельные задачи важны, однако не заменяют реального "боевого" опыта. К тому же более-менее крупные задачи легко давать младшим и средним специалистам, а старшие специалисты часто от них отказываются. Понятно, что если вакансия очень лакомая, и на неё прямо ломятся лучшие специалисты, то можно любые условия выставлять. Но далеко не все вакансии такие. Так что приходится подстраиваться под реалии и учитывать, что от творческой задачи кандидат может отказаться (но при этом это все равно может быть подходящий кандидат)
Я всегда уделяю большое внимание опыту кандидата. Во-первых, так я узнаю о жизни других компаний и, возможно, даже сам чему-то учусь. Во-вторых, люди, которые идеально решают модельные задачи (которые я предлагаю им на собеседовании), но не умеют решать практические задачи, для меня не выглядят подходящими кандидатами.
Хочу даже написать статью (видимо, уже не для Хабра) про выявление практического опыта кандидата. Дело в том, что про него часто врут. Иногда даже старшие разработчики
А можете привести 1-2 примера ваших удачных запросов к GPT? Интересно посмотреть, в чем именно модель оказалась полезной, а также как именно люди формулируют свои запросы к ней
Под "зоной ответственности" я понимаю то, что должна делать компонента. Подробный пример потребовал бы много времени. Однако в одном из запланированных постов, на тему технического долга, будет такой пример.
В документации я прямым текстом пишу, что решение подразумевает создание новых компонент, у каждой из них будет такая-то зона ответственности. Дополнительно отражаю эту ответственность в названиях компонент, чтобы сразу было понятно, чем они должны заниматься, а чем - нет.
По моему опыту, не-архитекторы не очень хорошо справляются с назначением зон ответственности. Тому я вижу несколько причин: 1) у разработчиков и менджеров по разработке меньше кругозор. Они могут не учитывать полной картины. И это вполне понятно, потому что им, в основном, приходится концентрироваться на собственных компонентах либо на ближайших соседях 2) разработчики и менеджеры часто стремятся максимально сосредоточить разработку в подконтрольных им компонентах. Потому что это понятнее и быстрее позволяет прийти к результату 3) сейчас все больше менеджеров и разработчиков (хотя и не все, конечно же) стремятся прийти к результату по кратчайшему пути, чтобы побольше медалей получить на погоны в конце года. Долгосрочное развитие часто не принимается во внимание, потому что народ все меньше работает на одном месте. Одна из частых мыслей во время принятия неоптимальных решений: "Меня через два года уже не будет в этой компании". Впрочем, "кратчайший путь" - это часто иллюзия... Срезая неправильные углы, люди часто огребают по полной. И вместо пары месяцев идут в продакшн полтора года (и у меня есть реальные примеры).
Вспомнил о тех продуктах, над которыми сам работал. Я бы сказал, что ничего, за исключением того, что очевидные лишние пункты уйдут. Но от специфики конректного бизнеса могут меняться акценты, либо исчезать/добавляться новые проблемы. Из своего опыта могу вспомнить проекты, которые предполагали активный вклад в Open Source или программно-аппаратный co-design (или даже и то, и другое сразу). Конкретно для этих случаев мой список был бы немного другим, но по большей части все равно остался бы тем же.
Для документирования: Confluence, Microsoft Word. Однако лучшая документация должна жить в самом коде или каким-либо образом автоматически строиться на "живых" системах. Возможно, напишу как-нибудь об этом.
Конкретно для рисования диаграмм предпочитаю Draw.io (это визуальный редактор, очень шустрый) и PlantUML (генерирует sequence-диаграммы по текстовому описанию; очень удобно, если необходимо сравнивать разные ревизии диаграмм между собой, потому что текст сравнивать проще, чем картинки). Еще могу порекомендовать Enterprise Architect. Но это уже не просто рисовалка диаграмм. Это целый фрейморк для проективания систем и решений Enterprise-уровня. Там очень богатый функционал
Подумаю над этим, но обещать такой пост пока не могу. Скажу честно: пока что не знаю, как писать на тему аджайла. Абстрактные принципы там просты, и они уже много где разобраны со всех сторон. Интересно именно разобрать как они реализуются в контексте конкретного бизнеса. Потому что у каждого бизнеса свои собственные препятствия на пути к реализации аджайла. Проблема в том, что анализировать конкретные бизнесы публично обычно нельзя...
Ох... То, как ведется разработка solutions-архитектуры в условиях Agile - это большой и непростой вопрос. Развернутый ответ с примерами потребовал бы отдельного большого поста. Давайте, я отвечу общо: если бизнес большой и сложный, и в продукт/решение вовлечено множество программных компонент, то все перечисленные в посте вопросы придется решать независимо от того, какая методология разработки используется в компании.
Поэтому, если коротко, то да, чек-лист актуален для Agile. И даже не зависит от конкретной методологии разработки. Методология будет влиять только на то, как именно вы идете от идеи к реализации.
Да, к сожалению, наш контроль над нашими же смартфонами далек от полного… И пользовательские соглашения для приложений все больше напоминают историю: «соглашайтесь на всё или никакого сервиса не получите».
Внешних карт памяти у меня нет. Все, что я сделал после покупки нового телефона, — это вошел с него в аккаунт Google и воспользовался функцией восстановления приложений. Контакты и настройки приложений — это единственно, что у меня бэкапится в облако. Все остальные бэкапы (в том числе и на уровне приложений) запрещены.
Думаю, работа «в склад» действительно может случаться на некоторых производствах при определенной конъюнктуре. Там, где остановка производственных мощностей очень дорого обходится. Например, остановка (и обратный запуск) нефтяной скважины — дело очень затратное.
Поэтому если в краткосрочном периоде цена уходит ниже себестоимости, возможно, есть смысл поработать в хранилище.
Но в большинстве случаев такого, конечно, не бывает.
С DRAM как раз ситуация обратная. В этом году цены практически на все компы выросли из-за недостатка памяти на рынке. Производители памяти знали о ситуации, но предпочли не инвестировать в дополнительное производство. Вместо этого взвинтили цены. Отсюда и подорожание всего остального, в чем есть память. Но это длинная история. Там много интересных моментов. Вот для затравочки:
http://www.dramexchange.com/WeeklyResearch/Post/2/4563.html
http://www.dramexchange.com/WeeklyResearch/Post/2/4618.html
По-моему, это мертвая тема.
Хотя, несомненно, заслуженная :)
DAOS использовался в самой первой реализации Burst Buffer'ов совместно с EMC и HDF Group в 2012 году. Эту работу проспонсировал американский Department of Energy.
Насколько мне известно, до продуктизации DAOS дело никогда не доходило. Только экспериментальные наработки…
Да, люди, выдавленные ею из компании, нашли себе хорошие места для дальнейшей работы. Пострадала компания в целом и конкретные команды, которых лишили классных руководителей. Некоторые команды особенно жаль, потому что вместо опытных эффективных директоров они получили дурачков, вообще не понимающих реалии разработки софта (но при этом действующих в интересах той тёти).
Тётку не уволили, тётка с тех пор захватила ещё больше власти. Компания пока тоже не развалилась. Всё-таки это транснациональная корпорация, и одна тётка её не развалит, даже если это будет CEO. Но тем не менее, постепенная деградация идёт. Адекватных людей всё меньше, инноваций нет, акции стабильно снижаются уже несколько лет
Спасибо за подробный рассказ о вашем подходе! Очень интересно!
Про задачки, приближенные к практике, я согласен. Сам постоянно даю такие. Собственно, задача, которую кандидат отказался брать на дом, была такой. Я специально придумал её таким образом, чтобы она была творческой и приближенной к реальным потребностям конторы.
Но на мой вкус, модельные задачи важны, однако не заменяют реального "боевого" опыта. К тому же более-менее крупные задачи легко давать младшим и средним специалистам, а старшие специалисты часто от них отказываются. Понятно, что если вакансия очень лакомая, и на неё прямо ломятся лучшие специалисты, то можно любые условия выставлять. Но далеко не все вакансии такие. Так что приходится подстраиваться под реалии и учитывать, что от творческой задачи кандидат может отказаться (но при этом это все равно может быть подходящий кандидат)
Спасибо за интерес!
Я всегда уделяю большое внимание опыту кандидата. Во-первых, так я узнаю о жизни других компаний и, возможно, даже сам чему-то учусь. Во-вторых, люди, которые идеально решают модельные задачи (которые я предлагаю им на собеседовании), но не умеют решать практические задачи, для меня не выглядят подходящими кандидатами.
Хочу даже написать статью (видимо, уже не для Хабра) про выявление практического опыта кандидата. Дело в том, что про него часто врут. Иногда даже старшие разработчики
Ого! Фудаментально :) Спасибо за примеры!
А можете привести 1-2 примера ваших удачных запросов к GPT? Интересно посмотреть, в чем именно модель оказалась полезной, а также как именно люди формулируют свои запросы к ней
Спасибо за отклик!
Под "зоной ответственности" я понимаю то, что должна делать компонента. Подробный пример потребовал бы много времени. Однако в одном из запланированных постов, на тему технического долга, будет такой пример.
В документации я прямым текстом пишу, что решение подразумевает создание новых компонент, у каждой из них будет такая-то зона ответственности. Дополнительно отражаю эту ответственность в названиях компонент, чтобы сразу было понятно, чем они должны заниматься, а чем - нет.
По моему опыту, не-архитекторы не очень хорошо справляются с назначением зон ответственности. Тому я вижу несколько причин:
1) у разработчиков и менджеров по разработке меньше кругозор. Они могут не учитывать полной картины. И это вполне понятно, потому что им, в основном, приходится концентрироваться на собственных компонентах либо на ближайших соседях
2) разработчики и менеджеры часто стремятся максимально сосредоточить разработку в подконтрольных им компонентах. Потому что это понятнее и быстрее позволяет прийти к результату
3) сейчас все больше менеджеров и разработчиков (хотя и не все, конечно же) стремятся прийти к результату по кратчайшему пути, чтобы побольше медалей получить на погоны в конце года. Долгосрочное развитие часто не принимается во внимание, потому что народ все меньше работает на одном месте. Одна из частых мыслей во время принятия неоптимальных решений: "Меня через два года уже не будет в этой компании". Впрочем, "кратчайший путь" - это часто иллюзия... Срезая неправильные углы, люди часто огребают по полной. И вместо пары месяцев идут в продакшн полтора года (и у меня есть реальные примеры).
Вспомнил о тех продуктах, над которыми сам работал. Я бы сказал, что ничего, за исключением того, что очевидные лишние пункты уйдут. Но от специфики конректного бизнеса могут меняться акценты, либо исчезать/добавляться новые проблемы. Из своего опыта могу вспомнить проекты, которые предполагали активный вклад в Open Source или программно-аппаратный co-design (или даже и то, и другое сразу). Конкретно для этих случаев мой список был бы немного другим, но по большей части все равно остался бы тем же.
Спасибо за интерес!
Для документирования: Confluence, Microsoft Word. Однако лучшая документация должна жить в самом коде или каким-либо образом автоматически строиться на "живых" системах. Возможно, напишу как-нибудь об этом.
Конкретно для рисования диаграмм предпочитаю Draw.io (это визуальный редактор, очень шустрый) и PlantUML (генерирует sequence-диаграммы по текстовому описанию; очень удобно, если необходимо сравнивать разные ревизии диаграмм между собой, потому что текст сравнивать проще, чем картинки). Еще могу порекомендовать Enterprise Architect. Но это уже не просто рисовалка диаграмм. Это целый фрейморк для проективания систем и решений Enterprise-уровня. Там очень богатый функционал
Подумаю над этим, но обещать такой пост пока не могу. Скажу честно: пока что не знаю, как писать на тему аджайла. Абстрактные принципы там просты, и они уже много где разобраны со всех сторон. Интересно именно разобрать как они реализуются в контексте конкретного бизнеса. Потому что у каждого бизнеса свои собственные препятствия на пути к реализации аджайла. Проблема в том, что анализировать конкретные бизнесы публично обычно нельзя...
Ох... То, как ведется разработка solutions-архитектуры в условиях Agile - это большой и непростой вопрос. Развернутый ответ с примерами потребовал бы отдельного большого поста. Давайте, я отвечу общо: если бизнес большой и сложный, и в продукт/решение вовлечено множество программных компонент, то все перечисленные в посте вопросы придется решать независимо от того, какая методология разработки используется в компании.
Поэтому, если коротко, то да, чек-лист актуален для Agile. И даже не зависит от конкретной методологии разработки. Методология будет влиять только на то, как именно вы идете от идеи к реализации.
Поэтому если в краткосрочном периоде цена уходит ниже себестоимости, возможно, есть смысл поработать в хранилище.
Но в большинстве случаев такого, конечно, не бывает.
http://www.dramexchange.com/WeeklyResearch/Post/2/4563.html
http://www.dramexchange.com/WeeklyResearch/Post/2/4618.html
Вы занимаетесь системами хранения?
Хотя, несомненно, заслуженная :)
DAOS использовался в самой первой реализации Burst Buffer'ов совместно с EMC и HDF Group в 2012 году. Эту работу проспонсировал американский Department of Energy.
Насколько мне известно, до продуктизации DAOS дело никогда не доходило. Только экспериментальные наработки…
Спасибо, что вспомнили о нем!