Картинок в гугле миллион, но у всех есть копирайты.
Но ведь ничего не мешает вдохновляться картинкой с копирайтом. Точно так же, как вы делаете макет в какой-нибудь Figma, глядя на картинку, сделанную нейросетью, вы можете делать макет, глядя на картинку из Гугла.
Дизайны красивые, мне нравится. Но хотелось бы узнать фидбэк о том, насколько они полезны в работе. Например, сколько времени придётся потратить, чтобы "выдрать" из этих картинок иконки, перегнать их в вектор и собрать в иконочный шрифт. Второй момент: когда такой мокап превратится в готовый продукт, оценить, насколько хорошо или плохо было продумано юзабилити дизайна.
То, что я увидел в статье, выглядит абсолютно неубедительно. Подобных картинок можно просто найти в Гугле целый миллион. А в цену подписки на Midjourney можно купить уже свёрстанную тему. Что касается генерации палитры, то подобных сервисов в интернете миллион.
Пока что я вижу, что нейросеть делает то же, что другие инструменты, только хуже, медленнее и дороже
Именно. Плюс пытаться что-то поменять в своём подходе. Повторять одни и те же действия при полном отсутствии результата нет никакого смысла. Представьте себе ситуацию, вы приходите домой, пытаетесь включить свет, а он не включается. Есть действие - щелчок по выключателю, и есть полное отсутствие фидбэка. Любой нормальный человек пощёлкает туда-сюда пару раз, а потом займётся, как вы выразились, "гаданием на кофейной гуще": попробует включить свет в другой комнате, проверит автоматы, посмотрит, горит ли свет в соседних домах. И только соискатель позиции джуна без опыта работы будет щёлкать выключателем тысячу раз, а потом напишет в линкедин слезливый пост о том, что рынок электричества просел.
Спасибо за статью, мнигие моменты напомнили мне самого себя. Я тоже когда-то работал несколько лет на гос.конторе и прямо сидя на работе начал изучать веб, и первые проекты за деньги делал прямо на той работе)) Кстати, многие нынешние "вайтишники" как-то совершенно упускают из виду возможность набраться опыта на фрилансе. Вы молодец, что этим воспользовались.
Однако хочу дать совет: нет ничего хорошего в том, чтобы работать на двух работах. Все эти статьи про выгорание пишут не на пустом месте.
Ну и второй совет уже не вам, а тем, кто ещё только начинает свой путь в IT. У вас там сначала написано про 1000 откликов вникуда, а потом переделали резюме и довольно быстро нашли работу. Судя по всему, 1000 откликов вникуда - это сейчас стандартная ситуация. Но тут у меня вопрос не к рынку, а к соискателю. Даже в лучшие времена не было такого, чтобы специалист мог найти себе такое огромное количество подходящих вакансий. А проблема в том, что отзываются, не глядя: на офисные вакансии в Раджастане, на позиции архитектора, на другой стек. Другой момент, что важно не только произвести хорошее впечатление, но и не произвести плохого. Поэтому откликаться надо сразу максимум на 5 вакансий, а потом ждать фидбэк и предпринимать меры. Если фидбэка нет в течение пару дней, пытаться понять, почему его нет.
Я привёл этот пример только за тем, чтобы показать, что решение бизнес-задачи - это и есть единственная конечная цель программирования, а все остальные ярусы пирамиды ну никак не могут являться конечными целями ни в каком понимании.
Тем не менее, в вашей пирамиде есть одна интересная закономерность. Под ярусом Business у вас перечислены необходимые технические критерии, а над ярусом - экономические. Ненаписанная, не скомпилированная или не запускаемая программа по определению не может выполнить задачу. А вот плохо читаемая, плохо тестируемая и трудно модифицируемая программа с задачей может справляться хорошо, но быстро станет для бизнеса невыгодной.
Бизнес-задача может решаться вне блока if. Но при этом внутри недосягаемого блока может быть какая-то сложная логика, задействующая много разных классов, объединённых какими-то паттернами, да ещё и покрытых юнит-тестами. Факт запуска юнит-теста при этом закрывает ярус Run из вашей пирамиды. То есть программа по факту работает, и код в ней крутой, но ненужный.
И кстати есть ещё один очень важный критерий любого кода - ресурсоёмкость. Почему-то об этом очень часто забывают. До недавнего времени было принято считать, что в случае серверных приложений выгоднее нанять более дешёвых разработчиков, но арендовать более дорогой сервер, но в последнее время всё чаще бизнес стал понимать, что выгоднее один раз заплатить программисту условно на 5000$ больше, чтобы в будущем экономить 200$ в месяц на инфраструктуре
У вас в рассуждениях фундаментальная ошибка в самом начале. Вы задаётесь вопросом "какая цель?", а в итоге большую часть статьи рассуждаете не о цели, а о средствах её достижения. Цель программирования - программа. А код - это средство достижения цели. К примеру, вот такая программа может полностью удовлетворять всем критериям из вашей пирамиды, но при этом является абсолютно бессмысленной:
if (FALSE) {
// Миллион строк легкоподдерживаемого и удобно-расширяемого кода
}
Там на две позиции выше в выдаче статья How to handle post-request in Node.js without frameworks. Вот там сразу нормально написано. А ниже идёт стек, там лучшие ответ подразумевает использование express, приходится листать дальше и вчитываться. То есть помимо документации нашёлся ещё один источник более удобный, чем Stackoverflow
Папка examples не является платформенно-зависимой. Просто я много работаю с javascript и Drupal. Эта практика применяется и там, и там.
По вашему запросу у меня Stackoverflow только на пятой позиции выдачи. И там приводят сниппет с использованием express. Если вы собираетесь использовать express, сразу смотрите его документацию, там всё есть. А если не собираетесь, то опять же получается, что Stackoverflow не дал ответа на вопрос
Моя мысль изложена в моём первом комментарии. Но поясню ваши вопросы: examples и demo - это в javascript экосистеме принято. Любой пакет или либа имеет либо такую папочку, либо онлайн-демо. Но это конечно не об эндпоинтах.
Говоря о документации, я имею в виду не openapi документацию для эндпоинта, а обычную документацию для фреймворка или библиотеки. Как правило, в нормальных фреймворках в документации есть примеры эндпоинтов. И эти примеры будут проверены и утверждены сообществом, в отличие от Stackoverflow, где может писать каждый. Я вот реально не понимаю, что может быть за такая технология, где будучи сеньор-разработчиком с ходу надо лезть не в доки, а на Stackoverflow.
Никогда, никогда, никогда сеньор-разработчик не будет копировать код первого эндпоинта со Stackoverflow. Он может его скопировать из документации, из папки examples или demo, с другого проекта. Но никогда не со Stackoverflow.
Сеньор никогда не будет копировать код первого эндпоинта с SO, потому что для этого есть во-первых генераторы кода, а во-вторых, документация. Stackoverflow в данном случае вообще лишний. И джун не будет делать то же самое. Когда у джуна возникает вопрос, он идёт гуглить ответ. Когда вопрос возникает у сеньора, он либо уже знает, где именно написан ответ, либо придумывает его сам.
Я сеньор уже много лет, и с трудом вспомню, когда в последний раз приходилось копировать код со Stackoverflow. Если задача простая и маленькая, то код пишешь сразу из головы, не думая. Не потому что помнишь, а потому что знаешь, как воспроизвести. Если же надо воспроизвести длинный кусок кода, то он, как правило, берётся из другой части проекта, или из другого проекта или прямо из ядра фреймворка, библиотеки и т.д. Если под рукой нужного сниппета нет, то он копируется из документации или папки examples в репозитории используемого решения. И вот только если во всех вышеуказанных местах ничего не нашлось, тогда идёшь на Stackoverflow.
Всё просто: джун копирует код на Stackoverflow из вопроса. Миддл - из ответа. А сеньор вообще забыл дорогу на Stackoverflow, потому что привык, что по большинству сложных задач решения в интернете нет.
Вот опять же получается, чтобы чат-бот заменил поисковик, нужно научить чат-бот делать то же самое, что умеет поисковик. На выходе получится ещё один поисковик, только платный и с ограничениями по IP :D Вообще, это уже ставшая привычной практикой попытка поставить телегу впереди лошади. Покуда все восторженно пишут статьи о том, как космические корабли бороздят большой театр, IT-гиганты уже во всю внедряют ИИ в привычные нам инструменты. За последнее время у меня было уже несколько случаев, когда я не знал, как сформулировать запрос, писал просто то, что на уме, и поисковик понимал, что мне нужно. А в итоге окажется, как и с другими инновациями - ИИ просто пропишется в некоторых сферах, как ненавязчивый помощник. А страшилки про толпы безработных, Скайнет и апокалипсис так и останутся страшилками.
Высшая математика нужна далеко не всем разработчикам. Вернее она не нужна большинству разработчиков. Я занимаюсь веб-разработкой уже 10 лет и ни разу не пригодилось ничего сложнее синусов и костнусов. То есть банальной тригонометрии достаточно.
Что касается необходимости постоянно учиться, так это касается любой сферы. Любой хороший специалист должен постоянно следить за развитием своей сферы, будь то нейрохирург или плиточник
По поводу задач, которые нельзя доверять ChatGPT, полностью согласен. Но вот по поводу поиска - нет. Тему возможной недостоверности результатов вы раскрыли хорошо, но есть ещё много аспектов, из-за которых чат-боты абсолютно не подходят для замены веб-поиска:
1.Чат-боты не знают, где ближайший ремонт обуви или в каком конкретно магазине можно найти конкретную автозапчасть.
2.Чат-боты крайне затрудняют факт-чекинг. Хоть и обещают, что новая версия ChatGPT будет давать ссылки на источники, это всё равно не так удобно, как сразу перейти на источник из того же гугла.
3. Многословность. Если мне надо узнать, к примеру, что такое кёфте, я просто введу в адресную строку одно слово, а гугл мне прямо в автокомплите напишет, что это блюдо турецкой кухни и картиночку покажет. И это даже не переходя на страницу поиска. А на странице поиска будет и сводная информация, и рецепты и картинки. А ChatGPT потребует запрос из нескольких слов, и выдаст в ответ текст, на 90% состоящий из воды. Ну и никаких картинок.
4. В чат-боте нет автодополнения. Если неверно услышал слово, неверно его ввёл, чат-бот в итоге может подстроиться под ошибочный вопрос. Впрочем, вы хорошо раскрыли этот случай
А тот случай, когда нужно перефразировать запрос,он действительно является хорошим применением для чат-ботов, но это довольно редкий случай, поэтому говорить о какой-то революции в сфере поиска тут явно не приходится.
Отсутствие work-life баланса - это как раз очень страшно. Даже на время адаптации. Работодатель должен сам учитывать, что онбординг будет длиться какое-то время, и в течение этого времени продуктивность нового сотрудника будет минимальной. Если руководство этого не понимает, то нет смысла оставаться, потому что когда освоитесь и начнёте прказывать результаты, к этому будет точно такое же отношение. Помню звали меня в стартап, в описании вакансии было что-то про 50-часовую рабочую неделю. Поинтересовался, не ошибка ли это. Ответили "нам нужны увлечённые люди". На этом и закончили. Я понимаю, когда в нерабочее время занимаешься самообучением - это нормально. Но все рабочие задачи сверх 40 часов в неделю должны оплачиваться по двойному тарифу, и никак иначе.
Отказывать мутным клиентам - это нормально. Во-первых, такие работы потом банально стыдно добавлять в резюме или портфолио. Во-вторых, это всё мелкая рыба, то есть малобюджетные и краткосрочные проекты. И в таких проектах вы не научитесь строить стратегии, делать А/Б-тестирование и т.д., то есть не вырастете, как специалист.
Единственный случай, когда стоит за такое браться - это когда работы нет, а деньги нужны здесь и сейчас.
Я ни разу не встречал такого, чтобы при выполнении работ длительностью больше двух дней у исполнителя в процессе не возникли какие-то уточняющие вопросы к клиенту. Всегда всплывают какие-то вещи, которые были упущены во время изначальной постановки задачи или составления ТЗ. Причём это касается любой сферы, будь то разработка ПО, дизайн, строительство, ремонт авто или ещё что-нибудь. Если исполнитель сам не выходит на связь в течение длительного времени, скорее всего это означает, что ваш заказ ещё в очереди и за него ещё не брались. Именно поэтому клиенты волнуются. И именно поэтому вы правильно делаете, что информируете клиента о ходе работы.
Но ведь ничего не мешает вдохновляться картинкой с копирайтом. Точно так же, как вы делаете макет в какой-нибудь Figma, глядя на картинку, сделанную нейросетью, вы можете делать макет, глядя на картинку из Гугла.
Дизайны красивые, мне нравится. Но хотелось бы узнать фидбэк о том, насколько они полезны в работе. Например, сколько времени придётся потратить, чтобы "выдрать" из этих картинок иконки, перегнать их в вектор и собрать в иконочный шрифт. Второй момент: когда такой мокап превратится в готовый продукт, оценить, насколько хорошо или плохо было продумано юзабилити дизайна.
То, что я увидел в статье, выглядит абсолютно неубедительно. Подобных картинок можно просто найти в Гугле целый миллион. А в цену подписки на Midjourney можно купить уже свёрстанную тему. Что касается генерации палитры, то подобных сервисов в интернете миллион.
Пока что я вижу, что нейросеть делает то же, что другие инструменты, только хуже, медленнее и дороже
Именно. Плюс пытаться что-то поменять в своём подходе. Повторять одни и те же действия при полном отсутствии результата нет никакого смысла. Представьте себе ситуацию, вы приходите домой, пытаетесь включить свет, а он не включается. Есть действие - щелчок по выключателю, и есть полное отсутствие фидбэка. Любой нормальный человек пощёлкает туда-сюда пару раз, а потом займётся, как вы выразились, "гаданием на кофейной гуще": попробует включить свет в другой комнате, проверит автоматы, посмотрит, горит ли свет в соседних домах. И только соискатель позиции джуна без опыта работы будет щёлкать выключателем тысячу раз, а потом напишет в линкедин слезливый пост о том, что рынок электричества просел.
Спасибо за статью, мнигие моменты напомнили мне самого себя. Я тоже когда-то работал несколько лет на гос.конторе и прямо сидя на работе начал изучать веб, и первые проекты за деньги делал прямо на той работе)) Кстати, многие нынешние "вайтишники" как-то совершенно упускают из виду возможность набраться опыта на фрилансе. Вы молодец, что этим воспользовались.
Однако хочу дать совет: нет ничего хорошего в том, чтобы работать на двух работах. Все эти статьи про выгорание пишут не на пустом месте.
Ну и второй совет уже не вам, а тем, кто ещё только начинает свой путь в IT. У вас там сначала написано про 1000 откликов вникуда, а потом переделали резюме и довольно быстро нашли работу. Судя по всему, 1000 откликов вникуда - это сейчас стандартная ситуация. Но тут у меня вопрос не к рынку, а к соискателю. Даже в лучшие времена не было такого, чтобы специалист мог найти себе такое огромное количество подходящих вакансий. А проблема в том, что отзываются, не глядя: на офисные вакансии в Раджастане, на позиции архитектора, на другой стек. Другой момент, что важно не только произвести хорошее впечатление, но и не произвести плохого. Поэтому откликаться надо сразу максимум на 5 вакансий, а потом ждать фидбэк и предпринимать меры. Если фидбэка нет в течение пару дней, пытаться понять, почему его нет.
Я привёл этот пример только за тем, чтобы показать, что решение бизнес-задачи - это и есть единственная конечная цель программирования, а все остальные ярусы пирамиды ну никак не могут являться конечными целями ни в каком понимании.
Тем не менее, в вашей пирамиде есть одна интересная закономерность. Под ярусом Business у вас перечислены необходимые технические критерии, а над ярусом - экономические. Ненаписанная, не скомпилированная или не запускаемая программа по определению не может выполнить задачу. А вот плохо читаемая, плохо тестируемая и трудно модифицируемая программа с задачей может справляться хорошо, но быстро станет для бизнеса невыгодной.
Бизнес-задача может решаться вне блока if. Но при этом внутри недосягаемого блока может быть какая-то сложная логика, задействующая много разных классов, объединённых какими-то паттернами, да ещё и покрытых юнит-тестами. Факт запуска юнит-теста при этом закрывает ярус Run из вашей пирамиды. То есть программа по факту работает, и код в ней крутой, но ненужный.
И кстати есть ещё один очень важный критерий любого кода - ресурсоёмкость. Почему-то об этом очень часто забывают. До недавнего времени было принято считать, что в случае серверных приложений выгоднее нанять более дешёвых разработчиков, но арендовать более дорогой сервер, но в последнее время всё чаще бизнес стал понимать, что выгоднее один раз заплатить программисту условно на 5000$ больше, чтобы в будущем экономить 200$ в месяц на инфраструктуре
У вас в рассуждениях фундаментальная ошибка в самом начале. Вы задаётесь вопросом "какая цель?", а в итоге большую часть статьи рассуждаете не о цели, а о средствах её достижения. Цель программирования - программа. А код - это средство достижения цели. К примеру, вот такая программа может полностью удовлетворять всем критериям из вашей пирамиды, но при этом является абсолютно бессмысленной:
Там на две позиции выше в выдаче статья How to handle post-request in Node.js without frameworks. Вот там сразу нормально написано. А ниже идёт стек, там лучшие ответ подразумевает использование express, приходится листать дальше и вчитываться. То есть помимо документации нашёлся ещё один источник более удобный, чем Stackoverflow
Папка examples не является платформенно-зависимой. Просто я много работаю с javascript и Drupal. Эта практика применяется и там, и там.
По вашему запросу у меня Stackoverflow только на пятой позиции выдачи. И там приводят сниппет с использованием express. Если вы собираетесь использовать express, сразу смотрите его документацию, там всё есть. А если не собираетесь, то опять же получается, что Stackoverflow не дал ответа на вопрос
Моя мысль изложена в моём первом комментарии. Но поясню ваши вопросы: examples и demo - это в javascript экосистеме принято. Любой пакет или либа имеет либо такую папочку, либо онлайн-демо. Но это конечно не об эндпоинтах.
Говоря о документации, я имею в виду не openapi документацию для эндпоинта, а обычную документацию для фреймворка или библиотеки. Как правило, в нормальных фреймворках в документации есть примеры эндпоинтов. И эти примеры будут проверены и утверждены сообществом, в отличие от Stackoverflow, где может писать каждый. Я вот реально не понимаю, что может быть за такая технология, где будучи сеньор-разработчиком с ходу надо лезть не в доки, а на Stackoverflow.
Никогда, никогда, никогда сеньор-разработчик не будет копировать код первого эндпоинта со Stackoverflow. Он может его скопировать из документации, из папки examples или demo, с другого проекта. Но никогда не со Stackoverflow.
Сеньор никогда не будет копировать код первого эндпоинта с SO, потому что для этого есть во-первых генераторы кода, а во-вторых, документация. Stackoverflow в данном случае вообще лишний. И джун не будет делать то же самое. Когда у джуна возникает вопрос, он идёт гуглить ответ. Когда вопрос возникает у сеньора, он либо уже знает, где именно написан ответ, либо придумывает его сам.
Я сеньор уже много лет, и с трудом вспомню, когда в последний раз приходилось копировать код со Stackoverflow. Если задача простая и маленькая, то код пишешь сразу из головы, не думая. Не потому что помнишь, а потому что знаешь, как воспроизвести. Если же надо воспроизвести длинный кусок кода, то он, как правило, берётся из другой части проекта, или из другого проекта или прямо из ядра фреймворка, библиотеки и т.д. Если под рукой нужного сниппета нет, то он копируется из документации или папки examples в репозитории используемого решения. И вот только если во всех вышеуказанных местах ничего не нашлось, тогда идёшь на Stackoverflow.
Всё просто: джун копирует код на Stackoverflow из вопроса. Миддл - из ответа. А сеньор вообще забыл дорогу на Stackoverflow, потому что привык, что по большинству сложных задач решения в интернете нет.
Вот опять же получается, чтобы чат-бот заменил поисковик, нужно научить чат-бот делать то же самое, что умеет поисковик. На выходе получится ещё один поисковик, только платный и с ограничениями по IP :D Вообще, это уже ставшая привычной практикой попытка поставить телегу впереди лошади. Покуда все восторженно пишут статьи о том, как космические корабли бороздят большой театр, IT-гиганты уже во всю внедряют ИИ в привычные нам инструменты. За последнее время у меня было уже несколько случаев, когда я не знал, как сформулировать запрос, писал просто то, что на уме, и поисковик понимал, что мне нужно. А в итоге окажется, как и с другими инновациями - ИИ просто пропишется в некоторых сферах, как ненавязчивый помощник. А страшилки про толпы безработных, Скайнет и апокалипсис так и останутся страшилками.
Высшая математика нужна далеко не всем разработчикам. Вернее она не нужна большинству разработчиков. Я занимаюсь веб-разработкой уже 10 лет и ни разу не пригодилось ничего сложнее синусов и костнусов. То есть банальной тригонометрии достаточно.
Что касается необходимости постоянно учиться, так это касается любой сферы. Любой хороший специалист должен постоянно следить за развитием своей сферы, будь то нейрохирург или плиточник
По поводу задач, которые нельзя доверять ChatGPT, полностью согласен. Но вот по поводу поиска - нет. Тему возможной недостоверности результатов вы раскрыли хорошо, но есть ещё много аспектов, из-за которых чат-боты абсолютно не подходят для замены веб-поиска:
1.Чат-боты не знают, где ближайший ремонт обуви или в каком конкретно магазине можно найти конкретную автозапчасть.
2.Чат-боты крайне затрудняют факт-чекинг. Хоть и обещают, что новая версия ChatGPT будет давать ссылки на источники, это всё равно не так удобно, как сразу перейти на источник из того же гугла.
3. Многословность. Если мне надо узнать, к примеру, что такое кёфте, я просто введу в адресную строку одно слово, а гугл мне прямо в автокомплите напишет, что это блюдо турецкой кухни и картиночку покажет. И это даже не переходя на страницу поиска. А на странице поиска будет и сводная информация, и рецепты и картинки. А ChatGPT потребует запрос из нескольких слов, и выдаст в ответ текст, на 90% состоящий из воды. Ну и никаких картинок.
4. В чат-боте нет автодополнения. Если неверно услышал слово, неверно его ввёл, чат-бот в итоге может подстроиться под ошибочный вопрос. Впрочем, вы хорошо раскрыли этот случай
А тот случай, когда нужно перефразировать запрос,он действительно является хорошим применением для чат-ботов, но это довольно редкий случай, поэтому говорить о какой-то революции в сфере поиска тут явно не приходится.
Отсутствие work-life баланса - это как раз очень страшно. Даже на время адаптации. Работодатель должен сам учитывать, что онбординг будет длиться какое-то время, и в течение этого времени продуктивность нового сотрудника будет минимальной. Если руководство этого не понимает, то нет смысла оставаться, потому что когда освоитесь и начнёте прказывать результаты, к этому будет точно такое же отношение. Помню звали меня в стартап, в описании вакансии было что-то про 50-часовую рабочую неделю. Поинтересовался, не ошибка ли это. Ответили "нам нужны увлечённые люди". На этом и закончили. Я понимаю, когда в нерабочее время занимаешься самообучением - это нормально. Но все рабочие задачи сверх 40 часов в неделю должны оплачиваться по двойному тарифу, и никак иначе.
Отказывать мутным клиентам - это нормально. Во-первых, такие работы потом банально стыдно добавлять в резюме или портфолио. Во-вторых, это всё мелкая рыба, то есть малобюджетные и краткосрочные проекты. И в таких проектах вы не научитесь строить стратегии, делать А/Б-тестирование и т.д., то есть не вырастете, как специалист.
Единственный случай, когда стоит за такое браться - это когда работы нет, а деньги нужны здесь и сейчас.
Я ни разу не встречал такого, чтобы при выполнении работ длительностью больше двух дней у исполнителя в процессе не возникли какие-то уточняющие вопросы к клиенту. Всегда всплывают какие-то вещи, которые были упущены во время изначальной постановки задачи или составления ТЗ. Причём это касается любой сферы, будь то разработка ПО, дизайн, строительство, ремонт авто или ещё что-нибудь. Если исполнитель сам не выходит на связь в течение длительного времени, скорее всего это означает, что ваш заказ ещё в очереди и за него ещё не брались. Именно поэтому клиенты волнуются. И именно поэтому вы правильно делаете, что информируете клиента о ходе работы.