Dan Groove
Не раскрыта тема что делать после того как токены засунуты в арбитрум. Хорошо бы пример проекта который с ним интегрировался и как именно работает такая интеграция.
Покупаешь биток с каждой зарплаты в течении нескольких лет, например. Загугли "Dollar Cost Average bitcoin".
Работаю в Долине будучи между Уралом и Сибирью. Пересечения утром и вечером, и норм. И, внезапно, это позволяет очень неплохо присмотреть за продакшеном когда они там спят.
Вообще я записываю все интересные идеи, которые приходят в голову, потом сортирую, большая часть привязывается к какому-то проекту или контексту и уходит в someday.
Иногда просматриваю someday, и беру оттуда в работу что-нибудь (когда разгребается next).
Проект не должен быть отдельной сущностью где-то в стороне, в софте который я использую все проектные задачи так же точно как и другие лежат в tomorrow / next / someday / назначены на дату. Так что ни о какой моей идеальности речи не идёт.
Использую doit.im, который реализует GTD и как иногда называют "метод пустого инбокса". Кстати, рекомендую всем посмотреть на youtube Александра Дорофеева "Джедайская техника 2.0".
На счёт периодических задач в корне не согласен. Например, у меня там все задачи вида "передать показания счётчиков", "оформить диагностическую карту", "продлить ОСАГО" и т.д.
Неэффективность разбивки на проекты - не согласен. По сути проект это просто сгруппированные задачи, относящиеся к проекту. Это даёт наглядность.
А для продуктовой разработки мне нравится использовать доску как в kanban. Потому что позволяет классно визуализировать движение задач от начальной идеи до выпуска релиза.
Ещё у Лимончелли читал про то, что есть 2 подхода:
1. нанимать людей
2. нанимать навыки
Т.е. первый - это найм умных людей, которые если и не знают, то разберутся/научатся, а второй - это найм по конкретным требованиям. Хотя на практике это часто комбинируют. Может капитаню, но всё же решил дописать.
Один мой товарищ на должности head of operations (или как там) в очень известной компании вообще говорил, что более приоритетно рассматривает заинтересованность человека, его уверенность в себе, своих способностях. Например, порекомендовал я ему человека, который ранее со мной работал, как спец он норм, middle которому пора переходить в senior, и вот он его не взял именно не по техническим причинам, а потому что человек не был уверен в себе, недооценивал свои возможности.
Сложно сказать, ну ясно что надо изучать предметную область, что вы и делаете. Так же, взаимодействовать с IT-спецами компании, слушать их запросы, выспрашивать feedback по кандидатам, которые не прошли техническое собеседование, узнавать что с ними было не так, и наоборот - почему взяли вот того человека, что понравилось.
Да, на собеседованиях спрашивают теорию в том числе, надо ведь как-то оценивать знания тех кто приходит (я не HR, но в IT-отделах где работал сотни 3 собеседований провёл, и представляю какие бывают кандидаты, и сам составлял опросники и задачки для оценки уровня человека).
Ещё такой момент - HR может отсеять человека потому, что он прямо сейчас не владеет какой-то технологией, а IT-спец может посмотреть на общий уровень компетенции, на прошлые проекты и понять, что собеседуемый эту новую штуку расколет как орех ударом кувалды.
Вообще конечно направление верное. Но самым лучшим IT-HR будет тот, кто сам поработал в предметной области и знает её изнутри. Про ООП позабавило. Программисты это не преподы, вот эти все нюансы не обязательно постоянно держать в голове. Но при этом код будет написан "как надо". На этапе проектирования ПО - да, важно быть в курсе про всякие SOLID и design patterns, чтобы не понаписать херни.
Было бы интересно узнать как легализовать крипту полученную в качестве оплаты на зарубежную компанию. Сейчас это похоже вне закона.