Читайте выше… Вопрос был почему при запрете роскоши или прочих репрессиях на богачей, обычные люди абсолютно никакого профита не получают.
Ответ: потому что эти деньги являются богатством только когда сосредоточены в руках единиц, а для всего населения эти же деньги — это доли процента от средней зарплаты. Ну а glioma ещё забыл, что в случае с миллиардерами это никакие не деньги, а всего лишь оценочная стоимость их доли в компании. Есть конечно какие-то предметы роскоши и наличка, но вряд ли они хотя бы 5% от общей оценки состояния составляют.
Никакой магии. Если каждый из 72 млн.человек, официально работающих в России, скинутся Вам раз в месяц по 10 руб, то у Вас будет 720 млн. рублей в месяц. По-моему достаточно для роскошной жизни. А вот каждому отдельному человеку от этих 10 рублей ни жарко, ни холодно.
Да дебилизм полнейший все эти задания написать какой-то код на бумажке или в GoogleDocs. По факту вы просто отсеиваете людей, которые не умеют писать код на бумажке. Мне такой навык от сотрудников нафиг не нужен.
Ну а разучиться программировать — это из серии разучиться на велосипеде кататься.
если ответ на вопрос занимает 1 минуту, то потери производительности, у человека, пишущего код — 15-30 минут.
Это всё так, но вас послушать так программисты только и делают, что код пишут. Обсуждать идеи прежде, чем переводить их в код — очень даже полезно. И уж хватает методологий как это делать, чтобы не вызывать проблему постоянных отвлечений.
А сколько людей вы на работу опросили и наняли, позвольте спросить?
Не так много, нанимал около десятка, опрашивал соответственно в разы больше.
Потому что бо́льшая часть «сеньоров» код писать не умеет.
Тут если только вам поверить, я ни одного такого сеньора вживую не видел. Я допускаю, что есть куча сеньоров, которые не напишут на бумажке QuickSort, потому что в прошлый раз они этим интересовались 10-15 лет назад, или вообще на бумажке ничего не напишут, т.к. давным давно переложили автодополнение на IDE. Но вот чтобы они не могли код написать в обычных условиях на своём компе, такого я не встречал.
Конечно, у каждой роли есть своя основная зона ответственности. Но на практике все эти границы размываются… И архитектор и тимлид могут сделать что-то в коде, а сеньоры обсудить архитектуру.
Если разделять прям строго, то всё закончится фигнёй типа "это не по моей части" и чехардой перекидывания ответственности друг на друга. Вот вы пишете "код и только код", т.е. такой сеньор в любой момент времени может сказать "я так сделал, потому что мне так сказали"… такой формализованный подход, без вникания в суть.
Имхо, Вы переусложняете классификацию… Если tech lead больше архитектор, то чем он отличается от архитектора?
Вот тут немножко про ведущего программиста.
Я бы даже не стал строгой границы между тимлидом и сеньором проводить. Да, не каждый сеньор может выполнять роль тимлида, в силу особенностей характера, но каждый тимлид — это сеньор по квалификации, который в силу роли просто несколько больше управленческой работы выполняет, чем обычный сеньор.
Всё, о чём Вы говорите, затрагивает только R&D.
И в данном контексте речь идёт по сути не о сеньорах, а об исследователях. Т.е. с одной стороны — да, человек, имеющий квалификацию сеньора, может выступать в роли исследователя. Но с другой стороны, в рамках всей индустрии, кейс когда сеньор что-то пилит в одиночку, опираясь только на своё видение проекта, — не такой уж частый. Поэтому я не понимаю, почему Вы так упорно пытаетесь натянуть сову на свой глобус, при всей очевидности, что так устроена работа в очень малом кол-ве компаний, а ещё точнее только в 1 департаменте этих компаний.
Как все ваши джуниоры и миддлы должны будут догадаться что вам делать? Путём телепатического заглядывания к вам в мозг?
А кроме регламентных документов и телепатии Вы других способов общения не знаете?
Ну раз вы на собеседовании только это и спрашиваете — то, скорее всего, наберёте людей, которые только это и умеют…
Да бросьте, я спокойно доверяю людям в этом отношении. И не сомневаюсь, что отработав многие годы программистами они могут набрать код. Меня больше интересует, чтобы сеньор вёл себя согласно своей роли, а не как мега-опытный джуниор.
Tech Lead, Lead Developer, ведущий программист — это просто альтернативные названия для Senior Developer.
И это не только моё частное мнение… Почти никто не разделяет эти роли. Вот для примера: What Defines a “Senior Developer?”
А кто вам сказал, что у вас есть заказчик? Нет его. Вон пользователи бегают. Миллиарды. И чего хотят — они сами не знают. И не узнают — пока вы не придумаете чего бы такого сделать и как бы это реализовать.
В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель "напрасный труд". Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям. По описанию фигня какая-то выходит… Я честно скажу, что не понимаю чем вы там вообще занимаетесь и зачем, с моей перспективы это выглядит как работа ради работы. Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?
нужно создавать внутренние документы какие-то описания, согласования и прочее
Это уже от степени бюрократии зависит, а не от кол-ва людей.
С чего вы решили, что они «никому не нужны»? Часть выкидывается, часть превращается во что-то большое.
С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку. Если бы там была ситуация в формате "есть такая-то проблема, давайте запустим R&D и несколько человек предоставят прототипы разного варианта решения" — это бы я понял. А с ваших слов получается, что-то в формате: "сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы".
Пресловутые пять миров?
Возможно. Хотя классификация уже давно устарела. Но безусловно у разных компаний разная специфика.
разрабатывает новые вещи
Новые вещи разрабатываются крайне редко. Везде сплошная адаптация уже известных концептов под нужды бизнеса или пользователей. Ваши 4 проекта тут ни разу не исключение. Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина. Никаких концептуально новых вещей Вы не делаете. Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.
У нас тоже ТЗ нет никаких, но есть те самые нужды бизнеса, которые обсуждаются и под них разрабатывается решение. Причём это не в статике, нужды бизнеса меняются и решение должно легко адаптироваться.
И вот тут сеньор, умеющий только управлять джунами
С чего Вы взяли, что он только это умеет? Вот тут как раз в тему статья вышла. Способности программиста — это одна из 4 характеристик сеньора, само собой она важна и обязательна. Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут. Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.
часто попытка хотя бы примерно прикинуть в коде — всё ставит «с ног на голову».
Может просто стоило картинки чуть дольше покрутить? Реализация может вносить коррективы, но ситуация «с ног на голову» — это фейл этапа проектирования.
Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.
Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче? Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения? На кого должны равняться мидлы и джуниоры? Кто code review должен делать?
В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.
Правильно, судя по всему, вам и не нужны сеньоры в компанию, вам нужны линейные исполнители — нормальные джуниоры и начинающие мидлы. Для некоторых проектов этого вполне достаточно.
можно ли или нельзя ли её применить к решению кроссвордов (ответ, кстати — нельзя, это скорее чуть-чуть похоже на игру в «слова», но при всей внешней похожести реально это — совсем разные задачи).
И Вас даже не смутило, что в формулировке не указаны конкретные условия? А если Вы имели в виду формулировку от kruslan, то там никакой схожестью с кроссвордами вообще не пахнет. Рано Вам в сеньоры...
Поиграться уже можно: https://webassembly.org/docs/c-and-c++/. А за год может и популярность наберёт..
Читайте выше… Вопрос был почему при запрете роскоши или прочих репрессиях на богачей, обычные люди абсолютно никакого профита не получают.
Ответ: потому что эти деньги являются богатством только когда сосредоточены в руках единиц, а для всего населения эти же деньги — это доли процента от средней зарплаты. Ну а glioma ещё забыл, что в случае с миллиардерами это никакие не деньги, а всего лишь оценочная стоимость их доли в компании. Есть конечно какие-то предметы роскоши и наличка, но вряд ли они хотя бы 5% от общей оценки состояния составляют.
Никакой магии. Если каждый из 72 млн.человек, официально работающих в России, скинутся Вам раз в месяц по 10 руб, то у Вас будет 720 млн. рублей в месяц. По-моему достаточно для роскошной жизни. А вот каждому отдельному человеку от этих 10 рублей ни жарко, ни холодно.
Это будет парсер выражений в данном случае.
Где интересно такие кадры водятся? В Индии что-ли?
Да дебилизм полнейший все эти задания написать какой-то код на бумажке или в GoogleDocs. По факту вы просто отсеиваете людей, которые не умеют писать код на бумажке. Мне такой навык от сотрудников нафиг не нужен.
Ну а разучиться программировать — это из серии разучиться на велосипеде кататься.
Это всё так, но вас послушать так программисты только и делают, что код пишут. Обсуждать идеи прежде, чем переводить их в код — очень даже полезно. И уж хватает методологий как это делать, чтобы не вызывать проблему постоянных отвлечений.
Не так много, нанимал около десятка, опрашивал соответственно в разы больше.
Тут если только вам поверить, я ни одного такого сеньора вживую не видел. Я допускаю, что есть куча сеньоров, которые не напишут на бумажке QuickSort, потому что в прошлый раз они этим интересовались 10-15 лет назад, или вообще на бумажке ничего не напишут, т.к. давным давно переложили автодополнение на IDE. Но вот чтобы они не могли код написать в обычных условиях на своём компе, такого я не встречал.
Конечно, у каждой роли есть своя основная зона ответственности. Но на практике все эти границы размываются… И архитектор и тимлид могут сделать что-то в коде, а сеньоры обсудить архитектуру.
Если разделять прям строго, то всё закончится фигнёй типа "это не по моей части" и чехардой перекидывания ответственности друг на друга. Вот вы пишете "код и только код", т.е. такой сеньор в любой момент времени может сказать "я так сделал, потому что мне так сказали"… такой формализованный подход, без вникания в суть.
Не, для этой графы надо оставить табы vs пробелы.
Имхо, Вы переусложняете классификацию… Если tech lead больше архитектор, то чем он отличается от архитектора?
Вот тут немножко про ведущего программиста.
Я бы даже не стал строгой границы между тимлидом и сеньором проводить. Да, не каждый сеньор может выполнять роль тимлида, в силу особенностей характера, но каждый тимлид — это сеньор по квалификации, который в силу роли просто несколько больше управленческой работы выполняет, чем обычный сеньор.
Всё, о чём Вы говорите, затрагивает только R&D.
И в данном контексте речь идёт по сути не о сеньорах, а об исследователях. Т.е. с одной стороны — да, человек, имеющий квалификацию сеньора, может выступать в роли исследователя. Но с другой стороны, в рамках всей индустрии, кейс когда сеньор что-то пилит в одиночку, опираясь только на своё видение проекта, — не такой уж частый. Поэтому я не понимаю, почему Вы так упорно пытаетесь натянуть сову на свой глобус, при всей очевидности, что так устроена работа в очень малом кол-ве компаний, а ещё точнее только в 1 департаменте этих компаний.
А кроме регламентных документов и телепатии Вы других способов общения не знаете?
Да бросьте, я спокойно доверяю людям в этом отношении. И не сомневаюсь, что отработав многие годы программистами они могут набрать код. Меня больше интересует, чтобы сеньор вёл себя согласно своей роли, а не как мега-опытный джуниор.
Надо в следующую перепись населения включить вопрос: "На каких ЯП Вы программируете?" xD
Tech Lead, Lead Developer, ведущий программист — это просто альтернативные названия для Senior Developer.
И это не только моё частное мнение… Почти никто не разделяет эти роли. Вот для примера: What Defines a “Senior Developer?”
В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель "напрасный труд". Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям. По описанию фигня какая-то выходит… Я честно скажу, что не понимаю чем вы там вообще занимаетесь и зачем, с моей перспективы это выглядит как работа ради работы. Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?
Это уже от степени бюрократии зависит, а не от кол-ва людей.
С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку. Если бы там была ситуация в формате "есть такая-то проблема, давайте запустим R&D и несколько человек предоставят прототипы разного варианта решения" — это бы я понял. А с ваших слов получается, что-то в формате: "сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы".
Возможно. Хотя классификация уже давно устарела. Но безусловно у разных компаний разная специфика.
Новые вещи разрабатываются крайне редко. Везде сплошная адаптация уже известных концептов под нужды бизнеса или пользователей. Ваши 4 проекта тут ни разу не исключение. Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина. Никаких концептуально новых вещей Вы не делаете. Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.
У нас тоже ТЗ нет никаких, но есть те самые нужды бизнеса, которые обсуждаются и под них разрабатывается решение. Причём это не в статике, нужды бизнеса меняются и решение должно легко адаптироваться.
С чего Вы взяли, что он только это умеет? Вот тут как раз в тему статья вышла. Способности программиста — это одна из 4 характеристик сеньора, само собой она важна и обязательна. Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут. Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.
Может просто стоило картинки чуть дольше покрутить? Реализация может вносить коррективы, но ситуация «с ног на голову» — это фейл этапа проектирования.
Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.
Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче? Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения? На кого должны равняться мидлы и джуниоры? Кто code review должен делать?
В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.
Да тут уже давно не Ваш кейс обсуждают, а в целом подход, какими вопросами какой уровень можно проверить.
Правильно, судя по всему, вам и не нужны сеньоры в компанию, вам нужны линейные исполнители — нормальные джуниоры и начинающие мидлы. Для некоторых проектов этого вполне достаточно.
И Вас даже не смутило, что в формулировке не указаны конкретные условия? А если Вы имели в виду формулировку от kruslan, то там никакой схожестью с кроссвордами вообще не пахнет. Рано Вам в сеньоры...