Я в своё время сделал pomodoro-таймер, где цель - набрать нужное количество помидорок за день. После перехода на удалённую работу график стал более размытым, начал работать в перерывах, когда жду детей на занятиях, поэтому учёт помидорок помогал учитывать отработанное время. А детям можно было сказать: "Мне нужно набрать ещё пару помидорок, и я с вами поиграю".
Но потом понял, что работе в состоянии фокуса эти помидорки мешают - отвлекают звуком и необходимостью запускать таймер. Поэтому сейчас навайбкодил себе такой FocusBar
Внизу экрана ненавязчиво показывает, какой этап рабочего дня сейчас идёт: сконцентрированная работа, обед, совещание, перерыв. Цвета подобрал, чтобы не отвлекали. Удобно, что не отвлекает звуками и уведомлениями, но ненавязчиво структурирует рабочий день.
Я буквально на днях осознал, что ИИ не ускоряет меня, а замедляет, хотя это может звучать парадоксально. Нужно было сделать небольшую правку, но я по привычке стал делать через LLM. И ей сначала нужно объяснить задачу, потом прочитать весь её объемный вывод, понять, что ответ меня не устраивает, переформулировать запрос и снова прочитать объёмный ответ модели, и снова... А можно было просто взять и сделать самому. При этом иногда я практикую написание самому, руками, и это такое приятное ламповое ощущения контроля.
А чтобы не выгорать и видеть смысл в работе, я нашел такое средство - повышение квалификации. Стараюсь в день 1-2 вопроса разбирать, параллельно создаю карточки Anki для запоминания и конспектирую рукой в тетрадке. Это тоже, как оказалось, весьма приятное чувство)
Спасибо за статью! Интересный опыт. Я сам когда-то пытался пробиться через фильтры Google для публикации пет-проекта. Сначала забанили, из-за того, что на скриншоте была станица электронной книги с текстом "I’m pretty much fucked.". А затем я не смог найти нужного числа бета-тестеров с Android и Google-аккаунтами. Поэтому пришлось публиковаться на RuStore и через публикацию apk-файла.
Я тоже в конце прошлого года устраивался в Яндекс Вертикали. Опыт 17 лет, в том числе системы обработки данных реального времени на C++, университетское образование, опыт руководства проектом. С HR пообщались хорошо. Техническую секцию по ощущениям прошёл хорошо, на все вопросы ответил, даже нечего было записать по обыкновению на будущее изучение. Задачу решил по оценке ChatGPT на 10 из 10.
Ждал ответ недели 3, не дождался, решил сам написать. HR думала, что мне обратную связь передали, перенаправила к другой HR. Та тоже думала, что обратную связь дали. В результате запросила у команды - отказ, стандартная отписка, даже без подробностей.
А после этого мой друг пробовался туда же. Крутой спец, руководил блокчейн-проектом. И тоже не прошёл, причём в ответ получил тот же самый шаблонный отказ.
Есть ещё такое когнитивное искажение: когда ты сам подготовил вопросы и знаешь на них правильные ответы, то кажешься себе умным, а те, кто ответов не знают - глупые. Замечал это, когда принимал экзамены в университете и искренне не понимал, как можно не знать ответов на такие очевидные (для меня) вопросы.
Это я к тому, что если на собеседовании кандидат не знает ответов на ВАШИ вопросы, это ещё не означает, что он не компетентен.
Однажды мне предстояло разрабатывать Android-приложение на Kotlin, да к тому же руководить командой. С Kotlin и в целом с Android у нас опыта не было, следовательно в резюме бы я эти навыки написать не смог, и формально на позицию не подходил. Тем не менее приложение с ML под капотом мы успешно запилили и вывели на рынок. Такой вот парадокс.
И что указывать в резюме? Только сильные навыки? Я 12 лет писал на плюсах, но после 4-летнего перерыва забыл, как класс объявить. Так мне и плюсы тогда не указывать? Потом за 5 минут контекст погрузил, вспомнил и написал.
Так что сложный вопрос, как нанимать. Я убеждён, что человека надо смотреть в деле. Но с другой стороны, когда сотни откликов, всех на испытательный срок не примешь. Пока склоняюсь к тому, что связи и рекомендации будут иметь роль при поиске сотрудников/работы.
Читаю такие статьи, и странное чувство возникает - по описанным критериям я волк: я не расскажу в деталях, как работает JVM, так как в работе мне это не нужно. Про сборщик мусора могу только предполагать, что он освобождает память при выходе из скоупа. Про kafka в деталях не расскажу, т.к. она используется, и я просто дорабатывал немного консьюмеров и продьюсеров в коде, а когда настраивал - сделал это один раз под задачу, и сейчас повторно в этом надо будет разбираться заново. group by в SQL по памяти не напишу, хотя знаю, что это, просто от силы за всё время работы такое требовалось раз 5. Задачу на кодинг без подсказок IDE в блокноте под стрессом решу не идеально. Так что по всем критериям я волк.
Но в то же время у меня 18 лет опыта, честное универское образование. Во всех фирмах, где я работал и работаю нет никаких нареканий, успешно проходил испытательные сроки, вывозил самые сложные задачи.
Вот я и не могу понять, то ли со мной что-то не так, то ли с системой оценки кандидатов.
Мне понравилась идея. Видимо, потому, что я люблю путешествовать, а после прочтения «Человеческого фактора» мечтаю работать в кристаллизованной команде единомышленников. По крайней мере в моем воображении идея работает
Вы очень интересную тему затронули, и, судя по результатам голосования, это вовсе не Ваша личная проблема. Когда читал, казалось, будто сам это написал — настолько знакомым было описанное. Часто я могу очень углубиться в проблему, что остальное кажется неважным. Например, могу целый день писать сценарий, делающий бэкапы, нумерующий версии, делающий еще кучу всего, и думаю: «Как же я раньше-то жил без этого, это ведь так важно!». То есть ухожу в сторону от решаемой задачи, хотя, вроде, и не бездельничаю.
Если такое возникает, и решить вопрос сходу не получается, то нужно вынести его на обсуждение с друзьями. Может оказаться, что проблема надумана, или друзья подскажут красивое решение, или вместе придем к выводу, что проблема действительно важная, но нужно пока отложить ее решение. У меня бывало, что тратил кучу времени и сил, и не мог решить проблему, а через некоторое время находил красивое решение. Так было, например, с scm-manager.
Часто возникает вопрос, до какой степени качества доводить систему. Должен быть разумный баланс, и я думаю, что помочь в этом могут заранее заданные критерии качества. Они могут существовать для кода, для интерфейса, для документации и т.п. Прохождение этих критериев снимает с человека психологическую нагрузку, повышается доверие к разрабатываемому продукту.
Еще пользуюсь таким приемом: после того, как сделаю основу, пробегаюсь по результатам и записываю все, что мне не очень нравится. Часто оказывается, что многие недостатки можно устранить «малой кровью», это не отнимает много времени, но делает программу эстетичнее.
Выше в комментариях говорили про внешние обязательства, например, регулярные релизы. Тоже хороший метод. Я, например, для себя составляю оперативные планы в Redmine, и пусть они носят для меня рекомендательный характер, но внутренне структурируют, позволяют сохранять направление на курс.
Лучшее — враг хорошего, нужно давать системе пространство для роста. Как у меня друзья сегодня сказали, пользователи могут не пользоваться плохим продуктом, но хорошим, но не выпущенным продуктом, они вообще не смогут пользоваться!
И да, понравилась мантра «Make it Work, Make it Right, Make it Fast». Разработка — процесс итеративный. Вселенная по спирали эволюционирует :)
Полностью согласен с вашими замечаниями про рефакторинг в прототипе. Не раз уже замечал, что до того наэкспериментируешься, такого кода нагородишь в прототипе, что дальше экспериментировать просто невозможно. И тогда просто выбора не остается, приходится делать рефакторинг. И чем более высокого уровня язык, тем это быстрее и проще
Всем, кто принимал участие в проверке. Причем, это не должно быть компромиссным решением, а именно решение, устраивающее всех. Если у кому-то из участников решение не нравится, значит либо в решении есть противоречие, которое нужно устранить, либо участник не правильно его понимает, и эта проблема решается обсуждением.
А размер группы не имеет смысла делать более 4-5 человек, а такое количество людей вполне могут договориться
Сложно точно сказать, можно только предположить. Я в последнее время все больше прихожу к тому, что в работе важнее всего взаимодействие, командная работа. Для участников команды важно, что они трудятся под одной крышей. И еще важна эстетическая составляющая. В «офисе», расположенном на берегу горного озера приятнее работать. А для стартаперов, не имеющих возможности снимать дорогой офис в красивом месте, это может быть важно. И еще рабочий процесс своеобразно переплетается с игровым процессом, поэтому и взаимодействие в команде будет более живым, интересным, может команда даже станет сплоченнее
Точнее работа-игра. Поработал, решил отдохнуть — поиграл прямо тут же. Но все же я не думаю, что это будет игра в работу. Я представляю, что в основном на экране будет именно обычная рабочая среда, просто при этом будет ощущение, что ты сидишь не у себя дома, а в офисе с другими людьми. Большее ощущение присутствия, по сравнению, например, со скайпом
Чтобы отследить такие вещи, анализатор должен понимать смысл написанного. Поэтому оставим эту задачу на откуп человеку. По крайней мере пока.
А чтобы помочь будущим разработчикам в анализе кода, можно заранее определиться с терминологией, на подобии того, как заранее продумываются интерфейсы. А то я часто встречал примеры (иногда и сам грешил), когда одна вещь в разных местах называется по-разному, разные вещи называются одинаково, а некоторые названия придумываются мимоходом в процессе кодирования. Мне вообще кажется, что задачи проектирования и реализации должны разграничиваться. Сначала придумываем, что и как хотим сделать, а потом делаем. Если пытаться проектировать «по ходу», получается плохо. Проверял.
Извините, я не понял, что вы имеете ввиду. По-моему, все приведенные вами примеры хорошо укладываются в предложенную метрику. Если бы вместо суммирования был какой-то сложный код, то его стоило бы вынести в функцию с понятным названием, и тогда можно было бы в ее реализацию не заглядывать.
По поводу сложности инструкций — я понял вашу мысль. Выше был комментарий, и я с ним согласен, что для небольших фрагментов кода можно считать не скроллы и переходы, а время потраченное на анализ кода.
Я не совсем это имел ввиду. Зависимости — это другая грань качества кода. Предложенная же метрика ориентированна именно на понятность для человека. Хотя, скорее всего, код с небольшим числом зависимостей будет и достаточно понятным
Нет, конечно! Если программа большая, то какого же размера будет эта функция, и сколько в ней будет переменных! Листать и переходить в ней придется много, из-за чего метрика уменьшится.
Говоря про главную функцию я имел ввиду, что если она понятно написана, то не обязательно нужно будет смотреть вызываемые функции. Из вызова (названия и параметров) будет понятно их назначение.
Я в своё время сделал pomodoro-таймер, где цель - набрать нужное количество помидорок за день. После перехода на удалённую работу график стал более размытым, начал работать в перерывах, когда жду детей на занятиях, поэтому учёт помидорок помогал учитывать отработанное время. А детям можно было сказать: "Мне нужно набрать ещё пару помидорок, и я с вами поиграю".
Но потом понял, что работе в состоянии фокуса эти помидорки мешают - отвлекают звуком и необходимостью запускать таймер. Поэтому сейчас навайбкодил себе такой FocusBar
Внизу экрана ненавязчиво показывает, какой этап рабочего дня сейчас идёт: сконцентрированная работа, обед, совещание, перерыв. Цвета подобрал, чтобы не отвлекали. Удобно, что не отвлекает звуками и уведомлениями, но ненавязчиво структурирует рабочий день.
Я буквально на днях осознал, что ИИ не ускоряет меня, а замедляет, хотя это может звучать парадоксально. Нужно было сделать небольшую правку, но я по привычке стал делать через LLM. И ей сначала нужно объяснить задачу, потом прочитать весь её объемный вывод, понять, что ответ меня не устраивает, переформулировать запрос и снова прочитать объёмный ответ модели, и снова... А можно было просто взять и сделать самому. При этом иногда я практикую написание самому, руками, и это такое приятное ламповое ощущения контроля.
А чтобы не выгорать и видеть смысл в работе, я нашел такое средство - повышение квалификации. Стараюсь в день 1-2 вопроса разбирать, параллельно создаю карточки Anki для запоминания и конспектирую рукой в тетрадке. Это тоже, как оказалось, весьма приятное чувство)
Спасибо за статью! Интересный опыт. Я сам когда-то пытался пробиться через фильтры Google для публикации пет-проекта. Сначала забанили, из-за того, что на скриншоте была станица электронной книги с текстом "I’m pretty much fucked.". А затем я не смог найти нужного числа бета-тестеров с Android и Google-аккаунтами. Поэтому пришлось публиковаться на RuStore и через публикацию apk-файла.
Кстати, может кому интересно будет - приложение для изучения английского в виде читалки со встроенным переводом: https://www.rustore.ru/catalog/app/com.stanislavlyalin.enjoy
Я тоже в конце прошлого года устраивался в Яндекс Вертикали. Опыт 17 лет, в том числе системы обработки данных реального времени на C++, университетское образование, опыт руководства проектом. С HR пообщались хорошо. Техническую секцию по ощущениям прошёл хорошо, на все вопросы ответил, даже нечего было записать по обыкновению на будущее изучение. Задачу решил по оценке ChatGPT на 10 из 10.
Ждал ответ недели 3, не дождался, решил сам написать. HR думала, что мне обратную связь передали, перенаправила к другой HR. Та тоже думала, что обратную связь дали. В результате запросила у команды - отказ, стандартная отписка, даже без подробностей.
А после этого мой друг пробовался туда же. Крутой спец, руководил блокчейн-проектом. И тоже не прошёл, причём в ответ получил тот же самый шаблонный отказ.
Сломан найм в Яндексе, похоже.
Есть ещё такое когнитивное искажение: когда ты сам подготовил вопросы и знаешь на них правильные ответы, то кажешься себе умным, а те, кто ответов не знают - глупые. Замечал это, когда принимал экзамены в университете и искренне не понимал, как можно не знать ответов на такие очевидные (для меня) вопросы.
Это я к тому, что если на собеседовании кандидат не знает ответов на ВАШИ вопросы, это ещё не означает, что он не компетентен.
Однажды мне предстояло разрабатывать Android-приложение на Kotlin, да к тому же руководить командой. С Kotlin и в целом с Android у нас опыта не было, следовательно в резюме бы я эти навыки написать не смог, и формально на позицию не подходил. Тем не менее приложение с ML под капотом мы успешно запилили и вывели на рынок. Такой вот парадокс.
И что указывать в резюме? Только сильные навыки? Я 12 лет писал на плюсах, но после 4-летнего перерыва забыл, как класс объявить. Так мне и плюсы тогда не указывать? Потом за 5 минут контекст погрузил, вспомнил и написал.
Так что сложный вопрос, как нанимать. Я убеждён, что человека надо смотреть в деле. Но с другой стороны, когда сотни откликов, всех на испытательный срок не примешь. Пока склоняюсь к тому, что связи и рекомендации будут иметь роль при поиске сотрудников/работы.
Читаю такие статьи, и странное чувство возникает - по описанным критериям я волк: я не расскажу в деталях, как работает JVM, так как в работе мне это не нужно. Про сборщик мусора могу только предполагать, что он освобождает память при выходе из скоупа. Про kafka в деталях не расскажу, т.к. она используется, и я просто дорабатывал немного консьюмеров и продьюсеров в коде, а когда настраивал - сделал это один раз под задачу, и сейчас повторно в этом надо будет разбираться заново. group by в SQL по памяти не напишу, хотя знаю, что это, просто от силы за всё время работы такое требовалось раз 5. Задачу на кодинг без подсказок IDE в блокноте под стрессом решу не идеально. Так что по всем критериям я волк.
Но в то же время у меня 18 лет опыта, честное универское образование. Во всех фирмах, где я работал и работаю нет никаких нареканий, успешно проходил испытательные сроки, вывозил самые сложные задачи.
Вот я и не могу понять, то ли со мной что-то не так, то ли с системой оценки кандидатов.
Если такое возникает, и решить вопрос сходу не получается, то нужно вынести его на обсуждение с друзьями. Может оказаться, что проблема надумана, или друзья подскажут красивое решение, или вместе придем к выводу, что проблема действительно важная, но нужно пока отложить ее решение. У меня бывало, что тратил кучу времени и сил, и не мог решить проблему, а через некоторое время находил красивое решение. Так было, например, с scm-manager.
Часто возникает вопрос, до какой степени качества доводить систему. Должен быть разумный баланс, и я думаю, что помочь в этом могут заранее заданные критерии качества. Они могут существовать для кода, для интерфейса, для документации и т.п. Прохождение этих критериев снимает с человека психологическую нагрузку, повышается доверие к разрабатываемому продукту.
Еще пользуюсь таким приемом: после того, как сделаю основу, пробегаюсь по результатам и записываю все, что мне не очень нравится. Часто оказывается, что многие недостатки можно устранить «малой кровью», это не отнимает много времени, но делает программу эстетичнее.
Выше в комментариях говорили про внешние обязательства, например, регулярные релизы. Тоже хороший метод. Я, например, для себя составляю оперативные планы в Redmine, и пусть они носят для меня рекомендательный характер, но внутренне структурируют, позволяют сохранять направление на курс.
Лучшее — враг хорошего, нужно давать системе пространство для роста. Как у меня друзья сегодня сказали, пользователи могут не пользоваться плохим продуктом, но хорошим, но не выпущенным продуктом, они вообще не смогут пользоваться!
И да, понравилась мантра «Make it Work, Make it Right, Make it Fast». Разработка — процесс итеративный. Вселенная по спирали эволюционирует :)
А размер группы не имеет смысла делать более 4-5 человек, а такое количество людей вполне могут договориться
А чтобы помочь будущим разработчикам в анализе кода, можно заранее определиться с терминологией, на подобии того, как заранее продумываются интерфейсы. А то я часто встречал примеры (иногда и сам грешил), когда одна вещь в разных местах называется по-разному, разные вещи называются одинаково, а некоторые названия придумываются мимоходом в процессе кодирования. Мне вообще кажется, что задачи проектирования и реализации должны разграничиваться. Сначала придумываем, что и как хотим сделать, а потом делаем. Если пытаться проектировать «по ходу», получается плохо. Проверял.
По поводу сложности инструкций — я понял вашу мысль. Выше был комментарий, и я с ним согласен, что для небольших фрагментов кода можно считать не скроллы и переходы, а время потраченное на анализ кода.
Говоря про главную функцию я имел ввиду, что если она понятно написана, то не обязательно нужно будет смотреть вызываемые функции. Из вызова (названия и параметров) будет понятно их назначение.