Есть Earworms (но это с английского на другие языки) — весьма ок,
на ютубе очень много песенок для детей начального уровня, можно искать, например, «super simple learning»
> для среднестатистического трудящегося человека это всё неактуально
На самом деле, актуально в особенности для них.
«Кто везет — на том и едут», в любом более-менее большом коллективе возникают хитрецы, которые пытаются переложить на вас свою работу и напоручать всяких бесполезных для вашей зарплаты и карьерных перспектив задач и очень часто они вам даже не начальство.
И таки у вас выбор — быть все время в мыле и заваливать важные для вас задачи (прямые обязанности или связанные с вашими целями) или слать всё что не связано с обязанностями и целями нафиг и греться в лучах славы какой вы офигенный в скорости и качестве выполнения задач для которых вы наняты.
Если смотреть рост стоимости в деньгах, скорость/масштаба переделки проектов (фликра и проч), рост посещаемости — то у яху дела идут в гору с момента, когда было сделано такое решение.
Судя по бложику, он публично выступает, коучит, консультирует и прочий путь бизнес-тренера.
Т.е. вполне себе полноценная работа — создать себе бренд как консультанта и этот бренд монетизировать.
Ну и метрика продуктивности может быть, например, очень простая — сравнить через X времени, сколько зарабатывают те, кто таки устроился на те отличные предложения, и сколько зарабатывает автор.
Вообще говоря, это один из основных моментов многих техник тай-менеджмента — все задачи всё равно никогда не переделаешь, поэтому не приносящие пользы надо распознать и выкинуть.
Теперь представим, что в этой компании — один-два-три человека с принципиальным неприятием к алкоголю или медицинскими противопоказаниями к нему — и начинается гниль, кто с боссом не пьет, считает что ему не добавили денег не потому что код не очень, а потому что он не пьет, кто пьет — в недоумении, как же так, он всей душой тут, а денег добавили демонстративно отколовшемуся от коллектива и т.п.
Нафиг-нафиг такие тимбидинги (хотя таки есть и люди и даже целые компании у которых совместное распитие — основной критерий выбора места работы).
> то снизить этот оклад просто так нельзя по закону.
В рамках закона нет никакой проблемы сопровождать бумагами все случаи, когда человек «не тянет» и проводить раз в год аттестационную комиссию, которая оформит «не соотвествует», «понизить»
> Будет такая философия, будет компания из 10 человек, которая «13 или 14 занимаемся разработкой всякой фигни, про которую никто не слышал».
Ну таки у кого какие ценности,
часто владельцы/технические руководители таких компаний имеют заметно более высокий уровень потребления и более расслабленный стиль жизни, чем в корпорации руководитель структуры в сотни человек.
Даже модные на этом ресурсе основатели 37Signals в книге Rework именно так и пишут — а зачем нам расти, если у нас обалденный для отрасли показатель выручки на человека (который не отмасштабировать при росте поголовья) и мы всем довольны.
Так смотря что называть имиджевым капиталом,
часто это явные просьбы локальных администраций «уважаемое предприятие, дайте денег вот этим и этим, а мы вам не будем мешать там и там, или даже поможем» и инициатива предприятий «дорогая администрация, смотрите какие мы социально ответственные, давайте мы вам напишем ещё и ТЗ для системы, на разработку которой вы тендер устраивать собираетесь»?
Большим бизнесам без этой всей возни часто никак не получается, даже Джобса в городском совете за разрешение на строительство пытались разводить «давайте городу кайфаков, вай-фай всем бесплатно или ещё что-то», и не все такие крутые, чтобы это пресекать.
Самое простое и банальное — программисты зачастую слабы в навыках «торговаться», «убеждать» (если бы они были сильны — они бы сделали бы намного более выгодную карьеру в продажах металлопроката, например).
И они уже сталкивались с тем, что при попытке заикнуться, что реализовать можно, но это потребует такого-то времени (ради которого придется двигать другие задачи, которые уже на них) или других ресурсов, ими нещадно манипулировали, впихивая задачу до кучи к имеющимся,
приходилось работать ночами и выходными, а потом получать лишение премии или неласковые слова за низкое качество, срыв сроков и завал не только этой задачи, но и остальных.
Т.е. они опытным путем пришли к тому, что тупо идти в отказ («невозможно») — более выигрышная стратегия, позволяющая не заколебаться и выпускать свои задачи в срок и с годным качеством.
И это не обязательно проблема в вашем менеджменте, могут быть и последствия травмы полученной у предыдущего работодателя.
Очень часто это чувство стабильности — ложное, разработчиков запросто отправляют на сокращение при кризисе, реорганизации конторы (централизуя разработку в один город и не ваш), смене собственников и т.п.
При этом у очень многих велик соблазн ничего нового не воспринимать и не пытаться, а окопаться на своем десятилетнем говнокоде, который уже сгнил настолько, что его развивать никто не сможет.
Как по мне, так лучшее чувство стабильности дает запас кеша, знание людей в других компаниях и постоянное изучение актуальных технологий, которое позволит выйти на новое место в течении недели-двух.
Я видел людей со «стабильными рабочими местами», которых отправили на помоечку с их большими проектами на дельфи 3 и фокспро. Общаясь с теми кто давно в полиграфической отрасли, я наслышан о множестве тех, кто не осилил перейти с наборных столов на софт для верстки и так же пошел на помоечку (несмотря на работу в крупной и стабильной компании).
Есть люд, который прется от челленджей и решения задач на пределе своих возможностей,
и есть люд, у которого единственная ценность — «чтоб не трогали» и чтобы встать с рабочего кресла ровно в пять вечера.
Вторых в штуках больше (особенно в гос. и крупных компаниях), но я бы не стал их ценности равнять с ценностями вообще всех представителей отрасли.
Потому что последовательное следования практикам, изложенным в материалах вендора/книжке именитого автора экономит время ваше и тех кто через 5 лет после вас будет переделывать/поддерживать вашу систему при сохранении годного результата.
Т.е. это как следовать руководству по эксплуатации технически сложного прибора, например.
Это больше говорит о проектах, в которых вы заняты, чем о том, что знать как устроен GC не нужно.
Разработчики stackowerflow (думаю, вам как шарперу, такой пример ближе), например, на конференциях рассказывают, что с ростом посещаемости были сильно поражены тому, как сильно удалось расширяться не за счет введения в строй новых серверов, а за счет переписывания кода с учетом работы GC.
Разработчики twitter — аналогично, можно найти много их выступлений о тюнинге JVM.
Про Дойчебанк тоже есть информация, что они обучают своих разработчиков занятых на low latency системах как писать код, чтобы минимизировать использование GC
Да, лучше было бы упомянуть AMD Am5x86, Cyrix Cx5x86, IBM 5x86 и похоже именованные модели постарше и помладше от этих и других производителей.
Они были реально очень распространены (первые два — даже в отечественной рознице, с ценой заметно ниже интеловских).
Очень интересует «Причина № 6», есть ли данные о том, столько программистов работают над созданием Java-интерактива дисков и какие диски приобрести, чтобы сильнее впечатлиться работой этих программистов.
на ютубе очень много песенок для детей начального уровня, можно искать, например, «super simple learning»
На самом деле, актуально в особенности для них.
«Кто везет — на том и едут», в любом более-менее большом коллективе возникают хитрецы, которые пытаются переложить на вас свою работу и напоручать всяких бесполезных для вашей зарплаты и карьерных перспектив задач и очень часто они вам даже не начальство.
И таки у вас выбор — быть все время в мыле и заваливать важные для вас задачи (прямые обязанности или связанные с вашими целями) или слать всё что не связано с обязанностями и целями нафиг и греться в лучах славы какой вы офигенный в скорости и качестве выполнения задач для которых вы наняты.
Т.е. вполне себе полноценная работа — создать себе бренд как консультанта и этот бренд монетизировать.
Ну и метрика продуктивности может быть, например, очень простая — сравнить через X времени, сколько зарабатывают те, кто таки устроился на те отличные предложения, и сколько зарабатывает автор.
Вообще говоря, это один из основных моментов многих техник тай-менеджмента — все задачи всё равно никогда не переделаешь, поэтому не приносящие пользы надо распознать и выкинуть.
Нафиг-нафиг такие тимбидинги (хотя таки есть и люди и даже целые компании у которых совместное распитие — основной критерий выбора места работы).
В рамках закона нет никакой проблемы сопровождать бумагами все случаи, когда человек «не тянет» и проводить раз в год аттестационную комиссию, которая оформит «не соотвествует», «понизить»
Ну таки у кого какие ценности,
часто владельцы/технические руководители таких компаний имеют заметно более высокий уровень потребления и более расслабленный стиль жизни, чем в корпорации руководитель структуры в сотни человек.
Даже модные на этом ресурсе основатели 37Signals в книге Rework именно так и пишут — а зачем нам расти, если у нас обалденный для отрасли показатель выручки на человека (который не отмасштабировать при росте поголовья) и мы всем довольны.
часто это явные просьбы локальных администраций «уважаемое предприятие, дайте денег вот этим и этим, а мы вам не будем мешать там и там, или даже поможем» и инициатива предприятий «дорогая администрация, смотрите какие мы социально ответственные, давайте мы вам напишем ещё и ТЗ для системы, на разработку которой вы тендер устраивать собираетесь»?
Большим бизнесам без этой всей возни часто никак не получается, даже Джобса в городском совете за разрешение на строительство пытались разводить «давайте городу кайфаков, вай-фай всем бесплатно или ещё что-то», и не все такие крутые, чтобы это пресекать.
Самое простое и банальное — программисты зачастую слабы в навыках «торговаться», «убеждать» (если бы они были сильны — они бы сделали бы намного более выгодную карьеру в продажах металлопроката, например).
И они уже сталкивались с тем, что при попытке заикнуться, что реализовать можно, но это потребует такого-то времени (ради которого придется двигать другие задачи, которые уже на них) или других ресурсов, ими нещадно манипулировали, впихивая задачу до кучи к имеющимся,
приходилось работать ночами и выходными, а потом получать лишение премии или неласковые слова за низкое качество, срыв сроков и завал не только этой задачи, но и остальных.
Т.е. они опытным путем пришли к тому, что тупо идти в отказ («невозможно») — более выигрышная стратегия, позволяющая не заколебаться и выпускать свои задачи в срок и с годным качеством.
И это не обязательно проблема в вашем менеджменте, могут быть и последствия травмы полученной у предыдущего работодателя.
При этом у очень многих велик соблазн ничего нового не воспринимать и не пытаться, а окопаться на своем десятилетнем говнокоде, который уже сгнил настолько, что его развивать никто не сможет.
Как по мне, так лучшее чувство стабильности дает запас кеша, знание людей в других компаниях и постоянное изучение актуальных технологий, которое позволит выйти на новое место в течении недели-двух.
Я видел людей со «стабильными рабочими местами», которых отправили на помоечку с их большими проектами на дельфи 3 и фокспро. Общаясь с теми кто давно в полиграфической отрасли, я наслышан о множестве тех, кто не осилил перейти с наборных столов на софт для верстки и так же пошел на помоечку (несмотря на работу в крупной и стабильной компании).
и есть люд, у которого единственная ценность — «чтоб не трогали» и чтобы встать с рабочего кресла ровно в пять вечера.
Вторых в штуках больше (особенно в гос. и крупных компаниях), но я бы не стал их ценности равнять с ценностями вообще всех представителей отрасли.
Т.е. это как следовать руководству по эксплуатации технически сложного прибора, например.
Разработчики stackowerflow (думаю, вам как шарперу, такой пример ближе), например, на конференциях рассказывают, что с ростом посещаемости были сильно поражены тому, как сильно удалось расширяться не за счет введения в строй новых серверов, а за счет переписывания кода с учетом работы GC.
Разработчики twitter — аналогично, можно найти много их выступлений о тюнинге JVM.
Про Дойчебанк тоже есть информация, что они обучают своих разработчиков занятых на low latency системах как писать код, чтобы минимизировать использование GC
Они были реально очень распространены (первые два — даже в отечественной рознице, с ценой заметно ниже интеловских).