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

E>>>То, что вам платят мало (или меньше, чем вы хотите), говорит лишь о том, что:
E>>>1. У вас завышенная самооценка (вы думаете, что стоите больше, чем есть на самом деле)
E>>>2. Вы вынуждены работать за эту з/п, т.к. иначе уже давно сменили бы место работы.
LM>>Вы забываете про другую мотивацию.
E>Да? Неужели? Какая такая?А мне тут рассказывали, что нет более лучшей мотивации, чем деньги...

Автор: AmSpb
Дата: 30.06.06

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

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

E>>Ребят, сложно спорить, когда вы говорите, что:
E>>1. Я плохо работаю потому, что мне мало платят.
E>> 1.1 Но при этом я не уйду, хотя в другом месте платят больше
E>Ты предлагаешь каждый раз, попадая в плохо платящую контору, тотчас же писать заявление ?

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

E>Ты не знаешь основной принцип игр ? Основной фактор, заставляющий людей проигрываться в пух и прах — это желание отыграться за то, что проиграл.
E>Это же желание держит нас на прежнем рабочем месте, это же стремление позволяет нас "динамить" девушкам.

Это не игра, далеко не игра. И принципы игр здесь неприменимы.
Вы же не станете покупать машину "на авось"?

E>Я сейчас в такой же ситуации. Мало платят, в конторе все фигово, но не ухожу потому что
E>- хочу отгулять отпуск

Да, это знакомо. Ну так отгуляйте и уходите. Думаю, сейчас фирмы, проводящие неграмотную кадровую политику будут коллапсировать.

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

E>>А "авансом" з/п не повышают нигде, на этот счет можете быть спокойны. Сначала вы доказываете, что можете работать лучше, а потом повышается з/п.
DE>Кстати, это достаточно философский вопрос — что первично в плане повышения производительности, труд или мотивация?
DE>Получается что есть два пути:
DE>- работать больше, надеясь что начальство заметит и повысит зарплату

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

DE>- начальство сразу оговаривает виды мотивации, и человек работает больше если эта мотивация его устраивает
DE>Лично мне второй путь кажется более перспективным для сотрудника, т.к. человек имеет более конкретные цели и задачи. Впрочем это ИМХО.

Почему больше то? Выполнить и перевыполнить? Это далеко в прошлом.
На самом деле все очень просто. Действуют первичные законы бизнеса
1. Вы повышаете уровень своего профессионализма. За счет опыта и знаний. И начинаете работать лучше. Возможно и больше, но только не за счет времени, проведенного за работой (!), а за счет знаний и опыта, позволяющих вам сделать больший объем работы.
2. Как профессионал вы реально на рынке начинаете стоить больше. Работодатель, заинтересованный чтобы вы работали именно у него, а не у конкурента повышает вам з/п. Еще раз повторю свой тезис: З/П — это средство удержания, и не более того.
3. Если работодатель платит вам меньше денег, чем вы стоите как специалист, то он теряет вас как специалиста, вот и все. Также как нельзя купить мерседес по цене запорожца — закон бизнеса.

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

DE>Кстати, насчет повышения з/п "авансом" — учитывая инфляцию 10% в год, пересчет зарплаты раз в году с учетом этого, есть вполне распространенная практика. Правда, по правде говоря это не совсем повышение...

Это компенсация инфляции, а не повышение.

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

ГВ>>Э... Тема про кодогенерацию, как замену виртуальных функций — не раскрыта.
Д>Только во время компиляции, если тип можно вывести из контекста. А как — это и так должно быть очевидно.

Всё равно не понятно. Имеем два типа:

class Foo
{
  void main_func();
};

class Bar
{
  void primary_function();
};

Класс-пользователь должен вызвать main_func() и primary_function(). Как будем делать кодогенератор? Адаптеры совать типа таких:

template<typename T>
class Adapter
{
  void recall(T *p)
}

template<>
void Adapter<Foo>::recall(Foo *p)
{
  p->primary_function();
}

?

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

DE>>Получается что есть два пути:
DE>>- работать больше, надеясь что начальство заметит и повысит зарплату

E>Работать лучше, не больше.

Как оценивать работу, "лучше" она стала или нет? Какие критерии? Мотивация она ведь должна быть четкой, чтобы человек мог знать на что может расчитывать в том или ином случае.

E>Только очень глупый менеджер станет мотивировать переработки, если в этом нет прямой необходимости.

Мотивация может быть и косвенной, например приличная премия по окончании проекта. И у человека будет стимул сделать все дела быстрее.

E>НО как только вы начинаете тунеядничать и ныть..

У Вас весьма полярная оценка работоспособности — человек или вкалывает по 8 часов в сутки не отрываясь, или тунеядец А ведь на самом деле градаций гораздо больше.
Если например, я потратил 4 минуты рабочего времени на то чтобы написать это сообщение в форум, меня уже можно считать тунеядцем, или ещё нет?

E>Почему больше то? Выполнить и перевыполнить? Это далеко в прошлом.

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

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

L>Интересно.. А ошибки системы что, сами собой возникают? Это ошибки в юнитах, не отловленные на этапе юнит-тестов, пусть даже они и возникают только на этапе интеграции системы.

Я попытаюсь объяснить на примере... Предположим, что у нас есть два юнита: парень и девушка Оба юнита можно замечательно протестировать: девушка умная, красивая, спортсменка, комсомолка , общительная, с веселым характером, с адекватной реакцией на входные воздействия (кроме того, которое до сих пор мы не могли протестировать по вполне понятным причинам ). Парень — неглупый, симпатичный, турист-скалолаз, душа компании, умеет играть на гитаре. Оба юнита были разработаны 20 лет назад, их баги были выловлены и исправлены в первые 10 лет существования, и вот уже 10 лет как юнит-тестирование этих двух юнитов можно считать 100% завершенным

И вот некий архитектор (который, собственно говоря, и занимается организацией всех процессов, которые происходят там, где функционируют эти юниты ) решает объединить эти юниты в единую систему...

Вопрос: как поведет себя система из объединения двух перечисленных юнитов? Я утверждаю, что, несмотря на стабильное функционирование этих юнитов по-отдельности на протяжении вот уже 10 лет, немеренное количество багов попрет сплошным потоком

L>Вопрос еще и в том, что и когда считать юнитом
Ну в некоторых технологиях юнит-тестирования это четко оговорено. Посмотрите на JUnit — классический пример подхода к юнит-тестированию. Или я не прав?

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

E>Ты предлагаешь каждый раз, попадая в плохо платящую контору, тотчас же писать заявление ?
E>и получать
E>1.1.1. Лишниюю запись в трудовой книжке, потрящей твою трудовую биографию и характеризующей как летуна
E>1.1.2. поиск новой работы со всеми "плюсами" — нервы с выбором варианта, езда по собеседованиям, время, потраченное на выполнения тестовых (при том все время поиска вам никто ничего не платит)
E>+ потеря отпуска

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

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

DE>>>Получается что есть два пути:
DE>>>- работать больше, надеясь что начальство заметит и повысит зарплату
E>>Работать лучше, не больше.
DE>Как оценивать работу, "лучше" она стала или нет? Какие критерии?

Это видно, поверьте.

E>>Только очень глупый менеджер станет мотивировать переработки, если в этом нет прямой необходимости.
DE>Мотивация может быть и косвенной, например приличная премия по окончании проекта. И у человека будет стимул сделать все дела быстрее.

Это и есть мотивация переработки.

E>>НО как только вы начинаете тунеядничать и ныть..
DE>У Вас весьма полярная оценка работоспособности — человек или вкалывает по 8 часов в сутки не отрываясь, или тунеядец

Ничего подобного

Автор: Eurispheus
Дата: 04.07.06

.

E>>Почему больше то? Выполнить и перевыполнить? Это далеко в прошлом.
DE>Ну если у Вас "перевыполнять" ничего не нужно, никакие сроки не горят, то тогда и мотивировать кого-либо незачем, работа идет и ладно. Но обычно ведь бывает наоборот, выгоднее закончить проект пораньше.

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

Здравствуйте, Александр Каширин, Вы писали:

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

E>>Ты предлагаешь каждый раз, попадая в плохо платящую контору, тотчас же писать заявление ?
E>>и получать
E>>1.1.1. Лишниюю запись в трудовой книжке, потрящей твою трудовую биографию и характеризующей как летуна
E>>1.1.2. поиск новой работы со всеми "плюсами" — нервы с выбором варианта, езда по собеседованиям, время, потраченное на выполнения тестовых (при том все время поиска вам никто ничего не платит)
E>>+ потеря отпуска

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

Отпуск между работами — это нервы и неопределенность — а вдруг откат или отказ (не каждый ее любит). Компенсацию за неиспользованный отпуск многие стараются "забыть" (но это уже другая тема). Большинство все же платят.

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

Хотя как вариант отпуска, временную безработицу можно рассматривать. Но ... как-то нехорошо напрягает это состояние.))

XP тема: "программирование по законам шариата"

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

skipped

DH>можно подумать, что ты сейчас не в интернете и работаешь...

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

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

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM> правильный ответ был бы, imho, "для чего?".
Правильно говоришь
Зачем квадрат от прямоугольника наследовать или наоборот. Это же, суть, одно и то же
четыре стороны, прямые углы, не вижу разницы. Красить,рисовать, вычислять площадь и тп.
если что невлезет, так можно и делегат туда приспособить ввести еще один абстрактный уровень

Здравствуйте, Александр Каширин, Вы писали:

АК>Здравствуйте, landerhigh, Вы писали:

L>>Интересно.. А ошибки системы что, сами собой возникают? Это ошибки в юнитах, не отловленные на этапе юнит-тестов, пусть даже они и возникают только на этапе интеграции системы.

АК>Я попытаюсь объяснить на примере... Предположим, что у нас есть два юнита: парень и девушка Оба юнита можно замечательно
Хм.. пример, конечно, интересный, но есть одно но — данная конкретная девушка и данный конкретный парень вовсе не разрабатывались для создания пары (о, как звучит!). Вот тут и понадобится последующая шлифовка-притирка, если пара таки создастся.
А когда речь идет о программной системе, когда известно, что методы Х класса Y будут использоваться классами Z,K,C, то не вижу причин, почему нельзя все это протестировать еще до полной интеграции системы. Как раз проблемы, характерные для multi-thread приложений, тут отлавливаются на раз, как и многое другое. У меня как раз есть положительный опыт подобной игры в кубики, после которой из этих кубиков собиралось нечто, в чем тестеры долго пытались хотя бы один баг найти. Правда, там не было GUI
L>>Вопрос еще и в том, что и когда считать юнитом
АК>Ну в некоторых технологиях юнит-тестирования это четко оговорено. Посмотрите на JUnit — классический пример подхода к юнит-тестированию. Или я не прав?
CPPUnit — в принципе, то же самое. Однако кто ж запрещает слегка его изменить, и вуаля — мы тестируем модуль, используя другие модули, или загрушки, или эмуляторы, или даже готовое ядро системы. Можно даже не менять, но это опять зависит от архитектуры. В общем, технологии технологиями, но здравый смысл пока рулит

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

NS>Всех желающих на испытательный не возмешь (на испытательном деньги тоже платят), необходимо отсеять лишних.
NS>А по каким критериям отсеивать — тема не раскрыта.
NS>Так что, ИМХО, простой тест или вопросы на общую вменяемость очень даже вариант.
Тут в одном таком тесте, претендующем на звание теста на вменяемость, видел вопрос "В чем основное отличие Unix от Windows?"

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

IS>>ничего ты не указал. когда ТЕБЕ ПОКАЗАЛИ что виртуальным наследованием не пользуются подавляющее большинство разработчиков, а добрая половина ВООБЩЕ НИКОГДА ничего виртуально не наследовала ты не нашел ничего лучшего чем попытаться увести разговор в сторону.

ГВ>Йо! Что-то я никакой статистики не увидел.

Плохо что не увидел — придется собирать : встань из-за стола — поспрашивай тех, кто сидит рядом с тобой. Позвони тем с кем работал на прошлых проектах/компаниях.

IS>>а теперь внимание вопрос: линейкой из какого железа следует бить по пальцам людей, которые используют этот тип наследования в большом проекте? Хинт — большой проект подразумевает:

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

ГВ>А взять книжку почитать им недосуг?
А зачем ?

IS>>2.большое время жизни проекта, только усугубляющее положение средних разработчиков из п.1, и как следствие положение самого проекта (большой проект — он ведь держится на средних разработчиках).

ГВ>Проект всё тянется и тянется, а книжку всё недосуг и недосуг. Аврал, что ли, бесконечный?

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

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

C>Да вот как теперь называются разработчики которые не знают тонкостей языка

Добро пожаловать в 21-й век.

C>Куда катится мир.

Уже прикатился.

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

ГВ>Всё равно не понятно. Имеем два типа:

читай про обобщенное программирование

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

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

C>>Да вот как теперь называются разработчики которые не знают тонкостей языка

IS>Добро пожаловать в 21-й век.

21-й век где индийские и китайские программисты захватывают рынок. Когда 10 китайцев за чашку риса будут делать твою работу, я думаю придется открыть книжку и начать изучать тонкости. Потому-что тот уровень на который ты опускаешь наших средних программистов — это уровень малообразованного индийца.


C>>Куда катится мир.

IS>Уже прикатился.

К счастью пока нет, раз "средний" разработчик у нас еще работает за деньги а не за еду.

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

IS>Здравствуйте, Геннадий Васильев, Вы писали:

IS>>>ничего ты не указал. когда ТЕБЕ ПОКАЗАЛИ что виртуальным наследованием не пользуются подавляющее большинство разработчиков, а добрая половина ВООБЩЕ НИКОГДА ничего виртуально не наследовала ты не нашел ничего лучшего чем попытаться увести разговор в сторону.

ГВ>>Йо! Что-то я никакой статистики не увидел.

IS>Плохо что не увидел — придется собирать : встань из-за стола — поспрашивай тех, кто сидит рядом с тобой. Позвони тем с кем работал на прошлых проектах/компаниях.

IS>>>а теперь внимание вопрос: линейкой из какого железа следует бить по пальцам людей, которые используют этот тип наследования в большом проекте? Хинт — большой проект подразумевает:

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

ГВ>>А взять книжку почитать им недосуг?
IS>А зачем ?

Чтобы развивать свой мыслительный аппарат и поднимать свой профессиональный уровень.

IS>>>2.большое время жизни проекта, только усугубляющее положение средних разработчиков из п.1, и как следствие положение самого проекта (большой проект — он ведь держится на средних разработчиках).

ГВ>>Проект всё тянется и тянется, а книжку всё недосуг и недосуг. Аврал, что ли, бесконечный?

IS>Про книжку — я тебе выше написал. Дело не в авралах — дело в желании изучать ненужное.

Дело в нежелании изучать нужное!

IS>Взрослым людям это просто неинтересно.

Взрослых людей очень много, не стоит говорить за всех.

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

IS>>Добро пожаловать в 21-й век.

C>21-й век где индийские и китайские программисты захватывают рынок. Когда 10 китайцев за чашку риса будут делать твою работу, я думаю придется открыть книжку и начать изучать тонкости. Потому-что тот уровень на который ты опускаешь наших средних программистов — это уровень малообразованного индийца.

Давай-ка покажи где я "опускал ваших средних программистов " и я посмотрю стоит тебе отвечать или нет.