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

_FR>>Так что если наберётся "несколько тыщ строк", которые кандидату не стыдно показать и, затем, обсудить гораздо важнее голословных (ничего не говорящих _о кандидате_ существенного) цифер с нулями.

B>Если ты претендуешь на тим лида, то показывать те "несколько тыщ строк",
B>которыми ты гордишься, нету никакого смысла.
B>Вернее это очень мало…

А показывать мильон смысл есть? То-то, и я как раз на этом заострил внимание.

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

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

B>Ведущий программер должен показать, что он успешно работает именно в команде.

ОК, не тим-лид, а "ведущий". Это уже в кассу. Я не знаю критериев "успешной работы в команде" Вернее, каких-то особенных критериев для команды программистов. Если человек работал в команде начальника, его секретарши, её ухажёра и жены начальника впридачу с бухгалтером, охранником, уборщицей и сисадмином, то это опыт работе в команде.
Это опыт… [не знаю, как правильно сказать ] разделения, обмена мыслями с другими людьми с целью выслушать критику, переосознать или, наоборот, утревлиться в своих выводах. Умение вовремя (+-) сделать то, что обещал (написать класс или принести какую-нить справку в администрацию — не важно!).

B>Автор топика явно не работал в команде. Именно по этому он не может претендовать
B>ни на сеньора, ни на лидера...
B>Его 30000 строк кода скорее всего никто не видел.
B>Врядли он с кем-то обсуждал те или иные архитектурные решения.
B>Даже если он миллион строк наваяет, толку от этого мало, если он это делал в одиночку.

Бу… Весьма поспешно и бездоказательно. Основываясь на своих ощущениях или опыте я тоже могу написать чот-то для других странное. Но это не интересно. Я бы сказал, "Скорее всего, не может…". Тут же выглядит как приговор

B>Да и вообще.... Писать новый код — проще паренной репы
B>Сложно его писать так, чтобы его было легко сопровождать.
B>А оценить это можно только со временем.

А вот тут не соглашусь категорически :о)) Можно "оценить" скорее. Ведь правильный, "лекго сопровождаемый" код похож друг на друга (и узнаеть его не сложно по тем строчкам, которыми автор гордится), в то время как странных, проблемный код очень сильно разнится.

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

_FR>Я не знаю критериев "успешной работы в команде" Вернее, каких-то особенных критериев для команды программистов. Если человек работал в команде начальника, его секретарши, её ухажёра и жены начальника впридачу с бухгалтером, охранником, уборщицей и сисадмином, то это опыт работе в команде.

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

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

Да и вообще, "лид", "сеньор" и прочие приставки — это признаки некой иерархии,
которая возможно только в команде
Если ты один, то ты сам себе и подчиненный и начальник и бог в одном лице

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

_FR>>Я не знаю критериев "успешной работы в команде" Вернее, каких-то особенных критериев для команды программистов. Если человек работал в команде начальника, его секретарши, её ухажёра и жены начальника впридачу с бухгалтером, охранником, уборщицей и сисадмином, то это опыт работе в команде.

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

Мне только кажется, или ты действительно стараешься сказать "всё ни о чём"? Зачем так обтекаемо и неясно? Можешь ли ты назвать несколько факторов (коих я не знаю ни одного) о специфике команды программистов?

B>Работа в нормальной команде — это то, без чего ты не станешь профи.
B>Тут можно довольно много чего сказать.

К сожелению, это мне непонятно, ибо точного определения понятий "нормальная команда" и "профи" мне так же неизвестно

B>Одиночка, который варится в собственном соку, имеет куда меньше шансов развиться как профи.

Развиться в профессиональном плане можно именно одному: читая и делая потытки. В этом не поможет никто. Но далее требуется трезвый взгляд со стороны на результаты попыток. Иметь такой взгляд под боком — редкое везение и далеко не многие могут им похвастать. Обычно приходится (например, мне) сравнивать своё с тем, что делают другие и находить этих самых других в инете (то есть тут ) Так что развитие "в отрыве от команды" более чем возможно.

B>Понятно что есть исключения и есть такие команды, где фиг разовьешься,
B>но в целом тенденция именно такая.

B>Сложные продукты создаются коллективами, а не одиночками.
B>Реально развиться можно только решая сложные проблемы на нетривиальных проектах.

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

B>Да и вообще, "лид", "сеньор" и прочие приставки — это признаки некой иерархии,
B>которая возможно только в команде

Нет, между тим-лидом и сеньёр-разработчиком есть разница. Кстати, да: как раз тим-лид\управленец и может похвастаться крупным проектом. То, что он какое-то время существовал — его заслуга. Заслуга программиста, его визитная карточка — это качественный код. И я не вижу разницы, является ли этот код частью "огроменного проектища" или же "небольшой поделочкой".

B>Если ты один, то ты сам себе и подчиненный и начальник и бог в одном лице



Между прочим: мне известны люди, заработавшие весьма и весьма добрую славу в профессиональных кругах на поприще фриланса. Они — несомненно одиночки и это не мешает им быть всесторонне развитыми профессионально

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

_FR>Мне только кажется, или ты действительно стараешься сказать "всё ни о чём"? Зачем так обтекаемо и неясно? Можешь ли ты назвать несколько факторов (коих я не знаю ни одного) о специфике команды программистов?

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

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

Успешность работы команды тоже вполне реально оценить.
За команду говорят те проекты, которые она довела до конца.
Туда попадут и все отставания от сроков, и статистика по багам,
и скорость реакции на новые требования и прочее прочее прочее...
При большом желании это можно даже объективно померить и выдать цифирь
Не спрашивай меня про то, как ее вычислить
Я все равно тебя отправлю в форум "управление проектами"

"Сеньора" вполне можно оценить по тому, что он делал в командных проектах.
Моя же мысль в том, что человеку нет смысла мечтать о "сеньорстве",
если он не работал в команде. Не дорос он еще до этого...
Он может после первого же review уйдет обиженным

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

_FR>>Мне только кажется, или ты действительно стараешься сказать "всё ни о чём"? Зачем так обтекаемо и неясно? Можешь ли ты назвать несколько факторов (коих я не знаю ни одного) о специфике команды программистов?

B>Ну я даже не знаю, что тебе сказать.
B>Работа в коллективе принципиально отличается от работы одиночки.
B>Я не пишу про это протому что писать придется слишком много.
B>Зайди на форум "управление проектами" и ты увидешь типичные проблемы и особенности работы в команде.

Не спорю, даже поддерживаю! Но я о "разнице работы в коллективе" и "разнице работы в коллективе программистов"

B>Тут тебе будет и стандарты кодирования…

Они и одному необходимы, если он понимает, чо делает.

B>…и особенности принятия коллективных решений и многое другое...

В интернет-обсуждениях и бытовых спорах треннируются те же навыки Или взять. например. время обучения в школе и институте. Чем не навыки общения, доказывания точки зрения и принятия компромисса?

B>На этом форуме практически нету вопросов, которые имеют смысл, если ты один в поле.

Вот уж нет. нету вопросов, которые не имеют смысла, если ты "пишешь в стол" для чёрте-кого и лишь бы поскорей об этом забыть. То есь если сам Если ты один, то что мешает писать "на века", что бы "…песня!!!"?

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

Как же так? Декомпозиция, например, уже не всчёт? Опять же умение "распараллеливать" можно приобрести и в реале.

B>Ты один и ни от кого не зависишь. Работаешь так, как считаешь нужным.
B>Команда так работать не может.

Хе-хе! Это можно читать обоюдоострым утрерждением, смысл которого зависит от уровня "одиночки". Если он достаточно большой, то никакой команде за ним, естественно (в смысле уровня и класса), не угнаться и "так она работать не сможет".

B>Успешность работы команды тоже вполне реально оценить.
B>За команду говорят те проекты, которые она довела до конца.

Что значит "до конца"? я вот не помню ни одного проекта, который довёл до "счастливого" конца (заглохшие и сгинувшие ведь нас не интересуют?)

B>Он может после первого же review уйдет обиженным

Возможно! Но не это показатель класса. показатель класса: если он вернётся и либо докажет тебе, что review было проведено нерпавильно и претензии оказались необоснованными или же с исправлениями — то это Уважуха вот если не вернётся — то


ЗЫ: По ошущенным здесь цитатам у меня сложилось вчепятление, что у тебя какое-то фанатичное, "шапкозакидательское", предвзятое отношение к обсуждаемому вопросу. "команда", "колелктив", "управление проектами", … — "общие места", как сказала бы моя учительница по литературе

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

MC>Наверное потому, что сейчас возвращаюсь из ОАЭ домой и компания ищет замену. Я лично просмотрел уже штук 50 резюме, пообщался с 5 претендентами

http://www.rsdn.ru/forum/message/2628541.1.aspx

Автор: Sergei Soloviev
Дата: 21.08.07

Вы уже нашли друг друга?

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

_FR>Но я о "разнице работы в коллективе" и "разнице работы в коллективе программистов"

Разница простая. Ты не один.
Тебе этого мало?
А то что в команде надо уметь разбираться в чужом коде сомнений не добавляет?


B>>Тут тебе будет и стандарты кодирования…

_FR>Они и одному необходимы, если он понимает, чо делает.

Ты еще скажи, что одиночка сам с собой code review проводит.
Хотел бы я на это зрелище посмотреть

B>>…и особенности принятия коллективных решений и многое другое...

_FR>В интернет-обсуждениях и бытовых спорах треннируются те же навыки Или взять. например. время обучения в школе и институте. Чем не навыки общения, доказывания точки зрения и принятия компромисса?

Это не то. Мы вот с тобой тоже вроде как спорим. Но это просто обмен мнениями,
который ни к чему не обязывает. Работа в команде требует эффективности и принятия
решений, что, в том числе, требует компромиссов.
Грубо говоря, переодически требуется наступать самому себе на горло
Работая в одиночку мне редко когда приходилось наступать самому себе на горло.
Работая в одиночку я так же никогда не был свиделем идиотских решений

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

_FR>Как же так? Декомпозиция, например, уже не всчёт? Опять же умение "распараллеливать" можно приобрести и в реале.

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

B>>Успешность работы команды тоже вполне реально оценить.
B>>За команду говорят те проекты, которые она довела до конца.

_FR>Что значит "до конца"? я вот не помню ни одного проекта, который довёл до "счастливого" конца (заглохшие и сгинувшие ведь нас не интересуют?)

Сочувствую... Тебе явно не везло и работаешь ты видимо не так давно.
Я уже довольно много выпил по поводу успешно завершенных проектов
"До конца" — означает сделано все, что запланировано; продуктом реально пользуются;
есть отклик пользователей (довольных и недовольных) и есть планы по выпуску следующей версии.

B>>Он может после первого же review уйдет обиженным

_FR>Возможно! Но не это показатель класса. показатель класса: если он вернётся и либо докажет тебе, что review было проведено нерпавильно и претензии оказались необоснованными или же с исправлениями — то это Уважуха вот если не вернётся — то

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

_FR>ЗЫ: По ошущенным здесь цитатам у меня сложилось вчепятление, что у тебя какое-то фанатичное, "шапкозакидательское", предвзятое отношение к обсуждаемому вопросу. "команда", "колелктив", "управление проектами", … — "общие места", как сказала бы моя учительница по литературе

Мы вот только что начали небольшой проект на 20 человеко лет.
Если ты будешь вкалывать один, то лет через 30 его закончишь.
Нам надо его закончить через год, при этом так, чтобы было возможно
наращивать функциональность в последующие 6-8 лет.
Вот собственно и все шапкозакидательство.

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

_FR>>Но я о "разнице работы в коллективе" и "разнице работы в коллективе программистов"

B>Разница простая. Ты не один.
B>Тебе этого мало?
B>А то что в команде надо уметь разбираться в чужом коде сомнений не добавляет?

Рабираться в исходниках sscli или инфрагистика приходится и работая одному

B>>>Тут тебе будет и стандарты кодирования…
_FR>>Они и одному необходимы, если он понимает, чо делает.

B>Ты еще скажи, что одиночка сам с собой code review проводит.
B>Хотел бы я на это зрелище посмотреть

опубликовать свой кусок кода в форуме Исходники — например, прекрасный вариант ревью.

B>>>…и особенности принятия коллективных решений и многое другое...

_FR>>В интернет-обсуждениях и бытовых спорах треннируются те же навыки Или взять. например. время обучения в школе и институте. Чем не навыки общения, доказывания точки зрения и принятия компромисса?

B>Это не то. Мы вот с тобой тоже вроде как спорим. Но это просто обмен мнениями,
B>который ни к чему не обязывает. Работа в команде требует эффективности и принятия
B>решений, что, в том числе, требует компромиссов.

Да уж, мы с тобой эффективны в своём споре

B>Грубо говоря, переодически требуется наступать самому себе на горло
B>Работая в одиночку мне редко когда приходилось наступать самому себе на горло.
B>Работая в одиночку я так же никогда не был свиделем идиотских решений

Ага, так ты о себе? И не можешь даже допустить возможность, что у кого-то может быть не так?

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

_FR>>Как же так? Декомпозиция, например, уже не всчёт? Опять же умение "распараллеливать" можно приобрести и в реале.

B>В каком реале? На реальных проектах? СОгласен. Это только в реале и приобретается.

Нет, в задачах "реальной" жизни: и на работе успеть, и жену в ресторан сводить, и дочку из садика забрать и к любовнице наведаться.

B>Но вот когда я работал один, то мне ни разу не приходилось ждать самого себя
B>А вот сейчас, работая в команде, я почему-то постоянно оказываюсь на критическом пути.
B>Разницу я ощущаю всем нутром

когда работаешь один — ты не совсем один. Ведь кто-от задаёт требования и "ждать самого себя" — о-го-го как!

B>>>Успешность работы команды тоже вполне реально оценить.
B>>>За команду говорят те проекты, которые она довела до конца.

_FR>>Что значит "до конца"? я вот не помню ни одного проекта, который довёл до "счастливого" конца (заглохшие и сгинувшие ведь нас не интересуют?)

B>Сочувствую... Тебе явно не везло и работаешь ты видимо не так давно.
B>Я уже довольно много выпил по поводу успешно завершенных проектов

Бедняга…

B>"До конца" — означает сделано все, что запланировано; продуктом реально пользуются;
B>есть отклик пользователей (довольных и недовольных) и есть планы по выпуску следующей версии.

То есть "завершённый проект" — это проект, доживший до первой версии Не, это только начало жизни проекта, его рождение То, что было до первого релиза — это секс, который "педанты" стараются сделать качественным, красивым и запоминающимся всем участникам, а некоторые прочие: завершить поскорей, поставить себе галочку и подумать о чём-либо ещё. Последнии как-раз-таки и считают разы. А вот первые — запоминают ощущения.

B>>>Он может после первого же review уйдет обиженным

_FR>>Возможно! Но не это показатель класса. показатель класса: если он вернётся и либо докажет тебе, что review было проведено нерпавильно и претензии оказались необоснованными или же с исправлениями — то это Уважуха вот если не вернётся — то

B>Похоже что ты думаешь, что ревью устраивают с целью доказать правоту.
B>Это не так.

С целью в дискуссии оценить результат чего-либо. Назови своё определение и покажи, что оно не подходит под мою аналогию.

_FR>>ЗЫ: По ошущенным здесь цитатам у меня сложилось вчепятление, что у тебя какое-то фанатичное, "шапкозакидательское", предвзятое отношение к обсуждаемому вопросу. "команда", "колелктив", "управление проектами", … — "общие места", как сказала бы моя учительница по литературе

B>Мы вот только что начали небольшой проект на 20 человеко лет.
B>Если ты будешь вкалывать один, то лет через 30 его закончишь.
B>Нам надо его закончить через год, при этом так, чтобы было возможно
B>наращивать функциональность в последующие 6-8 лет.
B>Вот собственно и все шапкозакидательство.

15см? 25!

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

_FR>15см? 25!

Ты про что? Впрочем не важно.

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

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

B>Это типа была демонстрация разницы работы в команде и в одиночку.
B>Сейчас мы с тобой дискутируем как 2 независимых друг от друга человека.
B>Ты можешь поставить смайлик, сказать, что bkat — мутный тип, который сам
B>не знает о чем говорит, меряется пиписьками и на этом все и закончится.

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

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

Не прибедняйся, моя ещё страшнее

B>В другой команде тебе пришлось бы терпеть других странных типов.
B>Это одно из принципиальных различий работы в команде от работы в одиночку.

"странных типов" приходится терпеть повсюду

Чесслово, я не увидел ни одного различия между обычной командой и командой программистов (с твоих слов)

У меня есть один вопрос. Если я прихожу в фирму и вижу что мой уровень повыше уровня остальных программистов (несмотря на то что до этого я работал только один, либо вдвоем с напарником), разве я не могу быть senior software developer там? Или для этого, как сообщают в этой дискуссии, обязательно надо будет сначало пару лет работать с ними якобы на равных?

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

MC>У меня есть один вопрос. Если я прихожу в фирму и вижу что мой уровень повыше уровня остальных программистов (несмотря на то что до этого я работал только один, либо вдвоем с напарником), разве я не могу быть senior software developer там? Или для этого, как сообщают в этой дискуссии, обязательно надо будет сначало пару лет работать с ними якобы на равных?

Не бери в голову названия должностей и отталкивайся от этого правила. Пускай другие называют себя как им угодно — это их дело и это _не важно_.

Я вот недавно стал в "менеджером по разработке програмного обеспечения" Ну как к этому можно относиться серьёзно Только не обращая внимание

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

MC>У меня есть один вопрос. Если я прихожу в фирму и вижу что мой уровень повыше уровня остальных программистов (несмотря на то что до этого я работал только один, либо вдвоем с напарником), разве я не могу быть senior software developer там? Или для этого, как сообщают в этой дискуссии, обязательно надо будет сначало пару лет работать с ними якобы на равных?

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

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

MC>У меня есть один вопрос. Если я прихожу в фирму и вижу что мой уровень повыше уровня остальных программистов (несмотря на то что до этого я работал только один, либо вдвоем с напарником), разве я не могу быть senior software developer там?

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

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

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

_FR>Чесслово, я не увидел ни одного различия между обычной командой и командой программистов (с твоих слов)

Ну это только говорит о моем красноречии

А сам ты и в самом деле различий не видишь?
Ни в организации работы, ни в объеме решаемых задач,
ни в необходимости координации всего и вся, если это затрагивает хотя бы 2 персоны?

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

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

Очень даже стоит, особенно если фрилансишь и паралельно ведешь пару своих
проектов

B>Ты один и ни от кого не зависишь. Работаешь так, как считаешь нужным.

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

B>Команда так работать не может.

B>Успешность работы команды тоже вполне реально оценить.
B>За команду говорят те проекты, которые она довела до конца.
B>Туда попадут и все отставания от сроков, и статистика по багам,
B>и скорость реакции на новые требования и прочее прочее прочее...
B>При большом желании это можно даже объективно померить и выдать цифирь
B>Не спрашивай меня про то, как ее вычислить
B>Я все равно тебя отправлю в форум "управление проектами"

У нормального одиночки профессионала такая статистика также ведется и
доступна для анализа.

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

B>А то что в команде надо уметь разбираться в чужом коде сомнений не добавляет?

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

B>>>Тут тебе будет и стандарты кодирования…

_FR>>Они и одному необходимы, если он понимает, чо делает.

B>Ты еще скажи, что одиночка сам с собой code review проводит.
B>Хотел бы я на это зрелище посмотреть

Нормальное зрелище. Называется "читать код" часто помогает сильно съэкономить на отладке.

B>>>…и особенности принятия коллективных решений и многое другое...

_FR>>В интернет-обсуждениях и бытовых спорах треннируются те же навыки Или взять. например. время обучения в школе и институте. Чем не навыки общения, доказывания точки зрения и принятия компромисса?

B>Это не то. Мы вот с тобой тоже вроде как спорим. Но это просто обмен мнениями,
B>который ни к чему не обязывает. Работа в команде требует эффективности и принятия
B>решений, что, в том числе, требует компромиссов.

У одиночки тоже самое если проекты не тривиальны.

B>Грубо говоря, переодически требуется наступать самому себе на горло
B>Работая в одиночку мне редко когда приходилось наступать самому себе на горло.

Мне кажется ты просто не делал в одиночку достаточно сложных проектов, с изменяющимися
по ходу разработки требованиями.

B>Работая в одиночку я так же никогда не был свиделем идиотских решений

Просто попробуй посмотреть свой же код N летней давности

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

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

MC>>Добрый день,
MC>> Хотел спросить у знающих людей чтобы мне в кратце объяснили про значения уровней программистов, т.е. Software Developer, Senior Software Developer, Lead Software Developer, Team Leader и т.д.

BZ>вот кстати ответ под которым я могу подписаться: http://hh.ru/vacancy/906859 . взят из соседней ветки


Хорошо, мне тоже стало интересно на что я могу претендовать, если я:
1. Тоже имею 2 года опыта работы в достаточно крупной конторе.
2. Работаю в коллективе программистов с многолетним опытом работы, в основном явл. выпускниками МИФИ, Бауманки, МГУ.

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

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

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

Функциональная спецификация осуществлялась лично мной, но ессно контролировалась как со стороны старших коллег, так и начальства.
Тестирование и поддержка осуществляется специально выделенными людьми в команде.

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

Вопрос: относится ли выполнение описанных мною задач к senior software developer?

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

E>Если бы так было, как ты говоришь, то все мелкие начальники были бы 40-50 летнего возраста. но что-то таких сложно найти в софтверных конторах. А все перечисленные тобой категории , как правило, моложе 30-ти.

Потому что ай-ти отрасль росла как на дрожжах — достаточного количества опытных людей банально не было.

E>После все умные люди уже забывают автоинкременты и гуиды, садятся в ворд и аутлук и становятся пиЭмами.

Ну, а сразу после этого начинается полная жО.

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

MC>Если у меня 2.5 года опыта работы с .NET, PHP, БД, то на какую позицию мне лучше и реальнее претендовать? Senior Software Developer или Lead Software Developer? Как будет смотреться в резюме если после 2х лет опыта позиция — просто Software Developer?

Смотря что вы сделали за эти 2.5 года Возможно, что вы можете претендовать на "Lead Software Developer", а возможно вам светит только позиция программист-стажер. Учет в сутках никого не волнует.