Ребята, а есть кто-то с очень хорошим английским?
У меня уже полгода в полунаписанном состоянии несколько статей и я все боюсь их опубликовать т.к. боюсь что они выглядят неграмотно с точки зрения языка.
Так вот. Я ищу человека который поможет мне в редактировании статей о программировании и дизайне на английском. Нужно будет отредачить (совместно со мной) и высказать свое мнение/критику. Желательно джуновый или мидловый уровень в айти.
С меня - менторинг / подготовка к IT собесам / алгоритмы / ну или просто деньги ^^ кто заинтересон напишите пожалуйста в пм или комменты ваш уровень инглиша / IT и чего бы хотелось получить взамен.
У меня уже полгода в полунаписанном состоянии несколько статей и я все боюсь их опубликовать т.к. боюсь что они выглядят неграмотно с точки зрения языка.
Так вот. Я ищу человека который поможет мне в редактировании статей о программировании и дизайне на английском. Нужно будет отредачить (совместно со мной) и высказать свое мнение/критику. Желательно джуновый или мидловый уровень в айти.
С меня - менторинг / подготовка к IT собесам / алгоритмы / ну или просто деньги ^^ кто заинтересон напишите пожалуйста в пм или комменты ваш уровень инглиша / IT и чего бы хотелось получить взамен.
Опубликовал небольшую заметку о том, как проектировать бд с OLTP-подходом. Наверное следующая будет о том, когда и зачем нужна денормализация.
https://hackernoon.com/principles-of-a-clean-relational-database
https://hackernoon.com/principles-of-a-clean-relational-database
Hackernoon
Principles of a Clean Relational Database | HackerNoon
The article describes how a relational database should be designed to properly work in OLTP mode.
Пару недель назад вышел подкаст со мной на Javaswag. Бегом бронировать полтора часа на послушать разговор за Java, Clean code и собеседования 😏
Forwarded from javaswag
https://soundcloud.com/javaswag/e34
В 34 выпуске подкаста Javaswag поговорили с Андреем Сундуковым о переходе c PHP на Java, чистом коде и о собеседованиях
00:00:09 Инженер дата-центра
00:02:54 Из PHP в Java
00:08:16 Что хорошего в Java с точки зрения PHP
00:11:58 PHP же тоже можно писать читаемый код
00:17:15 Зачем писать чистый код
00:33:39 Clean Code 2.0
00:42:04 Простая 300 строчная функция против чистого кода
00:49:03 Договорились писать "чистый код", что дальше?
00:58:28 Спринг мотивируют писать чистый код
01:04:13 Собеседования, курс From Junior to Middle https://education.dhabits.ru/
01:07:48 Что должно быть в резюме
01:18:29 Что спрашивают Сеньоров?
01:27:04 Систем дизайн интервью
01:32:38 Канал https://t.me/developers_mind
Ссылки от гостя:
Разбор резюме на позицию Java Dev https://www.youtube.com/watch?v=nDRXq21B4PI
Гость - https://t.me/Hcd5opza9bdcjid26fg
Кип сейф! 🖖
В 34 выпуске подкаста Javaswag поговорили с Андреем Сундуковым о переходе c PHP на Java, чистом коде и о собеседованиях
00:00:09 Инженер дата-центра
00:02:54 Из PHP в Java
00:08:16 Что хорошего в Java с точки зрения PHP
00:11:58 PHP же тоже можно писать читаемый код
00:17:15 Зачем писать чистый код
00:33:39 Clean Code 2.0
00:42:04 Простая 300 строчная функция против чистого кода
00:49:03 Договорились писать "чистый код", что дальше?
00:58:28 Спринг мотивируют писать чистый код
01:04:13 Собеседования, курс From Junior to Middle https://education.dhabits.ru/
01:07:48 Что должно быть в резюме
01:18:29 Что спрашивают Сеньоров?
01:27:04 Систем дизайн интервью
01:32:38 Канал https://t.me/developers_mind
Ссылки от гостя:
Разбор резюме на позицию Java Dev https://www.youtube.com/watch?v=nDRXq21B4PI
Гость - https://t.me/Hcd5opza9bdcjid26fg
Кип сейф! 🖖
SoundCloud
Hear the world’s sounds
Explore the largest community of artists, bands, podcasters and creators of music & audio
Вчера был мой 4ый рабочий день на новой работе. Вкратце как проходит онбординг:
день 1 - вводный колл с тиммейтом, получение ноута в середине рабочего дня, небольшая настройка
день 2 - еще пара коллов на полтора часа по онбордингу, изучение всяких онборд доков и настройка доступов, в конце дня получил ключик к репозиторию, стянул основную репу, поковырялся в ней
день 3 - прошел несколько онборд тренингов, получил первую таску (причем по фронтенду, с которым я никогда не работал). стянул фроненд репу, тиммейт помог быстро его запустить, начал разбираться и шерстить как это сделать
день 4 - закончил онборд тренинги, доразбирался с таской, тиммейт помог поправить пару косяков, создал PR, прошел ревью, нажал merge, через полчаса таска уже в продакшене.
Да да, на 4ый день я уже принес пользу и выложил свое поделие в продакшн. Первый раз настолько быстрый и эффективный онбординг и отлично работающие CI/CD, простой понятный код (даже на незнакомых технологиях), отсутствие танцев с бубном для запуска сервисов. Немного даже в шоке 🙂
день 1 - вводный колл с тиммейтом, получение ноута в середине рабочего дня, небольшая настройка
день 2 - еще пара коллов на полтора часа по онбордингу, изучение всяких онборд доков и настройка доступов, в конце дня получил ключик к репозиторию, стянул основную репу, поковырялся в ней
день 3 - прошел несколько онборд тренингов, получил первую таску (причем по фронтенду, с которым я никогда не работал). стянул фроненд репу, тиммейт помог быстро его запустить, начал разбираться и шерстить как это сделать
день 4 - закончил онборд тренинги, доразбирался с таской, тиммейт помог поправить пару косяков, создал PR, прошел ревью, нажал merge, через полчаса таска уже в продакшене.
Да да, на 4ый день я уже принес пользу и выложил свое поделие в продакшн. Первый раз настолько быстрый и эффективный онбординг и отлично работающие CI/CD, простой понятный код (даже на незнакомых технологиях), отсутствие танцев с бубном для запуска сервисов. Немного даже в шоке 🙂
Как быстро на последнем месте работы ваш код впервые попал в продакшн?
Anonymous Poll
18%
до 7 дней
16%
7-20 дней
15%
3-8 недель
7%
2-4 месяца
12%
4+ месяцев
32%
посмотреть результаты
В прошлую субботу выступал в качестве спикера в Белграде на IT-митапе по софт скилам (@belgradeitmeetups). Тема: "behavior собеседования на западном рынке".
Основные тезисы:
1. CV - упор на Achievements вместо Responsibilities
2. English - основная причина провала технарей из СНГ на собеседованиях в иностранные компании
3. Необходимо мыслить с точки зрения вашего value для компании, а не с точки зрения какой вы классный или классная и сколько задачек вы успеваете делать.
По-моему эти три пункта отвечают за 20% усилий и 80% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.
В следующих постах раскрою подробнее каждый пункт.
Основные тезисы:
1. CV - упор на Achievements вместо Responsibilities
2. English - основная причина провала технарей из СНГ на собеседованиях в иностранные компании
3. Необходимо мыслить с точки зрения вашего value для компании, а не с точки зрения какой вы классный или классная и сколько задачек вы успеваете делать.
По-моему эти три пункта отвечают за 20% усилий и 80% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.
В следующих постах раскрою подробнее каждый пункт.
CV - Responsibilities vs Achievements
Какое же основное отличие резюме для западного рынка и резюме с рынка СНГ? Из моего опыта - это упор на достижения вместо описания зоны ответственности. Особенно удручающе выглядят фразы типа “написание кода”, “исправление багов”, “проведение код ревью” - это похоже на “ответсвенный, коммуникабельный стрессоустойчивый, легкообучаемый” что, конечно, является огромным клише. Итак, вместо “разработка функционала” лучше написать “реализовал рекоммендательную систему, которая увеличила прибыль на 40%”. Вместо “оптимизация кода” лучше написать “оптимзировал главную страницу на 200 мс, что улучшило конверсию на 30% и сэкономило на оборудовании 20%”. Вместо “проведение код ревью” лучше написать “внедрил автоматический процесс проверки качества кода который экономит 20 человекочасов разработчиков IT-департамента еженедельно”. Так уж сложилось что на западном рынке не смотрят на, что специалист делал ежедневно, Намного важнее, чего он достиг и как он поможет бизнесу зарабатывать больше денег. В конце концов зарабатывать деньги - и есть цель любого бизнеса.
Бонусом же к такому подходу в составлении CV будет и то, что и на рынке СНГ такое CV не выглядит чужим. Оно выглядит нормально для западных компаний и свежо для компаний рынка СНГ.
Какое же основное отличие резюме для западного рынка и резюме с рынка СНГ? Из моего опыта - это упор на достижения вместо описания зоны ответственности. Особенно удручающе выглядят фразы типа “написание кода”, “исправление багов”, “проведение код ревью” - это похоже на “ответсвенный, коммуникабельный стрессоустойчивый, легкообучаемый” что, конечно, является огромным клише. Итак, вместо “разработка функционала” лучше написать “реализовал рекоммендательную систему, которая увеличила прибыль на 40%”. Вместо “оптимизация кода” лучше написать “оптимзировал главную страницу на 200 мс, что улучшило конверсию на 30% и сэкономило на оборудовании 20%”. Вместо “проведение код ревью” лучше написать “внедрил автоматический процесс проверки качества кода который экономит 20 человекочасов разработчиков IT-департамента еженедельно”. Так уж сложилось что на западном рынке не смотрят на, что специалист делал ежедневно, Намного важнее, чего он достиг и как он поможет бизнесу зарабатывать больше денег. В конце концов зарабатывать деньги - и есть цель любого бизнеса.
Бонусом же к такому подходу в составлении CV будет и то, что и на рынке СНГ такое CV не выглядит чужим. Оно выглядит нормально для западных компаний и свежо для компаний рынка СНГ.
English
Много раз собеседовался в иностранные компании и получил несколько инсайдов из западных же компаний по поводу главных причин отказа ребятам из России. Несложно догадаться - это уровень английского. Большинству технически сильных кандидатов отказывают из-за низкого уровня коммуникации - для мидловых, а особенно сеньорных ролей, это критически важный момент. Причем такой фидбек и дают: "кандидат технически крутой, но коммуникация это труба, как потом с ним взаимодействовать?". С кандидатами из других стран это проблема намного менее ярко выражена.
Причина? Так уж исторически сложилось, что в русскоговорящем сегменте было много проектов нацеленных на внутренний рынок и много своих кандидатов, потому что русскоговорящий рынок это 250 миллионов культурно похожих и близко проживающих людей. Т.е. всегда можно найти что-то на своем рынке и нет необходимости учить язык. Европейские страны такого свойства были лишены поэтому там уровень знания английского сильно выше.
Что делать, если хотите работать на западном рынке? Учите английский.
Много раз собеседовался в иностранные компании и получил несколько инсайдов из западных же компаний по поводу главных причин отказа ребятам из России. Несложно догадаться - это уровень английского. Большинству технически сильных кандидатов отказывают из-за низкого уровня коммуникации - для мидловых, а особенно сеньорных ролей, это критически важный момент. Причем такой фидбек и дают: "кандидат технически крутой, но коммуникация это труба, как потом с ним взаимодействовать?". С кандидатами из других стран это проблема намного менее ярко выражена.
Причина? Так уж исторически сложилось, что в русскоговорящем сегменте было много проектов нацеленных на внутренний рынок и много своих кандидатов, потому что русскоговорящий рынок это 250 миллионов культурно похожих и близко проживающих людей. Т.е. всегда можно найти что-то на своем рынке и нет необходимости учить язык. Европейские страны такого свойства были лишены поэтому там уровень знания английского сильно выше.
Что делать, если хотите работать на западном рынке? Учите английский.
В новой компании в слаке есть канал #insights куда падают feature-реквесты от пользователей и куда кидают результаты опроса-фидбека по поводу причин почему пользователь начал или прекратил пользоваться услугами компании.
Очень нравится быть намного ближе к пользователям и возможность тут же обсудить их идеи с коллегами, а может и забрать что-то в беклок. Сразу начинаешь и по своим небольшим задачам понимать необходимсть / пользу / критичность.
Очень нравится быть намного ближе к пользователям и возможность тут же обсудить их идеи с коллегами, а может и забрать что-то в беклок. Сразу начинаешь и по своим небольшим задачам понимать необходимсть / пользу / критичность.
Value
И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.
И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.
Запостил новую статью про то как делать какие-то прикидки насколько быстро или долго может выполняться тот или иной запрос:
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries
Но конечно все равно такие вещи сводятся к мониманию архитектуры баз данных, а еще глубже - к знанию как работает железо.
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries
Но конечно все равно такие вещи сводятся к мониманию архитектуры баз данных, а еще глубже - к знанию как работает железо.
Hackernoon
How to Make Rough Estimates of SQL Queries | HackerNoon
To do estimates of SQL queries we need to understand how DB works with queries. Let's find out what exactly the db do with queries.
Недавно дошло, почему у меня в целом редко бывают рутиные задачи в обычной деятельности, хотя почти на каждом рекрутинговом интервью спрашивают "А как ты относишься к рутиным задачам?".
Дело в том, что суть любого программиста - это автоматизировать рутину. И вот буквально каждый мой рабочий момент, где я сталкиваюсь с рутиной или местом, где мне нужно скопипастить сотни, а то и тысячи строк, чтоб добавить функциональность/фичи, я начинаю искать как же это можно автоматизировать или унифицировать и как-то само собой рутиная задача превращается в интересный челлендж "как же сделать правильно то, что не сделали до тебя другие". И почти всегда можно найти ошибки в дизайне / проектировании / идее, которые привели к появлению рутины в том месте, где этого можно было избежать или создать инструмент чтоб твои заказчики/пользователи сами с помощью инструмента решали свои рутиные хотелки.
Помните об этой возможности каждый раз когда получаете рутиную задачу. Рутина - это не для тех, кто не умеет в программирование и архитектуру.
Дело в том, что суть любого программиста - это автоматизировать рутину. И вот буквально каждый мой рабочий момент, где я сталкиваюсь с рутиной или местом, где мне нужно скопипастить сотни, а то и тысячи строк, чтоб добавить функциональность/фичи, я начинаю искать как же это можно автоматизировать или унифицировать и как-то само собой рутиная задача превращается в интересный челлендж "как же сделать правильно то, что не сделали до тебя другие". И почти всегда можно найти ошибки в дизайне / проектировании / идее, которые привели к появлению рутины в том месте, где этого можно было избежать или создать инструмент чтоб твои заказчики/пользователи сами с помощью инструмента решали свои рутиные хотелки.
Помните об этой возможности каждый раз когда получаете рутиную задачу. Рутина - это не для тех, кто не умеет в программирование и архитектуру.
Dependency Inversion для процессов разработки
Представьте, что у вас есть команда, отвечающая за бекофис банка. У вас есть несколько сотен тысяч клиентов, с которыми периодически что-то происходит - у кого-то баг, кому-то что-то не привезли, кто-то решил закрыть аккаунт. Выделена команда, которая реализует бекофисную "очередь запросов" требующую от менеджеров вовлечения - аппрув чего-либо, расширение лимитов, ревью из-за подозрения в мошенничестве или отмывании денег, запрос документов и т.д.
Команда может быть загружена на 100% реализацией каждого вида запроса - нужно делать серверную интеграцию, фронтенд часть, отображение информации и т.д. Но что если посмотреть на эту задачу с другой точки зрения? Можно создать инструмент для создания таких фич для других команд и сервисов, чтоб они сами регистрировали новые типы кейсов, требующих ревью менеджеров, и сообщали в наш сервис коллбек поинт с вариантами возможных действия для решения кейса.
Таким образом, мы можем развернуть зависимость и создать инструмент для других инженерных команд. Другие команды знают детали своих серверов сильно лучше и могут эффективнее и быстрее интегрировать свои бизнес процессы самостоятельно. Нужно лишь дать им несколько эндпоинтов. А бекофисная команда может сфокусироваться на создании и апгрейде самого инструмента и применении своих сил для других, не рутинных, дел.
Короче, такой "продуктовый DI" в конце концов изменяет процессы разработки и повышает эффективность работы и этой команды и других. Не стоит зацикливаться на реализации каждой отдельной фичи, лучше создать инструменты, которые позволят другим командам интегрировать свои сервисы самостоятельно.
Представьте, что у вас есть команда, отвечающая за бекофис банка. У вас есть несколько сотен тысяч клиентов, с которыми периодически что-то происходит - у кого-то баг, кому-то что-то не привезли, кто-то решил закрыть аккаунт. Выделена команда, которая реализует бекофисную "очередь запросов" требующую от менеджеров вовлечения - аппрув чего-либо, расширение лимитов, ревью из-за подозрения в мошенничестве или отмывании денег, запрос документов и т.д.
Команда может быть загружена на 100% реализацией каждого вида запроса - нужно делать серверную интеграцию, фронтенд часть, отображение информации и т.д. Но что если посмотреть на эту задачу с другой точки зрения? Можно создать инструмент для создания таких фич для других команд и сервисов, чтоб они сами регистрировали новые типы кейсов, требующих ревью менеджеров, и сообщали в наш сервис коллбек поинт с вариантами возможных действия для решения кейса.
Таким образом, мы можем развернуть зависимость и создать инструмент для других инженерных команд. Другие команды знают детали своих серверов сильно лучше и могут эффективнее и быстрее интегрировать свои бизнес процессы самостоятельно. Нужно лишь дать им несколько эндпоинтов. А бекофисная команда может сфокусироваться на создании и апгрейде самого инструмента и применении своих сил для других, не рутинных, дел.
Короче, такой "продуктовый DI" в конце концов изменяет процессы разработки и повышает эффективность работы и этой команды и других. Не стоит зацикливаться на реализации каждой отдельной фичи, лучше создать инструменты, которые позволят другим командам интегрировать свои сервисы самостоятельно.
Через пару недель вместе с замечательной @xuyanet планируем провести стрим с обсуждением IT рыночка и в качестве бонуса разберём и покритикуем несколько резюмешек. Если хотите чтоб ваша резюмешка попала в разбор - кидайте мне в личку, самые типовые ошибки обсудим, а самые интересные CVшки разберём на стриме.
На прошлой неделе схлестнулись мы с коллегами по одной теме о том, как же правильно писать компоненты на React, я из-за некоторых болячек пересмотрел подходы к базовому паттерну в проекте и имплементировал кое-что попроще (с моей точки зрения), но коллегам не нравилось это, хотя альтернативы были хуже и экстремальнее (с моей точки зрения). А их только одна небольшая деталь в общем-то не устраивала, но как ее сделать правильно ни я, с 6 месяцами опыта на реакте, ни кто-нибудь из них не втыкали. Вот так и просидели 4 мидло-сениора три часа на коле ничего не решив и только проспорив про подходы.
А на следующий день я вместе с ChatGPT обсудил проблему, рассказал ему чего там у меня в компонентах и он показал на примере как можно упростить мою штуку. Коллеги сказали "Да, это подходит".
А выводов пока что не будет. Вот посоветую только интересную статью как тот самый Т9 доэволюционировал до ChatGPT: https://thebell.io/evolyutsiya-neyrosetey-ot-t9-do-chatgpt-obyasnyaem-na-prostom-russkom-kak-rabotayut-yazykovye-modeli
А на следующий день я вместе с ChatGPT обсудил проблему, рассказал ему чего там у меня в компонентах и он показал на примере как можно упростить мою штуку. Коллеги сказали "Да, это подходит".
А выводов пока что не будет. Вот посоветую только интересную статью как тот самый Т9 доэволюционировал до ChatGPT: https://thebell.io/evolyutsiya-neyrosetey-ot-t9-do-chatgpt-obyasnyaem-na-prostom-russkom-kak-rabotayut-yazykovye-modeli
The Bell
Эволюция нейросетей от Т9 до ChatGPT. Объясняем на простом русском, как работают языковые модели
НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН И РАСПР
Начал все больше использовать ChatGPT. Всякие рутиные задачи он конечно классно снимает, например тут для генерации таблицы для статьи.
Интересно ли вам читать для кейсы использования ChatGPT?
Anonymous Poll
77%
да
23%
нет, надоело уже из каждого утюга
Fill Factor для РСУБД
Fill Factor — это параметр, определяющий, какой процент каждого блока данных базы данных будет использоваться для операций вставки (INSERT). Оставшееся пространство будет использоваться для операций обновления (UPDATE). Это означает, что если в том же блоке имеется свободное пространство, строка будет перезаписана в тот же блок, что в свою очередь не потребует пересчета индекса.
Для некоторых паттернов нагрузки на таблицу, например, если ваша таблица часто получает запросы по определенному индексу (не первичному) и возвращает более одной строки, а также имеет много запросов на обновление отдельных записей, установка Fill Factor ниже 100% позволит хранить часто запрашиваемые данные вместе, избегая фрагментации. В результате, это приведет к уменьшению случайных чтений (Random Reads) с диска и увеличению процента последовательного чтения.
Применяя Fill Factor и команду CLUSTER в одном из моих недавних экспериментов на продакшен-базе на сервере Google Cloud SQL, мне удалось ускорить выполнение критических запросов в ~1000 раз для наиболее сложных сценариев. Конечно, все зависит от характера нагрузки на таблицы, но у меня сложилось ощущение что это может вылечить многие сложные случаи.
Fill Factor — это параметр, определяющий, какой процент каждого блока данных базы данных будет использоваться для операций вставки (INSERT). Оставшееся пространство будет использоваться для операций обновления (UPDATE). Это означает, что если в том же блоке имеется свободное пространство, строка будет перезаписана в тот же блок, что в свою очередь не потребует пересчета индекса.
Для некоторых паттернов нагрузки на таблицу, например, если ваша таблица часто получает запросы по определенному индексу (не первичному) и возвращает более одной строки, а также имеет много запросов на обновление отдельных записей, установка Fill Factor ниже 100% позволит хранить часто запрашиваемые данные вместе, избегая фрагментации. В результате, это приведет к уменьшению случайных чтений (Random Reads) с диска и увеличению процента последовательного чтения.
Применяя Fill Factor и команду CLUSTER в одном из моих недавних экспериментов на продакшен-базе на сервере Google Cloud SQL, мне удалось ускорить выполнение критических запросов в ~1000 раз для наиболее сложных сценариев. Конечно, все зависит от характера нагрузки на таблицы, но у меня сложилось ощущение что это может вылечить многие сложные случаи.
Снова про ChatGPT
В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.
Это вот то самое пресловутое "рост производительности труда". Как писали умные люди - к безработице это не приведет, но приведет к необходимости переучиваться, еще большему количеству новых рабочих мест, и росту среднего благосостояния.
Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.
Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)
Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.
В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.
Это вот то самое пресловутое "рост производительности труда". Как писали умные люди - к безработице это не приведет, но приведет к необходимости переучиваться, еще большему количеству новых рабочих мест, и росту среднего благосостояния.
Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.
Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)
Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.