Есть на работе T410 2010 года, в свое время добавил памяти до 8 Гб, поставил диск SSD, проапгрейдил windows до 10. Хорошая лошадка, до сих пор полезная в хозяйстве.
Единственная претензия — wifi с поддержкой только 2.4 ГГц, 802.11n и без современных наворотов. Его тоже можно поменять, но как-то руки не доходят.
Ну автор в статье упоминал канбан, я так понял, ему «зашло». Диаграмма Ганта — она скорее для оценки времени выполнения целого проекта или большого этапа проекта, а канбан — для структурирования входящих запросов и выстраивания приоритетов.
Мутная задача — прежде всего плохо поставленная задача. Разделить её на понятные, т. е. которые можно делегировать подчинённым «по S.M.A.R.T.» — это и есть задача тимлида. Парадокс, но иногда для этого надо немного покодить :)
По п. 1 — кодить всё равно приходится, но нужно брать только те задачи, которые невозможно делегировать. Как правило, это самые «мутные», плохо сформулированные задачи. Как только задача стала яснее (например, её удалось декомпозировать) — нужно постараться сразу отдать хотя бы часть.
По п. 2 — есть примерно такая формулировка: «Инструменты разработчика — компилятор, IDE, линтер и т. п., инструменты тимлида — прежде всего другие разработчики, а потом уже компилятор, IDE, линтер и т. п.». Музыканты ещё говорят, что дирижёр — это такой музыкант, который играет «на оркестре».
По п. 3 — планирование всегда больной вопрос. Во-первых, на планирование надо выделять отдельное время. Например, полчаса с утра для того чтобы подвигать задачи на своей личной канбан-доске. Во-вторых, рекомендация для других людей «планировать встречи, глядя в ваш календарь» — очень спорная. К сожалению, некоторые коллеги страдают болезнью «скучно? собери совещание!», и ты вдруг понимаешь, что у тебя вообще весь календарь расписан какими-то непонятными встречами. И поэтому в-третьих, следует приучить коллег, что вопросы надо решать в порядке приоритета - коротким сообщением в мессенджер, письмом, звонком, и если только не получается договориться - собирать совещание.
В порядке обмена опытом — если задачи не выстраиваются «друг за другом», т. е. их взанимное влияние неочевидно, вместо канбана (или в дополнение) хороша техника «ментальных карт» (mind maps). Особенно полезна при сложных миграциях, где надо обеспечить непрерывность сервиса.
По п. 4 — да, всё так, стоит тимлиду расслабиться, и проектная команда начинает вешать на него принятие всех мелких и не очень мелких решений. Нужно уметь «возвращать» вопрос, т. е. спрашивать «а что бы сделал ты? а почему так? а какие вообще ты здесь видишь варианты? какие из них лучше?» Именно так сотрудники и развиваются. Также нужно учить сотрудников «не держать информацию в себе» — сообщать тимлиду о проблемах — немедленно, другим участникам проекта — какие решения приняты и почему.
Цель же не в том, чтобы «прессовать» — цель в том, чтобы за один час собеседования приблизительно понять, что человек умеет, чему его придется учить, сколько времени займет обучение, и чему он в результате научится быстро, а чему — будет учиться долго или не научится никогда, как-то так.
Я в общем тоже наверное хороший полицейский (стараюсь быть, кандидатам виднее).
Страхи отчасти обоснованны — почти никто в институте и на работе целенаправленно не учит теорию, не копит теоретические знания, не складывает специально их в систему. Студенты к экзамену учат «билеты». Те, кто уже работает, доводят до совершенства навыки, нужные именно на данной работе, и изо дня в день их успешно применяют, максимально избагая рабочего стресса.
На собеседовании картина меняется. Потенциальному работодателю важно, насколько быстро и успешно кандидат вольётся в проект и возьмёт на себя часть задач. На этом этапе у нового работника точно возникнет стресс, и реакцию на этот стресс хорошо бы увидеть уже на собеседовании. Так что потенциальный руководитель будет всегда «копать в глубину» и пытаться найти вопрос, на который кандидат не ответит, это важно уже для его карьеры.
Надо сказать, что собеседующие тоже не всегда демонстрируют лучшие качества — например, не пытаются выслушать и проанализировать ответы кандидата, а пытаются уложить эти ответы в ими же придуманную псевдо-идеальную картину.
Хорошая книга. В свое время именно в ней я нешёл ответ на вопрос «почему продукты компании Микрософт вроде бы всем хороши, но их использование не приносит радости». Рекомендую прочитать ее не только специалистам по UI/UX, но и программистам (чтобы разрабатывать хорошие API), безопасникам (чтобы разрабатывать хорошие политики ИБ), да и вообще всем, кто хочет делать жизнь людей удобнее.
Нужно превратить этот вопрос в "как позвать на курсы тех, кому оно надо"
Можно поставить вопрос ещё шире — например, «как принять на работу тех, кто будет хорошо работать». Пока наша концепция (для начинающих специалистов) — чтобы был интерес к тому, чем мы занимаемся (и к ИТ в принципе). Остальному можно научить и научиться.
На «каких-то курсах» научиться «нормально» нельзя ничему — здесь задача осуществить bootstrap и показать направление, куда двигаться (это вообще любых курсов касается).
Верно и обратное — те сотрудники, которым можно показать направление, и они сами начинают в том направлении идти, быстрее всех прогрессируют, и очень ценятся работодателями.
А дальше 2 варианта - либо человек сидит и использует только стандартные заученные конструкции в коде и не может ничего толком написать (зачем ему тогда пайтон, если конструкции в ансибле запомнить проще?)
Это вообще самый сложный вопрос подготовки (и самоподготовки) любого специалиста — как сделать так, чтобы знания сложились в систему. Здесь нет однозначного ответа (за годы преподавательского опыта я его так и не нашел). Мне кажется, что нужные нейронные связи будущий специалист может сформировать только сам — пробуя, ошибаясь, размышляя, и берясь за всё более сложные задачи. Это стресс, это боль, но пойти по «простому» пути (годами использовать стандартные конструкции для решения стандартных задач) — тоже невесело, и ценность такого специалиста будет со временем падать.
Про shell и ansible — всё так и есть, а дальше возникают вопросы
можно и нужно показать golang. ... безапялицонно показывать людям python как первый инструмент для автоматизации ops-работы - плохой путь. Это полноценный ЯП
golang я не знаю (видел издали, слышал хорошие отзывы, но ни строчки кода на нём не написал), впечатления от него — это хороший, полнофункциональный язык, особенно для того чтобы быстро и качественно написать backend-часть веб-приложения.
Почему вы его противопоставляете питону, называя питон «полноценным ЯП»? Чем golang менее «полноценен»?
Давайте воспользуемся принципом «критикуешь — предлагай». К питону как к первому языку у меня тоже масса вопросов, но на чём ещё учить? В вузах сейчас учат в основном сразу на несуществующем языке «С/С++» (ибо «индустрия требует»), и ребята приходят к нам уже с психотравмой и стойким отвращением к написанию кода. Идти по пути, предлагаемому Столяровым — методически правильно, но на это нужен плюс-минус год. Какие ещё есть варианты?
Ну точно не про нашу компанию, и не про наше подразделение. У нас скорее другая проблема — когда молодой и очень старательный инженер в текстовом редакторе перепиливает 100500 правил ACL из формата, условно, cisco, в формат, условно, iptables, и пользуется максимум поиском/заменой. Хотя никто не запрещает ни bash, ни awk, ни регулярные выражения, ни perl, ни python.
Статья — попытка начать дискуссию на тему «почему инженер/админ/связист боится/не хочет написать нужный ему по работе кусок кода» и как ему можно помочь (захотеть). Вернее, вынести наши внутренние обсуждения на эти темы на более широкую аудиторию. Готовы об этом поговорить?
Спасибо за развернутый комментарий. Да, мы с помощью курса пытались решить именно наши задачи. Как получилось — лучше расскажут сами участники обучения (а также те, с кем они вместе работают). По поводу деления наук на «первый и второй уровни» — спорное утверждение. Хорошая вузовская программа предусматривает теорию (лекции, семинары) и практику (лабы, курсовые). Алгоритмы, дискретная математика, теория формальных языков, реляционная алгебра — это теория. А написание кода на конкретном языке — это, конечно же, практика. В наших условиях мы, конечно же, можем дать в основном практику. Теорию — только «по верхам», в расчете, что кто-то заинтересуется и пойдет читать книжки.
У Cisco есть ISE, но к нему — масса вопросов. Управление политиками там реализовано, мягко говоря, своеобразно.Мы были в похожей ситуации, и дело кончилось заменой VPN-решения. Вообще же, etnerprise-подход должен выглядеть так: помещаем пользователей в группы AD, и далее все VPN-шлюзы сами на основе членства в группах формируют при подключении пользователя персональные политики доступа. Связка ASA+ISE, PaloAlto, Fortinet — умеют такое в каком-то виде, но, как всегда, «не совсем так как хочется».
На самом деле, поднятая в статье проблема очень серьёзная. Работники обычно а) не идиоты б) любят деньги, поэтому если им установить KPI — они будут добросовестно исполнять KPI.
Если в результате такого добросовестного исполнения получается полная фигня — далеко не каждый руководитель сможет решить проблему и грамотно скорректировать показатели. Бывают и такие, которые отказываются признать, что проблема вообще существует, увы.
> Чем вам Керниган-Ритчи и Си как первый язык для обучения основам не угодил.
Строгий «академический» ответ на этот вопрос приведен в монографии Столярова, ссылку на которую дали в комментах выше.
А я по-простому скажу. Си похож одновременно на самурайский меч, турецкую саблю и мушкетёрскую шпагу — устроен очень просто, в нём почти ничего нет, но приёмы написания программ на нём — сложны и замысловаты. И для освоения именно этих приёмов (и безопасного их применения!) нужно много специальных знаний.
Таким образом, изучение Си на уровне чуть выше элементарного тут же превращатся в изучение операционной системы (что такое файл? а дескриптор файла? И зачем функция dup2?), архитектуры компьютера (ошибки buffer overflow где-то рядом, а вместе с ними — опасные уязвимости) и прочих интересных вещей. Такие знания, разумеется, программисту тоже нужны, но на самом начальном этапе обучения программированию у студента начинается информационный перегруз — он не в состоянии справиться с потоком сведений и отделить важное от неважного, как, собственно, и произошло с автором исходного поста.
Мы и не отказываемся. Мы — интегратор, наша основная работа — помочь заказчику справиться с его зоопарком.
Мое мнение — «хороших» вендоров не бывает. Допускаю правда, что это профдеформация, потому что когда всё хорошо работает (т. е. без напильника и интуитивно понятно), нас не зовут.
Есть на работе T410 2010 года, в свое время добавил памяти до 8 Гб, поставил диск SSD, проапгрейдил windows до 10. Хорошая лошадка, до сих пор полезная в хозяйстве.
Единственная претензия — wifi с поддержкой только 2.4 ГГц, 802.11n и без современных наворотов. Его тоже можно поменять, но как-то руки не доходят.
Ну автор в статье упоминал канбан, я так понял, ему «зашло». Диаграмма Ганта — она скорее для оценки времени выполнения целого проекта или большого этапа проекта, а канбан — для структурирования входящих запросов и выстраивания приоритетов.
Мутная задача — прежде всего плохо поставленная задача. Разделить её на понятные, т. е. которые можно делегировать подчинённым «по S.M.A.R.T.» — это и есть задача тимлида. Парадокс, но иногда для этого надо немного покодить :)
Очень хорошо всё расписано, немного дополню.
По п. 1 — кодить всё равно приходится, но нужно брать только те задачи, которые невозможно делегировать. Как правило, это самые «мутные», плохо сформулированные задачи. Как только задача стала яснее (например, её удалось декомпозировать) — нужно постараться сразу отдать хотя бы часть.
По п. 2 — есть примерно такая формулировка: «Инструменты разработчика — компилятор, IDE, линтер и т. п., инструменты тимлида — прежде всего другие разработчики, а потом уже компилятор, IDE, линтер и т. п.». Музыканты ещё говорят, что дирижёр — это такой музыкант, который играет «на оркестре».
По п. 3 — планирование всегда больной вопрос. Во-первых, на планирование надо выделять отдельное время. Например, полчаса с утра для того чтобы подвигать задачи на своей личной канбан-доске. Во-вторых, рекомендация для других людей «планировать встречи, глядя в ваш календарь» — очень спорная. К сожалению, некоторые коллеги страдают болезнью «скучно? собери совещание!», и ты вдруг понимаешь, что у тебя вообще весь календарь расписан какими-то непонятными встречами. И поэтому в-третьих, следует приучить коллег, что вопросы надо решать в порядке приоритета - коротким сообщением в мессенджер, письмом, звонком, и если только не получается договориться - собирать совещание.
В порядке обмена опытом — если задачи не выстраиваются «друг за другом», т. е. их взанимное влияние неочевидно, вместо канбана (или в дополнение) хороша техника «ментальных карт» (mind maps). Особенно полезна при сложных миграциях, где надо обеспечить непрерывность сервиса.
По п. 4 — да, всё так, стоит тимлиду расслабиться, и проектная команда начинает вешать на него принятие всех мелких и не очень мелких решений. Нужно уметь «возвращать» вопрос, т. е. спрашивать «а что бы сделал ты? а почему так? а какие вообще ты здесь видишь варианты? какие из них лучше?» Именно так сотрудники и развиваются. Также нужно учить сотрудников «не держать информацию в себе» — сообщать тимлиду о проблемах — немедленно, другим участникам проекта — какие решения приняты и почему.
Цель же не в том, чтобы «прессовать» — цель в том, чтобы за один час собеседования приблизительно понять, что человек умеет, чему его придется учить, сколько времени займет обучение, и чему он в результате научится быстро, а чему — будет учиться долго или не научится никогда, как-то так.
Я в общем тоже наверное хороший полицейский (стараюсь быть, кандидатам виднее).
Страхи отчасти обоснованны — почти никто в институте и на работе целенаправленно не учит теорию, не копит теоретические знания, не складывает специально их в систему. Студенты к экзамену учат «билеты». Те, кто уже работает, доводят до совершенства навыки, нужные именно на данной работе, и изо дня в день их успешно применяют, максимально избагая рабочего стресса.
На собеседовании картина меняется. Потенциальному работодателю важно, насколько быстро и успешно кандидат вольётся в проект и возьмёт на себя часть задач. На этом этапе у нового работника точно возникнет стресс, и реакцию на этот стресс хорошо бы увидеть уже на собеседовании. Так что потенциальный руководитель будет всегда «копать в глубину» и пытаться найти вопрос, на который кандидат не ответит, это важно уже для его карьеры.
Надо сказать, что собеседующие тоже не всегда демонстрируют лучшие качества — например, не пытаются выслушать и проанализировать ответы кандидата, а пытаются уложить эти ответы в ими же придуманную псевдо-идеальную картину.
Хорошая книга. В свое время именно в ней я нешёл ответ на вопрос «почему продукты компании Микрософт вроде бы всем хороши, но их использование не приносит радости».
Рекомендую прочитать ее не только специалистам по UI/UX, но и программистам (чтобы разрабатывать хорошие API), безопасникам (чтобы разрабатывать хорошие политики ИБ), да и вообще всем, кто хочет делать жизнь людей удобнее.
Можно поставить вопрос ещё шире — например, «как принять на работу тех, кто будет хорошо работать». Пока наша концепция (для начинающих специалистов) — чтобы был интерес к тому, чем мы занимаемся (и к ИТ в принципе). Остальному можно научить и научиться.
На «каких-то курсах» научиться «нормально» нельзя ничему — здесь задача осуществить bootstrap и показать направление, куда двигаться (это вообще любых курсов касается).
Верно и обратное — те сотрудники, которым можно показать направление, и они сами начинают в том направлении идти, быстрее всех прогрессируют, и очень ценятся работодателями.
Это вообще самый сложный вопрос подготовки (и самоподготовки) любого специалиста — как сделать так, чтобы знания сложились в систему. Здесь нет однозначного ответа (за годы преподавательского опыта я его так и не нашел). Мне кажется, что нужные нейронные связи будущий специалист может сформировать только сам — пробуя, ошибаясь, размышляя, и берясь за всё более сложные задачи. Это стресс, это боль, но пойти по «простому» пути (годами использовать стандартные конструкции для решения стандартных задач) — тоже невесело, и ценность такого специалиста будет со временем падать.
Про shell и ansible — всё так и есть, а дальше возникают вопросы
golang я не знаю (видел издали, слышал хорошие отзывы, но ни строчки кода на нём не написал), впечатления от него — это хороший, полнофункциональный язык, особенно для того чтобы быстро и качественно написать backend-часть веб-приложения.
Почему вы его противопоставляете питону, называя питон «полноценным ЯП»? Чем golang менее «полноценен»?
Давайте воспользуемся принципом «критикуешь — предлагай». К питону как к первому языку у меня тоже масса вопросов, но на чём ещё учить?
В вузах сейчас учат в основном сразу на несуществующем языке «С/С++» (ибо «индустрия требует»), и ребята приходят к нам уже с психотравмой и стойким отвращением к написанию кода.
Идти по пути, предлагаемому Столяровым — методически правильно, но на это нужен плюс-минус год.
Какие ещё есть варианты?
Ну точно не про нашу компанию, и не про наше подразделение. У нас скорее другая проблема — когда молодой и очень старательный инженер в текстовом редакторе перепиливает 100500 правил ACL из формата, условно, cisco, в формат, условно, iptables, и пользуется максимум поиском/заменой. Хотя никто не запрещает ни bash, ни awk, ни регулярные выражения, ни perl, ни python.
Статья — попытка начать дискуссию на тему «почему инженер/админ/связист боится/не хочет написать нужный ему по работе кусок кода» и как ему можно помочь (захотеть). Вернее, вынести наши внутренние обсуждения на эти темы на более широкую аудиторию. Готовы об этом поговорить?
В нашей местной... в чём, простите? Расшифруйте, пожалуйста :)
Спасибо за развернутый комментарий. Да, мы с помощью курса пытались решить именно наши задачи. Как получилось — лучше расскажут сами участники обучения (а также те, с кем они вместе работают).
По поводу деления наук на «первый и второй уровни» — спорное утверждение. Хорошая вузовская программа предусматривает теорию (лекции, семинары) и практику (лабы, курсовые). Алгоритмы, дискретная математика, теория формальных языков, реляционная алгебра — это теория. А написание кода на конкретном языке — это, конечно же, практика.
В наших условиях мы, конечно же, можем дать в основном практику. Теорию — только «по верхам», в расчете, что кто-то заинтересуется и пойдет читать книжки.
В версии, по-моему, 2.3 — умел, к версии 2.4 — сломали. Актуальная версия 3.x, починили ли в ней — не знаю.
У Cisco есть ISE, но к нему — масса вопросов. Управление политиками там реализовано, мягко говоря, своеобразно.Мы были в похожей ситуации, и дело кончилось заменой VPN-решения.
Вообще же, etnerprise-подход должен выглядеть так: помещаем пользователей в группы AD, и далее все VPN-шлюзы сами на основе членства в группах формируют при подключении пользователя персональные политики доступа. Связка ASA+ISE, PaloAlto, Fortinet — умеют такое в каком-то виде, но, как всегда, «не совсем так как хочется».
Если в результате такого добросовестного исполнения получается полная фигня — далеко не каждый руководитель сможет решить проблему и грамотно скорректировать показатели. Бывают и такие, которые отказываются признать, что проблема вообще существует, увы.
Строгий «академический» ответ на этот вопрос приведен в монографии Столярова, ссылку на которую дали в комментах выше.
А я по-простому скажу. Си похож одновременно на самурайский меч, турецкую саблю и мушкетёрскую шпагу — устроен очень просто, в нём почти ничего нет, но приёмы написания программ на нём — сложны и замысловаты. И для освоения именно этих приёмов (и безопасного их применения!) нужно много специальных знаний.
Таким образом, изучение Си на уровне чуть выше элементарного тут же превращатся в изучение операционной системы (что такое файл? а дескриптор файла? И зачем функция dup2?), архитектуры компьютера (ошибки buffer overflow где-то рядом, а вместе с ними — опасные уязвимости) и прочих интересных вещей. Такие знания, разумеется, программисту тоже нужны, но на самом начальном этапе обучения программированию у студента начинается информационный перегруз — он не в состоянии справиться с потоком сведений и отделить важное от неважного, как, собственно, и произошло с автором исходного поста.
Мы и не отказываемся. Мы — интегратор, наша основная работа — помочь заказчику справиться с его зоопарком.
Мое мнение — «хороших» вендоров не бывает. Допускаю правда, что это профдеформация, потому что когда всё хорошо работает (т. е. без напильника и интуитивно понятно), нас не зовут.