Вот так, собственно, и выглядел наш стенд.

Не раз уже напоминал об этом, но если у кого-то из вас есть интересные идеи, вопросы или пожелания, смело пишите.
Даже не на почту (согласен, это дико неудобно), а прямо в Телеграм - @ThomasStorm

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

В то же время разработка процесс непрерывный. Вы написали приложение, которое делает что-то конкретно одно, потому что вы любите минимализм и весь из себя такой unix way. Вскоре вы переписываете свое приложение, и далек не потому, что оно вам внезапно не нравится. Потому что требования новые.

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

Ранее, когда сотрудник получал ноутбук, он подписывал бумажку на которой значились данные по ноутбуку, его цена и ответственность сотрудника. Бумага сканировалась ИТшниками, отправлялась кадровикам. Кадровики вручную загружали скан договора с HR систему. Бумага отправлялась в шредер.

Крайне неэффективно, не правда ли?

Так вот я и парень-из-гугла написали 3-компонентую систему:
- Скрипт на Groovy, которые отправляет кастомное письмо с ссылкой на форму цифровой подписи
- Google Script приложение, которое собирает данные и генерирует контракт с цифровой подписью
- Python скрипт, которые забирает контракт, загружает его в HR систему и меняет статус тикета в Сервисдеске.

Затем началось веселье:
- А давайте брать данные по оборудованию из CMDB, а не забивать их вручную!
- А еще подпилим приложение, чтобы оно не валилось от ASCII несовместимых символов!
- А можно копию контракта по почте отправлять?
- А что делать с людьми, если они поженились и сменили фамилию? Может будем искать не по имени, а по идентификатору сотрудника?

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

Как сказал классик: "Компьютеризация бардака превращает его в компьютеризированный бардак."

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

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

Эх, смена поколений... 🙁

Ребзя, канал не умер! Просто я был очень и очень занят.

У меня есть 2 новости.

Первая: наш мамкин стартап в лице робота-криптотрейдера из зачаточного состояние вырос в такую себе машину по зарабатыванию денег. Предстоит еще много чего сделать, но фундамент заложен.
Кому интересны цифры - https://stats.gsmg.io
Кому интересно пообщаться с нами и нашей маленькой коммьюнити - https://join.slack.com/t/gsmg-platform/shared_invite/enQtMjcxNzQyOTYzNjIxLWMzMGEwNDQ2ZDZiMTRmMjY5OGUxZTkzMjlkYzY4MzhjNzlmZjA5MDA1MGRlOTA5MmVhNmY5NWEyOTliNDgyZTE
Если заходите по ссылке из канала, так и говорите, я вас узнаю. 😉

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

Иногда, когда я решаю какую-то сложную задачу, я люблю крикнуть: "Я есть Тьма!" (не вслух разумеется, а только в чатах.)
Поскольку я работаю преимущественно с нидерландцами, то иногда я пишу: "Ik ben Duisternis!"

Fun факт - Dusternis переводится как тьма или темнота. Но стоит опечататься и перепутать расположение букв t и s, то получается Duitsernis, что дословно означает "надгробье для немцев".

Даже не знаю, что круче. 🤔

Касательно недавних новостей, тут все прозаично - с нового года я выхожу на новую работу и буду не абы кем, а Cloud Architect.

Причины, по которым я искал и нашел новую работу, оставим за скобками.

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

А пока я расскажу про штуку, которая меня дико раздражает.
Среди ИТ сообщества любят часто шутить на тему Линукса, как чего-то непонятного, что ты обязан собирать сам.

Как инженер с уже 7-летним опытом хочу развеять эти идиотские сомнения.

Видите ли, в мире серверных операционных систем доминируют лишь две группы: ОС семейства Микрософт (Windows Server со всеми вытекающими и новыми версиями) и так называемые *nix-подобные системы.

Если в плане Микрософта у вас есть только Windows, то никс-подобных систем великое множество - от различных дистрибутивов Линукса, до монстров типа FreeBSD и HP-UX.

Я не буду вдаваться в подробности архитектурных особенностей двух главных конкурентов, но вот главное отличие: Windows готов к работе из коробки и позволяет вам развернуть на нем различное ПО (от веб-серверов и серверов БД до системы удаленных рабочих столов и прочих прелестей).

Линукс же приходит к вам в виде конструктора. Сам Линукс это лишь ядро, kernel, из которого различные вендоры, от HP и IBM до Яндекса и RedHat, разрабатывают свои вариации Линукса.

Это абсолютно не значит, что вам нужно отращивать бороду, надевать столетний свитер и искать шаманский бубен.

Чтобы установить Линукс на компьютер, сервер или виртуальную машину, нужно всего-лишь обладать базовым пониманием работы компьютеров и операционных систем.
С другой стороны Линукс предоставляет огромный набор возможностей по кастомизации операционной системы. Вы можете отключать ненужные модули ядра (например модуль звука или 3D графики - зачем они вам на сервере?), ставить свои ограничения по количество одновременно запущенных процессов или выставлять им приоритезацию ресурсов - это лишь верхушка айсберга из того, что мне приходилось с Линуксом делать.

Про то, что все модные системы виртуализации (кроме Микрософтовского Hyper-V) разрабатывались по философии и логике Линукса, я вообще молчу.

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

Смеюсь и не могу остановиться.

Только что коллега скинул мне ссылку на публичный репозиторий одного проекта, разработкой которого занималось нидерландское правительство.

Проект стоимостью 19 миллионов евро провалился.
Правительство выкладывает его на Github.

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

Учитывая стоимость проекта выходит, что одна строчка кода стоила около 350 евро.

А еще говорят в России коррупция и распил.

Я, однако, мастер давать невыполнимые обещания. Обещал дать вам контент по "плохим" голландским инженерам на той неделе и не сделал.

Ближе к делу.

В первую очередь хочу заявить, что то, что я сейчас опишу вызывает у меня крайнюю фрустрацию. Почему? Потому что западные компании обладают возможностью использовать любые технологии по причине определенной инженерной свободы и наличия необходимого бюджета. Хотите модный новый мониторинг? Вперед. Переехать на облако AWS? А пожалуйста! Поставить enterprise версию Puppet? Пфф.

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

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

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

При всем при этом вторая особенность - голландцы ужасные раздолбаи.
Вы редко увидите местного инженера, задерживающегося на работе. Если время 18.00 и человек сидит за столом - то он либо ждет свой поезд, либо доставку. Расслабленный образ жизни, пожизненная неторопливость и переоцененность work-life баланса в результате выходит в виде проваленных сроков и аварий, которыми занимаются "зеленые" ребята из Network Operations Center, зачастую пытаясь починить то, к чему у них даже доступа нет. Потерянные заказы, упущенная прибыль, за которую, во время моей работы в Рено, готовы были расстреливать, здесь всего лишь - "принеси печеньки и раздай их коллегам". Геймификация работы подпитывают инфантилизм местных и также тешит их чувство исключительности. Отсюда третья особоенность.

В Нидерландах есть мало чего "своего" (если вообще есть). Кухни нет, история закончилась, когда испанцы выбили у голландцев господство над морем, культура заканчивается на Ван Гоге и Рембрандте. Язык - смесь немецкого, английского и французского. Отсутствие своей изюминки в итоге сказывается на поведении местных, и это поведение, поверьте мне как представителю этнического меньшинства, очень похоже на поведение украинцев, армян, грузин, морроканцев и других миноритариев. "Мы лучше, потому что мы особенные."

Как можно донести до человека, что он не умеет работать, если он считает себя лучшим, потому что вместо "Г" он произносит "Х"? Да никак. Экспаты, работающие в командах, где доминируют голландцы, сталкиваются с профессиональной дискриминацией, и в итоге не могут построить карьеру или изменить текущий порядок вещей (который зачастую находится в пагубном состоянии).

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

А пока помните - русский инженер самый сильный. По определению.

И нет, у меня не бомбит. :)

Помните, я упомянул про геймификацию работы? Сейчас, на общем собрании ИТ департамента директор департамента попросил нас нарисовать дом.

Дом, Карл!

Немного расстраивает узколобость интересов коллег.

Когда я ездил на Хакатон, основной темой разговоров вне разработки были либо разговоры о программировании, либо о технологиях. По пальцам одной руки можно пересчитать людей, с кем я разговаривал о чем-то, вообще не связанном с моей профессией.

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

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

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

Подписоты привалило. Люблю такое, надо почаще сидеть на тематических форумах и чатиках. 🙂

Я уже писал раньше, что сменил место работы - теперь я уже не рядовой инженегр, а самый, что ни на есть, Архитектор. Если быть занудой, Архитектор Облачных Решений.

Тут, надо заметить, есть колоссальная разница. Инженер, будь он самым крутым, умным и сильным, собирает новые решения сам, вот этими самыми руками.

У меня опыт с архитектурными проектами был и раньше. Как правило, там приходилось рисовать диаграммы, защищать бюджет, набирать команду, да всеми руками это дело внедрять и собирать.

В последний раз с архитектором я работал в CoolBlue, на своем последнем серьезном проекте по автоматизации выдачи ноутбуков (о чем я уже писал ранее). Парень, часовая ставка которого была 200 евро, за 3 дня со мной на пару собрал вундервафлю, после чего сделал ручкой и растворился с тумане Роттердама.

Тогда я для себя решил, что архитектор это такой нереально умный человек, который знает все и про все (ну или хотя бы 90%). Разумеется таких людей не существует на свете (а те, кто считает себя таковыми - лжецы и подлецы), поэтому логично их разделять на области. Например, архитектор по серверной инфраструктуре, архитектор информационных систем, архитектор баз данных, архитектор сетей и дальше по списку. Но самая заманчивая тема, на которую я буду делать ставку в своей карьере, это архитектор решений (с буржуйского Solution Architect). Почему - напишу чуть позже, надо правильно сформулировать мысль.

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

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

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

После 2 месяцев этакого похода в ИТ стриптиз клуб, наглядевшись на окружающую меня порнографию, я подготовил 4 20-страничных документа - по безопасности, по процедуре CI/CD, по мониторингу и логированию, а также горячо любимые сердцу Definition of Ready и Definition of Done (люди, работающие по Agile поймут).
Итоговым выхлопом из этой документации стали более десятка story по improvement’у.

Коллега же нашел в текущей инфраструктуре столько изъянов, что волосы встают дыбом. Чего только стоят API вызовы по HTTP и 20 аккаунтов разработчиков в Амазоне в FullAdminAccess.

Год обещает быть очень веселым. 🙂

Между делом вновь прибывшим и старичкам напоминаю - идеи, критику, вопросики и пожелания смело отправляйте в телеграм (@ThomasStorm) или на почту thomas.storm@protonmail.com

Есть большая разница между празднованием 8-ого марта в России и в Европе.

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

Так, например, одна дама менеджер любит выкладывать фотки с конференций в стиле “Женщины в ИТ” и “Женщины в менеджменте”. Другая участвовала в инициативе по привлечению женщин не из ИТ сферы, преподавая им программирование на Ruby (не знаю почему, но в Нидерландах очень любят Ruby).

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

Я не могу сказать, что очень жалую “гендерные” праздники. Праздновать 8 Марта, потому что ты выступаешь против “хуемразей” и “спермобаков” (или как там мужчин еще называют в интернете), тоже самое что праздновать 23 Февраля, потому что ты поймал пулю в Афганистане. Так себе повод, если честно.

Тем не менее, пусть мой Линкдин лопается от эстрогена, а Фейсбук от фотографий цветов (хорошо, что я удалил Инстаграм), я все равно поздравлю своих горячо любимых женщин.

Чего и вам желаю.

Прежде чем описать такого персонажа как Solution(s) Architect (далее SA) надо для начала пояснить принципиальные отличия между инженером и архитектором. Писать тут очень много, поэтому буду разбивать

Эти отличия в принципе подходят для всех ролей, например:
- Software Engineer -> Software Architect
- System/Infrastructure Engineer -> Infrastructure Architect
- Database Administrator -> Database Architect
- DevOps/Site Reliability Engineer -> Solutions Architect
- Cloud engineer -> Cloud architect

Пусть эти стрелочки не вводят вас в заблуждение - архитектор не всегда “лучше” инженера.

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

Условный сферический конь в вакууме (будь он Windows или Linux инженером) потратит первые месяцы на изучение конкретно своего (и зачастую только своего) домена (Под доменом понимается зона его экспертной оценки). Проще говоря Linux человечек не полезет в дебри Active Directory или SCCM. Он дойдет до этого (особенно в Scrum команде), но очень нескоро.

Архитектору же положено узнать все - от бизнеса компании и структуры организации до ВСЕХ продуктов и ВСЕХ процессов. Вот тут и кроется главная заковырка - изучить надо все, но запомнить все при этом будет невозможно. Остается достичь какого-то определенного абстрактного “понимания”, как все работает, и, поверьте, это далеко не самое главное. Не ждите, что с вас реально спросят как компоненты работают между собой. Это так же глупо, как спрашивать профессионального ретушера рассказать абсолютно все функции Adobe Photoshop.

Гораздо важнее на стартовом этапе понять не “как оно работает”, а какие причины и история стоят за выбранными системами и технологиями. Одним из моих основных вопросов на собеседовании был “почему”. Знать “почему” гораздо важнее, чем “как” и “что”. Это - первое отличие архитектора от инженера.

Узнав историю, вы сможете понять в каком (плачевном) состоянии находится контора и ее продукты и почему, и как с этим жить и что делать дальше. Запомните и запишите, поскольку это очень важно.
Архитекторов не нанимают, когда все хорошо. (На собеседовании вам об этом, разумеется не скажут, иначе можно спекулировать на зарплате)

Чтобы вы понимали - на дворе 8 марта, а мой коллега архитектор только сейчас закончил с аудитом по безопасности.

Про первое отличие поговорили, приступим ко второму - кругозору.

Инженер знает что-то свое и знает хорошо (иногда ОЧЕНЬ хорошо). Именно поэтому архитектор не всегда лучше - в свое время хардкорный инженер IBM WebSphere мог расчитывать на такую зарплату, которая обычному ИТ архитектору и не снилась.

Сейчас мир неумолимо движется в сторону облачных вычислений и managed services, которые гораздо проще развернуть без определенных навыков. А раз у нас есть сотни разных прикольных штук (баз данных, брокеров сообщений, систем рассылки и приема электронной почты, серверов, поднимаемых буквально в 2-3 клика и т.д.), которые и администрировать даже не надо (на самом деле надо, но это не ваша проблема) - то и требования к специалисту растут.

Тот же экзамен AWS Certified Solution Architect Associate подразумевает, что вы знаете как минимум 2-3 языка программирования, умеете работать с Windows и Linux, знаете BigData, Hadoop, Enterprise Service Bus, Application Architecture, OOP/FP , RESTful API, TCP/IP, VPN… очень много.

Казалось бы, чтобы реально ЗНАТЬ вот это все понадобится угробить 15-20 лет на опыт и успеть побыть в шкуре как сисадмина, так и разработчика.
И по сути архитектор и есть такой парень. Но раз системы стали проще, то и порог в годах становится меньше.
В итоге и получаем, что архитектор знает немного обо всем.

Вторым важным дополнением к кругозору является активность в сообществах. Нужно (вот реально нужно) гонять на всякие конференции и митапы, участвовать в вебинарах, сидеть на форумах и чатиках (Отдельно даже приветствуется участие в open source проектах).

Получаем 3 неоспоримых преимущества:
- узнаем “как там у них все работает”, очень полезно, когда можете узнать инфраструктуру коллеги по цеху без необходимости приему на работу.
- занимаемся пошлым занятием под названием networking - обрастаем всякими связями, налаживаем контакты.
- зарабатываем необходимый навык менторства - архитектор, помимо всего остального может поделиться мудрым советом или наставить на путь истинный.

Казалось бы, звучит это все как детский сад. Вроде умеешь себе серверы настраивать да со всякими там pipeline’ами - уже хорошо, без работы не останешься.

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

Все придется делать.

А кто не хочет… ищите мой пост про сисадмина средней руки в “ООО Рога и Копыта” на 100 человек.

Теперь о третьем - чтобы стать архитектором, нужно БЫТЬ архитектором.

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

НЕЛЬЗЯ:
- Спешить. Нередко талантливый спец сталкивается с проблемой, созданной им самим, потому что в свое время неправильно оценил объем труда или задачу как таковую. Подходите критически к задаче. Если вас попросят построить дом, прежде чем закладывать фундамент, оцените сколько людей в нем будет жить, сколько этажей надо и какое количество ванных надо предоставить.
- Хвататься за несколько задач одновременно. Проектирование требует жесткого фокуса на цели. Если будете отвлекаться на все задачи подряд, уведомления мессенджеров и входящую почту, то легко забудете, что и зачем вы делаете. Выключите звук на телефоне. Спрячьте открытые Вконтакте и Фейсбук. Поставьте музыку на паузу. Спрячьтесь в переговорке, где вас никто не тронет. Положите перед собой лист бумаги и ручку и займитесь своим делом.
- Соглашаться на все требования. Внедрение любого решения требует ресурсов, будь то деньги, время или люди. Продумайте что от вас требуется, прикиньте сколько времени и рук нужно на решение задачи. Если задача кажется слишком большой - разбейте ее на несколько этапов. Если вас просят собрать вундервафлю за пару часов, говорите “НЕТ”. Если к вам подошел разработчик и просит вставить небольшой скрипт в CI/CD, говорите “НЕТ”, пока не убедитесь, что этот скрипт не ломает всю структуру.

Собрав все воедино, могу сказать, что чаще всего из ваших уст будут сыпаться слова “нет” и “почему”.

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

Приступим к можно (а точнее НУЖНО).

НУЖНО:
- Учиться. Я уверен, вы слышали из каждого утюга, как надо много много учиться, и, к сожалению, это правда. Со скоростью развития технологий, чтобы стать первым парнем на деревне придется очень много и очень быстро учиться. К счастью, многие сервисы предлагают определенный free tier, когда можно пробовать систему в промышленной эксплуатации, не заплатив ни копейки. Впрочем, я настоятельно рекомендую инвестировать в собственное развитие хотя бы 10 евро в месяц.
- Предлагать что-то новое. Какой бы идеальной ни была компания и продукт, всегда можно что-то сделать лучше.
- Не бояться ошибок и экспериментировать. Не бойтесь тратить время на освоение новой технологии, обкатывайте ее локально и в тестовом окружении. Даже если все время будет потрачено впустую, вы получите бесценный опыт.
- Критически относиться ко всему новому. Все модные свистелки и перделки были в основном придуманы крупными компаниями: Kubernetes, он же Borg, был придумал Гуглом для Гугла, ReactJS и GraphQL придумали в Facebook, kPHP во Вконтакте. То что кто-то что-то написал и успешно внедрил у себя, не значит, что это подойдет вам. Тот же Амазон перенес инфраструктуру своего бизнеса на AWS только в 2010-ом году, когда тот функционировал уже лет 6, а Фейсбук все еще сидит на своих ЦОД’ах и уходить от них не планирует.
- Отталкиваться от нужд бизнеса. Когда вас просят спроектировать облачную инфраструктуру, посмотрите на это со стороны бизнеса. В каких странах планируется “продавать” продукт? Как там обстоят дела с регулированием? Сколько планируется привлечь клиентов? Какой ожидаемый рост данных? Что делать с архивными данными? Ответьте на эти вопросы сейчас, чтобы не рвать на себе волосы потом.
- Думать о расходах. Хороший архитектор отличается от плохого тем, что его решение будет таким же крутым. но еще и дешевле.
- Не бойтесь делегировать и просить о помощи. Как я уже писал раньше, опытный инженер знает нечто (сервер, СУБД, сервер приложений) лучше вас, и это НОРМАЛЬНО.

Список можно продолжать бесконечно и важно понимать, что это не silver bullet. Даже если вы освоите все хард и софт навыки, вам все равно не гарантируется должность.
К сожалению, наш мир настолько неидеален, что вам вообще ничего и никогда не гарантируется.

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

А пока еще раз напоминаю, что все вопросы и предложения можно смело слать на @ThomasStorm