Эхх ученые в говне моченые, опять понаставили дизов новаторским и революционным спекуляциям. 🙃
Касаемо вечного двигателя, то учитесь пока жив: ищем могилы политиков и известных государственный деятелей 20 века по всему миру. Вскрывает их и обнаруживаем внутри вращательнын движения близкие к скорости света. Прикрепляем останки к динамо машине и этого хватит, чтобы запитать целые страны. 😎
А как вообще задача может быть выполнена без следа? Есть же условный гитхаб (или миллион других ему аналогов), где всё по коммитам видно. Есть задача в таск менеджере. Это возможно только в если коммиты пушить раз в неделю, а в задаче вообще никакого summary не давать (просто дальше передать например). А так мысли верные) Я вообще за то, чтобы всё относящееся к работе было в облаке, т.к. истории про "другой компьютер, молния ударила, света нет, почта не работает, меркурий вошёл в венеру и т.д." случаются и причём часто это не отмазки. Когда всё в облаке, это удобно. Я как работник даже если отойду смогу важные быстрые дела сделать хоть с телефона. Да и всякие форс мажоры (которые правда бывают) перестают быть блокером для работы над проектом.
В голове у тимлида в пятницу не таблица «Вася: 14 тикетов». Там что-то вроде: «Маша разрулила блокер с API, мы не улетели по срокам» «Петя второй день молчит, хз что с ним» «Вася… вроде ок, стабильный»
Если у тим лидов такое в голове, вместо банального анализа kpi, трекинга тасков и анилза пул реквестов, то радуйтесь, что вас из такой команды уволили. Потому что, всем в такой команде будет точно пофиг на результат, все будут стараться выслужиться перед начальством, как раз изображая красивую деятельность.
Однако проблема, скрытой работы реально есть и объяснить её необходимость заказчикам, как раз задача TL PM и Сеньоров иначе в нормальной организации вопрос будет не к джуну, почему он занимался немойми чем, а к тем, кто ему работу давал и принимал. Если джуну дали работу, а он её не сделал или сделал плохо, то тогда вопрос будет к нему, но если он делал работу качественно, а она оказалась организации и заказчикам не нужна, то не джуна проблемы.
Помню, один раз летел в самолёте и читал журнал для предпринимателей и бизнеса, где как раз об этой теме писалось. Какой-то "эксперт" писал, что в России низкая производительность труда, потому что все работники вечно ерундой занимаются. То бегают курить (буквально это было указано, как одна из главных причин), то задерживаются на обеде, то отпрашиваются пораньше. А вот на Западе, по его мнению, такого нет, все работают от звонка до звонка со 100% эффектностью. И ни слова, об огромных проблемах в организации труда и управлении персоналом.
Так же ни слова, что на Западе работают профсоюзы и если брать, например немцев, как педантичную нацию, то возможно типичный Ганс и правда курит меньше на работе, но при этом он ровно в 18:00 уходит домой и не делает работу сверх того, что написано у него в договоре. От такого многие наши работодатели с их "мы же семья", "ты что только за деньги работаешь" взвыли бы, т.к. будь они в Европе, их "рога и копыта" профсоюзы прикрыли бы очень быстро.
Это я к чему. Сначала работодалели (которое разделяют мнение эксперта и таких много) пытаются найти людей оркестров, которые должны и пол убирать, и видеомонтаж делать, и за хайлоадом следить, а потом удивляются низкой производительности, привязке к конкретным работникам, выгораниям пенсонала и низкой производительности с учётом плохо налаженных рабочих процессов. Но виноват в этом у подобных руководителей работник Name, что курить часто бегает и в вк сидит на работе.
Поэтому честный вопрос к любой деятельности, называющей себя инженерией, звучит не как “всё ли вы знаете?”, а как “что у вас сделано на случай обнаружения того, чего вы не знаете?”.
Думаю, это утверждение относится к любой специальности. Управление рисками и проектирование являются неотъемлемой частью многих специальностей.
Касаемо инженерии, то у самого слова есть вполне себе общепринятое значение. Если для решения практических задач используются математические, технические и научные знания, это уже можно назвать проявлением инжинерии. А вот насколько грамотно эти знания применены и насколько они обширны у конкретных специалистов, это уже вопрос их опыта и квалификации.
То что используют давно в CMS всякие AI функции это понятно)
> Наверно допил функционала слишком специфичен, чтобы решать его вайбкодингом. Думаю, написать под подобные cms обвязку, что не будет сжирать миллионы токенов и давать внятный результат на деле, не такая уж и простая задача. А так да.
Не старье наверное всякие next.js nuxt.js, хотя уже тоже относительно. Сейчас мне кажется не старьем будет cms с обвязкой под нейронки под капотом, что позволит допиливать модерам админок функционал самостоятельно без программирования. Ну пока этот спагетти код не разрастается до макаронного монстра.)
закрытый контур без интернета и без Git-based CI/CD (manifest-driven деплой через deploy-cutover.py);
Не совсем понимаю, что мешало использовать Git с CI/CD, если их можно настроить так же локально или в сети компании. Не совсем понятно, что за deploy-cutover.py? Может это ваш какой-то внутренний скрипт, но мы то откуда знаем его код и по какому принципу он работает и чем отличается от общепринятых CD практик? 🤔
Дело не только в тире, которые по тексту то длинные, то короткие вперемешку, на скрине это тоже видно. И даже не в tldr по поводу и без. А в самом стиле написания. Неронки в угоду экономии токенов, обожают писать текст тезисно. Противопоставлять одно другому, использовать часто списки, даже там, где они избыточны и строить бОльшую часть текста в формате вопрос-ответ. То что автор написал этот текст не одной генерацией и подрихтовал ответы собрав в одну цельную статью похвально. Если народу нравится, то окей.
Я слишком много использую llm и даже в видео слышу, по слогу, где автор использовал в написании сценария нейронки, а где нет. Правда сейчас многие из-за большого количества работы с llm начинают подражать их стилю и отличить, где подражание, а где реально llm уже сложнее.
Касаемо бана, то я бы ввёл бан за невнимательное прочтение комментариев и манипуляции с выдергиванием контекста с последующим возведением его в абсолют.
По идее, нейронка так же через mcp будет искать информацию по документации, что по сути тажа трата времени на ризонинг с поиском и чтением md файлов. Как-будто проще запихать большую документацию в векторку, что реально сможет сэкономить контекст.
Реклама может сделать из говна конфетку, только если идеально работает критически важный пользователям функционал.
Хороший пример, чат gpt. Когда он только стал всем доступен, у него постоянно падали сервера, криво работала гугл авторизация с вечным разлогином, до сих пор лагает web ui, когда страница с чатом тормозит при большом количестве вопросов-ответов, т.к. open ai не умеет в нормальную ленивую загрузку и контроль ресурсов. Однако, это всё пользователи готовы терпеть ради главного функционала, что работает отлично, а именно ради самой llm. С точки зрения веба чат gpt посредственен, но мы знаем множество копирок с крутым веб ui ux, но кривой реализацией llm из-за чего они нафиг никому не нужны.
Понимаю, что mvp это термин, который сам по себе подразумевает минимально жизнеспособныйипродукт, но даже в рамках минимума, есть критически важный функционал, который должен работать идеально и второстепенный, который может работать криво.
Поэтому если критически важный функционал не завершён - то проект никакя реклама не спасет, это верно)
Уже многое написали про тех. готовность. Незавершённость проекта оправдана, только в одном случае: если ваш продукт уникальный и даже в таком качестве лучше конкурентов.
По опыту, могу сказать, чтобы занять нишу, нужно хорошо знать конкретную сферу и её рынок.
Например, я практически всё время работал в мед. организацих. Из-за чего хорошо знаю эту кухню. Если когда-то захочу создать стартап, у меня есть представление, что будет удобно и интересно врачам. Какаое тех качество допустимо для mvp и что критически важно в продукте. Так же, знаю главное, как набирать клиентскую базу и специфику сферы. За свою жизнь повидал много мед. стартапов и прекрасно знаю их ошибки. Поэтому у меня бы всё скорее-всего получилось.
Однако, если бы я захотел залезть в финтех, логистику и т.д., то скорее-всего провалился. Да, проводил бы ресерч рынка, пытался бы получить фидбэк, но без понимания того, что нужно и важно конечному пользователю и как вообще ему о продукте рассказать, это путь в никуда.
Лично стартапы не открывал, но пет проекты делаю часто. Какие-то забрасываю, какие-то в долгострое, а какие-то использую в обиходе или отдаю коллегам. Так же, участвовал в чужих стартарах.
Честно, как бы не пытался делать пет проекты, держа всё в голове, всё всегда сводилось, к списку задач с ротацией: бэклог - в работе - выполнено, а потом и к доскам с карточками.
За всё время понял одно. Если хочешь сделать, что-то годное, среднее+ по масштабам, то к проекту нужно относиться словно он оплачиваемый энтерпрайз. Даже если ты вайбкодишь. Точнее особенно если ты вайбкодишь, всегда используй таск менеджеры, гит с моно репо, юнит тесты (очень желательно даже если кажется, что они лишние, не повторяйте моих ошибок), ci cd на свой сервер если это бэкенд. Если приложение или игра, то грамотная настройка билда с публикацией, а не просто debug-build. Только дисциплиной можно добиться результатов. По сути вы должны быть сами себе аналитиком, продуктом, дизайнером, программистом, тестировщиком, ceo и даже конечным пользователем.
П.С. Перечитал, написанное, вроде очевидные вещи, однако многие про них знают, но на практике не осознают.
не вдаваясь в то, как именно ООП реализовано в JavaScript.
Если честно для ООП он тоже мало подходит. Тот же ts по сути обёртка, которая не спасает от проблем в рантайме, ведь код компилируется в обычный js. Поэтому хоть сколько-то адекватный код приходится писать с оглядкой на это.
критика — конкретная и повторяющаяся: «иммутабельность дорогая по памяти», «рекурсия небезопасна из-за стека».
Вроде же автор, сам в статье расскрыл эти проблемы, не совсем понимаю в чём претензия к кандидатам на собесах?) То что они не прочитали лекцию, чем именно js плох для чистого фп?)
Но функциональным языком он не является. Не потому что в нём нельзя писать функционально, а потому что он не был спроектирован для этого.
Он не был скорректирован и для ООП, но очень многие разработчики пишут на нем код именно в ООП стиле. Тоже самое и с ФП. Зачасую для js разработчиков на практике даже рекурсия не нужна. Всё фп заканчивается написанием функций под event loop и промисы. Большинство js разработчиков не приведет пример монады, функтора или апликатива. Даже не так, большинство разработчиков на популярных яп, это вряд-ли сделают, чтобы js разработчики, не думали, что я их как-то принижаю. И это нормально, в js часто используют фп и ооп в связке, при этом ни фп, ни ооп не используют "на полную".
Эхх ученые в говне моченые, опять понаставили дизов новаторским и революционным спекуляциям. 🙃
Касаемо вечного двигателя, то учитесь пока жив: ищем могилы политиков и известных государственный деятелей 20 века по всему миру. Вскрывает их и обнаруживаем внутри вращательнын движения близкие к скорости света. Прикрепляем останки к динамо машине и этого хватит, чтобы запитать целые страны. 😎
А как вообще задача может быть выполнена без следа? Есть же условный гитхаб (или миллион других ему аналогов), где всё по коммитам видно. Есть задача в таск менеджере. Это возможно только в если коммиты пушить раз в неделю, а в задаче вообще никакого summary не давать (просто дальше передать например). А так мысли верные) Я вообще за то, чтобы всё относящееся к работе было в облаке, т.к. истории про "другой компьютер, молния ударила, света нет, почта не работает, меркурий вошёл в венеру и т.д." случаются и причём часто это не отмазки. Когда всё в облаке, это удобно. Я как работник даже если отойду смогу важные быстрые дела сделать хоть с телефона. Да и всякие форс мажоры (которые правда бывают) перестают быть блокером для работы над проектом.
Эх нейронка нейронка.
Если у тим лидов такое в голове, вместо банального анализа kpi, трекинга тасков и анилза пул реквестов, то радуйтесь, что вас из такой команды уволили. Потому что, всем в такой команде будет точно пофиг на результат, все будут стараться выслужиться перед начальством, как раз изображая красивую деятельность.
Однако проблема, скрытой работы реально есть и объяснить её необходимость заказчикам, как раз задача TL PM и Сеньоров иначе в нормальной организации вопрос будет не к джуну, почему он занимался немойми чем, а к тем, кто ему работу давал и принимал. Если джуну дали работу, а он её не сделал или сделал плохо, то тогда вопрос будет к нему, но если он делал работу качественно, а она оказалась организации и заказчикам не нужна, то не джуна проблемы.
База, которая понятна любому программисту) Не совсем понял в чём именно сложность статьи, но вещи написаны верные
Потому что грамотность применения знания и их обширность напрямую зависят от опыта и квалификации. По сути это чуть ли не синонимы.
Есть риск-менеджмент, для предотвращения ошибок или их выявлению.
Помню, один раз летел в самолёте и читал журнал для предпринимателей и бизнеса, где как раз об этой теме писалось. Какой-то "эксперт" писал, что в России низкая производительность труда, потому что все работники вечно ерундой занимаются. То бегают курить (буквально это было указано, как одна из главных причин), то задерживаются на обеде, то отпрашиваются пораньше. А вот на Западе, по его мнению, такого нет, все работают от звонка до звонка со 100% эффектностью. И ни слова, об огромных проблемах в организации труда и управлении персоналом.
Так же ни слова, что на Западе работают профсоюзы и если брать, например немцев, как педантичную нацию, то возможно типичный Ганс и правда курит меньше на работе, но при этом он ровно в 18:00 уходит домой и не делает работу сверх того, что написано у него в договоре. От такого многие наши работодатели с их "мы же семья", "ты что только за деньги работаешь" взвыли бы, т.к. будь они в Европе, их "рога и копыта" профсоюзы прикрыли бы очень быстро.
Это я к чему. Сначала работодалели (которое разделяют мнение эксперта и таких много) пытаются найти людей оркестров, которые должны и пол убирать, и видеомонтаж делать, и за хайлоадом следить, а потом удивляются низкой производительности, привязке к конкретным работникам, выгораниям пенсонала и низкой производительности с учётом плохо налаженных рабочих процессов. Но виноват в этом у подобных руководителей работник Name, что курить часто бегает и в вк сидит на работе.
Думаю, это утверждение относится к любой специальности. Управление рисками и проектирование являются неотъемлемой частью многих специальностей.
Касаемо инженерии, то у самого слова есть вполне себе общепринятое значение. Если для решения практических задач используются математические, технические и научные знания, это уже можно назвать проявлением инжинерии. А вот насколько грамотно эти знания применены и насколько они обширны у конкретных специалистов, это уже вопрос их опыта и квалификации.
То что используют давно в CMS всякие AI функции это понятно)
> Наверно допил функционала слишком специфичен, чтобы решать его вайбкодингом.
Думаю, написать под подобные cms обвязку, что не будет сжирать миллионы токенов и давать внятный результат на деле, не такая уж и простая задача. А так да.
Не старье наверное всякие next.js nuxt.js, хотя уже тоже относительно. Сейчас мне кажется не старьем будет cms с обвязкой под нейронки под капотом, что позволит допиливать модерам админок функционал самостоятельно без программирования. Ну пока этот спагетти код не разрастается до макаронного монстра.)
Не совсем понимаю, что мешало использовать Git с CI/CD, если их можно настроить так же локально или в сети компании. Не совсем понятно, что за deploy-cutover.py? Может это ваш какой-то внутренний скрипт, но мы то откуда знаем его код и по какому принципу он работает и чем отличается от общепринятых CD практик? 🤔
Они ответят, что это в ваш товар плохой и рыночек порешал.)
Это делается для перезаливщиков, которым вк делал выплаты и так неплохие, а сейчас они увеличатся на ~22%.
Дело не только в тире, которые по тексту то длинные, то короткие вперемешку, на скрине это тоже видно. И даже не в tldr по поводу и без. А в самом стиле написания. Неронки в угоду экономии токенов, обожают писать текст тезисно. Противопоставлять одно другому, использовать часто списки, даже там, где они избыточны и строить бОльшую часть текста в формате вопрос-ответ. То что автор написал этот текст не одной генерацией и подрихтовал ответы собрав в одну цельную статью похвально. Если народу нравится, то окей.
Я слишком много использую llm и даже в видео слышу, по слогу, где автор использовал в написании сценария нейронки, а где нет. Правда сейчас многие из-за большого количества работы с llm начинают подражать их стилю и отличить, где подражание, а где реально llm уже сложнее.
Касаемо бана, то я бы ввёл бан за невнимательное прочтение комментариев и манипуляции с выдергиванием контекста с последующим возведением его в абсолют.
И по этому этому по всему тексту разбросаны tl;dr;, а так же длинные тире. Дело ваше, конечно.
Вы шутите? Процентов на 90 это нейрослоп. Все эти пункты, речевые обороты, что оьожает GPT палятчя сразу.
По идее, нейронка так же через mcp будет искать информацию по документации, что по сути тажа трата времени на ризонинг с поиском и чтением md файлов. Как-будто проще запихать большую документацию в векторку, что реально сможет сэкономить контекст.
Реклама может сделать из говна конфетку, только если идеально работает критически важный пользователям функционал.
Хороший пример, чат gpt. Когда он только стал всем доступен, у него постоянно падали сервера, криво работала гугл авторизация с вечным разлогином, до сих пор лагает web ui, когда страница с чатом тормозит при большом количестве вопросов-ответов, т.к. open ai не умеет в нормальную ленивую загрузку и контроль ресурсов. Однако, это всё пользователи готовы терпеть ради главного функционала, что работает отлично, а именно ради самой llm. С точки зрения веба чат gpt посредственен, но мы знаем множество копирок с крутым веб ui ux, но кривой реализацией llm из-за чего они нафиг никому не нужны.
Понимаю, что mvp это термин, который сам по себе подразумевает минимально жизнеспособныйипродукт, но даже в рамках минимума, есть критически важный функционал, который должен работать идеально и второстепенный, который может работать криво.
Поэтому если критически важный функционал не завершён - то проект никакя реклама не спасет, это верно)
Уже многое написали про тех. готовность. Незавершённость проекта оправдана, только в одном случае: если ваш продукт уникальный и даже в таком качестве лучше конкурентов.
По опыту, могу сказать, чтобы занять нишу, нужно хорошо знать конкретную сферу и её рынок.
Например, я практически всё время работал в мед. организацих. Из-за чего хорошо знаю эту кухню. Если когда-то захочу создать стартап, у меня есть представление, что будет удобно и интересно врачам. Какаое тех качество допустимо для mvp и что критически важно в продукте. Так же, знаю главное, как набирать клиентскую базу и специфику сферы. За свою жизнь повидал много мед. стартапов и прекрасно знаю их ошибки. Поэтому у меня бы всё скорее-всего получилось.
Однако, если бы я захотел залезть в финтех, логистику и т.д., то скорее-всего провалился. Да, проводил бы ресерч рынка, пытался бы получить фидбэк, но без понимания того, что нужно и важно конечному пользователю и как вообще ему о продукте рассказать, это путь в никуда.
Лично стартапы не открывал, но пет проекты делаю часто. Какие-то забрасываю, какие-то в долгострое, а какие-то использую в обиходе или отдаю коллегам. Так же, участвовал в чужих стартарах.
Честно, как бы не пытался делать пет проекты, держа всё в голове, всё всегда сводилось, к списку задач с ротацией: бэклог - в работе - выполнено, а потом и к доскам с карточками.
За всё время понял одно. Если хочешь сделать, что-то годное, среднее+ по масштабам, то к проекту нужно относиться словно он оплачиваемый энтерпрайз. Даже если ты вайбкодишь. Точнее особенно если ты вайбкодишь, всегда используй таск менеджеры, гит с моно репо, юнит тесты (очень желательно даже если кажется, что они лишние, не повторяйте моих ошибок), ci cd на свой сервер если это бэкенд. Если приложение или игра, то грамотная настройка билда с публикацией, а не просто debug-build. Только дисциплиной можно добиться результатов. По сути вы должны быть сами себе аналитиком, продуктом, дизайнером, программистом, тестировщиком, ceo и даже конечным пользователем.
П.С. Перечитал, написанное, вроде очевидные вещи, однако многие про них знают, но на практике не осознают.
Если честно для ООП он тоже мало подходит. Тот же ts по сути обёртка, которая не спасает от проблем в рантайме, ведь код компилируется в обычный js. Поэтому хоть сколько-то адекватный код приходится писать с оглядкой на это.
Вроде же автор, сам в статье расскрыл эти проблемы, не совсем понимаю в чём претензия к кандидатам на собесах?) То что они не прочитали лекцию, чем именно js плох для чистого фп?)
Он не был скорректирован и для ООП, но очень многие разработчики пишут на нем код именно в ООП стиле. Тоже самое и с ФП. Зачасую для js разработчиков на практике даже рекурсия не нужна. Всё фп заканчивается написанием функций под event loop и промисы. Большинство js разработчиков не приведет пример монады, функтора или апликатива. Даже не так, большинство разработчиков на популярных яп, это вряд-ли сделают, чтобы js разработчики, не думали, что я их как-то принижаю. И это нормально, в js часто используют фп и ооп в связке, при этом ни фп, ни ооп не используют "на полную".
Ой, порог входа в профессию. Немного криво написал. С годами, порог входа в программирование будет только расти.
Мне кажется наоборот вход в профессию выростит, потому что если все смогут кодить, то и уровень к специалисту будет выше)