All streams
Search
Write a publication
Pull to refresh
0
0
Send message
Профнепригодные архитекторы, профнепригодные менеджеры, профнепригодные девелоперы. Куда деваются люди, со знанием — загадка.


Про менежеров у меня есть теория: хорошо менеджерить IT-проект может только хороший программист, который потрогал всю подноготную ремесла. Который понял, зачем тесты, понял, что такое рефакторинг, деплой, архитектура. В общем, понял это непростое ремесло. После этого, человек имеет возможность менеджерить такие проекты хорошо. Но если он хороший программист — зачем ему менеджерить? Я думаю, что большинство хороших прогеров не хотят перерастать в менеджеров.

Если же менеджер не был программистом, то программистам придется выпрашивать (в буквальном смысле) время на рефакторинг/тесты/песочницы.
Разработчик утверждает, что ошибка исправлена — мы проверяем. Если ошибка не исправлена, возвращаем тикет в работу.

Если разработчик несколько раз не может исправить одну и ту же ошибку, то убираем эту часть из обновления…


По-моему, что-то не так…
Ох уж эти декларативные утверждения «так лучше, а вот так — хуже». Все зависит от того, какой результат нужен на выходе. Если нам нужен рабочий прототип в ограниченное время — то, очевидно, чем быстрее и проще будет написан код — тем лучше. (И то не всегда! Нужно думать головой в первую очередь) Если же проект долгоиграющий, то подход к написанию кода совершенно другой — на первый план выходят расширяемость, поддерживаемость, тестируемость, модульность, «правильность» архитектуры и тп.
Если менеджер на вашем проекте — чудак на букву «м», то не стесняйтесь работать за него. Если за счёт этого вытянете проект, то в компании это должны оценить.


Это хорошее основание поднять должность и/или зарплату. А если не оценят, то поменяете работу и с имеющимся опытом будете претендовать опять же на более высокую должность и зарплату.


У нас разные подходы к карьерному росту. Я расту за счет роста своего профессионализма в своей технической сфере, потому что я не хочу становится директором по продажам (оставляю это место тем, кто больше ничего не умеет). Я предоставляю бизнесу хорошо продуманный человеческий интерфейс для воплощения бизнесовых хотелок в виде программного кода/архитектуры. Какие делать хотелки и за какие сроки и прочее планирование — это не моя юрисдикция, в моей юрисдикции навалом другого более сложного планирования.

Да, я иногда залажу в смежную область управления. Просто потому что не хочу превратиться в аутиста, который замкнут и оторван от мира. Я в курсе, как у ребят сверху обстоят дела и знаю, как они продают продукт, который я пишу. Знаю, что про продукт говорят клиенты. Но я не делаю не свою работу. Потому что не вижу в этом никакого смысла, ибо у меня свой бизнес — «Написание программного обеспечения как услуга», в котором есть своя карьерная лестница, которая не основывается на понятиях «не стесняйтесь работать за него и тебя, возможно, повысят». Для меня подобный подход — бред.
Да, вот еще в догонку к первому комментатору: будучи разработчиком, я сразу же спалю, что человек занят на рабочем месте не тем, чем должен. Моментально спалю. Уверен, что разработчики даже не подумают в открытую врать менеджеру, зная, что он в прошлом — сам разработчик.
Если наоборот, разработчик приходит ко мне с инициативами или решенными задачами, раньше сроков и в меньшие часы — для меня это сигнал, что я обладаю ценным ресурсом и моя задача аккуратно удержать его, следя за тем, что бы он не перегорел.


Если вы не умеете программировать — вам подсядут на уши карьеристы, и вы их не отличите от нормальных разработчиков. Во многих местах, в которых я работал — есть карьерист, который искусно присаживается на уши менеджерам. Такова жизнь.

мне остается понять, недостаток ли это исполнителя


Если вы не умеете программировать — как вы это поймете? Во многих местах, где я работал — есть врун-лентяй, который искусно спихивает ответственность от себя во все стороны, при этом держится на плаву с помощью выполнения простых тасков, дающих простой и объемный видимый результат. Этот врун на столько привык так себя вести, что почти никто (и даже он сам) не понимают, что он на самом деле врет. Понимают только специалисты, которые работают с ним бок о бок и периодически доделывают не свою работу.

В общем, тут можно бесконечно продолжать.

Я не говорю, что вам это нужно — выбор то за вами. Жизнь ваша и карьера — тоже ваша. Вполне себе можно быть руководителем подразделения, не зная специфики внутреннего устройства самого подразделения. У нас так пол страны устроено. Вопрос только в уровне профессионализма, который вы хотите достичь. Вот и все. Так что спорить не о чем.
А систематическая помощь менеджеру со стороны подчинённого рано или поздно возвращается ростом зарплаты и/или карьерным ростом.


Мне кажется, вы — плохой менеджер, который ставит блокирующие таски, а впоследствии ищет виноватого. Карьерным ростом заканчивается стремление к карьерному росту (но это не точно). Ростом зарплаты заканчивается стремление больше зарабатывать (но это тоже не точно). Альтруизм — это альтруизм, и не больше.

Хотелось бы дополнить парой комментариев для подчинённых: если видите, что руководитель не успевает сделать что-то из вышеперечисленного, не стесняйтесь сделать это за него.


А потом намекнуть, чтобы заплатили, как начальнику? Или попросить отрефакторить кусочек кода? )
Я разработчик. Если я даю менеджеру обратную связь о блокировках в тасках, техническом долге, новых проблемах, предлагаю очевидные технические улучшения, в общем, делаю все, чтобы повысить эффективность, то я — хороший разработчик. Я проявляю обычную, очевидную инициативу и всем в итоге лучше. Менеджер может делать то же самое, только с другой стороны. Самый простой пример — отсутствие блокирующих тасков. Пример посложнее — уменьшить переключение контекстов разработчиками.

Умение программировать и понимание особенностей процесса изнутри — не может быть лишним. Это абсолютно очевидно. Нужно это конкретному менеджеру или нет — пусть сам решает.
Скажите, а есть примеры реальных работающих проектов, где именно блокчейн приносит профит в виде денег?
Такими темпами можно ограничить знания, например, бэкендеров до границ IDE. Зачем знать как работают сокеты, протоколы, веб-сервер в связке с твоим кодом? Сейчас от всего этого можно абстрагироваться: открыл гугл, настроил nginx (или вообще докер-образ скачал и запустил) и все вроде бы работает. Но нормальные работодатели предпочитают нанимать сотрудников, которые имеют понятие, как это все устроено внутри. И это нормально, потому что при таком подходе есть надежда, что человек сможет разобраться и сделать то, что выходит за его обыденные компетенции.

С логическими задачами — это еще более широкая гарантия того, что человек не идиот в общем и целом и хотя бы будет в какую-то сторону напрявлять свою мысль, анализировать связь между входными данными неидеального реального мира и желаемым результатом.

UPD: недавно видел код парсера одного знаменитого сайта, который буквально ддосил запросами, пришлось переписывать. А все почему? Потому что написано в парадигме «как-то работает и окей»
Очевидный ответ на заголовок: лучше жить там, где больше нравится.
Это не дискредитация. Вопросики про обход бинарного дерева, разворот строки, переправку собачек и кошек через реку и т.п. дают рекрутеру дополнительную гарантию, что человек сможет ориентироваться не только в хорошо знакомых областях, но и имеет некий ментальный запас прочности, позволяющий ему находить выход из ситуаций в которые он не попадал.

Information

Rating
Does not participate
Registered
Activity