Сегодня резюме удивительно адекватное пришло, давно таких не видел: очень компактно и очень по делу написано, никакой воды, тысяч технологий и прочего. Человек просто перечислил с чем работал последнее время и чем занимался. Завтра придёт на собеседование.

https://thehill.com/policy/technology/488075-federal-government-in-talks-with-tech-groups-to-use-phone-location-data-to

Всё ради детей и коронавируса.

Вот ещё такая фигня есть: когда что-то впервые узнаёшь, это кажется понятным и с какого-то момента очевидным. Оказалось, это не работает для матстатистики, теории категорий и системной-инженерии. В последнем случае всё ещё более запутанно оказалось, так как пришлось заново переосмысливать вещи, которые вроде бы знал раньше. Оказалось — не знал.

Следующий пост будет о терминологии и неправильном понимании.

В программной и системной инженерии есть такой термин — stakeholder. В русскоязычной традиции его обычно переводят как заинтересованное лицо. Типичное объяснение термина такое: Stakeholders are individuals or groups that have an interest in the success and progression of a company. В нём вроде бы всё хорошо, но вот только оно неправильное. Ключевая проблема здесь в слове individuals, многие люди считают, что речь идёт о конкретном человеке (Иван Фёдорович или Илон Маск, например). Однако человек-персона на может быть стейкхолдером, так как очень сложно понять, что вообще за штука такая — человек — применительно к нашему системному контексту. У человека-человека очень много разных внешних представлений есть, он играет разные роли в разных контекстах. И поэтому стейкхолдер — это не персона, а роль. Например, роль «участковый врач» для медицинской системы или «ученик школы» для системы «Электронный дневник».

Как только вы представляете конкретного человека в роли стейкхолдера, вы сворачиваете с правильного пути рассуждений на путь, который вас приведёт практически гарантированно не туда.

Точно такой же ролью на самом деле являются почти все сущности-с-интересами: акторы (actors), персоны (personas), пользователи (users). В системных и программных моделях нет места личностям, там только модели, коими как раз и являются роли.

К сожалению, все эти термины семантически запутанны и переплетены. К примеру, в обычной жизни actor обычно представляется как актёр, то есть некий конкретный человек, Иван Фёдорович Крузенштерн, например. А в моделировании actor — это роль, одна из масок, которые носит Иван Фёдорович в разных контекстах. Аналогично было с персонами: persona ≠ person.

Размышления о системах переходят на качественно новый уровень, как только вы начинаете чётко разделять живых людей (или любые другие конкретные сущности) и роли в контексте.

Народу выдали маски и отправили работать по домам, в офисах, для тех кто остался, поставили обеззараживатели воздуха, провели профилактические разъяснения по выживанию в условиях эпидемии - дальше суетиться или паниковать бесполезно.

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

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

Помните, в 2014 году на волне паники курс доллара местами до 100р доходил. Сидите ровно и не дёргайтесь, пока рынок колбасит.

При условии, конечно, если у вас нет кучи долларов, тогда есть вероятность неплохо заработать.

Друзья, ну вы же все понимаете, что растасканная по интернету статья с хабра, за авторством Tomas Pueyo - полное фуфло, с недостоверной и сомнительной матмоделью и ошибочными выводами? Вот эта https://m.habr.com/ru/post/491974/ да.

В принципе, как хейтмонгер я одобряю и уважаю fearmongering тоже, но не уважаю фуфло и буллшыт от плохих исследователей)

Вот хорошая статья с хабра на тему, призываю делиться ею, а не лажей.
https://m.habr.com/ru/post/492946/

И вот ещё друзья показали
https://medium.com/@joschabach/flattening-the-curve-is-a-deadly-delusion-eea324fe9727

В постмортеме текущего кризиса напишут наверняка что-то про crisis caused by worldwide panic, тут даже сам коронавирус побоку, просто всеохватывающая паника, которая сама себя подогревает.

Производители CRM, средств удалённой работы и контроля ожидаемо резко усилили маркетинговые работы. Кругом куча совето, инструкций и рекомендаций. Но почему-то они все чисто технические, а в административные моменты почти никто не вдаётся, хотя это очень важно. Без правильной подготовки всё это схлопнется сразу же, как только СМИ отменять истерику и карантин уйдёт. И это печально.

https://www.linkedin.com/pulse/containers-future-ian-eyberg/

That's when I realized that there has been an entire generation of software engineers that have grown up on this madness. Imagine if you were 22 or 23 back in 2013 (that's only 7 years ago) but in a world of software that's practically a lifetime. Hell that's long enough to graduate from college and earn your "senior engineer" spurs. You could've spent all of your 20s only deploying containers and not knowing any other methods even existed. Case in point - the term "ingress" is used in the k8s community as if it's some sort of product category and lo-and-behold nginx is used as a main component. Go figure. You'll see people asking questions like "What would you use for ingress?". What they are basically asking is how would you configure nginx as a reverse proxy.

И ещё оттуда же:

A very interesting paradox going on is that a lot of kubernetes users are learning/deploying kubernetes clusters via "resume-driven development" and VPs of engineering and other leaders are letting them so that they can retain them and do what is already a very hard job to do - hire engineers.

Directors and VPs and other leaders are effectively throwing them a bone to keep them employed at their companies - not necessarily for technical/cost benefits. Many people in positions of management have privately admitted this.

Главный элемент в работе разработчика — это прогресс. Нужно обязательно выдавать хоть какой-то результат работы, который бы ощутимо приближал к поставленной цели. Если человек не может раз, скажем, в месяц или два выдавать результат, то его работу очень сложно оценить и поэтому доверие к нему со стороны менеджмента будет падать. Нельзя жить в коконе, а телепатия не работает — менеджер не может, не хочет и не имеет возможности вникать в самую суть программерской работы. Разработчик обязательно должен уметь рассказывать, чем именно он занимается, как далеко продвинулся и продемонстрировать это. Менеджеры — не телепаты.

Не понимаю, почему люди так псят на КриптоПро CSP — это качественный отечественный продукт с отличной поддержкой и документацией. Это не распильно-откатный проект, он действительно работает.

http://maximilyahov.ru/blog/all/je-suis-krasavchik/

Когда человек откликается на вакансию, он ошибочно думает так: «Я должен показать, какой я крутой. Чем более крутым я себя покажу, тем больше вероятность, что меня наймут».

Это заблуждение по двум причинам.

Дальше по ссылке, очень толковый текст.

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

У прокрастинации есть один плюс: завершённое дело вызывает небывалый кайф, нормальным людям не понять.

У книг с большим количеством иллюстраций есть одна огромная проблема: картинки и текст, который их использует, находятся на разных страницах. Это вроде бы мелочь, но когда иллюстраций несколько сотен и они все важные, необходимость скроллить туда-сюда начинает в итоге выбешивать.

И вроде совсем базовое правило оформления книг, а всё равно на эти грабли авторы продолжают наступать.

Бигдата

Среди айтишников существует популярная идея, что «заказная» и «продуктовая» разработка фундаментально различаются, что люди, привыкшие к одной из систем, не могут работать в другой. И это очень печально, поскольку фундаментально разницы там особо нет. А неспособность людей работать в другой области проистекает от бардака, царящего в продуктовой разработке.

Да-да, дети, в заказной разработке порядка в целом больше. Человек, привыкший к чётким форумлировкам, ТЗ и системе контроля качества, не хочет работать в продуктовом хаосе. И наоборот, привыкший работать в мутных водах продуктовой разработки, не может приспособиться к «адской бюрократии» в заказной.

А вот если в продуктовой среде всё чётко: ТЗ, архитектура, контроль качества, стейкхолдеры и отчёты, то миграция происходит легко и безболезненно.

Нунчапельник