Здравствуйте, Ушастый Ёж, Вы писали: УЁ>30,000 строк это очень мало. Вот когда в проекте кол-во строк зайдет за миллиончик — тогда можно надуть щеки и сказать что проект серьезный.
Нет. Тогда можно будет сказать, что "труп раздуло".
Здравствуйте, MozgC, Вы писали:
MC>Если у меня 2.5 года опыта работы с .NET, PHP, БД, то на какую позицию мне лучше и реальнее претендовать? Senior Software Developer или Lead Software Developer? Как будет смотреться в резюме если после 2х лет опыта позиция — просто Software Developer?
Вы закончили стажировку и перешли в категорию "молодой специалист". В IT секторе РФ этому уровню может соответствовать любое звание от "разработчика" до "старшего технического директора". В целом, чем хуже контора, тем выше звания.
MC> Хотел спросить у знающих людей чтобы мне вкратце объяснили про значения уровней программистов, т.е. Software Developer, Senior Software Developer, Lead Software Developer, Team Leader и т.д. MC>Какие требования предъявляются к кандидатам на эти уровни? Как примерно понять какого уровня человек? Какой опыт в среднем необходим для каждого уровня?
В России? Считайте, что никакие. Не доросли мы до этого.
Software Developer 4-10 (редко 2-5) лет опыта коммерческой разработки. Человек редко допускающий очевидные ляпы. Senior Software Developer 10+ лет опыта Lead Software Developer 15(редко 10)+ лет опыта. Знание многих архитектур. Участие в проектах 1 000 000 + строк кода. Опыт имплементации 1000+ юзкейсов. Свободное разворачивание обычного CRUD-а в альтернативные сценарии на пару десятков страниц, понимании преобразования разных видов требований друг в друга и в код и т.д. Умение составить модель предметной области сайта rsdn (часов четырех, я думаю, будет достаточно) и преобразовать ее в иерархию классов (еще 4-8 часов), после чего реализовать все это на функциональном псевдоязыке . Знание ограничений автоикремента и гуида на уровне мозжечка. Знание и опыт участия в разработке нескольких стандартов кодирования. Да, и естественно, прочтение не менее полуметра книг по разработке + нескольких тысяч статей + десяток собственных статей ОТРЕЦЕНЗИРОВАННЫХ другими специалистами. Team Leader 15(редко 10)+ лет опыта кроме технических качеств имеет опыт в управлении и серьезную подготовку в преподавании (от 1000 часов). Знакомство с несколькими методологиями разработки. Способность самостоятельно составить описание технических процессов и рассказать какие из них лучше подходят для конкретного проекта. Опыт в управлении и контроле качества выпускаемого продукта и процессов. Это другая ветвь развития.
С другой стороны, я не программист, так что может и не прав.
Здравствуйте, MozgC, Вы писали:
MC>Если у меня 2.5 года опыта работы с .NET, PHP, БД, то на какую позицию мне лучше и реальнее претендовать? Senior Software Developer или Lead Software Developer? Как будет смотреться в резюме если после 2х лет опыта позиция — просто Software Developer?
Не меньше, чем Lead Architect требуй
А если сурьезно — не видел людей с двухлетним опытом, которым не страшно было бы отдать что-то больщее, чем рисование формочек. А до лидов с таким опытом — как до Пекина р....
Здравствуйте, MozgC, Вы писали:
MC>Ясно... Ну а на позицию Senior S.D. нормально претендовать с 2.5 — 3 годами опыта или слишком нагло?
Прямо как дите...
Можно быть Senior Software Design Architect с разплатой $1000
Можно быть Software Developper с зарплатой $5000
Какая разница, как называется должность?
Senior — это как правило ничего не значая приставка. Это как в госконторах — надо поднять ЗП — начинают оформлять "категории" и "разряды". У меня в трудовой есть записи — программист 1 категории, старший программист и т.д.
Здравствуйте, kaa.python, Вы писали:
KP>Опыт очень небольшой. Я считаю что до позиции Senior Software Developer еще расти и расти (ну года 2 точно).
Извините, но некрасиво выглядит, когда рядом со ссылкой на свое краткое резюме Вы даете такие советы.
Согласно Вашей записи в moikrug у Вас было три года опыта работы программистом (из них 2.5 совпали с Вашим обучением в вузе, т.е. чистой работы — всего полгода), прежде чем Вы стали "ведущим программистом". А сейчас Вы лихо перечеркнули 2.5 года работы другого человека, сказав "еще расти и расти (ну 2 года точно)".
Здравствуйте, MozgC, Вы писали:
MC>Как будет смотреться в резюме если после 2х лет опыта позиция — просто Software Developer?
Software Developer — это то, что и стоит писать.
У меня опыт поболе будет и ничего кроме Software Developer
я в резюме не пишу и писать собираюсь.
Software Developer — это говорит о том, что человек занимается разработкой софта.
Что конкретно он делал — это должно быть видно из основной части резюме.
Здравствуйте, Ушастый Ёж, Вы писали:
УЁ>30,000 строк это очень мало. Вот когда в проекте кол-во строк зайдет за миллиончик — тогда можно надуть щеки и сказать что проект серьезный.
Несколько десятков коммерчески успешных проектиков по несколько тыщ строк, которые поддерживаются (в live) уже несколько лет — более весомый повод "надуть щёки"
Так что разговоры про сотни тысяч и миллионы — равно разговоры про сантиметры. Всё дело — в качестве работы. Вот что будет являеться "мерилом" и для тим-лида и для кадровика (в смысле брать\не брать и на сколько). Так что если наберётся "несколько тыщ строк", которые кандидату не стыдно показать и, затем, обсудить гораздо важнее голословных (ничего не говорящих _о кандидате_ существенного) цифер с нулями.
Help will always be given at Hogwarts to those who ask for it.
Добрый день,
Хотел спросить у знающих людей чтобы мне в кратце объяснили про значения уровней программистов, т.е. Software Developer, Senior Software Developer, Lead Software Developer, Team Leader и т.д.
Какие требования предъявляются к кандидатам на эти уровни? Как примерно понять какого уровня человек? Какой опыт в среднем необходим для каждого уровня?
Если у меня 2.5 года опыта работы с .NET, PHP, БД, то на какую позицию мне лучше и реальнее претендовать? Senior Software Developer или Lead Software Developer? Как будет смотреться в резюме если после 2х лет опыта позиция — просто Software Developer?
N>Вы хотите сказать, что на новой работе выполняете те же обязанности, что и на старой, но должность у вас "ниже"?
Я хочу сказать, что должность формально ниже, а зарплата сильно выше. При этом мне плевать на наличие приставки Senior. Пусть хоть Junior напишут, лишь бы ЗП нормальную платили.
Здравствуйте, MozgC, Вы писали:
MC>Добрый день, MC> Хотел спросить у знающих людей чтобы мне в кратце объяснили про значения уровней программистов, т.е. Software Developer, Senior Software Developer, Lead Software Developer, Team Leader и т.д. MC>Какие требования предъявляются к кандидатам на эти уровни? Как примерно понять какого уровня человек? Какой опыт в среднем необходим для каждого уровня?
MC>Если у меня 2.5 года опыта работы с .NET, PHP, БД, то на какую позицию мне лучше и реальнее претендовать? Senior Software Developer или Lead Software Developer? Как будет смотреться в резюме если после 2х лет опыта позиция — просто Software Developer?
а после 10 ты на что собираешься претендовать?
большого опыта у тебя нет — ты варился в собственном соку и больше рос как офисный работник
сеньор — разбирается в наиболее сложных вещах, участвует в проектировании, учит других, разжёвывает им задачи, инспектирует результаты их работы. соответственно, опыт должен включать знание наиболее сложных из применяемых в данном проекте технологий, умение проектировать не очень большие вещи, аргументированно отстаивать свою точку зрения на дизайн, стиль кодирования и т.п., умение возиться с менее квал. программистами
лидер — помимо этого, отвечает за техническую часть проекта в целом. т.е. доводит задачу от ТЗ до готового продукта, делегируя работу своим подчинённым. нужно представлять жизненный цикл ПП, разбираться во всех его этапах как минимум на уровне необходимом для выбора исполниетелей и контроля результатов их работы. при этом делательно ещё быть яркой личностью, за которой идут другие люди
ps: впрочем, это всё теория. на практике, как я замечаю, понятие senior часто означает либо что фирма верит, что предалагет зарпалту выше среднего, либо она громкими титулами надеется скомпенсировать зарплату ниже среднего
лучше ориентируйся по требованиям к знанию технологий, явному упоминанию о "людях в подчинении" и "ответственности за дизайн" и конечно размеру з/п. она хоть и разная у разных фирм даже за одно и то же, но всё же большая з/п — достаточно надёжный индикатор больших требований
M>Не меньше, чем Lead Architect требуй M>А если сурьезно — не видел людей с двухлетним опытом, которым не страшно было бы отдать что-то больщее, чем рисование формочек. А до лидов с таким опытом — как до Пекина р....
сейчас не сложно и Project Manager встретить с таким опытом работы (буквально недавно знакомая американско-питерская контора такого взяла) и соответствующими познаниями, да и не редкость когда люди с 1.5 годами работы начинают себя позиционировать как Senior Software Developer .. я в 21 тоже думал что я пуп земли, а сейчас вот думаю что хорошо что мне кроме как формочки рисовать ничего не давали
Здравствуйте, _Obelisk_, Вы писали:
_O_>Просто вы с большими проектами не сталкивались. Когда работаешь с проектом где несколько миллионов строк кода, то 30 000 — это совсем не много.
Работа с миллионами строк называется по-другому — обслуживание.
С другой стороны, я, например, где-то полгода работал над алгоритмом, который получился всего-то в 2000 строк.
Но должен признать, что по неким вторичным половым признакам те упомянутые 30000 строк — это абсолютная банальность.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, _FRED_, Вы писали:
_FR>Я не знаю критериев "успешной работы в команде" Вернее, каких-то особенных критериев для команды программистов. Если человек работал в команде начальника, его секретарши, её ухажёра и жены начальника впридачу с бухгалтером, охранником, уборщицей и сисадмином, то это опыт работе в команде.
Если программер работал в "команде начальника, его секретарши, её ухажёра и жены начальника впридачу с бухгалтером, охранником, уборщицей и сисадмином", то это его личный опыт и эта информация
говорит кое о чем говорит. По крайней мере я смогу сделать выводы
Работа в нормальной команде — это то, без чего ты не станешь профи.
Тут можно довольно много чего сказать.
Одиночка, который варится в собственном соку, имеет куда меньше шансов развиться как профи.
Понятно что есть исключения и есть такие команды, где фиг разовьешься,
но в целом тенденция именно такая. Сложные продукты создаются коллективами, а не одиночками.
Реально развиться можно только решая сложные проблемы на нетривиальных проектах.
Да и вообще, "лид", "сеньор" и прочие приставки — это признаки некой иерархии,
которая возможно только в команде
Если ты один, то ты сам себе и подчиненный и начальник и бог в одном лице
Опыт очень небольшой. Я считаю что до позиции Senior Software Developer еще расти и расти (ну года 2 точно). Хотя, безусловно, бывают исключения (но судя по тому что ты подобный вопрос задал тут, на форуме, ты явно не это исключение).
А требования — зайди в раздел предложений о работе, там их гора (вариантов требований).
Здравствуйте, bkat, Вы писали:
_FR>>Так что если наберётся "несколько тыщ строк", которые кандидату не стыдно показать и, затем, обсудить гораздо важнее голословных (ничего не говорящих _о кандидате_ существенного) цифер с нулями.
B>Если ты претендуешь на тим лида, то показывать те "несколько тыщ строк", B>которыми ты гордишься, нету никакого смысла. B>Вернее это очень мало…
А показывать мильон смысл есть? То-то, и я как раз на этом заострил внимание.
B>…и это только один из многих аспектов, B>которые отличают хорошего программера от супер программера и тем более от того, B>кто претендует на руководство другими программерами.
А тут нельзя смешивать: программиста и управленца — а тим-лид это именно управленец, организатор, "рулевой".
В топике о тим-лидах речи не идёт: говорят об "уровнях программистов", а уровни программирования и управления лежат в совершенно разных плоскостях.
B>Ведущий программер должен показать, что он успешно работает именно в команде.
ОК, не тим-лид, а "ведущий". Это уже в кассу. Я не знаю критериев "успешной работы в команде" Вернее, каких-то особенных критериев для команды программистов. Если человек работал в команде начальника, его секретарши, её ухажёра и жены начальника впридачу с бухгалтером, охранником, уборщицей и сисадмином, то это опыт работе в команде.
Это опыт… [не знаю, как правильно сказать ] разделения, обмена мыслями с другими людьми с целью выслушать критику, переосознать или, наоборот, утревлиться в своих выводах. Умение вовремя (+-) сделать то, что обещал (написать класс или принести какую-нить справку в администрацию — не важно!).
B>Автор топика явно не работал в команде. Именно по этому он не может претендовать B>ни на сеньора, ни на лидера... B>Его 30000 строк кода скорее всего никто не видел. B>Врядли он с кем-то обсуждал те или иные архитектурные решения. B>Даже если он миллион строк наваяет, толку от этого мало, если он это делал в одиночку.
Бу… Весьма поспешно и бездоказательно. Основываясь на своих ощущениях или опыте я тоже могу написать чот-то для других странное. Но это не интересно. Я бы сказал, "Скорее всего, не может…". Тут же выглядит как приговор
B>Да и вообще.... Писать новый код — проще паренной репы B>Сложно его писать так, чтобы его было легко сопровождать. B>А оценить это можно только со временем.
А вот тут не соглашусь категорически :о)) Можно "оценить" скорее. Ведь правильный, "лекго сопровождаемый" код похож друг на друга (и узнаеть его не сложно по тем строчкам, которыми автор гордится), в то время как странных, проблемный код очень сильно разнится.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, MozgC, Вы писали:
MC>У меня есть один вопрос. Если я прихожу в фирму и вижу что мой уровень повыше уровня остальных программистов (несмотря на то что до этого я работал только один, либо вдвоем с напарником), разве я не могу быть senior software developer там?
То, что ты о себе думаешь — это только твоя самооценка.
Важно еще как тебя оценивают и примут ли тебя в качестве senior.
Ты уверен, что твоя самоценка совпадает с оценкой других тебя?
Тебя вообще кто-нибудь видел в работе?
В общем я не хочу повторяться.
Одно дело отвечать только за свой кусок (пусть и большой).
А другое дело — отвечать за еще больший кусок, который разрабатывает команда,
работу которой надо координировать и направлять.
Здравствуйте, kaa.python, Вы писали:
KP>Хотя, безусловно, бывают исключения (но судя по тому что ты подобный вопрос задал тут, на форуме, ты явно не это исключение).
А понял, это как раз ответ на мой вопрос, видимо принадлежность к этим уровням определяется знанием этих определений, а не опытом человека.
Здравствуйте, MozgC, Вы писали:
MC>Ясно... Ну а на позицию Senior S.D. нормально претендовать с 2.5 — 3 годами опыта или слишком нагло?
Это не нагло. Это смешно
2.5 года — Senior
Здравствуйте, SALar, Вы писали:
SAL>Lead Software Developer 15(редко 10)+ лет опыта. Знание многих архитектур. Участие в проектах 1 000 000 + строк кода. Опыт имплементации 1000+ юзкейсов. Свободное разворачивание обычного CRUD-а в альтернативные сценарии на пару десятков страниц, понимании преобразования разных видов требований друг в друга и в код и т.д. Умение составить модель предметной области сайта rsdn (часов четырех, я думаю, будет достаточно) и преобразовать ее в иерархию классов (еще 4-8 часов)
N>Здравствуйте, AntZ, Вы писали:
AZ>>Какая разница, как называется должность? AZ>>Senior — это как правило ничего не значая приставка.
N>Как правило, в нормальных конторах название должности соответствует должностным обязанностям. N>Как правило, в нормальных конторах приставка в названии должности определяет уровень ответственности и компетенции.
В номальных, это в каких? Официальный статус часто не имеет абсолютно ничего общего с реальным положением дел. Человек может быть рядовым программером и быть неофициальным лидером, наоборот, человек может быть каким угодно синьором, но все окружающие могут знать что он некомпетентный маразматик.
Вот пример. На старой работе я был Senior Software Engineer, на новой просто Software Engineer, при этом зарплата почти в полтора раза выше. Теперь объясните мне, это повышение или понижение? Да в мелкой компании я могу быть хоть Главным Ответственным Исполнительным Техническим Директором, а в крупной корпорации где сотни тысяч человек рядовым разработчиком. Которая из контор нормальная?
ps: впрочем, это всё теория. на практике, как я замечаю, понятие senior часто означает либо что фирма верит, что предалагет зарпалту выше среднего, либо она громкими титулами надеется скомпенсировать зарплату ниже среднего
Здравствуйте, bkat, Вы писали:
_FR>>Я не знаю критериев "успешной работы в команде" Вернее, каких-то особенных критериев для команды программистов. Если человек работал в команде начальника, его секретарши, её ухажёра и жены начальника впридачу с бухгалтером, охранником, уборщицей и сисадмином, то это опыт работе в команде.
B>Если программер работал в "команде начальника, его секретарши, её ухажёра и жены начальника впридачу с бухгалтером, охранником, уборщицей и сисадмином", то это его личный опыт и эта информация B>говорит кое о чем говорит. По крайней мере я смогу сделать выводы
Мне только кажется, или ты действительно стараешься сказать "всё ни о чём"? Зачем так обтекаемо и неясно? Можешь ли ты назвать несколько факторов (коих я не знаю ни одного) о специфике команды программистов?
B>Работа в нормальной команде — это то, без чего ты не станешь профи. B>Тут можно довольно много чего сказать.
К сожелению, это мне непонятно, ибо точного определения понятий "нормальная команда" и "профи" мне так же неизвестно
B>Одиночка, который варится в собственном соку, имеет куда меньше шансов развиться как профи.
Развиться в профессиональном плане можно именно одному: читая и делая потытки. В этом не поможет никто. Но далее требуется трезвый взгляд со стороны на результаты попыток. Иметь такой взгляд под боком — редкое везение и далеко не многие могут им похвастать. Обычно приходится (например, мне) сравнивать своё с тем, что делают другие и находить этих самых других в инете (то есть тут ) Так что развитие "в отрыве от команды" более чем возможно.
B>Понятно что есть исключения и есть такие команды, где фиг разовьешься, B>но в целом тенденция именно такая.
B>Сложные продукты создаются коллективами, а не одиночками. B>Реально развиться можно только решая сложные проблемы на нетривиальных проектах.
И опять не вижу связи между "проектом, на котором можно сильно укрепить скилы" — то, что споосбствует профессиональному росту, и "сложным и нетривиальным продуктом, решающим сложные проблемы" о котором говоришь ты. Связь может быть — я не спорю, но не согласен с тем, что она есть всегда и даже с тем, что она есть часто. Простой и небольшой проект намного лекче сделать "конфеткой", нежели "монстрообразный".
B>Да и вообще, "лид", "сеньор" и прочие приставки — это признаки некой иерархии, B>которая возможно только в команде
Нет, между тим-лидом и сеньёр-разработчиком есть разница. Кстати, да: как раз тим-лид\управленец и может похвастаться крупным проектом. То, что он какое-то время существовал — его заслуга. Заслуга программиста, его визитная карточка — это качественный код. И я не вижу разницы, является ли этот код частью "огроменного проектища" или же "небольшой поделочкой".
B>Если ты один, то ты сам себе и подчиненный и начальник и бог в одном лице
Между прочим: мне известны люди, заработавшие весьма и весьма добрую славу в профессиональных кругах на поприще фриланса. Они — несомненно одиночки и это не мешает им быть всесторонне развитыми профессионально
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Мне только кажется, или ты действительно стараешься сказать "всё ни о чём"? Зачем так обтекаемо и неясно? Можешь ли ты назвать несколько факторов (коих я не знаю ни одного) о специфике команды программистов?
Ну я даже не знаю, что тебе сказать.
Работа в коллективе принципиально отличается от работы одиночки.
Я не пишу про это протому что писать придется слишком много.
Зайди на форум "управление проектами" и ты увидешь типичные проблемы и особенности работы в команде.
Тут тебе будет и стандарты кодирования и особенности принятия коллективных решений и многое другое...
На этом форуме практически нету вопросов, которые имеют смысл, если ты один в поле.
Перед одиночкой, к примеру, практически не стоит задача выделения
задач таким образом, чтобы их можно было выполнять параллельно.
Ты один и ни от кого не зависишь. Работаешь так, как считаешь нужным.
Команда так работать не может.
Успешность работы команды тоже вполне реально оценить.
За команду говорят те проекты, которые она довела до конца.
Туда попадут и все отставания от сроков, и статистика по багам,
и скорость реакции на новые требования и прочее прочее прочее...
При большом желании это можно даже объективно померить и выдать цифирь
Не спрашивай меня про то, как ее вычислить
Я все равно тебя отправлю в форум "управление проектами"
"Сеньора" вполне можно оценить по тому, что он делал в командных проектах.
Моя же мысль в том, что человеку нет смысла мечтать о "сеньорстве",
если он не работал в команде. Не дорос он еще до этого...
Он может после первого же review уйдет обиженным
Здравствуйте, _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!
Help will always be given at Hogwarts to those who ask for it.
Senior. Не устроишь в каком-то месте на сеньора — тебе зачастую там же предложат джуниора, а там уже смотри, надо тебе оно или нет.
Как правило люди спокойно смотрят на завышенную самооценку в виде слова senior. Неспокойно смотрят на неадекватные опыту запросы по деньгам, но можно вообще пожелания по деньгам в резюмешке не писать.
Команды очень сильно отличаются по требованиям к сениору и джуниору, может оказаться так, что сениор из одной команды не устроит даже как джуниор в другой, а может быть и так, что джуниор из одной команды вдруг на собеседовании обнаружит, что его готовы взять в сениоры.
Годы опыта вообще играют второстепенную роль по сравнению с а) мозгами, т.е. голым интеллектом б) "точечным" опытом работы непосредственно с теми технологиями, что нужны в данной конторе. Еще иногда требования "годы опыта" означает "личностная зрелость и общий возраст", т.е. на деле там хотят отсеять не малоопытных, а истеричных сопляков.
Для чего угодно, связанного со словом Lead, нужно иметь реальный опыт _руководства людьми_. Нет опыта — нефиг писать Lead.
B>Похоже что ты думаешь, что ревью устраивают с целью доказать правоту. B>Это не так.
Как сказать.
Избежать скатывания института ревью в членомерство и доказательство людьми своей значимости друг другу крайне сложно, очень сложно, и есть все основания полагать, что процентах в 50 команд, где проводятся регулярные ревью, все это цветет пышным цветом.
Это становится уже не технической фичей, а социальной — "ты идешь не в ногу", "а кто ты такой вообще есть", "а давай-ка тебя дустом попробуем", "что позволено Васе-Юпитеру, то не позволено тебе-быку" и все прочие прелести того, что называется "коллектив".
Реально институт ревью нужен только а) для поиска ЯВНЫХ БАГОВ, а не "мне не нравится" б) в особо сложных по поиску багов местах, где поиск бага обычными средствами займет больше часов.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>...и зачастую прекрасный работник себе в карман мимо работодателя
Дело совести и не зависит от опыта работы над крупными проектами.
MSS>Конечно, такой человек может быть очень крут. Но тем острее стоит вопрос его лояльности и мотивированности. Не смотивировали его, не добились лояльности — см. предыдущий абзац
Вопрос всегда актуален, опять же безотносительно опыта работы в команде. Неужели нет
MSS>>>А вот то, что все это есть мелочевка — минус. MSS>Размеры проектов мелкие. Ну что такое 2000 строк, сами подумайте?
Этого может быть более чем достаточно что бы оценить уровень профессиональных знаний и решить, на что человек способен. Я о том и говорю: если есть возможность показать один или несколько небольших проектиков и не стесняться того, как они сделаны это одно, а когда "большущий проект, немножко того, немножко того" то смотреть не на что.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
УЁ>>А работа в проекте с миллионом строк говорит о том, что
_FR>Сама по себе "работа" ни говорит ни о чём. Говорят детали: то, как и с помощью чего человек выполнял поставленные перед ним задачи. Насколько хорошо (по его словам и по описанию). Какую из целей выполнения задачи (время, надёжность, полноту) он ставил на первое, второе место и почему? И эти характеристики не зависят от объёма работ.
Вот представь себе, берут на работу пилота пассажирского авиалайнера. Кандидат рассказывает как классно он в воздух самолеты поднимает, сажает коробочкой в любую погоду, и все такое. Но одна проблема, что летал он на высоте 3-4 метра от земли, а боинги летают на 10000 метрах.
Дело в том, что в проектах "миллионниках" происходит так свойственный этому миру количественно-качественный переход. И все проблемы, которые в маленьких проектах кажутся пустяковыми, могут оказаться принципиально невыполнимыми.
_FR>С другой стороны конечно, когда нужен разработчик a-la monkey-coder то "миллиощик" самое оно и спорить не буду
Не перестаю удивляться, как часто люди рассказывают про мифического кодера-обезьянку, который умеет писать 1000 строк в день, главное сказать ему что писать. Дайте мне в проект таких? Человек 10. А я буду говорить им что писать, и еще еду приносить, чтобы работали 24 часа в сутки.
УЁ>>человек сталкивался с определенным видом задач, и когда завтра в систему нужно будет добавить новую фичу, он не будет переписывать все с нуля, мотивируя это тем, что там "все так криво написано, что разобраться просто невозможно".
_FR>Если вышеприведённую цитату представить, как характеризующую человека-одиночку-фрилансера, то она по прежнему останется верна, не правда ли?
Нет, она не остается верна. Если одиночка-фрилансер работал в больших проектах, он знает реальную цену юношской идеи переписать все с нуля. В проекте в 30000 строк это реально, за неделю-две, переписать какой то кусок проекта с нуля, одному. Но в реальных проектах это невозможно. Потому что во-первых зависимости в системе на порядок выше (и не надо рассказывать сказки про слабо-связанные системы, они к сожалению только в книжках бывают), и ничего не поломать становится так же на порядок сложней, а во-вторых в таких проектах всегда есть куда более приоритетные задачи. Я уж молчу о проблемах рефакторинга и мерджинга, когда используется несколько бранчей для разработки. В таких случаях даже класс переименовать может стать особой проблемой, что уж там говорить о переписке с нуля.
_FR> Опиши тогда те самые "определенные задачи", которые _выгодно отличают в лучшую сторону_ работника с рпытом в большой команде на огромным проектом от совсем небольшой команды с десятком небольших проектов?
Здравствуйте, Maxim S. Shatskih, Вы писали:
УЁ>>Вклад в проект оценивается не количеством написанных строк. А работа в проекте с миллионом строк говорит о том, что человек сталкивался с определенным видом задач, и когда завтра в систему нужно будет добавить новую фичу, он не будет переписывать все с нуля, мотивируя это тем, что там "все так криво написано, что разобраться просто невозможно".
MSS>По-моему, такие вещи, как переписка с нуля, требуют санкции начальства всегда, даже во вполне себе правильно построенных командах без строевой муштры во фрунт и идолопоклонства процессам.
Какие могут быть санкции начальства, в проекте-карлике с одним разработчиком? Он просто никому не скажет о задуманном. И будет сидеть 2 недели без выходных по 12 часов, переписывать и переписывать, при этом удивляясь почему это заняло не 2 дня, как ему казалось в начале. Хорошо если еще вовремя одумается и сделает ролл-бэк.
Кстати часто в маленьких проектах, особенно с 1 разработчиком, системы контроля версий вообще не используются, и хорошо если остался бэк-ап.
И придя в большой проект, такой разработчик может никому ничего не сказав начать что то переделывать, как всегда пообещав (в том числе самому себе) что все закончит через 2 дня.
Здравствуйте, MozgC, Вы писали:
MC>Добрый день,
MC>Если у меня 2.5 года опыта работы с .NET, PHP, БД, то на какую позицию мне лучше и реальнее претендовать? Senior Software Developer или Lead Software Developer?
Software Developer, без приставок.
Как будет смотреться в резюме если после 2х лет опыта позиция — просто Software Developer?
нормально будет смотреться.
в некоторых случаях можно и старшим программистом стать за два года, но это скорее исключение. А так — 4-5 лет до "сеньйора".
Здравствуйте, MozgC, Вы писали:
MC>Ясно... Ну а на позицию Senior S.D. нормально претендовать с 2.5 — 3 годами опыта или слишком нагло?
Претендовать ты можешь на что угодно.
Главное чтобы твое претензии подтверждались реальным опытом.
2.5 — 3 года все же маловато.
Но пока я не прочту твоего резюме и реально не пообщаюсь с тобой,
ничего более я сказать не смогу.
Ты то как себя лично оцениваешь?
Почему ты хочешь быть Senior'ом?
Потому что реально ты крут и это подтверждается реальными проектами?
Или ты хочешь пойти на Senior'а потому что веришь в то, что уже созрел
и им вообще больше платят?
Здравствуйте, bkat, Вы писали:
B>Почему ты хочешь быть Senior'ом? B>Потому что реально ты крут и это подтверждается реальными проектами? B>Или ты хочешь пойти на Senior'а потому что веришь в то, что уже созрел B>и им вообще больше платят?
Наверное потому, что сейчас возвращаюсь из ОАЭ домой и компания ищет замену. Я лично просмотрел уже штук 50 резюме, пообщался с 5 претендентами, и просто банально сравниваниваю и вижу разницу между тем что и как делали они и что сделал я за свой пусть небольшой опыт. Начинаю еще анализировать все что я делал, и понимаю что кажется я перерос уровень набрасывания кнопочек на формочки и создания простейших вещей и написания кода в стиле "лишь бы работало". Наверное так.
MC>Наверное потому, что сейчас возвращаюсь из ОАЭ домой и компания ищет замену. Я лично просмотрел уже штук 50 резюме, пообщался с 5 претендентами,
если возвращаешься в РФ, то пиши лучше Software developer, так как по деньгам всё равно тут решается всё в процессах собеседования, а найти место тут тем проще чем ниже звание указываешь.
MC>Наверное потому, что сейчас возвращаюсь из ОАЭ домой и компания ищет замену. Я лично просмотрел уже штук 50 резюме, пообщался с 5 претендентами, и просто банально сравниваниваю и вижу разницу между тем что и как делали они и что
по тем, кто к вам приходит, судить о своём уровне тебе нельзя. к вам приходят худшие из худших, поскольку на пути нет никаких барьеров
MC>сделал я за свой пусть небольшой опыт. Начинаю еще анализировать все что я делал, и понимаю что кажется я перерос уровень набрасывания кнопочек на формочки и создания простейших вещей и написания кода в стиле "лишь бы работало". Наверное так.
а юниор, по твоему — тот, кто просто бесцельно водит мышкой по столу?
Здравствуйте, MozgC, Вы писали:
MC>Наверное потому, что сейчас возвращаюсь из ОАЭ домой и компания ищет замену.
Ты тот, которому в ОАЭ копейки платили?
Если да, то на сеньера ты пока не тянешь.
Ты еще толком не работал. Ты работал в семейной фирме
и выполнял кучу обязанностей, многие из которых вообще к программированию никакого отношения не имеют.
Но у тебя скорей всего нету реального опыта на серьезных проектах,
которые делаются в команде. С реальными профи ты еще явно не работал.
И не надо смотреть на тех, кто возможно придут тебе на замену.
Профи с опытом в эту фирму точно не пойдут.
На самом деле в проекте 30000 строк написанных именно вручную, проект развивался постепенно в течение 2.5 лет, а дополнительную кучу обязанностей я начал выполнять только в последние 5 месяцев. Так что опыт на серьезном проекте есть, и я считаю что этот опыт лучше, чем выполнить 10 простых проектов, так как при развитии одного проекта с каждым разом выполняются все более сложные вещи, выполняя же постоянно много простых проектов можно застопориться на одном уровне. Это мое мнение.
Здравствуйте, MozgC, Вы писали:
MC>На самом деле в проекте 30000 строк написанных именно вручную, проект развивался постепенно в течение 2.5 лет, а дополнительную кучу обязанностей я начал выполнять только в последние 5 месяцев. Так что опыт на серьезном проекте есть, и я считаю что этот опыт лучше, чем выполнить 10 простых проектов, так как при развитии одного проекта с каждым разом выполняются все более сложные вещи, выполняя же постоянно много простых проектов можно застопориться на одном уровне. Это мое мнение.
Ты работал один? Если да, то этот опыт никак не тянет на опыт сеньера.
Я уж не буду тебя спрашивать про спецификации, дизайны, тестирования и прочие вещи.
Только не говори, что ты сам все специфицировал, дизайнил, кодил и тестровал.
Это просто не серьзно...
ggg>Извините, но некрасиво выглядит, когда рядом со ссылкой на свое краткое резюме Вы даете такие советы.
красиво. если уж начали обсуждать мое резюме, то могу объяснить почему красиво.
ggg>Согласно Вашей записи в moikrug у Вас было три года опыта работы программистом (из них 2.5 совпали с Вашим обучением в вузе, т.е. чистой работы — всего полгода),
то что совмещалось с учебой было fulltime работой (сложилось так) и никаких скидок на то что я студент не было. работа была не в одиночестве а в довольно большой и профессиональной команде, т.е. было у кого учиться и вопросах связанных с разработкой и в вопросах коммуникаций (что крайне важно для ведущего программиста). В третьей компании ведущим стал не сразу, просто в резюме стоит последняя позиция (ваш отзыв довольно интересный, я поправлю информацию).
AZ>Какая разница, как называется должность? AZ>Senior — это как правило ничего не значая приставка. Это как в госконторах — надо поднять ЗП — начинают оформлять "категории" и "разряды". У меня в
ну, она в общем то значащая, т.к. это категория для отдела кадров, от которой рассчитывается вилка ЗП.
но все это в пределах отдельно взятой компании.
не исключено что джуниор в "НаноОйлТрансТелеком" получает больше чем синьер в "НИИКБ Им.Шушпанского"
Здравствуйте, MozgC, Вы писали:
MC>На самом деле в проекте 30000 строк написанных именно вручную, проект развивался постепенно в течение 2.5 лет, а дополнительную кучу обязанностей я начал выполнять только в последние 5 месяцев. Так что опыт на серьезном проекте есть, и я считаю что этот опыт лучше, чем выполнить 10 простых проектов, так как при развитии одного проекта с каждым разом выполняются все более сложные вещи, выполняя же постоянно много простых проектов можно застопориться на одном уровне. Это мое мнение.
30,000 строк это очень мало. Вот когда в проекте кол-во строк зайдет за миллиончик — тогда можно надуть щеки и сказать что проект серьезный.
AZ>Какая разница, как называется должность? AZ>Senior — это как правило ничего не значая приставка.
Как правило, в нормальных конторах название должности соответствует должностным обязанностям.
Как правило, в нормальных конторах приставка в названии должности определяет уровень ответственности и компетенции.
Здравствуйте, MozgC, Вы писали:
MC>Добрый день, MC> Хотел спросить у знающих людей чтобы мне в кратце объяснили про значения уровней программистов, т.е. Software Developer, Senior Software Developer, Lead Software Developer, Team Leader и т.д.
SAL>Software Developer 4-10 (редко 2-5) лет опыта коммерческой разработки. Человек редко допускающий очевидные ляпы. SAL>Senior Software Developer 10+ лет опыта SAL>Lead Software Developer 15(редко 10)+ лет опыта. Знание многих архитектур. Участие в проектах 1 000 000 + строк кода. Опыт имплементации 1000+ юзкейсов. Свободное разворачивание обычного CRUD-а в альтернативные сценарии на пару десятков страниц, понимании преобразования разных видов требований друг в друга и в код и т.д. Умение составить модель предметной области сайта rsdn (часов четырех, я думаю, будет достаточно) и преобразовать ее в иерархию классов (еще 4-8 часов), после чего реализовать все это на функциональном псевдоязыке . Знание ограничений автоикремента и гуида на уровне мозжечка. Знание и опыт участия в разработке нескольких стандартов кодирования. Да, и естественно, прочтение не менее полуметра книг по разработке + нескольких тысяч статей + десяток собственных статей ОТРЕЦЕНЗИРОВАННЫХ другими специалистами. SAL>Team Leader 15(редко 10)+ лет опыта кроме технических качеств имеет опыт в управлении и серьезную подготовку в преподавании (от 1000 часов). Знакомство с несколькими методологиями разработки. Способность самостоятельно составить описание технических процессов и рассказать какие из них лучше подходят для конкретного проекта. Опыт в управлении и контроле качества выпускаемого продукта и процессов. Это другая ветвь развития.
SAL>С другой стороны, я не программист, так что может и не прав.
Если бы так было, как ты говоришь, то все мелкие начальники были бы 40-50 летнего возраста. но что-то таких сложно найти в софтверных конторах. А все перечисленные тобой категории , как правило, моложе 30-ти. После все умные люди уже забывают автоинкременты и гуиды, садятся в ворд и аутлук и становятся пиЭмами. Так тчо спускаемся с неба на землю.
_FR>Так что если наберётся "несколько тыщ строк", которые кандидату не стыдно показать и, затем, обсудить гораздо важнее голословных (ничего не говорящих _о кандидате_ существенного) цифер с нулями.
Если ты претендуешь на тим лида, то показывать те "несколько тыщ строк",
которыми ты гордишься, нету никакого смысла.
Вернее это очень мало и это только один из многих аспектов,
которые отличают хорошего программера от супер программера и тем более от того,
кто претендует на руководство другими программерами.
Ведущий программер должен показать, что он успешно работает именно в команде.
Автор топика явно не работал в команде. Именно по этому он не может претендовать
ни на сеньора, ни на лидера... Его 30000 строк кода скорее всего никто не видел.
Врядли он с кем-то обсуждал те или иные архитектурные решения.
Даже если он миллион строк наваяет, толку от этого мало, если он это делал в одиночку.
Да и вообще.... Писать новый код — проще паренной репы
Сложно его писать так, чтобы его было легко сопровождать.
А оценить это можно только со временем.
[]
M>Не меньше, чем Lead Architect требуй M>А если сурьезно — не видел людей с двухлетним опытом, которым не страшно было бы отдать что-то больщее, чем рисование формочек. А до лидов с таким опытом — как до Пекина р....
Здравствуйте, AntZ, Вы писали:
AZ>Вот пример. На старой работе я был Senior Software Engineer, на новой просто Software Engineer, при этом зарплата почти в полтора раза выше. Теперь объясните мне, это повышение или понижение? Да в мелкой компании я могу быть хоть Главным Ответственным Исполнительным Техническим Директором, а в крупной корпорации где сотни тысяч человек рядовым разработчиком. Которая из контор нормальная?
Вы хотите сказать, что на новой работе выполняете те же обязанности, что и на старой, но должность у вас "ниже"?
Здравствуйте, bkat, Вы писали:
_FR>>Мне только кажется, или ты действительно стараешься сказать "всё ни о чём"? Зачем так обтекаемо и неясно? Можешь ли ты назвать несколько факторов (коих я не знаю ни одного) о специфике команды программистов?
B>Ну я даже не знаю, что тебе сказать. B>Работа в коллективе принципиально отличается от работы одиночки. B>Я не пишу про это протому что писать придется слишком много. B>Зайди на форум "управление проектами" и ты увидешь типичные проблемы и особенности работы в команде.
Не спорю, даже поддерживаю! Но я о "разнице работы в коллективе" и "разнице работы в коллективе программистов"
B>Тут тебе будет и стандарты кодирования…
Они и одному необходимы, если он понимает, чо делает.
B>…и особенности принятия коллективных решений и многое другое...
В интернет-обсуждениях и бытовых спорах треннируются те же навыки Или взять. например. время обучения в школе и институте. Чем не навыки общения, доказывания точки зрения и принятия компромисса?
B>На этом форуме практически нету вопросов, которые имеют смысл, если ты один в поле.
Вот уж нет. нету вопросов, которые не имеют смысла, если ты "пишешь в стол" для чёрте-кого и лишь бы поскорей об этом забыть. То есь если сам Если ты один, то что мешает писать "на века", что бы "…песня!!!"?
B>Перед одиночкой, к примеру, практически не стоит задача выделения B>задач таким образом, чтобы их можно было выполнять параллельно.
Как же так? Декомпозиция, например, уже не всчёт? Опять же умение "распараллеливать" можно приобрести и в реале.
B>Ты один и ни от кого не зависишь. Работаешь так, как считаешь нужным. B>Команда так работать не может.
Хе-хе! Это можно читать обоюдоострым утрерждением, смысл которого зависит от уровня "одиночки". Если он достаточно большой, то никакой команде за ним, естественно (в смысле уровня и класса), не угнаться и "так она работать не сможет".
B>Успешность работы команды тоже вполне реально оценить. B>За команду говорят те проекты, которые она довела до конца.
Что значит "до конца"? я вот не помню ни одного проекта, который довёл до "счастливого" конца (заглохшие и сгинувшие ведь нас не интересуют?)
B>Он может после первого же review уйдет обиженным
Возможно! Но не это показатель класса. показатель класса: если он вернётся и либо докажет тебе, что review было проведено нерпавильно и претензии оказались необоснованными или же с исправлениями — то это Уважуха вот если не вернётся — то
ЗЫ: По ошущенным здесь цитатам у меня сложилось вчепятление, что у тебя какое-то фанатичное, "шапкозакидательское", предвзятое отношение к обсуждаемому вопросу. "команда", "колелктив", "управление проектами", … — "общие места", как сказала бы моя учительница по литературе
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, MozgC, Вы писали:
MC>Наверное потому, что сейчас возвращаюсь из ОАЭ домой и компания ищет замену. Я лично просмотрел уже штук 50 резюме, пообщался с 5 претендентами
Это типа была демонстрация разницы работы в команде и в одиночку.
Сейчас мы с тобой дискутируем как 2 независимых друг от друга человека.
Ты можешь поставить смайлик, сказать, что bkat — мутный тип, который сам
не знает о чем говорит, меряется пиписьками и на этом все и закончится.
Если бы мы работали в одной команде, то тебе пришлось бы каждый рабочий день видеть мою рожу
В другой команде тебе пришлось бы терпеть других странных типов.
Это одно из принципиальных различий работы в команде от работы в одиночку.
Здравствуйте, bkat, Вы писали:
B>Это типа была демонстрация разницы работы в команде и в одиночку. B>Сейчас мы с тобой дискутируем как 2 независимых друг от друга человека. B>Ты можешь поставить смайлик, сказать, что bkat — мутный тип, который сам B>не знает о чем говорит, меряется пиписьками и на этом все и закончится.
А в реале, работая в одном кабинете, не смогу? Кто-то обидится и сразу пойдёт увольняться или требовтаь увольнения зачинщика? Вот это как раз не подход Именно в обычной жизни, а ещё из классической (или религиозной, если интересно) литературы человек учится понимать или не понимать но всё равно прощать и спокойно, "нормально" относиться к тем, кого не понимает.
B>Если бы мы работали в одной команде, то тебе пришлось бы каждый рабочий день видеть мою рожу
Не прибедняйся, моя ещё страшнее
B>В другой команде тебе пришлось бы терпеть других странных типов. B>Это одно из принципиальных различий работы в команде от работы в одиночку.
"странных типов" приходится терпеть повсюду
Чесслово, я не увидел ни одного различия между обычной командой и командой программистов (с твоих слов)
Help will always be given at Hogwarts to those who ask for it.
У меня есть один вопрос. Если я прихожу в фирму и вижу что мой уровень повыше уровня остальных программистов (несмотря на то что до этого я работал только один, либо вдвоем с напарником), разве я не могу быть senior software developer там? Или для этого, как сообщают в этой дискуссии, обязательно надо будет сначало пару лет работать с ними якобы на равных?
Здравствуйте, MozgC, Вы писали:
MC>У меня есть один вопрос. Если я прихожу в фирму и вижу что мой уровень повыше уровня остальных программистов (несмотря на то что до этого я работал только один, либо вдвоем с напарником), разве я не могу быть senior software developer там? Или для этого, как сообщают в этой дискуссии, обязательно надо будет сначало пару лет работать с ними якобы на равных?
Не бери в голову названия должностей и отталкивайся от этого правила. Пускай другие называют себя как им угодно — это их дело и это _не важно_.
Я вот недавно стал в "менеджером по разработке програмного обеспечения" Ну как к этому можно относиться серьёзно Только не обращая внимание
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, MozgC, Вы писали:
MC>У меня есть один вопрос. Если я прихожу в фирму и вижу что мой уровень повыше уровня остальных программистов (несмотря на то что до этого я работал только один, либо вдвоем с напарником), разве я не могу быть senior software developer там? Или для этого, как сообщают в этой дискуссии, обязательно надо будет сначало пару лет работать с ними якобы на равных?
ну, если ты там самый опытный программист — то тебе придётся разрабатывать архитектуру системы, ставить им задачи и заниматься прочим что я уже перечислял. ты с этим справишься?
Здравствуйте, _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", а возможно вам светит только позиция программист-стажер. Учет в сутках никого не волнует.
_FR>Несколько десятков коммерчески успешных проектиков по несколько тыщ строк, которые поддерживаются (в live) уже несколько лет — более весомый повод "надуть щёки"
Коммерческая успешность проектов вообще не есть плюс девелоперу, который просится на работу на девелоперскую позицию.
B>Перед одиночкой, к примеру, практически не стоит задача выделения B>задач таким образом, чтобы их можно было выполнять параллельно.
Это не девелоперская задача, а управленческая. Скорее всего ПиЭмская, как минимум — тимлидская. Если человек не просится куда-то с приставкой lead — то это не обязательно.
B>"Сеньора" вполне можно оценить по тому, что он делал в командных проектах. B>Моя же мысль в том, что человеку нет смысла мечтать о "сеньорстве", B>если он не работал в команде. Не дорос он еще до этого... B>Он может после первого же review уйдет обиженным
Пожалуй, сейчас начну я с нуля отдельную тему, "Пешка из большой команды vs. одиночка", и вас в нее приглашу. Вопрос ИМХО того стоит.
SAL>Вы закончили стажировку и перешли в категорию "молодой специалист". В IT секторе РФ
В ИТ секторе РФ человек с 2 годами опыта работы — состоявшийся спец, а не "молодой". Во многих командах вполне устроят только такие люди.
SAL>этому уровню может соответствовать любое звание от "разработчика" до "старшего технического директора". В целом, чем хуже контора, тем выше звания.
Если в конторе вместе со званием выше и ЗП — то она хуже?
SAL>Software Developer 4-10 (редко 2-5) лет опыта коммерческой разработки. Человек редко допускающий очевидные ляпы.
1 года достаточно, при наличии мозгов — полугода.
SAL>Senior Software Developer 10+ лет опыта SAL>Lead Software Developer 15(редко 10)+ лет опыта. Знание многих архитектур. Участие в проектах 1 000 000 + строк кода. Опыт имплементации 1000+ юзкейсов. Свободное разворачивание обычного CRUD-а в альтернативные сценарии на пару десятков страниц, понимании преобразования разных видов требований друг в друга и в код и т.д. Умение составить модель предметной области сайта rsdn (часов четырех, я думаю, будет достаточно) и преобразовать ее в иерархию классов (еще 4-8 часов), после чего реализовать все это на функциональном псевдоязыке . Знание ограничений автоикремента и гуида на уровне мозжечка. Знание и опыт участия в разработке нескольких стандартов кодирования. Да, и естественно, прочтение не менее полуметра книг по разработке + нескольких тысяч статей + десяток собственных статей ОТРЕЦЕНЗИРОВАННЫХ другими специалистами.
В колоссальном количестве (большинстве?) контор в ИТ секторе РФ не нужно ни одного человека с таким набором атрибутов.
В не менее колоссальном количестве контор нужен 1 такой человек в ранге техдиректора (точное название может быть иным, но это нечто вроде Главного Мозга всей конторы. Все остальные люди могут быть слабее).
Понимание преобразования требований вообще девелоперу не обязательно, это работа аналитика или ПиЭма.
SAL>Team Leader 15(редко 10)+ лет опыта кроме технических качеств имеет опыт в управлении и серьезную подготовку в преподавании (от 1000 часов).
Вы всерьез считаете, что все тимлиды в ИТ секторе РФ имеют 1000 часов опыта в преподавании?
Подавляющее большинство тимлидов в РФ — это ребята с 2мя годами опыта работы, командующие ребятами с 1 годом опыта. Обычно выше среднего интеллект (хотя совсем не обязательно звездный) и много выше среднего амбиции.
SAL>Знакомство с несколькими методологиями разработки.
Требование к директору по прожект-менеджменту, даже не к ПиЭму.
SAL>С другой стороны, я не программист, так что может и не прав.
Вы неправы в том, что в ИТ секторе РФ как правило работают _на ведущих и руководящих позициях_ люди с намного меньшими атрибутами
T>Потому что ай-ти отрасль росла как на дрожжах — достаточного количества опытных людей банально не было.
В 90ые годы мало ценился советский опыт работы. Если, например, человек не знает DCOMа, который де-факто стандарт в разработках компании, и предлагает разработать свои протоколы презентационного уровня — то на кой черт такой нужен, лучше человек с 2 годами опыта вместо 10, но DCOM знающий.
Плохое знание платформы — это гигантский минус.
Советский руководящий опыт (не девелоперский) тоже has issues, чудовищная бюрократизация и низкая эффективность советских структур вряд ли тайна.
Это как в Перекрестки одно время НЕ брали людей с опытом в советской торговле )
Что же касается 00 годов, то тут речь о банальной нехватке людей, рынок труда перегрет.
Все это приводит к тому, что реально тимлидами работают люди с 2 годами опыта после вуза. Причем еще и _справляются_ — что греха таить, задачи-то у 90% команд несложные (если самим не искать приключений на анус и не делать ненужных овердизайновых наворотов).
FR>И даже на своих (шараварных) проектах часто приходится делать не так как FR>считаешь нужным, а быстрее и лишь бы пока работало
Конкретно шароварь имеет свои минусы. Слишком большая ориентация не на код, реализующий фичи, а на мимолетную денежку.
Конечно, любой бизнес есть денежка. Но денежка шароварщика получается им одним образом, а денежка компании человек в 50 — другим. Денежка корпорации в 50.000 человек — третьим.
Потому коммерческий аспект шаровари зачастую просто не применим в структурах побольше, там лучше, чем человек слабее коммерчески, зато сильнее технически (коммерсантов там на других собеседованиях на работу берут, разделение труда).
Здравствуйте, bkat, Вы писали:
MC>>Ясно... Ну а на позицию Senior S.D. нормально претендовать с 2.5 — 3 годами опыта или слишком нагло? B>Претендовать ты можешь на что угодно. B>Главное чтобы твое претензии подтверждались реальным опытом. B>2.5 — 3 года все же маловато.
Эпиграф: 4 слепых слона-мудреца решили познать, что такое человек. Один потрогал его ногой и сказал что человек это что-то плоское и мокрое. 3 других потрогали и согласились с ним.
Господа — про что вы спорите-то? Вы не определили чем отличается просто Software Developer, от Senior Software Developer и сейчас на основе одной вырванной из контекста цифры "опыта в годах" пытаетесь решить, что лучше написать.
Понятно, что в одних компаниях Senior-ы делат то, что в других просто девелоперы, а в третьих то-же что и project manager-ы. А 3 года опыта могут быть как ляпанием формочек так и чем нибудь серьезным.
Спасает только то, что в не зависимости от того, что написать в желаемую позицию работадатели этим не заморочатся, т.к. все равно это мало, что означает. Единственную полезную информацию которую это дает — человека мотивирует название его должности(часть работадателей этим попробует заплатить вместо денег, а остальные забьют).
P.S. На практике видел вот какие распределения названий должностей:
1) Кто как хочет тот так и называйтесь.
2) Senior-ство определяется цветом штанов — делим программистов на глаз на 2 половины, одну что покруче называем senior-ы. (Т.к. на входе это не всегда можно определить есть некоторые исключения)
3) Все девелоперы Senior, других не бывает.
4) Сам не видел, видимо в крупных компаниях есть: есть система грейдов, от них что-то зависит, в том числе название должности и зарплаты.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Гоги, Вы писали:
Г>Смотря что вы сделали за эти 2.5 года Возможно, что вы можете претендовать на "Lead Software Developer", а возможно вам светит только позиция программист-стажер. Учет в сутках никого не волнует.
Есть такие конторы, в народе известные как "посольства". Вот там меня просили указать свой опыт чуть ли не с точностью до дня
MSS>Годы опыта вообще играют второстепенную роль по сравнению с а) мозгами, т.е. голым интеллектом б) "точечным" опытом работы непосредственно с теми технологиями, что нужны в данной конторе. Еще иногда требования "годы опыта" означает "личностная зрелость и общий возраст", т.е. на деле там хотят отсеять не малоопытных, а истеричных сопляков.
Это да, но не всегда спасает — видели мы "сеньеров" с 6-и летним опытом, которые вообще языка не знают, не говоря уже о тонкостях технологий... Только личная беседа ставит все точки над i.
Здравствуйте, koandrew, Вы писали:
Г>>Смотря что вы сделали за эти 2.5 года Возможно, что вы можете претендовать на "Lead Software Developer", а возможно вам светит только позиция программист-стажер. Учет в сутках никого не волнует. K>Есть такие конторы, в народе известные как "посольства". Вот там меня просили указать свой опыт чуть ли не с точностью до дня
Например, это могла быть проверка памяти, а не знаний
UN>Это да, но не всегда спасает — видели мы "сеньеров" с 6-и летним опытом, которые вообще языка не знают, не говоря уже о тонкостях технологий... Только личная беседа ставит все точки над i.
+1
Даже скиллзы не всегда важны. Например, не важны скиллзы, которые не применяются в актуальном процессе разработки в твоей команде и их применение не планируется.
А уж годы опыта... ну кто круче — 10 лет опыта и посредственность и 2 года опыта и почти гений?
Здравствуйте, Maxim S. Shatskih, Вы писали:
_FR>>Несколько десятков коммерчески успешных проектиков по несколько тыщ строк, которые поддерживаются (в live) уже несколько лет — более весомый повод "надуть щёки"
MSS>Коммерческая успешность проектов вообще не есть плюс девелоперу, который просится на работу на девелоперскую позицию.
То был разговор об одиночках и командах. Я говорил про шароварные проекты. Когда приходит устраиваться человек и говорит, что до этого работал один (то есть не в команде) и имеет несколько достаточно успешных проектов, которые уже как несколько лет как поддерживаются (им) и развиваются и даже позволяют ему неплохо существовать, то это, ИМХО, весьма положительно говорит о способностях этого человека как работника. Ибо "за просто так" успех приходит редко, обычно его надо добиваьтся. человек же, умеющий добиваться необходимого и есть прекрасный работник.
А вот когда человек "работал в большой команде, которая писала проект на N мильонов строк кода…" то оказывается гораздо сложнее оценить вклад (и эффективность) человека и его работоспособности.
MSS>А вот то, что все это есть мелочевка — минус.
Не понял этого
Help will always be given at Hogwarts to those who ask for it.
_FR>То был разговор об одиночках и командах. Я говорил про шароварные проекты. Когда приходит устраиваться человек и говорит, что до этого работал один (то есть не в команде) и имеет несколько достаточно успешных проектов, которые уже как несколько лет как поддерживаются (им) и развиваются и даже позволяют ему неплохо существовать, то это, ИМХО, весьма положительно говорит о способностях этого человека как работника. Ибо "за просто так" успех приходит редко, обычно его надо добиваьтся. человек же, умеющий добиваться необходимого и есть прекрасный работник.
...и зачастую прекрасный работник себе в карман мимо работодателя
Конечно, такой человек может быть очень крут. Но тем острее стоит вопрос его лояльности и мотивированности. Не смотивировали его, не добились лояльности — см. предыдущий абзац
MSS>>А вот то, что все это есть мелочевка — минус.
_FR>Не понял этого
Размеры проектов мелкие. Ну что такое 2000 строк, сами подумайте?
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>А уж годы опыта... ну кто круче — 10 лет опыта и посредственность и 2 года опыта и почти гений?
Сравнивать надо соизмеримое, сами же сказали.
Кто круче: "10 лет опыта и почти гений" против "2 года опыта и почти гений"?
Здравствуйте, _FRED_, Вы писали:
_FR>А вот когда человек "работал в большой команде, которая писала проект на N мильонов строк кода…" то оказывается гораздо сложнее оценить вклад (и эффективность) человека и его работоспособности.
Вклад в проект оценивается не количеством написанных строк. А работа в проекте с миллионом строк говорит о том, что человек сталкивался с определенным видом задач, и когда завтра в систему нужно будет добавить новую фичу, он не будет переписывать все с нуля, мотивируя это тем, что там "все так криво написано, что разобраться просто невозможно".
УЁ>Вклад в проект оценивается не количеством написанных строк. А работа в проекте с миллионом строк говорит о том, что человек сталкивался с определенным видом задач, и когда завтра в систему нужно будет добавить новую фичу, он не будет переписывать все с нуля, мотивируя это тем, что там "все так криво написано, что разобраться просто невозможно".
По-моему, такие вещи, как переписка с нуля, требуют санкции начальства всегда, даже во вполне себе правильно построенных командах без строевой муштры во фрунт и идолопоклонства процессам.
Здравствуйте, Ушастый Ёж, Вы писали:
_FR>>А вот когда человек "работал в большой команде, которая писала проект на N мильонов строк кода…" то оказывается гораздо сложнее оценить вклад (и эффективность) человека и его работоспособности.
УЁ>Вклад в проект оценивается не количеством написанных строк.
Верно, их качеством исключительно.
УЁ>А работа в проекте с миллионом строк говорит о том, что
Сама по себе "работа" ни говорит ни о чём. Говорят детали: то, как и с помощью чего человек выполнял поставленные перед ним задачи. Насколько хорошо (по его словам и по описанию). Какую из целей выполнения задачи (время, надёжность, полноту) он ставил на первое, второе место и почему? И эти характеристики не зависят от объёма работ.
С другой стороны конечно, когда нужен разработчик a-la monkey-coder то "миллиощик" самое оно и спорить не буду
УЁ>человек сталкивался с определенным видом задач, и когда завтра в систему нужно будет добавить новую фичу, он не будет переписывать все с нуля, мотивируя это тем, что там "все так криво написано, что разобраться просто невозможно".
Если вышеприведённую цитату представить, как характеризующую человека-одиночку-фрилансера, то она по прежнему останется верна, не правда ли? Опиши тогда те самые "определенные задачи", которые _выгодно отличают в лучшую сторону_ работника с рпытом в большой команде на огромным проектом от совсем небольшой команды с десятком небольших проектов?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, bkat, Вы писали:
B>Да и вообще.... Писать новый код — проще паренной репы B>Сложно его писать так, чтобы его было легко сопровождать.
+1000 (много-много нулей ). Выучила уже не одного новичка — многие поначалу даже не понимают, зачем некоторые вещи писать именно так, чтобы его было потом легко сопровождать, а не как они привыкли.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, mik1, Вы писали:
КЛ>[]
M>>Не меньше, чем Lead Architect требуй M>>А если сурьезно — не видел людей с двухлетним опытом, которым не страшно было бы отдать что-то больщее, чем рисование формочек. А до лидов с таким опытом — как до Пекина р....
КЛ>не везет тебе с командой
Здравствуйте, Ушастый Ёж, Вы писали:
УЁ>Здравствуйте, MozgC, Вы писали:
MC>>На самом деле в проекте 30000 строк написанных именно вручную, проект развивался постепенно в течение 2.5 лет, а дополнительную кучу обязанностей я начал выполнять только в последние 5 месяцев. Так что опыт на серьезном проекте есть, и я считаю что этот опыт лучше, чем выполнить 10 простых проектов, так как при развитии одного проекта с каждым разом выполняются все более сложные вещи, выполняя же постоянно много простых проектов можно застопориться на одном уровне. Это мое мнение.
УЁ>30,000 строк это очень мало. Вот когда в проекте кол-во строк зайдет за миллиончик — тогда можно надуть щеки и сказать что проект серьезный.
Может проэкт с 1кк строк пора рефакторить или уже позно?
Здравствуйте, Ушастый Ёж, Вы писали:
УЁ>Дело в том, что в проектах "миллионниках" происходит так свойственный этому миру количественно-качественный переход. И все проблемы, которые в маленьких проектах кажутся пустяковыми, могут оказаться принципиально невыполнимыми.
Из всего сказанного напрашивается вывод о том, что определяющими качествами разработчика являются умение мёрджить; не переписывать, а поддерживать всё на имеющемся средненьком, или даже ниже, уровне; и, конечно же, работа в условиях сильносвязанных систем
Но я просто не могу в это поверить: за, примерно, три десятка пережитых собеседований, никто ни одного подобного вопроса не спросил Наоборот даже: в небольших компаниях (где < 30 разработчиков) разговор про систему контроля версий и технологии и тонкости работы с ними (а так же про организацию работы с базой данных и уместность использования ассертов в тех или иных случаях) был гораздо душевнее, чем в больших компаниях, где упор почему-то, в полный противовес вашим словам, делался на паттерны, тонкости синтаксиса и знания библиотек. Почему так? Или вот: все, у кого уже есть большая система рассказывают, что им как-раз таки нужны люди для серьёзно переделки больших её, системы, кусков, потому что заказчики уже есть, торопиться, как при стартапе, не надо и самое время подумать об удобстве будущих нововведений
Исходя из вышесказанного, никак не могу согласиться с тем, что решающим фактором (да вообще сколь угодно значимым) может быть опыт работы в больших проектах. Хотя бы потому, что привить его — дело нескольких месяцев, а вот выучиться на толкового девелопера — много сложнее.
Да неужели и вы в своей компании или в других, на собеседованиях говорите больше про тонны кода, а не про небольшие конкретные кусочки, выясняя, что в них хорошего, а что — не очень?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Ушастый Ёж, Вы писали:
УЁ>И придя в большой проект, такой разработчик может никому ничего не сказав начать что то переделывать, как всегда пообещав (в том числе самому себе) что все закончит через 2 дня.
Это "на раз" решается вменяемым менеджментом (без которого в большом проекте никак, верно?), так что сильно удивлюсь, если подобные проблемы действительно причиняют неудобство.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, McSeem2, Вы писали:
_O_>>Просто вы с большими проектами не сталкивались. Когда работаешь с проектом где несколько миллионов строк кода, то 30 000 — это совсем не много. MS>Работа с миллионами строк называется по-другому — обслуживание.
Это если их нужно обслуживать. Если же надо развивать проект, добавлять туда новые вещи, улучшать старые — то это уже совсем отдельная песня. Количество переход в качество
Можно в пример тот же Линукс взять — код в большинстве файлов абсолютно тупой, но никто же не утверждает, что любой средний программист справится с поддержанием такой системы.
MS>С другой стороны, я, например, где-то полгода работал над алгоритмом, который получился всего-то в 2000 строк. MS>Но должен признать, что по неким вторичным половым признакам те упомянутые 30000 строк — это абсолютная банальность.
Алгоритмы — это тоже отдельная песня. Ну не всем же нравится ломать голову над деталями кривых Безье
Здравствуйте, Cyberax, Вы писали:
C>...Количество переход в качество
Что под этим понимается? Количество чего? Я всегда эти слова понимал так, что количество вложенного труда переходит в качество результата, но не могу эту трактовку применить к вашим примерам: труд, затраченный на написанием миллионов строк на качестве, в хорошем смысле этого слова, не скажется.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
УЁ>>И придя в большой проект, такой разработчик может никому ничего не сказав начать что то переделывать, как всегда пообещав (в том числе самому себе) что все закончит через 2 дня.
_FR>Это "на раз" решается вменяемым менеджментом (без которого в большом проекте никак, верно?), так что сильно удивлюсь, если подобные проблемы действительно причиняют неудобство.
Вменяемый менеджмент — это тот, который будет пастись вокруг горе-программиста 24 часа в сутки и смотреть что он там на самом деле делает? Еще раз, он никому не скажет, что собирается все перепахать с нуля. Пообещает результат за 2 дня, менеджер подумает и скажет хорошо. Через день спросит — как там идут дела? Разработчик скажет что все по плану, завтра будет готово. А на самом деле нифига завтра готово не будет.
Второй сценарий — разработчик таки поймет, что переделать все невозможно, надо воткнуть нужный функционал в существующий код. Но вот она засада — опыта работы с миллионами строк чужого кода у него просто нет, и задача за 2 дня все равно не будет решена. И пройдет много времени, прежде чем он перестанет вздрагивать от вида тонн чужого кода, как правило далеко не лучшего качества.
Здравствуйте, _FRED_, Вы писали:
C>>...Количество переход в качество _FR>Что под этим понимается? Количество чего? Я всегда эти слова понимал так, что количество вложенного труда переходит в качество результата, но не могу эту трактовку применить к вашим примерам: труд, затраченный на написанием миллионов строк на качестве, в хорошем смысле этого слова, не скажется.
Нет, я имею в виду, что при большом количестве поддерживаемого кода, нужны уже качественно другие навыки, чем при поддержке кода в 30000 строк.
Здравствуйте, _FRED_, Вы писали:
УЁ>>Дело в том, что в проектах "миллионниках" происходит так свойственный этому миру количественно-качественный переход. И все проблемы, которые в маленьких проектах кажутся пустяковыми, могут оказаться принципиально невыполнимыми.
_FR>Из всего сказанного напрашивается вывод о том, что определяющими качествами разработчика являются умение мёрджить; не переписывать, а поддерживать всё на имеющемся средненьком, или даже ниже, уровне; и, конечно же, работа в условиях сильносвязанных систем
Для начала вынужден вам сообщить, что шансы попасть на проект, который только только начинает разрабатываться — близки к нулю. Почему так происходит — отдельная тема. В нашей реальности вы попадаете в проект, который уже находится в продакшене и требуется его развитие и поддержка. Конечно в таких проектах не только баги фиксят, но и пишут дофига нового кода, но этот код нужно приклеить к существующему, причем наилучшим в рамках имеющегося времени образом. Т.е. опять встает проблема умения работать с тоннами чужого кода. Во-вторых, как я уже сказал, слабосвязанные системы бывают только в сказках, где нет индусов, аутсорсинга и просто криворуких разработчиков. В при этом программисты-малометражники (с проектами из 30000 строк) будут в числе тех самых криворуких.
_FR>Но я просто не могу в это поверить: за, примерно, три десятка пережитых собеседований, никто ни одного подобного вопроса не спросил Наоборот даже: в небольших компаниях (где < 30 разработчиков) разговор про систему контроля версий и технологии и тонкости работы с ними (а так же про организацию работы с базой данных и уместность использования ассертов в тех или иных случаях) был гораздо душевнее, чем в больших компаниях, где упор почему-то, в полный противовес вашим словам, делался на паттерны, тонкости синтаксиса и знания библиотек. Почему так?
Ответ очень прост. На интервью рассказывают сказки о чудесном проекте, в котором все шоколадно и работать одно удовольствие. Если на интервью задать вопрос "а как вы относитесь в баг-фиксингу", то половина кандидатов сразу разбежится. Вот и спрашивают про всякие паттерны и прочий модный булшит, создавая впечатление мега-технологичной компании. Я ни в коем случае не говорю что не надо знать паттерны и спрашивать о них, я лишь говорю что по вопросам на интервью (адресованных кандидату) далеко не всегда можно понять, что там за кашу варят. Хотите узнать как обстоят дела на самом деле, то задавайте прямые вопросы о проекте.
Но это все частности. Я бы не стал обобщать опыт собеседований в больших и маленьких компаниях. Корреляции между размером компании и вопросами на интервью просто нет, все зависит от конкретных людей.
_FR> Или вот: все, у кого уже есть большая система рассказывают, что им как-раз таки нужны люди для серьёзно переделки больших её, системы, кусков, потому что заказчики уже есть, торопиться, как при стартапе, не надо и самое время подумать об удобстве будущих нововведений
Опять же, скорее всего это следует понимать как "требуются люди для бак-фиксинга и развития системы, да так, чтобы не поломать все нафиг".
_FR>Исходя из вышесказанного, никак не могу согласиться с тем, что решающим фактором (да вообще сколь угодно значимым) может быть опыт работы в больших проектах. Хотя бы потому, что привить его — дело нескольких месяцев, а вот выучиться на толкового девелопера — много сложнее.
Толковый девелопер без опыта работы в больших проектах сгодится только для написания cd-эректора. А для промышленной разработки он будет начинающим (пусть и толковым).
_FR>Да неужели и вы в своей компании или в других, на собеседованиях говорите больше про тонны кода, а не про небольшие конкретные кусочки, выясняя, что в них хорошего, а что — не очень?
В нашей компании (а точнее в нашем проекте) на интервью спрашивают все. И про отличие листа от сета (на что половина людей ответить не может), и про паттерны, и про уровни изоляции транзакций, и про опыт работы с тонной кода, и про опыт работы с системами контроля версий.
А нафига у кандидата спрашивать о небольших конкретных кусках нашего проекта я не понял...
Здравствуйте, Ушастый Ёж, Вы писали:
УЁ>>>И придя в большой проект, такой разработчик может никому ничего не сказав начать что то переделывать, как всегда пообещав (в том числе самому себе) что все закончит через 2 дня.
_FR>>Это "на раз" решается вменяемым менеджментом (без которого в большом проекте никак, верно?), так что сильно удивлюсь, если подобные проблемы действительно причиняют неудобство.
УЁ>Вменяемый менеджмент — это тот, который будет пастись вокруг горе-программиста 24 часа в сутки и смотреть что он там на самом деле делает?
Нет, это не правильное понятие менеджмента.
УЁ>Еще раз, он никому не скажет, что собирается все перепахать с нуля.
Чушь. Крышу может снести у кого угодно и спорить об этом бесмысленно. Дураком может быть кто угодно, не зависимо не от чего. Откуда, если не секрет, у вас стереотип о человеке без опыта работы в команде? На основании чего вы обобщаете своё мнение на всех "одиночек"? Если я начну рассказывать с какими примерами "коллективизма в условиях большого проекта" сталкивался, то у меня на клавиатуре некоторые кнопки с буквами, которые чаще всего встречаются в ругательных словах, поломаются или сотрутся
Но обобщать на всех те примеры я не вижу оснований. Напротив же, с примерами работы одиночек или очень небольших команд знаком исключительно с положительной стороны
УЁ>Пообещает результат за 2 дня, менеджер подумает и скажет хорошо.
С каких это пор (если говорить не о ком-то конкретно)? От том, как можно или не нужно поступать, вовсе не обязательно знать из личной опыта: достаточно общего мнения.
УЁ>Второй сценарий — разработчик таки поймет, что переделать все невозможно, надо воткнуть нужный функционал в существующий код. Но вот она засада — опыта работы с миллионами строк чужого кода у него просто нет, и задача за 2 дня все равно не будет решена. И пройдет много времени, прежде чем он перестанет вздрагивать от вида тонн чужого кода, как правило далеко не лучшего качества.
Коментировать ваши фантазии или страхи (ведь мы, повторюсь, говорим не конкретно о ком-то, а вообще о разработчике, не учавствовавшем в проекте на несколько миллионов строк) нет никакого желания.
По моему предвзятому мнению, мне удалось высказать свою точку зрения, которая заключается в том, что не количество строк и человеко-лет проекта делает разработчика ценным. Даже хоть сколько-нибудь ценным. Качество и умение являются определяющими факторами и если в какой-либо компании на собеседовании говорят или требуют, в первую очередь, не этого, идти туда не стоит, потому что вынести от туда можно лишь пресловутый, поставленный у меня по сомнение, опыт.
Вы прекрасно описали, что там ждёт. И кому такого надо? А зачем?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Cyberax, Вы писали:
C>>>...Количество переход в качество _FR>>Что под этим понимается? Количество чего? Я всегда эти слова понимал так, что количество вложенного труда переходит в качество результата, но не могу эту трактовку применить к вашим примерам: труд, затраченный на написанием миллионов строк на качестве, в хорошем смысле этого слова, не скажется. C>Нет, я имею в виду, что при большом количестве поддерживаемого кода, нужны уже качественно другие навыки, чем при поддержке кода в 30000 строк.
Да, с этим соглашусь, но ни где раньше не видел употребление обсуждаемой фразы в подобном контексте. Это не переход, а требование. И (если специально этому вопросу не уделять много внимания), зачастую (насколько видел и слышал я), переход, ведущий к снижению качества отдельных частей ради поддержания общего качества на существующем уровне. Пример — есть какой-то кусок (у многих такое есть :о)), который сделан ... не хорошо, скажем так. Все про это знают, но возможности переделать не находят. При необходимости как-то затронуть этот кусок приходится делать прикрутку не на столько хорошей и удобной в будущем, как могло бы быть. Но иначе нарушится и "общая картина", общий стиль. В результате количество кода разбухает, качество остаётся на одном уровне => проблем больше, так как стоимость повышения качества растёт или, что более точно, стремится к бесконечности.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
УЁ>>Вменяемый менеджмент — это тот, который будет пастись вокруг горе-программиста 24 часа в сутки и смотреть что он там на самом деле делает? _FR>Нет, это не правильное понятие менеджмента.
Вы не заметили что это был вопрос, а не утверждение? Да к тому же с сарказмом?
УЁ>>Пообещает результат за 2 дня, менеджер подумает и скажет хорошо. _FR>С каких это пор (если говорить не о ком-то конкретно)? От том, как можно или не нужно поступать, вовсе не обязательно знать из личной опыта: достаточно общего мнения.
Вы меня извините, но я не понимаю о чем вы пишите. Вы перечитываете свои сообщения перед отправкой?
УЁ>>Второй сценарий — разработчик таки поймет, что переделать все невозможно, надо воткнуть нужный функционал в существующий код. Но вот она засада — опыта работы с миллионами строк чужого кода у него просто нет, и задача за 2 дня все равно не будет решена. И пройдет много времени, прежде чем он перестанет вздрагивать от вида тонн чужого кода, как правило далеко не лучшего качества.
_FR>Коментировать ваши фантазии или страхи (ведь мы, повторюсь, говорим не конкретно о ком-то, а вообще о разработчике, не учавствовавшем в проекте на несколько миллионов строк) нет никакого желания.
Все понятно, вам кажется это фантазией, потому что вы с этим еще не встречались. Ну тогда все еще впереди.
_FR>По моему предвзятому мнению, мне удалось высказать свою точку зрения, которая заключается в том, что не количество строк и человеко-лет проекта делает разработчика ценным. Даже хоть сколько-нибудь ценным. Качество и умение являются определяющими факторами и если в какой-либо компании на собеседовании говорят или требуют, в первую очередь, не этого, идти туда не стоит, потому что вынести от туда можно лишь пресловутый, поставленный у меня по сомнение, опыт.
Все верно, качество и умение. Плюс опыт работы в реальных проектах (а не лабораторных работах), который вы почему то продолжаете и продолжаете игнорировать.
_FR>Вы прекрасно описали, что там ждёт. И кому такого надо? А зачем?
Прежде чем вы напишите свой проект в миллион строк, неплохо было бы посмотреть на уже написанные другими людьми.
Здравствуйте, MozgC, Вы писали:
MC>Ясно... Ну а на позицию Senior S.D. нормально претендовать с 2.5 — 3 годами опыта или слишком нагло?
Вполне нормально.
Все зависит от того, чем вы занимались эти 2.5-3 года.
Один человек активно учится, а другой просто штаны просиживает...
Думаю вы можете объективно сравнить себя и других синиоров из вашей команды и сами себе ответить на этот вопрос.
Про термин "Нагло" следует забыть.
(часов четырех, я думаю, будет достаточно) и преобразовать ее в иерархию классов (еще 4-8 часов), после чего реализовать все это на функциональном псевдоязыке 
Вернее, каких-то особенных критериев для команды программистов. Если человек работал в команде начальника, его секретарши, её ухажёра и жены начальника впридачу с бухгалтером, охранником, уборщицей и сисадмином, то это опыт работе в команде.
] разделения, обмена мыслями с другими людьми с целью выслушать критику, переосознать или, наоборот, утревлиться в своих выводах. Умение вовремя (+-) сделать то, что обещал (написать класс или принести какую-нить справку в администрацию — не важно!).
Весьма поспешно и бездоказательно. Основываясь на своих ощущениях или опыте я тоже могу написать чот-то для других странное. Но это не интересно. Я бы сказал, "Скорее всего, не может…". Тут же выглядит как приговор 
) Так что развитие "в отрыве от команды" более чем возможно.
вот если не вернётся — то 
Если ты один, то что мешает писать "на века", что бы "…песня!!!"?
