Комментарии 148
НЛО прилетело и опубликовало эту надпись здесь
Ну, можно копнуть глубже.
Год 1965, Генрих Альтшуллер: «Идеальная машина — это машина, функции которой выполняются, а размеры и масса стремятся к нулю.»
Год 1965, Генрих Альтшуллер: «Идеальная машина — это машина, функции которой выполняются, а размеры и масса стремятся к нулю.»
Можно еще глубже:
Сунь Цзы, «Искусство войны», приблизительно 380—325 годы до н. э.
Одержать сто побед в ста битвах — это не вершина воинского искусства. Повергнуть врага без сражения — вот вершина.
Сунь Цзы, «Искусство войны», приблизительно 380—325 годы до н. э.
Ждать на берегу реки, что ли?
Стояние на реке Угре, например, почти(а может и не почти) эталонная победа почти(попытки переправы отбивали в малых стычках) без фактического сражения основных сил. Причём победа там прям стратегического значения вышла.
Красивый эпизод, аж зачитался. Однако, вики пишет что тактическим достижением является в т.ч. «удавшаяся попытка Ивана III избежать военного столкновения, в котором не было ни военной, ни политической необходимости — Орда была сильно ослаблена, её дни как государства были сочтены.»
Это часть правды, которую знают все…
Мало кто, однако, слышал полную версию: пока большие армии стояли на Угре, строили друг другу рожи и показывалижопы неприличные жесты,
небольшой (сравнительно) русский отряд устроил рейд на Крым и сжёг к чертям дома тех самых хановых стояльцев.
По возвращению ихочень вежливо спросили — где вас шайтан носил?
Мало кто, однако, слышал полную версию: пока большие армии стояли на Угре, строили друг другу рожи и показывали
небольшой (сравнительно) русский отряд устроил рейд на Крым и сжёг к чертям дома тех самых хановых стояльцев.
По возвращению их
Не ждать, а использовать иные способы
В российской культуре традиционное китайское понятие недеяния почему-то традиционно понимается неправильно.
Недеяние — это не лень и бездействие, это направление событий в нужную сторону минимальным вмешательством, т.е. как можно большее их приближение к естественному ходу событий.
Недеяние — это не лень и бездействие, это направление событий в нужную сторону минимальным вмешательством, т.е. как можно большее их приближение к естественному ходу событий.
Цель развития любого механизма — мгновенный профит абсолютно без затрат.
Читал "Искусство войны". Оказывается, переводов этой книги довольно много, и каждый немного по-разному формулирует мысли автора. Даже если и правильно переведено, то всё равно для понимания многого приходится смотреть дополнительные комментарии и разъяснения. К слову, в той книге, что я читал, эти разъяснения были примерно того же объёма, как и сам текст книги...
Так о чём это я хотел сказать - а, "Повергнуть врага без сражения" - я читал "Избежать битвы". Но суть конечно остаётся одна, сделать так, чтобы "сражения" не было вовсе, и достичь цели.
Интересно, что такие идеальные "машины" иногда возможны: Бесконечно выгодная программа
Автор немного заработал на программе, у которой размер 0 байт.
спрашивали меня, чтобы узнать, как и зачем я скрываю размер программы (DIR ведь выдавал, что в ней 0 байт). Когда я рассказывал им, что программа действительно занимает 0 байт, некоторые начинали возмущаться: «Как вы смеете брать 5 фунтов ни за что?!» Я отвечал, что они неправы: ведь они же получили полезную вещь взамен.
Я постоянно говорю и подчиненным и начальству — основная функция архитектора, менеджера продукта или проекта не «что (как) делать» — а «что не делать».
Если ссылка на манифест против эджайл под рукой - присоедините, пожалуйста.
Вообще-то в статье шла речь о «манифесте Аджайл» против корпоративной бюрократии. К сожалению, Аджайл — точнее некоторые здравые идеи, высказанные авторами — был «прожеван и сьеден» этой самой бюрократией и консультантами от нее кормящимися. А продукт их жизнедеятельности — это действительно карго-культ, в котором от первоначальной идеи осталось чуть более чем ничего. Зато ко всем обязанностям работников добавилось участие в этих бессмысленных ритуалах — в некоторых компаниях доходящее до 10% рабочего времени.
НЛО прилетело и опубликовало эту надпись здесь
Разумеется. Но чаще всего, как минимум в корпоративном мире — делают наоборот. Стенд-ап в 9 часов (не потому, что так удобно команде — а потому что начальство решило), итерации в 2 недели «потому что все так делают», 3-5 незаконченных story к концу итерации потому что надо «готовить демо» и так далее. И 20+ обязательных полей на каждый story/task в JIRA, причем описание и DoD в их число не входят ;)
у вас конечно же есть решение проблемы? как надо делать? не делать стенд-ап? сделать итерацию не 2 недели- а сколько? каждый раз разное количество дней? комитнулся сделать таски и не закончил их- скрам мастер?
Что касается полей- согласен — тут прямо заболевание какое-то у людей, потом через год спрашиваешь — ну и какого хера мы эти поля заполняли- где они используются?
Что касается полей- согласен — тут прямо заболевание какое-то у людей, потом через год спрашиваешь — ну и какого хера мы эти поля заполняли- где они используются?
Да. Стенд-ап это не отчет перед начальством, и делать его надо когда решит команда (в том числе и не делать, если нет нужды).
Итерации — можно и день и месяц, в зависимости от того, над чем вы работаете. Если груминг, демо, ретроспектива и прочие ритуалы занимают больше времени чем сама работа — что-то у вас идет не так.
Команда должна максимизировать количество законченных историй — если все не успевают, надо что-то отставить в сторону - а освободившегося человека направить на завершение более приоритетных задач. 2 готовых истории гораздо полезнее 4х «почти» законченных. Разумеется, на ретроспективе произошедшее надо анализировать и в следующей итерации делать что-то по-другому. И «оркестрация» всего этого между продукт-, проджект- и прочими менеджерами и командой — прямая обязанность скрам-мастера.
Итерации — можно и день и месяц, в зависимости от того, над чем вы работаете. Если груминг, демо, ретроспектива и прочие ритуалы занимают больше времени чем сама работа — что-то у вас идет не так.
Команда должна максимизировать количество законченных историй — если все не успевают, надо что-то отставить в сторону - а освободившегося человека направить на завершение более приоритетных задач. 2 готовых истории гораздо полезнее 4х «почти» законченных. Разумеется, на ретроспективе произошедшее надо анализировать и в следующей итерации делать что-то по-другому. И «оркестрация» всего этого между продукт-, проджект- и прочими менеджерами и командой — прямая обязанность скрам-мастера.
общие фразы и я могу говорить.
Стендап никогда и не был отчетом. Я тоже не сторонник стендапов в 9 — тупо потому что все будут опаздывать. Но часто складывается ситуация что в 10 не может менеджер, в 11 не может тимлид, а в 12 у 3 человек английский. А синхронизироватся нужно, это же всем понятно. И если получается только в 9-00 то так тому и быть, это работа а не кружок филателистов. Другой вопрос, что если всем удобнее — можно и в 10 вечера эти стендапы несчастные проводить.
Что касается итераций- в среднем реально 2 недели проще и накладные расходы меньше(1 ретроспектива раз в две недели) и не забывается что было сделано(можно вспомнить и рассказать что хорошо сделано, а что было не так). Так же обычно за 2 недели обычной командой в 10+- человек выкатывается количество изменений которое можно безболезненно зарелизить(хотя тут конечно сова на глобусе, но общий смысл такой).
Сколько я не видел попыток изобрести свой размер спринта- все обычно заканчивалось или невероятным количеством накладных расходов(читай митингов) — если спринт слишком короткий, или постоянными внеплановыми релизами- потому что спринт месяц, а фичи нужны быстрее чем через месяц.
Что касается 2 законченных историй которые лучше 4 незаконченных — так это же не скрам мастер или заказчик бил себя в грудь пяткой и кричал что сделает их. Это не про скрам, не про аджайл или не про коммунизм — это про неспособность людей реально оценивать свои силы. И к сожалению отсутствие должного контроля за этим со стороны менеджмента, если хотите наказания виновных- не обязательно расстрелом, но можно особо упоротым не разрешать брать больше одной задачи на спринт.
Стендап никогда и не был отчетом. Я тоже не сторонник стендапов в 9 — тупо потому что все будут опаздывать. Но часто складывается ситуация что в 10 не может менеджер, в 11 не может тимлид, а в 12 у 3 человек английский. А синхронизироватся нужно, это же всем понятно. И если получается только в 9-00 то так тому и быть, это работа а не кружок филателистов. Другой вопрос, что если всем удобнее — можно и в 10 вечера эти стендапы несчастные проводить.
Что касается итераций- в среднем реально 2 недели проще и накладные расходы меньше(1 ретроспектива раз в две недели) и не забывается что было сделано(можно вспомнить и рассказать что хорошо сделано, а что было не так). Так же обычно за 2 недели обычной командой в 10+- человек выкатывается количество изменений которое можно безболезненно зарелизить(хотя тут конечно сова на глобусе, но общий смысл такой).
Сколько я не видел попыток изобрести свой размер спринта- все обычно заканчивалось или невероятным количеством накладных расходов(читай митингов) — если спринт слишком короткий, или постоянными внеплановыми релизами- потому что спринт месяц, а фичи нужны быстрее чем через месяц.
Что касается 2 законченных историй которые лучше 4 незаконченных — так это же не скрам мастер или заказчик бил себя в грудь пяткой и кричал что сделает их. Это не про скрам, не про аджайл или не про коммунизм — это про неспособность людей реально оценивать свои силы. И к сожалению отсутствие должного контроля за этим со стороны менеджмента, если хотите наказания виновных- не обязательно расстрелом, но можно особо упоротым не разрешать брать больше одной задачи на спринт.
Зачем вы все время пытаетесь запихать менеджеров в Аджайл? Методологию, ставящую во главу угла самоуправляемую команду? Если стендап зависит от присутствия менеджера — то это не стендап, а отчет. Если вы ждете от менеджера чтобы он/а следили за оценками задач и дрючили за несоответствия — то это не команда.
На ретроспективе прежде всего должен обсуждаться фактор каждой задачи/каждого участника — почему и насколько время ее выполнения не совпало с оценкой. И если условный Вася все вроде бы сделал вовремя, но его вздрючили на код-ревью, а потом интеграция его кода заняла два дня — то его персональный фактор будет 2.0, и задача команды — напомнить Васе на планировании следующего спринта чтобы он свои оценки на этот фактор помножил. И на следующей ретроспективе фактор Васи должен стать ближе к 1.0 — иначе вы что-то делаете совсем не так.
А когда команда научится реально оценивать свою производительность — можно переходить и к оптимизации.
На ретроспективе прежде всего должен обсуждаться фактор каждой задачи/каждого участника — почему и насколько время ее выполнения не совпало с оценкой. И если условный Вася все вроде бы сделал вовремя, но его вздрючили на код-ревью, а потом интеграция его кода заняла два дня — то его персональный фактор будет 2.0, и задача команды — напомнить Васе на планировании следующего спринта чтобы он свои оценки на этот фактор помножил. И на следующей ретроспективе фактор Васи должен стать ближе к 1.0 — иначе вы что-то делаете совсем не так.
А когда команда научится реально оценивать свою производительность — можно переходить и к оптимизации.
видите ли в чем дело, что то в наших условиях сферический скрам мастер не работает, если он не обличен властью. Менеджера хотя бы слушают, а когда приходит специально выделенный скрам мастер и начинает жужать про коэффицент 2.0 — то самое вежливое что сделает разработчик- это промолчит. А если кто-то начнет намекать про это самое на ретроспективе, то если этот разработчик чуть старше мидла- он сам найдет что припомнить, и вздрючит на следующем код ревью, тех кто слишком много умничал в прошлый раз.
Так зачем вы называете это скрамом?
Что ЭТО?
Отношения между людьми внезапно тоже оказываются важны. И да все работают по какому-то процессу. Моя ремарка была про то что менеджер вполне себе может быть и членом команды если он чтото делает для всех, и скрам мастером может быть если у него задач других нет, а члены команды недостаточно опытны.
до 10% рабочего времени.
1. Каждый день — дейли. 1 час из 8. 12% рабочего времени
2. Ретро раз в неделю. До 2 часов из 8. 5% рабочего времени.
3. Груминг и взятия задач в спринт. До 2 часов из 8. 5% рабочего времени.
Были еще другие встречи, но я на них не ходил. 22% рабочего времени уходило на встречи :)
Теперь вспоминаем, что человек может быть полезен примерно 50% времени, из которых 22% он уже «отбыл» на ритуалах. Остается 28% рабочего времени :)
Итог: смотри п.1 из статьи.
НЛО прилетело и опубликовало эту надпись здесь
Вопрос не в ритуалах. Если у команды нет самостоятельности и ответственности, нет доступа к заказчику или людям определяющим стратегию, компания не «дрючит» за отсутствие четких описаний задач и definition-of-done — какие ритуалы не делай, ничего не поможет. И наоборот — если все это присутствует, ритуалы имеют свойство резко сокращаться по времени и частоте.
Дейли в 1 час — это жестко. Больше я видел только в Штатах в полностью «индийской» команде. Хорошо, что в офисе была «пещера» — куда мы с самым толковым их джуниором и переехали, за полтора следующих рабочих дня «починив» все то, с чем команда не могла справиться месяц.
Дейли в 1 час — это жестко
К сожалению, видел и больше… На начальной стадии проекта всё хорошо, приходят PM и разработчики, 5-10 минут и все свободны.
В середине проекта добавляются тестировщики, начинается обсуждение багов прямо на дейли, митинг растягивается на 30-40 минут.
Для починки багов набирают контракторов. Ход проекта начинает контролировать менеджер более высокого уровня.
В итоге на дейли 15 человек, каждый занимает 5-10 минут времени…
Я однажды участвовал в конфколле на 3+ дня )
А можно подробнее про пещеру — как решалось, кто мог туда переехать и какие права она давала?
Пещера — это переоборудованная переговорка, с отсутствующей телекоммуникацией и непрозрачной перегородкой посредине стола (так что сидя, вы не видите сидящих напротив).
«Переехать» туда можно было по принципу наличия свободного места. В «пещере» нельзя разговаривать, а находящимся снаружи — звать и отвлекать находящихся внутри. Общение только по IM/e-mail.
Длительность нахождения в пещере вроде как не лимитировалась — во всяком случае меня никто ни о чем не спрашивал.
Кстати, в офисе была и противоположная крайность — несколько хитровыдуманных велосипедов (3-4 колесных), на которых можно было медленно ездить по коридорам. Очень помогало когда упираешься во что-то и начинаешь тупить — пару кругов и как рукой снимает.
«Переехать» туда можно было по принципу наличия свободного места. В «пещере» нельзя разговаривать, а находящимся снаружи — звать и отвлекать находящихся внутри. Общение только по IM/e-mail.
Длительность нахождения в пещере вроде как не лимитировалась — во всяком случае меня никто ни о чем не спрашивал.
Кстати, в офисе была и противоположная крайность — несколько хитровыдуманных велосипедов (3-4 колесных), на которых можно было медленно ездить по коридорам. Очень помогало когда упираешься во что-то и начинаешь тупить — пару кругов и как рукой снимает.
Я был в разных компаниях по разные стороны этих ритуалов (и как тот, кто на них ходил, и как тот, кто их собирал). Поэтому могут попробовать чуть более объективно рассказать, зачем это все.
Дейли, с точки зрения, рядового разраба — вещи, обычно, бесполезная. Ходишь там, рассказываешь что-то, время тратишь. В реальности же это довольно эффективный инструмент по предотвращению отправления срока задач в космос, причем, по нескольким причинам:
1) человек делает не то, что нужно
2) человек застрял, пытается разобраться сам, но капает не туда и не спрашивает
3) задача оказалась сильно сложнее, поэтому ее вообще можно отложить
Если речь идет не о ведущих разработчиках, а о рядовых копателях, то ситуации 1 и 2 стреляют очень часто. Руководитель зачастую не может (да ему и не нужно) постоянно всех мониторить, потому что и других дел хватает. Так что дейли помогает разрулить такие вопросы. Но час, конечно, много, мы всегда укладывались в 15-30 минут (команды до 10 человек), в деталях проблемы/вопросы решали уже отдельно.
Ретро. Это полезная штука, чтобы все понимали, что было сделано на 1-2-n недель. Без них часто бывает, что коллеги даже не знают, что там напилил их сосед.
Груминг и взятия задач. Опять же, у некоторых людей может быть особое виденье задач, какие-то тайные знания, почему нужно делать так или вообще лучше не делать. Так же, кто-то может захотеть взять именно эту задачу, потому что ему интересно или есть какие-то идеи. 30 минут такой встречи могут сократить дни разработки.
Тратить 100% времени чисто на разработку можно только в компаниях, где ты работаешь один, держишь все в голове, и тебе ни с кем не надо что-то согласовывать. Как только компания становится большой, сразу тратится приличная доля времени на синхронизацию — это абсолютно нормальный процесс.
Дейли, с точки зрения, рядового разраба — вещи, обычно, бесполезная. Ходишь там, рассказываешь что-то, время тратишь. В реальности же это довольно эффективный инструмент по предотвращению отправления срока задач в космос, причем, по нескольким причинам:
1) человек делает не то, что нужно
2) человек застрял, пытается разобраться сам, но капает не туда и не спрашивает
3) задача оказалась сильно сложнее, поэтому ее вообще можно отложить
Если речь идет не о ведущих разработчиках, а о рядовых копателях, то ситуации 1 и 2 стреляют очень часто. Руководитель зачастую не может (да ему и не нужно) постоянно всех мониторить, потому что и других дел хватает. Так что дейли помогает разрулить такие вопросы. Но час, конечно, много, мы всегда укладывались в 15-30 минут (команды до 10 человек), в деталях проблемы/вопросы решали уже отдельно.
Ретро. Это полезная штука, чтобы все понимали, что было сделано на 1-2-n недель. Без них часто бывает, что коллеги даже не знают, что там напилил их сосед.
Груминг и взятия задач. Опять же, у некоторых людей может быть особое виденье задач, какие-то тайные знания, почему нужно делать так или вообще лучше не делать. Так же, кто-то может захотеть взять именно эту задачу, потому что ему интересно или есть какие-то идеи. 30 минут такой встречи могут сократить дни разработки.
Тратить 100% времени чисто на разработку можно только в компаниях, где ты работаешь один, держишь все в голове, и тебе ни с кем не надо что-то согласовывать. Как только компания становится большой, сразу тратится приличная доля времени на синхронизацию — это абсолютно нормальный процесс.
Руководителю на дейли делать нечего — пускай в Джиру смотрит. Тогда и разрабы не будут стесняться просить помощи у коллег или указывать им на какие-то открывшиеся аспекты.
Ретро вообще не об этом — для понимания что сделано есть демо. Ретро служит для анализа работы команды по двум направлениям — а. что мешало/пошло не так и как это исправить б. насколько оценки разошлись с реальностью (неважно по каким причинам). Одна из целей скрам — научиться точно оценивать сроки выполнения тех или иных задач, причем не до «на моем компьютере работает» — а до релиза в продакшен. Если вы оценили что-то в 3 дня, а заняло оно 5 — то нужно научиться умножать первоначальную оценку на 1.7.
Ретро вообще не об этом — для понимания что сделано есть демо. Ретро служит для анализа работы команды по двум направлениям — а. что мешало/пошло не так и как это исправить б. насколько оценки разошлись с реальностью (неважно по каким причинам). Одна из целей скрам — научиться точно оценивать сроки выполнения тех или иных задач, причем не до «на моем компьютере работает» — а до релиза в продакшен. Если вы оценили что-то в 3 дня, а заняло оно 5 — то нужно научиться умножать первоначальную оценку на 1.7.
ИМХО, математика у вас неправильная.
Это получится 12% + 1% + 1%, поскольку недельные надо делить на пять.
На самом деле дейли в нормальных местах это 10-15 минут.
Это получится 12% + 1% + 1%, поскольку недельные надо делить на пять.
На самом деле дейли в нормальных местах это 10-15 минут.
А прикладную математику-то за что?
За оторванность от суровой реальности, очевидно :)
Потому, что выпускник ФПМ — это в первую очередь математик (пусть и прикладной), а только во вторую программист. Сейчас разница между этими профессиями уже слишком велика, чтобы её игнорировать.
НЛО прилетело и опубликовало эту надпись здесь
Не думаю, что отличия в содержании образовательных курсов создают непреодолимые профессиональные барьеры. Скорее, скажется разница в интересах, мотивации, образе мышления. Люди не просто так идут учиться на математиков, — очевидно, что она им нравится и у них к ней способности. Но в работе программиста математики либо мало, либо ноль (за редким исключением) — это другая профессия с людьми, имеющими другое образование и другие интересы.
НЛО прилетело и опубликовало эту надпись здесь
С математиками ситуация уникальна тем, что есть расхожее заблуждение о едва ли не тождественности математики и программирования. Я неделю назад разговаривал со студентами 3-го курса, которые учатся на программистов и среди них много таких, чьей мотивацией было прикладное применение математики (к которой у них были явные способности в школе). К 3-му курсу эти студенты сильно разочарованы в выбранной профессии программиста, многие уже ушли по собственному желанию, многие через силу учатся до диплома. Они не хотят работать программистами, им не интересно.
Да, это правда. Сейчас принято считать, что ПМ ≡ Computer Science, притом что в ПМ есть масса специализаций, далёких от разработки ПО вообще — от матмоделирования до исследования операций. Человек, к примеру, хочет заниматься матмоделированием — «…а потом эти специалисты по прикладной математике устраиваются работать фронтэндером на галеру и с тоской вспоминают линейную алгебру» .
НЛО прилетело и опубликовало эту надпись здесь
… если математикам не интересно в программирование, значит пойдут в дата сатанисты. welcome :)
Смотря какой программист. Если разработка ПО для беспилотников — то там почти вся программа состоит из математики.
нужно разводить математику и код. математик делает модель. программист ее преобразует в код. для того, чтобы алгоритмизировать математическую модель саму математику знать необязательно.
Для того, чтобы алгоритмизировать математическую модель, математику не нужен программист. Он и сам способен развернуть циклы и вписать в них формулы.
имхо, каждый должен заниматься своим делом. я работал с прикладными математиками-программистами. основная проблема: отсутствие понимания, как код ляжет на железо. причем к работоспособности кода вопросов не было, вопросы были по эффективности. поэтому для нагруженных систем и систем, критичных к ресурсам математику и кодирование лучше развести.
Во-во, периодически с этим сталкивался — сначала алгоритм поднимут и оттестируют на матлабе, а потом перетаскивают как есть на какую-нибудь дохлую железяку прямым транслейтом на С. Была ситуация с толстым алгоритмом на флоатах на старом арм процессоре без поддержки плавучки, где конечно ни в какие времянки не укладывались. И один раз среднее значение считали через квадратные корни. Справедливости ради — это все-таки от неопытности в предметной области, после хождений по граблям код становился получше. Но все равно во многих сферах математики и внедряющие нагенеренные алгоритмы программеры — это разные рабочие группы.
И один раз среднее значение считали через квадратные корни
Для несведущих — а в чем тут подводный камень?
Да, непонятно написал. Вопрос в конкретном применении — это очень дорогая операция для большинства камней. Когда нужно выполнять задачу раз в, например, 30 мс, а операция на железе выполняется за 80 мс, то задача не решена. ЕМНИП, в том конкретном случае делали нормализацию аудиосигнала, и достаточно было считать среднее по скользящему окну.
Всем без исключения математикам не дано понять, как код ложится на железо?..
Безусловно, что есть узкие специализации, где математика очень нужна: движки компьютерных игр, 3D-моделирование и визуализация (в медицине, например), военка и т.д. — просто рабочих мест в этих сферах очень мало, там заняты десятые или сотые доли процента всех программистов. Фактически, эти рабочие места можно до нуля округлить.
Что не отменяет того, что нужен программист который умеет писать программы, а не математику. Я собственно занимаюсь именно таким (про математику, не беспилотники), и у меня кровь из глаз идёт когда я вижу код набабаханный математиками (при этом он ещё иногда и работает не правильно).
На факультете Кибернетики КНУ пол потока считаются «прикладной математикой».
Очевидно, что туда идут не потому, что математиком хотят стать.
Просто в классификации и госзаказе ПМ — больше.
Очевидно, что туда идут не потому, что математиком хотят стать.
Просто в классификации и госзаказе ПМ — больше.
Возможно дело не в «трудности», а в «желании» осилить.
НЛО прилетело и опубликовало эту надпись здесь
Тема навевает старый анекдот:
Математик иинженерпрограммист принимают участие в психологическом эксперименте.
Их посадили в с одной стороны комнаты, с другой стороны в комнату зашла обнажённая женщина и встала напротив них. Испытуемых предупредили, что каждые 10 минут, когда они слышат сигнал — они могут пересечь половину расстояния, оставшегося до женщины.
Они слышат первый сигнал, инженер проходит половину
расстояния, а математик, со скучающим видом остаётся сидеть. Когда и
после второго сигнала математик не шевельнулся, инженер
поинтересовался, почему он не идёт.
— Это от того, что я знаю, что никогда не достигну женщину.
Инженер достал калькулятор, что-то минуту считал, а затем сказал:
— Через 1 час 10 минут плюс-минус 20 минут расстояние будет подходящим для
любого практического применения!
Проектирование баз данных?
ЖЦ проектов так и быть, вода, можно выучить просто почитав пару статей на тему.
Архитектура информационных систем? Математикам все эти сложные многозвенные клиент-серверные архитектуры обычно не нужны, и обычно не читают.
Архитектура вычислительных систем?
Сети? Топологии, протоколы, уровни модели OSI, реализации стандартных протоколов?
Практики и подходы к программированию? Математики очень часто пишут лапшу из большой процедуры (ака процедурный подход) и плохо умеют в ООП. Могут уметь зато в функциональщину, но не все.
Уровень со звездочкой: собственные компиляторы?
ЖЦ проектов так и быть, вода, можно выучить просто почитав пару статей на тему.
Архитектура информационных систем? Математикам все эти сложные многозвенные клиент-серверные архитектуры обычно не нужны, и обычно не читают.
Архитектура вычислительных систем?
Сети? Топологии, протоколы, уровни модели OSI, реализации стандартных протоколов?
Практики и подходы к программированию? Математики очень часто пишут лапшу из большой процедуры (ака процедурный подход) и плохо умеют в ООП. Могут уметь зато в функциональщину, но не все.
Уровень со звездочкой: собственные компиляторы?
В дополнение: методологии тестирования, юзабилити, методологии разработки ПО, организация производства (экономика предприятия в приложении к разработке ПО), что-то по интеллектуальной собственности. Этого нет у математиков.
Трудно ли это всё осилить — вопрос отдельный. Если есть список тем — осилить возможно, книжек сейчас масса. Если нет — то могут быть нюансы, например, математик может не подозревать, что меню программы из 25 пунктов одним списком, или 10 диаграмм и 50 кнопок в одном окне — не очень хорошо, тогда как программисту когда-то в одной из дисциплин (или даже не в одной) об этом говорили.
Нужно ли это — иногда нужно.
Проектирование баз данных?
В изложении «для математиков» — это тоненькая брошюрка, благо всякую там теорию множеств они знают, а реляционная алгебра особого разжевывания не требует.
Архитектура вычислительных систем?
Тем, кто занимается численными методами, ее знать надо, остальным — по желанию (да и многие программисты, скажем уж честно, ничего в этом не понимают).
Сети? Топологии, протоколы, уровни модели OSI, реализации стандартных протоколов?
Местами — это чистая математика, всякие там случайные процессы и все такое.
Практики и подходы к программированию?
Осваиваются при необходимости, равно как и " методологии тестирования, юзабилити, методологии разработки ПО, организация производства (экономика предприятия в приложении к разработке ПО), что-то по интеллектуальной собственности" из комментария ниже.
Уровень со звездочкой: собственные компиляторы?
Тут математики больше, чем где-то еще (вот хоть недавний пример с оптимизацией, построенной на теории рекуррентных цепей — habr.com/ru/post/550900 ).
В изложении «для математиков» — это тоненькая брошюрка, благо всякую там теорию множеств они знают, а реляционная алгебра особого разжевывания не требует.
там не только про SQL, но еще и нормальные формы, и ключи (PK/FK), и индексы. Много всякого. Так-то да — теорию множеств, все дела. Некоторые даже в школе проходили! Не мешает им потом дичь вместо баз данных делать.
Местами — это чистая математика, всякие там случайные процессы и все такое.
А кроме математики там еще предметная область. Прикладная, так скажем :) Пакеты, заголовки, запросы-ответы, вот это всё. Спроси у математика, как устанавливается соединение, а потом послушай ответ. Какие запросы идут к серверу. Какие вообще бывают варианты :)
А что вас пугает в нормальных формах? Слова «функциональная зависимость»? Ну это, после университетского курса алгебры или первых глав учебника Зорича по матану бояться перестанете. Индексы? В курсе программирования для математиков про древовидные структуры данных рассказывают, понять B-tree может даже обезьяна.
> Спроси у математика, как устанавливается соединение, а потом послушай ответ.
Ну я пока до пьяных бесед с зеркалом не дорос, могу завтра у коллег поспрашивать — два математика и три физика (1 физфак, 2 физтех) в наличии. Уверен, расскажут много интересного.
> Спроси у математика, как устанавливается соединение, а потом послушай ответ.
Ну я пока до пьяных бесед с зеркалом не дорос, могу завтра у коллег поспрашивать — два математика и три физика (1 физфак, 2 физтех) в наличии. Уверен, расскажут много интересного.
НЛО прилетело и опубликовало эту надпись здесь
?
Этого не было. Ради интереса, а как выглядит программа по этим предметам.
Архитектура вычислительных систем?
А чем это отличается от предыдущего? Или это в смысле всяких машин Тьюринга? Если последнее, то было.
Одно про сложные информационные системы, как они устроены, как работают взаимосвязи между их частями. Где тонкие клиенты, где толстые клиенты. Сервера приложений, сервера баз данных. Двухзвенные, трехзвенные архитектуры. Другие варианты. Вынос и распредление ответственности между функциональными частями информационной системы.
Второе про компьютеры — как устроены, процессоры, шины, ассемблеры (и программирование на ассемблере) и все такое.
Выглядит как обобщение ПМ к одному факультету ФПМ. Для примера в Воронеже факультет ПММ ВГУ выпускает большое количество специалистов которые работают потом программистами. Этот факультет выпускал программистов задолго до того как появились специальности по Computer Since.
ПМ как уже сказали разная. Например Исследованные Операций очень близка к программированию, а функциональный анализ далек.
Из опыта открытия программистами без математики:
— Упрощение условий if на порядки, знания дискретной математики в этих случаях помогают
— Полно непонимание сложности алгоритма что такое P(n) или O(n) для них Chinese kanji
— Слово предикат (функция возвращающая булево значение) что-то странное из SQL
— Оптимизация алгоритмов, не для них. Написать 10-к вложенных циклов это просто так.
— Перед написанием кода сделать план или продумать архитектуру это только для математиков.
Изучение математики, логики и т.д. приводит мышление в определенные рамки которые помогают писать код более понятным и продуманным.
Также полностью согласен что для задач когда нужна не логика, а просто красивый UI, математика не нужна. Например когда надо верстать формочки, аля Delphi накидать компонент на формочки или рисовать UI в очередном JS framework.
ПМ как уже сказали разная. Например Исследованные Операций очень близка к программированию, а функциональный анализ далек.
Из опыта открытия программистами без математики:
— Упрощение условий if на порядки, знания дискретной математики в этих случаях помогают
— Полно непонимание сложности алгоритма что такое P(n) или O(n) для них Chinese kanji
— Слово предикат (функция возвращающая булево значение) что-то странное из SQL
— Оптимизация алгоритмов, не для них. Написать 10-к вложенных циклов это просто так.
— Перед написанием кода сделать план или продумать архитектуру это только для математиков.
Изучение математики, логики и т.д. приводит мышление в определенные рамки которые помогают писать код более понятным и продуманным.
Также полностью согласен что для задач когда нужна не логика, а просто красивый UI, математика не нужна. Например когда надо верстать формочки, аля Delphi накидать компонент на формочки или рисовать UI в очередном JS framework.
>Из опыта открытия программистами без математики:
— Упрощение условий if на порядки, знания дискретной математики в этих случаях помогают
— Полно непонимание сложности алгоритма что такое P(n) или O(n) для них Chinese kanji
— Слово предикат (функция возвращающая булево значение) что-то странное из SQL
— Оптимизация алгоритмов, не для них. Написать 10-к вложенных циклов это просто так.
— Перед написанием кода сделать план или продумать архитектуру это только для математиков.
Это какие-то неправильные программисты. Обычных программистов именно этому учат на первых курсах. И даже "исследование операций" в программе обучения есть, а "функционального анализа" нет.
Вообще у программистов довольно много математических дисциплин *по сравнению с другими техническими специальностями*. На некоторых других специальностях даже дискретную математику из предмета "математика" не выделяют.
Безусловно программисты и математики — это разные люди/позиции. Но если есть время и желание, то математик изучит программирование в части касающейся его интересов и работодателя. Было бы желание. Разница велика в день выпуска из учебного заведения. Спустя пару лет всё меняется. В любом случае редко студенты являются профессионалами во время обучения, всё приходит с опытом.
Всё дело в мышлении, что для математика (прикладного математика) очевидно, для человека окончившего курсы (javascript за 5 минут) китайская грамота.
Т.е. код есть, работает, а для сопровождения нужно искать такого же математика.
<:o)
Т.е. код есть, работает, а для сопровождения нужно искать такого же математика.
<:o)
Не утверждаю, но может быть такое:
Если есть 2 экрана кода, делающего что-то, и нужно внести изменения с определённой даты, то некий человек делает ветвление по дате и копирует эти 2 экрана второй раз. Математически всё чисто, но теперь у нас 4 экрана кода.
Если есть 2 экрана кода, делающего что-то, и нужно внести изменения с определённой даты, то некий человек делает ветвление по дате и копирует эти 2 экрана второй раз. Математически всё чисто, но теперь у нас 4 экрана кода.
Это feature toggle: martinfowler.com/articles/feature-toggles.html
Главное, не забыть потом убрать старый код.
Главное, не забыть потом убрать старый код.
Как то препод сказал нам свое личное наблюдение касательно математиков и программистов:
1) Программист пишет программу так, чтобы она работа (правильно — не правильно, не важно, лишь бы работала, даже если изначально им даются неправильное и нерабочее задание)
2) Математик пишет программу так, как надо, и сдает нерабочую программу, если изначально ему дали нерабочее задание.
ЗЫ. Я прикладной математик если что. :D
1) Программист пишет программу так, чтобы она работа (правильно — не правильно, не важно, лишь бы работала, даже если изначально им даются неправильное и нерабочее задание)
2) Математик пишет программу так, как надо, и сдает нерабочую программу, если изначально ему дали нерабочее задание.
ЗЫ. Я прикладной математик если что. :D
Начнём с того, что это перевод.
Всё правильно написано. Я «старый» разработчик, денег платят хорошо, график гибкий, менеджеры в рот глядят, ждут, когда я что-то умное скажу. Кода я пишу в среднем несколько строк в неделю. Хотел бы, да приходится писать планы, консультировать и так далее. Но с другой стороны — гора технического долга. Подчищаю понемногу, для собственной совести, но гора растёт всё-равно. А в новой компании можно делать то же самое, но без груза прошлых разработок ;)
оо. у Евгения Широкова (экодома каркасно-соломенные) подобные реплики про идеальный умный дом. что умные дома на самом деле сделаны дебильно. куча не дышащего пластика, выпускающего внутрь тысячи вредностей. из которых 50+- научились регистрировать, а остальное наше унылое примитивное оборудование для регистрации них не умеет улавливать и измерять концентрации и тп. дорого и вредно, крч. и кругом насаждаются нездоровые веяния, нездоровая мода, нездоровая промывка по тв с презрением и издёвкой и тп.
и так куда не копни. весь мир как пример неправильного опыта жизни…
и так куда не копни. весь мир как пример неправильного опыта жизни…
Хоть и звучит сей комент немного глупо, но здравое зерно в этом есть, у меня у самого была идея, что было бы круто обойтись без горы электроники, например вроде читал что муравьи вентилируют свои подземные муравейники как-то, плюс есть, все время зыбываю как называется, система вентиляции/охлаждения использующая только ветер, на востоке такие строили.
Всё верно, можете поискать по ключевым словам «Earthship», «Земной корабль». Это как раз направление, где максимально эффективно используются пассивные технологии, заложенные на этапе дизайна и проектирования.
О, нашел - бадгир
Приточно-щелевая вентиляция.
Тащемто, более чем все советские постройки рассчитывали именно на такой тип вентиляции. И на всякий случай еще добавляли во всех инструкциях вплоть до передач в телевидении про здоровый образ жизни — проветривать помещения хотя бы перед сном.
Тащемто, более чем все советские постройки рассчитывали именно на такой тип вентиляции. И на всякий случай еще добавляли во всех инструкциях вплоть до передач в телевидении про здоровый образ жизни — проветривать помещения хотя бы перед сном.
У тайцев что-то похожее в традиционных домах есть. Проблема таких традиционных подходов в том, что крайне сложно найти достоверную информацию, в сети большая часть почти изотерического бреда. Конечно, можно потратить много сил и времени на поиски и проверку информации, но не многие на это готовы, особенно если цель быстро построит дом без заморочек.
ТС, видимо, не имеет никакого диплома, поэтому для него представляют серьезную конкуренцию лица с дипломом о высшем образовании в области прикладной математики (тема негативного отношения не раскрыта). Поскольку для прикладной математики нет ограничений в использовании методов/языков и способов оптимизации для решения поставленной задачи.
С дипломом есть нюанс.
Отдельно от всего синяя или красная картонка с гербом или без, в зависимости от страны и уровня сохраненных знаний есть пшик как и возраст, который иногда отождествляют с опытом.
В году 2005, когда среди вайтишников, те которые уже при галстуке, было стильно, модно, молодежно внедрять всякие аксапты, ораклы, сайбели с парусом и 1С. По отдельности или всё сразу. Удалось мне тогда побывать в АНХ РФ, где товарищи которые ни разу не видели интерфейса данных систем, которые ни разу не управляли промышленным или торговым предприятием, которые ни разу не читали листинг. Рассказывали не краснея как правильно и кошерно покупать сап или аксапту и что 1С это фу-фу-фу, отстой и анахронизм. И даже за это выдавали бумажку которая по тем временам стоила 1500 баксов. И да все люди которые были на тех курсах имели высшее техническое образование и были в должностях руководители ит-департаментов или замы.
Я думаю, тут немного в другом.
"Код, понятный машине, сможет написать каждый - искусство в том, что бы написать код, понятный человеку" (С)
Лучшие программисты которых я видел, это всегда либо математики, либо физики, либо специалисты в иных очень сложных областях (авиаконструкторы, металловеды и т.п.) Они очень хорошо умеют отличать предположения, верования и факты, что позволяет проектировать сложные системы и потом их поддерживать и развивать. Ничего подобного у тех кто просто научился программировать, но матана в жизни не видел, не наблюдается.
Лучшие программисты, которых я видел, это всегда были люди, которые не делали обобщений основываясь на субъективном опыте.
Опыт одного человека или окружения этого человека ни в одной вселенной не может быть релевантным. А делать выводы из этого опыта, больше говорит о человеке, чем его диплом по математической специальности.
Исходя из набора качеств ( отличать верования и факты ), вы видимо не имеете диплом специалиста?
Опыт одного человека или окружения этого человека ни в одной вселенной не может быть релевантным. А делать выводы из этого опыта, больше говорит о человеке, чем его диплом по математической специальности.
Исходя из набора качеств ( отличать верования и факты ), вы видимо не имеете диплом специалиста?
Но релевантность все же детектируется и независимыми наблюдателями.
Программирование, Логика и Математика имеют много точек соприкосновения и областей перекрытия.
Программирование, Логика и Математика имеют много точек соприкосновения и областей перекрытия.
Я давно прошёл тот возраст когда левым дядям верят больше чем своим глазам.
Я не говорил про левых дядей. Я говорил про исследование. На фоне которого можно делать выводы.
Программирование — это как и математика/физика/etc творческое занятие. И безусловно, люди, которые сильны в математике, имеют больше навыка работать с абстракциями, чем Вася, который учился на сварщика.
Но на этом факте, мы не можем делать далеко идущие выводы, по которым отсутствие знания матана, является отсеивающим критерием хорошего программиста.
Программирование — это как и математика/физика/etc творческое занятие. И безусловно, люди, которые сильны в математике, имеют больше навыка работать с абстракциями, чем Вася, который учился на сварщика.
Но на этом факте, мы не можем делать далеко идущие выводы, по которым отсутствие знания матана, является отсеивающим критерием хорошего программиста.
Я не говорил ни про какие исследования и про весь мир, я написал что я лично видел, с кем работал и работаю. Про тех программистов которых я не видел, ничего сказать не могу. А про какие исследования вы пытаетесь говорить я вообще не понимаю. А если я вам скажу что не любое исследование опубликованное в рецензируемом журнале правда? А если я скажу что фейковых исследований очень много?
А если я вам скажу что не любое исследование опубликованное в рецензируемом журнале правда? А если я скажу что фейковых исследований очень много?
И даже если исследование настоящее, проведенное на совесть — и связанное со статистикой — то и там все не так просто.
Я бы заметил, что математика это от Бога, а программирование это ремесло. Это так же как шедевры живописи сюжет это от Бога, а нарисовать это чисто технически. По этому весь мир веками восторгаетеся Джокондой Леонардо Давинчи, Рождением Христа Микианжелло или Едоками картофели Ван Гога. Все рисуют по разному, но сюжет завораживает.
Плюс сюда.
В последние годы очень сильно развилось представление, что программирование – это синтаксис. Программирование, всё же, прежде всего – математика.
Вы наверное никогда не видели код, написанный математиками.
Проблема в том, что есть задачи практические и прикладные где без математика никуда. Можно конечно не давать ему писать код, но когда он сам умеет не просто писать код, а именно разработчик с беком математика — всё прекрасно. Да, да, мне все говорят, что ты же не пишешь супер оптимизированный 3D движок, так вот я пишу.
НЛО прилетело и опубликовало эту надпись здесь
Я бы поспорил. Встречал тех кто матан видел, но как программист так себе. Всё зависит скорее от человека, а не от того, на кого он учился.
матан видел, но как программист так себе
Ооо, естественно, очень часто. Наличие матана в прошлом вообще ни разу само по себе не делает разработчика хорошим. Но среди хороших очень у многих матан таки был. Я считаю это практически необходимым условием, но ни разу не достаточным.
Кажется, тут причина и следствие перепутаны. Это не знание матана делает программиста хорошим, а внутренняя мотивация программиста двигает его и быть лучшим специалистом, и изучать смежные области — тот же матан. Если вы говнокодера научите решать дифуры — лучшим программистом он от этого вряд ли станет.
понятие лучшего программиста довольно неопределенно, imho что-то вроде лучшего землекопа которого видел, это заметим сильно от грунта зависит, и глубины траншеи, если говорить о самом сложном sw — это конечно разработка операционных систем (особенно если связано с реальным временем), самое простое — UI, все остальное где-то посередине, образование имеет значение, университет или колледж имеют значение, но талант и работоспособность ничем не заменишь, тогда как все остальное можно, плюс здоровье лошадиное надо (тоже ничем не заменишь),
что такое талант программиста — до эры pc традиционно считалось, что это способность легко и отчетливо понимать (и держать в голове) задачу сразу на нескольких уровнях — типа спецификации, система, модуль, код, в настоящее время все это сильно трансформировалось в сторону промышленного программирования, типа на конвейере по системе тейлора, когда необходима максимальное переиспользование кода, грамотное знание всякого рода пакетов, sdk, api и пр. много чего можно еще добавить, но пока так, как обычно строго imho
что такое талант программиста — до эры pc традиционно считалось, что это способность легко и отчетливо понимать (и держать в голове) задачу сразу на нескольких уровнях — типа спецификации, система, модуль, код, в настоящее время все это сильно трансформировалось в сторону промышленного программирования, типа на конвейере по системе тейлора, когда необходима максимальное переиспользование кода, грамотное знание всякого рода пакетов, sdk, api и пр. много чего можно еще добавить, но пока так, как обычно строго imho
теперь ждем откровения черного инженера.
Кто нибудь пояснит за 7 пункт? Почему мне нельзя работать?
Потому что в продуктовый смузи стартапах онлайн образования обмазанных скрамокультами вас могут не понять :)
чепуха, забудьте, все люди равны перед программированием :)
По жизни тоже все равны, но некоторые равнее
верно, только к чему это?
из любопытства, хотелось бы знать этих людей с которыми вы пересекались — «математики, физики, либо специалисты в иных очень сложных областях)», со своей стороны могу сказать, что видел достаточно программистов выпускников мфти и mit, но ничего похожего на упомянутую вами закономерность
из любопытства, хотелось бы знать этих людей с которыми вы пересекались — «математики, физики, либо специалисты в иных очень сложных областях)», со своей стороны могу сказать, что видел достаточно программистов выпускников мфти и mit, но ничего похожего на упомянутую вами закономерность
Есть опасность, что вы начнёте писать на фортране (писать на фортране можно на любом языке программирования) и всем, включая вас, будет от этого больно.
Да, про плюс 50 процентов на новом месте — к сожалению так, поэтому когда зовут на «новые амбициозные проекты» а добавляют плюс 10 даже задницу отрывать неохота. Но если бы работадатель у нас хотя-бы индексировал зп, поднимал хоть как то общим планом тогда бы и народ бы не бегал туда-сюда
Многое верно, но с тем что на работе с более низкой зарплатой будет хуже чем с высокой не соглашусь. Все всё понимают если это большой город и недоплаченная вам зарплата идет кому-то в карман и он точно не хочет потерять эту статью дохода поэтому и вас бережет.
«Вы», это не вы, а ваша должность.
С неё идут деньги в карман. Её берегут. Людей на ней — нет.
С неё идут деньги в карман. Её берегут. Людей на ней — нет.
Притча собственного придумывания:
— Неужели вы, считаете, что мне когда-то пригодится эта ваша линейная алгебра?
— Вы её так плохо знаете, что определённо нет.
— Неужели вы, считаете, что мне когда-то пригодится эта ваша линейная алгебра?
— Вы её так плохо знаете, что определённо нет.
Каждый раз, когда я меняю работу, я сокращаю свои обязанности на 50% и увеличиваю зарплату на 50%Отличный у Вас коэффициент
Любое хорошее начинание заканчивается чем-то плохим…
Придумали коммунизм — закончили массовыми репрессиями.
Придумали новый путь в Индию — закончили геноцидом индейцев.
Придумали аджайл — закончили скрамом.
Придумали коммунизм — закончили массовыми репрессиями.
Придумали новый путь в Индию — закончили геноцидом индейцев.
Придумали аджайл — закончили скрамом.
Мне пьяный оригинал больше понравился.
1 Работа в нашей отрасли полностью построена на порочных стимулах.
2 Лучший способ продвинуться по карьерной лестнице — это смена компании. Компании, в которых вы работаете, будут вознаграждать хорошую работу большей работой и ответственностью, а не большим количеством времени и/или денег. Компании, в которые вы переходите, вознаградят вашу предыдущую хорошую работу в других компаниях большими деньгами. На самом деле это не имеет смысла… См. Пункт №1.
можно кэпа? Каким образом короткая фраза «работа построена на порочных стимулах» объясняет почему переход на +50% не имеет смысла? Все пункты ссылаются на 1, но он звучит как «потому что гладиолус»
Как я понял, смысла не имеет поведение компаний, а не сотрудника.
1) Потому что деньги — зло.
2) Потому что не хотеть нагружать себя всё больше и больше за те же деньги — грех.
Мне кажется как-то так.
2) Потому что не хотеть нагружать себя всё больше и больше за те же деньги — грех.
Мне кажется как-то так.
1) Потому что деньги — зло.
2) Потому что не хотеть нагружать себя всё больше и больше за те же деньги — грех.
Мне кажется как-то так.
в этом нет логики. «пьяный инженер» какраз говорил о том что не имеет смысл давать себя эксплуатировать больше за те же деньги и что проще уйти в другую компанию. На что «трезвый инженер» сказал что эти рассуждения чепуха потому что «Работа в нашей отрасли полностью построена на порочных стимулах.»
Порочный стимул заключается в том, что человека вынуждают менять работу для улучшения жизненных условий.
При этом страдает как сам человек — от изменений, потери налаженных связей и опыта — так и компания, которая всё равно понесёт лишние расходы (на потерю специалиста, переобучение, новую высокую зарплату).
Не страдает только одно: эго руководства. Эта схема давно известна — «мы не прогибаемся и любые деньги готовы отдать за то, чтобы нас не прогнули». Работник это враг руководителя, просьба поднять зарплату — это акт агрессии, этот акт агрессии должен быть отбит с любыми потерями. Идеальный вариант — полное уничтожение противника, который исчезает с поля боя (из компании).
При этом страдает как сам человек — от изменений, потери налаженных связей и опыта — так и компания, которая всё равно понесёт лишние расходы (на потерю специалиста, переобучение, новую высокую зарплату).
Не страдает только одно: эго руководства. Эта схема давно известна — «мы не прогибаемся и любые деньги готовы отдать за то, чтобы нас не прогнули». Работник это враг руководителя, просьба поднять зарплату — это акт агрессии, этот акт агрессии должен быть отбит с любыми потерями. Идеальный вариант — полное уничтожение противника, который исчезает с поля боя (из компании).
(навеяно комментариями)
вопрос к плакату в начале статьи, кто изображен на нем более-менее понятно — трезвый программист за обедом (автор?), но не совсем понятно, что собственно у него на тарелке?
такое впечатление, что художник в жизни нормальной котлеты не видел, или видел, но так давно, что забыл и рисует по памяти, неужели раньше такое в ресторане предлагали?
затем не понятно, кто именно программисту рюмку водки налил, и собственно с какой стати?
рискну предположить, что это представитель фирмы конкурента, просит оставить например багс в программе, и предлагает выпить, а герой картины отказывается, типа «что мне с этого»,
в общем сплошные вопросы, что очевидно отражается и на комментариях к статье — типа «как именно прикладная математика на мозги программиста влияет — строго отрицательно, или же таки бывают исключения» :)
вопрос к плакату в начале статьи, кто изображен на нем более-менее понятно — трезвый программист за обедом (автор?), но не совсем понятно, что собственно у него на тарелке?
такое впечатление, что художник в жизни нормальной котлеты не видел, или видел, но так давно, что забыл и рисует по памяти, неужели раньше такое в ресторане предлагали?
затем не понятно, кто именно программисту рюмку водки налил, и собственно с какой стати?
рискну предположить, что это представитель фирмы конкурента, просит оставить например багс в программе, и предлагает выпить, а герой картины отказывается, типа «что мне с этого»,
в общем сплошные вопросы, что очевидно отражается и на комментариях к статье — типа «как именно прикладная математика на мозги программиста влияет — строго отрицательно, или же таки бывают исключения» :)
Отличный пост, спасибо за перевод, поставьте кто-нибудь плюсик за меня, почему-то не могу его поставить. Под некоторыми утверждениями готова подписаться, хоть я и не инженер — про карьерный рост через смену работы, про прирост зарплаты, про баланс между работой и личной жизнью, про перевернутое с ног на голову восприятие Agile и про инвестиционный счет и финансовую подушку безопасности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Откровения трезвого инженера