Если это про отношение к войнам, тогда я тоже вайнах. После армии как-то особенно.
Хотя приравнивать игры в танчики в детском саду к реальным войнам это как рисунки, где дети изображают маму с папой, приравнивать к прону (а чё они ведь тоже люди). В общем, контекст тут важен.
Мне структурные типы в TS кажутся выразительнее, чем номинальные как в Java. Плюс в нем более продвинутая алгебра типов, у которой понятно из каких разделов математической логики растут ноги. Но вполне допускаю, что это вкусовщина.
Мы не живём в России уже много лет, оставаясь при этом гражданами. В прошлом году за границей родился третий ребенок.
От РФ, жена получила статус многодетной и разовое пособие около 5 т.р.
Плюс ей открыли социальную карточку, куда теперь возвращается часть оплаты за коммуналку, которую я плачу за оставшуюся дома квартиру. Такого кэшбэка хватает на то, чтобы заплатить сотовому оператору за симки, куда приходят смс от банка, где открыт счёт, ... ну вы поняли.
Материнский капитал третьему ребенку не положен. Для выплаты пособия по уходу до 1.5 лет нужно показать или официальный заработок за два года у того кто будет сидеть в декрете, или отсутствие дохода свыше какой-то там суммы (чтобы рассчитывать на минимальное). Заработка понятно нет. Зато в банке у нее оказался небольшой вклад, проценты по которому за несколько лет сочли доходом. В общем ей ни чего не дали. Какие-то выплаты возможны для малообеспеченных, но мы не попали и под эти критерии (уф).
Оформление всех документов, включая документы на ребенка, рождённого за границей, с бегатней по разным инстанциям, заняло почти два месяца. Они были на каникулах, в гостях у бабушки, поэтому было свободное время этим заниматься.
При одинаковых условиях, семьи где работают оба супруга будут иметь значительно больший доход. Пусть и не в два раза.
От ситуации зависит. У жены практически вся зарплата госслужащией (что-то около 15т.р.) уходила на ту же работу: проездной (1.5т.р) и обеды (500*23=11.5т.р.). С учётом одежды, косметики и периодических больничных из-за сквозняков и стресса затея получалась планово убыточной. Чисто экономически ей было выгоднее ни куда не ездить, а сидеть дома.
если мать не работает, или ИП, то отец-айтишник, может взять отпуск по уходу за ребенком, тут же снова выйти на работу, и таким образом получить ~50к в месяц дополнительного дохода,
Там масса оговорок. Например, если мама не работает, то отпуск и пособия папе не дадут. Выбор появляется если мама работает официально или вы одинокий отец.
Мне кажется, что в примере есть ещё и историческое несоответствие с заявленным:
Подобное может быть верным лишь для только родившегося JS
В момент появления JavaScript, доступ к элементам был в силе "document.myForm.myInput", и это работало буквально лишь для нескольких типов (form, img и может ещё пары каких-то).
document.getElementById(), ровно как и весь DOM, это более позднее изобретение.
Код на слайде выглядит как лет на 10 позже. Т.е. JavaScript к тому времени не только родился, но уже и в школу пошёл.)
Типизация должна быть сделана на уровне рантайма, а не на уровне языка. Создатели TS рантайм не контролировали, и поэтому запилили транспиляцию.
Статическая типизация - это проверка типов на этапе компиляции. Ровно то, что реализовано в TS.
Проверка типов в рантайме это строгая типизация. Она несёт за собой дополнительные накладные расходы и тут всегда возникает tradeoff между строгостью и performance. Проверяйте входные данные, а в остальном можно жить и без этого.
если мы говорим о его использовании в микроконтроллера
У меня есть пара плат с Espurino. Это JavaScript для микроконтроллеров. Там где не важны задержки и плевать на энергоэффективность (а это львиная доля всей домашней автоматизации), писать логику на JS одно условие.
Для тех, кто у вас спрашивает оценки, а потом назначат их же вам как дедлайны - наверняка в аду приготовлен отдельный котёл.
Вообще задачи условно делятся на две категории. 1. Которые понятно как делать. 2. Которые - не понятно.
Задачи первого рода есть всегда и вы можете дать для них оценку с большой долей достоверности. Так сделайте это.
Если столкнулись с задачей второго рода, то положите в спринт спайк с задачей на исследование, и целью - родить план для дальнейших действий, которые уже сможете оценить. Установите на нее психологически и финансово комфортный лимит по времени сверху. Все у вас снова есть вполне правдоподобная оценка.
В итоге все задуманное либо будет оценено и выполнено. Либо вы от чего-то откажетесь, если сочтёте нерешаемым. Но у вас для этого уже будут все основания.
нам дали десять (двадцать, сто) камней, чтобы сложить стену, но мы не знаем, как это делать... "учи кирпичи!"
Между двадцатью и ста есть разница.
Ради интереса, попробуйте оценить: сколько времени у вас займет собрать пазл из соответствующего количества плиток? Здесь ведь даже учить ничего не надо - просто собрать. А потом реально собрать и порефлексировать над результатами.
Чтобы ещё больше приблизить игру к реальности, попробуйте предварительно смешать плитки из нескольких однотипных наборов. Просто в конце покажете несколько картинок, сложенных рядом.
Половину из них раздайте детям - с условием, чтобы они все вернули ровно через час. Оставшейся половины вам ведь точно должно хватить, чтобы не сидеть без дела всё это время?
Да, кто-то из детей потом может опоздать. Кто-то в процессе потеряетет какие-то детали, но чтобы не огорчать отца, заменит на примерно похожие. Поэтому разницы сразу вы не заметите. Но в конце результат у вас все равно должен быть как на макете.
Теперь снова прикиньте оценку. А может вам хватит простого коэффициента?)
Я называю это наркомания - стремление получить удовлетворение как можно быстрее. На это подсаживаешься, это вызывает привыкание, отсутствие быстрых результатов приводит к ломке и даже - выгоранию. В таком состоянии люди готовы буквально на всё, чтобы получить очередную дозу своего удовольствия сию секунду, даже на преступление.
Когда менеджеры требуют оценку немедленно, программисты коммитят код без тестов, чтобы закрыть задачу, а тестировщики красят в зелёный неглядя - вот это оно.
Да мысли в вашей статье классные. Попытаться описать себя в роли руководителя это хороший способ понять о чём это вообще. Даже оставаясь на ролях специалиста, потом начнёшь больше ценить такую работу. Сложно? Трудно? А то.
Ну вот руководитель со знаниями специалиста, или специалист с организаторскими способностями это комбо, на самом деле не так часто встречающееся в природе. Если вы нашли такого человека, то считайте, что выиграли в лотерею. Они не будут тупить, при виде слов фронтенд-бекенд, или ждать аналитиков, чтобы зафиксировать ключевые решения после встречи. Мне кажется слова Джобса об чём-то таком.
Опять же, рассчитывать на выигрыш в лотерее это так себе стратегия. Поэтому я согласен и с @lair - нужно уметь работать с тем, что имеем.
А что конкретно обязательно делает руководитель команды, кроме руководства?
Рассказывает как и что делать
Задача руководителя выбирать людей и указывать им цели - пресловутые who/what/when, - контролируя потом риски и результаты. А how "как" это работа специалистов - для этого их и нанимают.
Если специалисту приходится рассказывать как делать свою работу, то здесь от руководителя требуется во время определить риск. А дальше нужен просто более опытный специалист: учитель, тренер, наставник, - а не руководитель.
Они, разумеется, тоже будут ставить цели и контролировать результаты - в своих образовательных активностях. Но это занятие немного другого рода.
Я согласен. Хотя, тут как всегда нужно учитывать контекст. Можно быть мидлом на конкретном проекте или даже в целой организации, закрывая таски. Но за рамками делать какие-то продукты. Образовательный курс, канал в соцсетях, музыкальную группу, школу танцев, магазин собранный по принципу no-code/low-code,... да хоть морковку в огороде выращивать и на рынке продавать (у меня есть живые примеры). :)
когда сам вырастаешь до достаточного уровня, можно просто сказать "мое время слишком дорого, чтобы я его тратил на организацию встреч".
Сказать кому? Выглядит скорее как навык пушбэчить, нежели делегировать. Это срабатывает когда ответственность лежит на ком-то другом. Ну то есть собрать контакты, подготовить материалы и презу, написать агенду, а потом mfu с экшен айтемами по результатам это не дорого. А жамкнуть пару кнопок в календаре аутлука - тут без проджекта с аналитиком уже ни как?
Мне кажется продукт это то, что решает проблемы бизнеса. Софт здесь всегда лишь только часть - даже если вы продаете коробки. А в репозиториях лежат исходники приложения, или отдельных его компонентов. Написать работающее приложение и сделать прибыльный продукт это довольно разные вещи.
мне как к архитектору пришли и попросили дизайн для вот такой-то функциональности, то моя задача - сделать такой дизайн, а организовывать процесс его внедрения буду не я.
Ну а кто будет организовать процесс сбора требований, проводить встречи со стейк холдерами, пушить экспертов, верифицировать и оценивать решение с командами? Без организаторских навыков, имхо, тут будет тяжело. Может на начальных этапах карьеры за вас этим будут заниматься более опытные ребята. Но сидеть так вечно в джунах это какой-то инфантилизм.
Если это про отношение к войнам, тогда я тоже вайнах. После армии как-то особенно.
Хотя приравнивать игры в танчики в детском саду к реальным войнам это как рисунки, где дети изображают маму с папой, приравнивать к прону (а чё они ведь тоже люди). В общем, контекст тут важен.
Мне структурные типы в TS кажутся выразительнее, чем номинальные как в Java. Плюс в нем более продвинутая алгебра типов, у которой понятно из каких разделов математической логики растут ноги. Но вполне допускаю, что это вкусовщина.
Это динамическая типизация. Она может быть строгой, ну или как в JS).
Мы не живём в России уже много лет, оставаясь при этом гражданами. В прошлом году за границей родился третий ребенок.
От РФ, жена получила статус многодетной и разовое пособие около 5 т.р.
Плюс ей открыли социальную карточку, куда теперь возвращается часть оплаты за коммуналку, которую я плачу за оставшуюся дома квартиру. Такого кэшбэка хватает на то, чтобы заплатить сотовому оператору за симки, куда приходят смс от банка, где открыт счёт, ... ну вы поняли.
Материнский капитал третьему ребенку не положен. Для выплаты пособия по уходу до 1.5 лет нужно показать или официальный заработок за два года у того кто будет сидеть в декрете, или отсутствие дохода свыше какой-то там суммы (чтобы рассчитывать на минимальное). Заработка понятно нет. Зато в банке у нее оказался небольшой вклад, проценты по которому за несколько лет сочли доходом. В общем ей ни чего не дали. Какие-то выплаты возможны для малообеспеченных, но мы не попали и под эти критерии (уф).
Оформление всех документов, включая документы на ребенка, рождённого за границей, с бегатней по разным инстанциям, заняло почти два месяца. Они были на каникулах, в гостях у бабушки, поэтому было свободное время этим заниматься.
От ситуации зависит. У жены практически вся зарплата госслужащией (что-то около 15т.р.) уходила на ту же работу: проездной (1.5т.р) и обеды (500*23=11.5т.р.). С учётом одежды, косметики и периодических больничных из-за сквозняков и стресса затея получалась планово убыточной. Чисто экономически ей было выгоднее ни куда не ездить, а сидеть дома.
Там масса оговорок. Например, если мама не работает, то отпуск и пособия папе не дадут. Выбор появляется если мама работает официально или вы одинокий отец.
Мне кажется, что в примере есть ещё и историческое несоответствие с заявленным:
В момент появления JavaScript, доступ к элементам был в силе "document.myForm.myInput", и это работало буквально лишь для нескольких типов (form, img и может ещё пары каких-то).
document.getElementById(), ровно как и весь DOM, это более позднее изобретение.
Код на слайде выглядит как лет на 10 позже. Т.е. JavaScript к тому времени не только родился, но уже и в школу пошёл.)
Статическая типизация - это проверка типов на этапе компиляции. Ровно то, что реализовано в TS.
Проверка типов в рантайме это строгая типизация. Она несёт за собой дополнительные накладные расходы и тут всегда возникает tradeoff между строгостью и performance. Проверяйте входные данные, а в остальном можно жить и без этого.
У меня есть пара плат с Espurino. Это JavaScript для микроконтроллеров. Там где не важны задержки и плевать на энергоэффективность (а это львиная доля всей домашней автоматизации), писать логику на JS одно условие.
С точки зрения математики, сложение и конкатенация это разные вещи. Сложение коммутативно, а конкатенация - нет.
Использование в языке одного и того же символола для обозначения разных по сути операций это однозначно фейл.
Для тех, кто у вас спрашивает оценки, а потом назначат их же вам как дедлайны - наверняка в аду приготовлен отдельный котёл.
Вообще задачи условно делятся на две категории. 1. Которые понятно как делать. 2. Которые - не понятно.
Задачи первого рода есть всегда и вы можете дать для них оценку с большой долей достоверности. Так сделайте это.
Если столкнулись с задачей второго рода, то положите в спринт спайк с задачей на исследование, и целью - родить план для дальнейших действий, которые уже сможете оценить. Установите на нее психологически и финансово комфортный лимит по времени сверху. Все у вас снова есть вполне правдоподобная оценка.
В итоге все задуманное либо будет оценено и выполнено. Либо вы от чего-то откажетесь, если сочтёте нерешаемым. Но у вас для этого уже будут все основания.
Между двадцатью и ста есть разница.
Ради интереса, попробуйте оценить: сколько времени у вас займет собрать пазл из соответствующего количества плиток? Здесь ведь даже учить ничего не надо - просто собрать. А потом реально собрать и порефлексировать над результатами.
Чтобы ещё больше приблизить игру к реальности, попробуйте предварительно смешать плитки из нескольких однотипных наборов. Просто в конце покажете несколько картинок, сложенных рядом.
Половину из них раздайте детям - с условием, чтобы они все вернули ровно через час. Оставшейся половины вам ведь точно должно хватить, чтобы не сидеть без дела всё это время?
Да, кто-то из детей потом может опоздать. Кто-то в процессе потеряетет какие-то детали, но чтобы не огорчать отца, заменит на примерно похожие. Поэтому разницы сразу вы не заметите. Но в конце результат у вас все равно должен быть как на макете.
Теперь снова прикиньте оценку. А может вам хватит простого коэффициента?)
Я называю это наркомания - стремление получить удовлетворение как можно быстрее. На это подсаживаешься, это вызывает привыкание, отсутствие быстрых результатов приводит к ломке и даже - выгоранию. В таком состоянии люди готовы буквально на всё, чтобы получить очередную дозу своего удовольствия сию секунду, даже на преступление.
Когда менеджеры требуют оценку немедленно, программисты коммитят код без тестов, чтобы закрыть задачу, а тестировщики красят в зелёный неглядя - вот это оно.
Да мысли в вашей статье классные. Попытаться описать себя в роли руководителя это хороший способ понять о чём это вообще. Даже оставаясь на ролях специалиста, потом начнёшь больше ценить такую работу. Сложно? Трудно? А то.
Ну вот руководитель со знаниями специалиста, или специалист с организаторскими способностями это комбо, на самом деле не так часто встречающееся в природе. Если вы нашли такого человека, то считайте, что выиграли в лотерею. Они не будут тупить, при виде слов фронтенд-бекенд, или ждать аналитиков, чтобы зафиксировать ключевые решения после встречи. Мне кажется слова Джобса об чём-то таком.
Опять же, рассчитывать на выигрыш в лотерее это так себе стратегия. Поэтому я согласен и с @lair - нужно уметь работать с тем, что имеем.
Задача руководителя выбирать людей и указывать им цели - пресловутые who/what/when, - контролируя потом риски и результаты. А how "как" это работа специалистов - для этого их и нанимают.
Если специалисту приходится рассказывать как делать свою работу, то здесь от руководителя требуется во время определить риск. А дальше нужен просто более опытный специалист: учитель, тренер, наставник, - а не руководитель.
Они, разумеется, тоже будут ставить цели и контролировать результаты - в своих образовательных активностях. Но это занятие немного другого рода.
Я согласен. Хотя, тут как всегда нужно учитывать контекст. Можно быть мидлом на конкретном проекте или даже в целой организации, закрывая таски. Но за рамками делать какие-то продукты. Образовательный курс, канал в соцсетях, музыкальную группу, школу танцев, магазин собранный по принципу no-code/low-code,... да хоть морковку в огороде выращивать и на рынке продавать (у меня есть живые примеры). :)
Сказать кому? Выглядит скорее как навык пушбэчить, нежели делегировать. Это срабатывает когда ответственность лежит на ком-то другом. Ну то есть собрать контакты, подготовить материалы и презу, написать агенду, а потом mfu с экшен айтемами по результатам это не дорого. А жамкнуть пару кнопок в календаре аутлука - тут без проджекта с аналитиком уже ни как?
Мне кажется продукт это то, что решает проблемы бизнеса. Софт здесь всегда лишь только часть - даже если вы продаете коробки. А в репозиториях лежат исходники приложения, или отдельных его компонентов. Написать работающее приложение и сделать прибыльный продукт это довольно разные вещи.
Ну а кто будет организовать процесс сбора требований, проводить встречи со стейк холдерами, пушить экспертов, верифицировать и оценивать решение с командами? Без организаторских навыков, имхо, тут будет тяжело. Может на начальных этапах карьеры за вас этим будут заниматься более опытные ребята. Но сидеть так вечно в джунах это какой-то инфантилизм.