Оценок пусть сыпется минусов град,
Стою я и мир созерцаю..
И пусть не святой я и пусть виноват,
И ладно чего-то не знаю..

Оценки даются другими за то,
Что сами они понимают..
И минусы это по сути лишь то,
Что люди в себе отвергают

Лайфхак для начинающих разработчиков: уделите время изучению Английского

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

Это нужно чтобы получить преимущество на страте и забрать +100 к пониманию кода, документации, книг, статей и видосов по разработке. (И того что дают на выходе вайбкод-инструменты тоже.)

Очень многое завязано на английский в IT-мире, и названия железок, технологий и абстракций взялись не из воздуха, а как отсылки-аналогии на другие реальные объекты.

Например Server - это не только привычный нам сервер, а еще и официант. А Client - это клиент заведения. А заведение предоставляет Service.

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

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

Для того чтобы прокачаться в инглише много не надо. Банально можно поставить себе Duolingo и играться с ним по 10-15 минут каждый день. И этот простой шаг поможет не только изучению английского, но и программированию.

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

Let's start!

Sveta and Maxim walk in the city center.

"I'm hungry and want to eat," said Sveta.
"See, there's a cafe nearby; this cafe provides good service," said Maxim.

Maxim is a regular client of this cafe, and he likes its service.
They enter the cafe.

"Hi, Maxim," said the server Maria.
"Hi, Maria, menu please," said the client Maxim.

The server Maria gives them the menus.

Client Maxim orders a cake and tea.
Server Maria receives the order.
Client Sveta orders a hamburger and coffee.
Server Maria receives the order.

Then, server Maria passes the order to the cook Leonid.
Then, Leonid prepares the food for the clients.
After a while, server Maria passes the tea and cake to client Maxim.
And then, server Maria passes the coffee and hamburger to client Sveta.

Next, client Sveta eats her hamburger, and client Maxim eats his cake.

"I'm so happy, dear," said Sveta.
"I'm happy too, honey," said Maxim.

"Thank you for the good service, Maria," said client Maxim.
"You are welcome, Maxim," said server Maria.

The End :)

Делитесь своими мыслями и опытом в комментариях, хорошего вечера :)

P.S. Ну и сводите кого-нибудь в кафе на свидание, чтобы прочувствовать атмосферу метафоры, так лучше запоминается 😊

P.P.S. Проверка на внимательность: как зовут спутницу Максима, Света или Мария?

Есть ли смысл спрашивать моб.разработчика про устройство хештаблицы?

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

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

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

И биг О это..

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

Где здесь здравый смысл?

Вместо этого лучше спрашивать напрямую про оптимизацию времени выполнения и использования памяти.

А единственный вопрос который следует задать мобильному разработчику про хештаблицы - это используешь ли ты в качестве ключей что-нибудь кроме примитивов?

Нет - проходишь, да - ну ка расскажи тогда про хештаблицы голубчик.

Хотя я бы сразу такого взял на заметку. Ибо незачем в ключи совать то что не предназначено быть ключём, мы же с базами данных так не делаем? (Или у кого-то это бестпрактис? Тогда делитесь в комментариях для расширения кругозора 😁 )

Как я понял про хешмапы спрашивают 2 вида людей:

1. Каргокультисты, "а зачем ты спрашиваешь?", а все спрашивают и я спрашиваю, говорят что это "бла, бла, бла", и для здоровья полезно. (Так много чего для здоровья полезно 😁)

2. Те кто пару раз пихал таки в качестве ключа какую-нибудь дичь и потом отлаживал это дело пару недель, и теперь транслирует свою боль на весь мир. (Понимаю было больно, но это прошло, можно отпустить)

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

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

Или нет?

Размышлял на тему стартапа в HRTech и вот к чему пришел:

Веб.сервисы, моб.приложения, чат‑боты — это по сути автоматизация процессов.

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

(Это называют галлюцинациями, когда людям кажется одно, и они выстраивают вокруг этого инфраструктуру, бизнес, стартап, жизнь, а на самом деле происходит другое и всё сделанное идет в минус. Конечно, есть и плюсы, на ошибках учатся и заводят знакомства, сам так делаю 😁)

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

Продолжим:

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

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

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

Ок, давайте посмотрим на то как происходит наем в других сферах?

1. Нанимая аниматора для ребенка я ориентируюсь на запросы ребенка и портфолио аниматора. Это если я смотрю на хотели ребенка, а если я смотрю на хотелки окружающих то я буду ориентироваться на сарафанное радио и оценки знакомых и незнакомых.

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

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

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

Список можно продолжить. И будет плюс-минус так же.

Почему бы нанимая разработчика моб.приложений (или других IT-специалистов) не сделать так же?

Зашел на хедхантер\хабркарьеру нашел тех кто матчится по стеку, запросил 10-30 портфолио, прозвонил рассказал про задачу, побеседовали пригласил на свидание.. Тьфу ты, на свидание говорю мальчишка, на работу конечно же.

И никакой стартап не нужен, все уже есть 😁

А если захочется сделать мега-супер-дупер-сервис то можно сделать сайт с витриной разработчиков, их стеком и портфолио, и статусом свободен-занят, готовность выйти на работу и цену поездки.. «машина приедет через 10-минут, поездка займет пол.часа», можно даже что‑то типа Uber замутить (или типа Tinder). А с другой стороны сервиса разработчикам будут прилетать заказы.

Если же компания захочет нанять себе «личного водителя», то можно пригласить «водителя» прямо во время поездки. Аналогия с сервисом знакомств еще интереснее 😁

Делюсь идеей — пользуйтесь, и обязательно пригласите меня на тест-драйв если сделаете, буду рад!

Можете считать что я ваш первый клиент, так что рынок есть :)

P.S. Я кстати говоря сейчас в ленивом поиске, открыт для предложений и новых возможностей, так что пишите в тг если что, обсудим сотрудничество: @alex_ku_san

P.P.S. Говорят что я изобрел Mercor. Из поиска: Стартап ИИ-рекрутинга Mercor привлек первые $100 млн и получил оценку в $2 млрд. Значит идея в целом интересная :)

Я размышлял над созданием инструмента для вайбкодинга и вот что я понял:

Вайбкодинг — это менеджмент.

Со всеми его плюсами и минусами.

У менеджмента фокус на управление.

У разработки фокус на конструирование.

Для менеджмента нужны прокачанные скилы общения (говорить, слушать, писать, читать на человеческом)

Для разработки нужны прокачанные скилы разработки (говорить, слушать, писать, читать на программном)

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

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

Просто в какой-то момент станет не хватать рабочих рук и бизнес начнет разваливаться.

Если повезет то Волки-разработчики вырастут за это время и затащат поставленные задачи. Если нет то придется таки найти способных для этого людей.

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

Да и в конце-концов полочку прибить на кухне давно пора 😁

Тут же время для чтения книг, спорта, прогулок, творчества, хобби и свиданий..

Я вот стихи пишу например и Suno AI мне делает клубную музыку на их основе, мне нравится :)

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

А на момент когда позовут у нас уже будет прокачана 2-я профа, широкая душа (и кругозор), стабильная психика, любимые люди вокруг и экспертиза в новых технологиях пока они там с легаси копаются 😁

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

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

Благо в жизни есть и другие интересные дела и возможности.

Обнял 🤗

P.S. Я знаю что это не напрямую по теме моб.разработки, а около сложившейся ситуации в наеме в моб.разработке, ну и что? А где мне об этом писать как не в среде моб.разработчиков, частью сообщества которых я долгое время был? Так что пишу здесь и точка 😁

P.S. 2: Благодаря этому всему я опробовал Flutter на паре своих проектов и затем подсел на Compose Multiplatform. Сделал пару простых игр под мобилки в качестве эксперимента. Спроектировал маркетплейс как Avito от начала и до конца. Изобрел пару новых архитектурных решений. Придумал свой язык программирования и пилю среду разработки для него. Стартап запускал даже Structure Compositor для автоматической генерации кода по макетам. Пробую и экспериментирую с возможностями ИИ. Научился готовить - это прикольно, мне прям нравится. Ой, еще работ несколько разных перепробовал, начал больше гулять на природе, да много всего..

В общем живу насыщенной жизнью философа и любителя жизни, почти как в отпуске только за свой счет 😁

Давайте помечтаем или как я вижу адекватный мир трудоустройства в будущем:

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

Для разработчика моб. приложений например нужно подтвердить что ты можешь делать моб.приложения и что ты можешь делать их с использованием Jetpack Compose (выбрал пример из своей сферы Android-разработки потому как она мне близка, можно провести аналогию для других сфер). Понятно что ключевых компетенций и инструментов для их применения может быть больше.

Собеседование проходит в рамках любой компании которая возьмется это собеседование провести. Ключевые компетенции и инструментарий для каждой компетенции обговариваются перед собеседованием. Если соискатель и работодатель совпадают по ключевым компетенциям на 80% и более, и по конкретному инструментарию на 60% и более - проводится собеседование.

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

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

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

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

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

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

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

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

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

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

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

Соискатель соглашается на эти условия или нет.

Предложение оффера и согласование ЗП тоже происходит при личной встрече. Записывается на видео и может быть переиспользовано как соискателем так и компанией.

Работодатель имеет право предложить новый оффер через 7 дней. (Эти 7 дней можно затратить на обдумывание стратегии бизнеса и согласование бюджета)

Соискатель в решении о ЗП руководствуется своими реалиями и возможностями рынка.

3. Соискатель может найти работу на сайте компании без использования сторонних сервисов.

Каждая компания выставляет в открытый доступ список вакантных мест (3 разработчика, 2 дизайнера и т.п.)

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

Вот как-то так, такие мечты :)

Я думаю это позволит изменить ситуацию на рынке труда в лучшую сторону, на пользу и сотрудникам и компаниям, а что думаете вы?

P.S. Вообще конечно лучше вообще собеседования отменить. Давать на выбор: сделать ТЗ или отправить портфолио с проектами. А собеседования проводить только с целью знакомства.

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

Так как дело обстоит сейчас - никуда не годится.

IT-специалистов за людей не считают, независимо от стажа и ранга, будь ты junior, middle, senior или teamlead, ты сталкиваешься с проблемами при трудоустройстве.

Понятное дело что мы уже попривыкли к такому обращению, но разве нас это устраивает?

Меня - нет.

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

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

Но мы то не заключенные, мы то слава богу свободные!

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

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

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


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

Вспомнил холивары на первой работе на тему: что такое Activity?

Тогда, среди Android-разработчиков, в моде была MVC и общение было примерно такое:

"Activity - это контроллер" - говорили одни.

"Activity - это вью" - говорили другие.

"Activity - это модель" - так к сожалению никто не говорил, иначе было бы еще интереснее 😁

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

Кто из них прав?

Никто.

Или и те и другие.

Правильный же ответ такой:

Я создатель приложения и какую роль я дам этому классу(Activity) такую он и будет выполнять.

Это если смотреть со стороны архитектуры приложения.

А если смотреть со стороны OS Android, то Activity - это интерфейс через который пользовательское приложение взаимодействует с операционной системой.

Вот и всё :)

P.S. А какие холивары вспоминаются вам?)

Размышления визионера про идеи, задачи и реализацию:

Сначала появляется задача, запрос.

Затем появляется идея как эту задачу реализовать, ответ, наводка, подсвеченное решение.

Реализация идеи - это уже другая задача.

Т.к. запрос ставится обычно на конечное, сформированное решение, то в ответе тоже показывается сформированное решение.

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

И этот шаг не обязательно реализация продукта. Это может быть и использование уже чего-то существующего.

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

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

P.S. можно потренироваться на поисковых запросах, промтах к нейронкам и на задачах людям 😁

Пост о том как я разработчиков нанимал, история из жизни :)

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

У меня большой опыт в мобильной разработке, в основном нативный Android приправленный мультиплатформой на Compose Multiplatform и Flutter.

Руководитель компании попросил меня помочь сформировать команду Android-разработки на доработку и поддержку достаточно масштабного и сложного проекта X.

Проект тащил свое приятное но от того не менее сложное Legacy: многомодульность, Clean Architecture, DI, MVVM, Kotlin, Coroutines, Flow работа с БД и клиент-серверное взаимодействие - в общем популярный набор современного бизнес-приложения.

Строго говоря у меня было две задачи:
1. Помочь джуниору разобраться в проекте чтобы он мог уже что-то делать
2. Набрать команду нативных Android-разработчиков

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

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

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

Идем дальше:

Эйчары стали лить на меня трафик из соискателей на должность Android-разработчика. И на протяжении 2-х недель я каждый день собеседовал по 2-3 кандидата, иногда 1-го. Уровень у всех очень отличался. Приходили как совсем свежие пирожки прямо после курсов, так и уже матерые обкатанные на серьезных проектах колобки. У меня был стек проекта и потому вопросы тоже считай были сформированы, диалог строился так: Привет-привет, расскажи про свой опыт, и от этого опыта погнали ветвиться по темам в сторону нужных компетенций и стека. С кем-то укладывались в 30-минут, с кем-то залипали на 2 часа. Т.е. с кем-то шли дальше в глубину, а с кем-то прошли по верхам и на этом все.

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

Чтобы как-то передавать то что я узнавал в процессе собеседования о кандидатах, мы ввели оценку, грубо говоря число от 1 до 5, насколько человек подходит на проект + моя рекомендация. Дальше уже другие люди делали какой-то оффер на работу, или не делали.

В итоге за 2 недели мы наняли 5 человек, + тот разработчик что изначально был на проекте с моей (и божьей) помощью вкатился в проект и начал работу по задаче.

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

Я еще пару недель занимался онбордингом на проекте + выступал адвокатом разработчиков + переводчиком с менеджерского на разработческий и обратно, та еще задачка 😁.

1-н нанятый стажер в итоге не потянул и отвалился, остальные 5-ро продолжили работу, уже без меня, а я отправился дальше :)

Я переписывался с товарищем на тему архитектуры и сформировал более цельное понимание построения ООП-кода :)

Чуть-чуть обо мне: в разработке 12+ лет, сделал 50+ различных приложений и ещё немножко игр, это только для бизнеса, плюс еще мои личные эксперименты и petproject-ы.

Делая все эти приложения я пришел к тому что есть разные подходы к проектированию\моделированию систем, в частности с помощью ООП-кода:

(Условно назову эти типы в игровой терминологии так как разговор был с человеком из геймдева и игры мне тоже близки, кстати, я и программировать то начал чтобы делать игры 😁, итак вот эти подходы: )

1. "Action" - когда ты описываешь объекты как будто смотришь на описываемую систему изнутри (вид из глаз), фокус на взаимодействие объектов между собой в моменте, моделируются в первую очередь сущности и упускаются процессы.

2. "Strategy" - когда ты описываешь объекты как будто смотришь на описываемую систему снаружи (вид сверху), фокус на процессы взаимодействия всех объектов в жизненном цикле приложения, моделируются в первую очередь процессы и упускаются сущности.

3. "God Mode" - когда ты делаешь все что душе угодно (читай как и то и другое, "Action" и "Strategy" в одном флаконе)

И так же я пришел к тому что есть несколько слоев моделирования\проектирования:

(как сказали бы в Теории Систем - есть надсистема, есть система и есть подсистема, а Шрек описал бы это как слои лука, а Осел рассказал бы что это напоминает слоёный торт 😁)

1. Уровень реальности в которой есть человек пользователь, используемый девайс (десктоп, ноутбук, смартфон, и т.п.), сервер с бэкендом; правила их взаимодействия (интерфейсы, протоколы, договоренности); и процессы в которых это взаимодействие происходит (циклы, цепочки событий, потоки данных)

2. Уровень приложения в котором есть сущности бизнес-логики(игровой логики), например Hero, Enemy, Obstacle, Menu, Map, Score; правила их взаимодействия; и процессы в которых происходит взаимодействие

3. Уровень инструментов в котором есть сущности языка программирования такие как примитивы(Int, Long, String, Bool), структуры данных, основные компоненты игрового движка(операционной системы); правила их взаимодействия; и процессы в которых происходит это взаимодействие

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

На каждом слое может использоваться как ООП подход так и ФП, так и нечто смешанное что добавляет удобства.

К чему это все? Наш разговор начался с того что я вбросил мнение что самая чистая архитектура обычно это чистейший ООП-код, и удобство архитектуры зависит как раз от навыка моделирования систем этим ООП-кодом.

Такие дела :)

Я по прежнему считаю что ООП рулит! 😁

А что думаешь ты про ООП, архитектуру и чистый код?

Делись своим опытом в комментариях, или нет..

Проблема: Кадровый голод по специалистам, и при этом рекордные количества откликов на вакансии.

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

Общее решение: Изменить процесс наема так чтобы он помогал нанять специалиста для решения задач бизнеса.

Конкретные варианты решения:

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

2. Устранить причину мешающую текущему процессу наема. Например сократить цепочку ЛПР-ов на пути соискателя до оптимума.

   (Сейчас это авто-скрипт, эйчар(или ряд эйчаров), собеседующий специалист(или ряд специалистов), представитель команды(или ряд представителей), опционально тут еще какие-то посредники, и вот тут уже можно выйти на работу и работать 😁. Причем на каждом этапе у лже-ЛПР-ов есть цель отсеять человека на основании формального фильтра. Тогда как лучшие работники обычно "неформалы" ибо они про работу работать как Стив Возняк, а не про продукт(себя) продавать как Стив Джобс. Очевидно что не каждая птица долетит даже до середины.. 😢)

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

   ЛПР - это тот кто принимает решение что считает лучшим на этот момент, а не тот который работает по прописанному скрипту (иначе это не ЛПР, а человек которого настоящий ЛПР назначил отрабатывать строго по скрипту 😜).

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

P.S. Все 3 варианта решения на самом деле про одно и то же, только заход с разных сторон: убрать не то что мешает обрабатывать заявки на чиле, в пол уха, левой пяткой, а убрать то что действительно мешает нанять сотрудника для решения конкретных задач. (Да стало много спама, ну и что? Разве то что много спама говорит о том что среди спама нет специалистов способных делать работу? Нет. Как раз таки в этом и заключается задача\работа нанимателя - нанять сотрудника в этих конкретных условиях. Ну да, придется поработать. Соискатель, наниматель и работодатель в одной лодке как ни крути, если кто-то не хочет грести, то далеко ли уплывет такая лодка?🛶)

Хорошего дня, наема и трудоустройства!

Обнял 🤗

Я исследовал тему связности и связанности в построении кода и вот к чему пришел:

Не существует плохих\хороших\идеальных связности и связанности кода.

Мне кажется проблема и решение глубже - сколько людей столько и вариантов осмысления и построения "модели", столько вариантов же coupling & cohesion. У каждого что-то свое.

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

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

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

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

Ну и когда я говорю ООП, это не значит что я буду писать абстракцию на каждый чих, влоть до Int, Long и т.п., нет, это значит что я начну с самых больших MyApp { UserClient, ServerClient, DeviceClient } и законтачу их между собой логикой приложения, а там дальше буду создавать абстракции по необходимости, если будет удобно и полезно что-то добавить и переиспользовать то я добавлю и переиспользую (вот кстати хороший критерий - моделировать сущность когда надо что-то передавать между главными абсракциями(надсистемами)).

ООП рулит :)

P.S. И не надо стремиться к идеалу, иначе тут можно скатиться в подмену задач, и начать делать не данное конкретное приложение, а предложенный кем-то идеал архитектуры.

Дело не в том как ты проходишь собеседование

Дело в том хочет человек тебя нанять или нет

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

Так что не парься, будь счастлив 😁

Воспринимай собеседования не как путь именно к этой работе, а как путь к чему-то вообще :)

В любом случае этот шаг делает тебя на шаг ближе к цели

Если ты не прошел собес, то выбор простой: сражайся с этим или наслаждайся этим, и даже если сражаешься, то насладись сражением 😁

P.S. И так во всём..

Вопрос: оцени сколько времени займет выполнение задачи?

Оценка - это, по определению, предположение.

Так что какое число ни назови столько и будешь работать до следующего такого вопроса 😁

Решил посмотреть курс по обучению нейросетям, и вот что я осознал:

Курсы по нейросетям - это по прежнему бизнес продающий курсы.

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

Само же обучение работе с нейросетями не требует какого-то специального обучения.

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

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

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

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

В общем не надо особо чему-то новому учиться.

Просто делай то что делал до этого, только с использованием новых AI инструментов.

В своей предметной области, в своей теме, для своих задач.

Вот и всё :)

P.S. Основная польза курса как мне кажется - это история "Путь героя", которая подсвечивает варианты как это может быть и дает новую инфу(для кого-то), которая может подсветить какие-то новые инструменты. Все это есть как в платных курсах так и в свободном доступе. Ну еще автор работал над структурой. Но в жесткой структуре есть как свои плюсы, так и свои минусы.

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

Я размышлял про трудоустройство и наем, как нанять сотрудника в IT и как устроиться на работу в IT и вот к чему пришел :)

Я много встречал видео и статей "как пройти собеседование", "как получить работу" в IT.

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

По факту все сводится к семантике (привет Жаку Фреско) - каждый из нас говорит на своем языке, на языке своего опыта, на языке своего мышления, на языке своего локального карго-культа.

Или проще - люди не понимают друг-друга и только строят свои догадки относительно друг-друга.

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

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

С другой стороны, соискатели, технари, айтишники - тоже люди :)

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

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

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

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

Если я например хочу делать мобильные приложения, а бизнес хочет сделать себе мобильное приложение - то мы уже матчимся, подходим друг-другу для достижения наших целей, осталось только договориться о деталях. "Ты будешь делать достойное приложение 8 часов в день, 5 дней в неделю, по нашим задачам", "А ты за проделанную работу будешь платить мне достойную зарплату и содействовать в решении любых вопросов связанных с работой"

Справедлив вопрос: "а справится ли соискатель или он на словах такой герой?"
Справедлив и обратный вопрос: "а справится ли работодатель или он на словах такой герой?"

Ответ в обоих случаях очевиден: заранее неизвестно и можно только строить предположения.

Есть 3 простых способа чтобы понять, а может ли человек делать, то что он делать хочет:

1. Посмотреть на предыдущий опыт соискателя, на портфолио проектов (так же как и на предыдущий опыт работодателя, на портфолио проектов)

2. Тестовое задание, если вдруг нет портфолио, или есть сомнения по портфолио.

3. Испытательный срок, стажировка на проекте, во время которой станет действительно понятно что из себя представляет сотрудник (за одно и онбординг и притирку пройдет на лайте)

Хм.. А какое тестовое задание и испытательный срок дать работодателю? :)

(P.S. Но не один из этих способов, так же как и любые другие, не гарантирует 100% совпадения ожиданий с результатами, потому что ожидания это больше про вымысел, а результаты достигаются систематическими действиями с целью этих результатов достичь, и делают эти действия реальные люди со всеми их достоинствами и недостатками, а не идеальные кандидаты)

Говорят Сократ так говорил: «Женись непременно: если будет хорошая жена — будешь счастливым, если плохая — станешь философом»

Я сделал так, и могу сказать что Сократ был прав во многом, в том числе и в этом :)

Я проснулся, делал зарядку и размышлял о поиске работы, и вот что я осознал:

Эйчары не понимают бизнес.

Бизнес не понимает эйчаров.

Эйчары не понимают технарей.

Технари не понимают эйчаров.

Бизнес не понимает технарей.

Технари не понимают бизнес.

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

Делегирование делегированием, а эффективность эффективностью.

Еще:

Бизнес конкурирует с бизнесом.

Эйчары конкурируют с эйчарами.

Технари конкурируют с технарями.

И все конкурируют со всеми.

Как следствие - на технических собесах технари с обеих сторон стремятся доминировать друг над другом. Так как решение о наеме принимает собеседующая сторона, то она имеет преимущество над соискателем и ему приходится подстраиваться.

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

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

Выводы:

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

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

Такие дела.

Вот еще интересные мысли о наеме, с которых все началось:

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

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

Понимают ли они то что происходит во всей полноте? Похоже что нет, иначе процесс был бы устроен другим образом.

А происходит следующее: соискатель приходит на собеседование, обучается на нем правильно отвечать на вопросы, если проходит то устраивается на работу, если не проходит, то идет на следующее собеседование, и так пока не устроится.

Т.е. фактически компания которая дала отказ соискателю, затратила ресурсы, обучила соискателя, и передала его другой компании. Вот что происходит на самом деле.

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

А теперь вернись к началу, вероятно теперь станет понятно откуда взялись такие тезисы :)

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

Откуда такие мысли:

Я уже 12 лет как в теме, и устраивался на работу сам, и искал людей на свои проекты, и собеседовал как технарь(в Android разработке) на проекты бизнеса. В общем я пощупал этого слона с разных сторон, и теперь когда я снова в активном поиске - это сложилось в объемную картину.