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

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

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

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

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

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

Многие разговоры про “выход из зоны комфорта” в основном про усложнение простого процесса. Но в этих разоговорах упускается важная деталь - нельзя переступать через черту “слишком сложно”. Для интереса должно быть умеренно сложно.

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

Как вам парад оригинальных шуток про пуши в Линкедине?

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

Чтобы не повторять автора видео в попытках упрощенного но успешного ремейка, приведу еще более древние примеры, чем “Ромео и Джулльетты”. Есть популярное мнение, что прототипом средневековой Золушки является гетера Родопис, жившая предположительно в VI веке до нашей эры. По некоторым источникам ее похитили пираты и продали в рабство в Египет. Аналогом туфлей после балла является одна из сандалей, которую похитил орел и принес в Мемфис.

Или вот шумерский миф о всемирном потопе и Утнапишти, который построил корабль и собрал мастеров и животных для выживания (с мемами можно прочитать тут). Причем есть основания считать, что тот же шумерский Гильгамеш является прототипом Геркулеса. Если первый был дветретибогом, то последний - полубог. Чем ближе к современности, тем больше сил теряют герои мифов. В последних интерпретациях от Дисней Геркулес совсем становится посмешищем.

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

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

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

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

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

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

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

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

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

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

При прогнозировании времени, которое мы потратим на реализацию проекта или задач, важно учитывать фактор сопротивления. Если представить разработку в виде графика, то требуемый результат - планка на оси ”y”, время будет на оси ”x”, а начало разработки на нулевой точке (0, 0). (На самом деле ближе к правде дерево, но если не упрощу, я никогда не объясню). Сам процесс будет выглядеть линией от (0, 0) до планки. Если вы чересчур оптимист, это будет прямая линия, если более реалистичны, то кривая.

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

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

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

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

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

Скинули в группу друзей ссылку на статью.

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

Если хотите жизнь как в Катаре, предлагаю вам собраться с соседями и замутить какую-нибудь тему. Субботник может, собрать на ремонт, договориться о чем-то. Где будет легче договориться, в клубном доме на 30 квартир, или в ЖК на 300? А если между подъездами в ЖК расстояние не 10 метров, а километр? Где тогда будет дешевле проложить интернет, в компактном клубном доме, или в просторном полупустом ЖК? Какой дом легче держать в чистоте?

Ладно соседи. Как часто вам удается собрать друзей на посиделку? Пробовали собирать деньги на мероприятие? Все ли сдавали в срок без напоминаний? Как часто у вас собирается команда на 5 человек в Доту или КС? Или 6 человек на футбол. Когда играли в настолки, вы не ругались и не спорили? Если не ругались и не спорили, часто собирались?

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

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

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

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

Теперь давайте будем использовать этот вирус для благих целей, то есть попробуем натренировать иммунитет.

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

К примеру вы фронтендер вымышленного портала госуслуг на 20 миллионов юзеров под названием EA gov. Причем эти юзеры самые разные, под каждого нужно сверстать (а еще и в базу данных сохранять) особенную форму. Хорошо если этих форм 20 будет, а не больше. И вот бекэнд постоянно глючит, какой-то там тимлид получает премию почти не работая, рубит 2 ляма тенге, как вы думаете. Сайт ваш работает кое-как с горе пополам, пользователь в первую очередь винит вас, как и посетители кафе жалуются на официанта за плохо приготовленное блюдо. Портал на 3 языках, то есть работа усложняется в степени куба. Премию дают выборочно, тимлидам, либо прям хорошо показавшим себя. Но если давать премию всем, то выйдут совсем копейки, причем дав всем вообще не ощущается эта премия.

И существует прекрасный портал госуслуг в некой стране Qutur, юзеров 400 тысяч. В 50 раз юзеров меньше, прикиньте! Это типа если EA gov нужно 50 серверов, то здесь всего 1. Все юзеры одинаковые, форма одна. Язык портала 1. Каждый квартал каждому разрабу дается премия, она ощутимая, можно сказать получают 20 зарплат на 12 месяцев. Но и даже без премий уже хорошо живется. У них последние маки и установлены таск трекеры. Им ок, что их трекают, ведь они получают немыслимые деньги за это. Да и что там трекать, таски вообще изейшие. Офис окружен водой и тонкой границей суши. То есть на охрану не надо тратиться много. Офис небольшой, камеры обслуживать легко. Обслуживание здания ты отправил на аутсорс, а им уже выданы условия гораздо хуже. Но им ок, ведь они все равно приходят работать.

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

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

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

Почему нельзя спрашивать в тематических чатах советов про выбор технологии?

Попробую помочь начинающим айтишникам ответить на вопрос “куда пойти, какую технологию выбрать”? Очень много вопросов в тематических чатах вижу.

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

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

Третья проблема в ответственности. Этот вопрос должен определить ваши шаги на пятилетия, а то и десятилетия. Это вам не вопрос о правильной покраске кнопки. А айтишники (не только, много кто тоже) мнение свое любят, обожают делиться, по поводу и без. Гляньте Линкедин на досуге, если хотите убедиться. Околомиллионские зарплаты разрабов могут прибавить много очков к убедительности их слов.

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

К примеру спросив у ChatGPT, он с вами поделится зоопарком технологий, которые слабо будут вязаться друг с другом. Да и я сам не все из этих тем знаю, а я 8 лет уже как айтишник. А вы как начинающий все это быстро не освоите. Времени у вас мало, а те кто не спрашивают и просто делают, займут место, на которое вы можете метить. Люди, выбравшие технологию и слепо изучающего без сомнений, имеют высокий шанс быстро устроиться, как вознограждение за риск. Но выбрав конкретную технологию неудачно и потратив год (примерный необходимый минимум для дефолтного новичка), вы можете промахнуться, некоторые вложения могут не окупиться, из всего материала хорошо, если 20% еще в будущем воспользуетесь. К примеру в геймдеве много энтузиастов и мало рабочих мест, привычные бизнес задачи и задачи в геймдеве сложно коррелируются. Выбрав геймдев, перейти на разработку банковских приложений не так гладко. Если вы умелый ладно, а если нет?

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

(Продолжение дальше)

(Начало поста)

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

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

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

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

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

Предлагаю слеующий настрой, чтобы не топтаться на месте. Ваша цель - выпустить проект, чтобы кто-то пользовался. Легче всех для семьи, друзей или сокурсников. Вы знали, что вконтакте изначально создан для группы Павла Дурова в универе? Забудьте про захватывание мира, про ошеломительный успех других проектов. Второй Вконтакте делать не предлагаю, даже наоборот, отговариваю. Сделайте что-нибудь для близких, чтобы заинтересовать их, чтобы хотя бы раз в месяц они хотели пользоваться.

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

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

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

Если представить, что MVP продукта это ячейка 2048, то мелкие ячейки являются компонентами, которые нужно "сложить" в ячейку сложнее. Типа связать UI с бекэндом. А само поле является нашим кэшем - все то, что мы можем помнить и знать о проекте.

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

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

Уже из объяснения проблемы можно сделать вывод, что играть стоит "змейкой". Это значит стремиться выстроить ячейки по нарастающей. Если условиться, что ячейка с самым большим значением будет в правом нижнем углу, то следующая ячейка должна быть прям перед ней, во справа от нее. И так далее. По возможности нужно заблокировать движения максимальной ячейки влево, чтобы не нарушать последовательность. Что значит справа от этой ячейки нужно заполнить другими ячейками. Так мы локализуем нашу работу до поля 3x4, что упростит нам работу.

Если мы условились, что 2048 это MVP, то продолжение игры - соответственно продолжение и проекта, который может длиться очень долго. Взглянув на эту игру, легче принять мысль, почему костыляя можно быстрее дойти до 2048, но невозможно дойти до 8192. А если действовать последовательно, то мы будем медленными, но 8192 мы можем гарантировать.

Про ChatGPT.

У меня есть друг, у которого проблемы со сном (как вы видите по времени поста, сегодня у автора тоже не все в порядке). Был период, когда он принимал в виде таблеток мелатонин (гормон сна). Тогда я шутил, что его организм не справляется со сном (сейчас автору не смешно) и теперь он пользуется услугами аутсорса. Если посмотреть под определенным углом, то люди некоторые свои навыки тоже переносят ChatGPT как на аутсорс.

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

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

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

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

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

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

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

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

Вместе с вашими оригинальными мыслями эти дополнения помогут создать более всесторонний взгляд на роль и влияние ChatGPT и других ИИ в нашей жизни."