Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, gogogogogo, Вы писали:
G>>основные параметры: G>>- количество кода (либо в строках, либо в килобайтах, либо в мегабайтах)
O>Все остальные параметры настолько субъективны... Вот как оценить стиль? В каких единицах? От 1 до 5 чего? Очень похоже на попытку математически измерить красоту пейзажа.
гоните, коллега
все очень просто
пишется документ, в котором указываются единые требования к коду для всех программистов компании
— способ именования внутри кода
— способ именования файлов и каталогов
— размер отступов
— объем необходимых комментариев
— допустимый размер функций
— максимальная допустимая глубина вложенности
вот и все, насколько помню
все остальное оценивать не нужно, либо нарабатывается в процессе работы (скажем человек склонен использовать слишкомсложные и неудобочитаемые конструкции, просто можно попросить его писать проще)
Здравствуйте, gogogogogo, Вы писали:
G>формулы не знаю
G>но поскольку сам результат труда поддается измерению, то ее достаточно легко вывести G>основные параметры: G>- количество кода (либо в строках, либо в килобайтах, либо в мегабайтах)
А если большая часть кода автогенерная? Не учитывается сложность кода.
G>- количество и вес найденных багов (не более 5 категорий багов с весом от 1 до 5)
Субъективно.
G>- общий стиль кодирования (от удовлетворительного до отличного)
Очень субъективно.
G>- общий стиль архитектуры (от удовлетворительного до отличного)
Совсем субъективно.
G>- объем опыта в данной области (от удовлетворительного до отличного)
А как мерить? Годами или теме же строками?
G>- объем опыта в области специфичной для конкретного проекта, если проект большой (от удовлетворительного до отличного)
Совсем непонятно
G>- оценка по командной работе, данная коллегами по команде (от удовлетворительного до отличного, высчитывается среднее)
G>поманипулируйте параметрами и получите результат
Попробую.
Идеальный программист. 30 лет — 10 в разработке. Всю жизнь занимался бухгалтерскими программами. Пишет исключительно по GOF и Фаулеру. На каждом проекте делает свой ORM (учитывая что уже 50-й раз, то очень почти без багов), базу делаеть исключительно на SQL. Любит поговорить, всегда развернуто отвечает на вопросы "молодых", особенно по архитектуре. 5 лет назад увидет Coding Style от Microsoft, использует исключительно его.
Будет разрабатываться программа для бухгалтерии — будет получать больше всех.
Другой вариант.
Ужасный программист. 21 год, только закончил вуз, не больше года в разработке. (Пишет для примера на C#) Базу рисует в MS SQL Server Management Studio в графическом дизайнере. Использует LINQ2SQL (LINQ to Entities) для организации DAL, использует по-максимуму готовые компоненты. Кода сам пишет мало. Ошибки допускает, но быстро исправляет из-за простоты кода. Паттерны почти не использует. Стиль не всегда соблюдает. Немного стеснителен, общается мало.
На аналогичном проекте по бухгалтерии будет получать меньше всех.
Здравствуйте, Trinity-2001, Вы писали:
1. Увы, но на российском рынке (про западный не имею достоверных сведений) ЗП слабо коррелирована с профессионализмом, больше влияет как куда к кому устроился и насколько смог себя продать. ЗП двух сидящий рядом программистов очень часто одинаковая при несравненных знаниях/опыте.
2. Не смотря на 1 . Тебя дурят, наберись наглости и выложи руководству всё что ты думаешь по поводу. Если пошлют, то что ты забыла в такой конторе , поищи другую. Кстати искать можно начать заранее, вероятно ты быстро получишь интересные предложения, хоть и безусловно в РФ отношения к женщинам-программисткам изначально насторожденное .
Здравствуйте, gogogogogo, Вы писали:
G>пишется документ, в котором указываются единые требования к коду для всех программистов компании G>- способ именования внутри кода G>- способ именования файлов и каталогов G>- размер отступов G>- объем необходимых комментариев G>- допустимый размер функций G>- максимальная допустимая глубина вложенности
G>вот и все, насколько помню G>все остальное оценивать не нужно, либо нарабатывается в процессе работы (скажем человек склонен использовать слишкомсложные и неудобочитаемые конструкции, просто можно попросить его писать проще)
А потом появляется программер, упорно игнорирующий все эти правила и на кажлоре замечание выдающий длинное и слабо связанное логикой объяснение почему он полностью прав что так поступил . Причём его не остановит тот факт, что последние его 10 багов были как раз по причине игнорирования очередной серии пунктов документа .
Здравствуйте, gandjustas, Вы писали:
G>Идеальный программист. 30 лет — 10 в разработке. Всю жизнь занимался бухгалтерскими программами. Пишет исключительно по GOF и Фаулеру. На каждом проекте делает свой ORM (учитывая что уже 50-й раз, то очень почти без багов), базу делаеть исключительно на SQL. Любит поговорить, всегда развернуто отвечает на вопросы "молодых", особенно по архитектуре. 5 лет назад увидет Coding Style от Microsoft, использует исключительно его. G>Будет разрабатываться программа для бухгалтерии — будет получать больше всех.
G>Другой вариант. G>Ужасный программист. 21 год, только закончил вуз, не больше года в разработке. (Пишет для примера на C#) Базу рисует в MS SQL Server Management Studio в графическом дизайнере. Использует LINQ2SQL (LINQ to Entities) для организации DAL, использует по-максимуму готовые компоненты. Кода сам пишет мало. Ошибки допускает, но быстро исправляет из-за простоты кода. Паттерны почти не использует. Стиль не всегда соблюдает. Немного стеснителен, общается мало. G>На аналогичном проекте по бухгалтерии будет получать меньше всех.
G>Ну и где здесь математическая точность?
не совсем понял, как эти описания относятся к моему списку критериев
но мысль понял
ясно дело, что формализовать способ вычисления качества работника достаточно сложно, но сделать это можно
ес-сно такая формализация имеет смысл только в больших компаниях
просто почти все места, где я работал, максимально избегали такой формализации, поэтому воспринимайте мои посты, как некую тоску по нормально организованной работе
G>А если большая часть кода автогенерная? Не учитывается сложность кода.
Что за такой проект где основная чать кода получается автогенерацией ?
G>Идеальный программист. 30 лет — 10 в разработке. Всю жизнь занимался бухгалтерскими программами. Пишет исключительно по GOF и Фаулеру. На каждом проекте делает свой ORM (учитывая что уже 50-й раз, то очень почти без багов), базу делаеть исключительно на SQL. Любит поговорить, всегда развернуто отвечает на вопросы "молодых", особенно по архитектуре. 5 лет назад увидет Coding Style от Microsoft, использует исключительно его. G>Будет разрабатываться программа для бухгалтерии — будет получать больше всех.
Ой врятли он пишет свой маппер, скорее расскажет как его можно написать. Написать 50 раз свой маппер — это и 10ти лет не хватит. Фаулера он вероятно прочитал, а потом сказал, что ерунду написал этот файлер, в простых случаях всё и так очевидно, а в сложных по файлеру только ещё сложнее чем на самом деле выходит. Юнит тесты это расстрел воробьёв из гранатомёта, так как они только услосложняют жизнь и ничего не дают полезного.
G>Другой вариант. G>Ужасный программист. 21 год, только закончил вуз, не больше года в разработке. (Пишет для примера на C#) Базу рисует в MS SQL Server Management Studio в графическом дизайнере. Использует LINQ2SQL (LINQ to Entities) для организации DAL, использует по-максимуму готовые компоненты. Кода сам пишет мало. Ошибки допускает, но быстро исправляет из-за простоты кода. Паттерны почти не использует. Стиль не всегда соблюдает. Немного стеснителен, общается мало. G>На аналогичном проекте по бухгалтерии будет получать меньше всех.
Вероятне всего по каждой новой технологии от МС кричит "Вот какая концепуция, она перевернёт мир, давайте её использовать". Он не знает, что есть хибернейт, iBattis, Ado.net, он точно знает что linq2sql это супер, это современно, это МС, это на века. Он использует готовые компоненты, желательно без исходного кода, так как он не умеет его читать и не понимает. Если этот компонент упадёт, он расскажет про глюки студии, винды и несоврешенство нета, так как он не умеет править чужой код. Паттерны не использует, да и зачем, когда намного интереснее всё открывать самому, пусть даже после сотой очередной правки кода он получит фабрику, композит или интерпретатор. Зато какой кайф прийти самому к тому, что уже где то давно описано!
G>Ну и где здесь математическая точность?
А точность в том, что оба приведённых случая малополезны в проекте современного бухгалтерского софта .
Здравствуйте, Aviator, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>А если большая часть кода автогенерная? Не учитывается сложность кода. A>Что за такой проект где основная чать кода получается автогенерацией ?
Web-приложения на ASP.NET. Тонны кода генерируются несколькими кликами в дизайнере.
G>>Идеальный программист. 30 лет — 10 в разработке. Всю жизнь занимался бухгалтерскими программами. Пишет исключительно по GOF и Фаулеру. На каждом проекте делает свой ORM (учитывая что уже 50-й раз, то очень почти без багов), базу делаеть исключительно на SQL. Любит поговорить, всегда развернуто отвечает на вопросы "молодых", особенно по архитектуре. 5 лет назад увидет Coding Style от Microsoft, использует исключительно его. G>>Будет разрабатываться программа для бухгалтерии — будет получать больше всех. A>Ой врятли он пишет свой маппер, скорее расскажет как его можно написать. Написать 50 раз свой маппер — это и 10ти лет не хватит. Фаулера он вероятно прочитал, а потом сказал, что ерунду написал этот файлер, в простых случаях всё и так очевидно, а в сложных по файлеру только ещё сложнее чем на самом деле выходит. Юнит тесты это расстрел воробьёв из гранатомёта, так как они только услосложняют жизнь и ничего не дают полезного.
Зря утрируешь. Я видел таких программистов, как описал. По критериям товарища gogogogogo такой програмист должен получать больше всех.
G>>Другой вариант. G>>Ужасный программист. 21 год, только закончил вуз, не больше года в разработке. (Пишет для примера на C#) Базу рисует в MS SQL Server Management Studio в графическом дизайнере. Использует LINQ2SQL (LINQ to Entities) для организации DAL, использует по-максимуму готовые компоненты. Кода сам пишет мало. Ошибки допускает, но быстро исправляет из-за простоты кода. Паттерны почти не использует. Стиль не всегда соблюдает. Немного стеснителен, общается мало. G>>На аналогичном проекте по бухгалтерии будет получать меньше всех. A>Вероятне всего по каждой новой технологии от МС кричит "Вот какая концепуция, она перевернёт мир, давайте её использовать". Он не знает, что есть хибернейт, iBattis, Ado.net, он точно знает что linq2sql это супер, это современно, это МС, это на века. Он использует готовые компоненты, желательно без исходного кода, так как он не умеет его читать и не понимает. Если этот компонент упадёт, он расскажет про глюки студии, винды и несоврешенство нета, так как он не умеет править чужой код. Паттерны не использует, да и зачем, когда намного интереснее всё открывать самому, пусть даже после сотой очередной правки кода он получит фабрику, композит или интерпретатор. Зато какой кайф прийти самому к тому, что уже где то давно описано!
А тем не менее на неочень сложных проектах по автоматизации бизнеса такой программист работет гораздо быстрее первого случая. Хотя по критериям товарища gogogogogo такой програмист будет получать меньше всех.
G>>Ну и где здесь математическая точность? A>А точность в том, что оба приведённых случая малополезны в проекте современного бухгалтерского софта .
Здравствуйте, Trinity-2001, Вы писали:
T2>Народ, посоветуйте, что делать!! Искать другую работу, где будут платить больше и где люди нужны больше и бросить эту работу? Или что-то другое предпринять? Мучаюсь сомнениями и не знаю, что делать... Как-то это все очень обидно.. Может, кто-то был в таком положении, как я, и как вышел из него?
Мне кажется, Вам сейчас, как молодому специалисту, важнее набираться опыта, чем гнаться за зарплатой. Так что если контора Вам чего-то дает в плане самообучения, продолжайте работать, пока не почуствуете, что Вы уже переросли ту должность, которую занимаете. Если же не дает, ищите другую работу.
И Вы не должны рассматривать свою зарплату как мерило Вашего профессионализма. Иначе у Вас появится вполне реальный шанс оказаться там, где много платят, но ничему не научишься. Что в конечном итоге заведет Вас через несколько лет в тупик.
Здравствуйте, gogogogogo, Вы писали:
G>но поскольку сам результат труда поддается измерению, то ее достаточно легко вывести G>основные параметры: G>- количество кода (либо в строках, либо в килобайтах, либо в мегабайтах)
Количество кода, необходимого для решения одной и той же проблемы, может различаться у разных людей в несколько раз. Даже если не учитывать различие в стиле форматирования кода и в количестве пустых строк и комментариев. При этом очевидно, что каждая лишняя строка кода — потенциальное место, куда можно посадить багу.
G>- количество и вес найденных багов (не более 5 категорий багов с весом от 1 до 5)
Количество багов зависит от сложности кода, от качества архитектуры (зачастую навязанной тому, кто пишет код), от условий работы, от того, как часто приходится работать до ночи и по выходным.
G>- общий стиль кодирования (от удовлетворительного до отличного)
К сожалению, весьма субъективная вещь. Я тут как-то поспорил с кем-то, он привел стиль кодирования, который он считал идеальным. Я бы за такой убивал на месте.
G>- общий стиль архитектуры (от удовлетворительного до отличного)
Не всегда зависит от того, кто пишет код. Кроме того, вообще оценка качества архитектуры очень зависит от сложности решаемой задачи. Скажем, если задача сложная и необычная, то в хороших руках может получиться не слишком удачная архитектура, но все же работающая. А в плохих руках может ничего не получиться.
G>- объем опыта в данной области (от удовлетворительного до отличного) G>- объем опыта в области специфичной для конкретного проекта, если проект большой (от удовлетворительного до отличного)
Объем опыта обычно известен со слов обвиняемого.
G>- оценка по командной работе, данная коллегами по команде (от удовлетворительного до отличного, высчитывается среднее)
Очень зависит от человеческих отношений в команде.
В общем, я хочу сказать, нет никаких универсальных, объективных, математически точных критериев. Однако опытный человек может довольно легко оценить на глаз справедливую зарплату программиста, причем довольно точно.
Оценивая труд человека, работающего в команде, я бы в первую очередь смотрел на его вклад в проект (т.е., насколько сложнее было бы развивать проект, если бы не было такого человека, и вообще, в какой мере на этого человека можно положиться), а не количество производимых им человекобагов в минуту.
Приветствую!
За 15 дней до окончания испытательного срока:
1) Намечаете разговор в вежливой форме HR
2) Все что сдесь написали скажите ему (насчет зарплат коллег надо опустить, говорите сумму *чуток выше той, которая Вас устроит), а потом расскажите что Вас реально устраивает в этой фирме (как в басне про кусочек сыра у вороны )
3) Теперь ситуация раздваивается на 2 ветки:
а) Вы им подходите и они оценили Ваш вклад
1) Начнут торговаться. Сначала надо спустить половину из "чуток выше той, которая Вас устроит"
2) Стоять на этой зарплате до конца
3) Чтобы этого добиться, нужно спросить о дальнейших benefits'ах (бассейн, машина и т.д.) — даже если это и не нужно. HR свой торговый пыл снизит, отвлечется.
4) Если все еще торгуется (достал ) то спросите причину почему он не может дать Вам запрошеную сумму
5) Макс. что потеряете в деньгах это тот самый "чуток выше той зарплаты, которая Вас устроит".
6) НЕ ЗАБУДЬТЕ СПРОСИТЬ О СЛЕД. РАЗГОВОРЕ
7) Активизируйте подписание бумаг в тот-же или след. день.
б) Вы им не подходите
1) Уйти надо самой
2) Научиться себя ценить и знать свою цену. Работу 100% найдете ту, которая Вам подходит по всем параметрам
Проверено Кстати, если в фирме есть реальные недостатки — большой плюс если их нормально высказать (аргументировано). Разговор с HR это как бой И надо научиться побеждать!
Удачи!
Здравствуйте, raydac, Вы писали:
T2>>Не хочу никого обидеть, но я не очень уважаю женщин, которые таким способом получают работу и повышение- по-моему, это унизительно как-то.
R>да вообще совет бредовый, единственное что можно из него взять, что карьера в ИТ делается в большинстве случаев на человеческом факторе
Молодой человек, слово ИТ тут лишнее. People skills are the must everywhere!
Здравствуйте, Pzz, Вы писали:
Pzz>И Вы не должны рассматривать свою зарплату как мерило Вашего профессионализма. Иначе у Вас появится вполне реальный шанс оказаться там, где много платят, но ничему не научишься. Что в конечном итоге заведет Вас через несколько лет в тупик.
Ощущение, что тебе недоплачивают, обычно офигенно снижает мотивацию и полностью отбивает желание выкладываться на работе. Но при этом большая ЗП не компенсирует отстуствие профессионального роста.
Здравствуйте, Igor Beeone, Вы писали:
IB>Проверено Кстати, если в фирме есть реальные недостатки — большой плюс если их нормально высказать (аргументировано). Разговор с HR это как бой И надо научиться побеждать! IB>Удачи!
Девушка явно неуверенно себя чувствует, я бы ей посоветовал ещё походить по собеседованиям. Как минимум это повысит самооценку и научит общаться с работодателями .
Здравствуйте, alcotras, Вы писали:
A>Молодой человек, слово ИТ тут лишнее. People skills are the must everywhere!
Ага, это как в Office Space: "Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?"
T2>Недавно устроилась на новую работу программистом (месяца 3 назад). Работа по предметной области — то, что мне больше нравится — это системное программирование. НО! Из-за того, что у меня не особо много опыта в данной области, мне пришлось согласиться на более низкую зп, чем была на прошлой работе. HR при найме мне сказала, что большинству программеров здесь закрывают испытательный срок через 1-1.5 месяца.
Договариваться надо конкретнее. 1-1.5 месяца означает, что скорее всего 1.5. А "большинству программеров здесь..." — по большому счёту вообще никаких обязательств со стороны работодателя.
T2>НО! Прошло уже почти 3 месяца, а мне его пока так и не закрыли. Ну ладно, я могу это понять — была выставка — все бегали, у всех жопа горела, не до меня...
Следует понимать, что в вопросе, сколько тебе платить, у тебя с работодателем интересы прямо противоположные. Поэтому ожидать от работодателя инициативы в этом вопросе по меньшей мере странно.
T2>Сказали неделю назад, что пересмотрят зп, когда я кое-что доделаю, а это что-то вообще не от меня конкретно зависит...
Ключевой момент. К имевшим место договорённостям добавляются дополнительные условия. Стоит согласиться один раз, и становится понятно, что с тобой можно особо не церемониться.
T2>...может, дело в том, что я женщина , а женщинам-программистам, наверное, не любят много платить....
Работодатель знает, что к женщинам-программистам отношение скептическое, и тебе труднее найти работу, даже если ты владеешь профессией не хуже других. Поэтому на тебе можно съэкономить.
T2>Народ, посоветуйте, что делать!! Искать другую работу, где будут платить больше и где люди нужны больше и бросить эту работу? Или что-то другое предпринять? Мучаюсь сомнениями и не знаю, что делать... Как-то это все очень обидно.. Может, кто-то был в таком положении, как я, и как вышел из него?
Думаю, на этой работе сложно будет изменить к себе отношение.
T2>Кстати, есть несколько контор, которые меня бы тоже привлекли и по задачам, и по условиям, но я вот не знаю, что делать... Боюсь я как-то работу уже менять. Да и неудобно как-то, если уж получается, что сама напросилась на работу в эту контору...
Здесь важно не это. А то, что уход с работы так быстро может восприниматься будущими работодателями, как непрохождение испытательного срока. Рекомендую промучаться как минимум пол года. А лучше год. Но, конечно, не стоит терять времени впустую. Нужно постепенно начинать дёргать работодателя.
Здравствуйте, Trinity-2001, Вы писали:
T2>И САМОЕ ГЛАВНОЕ! Из-за всего этого у меня совершенно отпадает желание что-либо делать, работа мне противна становится... Производительность, как следствие, падает . А когда я ощущаю свою нужность конторе, я работаю СОВСЕМ ПО-ДРУГОМУ, с ажиотажем, с горящими глазами!
T2>Кстати, есть несколько контор, которые меня бы тоже привлекли и по задачам, и по условиям, но я вот не знаю, что делать... Боюсь я как-то работу уже менять. Да и неудобно как-то, если уж получается, что сама напросилась на работу в эту контору... T2>Подскажите, плиз, что делать... Может, я чего-то не понимаю...
Ага, ситуация знакомая. В свое время в одну из моих прошлых контор также девушка устраивалась. Потом втянулась, стала нормально зарабатывать.
А по делу, народ правильно говорит — либо расслабиться, работать и получать от этого удовольствие, либо вывешивать резюме (можно и сюда его скинуть, чтобы люди подсказали, куда с ним стоит идти) и ходить по собеседованиям.
Да, к сожалению девушек боятся брать на долгоиграющие проекты — боятся, что в декрет уйдет (ничего личного, просто сталкивался я с этой ситуацией).
Да, а системщики сейчас действительно не очень хорошо зарабатывают. Могу подкинуть мысль — подумайте уйти в юниксовые области обработки данных. Сейчас таких задач хватает, где под юниксом крутятся сервера, обрабатывающие данные (пишутся обычно на си и яве). В принципе, тоже практически никаких окошек. А денег там больше.
F>Ну, это зависит от многого. Много платить работодатели не любят никому... А то, что ты женщина даёт тебе колоссальное превосходство, на самом деле: ты можешь, например, одеться ультрасекси и подружится с топ-менеджментом... Всё решают отношения между людьми, вобщем, и тут у женщин чудовищное преимущество!
На самом деле такие советы исчерпывающе характеризуют их дающего.
Разве это не классно?
. Тебя дурят, наберись наглости и выложи руководству всё что ты думаешь по поводу. Если пошлют, то что ты забыла в такой конторе 
.
, а женщинам-программистам, наверное, не любят много платить....
