Должен ли быть программистом начальник, руководитель у программистов?

[Вадим Мошев]

Да, про сервер немного загнул, я понимаю, что, вообще-то, запросы посылаются серверу, но в рамках одного домена (хотя и не всегда одного), то есть, сервер будет тот же самый.

Вот другой пример. Не работает хостинг. Веб-приложения не открываются. Начальник винит разработчиков.
Ещё пример. На сайте используется API другого сайта. А другой сайт не работает. Соответственно, эта разработка работать тоже не будет. Разрабы не виноваты, но начальник винит всё равно их.

[Alex11223]

Дык пользователь тоже их винит )

Зависит от сайта и API.

[Вадим Мошев]

Сообщение от Alex11223

Дык пользователь тоже их винит

Пользователь не влияет на работу (то есть, на карьеру) разработчика, разве что через начальника. А начальник может лишить премии, объявить выговор, уволить. Если начальник не понимает ничего в этом, то разработчику будет нехорошо.

[Alex11223]

Ну я ж говорю, от ситауции зависит.
Разработчику тоже не надо забывать о пользователях/целях бизнеса, почитать The Clean Coder и т.п.

[digitalis]

Сообщение от ACE Valery

Еще не видела ни одного хорошего начальника-программиста.

http://programmersforum.ru/member.php?u=133285 - вот пожалуйста
Понятие "начальник" - довольно размытое. Директор, гл. инженер - им это не надо, их задача - деньги для коллектива искать. А дальше - нач. отдела, нач. сектора - уж он-то, если сектор программистов, а не "эффективных манагеров" должен быть профи. Распределять работу с учетом "who is who", вникать, куда завел его людей полет фантазии, обеспечивать единство принципа проектирования по всему проекту, орлиным взором находить затыки и предлагать пути решения.
Впрочем, это мой опыт прошлого тысячелетия, возможно, сейчас все поменялось, и один мега-программер строчит супер-прогу на весь проект.
min@y, are You here ?

[Вадим Мошев]

Сообщение от Alex11223

Ну я ж говорю, от ситауции зависит.

Вот я привожу пример конкретной ситуации. Не работает приложение. Не работает API стороннего сервиса. Клиент звонит, возмущается. Начальник после этого ругает разработчиков, те оправдываются, но в силу того, что он не знает вообще ничего о той сфере, в которой руководит (то есть, в IT полный ноль), не понимает и отказывается понимать. Он требует от программистов "перестать употреблять всякие умные слова типа API и не отмазываться ими". Говорит, чтобы через полчаса всё работало. А будут ли работать через полчаса, зависит не от разработчиков.

Сообщение от Alex11223

Разработчику тоже не надо забывать о пользователях/целях бизнеса, почитать The Clean Coder и т.п.

The Clean Coder не читал. Чем это может помочь, если, допустим, пользователь тоже "недалёк". Я верно понимаю, что в такого рода литературе описывается что-то вроде хорошего тона общения с заказчиками?

[Alex11223]

Это зависит от сервиса и деятельности, размера компании и должности начальника и кучи других факторов, может быть надо было придумать что-то на такой случай или вообще не использовать чужое API.
Ну и неплохо бы уметь мысль доносить, а не оправдываться кучей крутых терминов, причем желательно на более раннем этапе, а не тупо кодить по ТЗ сидя в своем углу.

Сообщение от Вадим Мошев

Я верно понимаю, что в такого рода литературе описывается что-то вроде хорошего тона общения с заказчиками?

Конкретно в этой много про что, про весь процесс, и общение, и код.

Сообщение от https://www.ozon.ru/context/detail/id/144954705/

Всех программистов, которые добиваются успеха в мире разработки ПО, отличает один общий признак: они больше всего заботятся о качестве создаваемого программного обеспечения. Это - основа для них. Потому что они являются профессионалами своего дела. В этой книге легендарный эксперт Роберт Мартин (более известный в сообществе как "Дядюшка Боб"), автор бестселлера "Чистый код", рассказывает о том, что значит "быть профессиональным программистом", описывая методы, инструменты и практики разработки "идеального ПО". Книга насыщена практическими советами в отношении всех аспектов программирования: от оценки проекта и написания кода до рефакторинга и тестирования. Эта книга - больше, чем описание методов, она о профессиональном подходе к процессу разработки.

[MihalNik]

Если начальник не понимает ничего в этом, то разработчику будет нехорошо.

Так в любом случае людям приходится проверять то, за что они платят деньги.

[Avazart]

Сообщение от ACE Valery

А давайте не перекручивать?
Я сказала, что начальнику не обязательно быть программистом. Еще не видела ни одного хорошего начальника-программиста.

Мм а кем он по Вашему должен быть если не программистом?

[ACE Valery]

Сообщение от Avazart

а кем он по Вашему должен быть если не программистом?

Буду кэпом, но другого ответа у меня нет: начальником (руководителем, управленцем, менеджером). Он должен знать все сильные и слабые стороны своей команды и грамотно распределять задачи между людьми так, чтобы получать от них максимальную эффективность.

Если мы сейчас говорим не о просто начальнике, а конкретно о тимлиде программистов, который еще и программирует ко всему прочему, то ему, разумеется, нужно уметь программировать Но это никак не относится к руководству людьми.

В конце-концов, в адекватных командах есть техлид, который отвечает за технологии и прочую матчасть.

А когда за все это отвечает один человек, то он очень сильно лажает как раз в части руководства. Потому что как крутой программист, он выбирает фронт работ программирования и забивает на руководство.