Обязанности программиста
В блоге у
gaperton есть запись про то, как ему показалось, что при переходе на уровень архитектора уже не нужно писать код, а нужно только думать и раздавать ЦУ тем, кто будет писать код. Ему там старшие товарищи объяснили, что это не так и что написание код позволяет архитектору не сойти с ума и не воспарить в эмпиреях.
Но изначальная идея была в том, что кодирование, возможно, мешает охватить мозгом систему в целом.
А вот когда можно заниматься думанием, когда каждый день приходится 2-3-4 часа уделять админским обязанностям: следить за апдейтами винды, за резервными копиями на нескольких серверах, писать резервные копии на матрицы, поддерживать все инфраструктуру вроде сервера subversion, баг-трекера и девелоперского сервера БД, подключать и настраивать новое железо на серверах, следить за всяческими долбаными рассылками и новостями, настраивать виртуальные машины для всяких надобностей, итд.
Вчера вот убил целый вечер на то, чтобы проверить работу wsus на виртуальной машине, сегодня уже второй час разгребаю завалы из бэкапов.
Если же привести эту работу в нормальное состояние - т.е. с регистрированием и описанием производимых действий хотя бы в wiki для будущих поколений - я вообще думать и код писать перестану.
И самое печальное, что я не совсем уверен в том, что это можно было бы переложить на выделенного админа: я постоянно в ирц наблюдаю, как админы всячески поливают помоями программистов за их "тупость" и за то, что те пытаются выполнять свою работу, требуя от админов каких-то связанных с работой действий. Это какое-то изначальное противоречие в мотивациях - админу лучше всего когда все работает и не изменяется, а у программистов работа заключается в создании нового софта(с которым потом мучиться админам).
Вот к примеру, понадобится мне срочно резервная копия БД клиента за прошлый год - сейчас я сам ее распакую и посмотрю. А так - сначала нужно будет сказать админу, тот начнет пищать "я тут типа занят" "пишите заявку на сервис", итд.
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Но изначальная идея была в том, что кодирование, возможно, мешает охватить мозгом систему в целом.
А вот когда можно заниматься думанием, когда каждый день приходится 2-3-4 часа уделять админским обязанностям: следить за апдейтами винды, за резервными копиями на нескольких серверах, писать резервные копии на матрицы, поддерживать все инфраструктуру вроде сервера subversion, баг-трекера и девелоперского сервера БД, подключать и настраивать новое железо на серверах, следить за всяческими долбаными рассылками и новостями, настраивать виртуальные машины для всяких надобностей, итд.
Вчера вот убил целый вечер на то, чтобы проверить работу wsus на виртуальной машине, сегодня уже второй час разгребаю завалы из бэкапов.
Если же привести эту работу в нормальное состояние - т.е. с регистрированием и описанием производимых действий хотя бы в wiki для будущих поколений - я вообще думать и код писать перестану.
И самое печальное, что я не совсем уверен в том, что это можно было бы переложить на выделенного админа: я постоянно в ирц наблюдаю, как админы всячески поливают помоями программистов за их "тупость" и за то, что те пытаются выполнять свою работу, требуя от админов каких-то связанных с работой действий. Это какое-то изначальное противоречие в мотивациях - админу лучше всего когда все работает и не изменяется, а у программистов работа заключается в создании нового софта(с которым потом мучиться админам).
Вот к примеру, понадобится мне срочно резервная копия БД клиента за прошлый год - сейчас я сам ее распакую и посмотрю. А так - сначала нужно будет сказать админу, тот начнет пищать "я тут типа занят" "пишите заявку на сервис", итд.
no subject
Админ как раз и должен заниматься железками, апдейтами и бекапить твою базу ! Бекапы и следить за тем чтобы они делались должен админ. Но в саму базу ему лезть нафиг не надо - бекапы доступны тебе и можеш разворачивать какие хочешь. Проблема ИМХО больше в том, чтобы найти такого админа, который бы делал все это под тебя, а не как захотелось.
(no subject)
(no subject)
no subject
Вот, к примеру, найти и распаковать самостоятельно резервную копию занимает 30 минут. А если написать заявку и получить ответ "копия распакована - пользуйтесь" занимает 60 минут, то есть смысл иметь специально обученного человека?
Ведь в эти 60 минут обязательно найдётся какая-то полезная работа не связанная с резервной копией!
И, ес-но, специально обученный человек не сидит, и не ждёт заявки от тебя. А обслуживает аналогичные заявки других пользователей. или проверяет работоспособность wsus.
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Либо научитесь делегировать полномочия и доверять специлистам, либо заворачивайтесь в простынку уже сегодня.
no subject
дали Линукс ? настраивай, зачем работать :(
Даже в ситуации, когда у админа знаний на порядок меньше чем у человека, который пришёл с конкретной проблемой...
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Чтобы большая программная система вообще была написана, обычно нужен некий "фреймворк", в рамках которого будут решены типичные проблемы, и его пользователи, пользуясь сервисами фреймворка, будут писать код в его рамках, и ольше думать о прикладной задаче.
Кто же будет проектировать и кодировать фреймворк? "Архитектор" при данном подходе и будет. Мало того, что он спроектирует и закодит фреймворк, он самостоятельно (или в составе небольшой группы архитекторов) сделает еще по одному прикладному кейсу, чтобы доказать, что на фреймворке писать удобно.
Архитектура - это то, что дает программистам ограничения и возможности. "Архитектор" - это человек, который эти ограничения и возможности задает. Боже упаси если он разучится писать код. А за пару лет он разучится. Вот об этом на самом деле и шла речь. Хотя, явно об это не говорилось, но я не видел возможностей в раммках короткого эмоционального рассказа об этом сказать.
Понимая архитектуру так
http://gaperton.livejournal.com/29043.html
(а данное определение достаточно универсально), вы можете перенести вышесказанное на еятельность админа.
no subject
Выход - себя "отклонировать" :). И именно это сделал Тол со мной. :)
no subject
Ребе, что ж так много-то?
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)