Слишком категоричное противопоставление — это касается и заголовка, и текста. Общий темп много от чего зависит, от количества человеческих ресурсов и скорости выполнения конкретных работ (конкретными людьми) в том числе.
Универсальность советов зачастую прямо соответствует их банальности, а полезности — обратно. Лично мое мнение: проблема не уникальна конкретно для айти; на темп влияет больше всего не некая "инженерная зрелость" отдельных членов (не важно, сколь многочисленных), а навыки и возможности менеджмента и руководства. Если исправление "любых мелочей" является частым и тратящим заметное время явлением, вопрос больше не к инфраструктуре, скорее к компетенциям ответственных и процессам в целом (отсутствует должный контроль качества).
Должны быть роли, которые системно следят за тратой ресурсов (как временных, так и прочих) и вовремя задаются связанными с ними вопросами: насколько это большие и критичные траты, действительно ли это должно столько требовать, можно ли их снизить или исключить, как именно, чем придется пожертвовать, чего не хватает. Люди и ситуации бывают самыми разными, в некоторых случаях подобными вопросами задаются сами исполнители, но без постановки подобных вопросов (не важно, кем) и их последующего решения (порой проблемы именно в этой части) все прочие попытки повышения эффективности будут носить скорее временный характер.
Когда идея о некоей разумной оптимизации трат лежит в основании рабочих процессов, тогда и до всего остального со временем получается добраться. И до повышения компетенций (зная, каких, у кого, как именно), и до улучшений окружения (зачем, как, когда), и до ускорения выполнения типовых работ — при необходимости в том числе за счёт привлечения дополнительных ресурсов.
А не за уши ли притянута эта связь? Ожидал увидеть явное упоминание того, что авторы неких первоначальных интерфейсов вдохновлялись именно таким использованием сетки, а не каким-то другим. Не увидел.
Субъективно. Никто не заставляет оставаться новичком, и можно аргументировать, что условному новичку будет лучше выбрать инструмент с богатым функционалом (чтобы не приходилось изучать и пользоваться несколькими для разных задач), который при этом является распространенным (при возникновении проблем будет выше шанс получить нужную информацию).
Лично у меня в памяти отложились воспоминания о том, как отец на обозреватель ругался и вместо него предпочитал TotalCommander для выполнения даже самых простых операций. Простота использования и удобство в ряде простых случаев не всегда оказываются достаточными аргументами в пользу выбора инструмента.
В любом случае гораздо интереснее читать про подобное, а не пролистывать десятки статей про ИИ подряд.
Идея хорошая, проблемы связаны больше с конкретной реализацией этой идеи и истинными мотивирующими факторами, которые могут сильно отличаться от тех, что представляем себе мы. Ключевые слова: "подтверждающие" и "формально".
Негативненько. В тексте несколько раз сделаны оговорки про "мы" и "вместе с разработчиками", какого-то пафоса не заметил, человек просто рассказывает про то, в чем принимает участие.
Лично у меня до сих пор полноценного понимания разницы между продуктовыми и проектными менеджерами не сложилось (с первыми виделся только раз), но в целом впечатление об обоих сложилось хорошее. Как это себе всегда представлял я, первые определяют, что нужно делать, вторые определяют, что не нужно делать (или как минимум отложить). В паре они должны добиваться того, чтобы объем работ оказывался понятен и посилен команде.
Если в Вашем случае наблюдаются проблемы с кем-то из членов команды, то это стоит обсуждать в первую очередь с ними. Неформальные разговоры — вполне себе действенная терапия, которая может помочь обеим сторонам разглядеть друг в друге простых людей со своими проблемными моментами в работе, которые до разговора могут быть недостаточно хорошо понятными. Если команда чем-то не устраивает, всегда можно поставить целью ее сменить на другую. Всех благ!
...те, кто говорит «не идите в IT, там всё плохо», не дают ответа на главный вопрос. А где хорошо? Куда идти-то?
Надо выбирать призвание — направление, к которому человека тянут не только деньги. Никто другой, кроме самого человека, это направление определить не может.
Высшее образование обязательным не является, в том числе по причине того, что его наличие не является гарантией ни наличия знаний и навыков, ни успешного трудоустройства. При этом рассматривать отказ от его получения есть смысл только в том случае, если человек устремлён в направлении, смежном с конкретной специальностью, и способен самостоятельно обрести необходимые знания и навыки без помощи ВУЗа.
Формально осуществить переход возможно в любом возрасте, но надо быть честным с собой и окружающими: получение навыков требует большого количества времени, причем с возвратом способности к обучению снижаются. Вдобавок к этому отрасль предполагает не только разовое получение навыков, но и постоянное их развитие, а при необходимости и замену. Войти в отрасль мало, нужно быть готовым в ней удержаться, а реальная возможность это осуществить напрямую зависит от того, насколько отрасль интересна сама по себе.
Представьте себе ситуацию, при которой высокие уровни доходов исчезают. Готовы ли вы будете остаться, или начнёте задумываться над тем, куда бы ещё "войти"?
Как ни пытался считать, учитывая общее количество или доли по отдельным направлениям, даже в идеальном случае не сходится картина. За текущие рабочие места конкуренция большая, при этом идут заявления в духе: "компаниям не нужны молодые после курсов, поэтому их нужно ещё больше". Отсюда могу сделать только один вывод: речь идёт о запросе не на заполнение рабочих мест (с чем лично у меня ассоциируется слово дефицит), а на усиление демпинга.
В других источниках дают намеки: "в айти зарплаты выше, чем в остальных секторах, поэтому нужно... прийти к снижению зарплат в айти". Текущих занятых успокаивают не потому, что проблемы нет, а чтобы те более спокойно относились к усугублению этих самых проблем. Молодых, которых призывают во всем этом безобразии участвовать, воспринимают просто как инструмент достижения своих целей. Параллельно ещё и с других стран намереваются развивать приток в сектор, чтобы было совсем уж не скучно.
Эта типология — не про навешивание ярлыков. А токсики не нужны
Токсик — это зачастую "тот, кто нам не нравится". Опираясь на указанные для них критерии, можно заметить, что те пересекаются с прочими типами. Очень неточное, субъективное понятие.
Основное различие между живым и синтетическим, которое будет продолжать иметь место быть ещё какое-то время — это метаболизм. Все прочее, предложенное в голосовании, может быть применимо к обоим. То, что сейчас принято называть ИИ, представляет из себя симулякр человеческого собеседника и не обладает ни сознанием, ни разумом.
Рефлексы, сознание, инстинкты, мышление, разум, эмоции, интеллект. Понятий разных десятки, и при этом отсутствие в конкретном случае чего-либо одного не обязательно подразумевает отсутствие другого. Более того, конкретное понятие не обязательно должно существовать только в том виде, в котором оно существует в человеке. При этом даже в случае самого человека имеют место быть качественные различия между двумя отдельными представителями.
Основная проблема, какой она видится мне — это стремление не добиться появления новой формы привычного нам, а воссоздать это привычное в форме, которая изначально предполагает совсем иное. Машины не должны походить на человека, и разумными они станут с большей вероятностью тогда, когда именно это будет поставлено целью. Механизм работы подобного разума при этом тоже будет другим. Возможности испытывать эмоции или воспроизводиться — это тоже другие задачи, которые могут решаться в иное время.
Пока люди не перестанут подыгрывать и стремиться увидеть то, чего нет, ничего не изменится. ИИ как инструменты, созданные для выполнения набора конкретных задач, продолжат развиваться, но так и останутся инструментами. Причина тому довольно проста — бизнес самого человека воспринимает в качестве инструмента, от недостатков которого стремится избавиться через замену на ИИ. Обоим не обязательно обладать развитым разумом, чтобы приносить пользу. Наивно надеяться, что разум появится сам собой или по доброй воле корпораций.
Моя старшая дочь [...] сама пробьет себе дорогу в этом мире. Моя младшая дочь [...] не обладает талантами и способностями, позволяющими пробиться в этом мире.
В своем поколении я позабочусь о менее одаренных членах общества, чтобы у них были дети, а их одаренные дети позаботятся о моих детях.
Подобные заявления не видятся последовательными в контексте позиции, которая якобы строится на идеях сохранения генов и традиций. Количественный и качественный рост с большей вероятностью успеха будет обеспечен в том случае, если имеет место быть селекция, когда приоритет отдается более сильному и способному потомству: чтобы люди в последующих поколениях были столь же или более одаренными (что бы это ни значило), это должно быть применимо и к предшествующим им поколениям.
В целом идея о том, чтобы ожидать от детей, а особенно дочерей, самостоятельного строительства своей судьбы, спорная. Я допускаю, что банально формулировка не самая удачная, и в действительности все иначе, потому что с большей частью остального согласен, но конкретно это бросается в глаза.
Социáльная инженерия — в контексте информационной безопасности — психологическое манипулирование людьми с целью совершения определенных действий или разглашения конфиденциальной информации.
Часть описанного пересекается с действительностью, но высказывамое отношение к проблематике работы в сфере не вызывает ничего, кроме отвращения. Сплошь и рядом несерьезность и непрофессионализм, выдаваемые за эталон.
В итоге получилось так, что по половине слова отгадывается все остальное, а потом остается понять, каким образом должна была получиться недостающая часть. На конце самого первого завис.
Не совсем понятно, о чем статья. На выбранный стиль изложения можно было бы закрыть глаза, но я не увидел основного — предложенного решения названной проблемы. По сути проблема названа абстрактная, а в ней — возможные причины, с которыми и можно было бы согласиться, но не в предлагаемой формулировке. Например, точно НЕ в такой:
В функциональном стиле проще наговнокодить, но шизокодить там сложно.
На мой взгляд, все описанные в статье проблемы с кодом так или иначе можно объяснить одним — допущением их существования разработчиком, который этот код писал. Решаться, следовательно, они должны через создание препятствий, которые будут «мешать» разработчику идти на подобные допущения. Опускаю случаи, когда наличие упомянутых проблем может быть в определенной степени оправдано:
— недостатком квалификации, обусловленный отсутствием опыта, а не слабоумием
— недостатком ресурсов (время/деньги), потому что чистый код — это хорошо, но порой решение нужно уже вчера
В остальных же случаях:
— проблема «хардкода» и нарушений стиля решается через применение практики code review с соответствующими требованиями к тем, кто их проводит
— «тем больше точек отказа, тем больше ошибок» — через применение практики непрерывной интеграции; при этом важно не просто наличие тестов как таковых, а наиболее полное покрытие кода, которое позволило бы выявлять неочевидные ошибки
— переизбыток/недостаток абстракций, проблемы с архитектурой — зависят от опыта конкретного разработчика на конкретной должности; решения для общего случая, на мой взгляд, нет
Во всех случаях в целом, особенно в последнем, проблемы нередко могут совершаться из-за наличия уже существующих, появившихся из-за неверно принятых решений в прошлом. В итоге их количество растет подобно снежному кому, потому что сделать «не идеально» получается правильнее (в контексте ограниченных ресурсов), чем менять архитектуру и переписывать все с нуля.
Суть манифеста, думаю, я понял, просто вместо простого перечисления проблем хотелось бы слышать:
— с предложением решений называемой проблемы
— без лексики, пригодной для «курилки»
— с логическими рассуждениями, когда в конкретном стиле чаще встречаются ошибки по конкретным причинам, а не «просто потому что»
Посыпаю голову пеплом — предыдущий комментатор, судя по всему, прав. Я же просто счел треком №3 то, что привычно мне самому.
В любом случае, вот mp3 (128kbps) того трека, который ошибочно указал я: <тык>
Посчастливилось найти при помощи поисковика. Активных торрентов с раздачей TLMC, к сожалению, не нашел. Вот ссылка на данный конкретный трек (№3) на стороннем ресурсе: тык
Слишком категоричное противопоставление — это касается и заголовка, и текста. Общий темп много от чего зависит, от количества человеческих ресурсов и скорости выполнения конкретных работ (конкретными людьми) в том числе.
Универсальность советов зачастую прямо соответствует их банальности, а полезности — обратно. Лично мое мнение: проблема не уникальна конкретно для айти; на темп влияет больше всего не некая "инженерная зрелость" отдельных членов (не важно, сколь многочисленных), а навыки и возможности менеджмента и руководства. Если исправление "любых мелочей" является частым и тратящим заметное время явлением, вопрос больше не к инфраструктуре, скорее к компетенциям ответственных и процессам в целом (отсутствует должный контроль качества).
Должны быть роли, которые системно следят за тратой ресурсов (как временных, так и прочих) и вовремя задаются связанными с ними вопросами: насколько это большие и критичные траты, действительно ли это должно столько требовать, можно ли их снизить или исключить, как именно, чем придется пожертвовать, чего не хватает. Люди и ситуации бывают самыми разными, в некоторых случаях подобными вопросами задаются сами исполнители, но без постановки подобных вопросов (не важно, кем) и их последующего решения (порой проблемы именно в этой части) все прочие попытки повышения эффективности будут носить скорее временный характер.
Когда идея о некоей разумной оптимизации трат лежит в основании рабочих процессов, тогда и до всего остального со временем получается добраться. И до повышения компетенций (зная, каких, у кого, как именно), и до улучшений окружения (зачем, как, когда), и до ускорения выполнения типовых работ — при необходимости в том числе за счёт привлечения дополнительных ресурсов.
Листал с хорошими мыслями, пока не прочитал про предложенную в продуктовой части идею. Жуть полная.
А не за уши ли притянута эта связь? Ожидал увидеть явное упоминание того, что авторы неких первоначальных интерфейсов вдохновлялись именно таким использованием сетки, а не каким-то другим. Не увидел.
Субъективно. Никто не заставляет оставаться новичком, и можно аргументировать, что условному новичку будет лучше выбрать инструмент с богатым функционалом (чтобы не приходилось изучать и пользоваться несколькими для разных задач), который при этом является распространенным (при возникновении проблем будет выше шанс получить нужную информацию).
Лично у меня в памяти отложились воспоминания о том, как отец на обозреватель ругался и вместо него предпочитал TotalCommander для выполнения даже самых простых операций. Простота использования и удобство в ряде простых случаев не всегда оказываются достаточными аргументами в пользу выбора инструмента.
В любом случае гораздо интереснее читать про подобное, а не пролистывать десятки статей про ИИ подряд.
После прочтения заголовка первая мысль была про Snakes для Symbian.
Идея хорошая, проблемы связаны больше с конкретной реализацией этой идеи и истинными мотивирующими факторами, которые могут сильно отличаться от тех, что представляем себе мы. Ключевые слова: "подтверждающие" и "формально".
Негативненько. В тексте несколько раз сделаны оговорки про "мы" и "вместе с разработчиками", какого-то пафоса не заметил, человек просто рассказывает про то, в чем принимает участие.
Лично у меня до сих пор полноценного понимания разницы между продуктовыми и проектными менеджерами не сложилось (с первыми виделся только раз), но в целом впечатление об обоих сложилось хорошее. Как это себе всегда представлял я, первые определяют, что нужно делать, вторые определяют, что не нужно делать (или как минимум отложить). В паре они должны добиваться того, чтобы объем работ оказывался понятен и посилен команде.
Если в Вашем случае наблюдаются проблемы с кем-то из членов команды, то это стоит обсуждать в первую очередь с ними. Неформальные разговоры — вполне себе действенная терапия, которая может помочь обеим сторонам разглядеть друг в друге простых людей со своими проблемными моментами в работе, которые до разговора могут быть недостаточно хорошо понятными. Если команда чем-то не устраивает, всегда можно поставить целью ее сменить на другую. Всех благ!
Надо выбирать призвание — направление, к которому человека тянут не только деньги. Никто другой, кроме самого человека, это направление определить не может.
Высшее образование обязательным не является, в том числе по причине того, что его наличие не является гарантией ни наличия знаний и навыков, ни успешного трудоустройства. При этом рассматривать отказ от его получения есть смысл только в том случае, если человек устремлён в направлении, смежном с конкретной специальностью, и способен самостоятельно обрести необходимые знания и навыки без помощи ВУЗа.
Формально осуществить переход возможно в любом возрасте, но надо быть честным с собой и окружающими: получение навыков требует большого количества времени, причем с возвратом способности к обучению снижаются. Вдобавок к этому отрасль предполагает не только разовое получение навыков, но и постоянное их развитие, а при необходимости и замену. Войти в отрасль мало, нужно быть готовым в ней удержаться, а реальная возможность это осуществить напрямую зависит от того, насколько отрасль интересна сама по себе.
Представьте себе ситуацию, при которой высокие уровни доходов исчезают. Готовы ли вы будете остаться, или начнёте задумываться над тем, куда бы ещё "войти"?
Как ни пытался считать, учитывая общее количество или доли по отдельным направлениям, даже в идеальном случае не сходится картина. За текущие рабочие места конкуренция большая, при этом идут заявления в духе: "компаниям не нужны молодые после курсов, поэтому их нужно ещё больше". Отсюда могу сделать только один вывод: речь идёт о запросе не на заполнение рабочих мест (с чем лично у меня ассоциируется слово дефицит), а на усиление демпинга.
В других источниках дают намеки: "в айти зарплаты выше, чем в остальных секторах, поэтому нужно... прийти к снижению зарплат в айти". Текущих занятых успокаивают не потому, что проблемы нет, а чтобы те более спокойно относились к усугублению этих самых проблем. Молодых, которых призывают во всем этом безобразии участвовать, воспринимают просто как инструмент достижения своих целей. Параллельно ещё и с других стран намереваются развивать приток в сектор, чтобы было совсем уж не скучно.
Токсик — это зачастую "тот, кто нам не нравится". Опираясь на указанные для них критерии, можно заметить, что те пересекаются с прочими типами. Очень неточное, субъективное понятие.
На ум приходят Аскон и Топ Системы. Посмотрел оригинальную новость, упоминается "Отечественный софт", среди списка входящих компаний Аскон числится.
Основное различие между живым и синтетическим, которое будет продолжать иметь место быть ещё какое-то время — это метаболизм. Все прочее, предложенное в голосовании, может быть применимо к обоим. То, что сейчас принято называть ИИ, представляет из себя симулякр человеческого собеседника и не обладает ни сознанием, ни разумом.
Рефлексы, сознание, инстинкты, мышление, разум, эмоции, интеллект. Понятий разных десятки, и при этом отсутствие в конкретном случае чего-либо одного не обязательно подразумевает отсутствие другого. Более того, конкретное понятие не обязательно должно существовать только в том виде, в котором оно существует в человеке. При этом даже в случае самого человека имеют место быть качественные различия между двумя отдельными представителями.
Основная проблема, какой она видится мне — это стремление не добиться появления новой формы привычного нам, а воссоздать это привычное в форме, которая изначально предполагает совсем иное. Машины не должны походить на человека, и разумными они станут с большей вероятностью тогда, когда именно это будет поставлено целью. Механизм работы подобного разума при этом тоже будет другим. Возможности испытывать эмоции или воспроизводиться — это тоже другие задачи, которые могут решаться в иное время.
Пока люди не перестанут подыгрывать и стремиться увидеть то, чего нет, ничего не изменится. ИИ как инструменты, созданные для выполнения набора конкретных задач, продолжат развиваться, но так и останутся инструментами. Причина тому довольно проста — бизнес самого человека воспринимает в качестве инструмента, от недостатков которого стремится избавиться через замену на ИИ. Обоим не обязательно обладать развитым разумом, чтобы приносить пользу. Наивно надеяться, что разум появится сам собой или по доброй воле корпораций.
Подобные заявления не видятся последовательными в контексте позиции, которая якобы строится на идеях сохранения генов и традиций. Количественный и качественный рост с большей вероятностью успеха будет обеспечен в том случае, если имеет место быть селекция, когда приоритет отдается более сильному и способному потомству: чтобы люди в последующих поколениях были столь же или более одаренными (что бы это ни значило), это должно быть применимо и к предшествующим им поколениям.
В целом идея о том, чтобы ожидать от детей, а особенно дочерей, самостоятельного строительства своей судьбы, спорная. Я допускаю, что банально формулировка не самая удачная, и в действительности все иначе, потому что с большей частью остального согласен, но конкретно это бросается в глаза.
Часть описанного пересекается с действительностью, но высказывамое отношение к проблематике работы в сфере не вызывает ничего, кроме отвращения. Сплошь и рядом несерьезность и непрофессионализм, выдаваемые за эталон.
Поболтать весело, конечно, но есть смысл в том, чтобы чата не было.
Не совсем понятно, о чем статья. На выбранный стиль изложения можно было бы закрыть глаза, но я не увидел основного — предложенного решения названной проблемы. По сути проблема названа абстрактная, а в ней — возможные причины, с которыми и можно было бы согласиться, но не в предлагаемой формулировке. Например, точно НЕ в такой:
На мой взгляд, все описанные в статье проблемы с кодом так или иначе можно объяснить одним — допущением их существования разработчиком, который этот код писал. Решаться, следовательно, они должны через создание препятствий, которые будут «мешать» разработчику идти на подобные допущения. Опускаю случаи, когда наличие упомянутых проблем может быть в определенной степени оправдано:
— недостатком квалификации, обусловленный отсутствием опыта, а не слабоумием
— недостатком ресурсов (время/деньги), потому что чистый код — это хорошо, но порой решение нужно уже вчера
В остальных же случаях:
— проблема «хардкода» и нарушений стиля решается через применение практики code review с соответствующими требованиями к тем, кто их проводит
— «тем больше точек отказа, тем больше ошибок» — через применение практики непрерывной интеграции; при этом важно не просто наличие тестов как таковых, а наиболее полное покрытие кода, которое позволило бы выявлять неочевидные ошибки
— переизбыток/недостаток абстракций, проблемы с архитектурой — зависят от опыта конкретного разработчика на конкретной должности; решения для общего случая, на мой взгляд, нет
Во всех случаях в целом, особенно в последнем, проблемы нередко могут совершаться из-за наличия уже существующих, появившихся из-за неверно принятых решений в прошлом. В итоге их количество растет подобно снежному кому, потому что сделать «не идеально» получается правильнее (в контексте ограниченных ресурсов), чем менять архитектуру и переписывать все с нуля.
Суть манифеста, думаю, я понял, просто вместо простого перечисления проблем хотелось бы слышать:
— с предложением решений называемой проблемы
— без лексики, пригодной для «курилки»
— с логическими рассуждениями, когда в конкретном стиле чаще встречаются ошибки по конкретным причинам, а не «просто потому что»
В любом случае, вот mp3 (128kbps) того трека, который ошибочно указал я: <тык>
тык