Как будто у нас есть тип A и тип B, а потом мы каждому добавляем ещё одно поле, чтобы их различать между собой. Такое ощущение, что что-то пошло не так.
Возможно, эту проблему можно решить через type guard?
Кажется, что здесь проблема с приоритезацией задач. Должен быть некий менеджер проекта, который будет говорить что очень важно, а что не важно. Другие могут только добавлять вводные, например, я как разработчик могу повлиять на включение техдолга, который заблокирует разработку или что-нибудь подобное.
Цель спринта как решение проблемы не очень понятно что даст, так как проблема описанная в статье может быть и в канбане. В целом, задача сама по себе должна давать понимание того, зачем она нужна, без цели спринта.
Приоритезация - это то, что решит проблему.
DoD - не всегда должен влиять на клиента, могут быть технические оптимизации. Не стоит смешивать критерии завершенности задачи и клиента
Это был "совковый" метод контроля разработчиков, чтобы мы не котиков смотрели, а код писали. Размеры выдались разные от 300мб, то нескольких Гб. Один раз тимлид смог продавить реформу и всем дали по 10Гб.
А за повышение отключали интернет, надо было написать заявку на админов, они или добавляли трафика немного, то ли обнуляли "пакет", точно не помню уже.
Интернет у меня с 2010 еще в общаге был безлимитный, и все было относительно хорошо. Это особенности той компании, чтобы работники не смотрели картинки, вместо работы)
Есть одна небольшая компания в Екатеринбурге. Название говорить уж не буду. У меня по приходу туда было 2Гб трафика, а потом с подачи тимлида подняли лимит до 10Гб и я был местным мажором) Приходилось изгаляться, поставил расширение, которое блочит не только рекламу, но и скрывает изображения. И дополнительно узнали, что teamviewer не учитывался в трафике и можно было тогда через него смотреть что-нибудь через свой домашний ПК) А ограничение было вроде до момента ухода, это был уже 2018 год. Как сейчас дела не знаю)
Работал в одной компании, где было ограничение трафика для всех, в том числе и разработчиков. У одного коллеги было 300мб на месяц в 2016 году. Он их "сжег" за 5 минут, потому что опечатался и гугл выдал ему вместо stackoverflow - catoverflow. На сайте оказались гифки с котиками)
Понятия не имею, если честно. Я не эксперт в ракетостроении, знаю что есть стартап, который делает центрифугу. Знаю, что проводят уже испытания на прототипах. И у них нет цели выводить на орбиту много груза, они хотят выводить небольшие спутники.
Вроде как идея и заключается в том, чтобы запустить ракету в полет с помощью центрифуги, а потом уже включить двигатели. По сути идея в замене первой ступени ракеты на центрифугу.
Уже есть такой стартап SpinLaunch, который с помощью центрифуги раскручивает ракету и потом запускает ее в космос. Но пока результатов не сильно много. Но рабочие прототипы есть и ведутся исследования.
"Доступны для пробного использования разработчиками в Chrome и Edge 139", сейчас актуальная версия 137, или ставить экспериментальную сборку или ждать еще месяц-другой.
Тогда Тим Стокли заведет AIFans, где будет создаваться куча контента по сути в прямом эфире с помощью тысяч видеокарт, и тогда он будет платить только налоги и за электричество.
Классно, если есть навык работать в консоли. Так как я фронтендер, то приходится мышкой тыкать в экран, чтобы все проверять и перепроверять по 100 раз, поэтому 100% vim головного мозга не смогу получить. Но в один момент заметил, что VS Code делает кучу лишних вещей при переходе между ветками git. Мне это дело не понравилось, начал пользоваться консолью для гита. А чуть позже открыл для себя мир git alias и теперь популярные команды пишу еще короче. Теперь вместо `git checkout master` пишу `git cm`.
А почему бы не добавить обратную связь на HR-ов и рекрутинг. Много где есть оценка текущего места работы, но почему я не могу дать обратную связь по компании, которая меня хочет нанять. Можно также выработать важные критерии: хорошо ли описана вакансия, дали обратную связь, заспамили, все ли подробно объяснили и т.д.
Возможно, при таком подходе и со стороны нанимателей будут какие-то бест-практис. Потому что есть миллион статей "как написать красивое резюме", но сильно меньше "как граммотно нанять кандидата".
Будет своего рода социальный рейтинг, если компания хочет развиваться, то и свой найм будет дотягивать до оценки 5.0, а если это будет совковая колхозная шарага, то это будет видно заранее.
Сейчас много различных телефонных ассистентов, они должны тогда научиться блокировать разговор по словам и фразам "майор ФСБ", "центробанк", "безопасный счет")
Нейросети хорошо подходят для того, чтобы преобразовывать одну текстовую структуру в другую.
Проверял насколько можно позволить нейронкам документацию на своем профиле в github. Загрузил в deepseek 9 скриншотов таблицы статистики (потому что не было API), он успешно распознал табличные данные, по моей просьбе просуммировал все и построил график в mermaid раз 5-6 (не нравились диапазоны и я просил другие).
Также делал библиотеку из одного компонента, решил "написать" документацию. Поместил код в нейронку, на выходе получил readme.md, минут за 5 почистил от воды и получил счастье.
Так как я разработчик, то в своих проектах я сперва пишу код, потом документацию. Хотя и на работе также. Есть верхнеуровневая документация, которая описывает поведение приложения, а я как разработчик уже сам декомпозирую постановку и создаю внутренние библиотеки с документацией.
Будь я аналитиком, то скорее всего сперва генерировал бы документацию, а потом уже кто-то генерировал код по нему.
На счет дейликов (из урока №3), на которых подсвечивают риски и проблемы. Они для этого и нужны, так как понять в каком статусе задача можно и смотря на доску в Jira или на доске со стикерами. Если там написано inProgress, значит я ее делаю и есть ли смысл спрашивать об этом - не понятно, оно же видно. Там же видно и то, что я делал вчера и то, что буду делать дальше (потому что у задач есть приоритет и надо брать самую приоритетную).
А вот если я оценили задачу в 2 дня, а делаю ее неделю - вот тут стоит спросить, что пошло не так. Или если я вижу затык по проблеме - я должен уточнить у кого-нибудь на дейли, если не сделал этого раньше.
Интересная статья. Недавно начал активно использовать ИИ-асистенотов и mermaid, понял, что они не плохо подходят для генерации документации к коду, а также для перевода одной текстовой структуры в другую.
Решил ради интереса и тренировки оформить свой github-профиль, использовал mermaid и deep-seek. Скинул 10 скриншотов статистики в deep-seek, с помощью него распознал табличные данные, попросил посчитать и построить график. Аналогично другие структуры в профиле заводил в различные графики mermaid.
Также пару раз генерировал код для простых библиотек, закидывал код в ИИ и просил написать readme-файл, получалось неплохо. Потом минут за 5 вычищал лишнюю воду и вуаля.
Почему программисты не пишущие документацию не начали использовать ИИ и mermaid+markdown для быстрого и легкого написания документации - не понятно) Ревью текста займет явно меньше времени, чем написать все с нуля.
Как будто у нас есть тип A и тип B, а потом мы каждому добавляем ещё одно поле, чтобы их различать между собой. Такое ощущение, что что-то пошло не так.
Возможно, эту проблему можно решить через type guard?
Кажется, что здесь проблема с приоритезацией задач. Должен быть некий менеджер проекта, который будет говорить что очень важно, а что не важно. Другие могут только добавлять вводные, например, я как разработчик могу повлиять на включение техдолга, который заблокирует разработку или что-нибудь подобное.
Цель спринта как решение проблемы не очень понятно что даст, так как проблема описанная в статье может быть и в канбане. В целом, задача сама по себе должна давать понимание того, зачем она нужна, без цели спринта.
Приоритезация - это то, что решит проблему.
DoD - не всегда должен влиять на клиента, могут быть технические оптимизации. Не стоит смешивать критерии завершенности задачи и клиента
Это был "совковый" метод контроля разработчиков, чтобы мы не котиков смотрели, а код писали. Размеры выдались разные от 300мб, то нескольких Гб. Один раз тимлид смог продавить реформу и всем дали по 10Гб.
А за повышение отключали интернет, надо было написать заявку на админов, они или добавляли трафика немного, то ли обнуляли "пакет", точно не помню уже.
Интернет у меня с 2010 еще в общаге был безлимитный, и все было относительно хорошо. Это особенности той компании, чтобы работники не смотрели картинки, вместо работы)
Есть одна небольшая компания в Екатеринбурге. Название говорить уж не буду. У меня по приходу туда было 2Гб трафика, а потом с подачи тимлида подняли лимит до 10Гб и я был местным мажором) Приходилось изгаляться, поставил расширение, которое блочит не только рекламу, но и скрывает изображения. И дополнительно узнали, что teamviewer не учитывался в трафике и можно было тогда через него смотреть что-нибудь через свой домашний ПК)
А ограничение было вроде до момента ухода, это был уже 2018 год. Как сейчас дела не знаю)
Работал в одной компании, где было ограничение трафика для всех, в том числе и разработчиков. У одного коллеги было 300мб на месяц в 2016 году. Он их "сжег" за 5 минут, потому что опечатался и гугл выдал ему вместо stackoverflow - catoverflow. На сайте оказались гифки с котиками)
Понятия не имею, если честно. Я не эксперт в ракетостроении, знаю что есть стартап, который делает центрифугу. Знаю, что проводят уже испытания на прототипах. И у них нет цели выводить на орбиту много груза, они хотят выводить небольшие спутники.
Вроде как идея и заключается в том, чтобы запустить ракету в полет с помощью центрифуги, а потом уже включить двигатели. По сути идея в замене первой ступени ракеты на центрифугу.
Уже есть такой стартап SpinLaunch, который с помощью центрифуги раскручивает ракету и потом запускает ее в космос. Но пока результатов не сильно много. Но рабочие прототипы есть и ведутся исследования.
"Доступны для пробного использования разработчиками в Chrome и Edge 139", сейчас актуальная версия 137, или ставить экспериментальную сборку или ждать еще месяц-другой.
Тогда Тим Стокли заведет AIFans, где будет создаваться куча контента по сути в прямом эфире с помощью тысяч видеокарт, и тогда он будет платить только налоги и за электричество.
Классно, если есть навык работать в консоли. Так как я фронтендер, то приходится мышкой тыкать в экран, чтобы все проверять и перепроверять по 100 раз, поэтому 100% vim головного мозга не смогу получить. Но в один момент заметил, что VS Code делает кучу лишних вещей при переходе между ветками git. Мне это дело не понравилось, начал пользоваться консолью для гита. А чуть позже открыл для себя мир git alias и теперь популярные команды пишу еще короче. Теперь вместо `git checkout master` пишу `git cm`.
А почему бы не добавить обратную связь на HR-ов и рекрутинг. Много где есть оценка текущего места работы, но почему я не могу дать обратную связь по компании, которая меня хочет нанять. Можно также выработать важные критерии: хорошо ли описана вакансия, дали обратную связь, заспамили, все ли подробно объяснили и т.д.
Возможно, при таком подходе и со стороны нанимателей будут какие-то бест-практис. Потому что есть миллион статей "как написать красивое резюме", но сильно меньше "как граммотно нанять кандидата".
Будет своего рода социальный рейтинг, если компания хочет развиваться, то и свой найм будет дотягивать до оценки 5.0, а если это будет совковая колхозная шарага, то это будет видно заранее.
Сейчас много различных телефонных ассистентов, они должны тогда научиться блокировать разговор по словам и фразам "майор ФСБ", "центробанк", "безопасный счет")
Нейросети хорошо подходят для того, чтобы преобразовывать одну текстовую структуру в другую.
Проверял насколько можно позволить нейронкам документацию на своем профиле в github. Загрузил в deepseek 9 скриншотов таблицы статистики (потому что не было API), он успешно распознал табличные данные, по моей просьбе просуммировал все и построил график в mermaid раз 5-6 (не нравились диапазоны и я просил другие).
Также делал библиотеку из одного компонента, решил "написать" документацию. Поместил код в нейронку, на выходе получил readme.md, минут за 5 почистил от воды и получил счастье.
Возможно, они перешли к TBD, но это не точно
Я бы еще в список добавил Angular, который тоже слез с игры webpack около года назад.
Так как я разработчик, то в своих проектах я сперва пишу код, потом документацию. Хотя и на работе также. Есть верхнеуровневая документация, которая описывает поведение приложения, а я как разработчик уже сам декомпозирую постановку и создаю внутренние библиотеки с документацией.
Будь я аналитиком, то скорее всего сперва генерировал бы документацию, а потом уже кто-то генерировал код по нему.
Не очень уверен, что правильно ответил на вопрос)
На счет дейликов (из урока №3), на которых подсвечивают риски и проблемы. Они для этого и нужны, так как понять в каком статусе задача можно и смотря на доску в Jira или на доске со стикерами. Если там написано inProgress, значит я ее делаю и есть ли смысл спрашивать об этом - не понятно, оно же видно. Там же видно и то, что я делал вчера и то, что буду делать дальше (потому что у задач есть приоритет и надо брать самую приоритетную).
А вот если я оценили задачу в 2 дня, а делаю ее неделю - вот тут стоит спросить, что пошло не так. Или если я вижу затык по проблеме - я должен уточнить у кого-нибудь на дейли, если не сделал этого раньше.
Интересная статья. Недавно начал активно использовать ИИ-асистенотов и mermaid, понял, что они не плохо подходят для генерации документации к коду, а также для перевода одной текстовой структуры в другую.
Решил ради интереса и тренировки оформить свой github-профиль, использовал mermaid и deep-seek. Скинул 10 скриншотов статистики в deep-seek, с помощью него распознал табличные данные, попросил посчитать и построить график. Аналогично другие структуры в профиле заводил в различные графики mermaid.
Также пару раз генерировал код для простых библиотек, закидывал код в ИИ и просил написать readme-файл, получалось неплохо. Потом минут за 5 вычищал лишнюю воду и вуаля.
Почему программисты не пишущие документацию не начали использовать ИИ и mermaid+markdown для быстрого и легкого написания документации - не понятно) Ревью текста займет явно меньше времени, чем написать все с нуля.