Я не говорю о том, что специалист не может стать начальником. Просто если он это сделает, то компания потеряет "рабочую лошадь", получив "хромую". Конечно, специалист станет каким-никаким или даже отличным начальником, но на это нужно время, а иногда, даже слишком много времени.
Не совсем понял, где я говорил о том, что начальником должен быть тот, кто ближе? Я говорю о том, что начальник должен быть человеком с необходимыми для управления другими людьми навыками и знаниями, а не просто любой бывший линейный специалист. И я уверен, что по такой схеме не работает почти ни одна гос-ка.
Начальники, которые не понимают специфики того, чем управляют и не хотят этого понимать- крайность. Таких не то, что могила, их экскаватор не исправит. И вот их да, в гос-ке полным полно.
Я не говорю о том, что специалист не может стать начальником. Просто если он это сделает, то компания потеряет "рабочую лошадь", получив "хромую". Конечно, специалист станет каким-никаким или даже отличным начальником, но на это нужно время, а иногда, даже слишком много времени. Смысл в этом, если можно нанять действительно качественного управленца и поставить начальником его?
В данной дискуссии смысла не вижу. Вы не пытаетесь парировать мои аргументы, а придумываете соломенное чучело и боритесь с ним. Ну или не можете прочесть и понять то, что написано на русском языке. Что из этого верно- не берусь судить. Так что всего доброго
На лицо полное непонимание ценности кадров... Да и мешанина "мух с котлетами".
Во-первых, квалификация сотрудника. Более опытный сотрудник решит тот же пулл задач, что и группа менее квалифицированных специалистов. Если же его сделать начальником, то решаемые ранее задачи он уже не сможет взять т.к. будет завален административными и организационными задачами.
Во-вторых, смотри во-первых. Потому что рост в начальники не является ростом профессиональным.
В-третих, не мешать работать означает не мешать сотруднику выполнять его прямые обязанности. Если вы не сталкивались с таким: завидую.
В-четвертых, дать спецу выполнять интересные ему задачи означает закрыть задачу максимально быстро и качественно, потому что у сотрудника есть огромная мотивация эту конкретную задачу закрыть. Навыки начальника этим и определяются: умением делегировать правильную задачу правильному сотруднику. Конечно, это не всегда удается, но тем не менее, это то, к чему нужно стремиться.
В-пятых, чем больше специалист работает в конкретном месте, тем большим знанием о специфике работы, продуктах, тонкостях и прочем этот специалист знает. Чем не повод поднять ему ЗП? Ведь даже если взять спеца такого же уровня с улицы, он потратит много времени для набора тех же знаний, что были у его предшественника.
Так что если вы все еще настаиваете на том, что если специалист не рвется в начальники, то и повышать ему ЗП не нужно, то не хотел бы я попасть к вам в контору, если она, конечно же, есть
Почему советское представление о мире "хорошего спеца надо двигать в начальники" еще сидит в головах людей? Сделать хорошего спеца начальником: значит потерять хорошего спеца и получить плохого руководителя. Хотите, чтобы спец получил рост? Не мешайте ему работать и позволяйте выполнять побольше интересных ему задач. На курсы повышения квалификации запишите, ЗП поднимите, на худой конец
Так я говорю про сборку, а не про релиз. Зачем каждый раз для каждого отдельного рабочего места заниматься настройкой окружения, если можно один раз сделать Docker-образ и использовать его? Или это тоже веяние моды и в этом примерно ноль целесообразности?
Для того, чтобы лишний раз не усложнять, минимально необходимая база команд Docker описана.
Зависимостей почти нет т.к. пока на системе один только Buildroot. Но когда начнется добавление своих пакетов, система так или иначе будет забиваться непонятно чем. Да и про воспроизводимость не будем забывать. Так что я считаю, что лучше всегда и всё оборачивать в Docker. Не сложно, но очень удобно
Docker — лишний? Вы любитель мема "На моем компьютере все работает"? CI/CD тоже без контейнеризации заводить будете?
Этот цикл рассчитан на новичков в Buildroot, которые хотели бы начать его использовать, но не знают, как подступиться. Поэтому всё будет вводиться последовательно. С данным подходом переход от вводной части с базовыми определениями к интеграции новой для Buildroot платы будет выглядеть непоследовательно, не находите?
В целом, этот вопрос относится ко всему комметарию: не стоит просить на данном этапе чего то сложнее Hello World. Для этого банально рано
Я догадывался, что при собесе в бигтехи происходит цирк, но чтобы до такой степени...
Все это выглядит так, будто народ поголовно валит снег с больной головы на здоровую (кто то по своей инициативе, а кого то заставляют). По итогу, собеседующие- это просто выдернутые из рабочего процесса люди, которые далеко не всегда будут заинтересованы в проведении собеса. Причем, на каждый этап нужен свой собеседующий, И если тебе не повезет и никому из этой цепочки собес нафиг не сдался, то ты, как соискатель, идешь нафиг и пофиг на твои навыки, реальный опыт и знания.
Еще добавим к этому то, что собеседует тебя суммарно 3-5 человек, каждый из которых имеет свою компетенцию и именно в ней сильнее всего, а ты один и должен в каждой из этих компетенций ответить более чем достойно.
Ах да, совсем забыл. Еще может оказаться так, что вакансии как таковой нет и что ты тут вообще делаешь, не сильно понятно.
Суммируя, можно задать вопрос. А почему бы собесы не проводить именно тем командам, которые заинтересованы в нахождении человека с конкретными компетенциями?
В итоге, секций получится 2: одна с HR, а другая с членами команды, где тебя будут спрашивать про твой опыт (для понимая того, что в тебя в целом можно закинуть) и про те задачи, которые требуется закрыть новым сотрудником в данный момент
Тогда грош цена такой проверке. Вы утверждаете, что скопировали из середины, где одна копипаста из Вики (хотя я ни одного предложения из Вики я не копировал).
При этом вы утверждаете, что это все создала нейронка.
Получается, что на вики статьи делали нейронки? Отвечать больше не буду. На лицо просто троллинг, не более того
Эм... Песочница- раздел для авторов. Зарегистрироваться можно когда угодно, но первая статья гарантрированно улетает либо в песочницу, либо получает бейдж "Из песочницы", как в моем случае
Возможно, не самый дешевый вариант, но около того- OrangePi PC. Стоит в районе 4к рублей. Хорошая железка с поддержкой Buildroot. Возможно, для новичка будет даже немножко "навырост". В следующей статье как раз буду использовать ее
Расстрою: в следующей статье по командам примерно так и будет. НО!
В своих статьях я планирую идти от простого к сложному, поэтому перед тем, как лезть в external layers, структуру Kconfig файлов и т.д, начинающим надо понять, в каких директориях что лежит, как с этим взаимодействовать, собирать и запускать.
Да и я в этой статье знатно задушнил, в следующей тоже буду душнить. Надо дать начинающим ощущение маленькой победы в виде запуска Linux на, хотя бы, стоковом одноплатнике, чтобы не отбить желание читать дальше)
Согласен, что хаб здесь смотрится странно, но, к сожалению, хаба SoC, Buildroot или SystemOnChip мне не дали поставить (Возможно, потому что только из песочницы вылез). Так что я решил оставить его: как никак, микрухи— ближайший родственник SoC
На этот тезис я уже отвечал пару сообщений назад:
В моем понимании, ничего не мешает начальнику во время онбординга и работы вникнуть в специфику
Не совсем понял, где я говорил о том, что начальником должен быть тот, кто ближе? Я говорю о том, что начальник должен быть человеком с необходимыми для управления другими людьми навыками и знаниями, а не просто любой бывший линейный специалист. И я уверен, что по такой схеме не работает почти ни одна гос-ка.
Начальники, которые не понимают специфики того, чем управляют и не хотят этого понимать- крайность. Таких не то, что могила, их экскаватор не исправит. И вот их да, в гос-ке полным полно.
Я не говорю о том, что специалист не может стать начальником. Просто если он это сделает, то компания потеряет "рабочую лошадь", получив "хромую". Конечно, специалист станет каким-никаким или даже отличным начальником, но на это нужно время, а иногда, даже слишком много времени. Смысл в этом, если можно нанять действительно качественного управленца и поставить начальником его?
Тут комментировать- только портить)
В данной дискуссии смысла не вижу. Вы не пытаетесь парировать мои аргументы, а придумываете соломенное чучело и боритесь с ним. Ну или не можете прочесть и понять то, что написано на русском языке. Что из этого верно- не берусь судить. Так что всего доброго
На лицо полное непонимание ценности кадров... Да и мешанина "мух с котлетами".
Во-первых, квалификация сотрудника. Более опытный сотрудник решит тот же пулл задач, что и группа менее квалифицированных специалистов. Если же его сделать начальником, то решаемые ранее задачи он уже не сможет взять т.к. будет завален административными и организационными задачами.
Во-вторых, смотри во-первых. Потому что рост в начальники не является ростом профессиональным.
В-третих, не мешать работать означает не мешать сотруднику выполнять его прямые обязанности. Если вы не сталкивались с таким: завидую.
В-четвертых, дать спецу выполнять интересные ему задачи означает закрыть задачу максимально быстро и качественно, потому что у сотрудника есть огромная мотивация эту конкретную задачу закрыть. Навыки начальника этим и определяются: умением делегировать правильную задачу правильному сотруднику. Конечно, это не всегда удается, но тем не менее, это то, к чему нужно стремиться.
В-пятых, чем больше специалист работает в конкретном месте, тем большим знанием о специфике работы, продуктах, тонкостях и прочем этот специалист знает. Чем не повод поднять ему ЗП? Ведь даже если взять спеца такого же уровня с улицы, он потратит много времени для набора тех же знаний, что были у его предшественника.
Так что если вы все еще настаиваете на том, что если специалист не рвется в начальники, то и повышать ему ЗП не нужно, то не хотел бы я попасть к вам в контору, если она, конечно же, есть
Почему советское представление о мире "хорошего спеца надо двигать в начальники" еще сидит в головах людей? Сделать хорошего спеца начальником: значит потерять хорошего спеца и получить плохого руководителя. Хотите, чтобы спец получил рост? Не мешайте ему работать и позволяйте выполнять побольше интересных ему задач. На курсы повышения квалификации запишите, ЗП поднимите, на худой конец
Так я говорю про сборку, а не про релиз. Зачем каждый раз для каждого отдельного рабочего места заниматься настройкой окружения, если можно один раз сделать Docker-образ и использовать его? Или это тоже веяние моды и в этом примерно ноль целесообразности?
Если только полностью опустить процесс создания своего пакета, процесс подготовки окружения для отладки его сборки и т.д.
Для того, чтобы лишний раз не усложнять, минимально необходимая база команд Docker описана.
Зависимостей почти нет т.к. пока на системе один только Buildroot. Но когда начнется добавление своих пакетов, система так или иначе будет забиваться непонятно чем. Да и про воспроизводимость не будем забывать. Так что я считаю, что лучше всегда и всё оборачивать в Docker. Не сложно, но очень удобно
Docker — лишний? Вы любитель мема "На моем компьютере все работает"? CI/CD тоже без контейнеризации заводить будете?
Этот цикл рассчитан на новичков в Buildroot, которые хотели бы начать его использовать, но не знают, как подступиться. Поэтому всё будет вводиться последовательно. С данным подходом переход от вводной части с базовыми определениями к интеграции новой для Buildroot платы будет выглядеть непоследовательно, не находите?
В целом, этот вопрос относится ко всему комметарию: не стоит просить на данном этапе чего то сложнее Hello World. Для этого банально рано
Я догадывался, что при собесе в бигтехи происходит цирк, но чтобы до такой степени...
Все это выглядит так, будто народ поголовно валит снег с больной головы на здоровую (кто то по своей инициативе, а кого то заставляют). По итогу, собеседующие- это просто выдернутые из рабочего процесса люди, которые далеко не всегда будут заинтересованы в проведении собеса. Причем, на каждый этап нужен свой собеседующий, И если тебе не повезет и никому из этой цепочки собес нафиг не сдался, то ты, как соискатель, идешь нафиг и пофиг на твои навыки, реальный опыт и знания.
Еще добавим к этому то, что собеседует тебя суммарно 3-5 человек, каждый из которых имеет свою компетенцию и именно в ней сильнее всего, а ты один и должен в каждой из этих компетенций ответить более чем достойно.
Ах да, совсем забыл. Еще может оказаться так, что вакансии как таковой нет и что ты тут вообще делаешь, не сильно понятно.
Суммируя, можно задать вопрос. А почему бы собесы не проводить именно тем командам, которые заинтересованы в нахождении человека с конкретными компетенциями?
В итоге, секций получится 2: одна с HR, а другая с членами команды, где тебя будут спрашивать про твой опыт (для понимая того, что в тебя в целом можно закинуть) и про те задачи, которые требуется закрыть новым сотрудником в данный момент
Тогда грош цена такой проверке. Вы утверждаете, что скопировали из середины, где одна копипаста из Вики (хотя я ни одного предложения из Вики я не копировал).
При этом вы утверждаете, что это все создала нейронка.
Получается, что на вики статьи делали нейронки? Отвечать больше не буду. На лицо просто троллинг, не более того
Эм... Песочница- раздел для авторов. Зарегистрироваться можно когда угодно, но первая статья гарантрированно улетает либо в песочницу, либо получает бейдж "Из песочницы", как в моем случае
Это уже просто смешно. Я бы еще понял 5-10%, но 100)
Кавычек "ёлочкой" тоже нет в стандартной раскладе. Но никто не запрещает использовать Alt+0171 и Alt+0187.
Возможно, не самый дешевый вариант, но около того- OrangePi PC. Стоит в районе 4к рублей. Хорошая железка с поддержкой Buildroot. Возможно, для новичка будет даже немножко "навырост". В следующей статье как раз буду использовать ее
Расстрою: в следующей статье по командам примерно так и будет. НО!
В своих статьях я планирую идти от простого к сложному, поэтому перед тем, как лезть в external layers, структуру Kconfig файлов и т.д, начинающим надо понять, в каких директориях что лежит, как с этим взаимодействовать, собирать и запускать.
Да и я в этой статье знатно задушнил, в следующей тоже буду душнить. Надо дать начинающим ощущение маленькой победы в виде запуска Linux на, хотя бы, стоковом одноплатнике, чтобы не отбить желание читать дальше)
Согласен, что хаб здесь смотрится странно, но, к сожалению, хаба SoC, Buildroot или SystemOnChip мне не дали поставить (Возможно, потому что только из песочницы вылез). Так что я решил оставить его: как никак, микрухи— ближайший родственник SoC
Да, в начале я пишу про загрузчик GRuB. В главе про загрузку обычного ПК.
Затем, в главе про загрузку SoC я вообще не упоминаю U-Boot. Он начинает фигурировать только в главе состав Embedded Linux.
Так что суть претензии мне совершенно непонятна.
П.С. Специально запарился и все короткие тирехи поменял на длинные, где находятся конструкции "Термин — определение". В чем проблема?