Написал небольшое эссе о своей работе, не знаю в юмор или «О работе». Многое из написанного у самого вызывает улыбку, хотя это правда (субъективная конечно).
Захотелось узнать, что же программист должен делать на работе и что ему в итоге приходится делать. Тема наболевшая (для меня), т.к. все же считаю, что программист должен программировать.
Вначале ситуация. Занимаюсь разработкой программных продуктов. Это основная деятельность… по крайней мере мне так хочется думать. ? Конторка небольшая. Программистов двое ?. Но на самом деле:
• Анализ объектов автоматизации на стороне заказчика;
• Написание технического задания
• Общение с представителями одного заказчика, которые и сами понимают, что не понимают, что они хотят ?
• Проектирование архитектуры приложения;
• Разработка пользовательского интерфейса (даже логотип фирмы пришлось в фотошопе разработать, который на визитках и буклетах присутсвует, но это не оплачивалось).
• Контроль качества кода;
• Иногда написание инструкции пользователя и технорабочего проекта;
• Выбор инструментария разработки;
• Разработка новых программных продуктов;
• Постоянные (параллельные) доработки в других программах, что конечно отвлекает от новой разработки;
• настройка и поддержание почтового сервера и брендмауэра (хотя думаю это дело системных администраторов);
• премии, о которых много говорится, но которых не видели, оказывается зависят от сдачи проекта, причем оказывается программист должен презентовать заказчику программу и обеспечить ее сдачу и в случае если программист «пропихнёт программу», то премия будет, хотя я думаю это дело менеджера.
• Консультации/общение с заказчиками;

Все это усугубляется тем, что директор давно уже не программист (писал в DOS на FoxPro и поэтому до сих пор считает себя программистом), и у него любая задача, выполняемая программистом «это просто» и «должна быть сделана вчера», причем не особо интересует, что разработчик, по его же распоряжению отвлекается на другую задачу. Т.е. объяснить ему, что задача будет решаться 3 дня, а не 5 мин. дело невозможное. Для примера, он не понимает почему при запросе на СУБД 5 записей возвращаются дольше, чем 200 (естественно разные ХП вызываются). ? Мотивация обычно заключается в долгом и нудном рассказе о бизнесе и как это важно для фирмы. С фразами «кто, если не ты?», «чем ты то можешь обяснить?», «Как так?» и т.д.. В целом много забавного происходит, но и раздражает так же… вот поэтому и хочу узнать у общественности — нормальная/обычная ситуация? И как ее можно исправить? ? Сменой работы?!

Здравствуйте, danshar, Вы писали:

D>[Вы писалиВы писалиВы писалиВы писалиВы писалиВы писалиВы писали]

Ну это типично для маленьких контор или небольших IT отделов в не IT компании. Так, что меняй работу... И главное в резюме отрази свой "дополнительный" опыт.

PS А зп ниже рынка? Может в будущем твоя контора разрастется, а ты там будешь уже не просто программистом. Хотя с таким директором ...

Здравствуйте, BluntBlind, Вы писали:

Я тоже так думаю, т.е., что эти типично для небольших контор. Задал себе вопрос, про карьеру... нда надо менять... наверное уже давно надо менять было...

Частный случай:
Вот сейчас долго рассказывал про бизнес, что нужно ему встретится с каким-то крутым директором
и надо сделать программу для демонстрации сегодня, хотя в планах было к вечеру завтра.
И склоняли к выбору решения — отменить ли ему встречу или он на словах будет рассказывать и, что мы работаь не хотим и т.д. Во время "беседы" смешно было неоднократно. Ну емое, сказал бы "Ребята, ну дано сделать! Ну понимаю, что работать придется больше, ну я доплачу там $$$! Сделаете?!". Все! А так про бизнес и про бизнес....

BB>Здравствуйте, danshar, Вы писали:

D>>[Вы писалиВы писалиВы писалиВы писалиВы писалиВы писалиВы писали]

BB>Ну это типично для маленьких контор или небольших IT отделов в не IT компании. Так, что меняй работу... И главное в резюме отрази свой "дополнительный" опыт.

BB>PS А зп ниже рынка? Может в будущем твоя контора разрастется, а ты там будешь уже не просто программистом. Хотя с таким директором ...

Здравствуйте, danshar, Вы писали: [много букв]

Судя по количеству подобных историй на тему "Брали программистом, а работать приходится программистом-эникейщиком", ситуация довольно типичная. При поиске работы, имеет смысл, например, на собеседовании пообщаться с аналитиком, архитектором, техническим писателем и т.д., которые работают в той команде (с той командой), где планируется работать. И если таковых не оказывается — делать соответствующие выводы ("Кто, если не ты?"). А если таковые имеются, но Вы понимаете, что Ваши навыки в этом вопросе выше, чем их — тоже делать определенные выводы (это еще вопрос, что хуже — отсутствие, например, системного администратора или его наличие, но "лучше бы не было").

Здравствуйте, danshar, Вы писали:

D>Написал небольшое эссе о своей работе, не знаю в юмор или «О работе». Многое из написанного у самого вызывает улыбку, хотя это правда (субъективная конечно).
D>Захотелось узнать, что же программист должен делать на работе и что ему в итоге приходится делать. Тема наболевшая (для меня), т.к. все же считаю, что программист должен программировать.
D>Вначале ситуация. Занимаюсь разработкой программных продуктов. Это основная деятельность… по крайней мере мне так хочется думать. ? Конторка небольшая. Программистов двое ?.

Нормальная ситуация для маленькой конторки. Лечится уходом в большую — там будут свои заморочки.

Полезно поработать и там, и там, а потом можно открывать свою фирму.

Здравствуйте, Maxim Golov, Вы писали:

MG>Здравствуйте, danshar, Вы писали:

D>>Написал небольшое эссе о своей работе, не знаю в юмор или «О работе». Многое из написанного у самого вызывает улыбку, хотя это правда (субъективная конечно).
D>>Захотелось узнать, что же программист должен делать на работе и что ему в итоге приходится делать. Тема наболевшая (для меня), т.к. все же считаю, что программист должен программировать.
D>>Вначале ситуация. Занимаюсь разработкой программных продуктов. Это основная деятельность… по крайней мере мне так хочется думать. ? Конторка небольшая. Программистов двое ?.

MG>Нормальная ситуация для маленькой конторки. Лечится уходом в большую — там будут свои заморочки.

MG>Полезно поработать и там, и там, а потом можно открывать свою фирму.

Свою — это очень хорошо! А какие заморочки в большой?

Здравствуйте, danshar, Вы писали:

MG>>Нормальная ситуация для маленькой конторки. Лечится уходом в большую — там будут свои заморочки.
MG>>Полезно поработать и там, и там, а потом можно открывать свою фирму.

D>Свою — это очень хорошо! А какие заморочки в большой?

В большой — обычно узкая специализация. Если раньше ты мог напрямую общаться с заказчиками и пользователями, то в большой между конечным пользователем и конечным программистом находится толстый-толстый слой посредников, который работает как испорченный телефон. Поэтому если в малой конторе ты худо-бедно но мог решать "правильную" проблему, то в большой — шансов на это гораздо меньше (по крайней мере это будет зависить уже не от тебя). Кроме того меньше свободы в выборе технических решений: над программистом сидит архитектор, над которым более главный архитектор, над которым еще более главнее и в конце концов самый главный архитектор, который "писал в DOS на FoxPro и поэтому до сих пор считает себя программистом".

Здравствуйте, danshar, Вы писали:

D>• Иногда написание инструкции пользователя и технорабочего проекта;

Это еще ничего, а слабо написать всю ПД, начиная от ТЗ, заканчивая инструкциями программиста, системного программиста и т.д.?

По теме. Есть 2 пути — уговорить начальство нанять эникейщика/сисадмина/менеджера или искать другую работу.

Здравствуйте, dshe, Вы писали:

D>В большой — обычно узкая специализация. Если раньше ты мог напрямую общаться с заказчиками и пользователями, то в большой между конечным пользователем и конечным программистом находится толстый-толстый слой посредников, который работает как испорченный телефон. Поэтому если в малой конторе ты худо-бедно но мог решать "правильную" проблему, то в большой — шансов на это гораздо меньше (по крайней мере это будет зависить уже не от тебя). Кроме того меньше свободы в выборе технических решений: над программистом сидит архитектор, над которым более главный архитектор, над которым еще более главнее и в конце концов самый главный архитектор, который "писал в DOS на FoxPro и поэтому до сих пор считает себя программистом".

Нда! Видишь ли, а в конечном случае ведь этот "главный" архитектор и будет не прав, если заказчик не захочет продолжить сотрудничество?! Или свалят на конечных исполнителей? Ведь "по бумагам" можно будет увидеть, что именно аналитики и/или архитекторы были не правы?! В моем случае и пользовательский интерфейс сам проектируешь, а отом "ты же понимаешь? пользователь по другому видит".. а как он видит никто не знает...

Напрягает, то, что как бы не упирался — все равно хотят большего

D>Нда! Видишь ли, а в конечном случае ведь этот "главный" архитектор и будет не прав, если заказчик не захочет продолжить сотрудничество?! Или свалят на конечных исполнителей? Ведь "по бумагам" можно будет увидеть, что именно аналитики и/или архитекторы были не правы?! В моем случае и пользовательский интерфейс сам проектируешь, а отом "ты же понимаешь? пользователь по другому видит".. а как он видит никто не знает...

"Свалят на исполнителей" всё реже и реже прокатывает. Видишь ли, бизнесу совершенно неинтересно, главный ли архитектор ошибся, или "не главный". Владелец компании, если он не дурак, разберется в проблеме и уволит именно того, кого надо было уволить. Если он "промахнется", да еще несколько раз подряд, фирма развалится, так что, даже хорошо, если из нее уволят раньше, чем она пойдет ко дну.
Отсюда, делаем вывод. Если "главные архитекторы" все дураки и кроме DOS/FoxPro ничего не знают, то... их уволят. Если их не увольняют, значит, похоже, вовсе не в них загвоздка.


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

Большинству программистов заниматься мерзкой политикой противно. Не лежит к этому душа. Вот в этом и есть проблема больших контор.
А поработать хотя бы в одной большой конторе обязательно нужно. Чтобы просто понять — в мире людей рулит политика. И именно за политику платят деньги.

Честно говоря, не знал, что можно по другому Разве бывает так, что "разработчик" всегда выполняет только 1 функцию — "писать код", а остальное все разпределено по каким-то другим абстрактным людям? Я думаю, это сферический конь в вакууме не больше не меньше. Реально все обстоит обычно как ты и написал, у меня, например, еще больше обязанностей, вот неполный список

1) Собственно писать код проекта
2) Deployment всего что можно и не можно на stage и production сервера
3) Тестирование всего что можно на dev, stage, production
4) Общаться с заказщиком, выяснять ТЗ, сроки, баги, изменения, просто его развлекать и т.п.
5) Писать ТЗ, если его нет (english)
6) Писать пользовательскую документацию по тому, что уже сделанно, но небыло ТЗ (все делалось по логам MSN, например). Доки все на английском.
7) Искать в сети бесплатные и платные контролы, компоненты, инструменты для реализации очередных "гениальных идей" заказщика, тестить их, писать сравнительные отчеты, тестовые приложения.
8) Придумывать и раздавать таски команде
9) Писать отчеты по сделанным таскам и исправлениям
10) Ставить и настраивать весь рабочий софт на нескольких компах: своем и нескольких машинах заказщиков
11) Проводить рефакторинг кода
12) Писать code review членов команды и вообще проекта
13) Проводить оптимизацию (производительность) созданных приложений и сайтов
14) Изучать новые технологии, инструменты, писать тестовые приложения
15) Иногда — ковыряться в контенте ЦМС, делая работу Content writer'а.

список можно продолжать еще больше... Главное, чтобы оплату не задерживали, ИМХО, а насчет обязанностей — что сказали то и делаешь.

Здравствуйте, Davader, Вы писали:

D>Честно говоря, не знал, что можно по другому Разве бывает так, что "разработчик" всегда выполняет только 1 функцию — "писать код", а остальное все разпределено по каким-то другим абстрактным людям? Я думаю, это сферический конь в вакууме не больше не меньше. Реально все обстоит обычно как ты и написал

+1.
Мечта быть "чистым программистом" — утопия. Да даже если и есть фирмы, предлагающие такую работу — я лично бы обходил такое за километр. Ибо для меня это — деградация в кодера, оторванного от реалий жизни... в того самого сферического коня...

А человек, который минус поставил высказаться не желает ? Или он и есть тот самый сферический конь — идеальный програмист, который только пишет код целый день и все?

Здравствуйте, Davader, Вы писали:
D>А человек, который минус поставил высказаться не желает ? Или он и есть тот самый сферический конь — идеальный програмист, который только пишет код целый день и все?
Выскажусь, коль желаешь

D>1) Собственно писать код проекта
D>7) Искать в сети бесплатные и платные контролы, компоненты, инструменты для реализации очередных "гениальных идей" заказщика, тестить их, писать сравнительные отчеты, тестовые приложения.
D>9) Писать отчеты по сделанным таскам и исправлениям
D>11) Проводить рефакторинг кода
D>13) Проводить оптимизацию (производительность) созданных приложений и сайтов
D>14) Изучать новые технологии, инструменты, писать тестовые приложения
По этим пунктам согласен на 100%
D>12) Писать code review членов команды и вообще проекта
Что значит "вообще проекта"? Но с большего согласен
D>8) Придумывать и раздавать таски команде
Team Lead, PM — согласен, но речь в топике идет про "простого" программиста?
D>2) Deployment всего что можно и не можно на stage и production сервера
D>10) Ставить и настраивать весь рабочий софт на нескольких компах: своем и нескольких машинах заказщиков
Достаточно часто нет специально выделенного человека для этих нужд, так что скорее согласен. Хотя если развертывание системы весьма сложно и клиентов не 1-2, то, на мой взгляд, лучьше иметь отлеьного человека для этого.
D>3) Тестирование всего что можно на dev, stage, production
Если это нормальное функциональное тестирование, то отдельный тестер должен быть.
D>4) Общаться с заказщиком, выяснять ТЗ, сроки, баги, изменения, просто его развлекать и т.п.
Отдельный человек, который имеет понятие о бизнесе, для которого пишеться приложение.
D>5) Писать ТЗ, если его нет (english)
D>6) Писать пользовательскую документацию по тому, что уже сделанно, но небыло ТЗ (все делалось по логам MSN, например). Доки все на английском.
Лучьше чтобы это делал человек, который общался(п.4), но в конкретном случае — это ты так что все совпадает
D>15) Иногда — ковыряться в контенте ЦМС, делая работу Content writer'а.
То что именно тебя нагружали — это не значит, что так хотя бы у 90% программистов

Можно я сделаю предположение? Ты работаешь, скорее всего, в фирме не IT направления и у тебя в подчинении 2-3 разработчика, а проект небольшая система для внутренних нужд?

Здравствуйте, Dziman, Вы писали:


D>>12) Писать code review членов команды и вообще проекта
D>Что значит "вообще проекта"? Но с большего согласен

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

D>>8) Придумывать и раздавать таски команде
D>Team Lead, PM — согласен, но речь в топике идет про "простого" программиста?

ну я тим-лид по сути, но в принципе оффициально — "разработчик".. Developer точнее.

D>>2) Deployment всего что можно и не можно на stage и production сервера
D>>10) Ставить и настраивать весь рабочий софт на нескольких компах: своем и нескольких машинах заказщиков
D>Достаточно часто нет специально выделенного человека для этих нужд, так что скорее согласен. Хотя если развертывание системы весьма сложно и клиентов не 1-2, то, на мой взгляд, лучьше иметь отлеьного человека для этого.

развертывание достаточно сложно — всего больше 10 немаленьких сайтов ну и dll куча проектов и еще всякое консольное.. А насчет нанять человека — ну по идее этим должен заниматься асмерикос — ПМ наш, но ему лениво. А остальные не умеют ни 2) ни 10). Или не хотят. Для дева есть Nant скрипты (я написал, когда понял, что руками это пол-дня развертывать). Но на другие сервера автоматизировать не удалось.

D>>3) Тестирование всего что можно на dev, stage, production
D>Если это нормальное функциональное тестирование, то отдельный тестер должен быть.

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

D>>4) Общаться с заказщиком, выяснять ТЗ, сроки, баги, изменения, просто его развлекать и т.п.
D>Отдельный человек, который имеет понятие о бизнесе, для которого пишеться приложение.

О да Бугога... Тот для кого пишется приложение не может сформулировать и 15 слов внятно, обычная история. Ну а мне как тиму надо общаться с ПМом — иначе просто команда не будет знать, что делать. Так что без этого нельзя.

D>>5) Писать ТЗ, если его нет (english)
D>>6) Писать пользовательскую документацию по тому, что уже сделанно, но небыло ТЗ (все делалось по логам MSN, например). Доки все на английском.
D>Лучьше чтобы это делал человек, который общался(п.4), но в конкретном случае — это ты так что все совпадает

Конечно. Хотя 5) мог бы и америкос сделать, но лениво, опять же. 6) — кроме нас это никто не сможет сделать просто-напросто.

D>>15) Иногда — ковыряться в контенте ЦМС, делая работу Content writer'а.
D>То что именно тебя нагружали — это не значит, что так хотя бы у 90% программистов

ну в предыдущей моей конторе было почти так же, так что — не знаю, не знаю...

D>Можно я сделаю предположение? Ты работаешь, скорее всего, в фирме не IT направления и у тебя в подчинении 2-3 разработчика, а проект небольшая система для внутренних нужд?

Проект — большой коммерческий торговый портал со сложной админкой и кучей наворотов, фирма — IT что ни на есть, насчет команды — в точку.

Здравствуйте, Davader, Вы писали:
D>>Team Lead, PM — согласен, но речь в топике идет про "простого" программиста?
D>ну я тим-лид по сути, но в принципе оффициально — "разработчик".. Developer точнее.
Часто программистами называют anykey'щиков, но от этого программистами они же не становятся . Я свои замечания исходя из того что программист — это именно рядовой разработчик.
На мой взгляд, ты все-в-одном(программист, TL, тестер, техписатель и еще). Обычно такое происходит на небольших(или вялотекущих) проектах или для экономии средств

Здравствуйте, danshar, Вы писали:

D>В целом много забавного происходит, но и раздражает так же… вот поэтому и хочу узнать у общественности — нормальная/обычная ситуация? И как ее можно исправить? ? Сменой работы?!

Это типичная ситуация для случаев когда руководитель плохо разбирается в программировании и совершенно не умеет управлять проектами в софтверной области.
Человек попросту пытается управлять тобой как получается, плохо при этом представляя зачем он это все делает, его цель нагрузить тебе какойнить фигни чтобы ты не задавал неудобных вопросов, а там ты сам уж какнибудь разберешься и сделаешь чтото такое что нужно. Часто такие люди любят такую тактику, как рассказывать какуюто ахинею до тех пор пока у слушателя крыша не начнет ехать и он не начнет сердится и пытаться объяснить что к чему, он будет спорить, но на самом деле мотать на ус, т.е. узнавать таким своеобразным образом что к чему. Прямо спросить, видимо гордость не позволяет
Общаться с такими людьми вредно для психики

По сути работа с таким руководителем заключается в том что все будешь делать ты, а все бонусы будет получать он, тебе же наоборот будут доставаться все шишки, которые такой человек умело переложит на тебя

Мой совет — иди в нормальную софтверную компанию...

Здравствуйте, Dziman, Вы писали:

D>Часто программистами называют anykey'щиков, но от этого программистами они же не становятся . Я свои замечания исходя из того что программист — это именно рядовой разработчик.
D>На мой взгляд, ты все-в-одном(программист, TL, тестер, техписатель и еще). Обычно такое происходит на небольших(или вялотекущих) проектах или для экономии средств

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

Здравствуйте, Davader, Вы писали:

D>1) Собственно писать код проекта

Согласен.

D>2) Deployment всего что можно и не можно на stage и production сервера

Не согласен. Это зависит от вида создаваемого софта.

D>3) Тестирование всего что можно на dev, stage, production

По большей части тестеры должны этим заниматься.

D>4) Общаться с заказщиком, выяснять ТЗ, сроки, баги, изменения, просто его развлекать и т.п.

При производстве коробочного (а не заказного) софта с кастомерами имеют дело аналитики, product mangement, FAEы (field application engineer-ы) и архитекторы (хотя они не всегда). Потребности кастомеров так же выявляются путем анализа их enhancement request-ов и на таких мероприятиях, как user group conference.

D>5) Писать ТЗ, если его нет (english)

Зависит от ситуации и используемой методологии разработки.

D>6) Писать пользовательскую документацию по тому, что уже сделанно, но небыло ТЗ (все делалось по логам MSN, например). Доки все на английском.

Технические писатели должны писать документацию. Девелоперы и архитекторы оказывают помощь в виде консультаций.

D>7) Искать в сети бесплатные и платные контролы, компоненты, инструменты для реализации очередных "гениальных идей" заказщика, тестить их, писать сравнительные отчеты, тестовые приложения.

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

D>8) Придумывать и раздавать таски команде

Обычно это делает PM или team leader.

D>9) Писать отчеты по сделанным таскам и исправлениям

Зависит от организации процесса работы. Написание отчетов не должно занимать больше времени, чем собственно имплементация таска.

D>10) Ставить и настраивать весь рабочий софт на нескольких компах: своем и нескольких машинах заказщиков

Зависит от типа производимого софта. В нормальных случаях это задача tech support-а.

D>11) Проводить рефакторинг кода

Угу, согласен, если рефакторинг одобрен.

D>12) Писать code review членов команды и вообще проекта

Зависит от размера проекта. Миллионы строк кода не всегда проревьювишь в одиночку Ревьювить код должны senior-ы и архитекторы.

D>13) Проводить оптимизацию (производительность) созданных приложений и сайтов

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

Здравствуйте, Dziman, Вы писали:

D>На мой взгляд, ты все-в-одном(программист, TL, тестер, техписатель и еще). Обычно такое происходит на небольших(или вялотекущих) проектах или для экономии средств

Такой "мастер на все руки" — обычная практика в небольших фирмах. И дела у этих самых фирм идут прекрасно, и проекты бьют фонтаном. Ибо иначе у маленькой фирмы просто быть не может — тогда она просто сдохнет. А "вялотекучесть" — это в основном удел больших компаний, с их "чистыми", "настоящими" программистами.

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

Все вышеизложенное относилось к Германии, хотя, думаю, в софтовой сфере в России ситуация ненамного отличается.