9 карьерных ловушек

5. Демонстрировать незаинтересованность в бизнесе компании

Я просто программист, я не интересуюсь бизнес-задачами.

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

6. Иметь "профсоюзную" ментальность

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

В довольно большом количестве контор царит такая ментальность: не торопись, не высовывайся, не перевыполняй норму, не проявляй много инициативы и активности. Рекомендация, что конечно не увязайте в таком болоте, всегда старайтесь развиваться, однако будьте готовым ко всему, и имейте в виду, что отношение к вашей ударной работе вполне может быть совсем не таким, как вы ожидаете. Если ситуация печальная, то у вас всегда есть возможность проголосовать ногами.

продолжение следует

9 карьерных ловушек

7. Не заботиться о своей ценности

Это вообще пожалуй самый ужасающий баг в карьере :)

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

Знай свою ценность, и стабильно наращивай её.

8. Думать, что дело только в деньгах

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

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

9. Относиться к своей работе просто как к работе

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

Развивай стратегическое понимание всей своей карьеры и профессии в целом. Это не просто работа, это путешествие длиною в жизнь.

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

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

repl.it запускает code jam с 10 по 31 августа: надо разработать свой язык программирования, и кто запилит действительно стоящий проект, получит приз 10,000 долларов.
Хотелось бы верить, что выиграет проект в духе вот такого например
https://github.com/cedille/cedille
но это вряд ли.
Подробнее и туториалы по теме:
https://blog.repl.it/langjam

После относительного спада количество айтишных вакансий медленно но уверенно начало восстанавливаться, сообщила некоммерческая ассоциация CompTIA. По данным на конец июня, количество вакансий в США достигло 263 тысяч. На программистов спрос почти 83 тысячи предложений. В феврале-марте вакансий было 350 тысяч, в мае их количество провалилось до 200 тысяч.
В целом всё позитивно: стабильно растут сектора разработки, ИТ-суппорта, облачных инфраструктур и информационной безопасности.
https://www.comptia.org/newsroom/press-releases/2020/07/02/tech-job-gains-confirm-pockets-of-strength-in-recovering-labor-market

Интересно, кто больше всех хантит: айтишники Amazon и IBM, финтех Wells Fargo, медики Anthem Blue Cross, производитель бытовых инструментов (внезапно) Stanley Black & Decker, и военные Northrop Grumman и Boeing.

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

Резюме двумя словами: доминирование Python. Второй Java, далее Си, С++ и JavaScript.

Надо конечно учитывать определённую специфику IEEE -- прежде всего инженеры-электронщики, которым нужен мощный и простой технический инструмент программирования и вычислений, и чтобы его можно было легко освоить. В некотором смысле Python сегодня -- как Basic в 1980-1990-е :-) Ну и конечно широчайшая популярность Python и в веб-разработке, и в научных вычислениях, и в машинном обучении, и как стандартный язык прикладного программирования во всех дистрибутивах Linux.

https://spectrum.ieee.org/at-work/tech-careers/top-programming-language-2020

Глубокомысленное исследование North Carolina State University и Microsoft внезапно выявило факт, о котором раньше как будто бы никто и не знал (это сарказм :).
https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/

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

И следствие отсюда по Кэпу Очевидность, что и кадровые агентства этим занимаются, и сами кандидаты это хорошо знают и практикуются, и я на курсе карьеры подчёркиваю: к успешному прохождению интервью надо готовиться целенаправленно, чётко понимая, что это совершенно отдельный набор скиллов, к прямой работе особого отношения не имеющий. Ну и вот в Microsoft этим обеспокоились, видимо поднабрали ребят, которые хорошо выступают у доски и красиво вешают лапшу на уши :-)

Есть такая классическая проблема двух генералов. Две армии окружили город с двух сторон, но у них нет связи друг с другом. Город можно захватить, только если атаковать одновременно, поодиночке каждая армия погибнет.

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

Проблема эта решения не имеет. Она часто упоминается на курсах по сетям при изучении протоколов TCP/UDP.

По этой причине создание распределённых систем -- тяжёлая задачка, и достичь 100% надёжности невозможно. Едва только возникает режим взаимодействия серверов, мы обречены на вероятности. А ведь с ростом популярности модели serverless вообще абсолютно всё становится распределённым :)

Правильный распределённый бэкенд должен базироваться на трёх архитектурных принципах:
-- Всё что может сломаться (а может сломаться всё что угодно), рано или поздно сломается;
-- Система всё равно должна продолжать работать;
-- Сбои должны легко фикситься.

Какими подходами этого достичь, рассмотрим далее.

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

1. Изоляция багов.

Помните эпический сбой интернета весной 2017-го?
Инженеры AWS ничтоже сумняшеся решили провести эксперимент на живой системе :-) А давайте отключим несколько серверов S3 и посмотрим, что получится? (серьёзно). Отлаживался балансировщик нагрузки, и как всегда что-то пошло не так -- отключилось слишком много серверов, нагрузка на остальные резко возросла, ну и они посыпались.
А так как на S3 как на хранилище файлов завязана по сути вся AWS, то поломалась и её существенная часть. А на AWS завязана половина интернета...

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

Три правила:
1. У каждой операции в системе единственная ответственность.
2. Каждая операция атомарна (и в идеале работает как транзакция с возможностью отката если что-то пошло не так).
3. Количество взаимосвязей между операциями минимизируется.

Механизм serverless например хорошо для этого подходит и поощряет такую практику.

Например, в случае AWS надо было критически важные файлы хранить в нескольких резервных режимах, потому что тогда даже дашборды AWS затупили просто потому, что их иконки хранились на S3.

Количество вакансий для программистов в США практически вернулось к исходному уровню перед пандемией, по данным Dice Tech Job Report.
https://insights.dice.com/2020/07/28/dice-tech-job-report-q2-offers-optimism-tech-industry/
Топовым хантером этим летом стал Амазон, берёт всех подряд, Java C++ ML... Интересно, что не особо отстают от него по активности крупнейшие военные подрядчики General Dynamics и Northrop Grumman.
Аж на 51% вырос спрос на Data Engineer (видимо, имеется в виду и data science, и бигдата, и классические базы данных). Техподдержка подросла на 30-35%, программисты -- на 31%, и отдельно на Java-сеньоров большой спрос, +30%.

Правила изоляции багов (продолжение темы про обеспечение надёжности).

1. У каждой операции в системе единственная ответственность.
Каждая функция, каждый метод должен делать что-то одно (на курсах по ООАП мы подробно этот момент разбираем). Например, функция не должна менять какое-то состояние и одновременно возвращать справочную информацию: либо изменение состояния, либо выдача данных гарантированно без модификации состояния.

Лайфках тут простой: если в комментариях, что делает функция, вы пишете "то И сё" (имеется союз И), значит её надо дробить.

9 игр для обучения программированию с околонуля
https://www.freecodecamp.org/news/best-coding-games-online-adults-learn-to-code/

Второй всероссийский учебный онлайн фестиваль по алгоритмическому программированию и искусственному интеллекту
31 августа – 4 октября 2020
https://rucode.net/

Хорошее соревнование в минимализме вакансий :)

Видимо, фуллстек хотят:
Стэк: Java, JavaScript, Go
Денег: $4500-7000
Remote
Fintech startup (Boston)
===

В принципе, совершенно адекватное предложение, ну разве что PostgreSQL немного специфична:
Backend Senior
Стэк: Java, PostgreSQL, Spring, Linux
Денег: $3000-4000
Moscow, Russia
Ищем Senior/Lead Java Developer в продуктовую компанию
===

Ну а кто помучился с поиском и никого не нашёл, начинают удалять лишние запросы:
Стэк: Java, Kotlin
Денег: $3000-4000
Remote
Revolut ищет талантливых и амбициозных разработчиков (Москва, Берлин, Лондон, Краков)

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

Вообще, правильный стек в вакансиях, это что-то типа
Python + SQL + Linux
или
Java + Android
или
C# + .NET Core
или
JavaScript + Node.js
==
$3000

За каждое дополнительное слово к этому накидывайте по $1000-$1500.

Илон Маск по сути пересказывает принципы продуктивного самонаучения Алана Кэя, ну и по большому счёту, советской научной школы (самое главное -- это фундамент и широта взглядов под зонтиком единой научной методологии), которую потом западные и китайские университеты скопировали, так как ранее упирались в практическую отдачу (схема финансирования через гранты к тому подталкивала).
https://entrepreneurshandbook.co/elon-musks-2-rules-for-learning-anything-faster-cf9a79fba35

1) Растите свои знания как семантическое дерево: перед тем, как взяться за прикладные листья, убедитесь, что вы понимаете основополагающие принципы, т.е. изучили ствол и крупные ветви, иначе вашим листочкам будет не за что зацепиться.

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

2) Вы не можете хорошо запомнить и продуктивно освоить то, что не с чем соединить.

Маск начинал с крепких корней и мощных стволов, а затем, когда его знания стали активно расти вверх, он начал скрещивать ветви и листья с ветвями и листьями других деревьев.
Маск никогда не учится наобум. Всё, что он загружает в свой мозг, он делает системно, соединяя новое с всё более и более глубоким и прочным фундаментом.

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

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

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

В последнее время на Javy что-то везде наезжают, каналы java memes прям плодятся, считаю, несправедливо. Да, бумеры её традиционно недолюбливают, но в основном "по старой памяти", когда были ужасающие java-апплеты в браузерах, а сама она в плане изучения была куда сложнее плюсов, ну и реально тормозила. Но сегодня, про проблемы с быстродействием можно забыть, особенно на фоне популярности питона, а когда выкатили Java 8, вообще стало норм.

Объективно, из 5-7 ведущих мэйнстримовских языков Java -- ну, топчик с т.зр. кампутер сайенса, т.к. Тьюринг-полнота её системы типов была доказана ещё лет пять назад, по моему. А вот в C# например генерики это фича, которая разрешается в рантайме (претензии, точнее, к CLR), ну и вообще type-checking шарпа is NP-hard.
А вот CSS -- ТП :) Продуктивнее всего кстати доказать, является ли система типов некоторого языка ТП -- это реализовать на ней комбинаторную логику, SKI calculus.
Ну вот, классика метапрограммирования: Scala type level encoding of the SKI calculus
https://michid.wordpress.com/2010/01/29/scala-type-level-encoding-of-the-ski-calculus/

Это я к тому, что как только возникает достаточно серьёзный проект, завязанный на формальные методы, когда верификацию, пруфы-скрипты, надо выгонять в прикладной код, вот и оказывается, что кроме Java и взять-то особо нечего. В этой вашей гошечке система типов -- днище 90-х годов; даже если динамические языки брать, то в питончике замыканий нормальных никогда не было, и т. д.

Антон работал до 30 лет продажником, а потом двинул в дата-сайнс.
1,5 года на обучение,
перепробовано 11 курсов,
потрачено 163 тысячи на освоение профессии.
Устроился в итоге в банк, вместе с премией получает 160-170т.
https://journal.tinkoff.ru/become-analytic/

А что если в ящик Шрёдингера поместить не котика, а компьютер, считающий некоторую задачу? Фактически, можно его не запускать, и тем не менее получить результат вычислений. Компьютер ждёт, пока кто-то не нажмёт "Старт", но при этом выдаст результат. С точки зрения ограниченного здравого смысла это невозможно, однако эксперименты с подобными -- так называемыми контрфактуальными вычислениями — успешно проводились физиками ещё 15 лет назад.

https://www.osp.ru/cw/2006/08/376287

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

И вот шикарный свежачок
https://fqxi.org/community/forum/topic/3345

А что, если контрфактуальные вычисления моделируют работу мозга? тогда мы получим зомби Шрёдингера, который как-то действует в мире, "мыслит", но при этом собственного опыта думания у него нету.

Тут же известная тема квантовых бомб Элицура-Вайдмана, когда есть бомбы, которые взрываются при любом факте их физического наблюдения (например, при попадании единственного фотона), однако в нашей реальности тем не менее возможно выяснить, какие конкретно бомбы рабочие, не взорвав их.
https://www.nkj.ru/archive/articles/17795/

В частности, применяя контрфактуальные вычисления, мы можем теоретически организовать жизнь так, чтобы гарантированно получать только счастливые результаты, и гарантированно избегать плохих результатов.

Просветлённые, впрочем, научились этому ещё тысячи лет назад.

=

Резюме такое, что пока сами квантовые физики по мере исследования темы офигевают всё больше и больше :)

Философия Unix (14 принципов правильного кода) применительно к Zen of Python
https://blog.finxter.com/the-unix-philosophy/