Пытаюсь понять, к какой категории в мире этой статьи себя отнести. Мне отлично заходят 5 часовые въедливые подкасты/лекции на одну тему, на одном уровне с короткими. Судя по просмотрам и знакомым я не один – многим людям нравится детальное, вдумчивое погружение в тему и, главное, теперь они могут получить его не доходя до университета.
А немного покопавшись в себе, я понимаю, что все этим «СДВГ» не следствие, а причина. Повышенная тревожность, которая заставляет в один день залипать в потоке информации и, напротив, спокойствие, когда смотришь подборку несколько минут и идешь заниматься своими делами.
Я благодарен аспирантуре за то, что четыре года дали возможность попробовать чуть больше, чем просто заказную разработку, создали несколько завышенные требования к себе.
Как оказалось то, что я считал утилитарными знаниями для решения научных задач отлично сконвертировались в работу программистом на первом же собеседовании.
Для этого в опенсорсе должна быть модерация и голосование, какой пакет принять за основной.
И тут же возникает проблема на уровне, где система для опенсорса с голосованием за форки порождает альтернативную площадку с «легковесной» подачей и быстрой доставкой фич без голосования. И вот у нас и тут становится минимум 2 стандарта «правильной» разработки опенсорса.
Еще есть чувство, что восприятие и коррекция перспективы должна зависить от размеров изображения.
Находясь на выставке фотографий, начиная с какого-то размера фото мозг выполняет ту же коррекцию. На иллюстрациях к статье мы смотрим на изображение с малым угловым размером и чем меньше изображение, тем больше требуется «компрессировать» перспективу.
Для организации таких вещей инструмент должен быть наиболее скучный. Если ловлю себя на полпути расставляющего карточки в ноушене, рисуя пятью цветами на флипчарте – обычно это не про решение проблемы, а про прокрастинацию.
Ранее оценивал это негативно – делаешь какую-то безделушку на приливе энергии вечером, а затем не можешь поддержать очередной майдмап/доску по ходу проекта в актуальном состоянии. Потом изменил мнение – иногда фокусировка на такой бесполезной работе по настройке очередного таск-менеджера дает новые идеи, хотя бы потому что каждый инструмент навязывает определенную логику мышления.
Но в повседневности крепче системных «Заметок» ничего не приживается.
В разработке большинство задач это не процесс исполнения инструкций, а минипроект по исследованию проблемы и последующая реализация плана ее решения.
Глубина исследования при этом иногда не может быть конечной, для того, что бы уместить ее в памяти разработчика. То есть разработка начинается с определенными допущениями в виде принимаемого риска.
Там где требуется снизить риски – появляется конвейерная разработка на фреймворке с помощью сертифицированных разработчиков, а задачи ставятся с пониманием ограничений этого фреймворка.
Но если это так низкорисково и предсказуемо, то это же выгодно запрограммировать? Так мы поднимаемся на уровень абстракции выше и получаем новые риски.
То есть грубо говоря, если в проекте не описывают только CRUDы, то разработка оценивает не «разгрузку грузовиков с песком», как в комментариях выше, а дает оценку проекту и реализации механизма, который мог бы разгружать разные грузовики в разных условиях при наступлении всяких событий, причем наборы этих «разных и всяких» меняются и их обычно надо при оценке прикинуть самостоятельно и задать наводящие вопросы.
Если возникает «горение», то проблему хочется не глушить, а все же первопричину решать – передоговариваться, искать другие подходы. Но если ты угорел, то здравые решения в голову не идут.
Помогают короткие отгулы 1-2 дня – взглянуть со стороны и разомкнуть клеммы так сказать, но в тоже время не отрываться на полноценный отпуск, потому как отпуск в состоянии перегорания или радикальная смена работы – постановка проблемы на паузу.
Про Lightroom Classic и Lightroom CC я и писал, что не тудя, ни сюда застряло в вопросах сортировки фотографий – CC решили урезать слишком сильно, а Classic не развивается.
За остальные рекомендации спасибо, надо рассмотреть альтернативы.
Пользовался лет десять назад Adobe Lightroom, который постепенно развивался, улучшался – в общем я был доволен. Затем забросил зеркалку, появился смартфон, который удобнее (как мне казалось) и я подсел на мобильную версию Lightroom, благо практически все настройки там были, а вот интерфейс сортировки и отбора – практически отсутствовал, если говорить о сериях больше 50 фотографий – палец сломаешь.
Недавно вернулся к увлечению фотографией, установил классическую и «мобильную» версию на компьютер и опечалился – на развитие классической так и забили лет 10 назад, обновляют профили, сделали синхронизацию с облаком и делают упор на том, что пора сваливать на «мобильную», а в ней за 5 лет так и не появилось нужных функций. В итоге нормальное приложение развалили предоставив выбор, либо модное-удобное облако, либо по-старинке.
Я не знаю как это работает в таких компаниях, но они просто разваливают бренд и если завтра появится свежая развитая на десктопе альтернатива, то вместо выбора я лучше переключусь на нее.
Очень структурировано, но в какой-то конкретной области разработки веб и мобильных-продуктов с плоской иерархией. Так-то существуют архитекторы, системные аналитики, разработчики/проектировщики БД, целый спектр продуктовых специалистов.
На протяжении десяти лет даже от опытных программистов про вот эту копипасту со SO, но никогда не доводилось делать самому. SO хорош как сборник релевантных терминов, когда не знаешь как подступится к документации или даже гуглу, а за тебя сформулировали вопрос. Узнаешь имя класса/паттерна/сущности и вперед искать дальше, но вот прямо кусками код брать, это где так можно?
Всегда было интересно, что это за проекты такие, в которых технологии важнее предметной области? Не встречал такого, что бы знание фреймворка давало преимуществ больше, чем знание местных костылей и умение гибко, планомерно делать код лучше.
Если брать не абстрактные холивары, а конкретную работу, то там всегда есть какой-то стек, к которому нужно подготовится. Если разработчик настолько ригидный, что вечно застревает в каком-то стеке (далеко не классическом), инфантильно ненавидит Angular2, Ember, React, etc словно это готовые коммерческие проекты, в которых кто-то кому-то должен, то это уже о чем-то говорит? Никто же не просит контрибьютить ежедневно, но поддерживать актуальное состояние знаний технологий нужно, а главное иметь фундаментальные знания, позволяющие включится в поток после перерыва без нытья.
А нытье будет, просто потому что страшно, что, освоив один инструмент нельзя делать одно и тоже всю жизнь — но это же никак не отличается от остальных профессий. Если хочется больше стабильности, надо подниматься на уровень выше.
Точно так же часы с кукушкой отсчитывают время и кукуют необходимое количество раз — в силу «внутренних причин», своего устройства, а не желания кого-то снаружи.
Но как же, взводил их вполне конкретный человек, который хотел, чтобы с определенной периодичностью кукушка куковала.
Аналогично и с машиной, которая едет. У нее может быть не только мотор и топливо, но и блок автоматической подачи, этот блок может даже сам принимать решение, очень запутанное, основанное на обучении. В один прекрасный день вы выходите, а она угадывает, что нужно подъехать именно сейчас. Но все же, когда-то ее запустили и это все тот же механизм, который взвели на заводе чьей-то конкретной рукой. Возможно даже механической, но и она в свою очередь тоже была кем-то создана.
Означает ли это, что «одушевленность» определяется простой невозможностью отследить первопричину движения?
Конечно они могут себе позволить, но выглядит несколько странно. «У нас такой крупный проект, что мы все настроили под себя, пользуйтесь» — но ведь множество других генераторов для Yeoman и прочих подходов их тоже не удовлетворили? Значит следующая компания скорее всего тоже потеряет время пробуя их платформу и начнет делать что-то свое?
Хорошо заглянуть и посмотреть под капот крупного проекта, но лучше не делать из этого еще одну новую «платформу» с новыми сущностями вроде архетипов.
Не может быть так, чтобы масса суперуниверсальных разработчиков не уменьшалась в таких условиях. Уменьшается масса, снова становятся востребованы разработчики с опытом решения реальных задач, а не мультистековые ребята, тратящие на поддержание своих знаний 90% рабочего времени.
В общем не понимаю, как эта ситуация хуже стала? Раньше разработчик разбирался в JS + jQuery и поверх писал свои велосипеды, а сегодня использует готовое, разбираясь в вещах уровнем выше, но не брезгуя смотреть открытый код? Получается проработав N лет, точно так же терял это время на специфичную для клиента систему, а сейчас только отрывается на несколько версий фреймворка, если совсем не смотрит по сторонам.
Наверное, это так, если хочешь соответствовать некоторому абстрактному «рынку» и пробовать по технологии за вечер — сейчас это уже невозможно. Если же требуется реальное приложение и ты работаешь над ним долго, то стек сам органично выстраивается.
Приложению на три таблицы не требуется поддержка? Почему бы не использовать чистый JS.
Если же приложение больше, то никакого такого ада там и нет. По мере необходимости из широкого ассортимента выбираются инструменты и им находится применение. И TypeScript будет в радость, и обилие npm пакетов и сборщики. Есть возможность собрать проект без webpack — замечательно, хотите использовать React с jQuery? Без проблем.
Но многим хочется готовых мануалов «Как стать модным фронтом 2016+», много лет назад они брали и писали же на чистом JS такой-то UI и все хорошо было то, а теперь надо же придумали! Хочется сразу использовать всю мощь, но что бы не разбираться. Но тогда и мощи не было бы, разрабатывали бы мощный фреймворк all-in-one, тратили бы годы на стандартизацию, имели бы мы приложение уровня 2005 года, зато было бы спокойно и понятно все.
Пытаюсь понять, к какой категории в мире этой статьи себя отнести. Мне отлично заходят 5 часовые въедливые подкасты/лекции на одну тему, на одном уровне с короткими. Судя по просмотрам и знакомым я не один – многим людям нравится детальное, вдумчивое погружение в тему и, главное, теперь они могут получить его не доходя до университета.
А немного покопавшись в себе, я понимаю, что все этим «СДВГ» не следствие, а причина. Повышенная тревожность, которая заставляет в один день залипать в потоке информации и, напротив, спокойствие, когда смотришь подборку несколько минут и идешь заниматься своими делами.
Я благодарен аспирантуре за то, что четыре года дали возможность попробовать чуть больше, чем просто заказную разработку, создали несколько завышенные требования к себе.
Как оказалось то, что я считал утилитарными знаниями для решения научных задач отлично сконвертировались в работу программистом на первом же собеседовании.
И тут же возникает проблема на уровне, где система для опенсорса с голосованием за форки порождает альтернативную площадку с «легковесной» подачей и быстрой доставкой фич без голосования. И вот у нас и тут становится минимум 2 стандарта «правильной» разработки опенсорса.
Еще есть чувство, что восприятие и коррекция перспективы должна зависить от размеров изображения.
Находясь на выставке фотографий, начиная с какого-то размера фото мозг выполняет ту же коррекцию. На иллюстрациях к статье мы смотрим на изображение с малым угловым размером и чем меньше изображение, тем больше требуется «компрессировать» перспективу.
Ранее оценивал это негативно – делаешь какую-то безделушку на приливе энергии вечером, а затем не можешь поддержать очередной майдмап/доску по ходу проекта в актуальном состоянии. Потом изменил мнение – иногда фокусировка на такой бесполезной работе по настройке очередного таск-менеджера дает новые идеи, хотя бы потому что каждый инструмент навязывает определенную логику мышления.
Но в повседневности крепче системных «Заметок» ничего не приживается.
Глубина исследования при этом иногда не может быть конечной, для того, что бы уместить ее в памяти разработчика. То есть разработка начинается с определенными допущениями в виде принимаемого риска.
Там где требуется снизить риски – появляется конвейерная разработка на фреймворке с помощью сертифицированных разработчиков, а задачи ставятся с пониманием ограничений этого фреймворка.
Но если это так низкорисково и предсказуемо, то это же выгодно запрограммировать? Так мы поднимаемся на уровень абстракции выше и получаем новые риски.
То есть грубо говоря, если в проекте не описывают только CRUDы, то разработка оценивает не «разгрузку грузовиков с песком», как в комментариях выше, а дает оценку проекту и реализации механизма, который мог бы разгружать разные грузовики в разных условиях при наступлении всяких событий, причем наборы этих «разных и всяких» меняются и их обычно надо при оценке прикинуть самостоятельно и задать наводящие вопросы.
Помогают короткие отгулы 1-2 дня – взглянуть со стороны и разомкнуть клеммы так сказать, но в тоже время не отрываться на полноценный отпуск, потому как отпуск в состоянии перегорания или радикальная смена работы – постановка проблемы на паузу.
За остальные рекомендации спасибо, надо рассмотреть альтернативы.
Недавно вернулся к увлечению фотографией, установил классическую и «мобильную» версию на компьютер и опечалился – на развитие классической так и забили лет 10 назад, обновляют профили, сделали синхронизацию с облаком и делают упор на том, что пора сваливать на «мобильную», а в ней за 5 лет так и не появилось нужных функций. В итоге нормальное приложение развалили предоставив выбор, либо модное-удобное облако, либо по-старинке.
Я не знаю как это работает в таких компаниях, но они просто разваливают бренд и если завтра появится свежая развитая на десктопе альтернатива, то вместо выбора я лучше переключусь на нее.
Иногда гибкость разработчика является дополнительной ценностью, которая продается или обменивается на взаимную лояльность.
Если брать не абстрактные холивары, а конкретную работу, то там всегда есть какой-то стек, к которому нужно подготовится. Если разработчик настолько ригидный, что вечно застревает в каком-то стеке (далеко не классическом), инфантильно ненавидит Angular2, Ember, React, etc словно это готовые коммерческие проекты, в которых кто-то кому-то должен, то это уже о чем-то говорит? Никто же не просит контрибьютить ежедневно, но поддерживать актуальное состояние знаний технологий нужно, а главное иметь фундаментальные знания, позволяющие включится в поток после перерыва без нытья.
А нытье будет, просто потому что страшно, что, освоив один инструмент нельзя делать одно и тоже всю жизнь — но это же никак не отличается от остальных профессий. Если хочется больше стабильности, надо подниматься на уровень выше.
Но как же, взводил их вполне конкретный человек, который хотел, чтобы с определенной периодичностью кукушка куковала.
Аналогично и с машиной, которая едет. У нее может быть не только мотор и топливо, но и блок автоматической подачи, этот блок может даже сам принимать решение, очень запутанное, основанное на обучении. В один прекрасный день вы выходите, а она угадывает, что нужно подъехать именно сейчас. Но все же, когда-то ее запустили и это все тот же механизм, который взвели на заводе чьей-то конкретной рукой. Возможно даже механической, но и она в свою очередь тоже была кем-то создана.
Означает ли это, что «одушевленность» определяется простой невозможностью отследить первопричину движения?
Хорошо заглянуть и посмотреть под капот крупного проекта, но лучше не делать из этого еще одну новую «платформу» с новыми сущностями вроде архетипов.
В общем не понимаю, как эта ситуация хуже стала? Раньше разработчик разбирался в JS + jQuery и поверх писал свои велосипеды, а сегодня использует готовое, разбираясь в вещах уровнем выше, но не брезгуя смотреть открытый код? Получается проработав N лет, точно так же терял это время на специфичную для клиента систему, а сейчас только отрывается на несколько версий фреймворка, если совсем не смотрит по сторонам.
Приложению на три таблицы не требуется поддержка? Почему бы не использовать чистый JS.
Если же приложение больше, то никакого такого ада там и нет. По мере необходимости из широкого ассортимента выбираются инструменты и им находится применение. И TypeScript будет в радость, и обилие npm пакетов и сборщики. Есть возможность собрать проект без webpack — замечательно, хотите использовать React с jQuery? Без проблем.
Но многим хочется готовых мануалов «Как стать модным фронтом 2016+», много лет назад они брали и писали же на чистом JS такой-то UI и все хорошо было то, а теперь надо же придумали! Хочется сразу использовать всю мощь, но что бы не разбираться. Но тогда и мощи не было бы, разрабатывали бы мощный фреймворк all-in-one, тратили бы годы на стандартизацию, имели бы мы приложение уровня 2005 года, зато было бы спокойно и понятно все.