Комментарии 115
Не стоит приступать к реализации того, что не придумано до конца.
Сначала сделай как изначально придумал.
В проекте должна быть цифра N. Любая задача, предполагающая больше времени, чем N, должна быть разбита на подзадачи.
Собеседование позволяет просто проверить, что заявленное в резюме верно. Больше, чем из резюме, не узнаете.
Краткие ежедневные митинги по делу и профессионально - хорошее начало дня.
Не стоит приступать к реализации того, что не придумано до конца.
в таком случае можно никогда не начать делать задачу, а бесконечно планировать, а конкурент уже выкатит mvp без половины функций и отожмет всех потенциальных клиентов
конечно это все обсуждаемо и не всегда применимо, но само по себе правило живьем я увидел только на нынешней работе и то только потому что закрытие задачи зависит от согласованного ТЗ и даже если вообще ничего не делаешь — нельзя начинать раньше — тупо не оплатят (или не согласуют или кардинально поменяют задачу)
в других компаниях, я бывало начинал делать задачу заранее чтобы к моменту когда согласуют — было понимание как оно будет работать уже по факту
Не стоит приступать к реализации того, что не придумано до конца.
Задача или подзадача это кратковременная сущность. Вы же говорите о проекте в целом, что его нельзя сделать потому что невозможно продумать до конца. А вот начинать задачи просто потому что надо и ничего не планируя - такая себе затея.
Иногда чтобы стало возможно продумать надо начинать делать. Если невозможно продумать, не возможно понять, это недостаток информации. Когда начинаешь делать эта информация появляется.
Мы спорим о терминах
Соглашусь, вроде как, с большинством: да, общий план должен быть – это, как мне кажется, очевидно, но планировать и планировать, постоянно спотыкаясь о что-то, потому что в набросках так или иначе что-то с чем-то скорее всего не будет стыковаться.. Лучше всё же с чего-то, да начать и уже затем потихоньку, конечно же не дотягивая до дедлайнов работать в "ищи ошибки"
С rnd не работает вообще. В большинстве случаев сначало пишется потом анализируется перепродумывается и переписывается и так по кругу.
Можно быть скромнее и браться за менее амбициозные задачи :) Я не настаиваю на абсолюте, в бизнесе всегда приходится балансировать. Но вот так по-человечески, как творческой единице, лучше сначала придумать. Можно упростить немного. Не начинать задач с открытым финалом.
А как же agile? Там же сама идеология не предполагает полного понимания.
Придумал чуть-чуть. Сделал чуть-чуть. Посмотрел, что нужно еще и тд по кругу
Не стоит приступать к реализации того, что не придумано до конца.
С учётом того, что «программа — это максимально детализированное ТЗ», программирование неправильно чуть более, чем целиком!!! :-)
N, я так понимаю, вы предлагаете разбивать на |,\ и |?
Я не предлагаю делить N. Вы из Питера чтоль?
Сначала не понял, а потом кааак понял... :)
Можете, пожалуйста, объяснить для тех, кто в танке?
Собеседование позволяет просто проверить, что заявленное в резюме верно. Больше, чем из резюме, не узнаете.
Вроде врать в резюме не считается пороком, оно нужно больше для пробития HR слоя.
Собеседование позволяет просто проверить, что заявленное в резюме верно. Больше, чем из резюме, не узнаете.
Вот эту мысль, честно говоря, не понял совсем. Следует ли из этого, что собеседование как этап избыточно, если есть другой (доверенный) источник, подтверждающий достоверность резюме?
Я лично кучу раз узнавал на собеседовании гораздо больше, чем заявлено в резюме
Если опыт работы соответствует резюме, то скорее всего никаких сюрпризов не будет. В среднем, на прежнем месте работы, у человека был такой же наниматель, как и вы. Это больше про техническую часть, конечно. Специалист по персоналу может сказать как человек поведет себя в коллективе, конфликтен ли, есть лидерские качества и все такое. Но это совсем другое образование и другая специальность, далекая от технарей. И я таких вообще пока не особо видел =)
Ну "не узнаете нового" и "не будет сюрпризов" - это все-таки немного разные утверждения, не находите? Резюме может быть банально недостаточно детальным, человек не указал там например, что работает с Х, а нам это может быть важно и мы спросим (и окажется он умеет).
Я исхожу из нормального хода событий, при котором на резюме без важных Х вы не отвечаете.
Например что? То что человек может в лайфкодин или зазубрил 10ок ответов на базовые вопросы?
Все фейлы на собесах это скорей неумении их проходить, а не реальные знания
Вы не правы, сейчас все курсы "программистов" готовят именно таких "специалистов" натаскивая их именно на прохождение собесов и вранье, а не на глубокие знания, ну и опыт таким вот "программистам" никто не заложит. И 25 лет работы в ит, это типа аргумент? Можно все это время цвет у кнопак менять...
Вы не правы, сейчас все курсы "программистов" готовят именно таких "специалистов" натаскивая их именно на прохождение собесов и вранье
Это же так не работает :) Можно или уметь программировать, или не уметь. Зазубрить наизусть способы решения задачек так, чтобы уметь их применять там, где спрашивают — это надо быть тоже гением, только фотографической памяти.
И 25 лет работы в ит, это типа аргумент? Можно все это время цвет у кнопак менять...
Типа аргумент. Не зря же сначала спрашивают про стаж, а уже потом погружаются в подробности.
Всмысле не работает? Вы на собесе чего проверяете? Способность программировать чтоли? Интересно как?) Самое приближенное к реальности хто тестовые зпдания но они сейчас не в почете. Ну и основы можно и вызубрить (паттерны, принципы, типы данных, солид, другой мусор что там сейчас популярно спрашивать?) Есть куча сайтов посвещенных именно на натаскивание решения типовых задач и в реале такой разраб с нуля ничего путного не сделает т.к. опыта у него нет. Это как со строителем - умение держать молоток в руке еще делает тебя строителем. С другой стороны интроверты которые впринципе не любят обшаться и темболее доказывать кому-то свои компетенции, вобшем в людях надо разбираться и находить подходы, чтобы среди мусорных разработчиков найти достойных, если это вообще нужно компании конечно...
Вы на собесе чего проверяете? Способность программировать чтоли?
Если на должности джуна — да, именно способность программировать. Потому что всё остальное как раз легко освоить и по ходу дела. Если на должности миддла, то в зависимости от "послужного списка". Если и так можно посмотреть, в каких проектах чувак участвовал и что там делал, фаззбазз у него можно не спрашивать, но если это только на словах, то да, прошу и попрограммировать малёхо.
Самое приближенное к реальности хто тестовые зпдания но они сейчас не в почете.
Я, например, как раз не стесняюсь, даю тестовые задания, небольшие, которые опытный решит минут за пятнадцать, джун — в зависимости от умения гуглить и соображать.
С другой стороны интроверты которые впринципе не любят обшаться и темболее доказывать кому-то свои компетенции
Бывают и такие, но честно скажу, стоимость ошибки "не взять толкового интраверта", она многократно ниже стоимости ошибки "взять бестолкового кого-нибудь". И если я пропущу бриллиант только потому, что он стесняется донести свои профессиональные навыки, ну, переживу как-нибудь. Это лучше, чем если я понесу убытки на проекте потому, что не проверил навыки и взял балбеса.
Если на должности джуна — да, именно способность программировать. Потому что всё остальное как раз легко освоить и по ходу дела. Если на должности миддла, то
Согласен, и даже более того и на мидла и даже и на сеньора, есль появились хоть малейшие подозрения. Потому что приходят именно такие - натасканные на прохождение собеседование и сливаются при решение простейшей задачи. Именно простейшей, никаких заданий на день и на пару часов. Только на 15 минут.
Краткие ежедневные митинги по делу и профессионально - хорошее начало дня.
Кому как. Мне больше нравится раз в неделю, в понедельник. Обсудили, что было на прошлой неделе, что сделано, что нет, какие проблемы и т.д., обсудили планы, первоочередные задачи, что-то ещё. И хватит.
Может, у меня в какой-то день вообще нет вдохновения доделать какую-то штуку, и я займусь чем-то вроде изучения накопившихся инструкций, новых приказов по предприятию, новых уязвимостей, может наконец дочитаю эту долбаную инструкцию по пожарной безопасности... А в другой день переключусь на рабочие задачи. Считаю, специалист должен иметь определённый диапазон времени, которым он может сам распоряжаться, когда что ему делать, главное - вот задача, вот сроки - и не надо каждый день спрашивать "нучотам?".
И только так и будет покрываться техдолг. Потому что без запаса времени никто не даст проводить рефакторинг, писать метрики, документацию и тесты и вот это все. Бизнесу это не нужно. Им фичи нужны и еще вчера.
У инженеров всегда должно быть свободное время делать то что они считают важным. А не бизнес. Иначе будет беда в итоге. Слишком разное виденье проектов без понимания зачем некоторые вещи надо делать у людей без технических знаний.
По моему опыты где то 1/3 времени должны быть свободными у людей без навязывания задач.
А то сначала ставят по 5 новых фичей в неделю в задачи. А потом удивляются почему от кода кровь из глаз идет.
Кому как. Мне больше нравится раз в неделю, в понедельник
Это если ты один на проекте и пилишь крупные задачи.
Если в команде несколько человек, и задачи разбиты на 1-3 дневные, то джун может застрять на какой-то мелочи и узнаешь ты об этом, только через неделю. Митинги нужны каждый день, но ровно в формате (done/in progress/obstacles) и проходить за 5-10 минут. Плохо когда митинги скатываются в обсуждение технических деталей и вся команда вынуждена слушать.
Не стоит приступать к реализации того, что не придумано до конца.
Практически все проекты, которые я делал в своей жизни, я начинал не продумав их до конца. Достаточно понять, что это принципиально реализуемо.
А в чем проблема продумать до конца?
Проблема во времени. Как тут уже справедливо заметили - если всё продумывать до конца, то реализации можно и не дождаться.
Все сделанное, сначала придумано. Это неизбежный процесс. Ни секунды не потеряете, если сначала придумаете.
Придумать айфон "до конца" -- это придумать первый айфон или четырнадцатый?
Или можно ли приступать к разработке экрана для айфона, пока ещё не придуманы все приложения полностью?
Когда дело касается физических объектов, то их то уж совершенно точно невозможно запустить в производство не спроектировав до конца. Нужно подробное описание и процесса и результата.
Сразу видно человека не работавшего в производстве.
Простой пример можно посмотреть сколько раз спайсХ переделывала двигатели прежде чем запустить в серийное производство.
Скажу больше есть прототипы в любой крупной компании которые никогда в серию не запускались. А так и остались в 1-3 экземплярах
Вот по поводу кратких митингов, не соглашусь. Они наоборот отвлекают от задумок и мыслей и способствуют замедлению процесса ведущему к положительному результату, т.к. превращаются зачастую не в краткие встречи, а длинные и незаконченные.
В колонке справа что-то с теми же цифрами всю прошлую (или позапрошлую?) неделю висело. Но туда не заглядывал, утверждать, что это та же статья - не берусь.
По уроку за год, продуктивно
Ожидал в конце что-нибудь вроде
Перестаньте читать статьи с банальными советами и идите писать код
...
12. Люди на самом деле не хотят инноваций
Это ещё Джордано Бруно, Николай Коперник и другие учёные доказали, когда выясняли что-то новое, но заскорузлое "научное сообщество" или нравы/подходы тех времён никак не хотели мириться с приходом чего-либо непривычного в их уклад жизни.
16. Программистам следует регулярно писать
Ха! Полностью поддерживаю! Это давно известно, "кто как мыслит, тот так и излагает". А про тех, кто "ниасилел" грамотную письменную речь, есть давным-давно диагноз "дисграфия".
Старое определение
Дисграфия – это специфическое расстройство письменной речи, проявляющееся в стойких ошибках. Развивается по причине несформированности высших отделов ЦНС. Заболевание не позволяет детям овладеть грамматическими особенностями языка.
То есть, недоразвитость неких областей мозга.
Много букв о причинах, современный подход
Нарушение письма может быть обусловлено задержкой в формировании определённых функциональных систем, важных для освоения письменной речи. Такая задержка возникает в результате воздействия неблагоприятных факторов в разные периоды развития ребёнка.
К неблагоприятным факторам раннего периода можно отнести:
отягощённая беременность — хронические заболевания матери, гестоз, анемия, многоплодная беременность;
рождение ребёнка на сроке беременности до 35 недель;
перинатальная патология центральной нервной системы (ЦНС);
церебральная гипоксия (ишемия) — острое повреждение головного мозга в результате его недостаточного кровоснабжения во время беременности, родов или в течение первого месяца жизни;
родовая травма ЦНС;
инфекции ЦНС (токсоплазмоз, герпес, цитомегаловирус, краснуха);
системные метаболические нарушения (билирубиновая энцефалопатия, гипогликемия, гипокальциемия, гипо- и гипермагниемия, гипо- и гипернатриемия).
Причины, которые могут привести к дисграфии в более старшем возрасте (после 2 лет):
черепно-мозговые травмы;
нейроинфекции;
патологии внутренних органов (пиелонефрит, гастрит, пневмония, ревматизм);
нарушения сердечно-сосудистой системы;
онкология;
выраженная психологическая травма, обусловленная сложной семейной обстановкой, низким социальным статусом, конфликтами со сверстниками, одиночеством.
Эти патологические состояния приводят к астении нервной системы и могут осложнять освоение письменной речи.
Часто встречается наследственная предрасположенность к дисграфии. Кроме того сложности с письмом могут возникнуть у ребёнка, пишущего левой рукой или переученного с левой руки на правую. Нередко дисграфией страдают дети, для которых язык, на котором они учатся писать, не является родным.
Вероятность дисграфии велика при общем недоразвитии речи. Расстройство может провоцировать логоневроз (заикание и запинания в речи) и сниженный темп созревания психических функций (например, на фоне хронических болезней или социальной дезадаптации).
Сейчас дисграфия, по мнению описаний на куче сайтов медклиник, успешно лечится. Но некоторые взрослые, до сих пор, пишут безграмотно. Лично по моему скромному опыту, я не встречал классных программистов, которые органически не умели бы писать грамотно. Могут совершать ошибки при письме "на бегу, второпях", но, когда стараются, пишут все грамотно.
Но в этом пункте и про продумывание, когда описываешь словами, а не только стрелочками и/или BPMN. И вот тут тоже полностью согласен, помогает сильно.
У меня идет особенность, что я не умею читать вслух. Как это проявляется.
1) Я отлично читаю про себя.
2) Я более менее разговариваю (в детстве сильно заикался, однако два года прозанимался с логопедом и стало более менее).
Однако, когда я начинаю читать вслух, то все поле зрения сужается до 2-3 букв и фактически не могу читать, так как не вижу все слово. Занятия с логопедом этот баг пофиксить не смогли.
Как итог, с возрастом научился, что читаю несколько слов про себя, потом их произношу уже без чтения. И так в режиме итератора, пока все не прочитаю.
Это сказывается на граммотности моего письма, что приходится несколько раз перепроверять все, чтобы оно вышло более менее адекватным. Являюсь помидором, все окей.
В детстве из-за этого очень не любил уроки литературы и русского языка, но вывез их старанием на четверки.
Лично по моему скромному опыту, я не встречал классных программистов, которые органически не умели бы писать грамотно
Звучит как зависимость глобального потепления от числа пиратов. Более простое объяснение — хорошие программисты читают (или как минимум читали) много написанных хорошим языком книг/статей, а это уже транслируется в хорошую письменную речь (плюс привычка структурировать информацию, а не тяп-ляп и в продакшен).
Я это прям хорошо ощущаю — в школе залпом употреблял содержимое школьной библиотеки, писал нормально просто на автомате. Сейчас большая часть контента — либо на нерусском, либо на разговорном русском, в итоге пунктуация давно стала авторской, а спряжения регулярно сношал её рука. Приходится перечитывать всё по 10 раз, и то что-нибудь да просочится.
Любой проект должен стартовать с MVP. Основной функционал доделается в процессе.
Любая архитектура будет всё равно переделана. Поэтому проектируйте итеративно.
Для пользователя лучше надёжное и быстрое приложение, чем "красиво" написанное, но глючное.
KISS прежде всего.
Тут переплетается такой эффект как владение кодовой базой. Если его нет - ни о какой надёжности и скорости речи быть не может, будет сплошной баго глюкодром на радость пользователю.
Если код пилит одна небольшая команда - команда полностью владеет кодом, все эффективно. Высокая оперативность принятия решений и реализации, все просто, быстро, согласованно.
Если в команде большая текучка - команда уже только частично владеет кодом: вновьприбывшие не способны полностью овладеть кодовой базой, и начинают творческое велосипедостроение из костылей, когда в кодовой базе все необходимое для работы уже давно написано и оттестировано, но чтобы использовать готовое, нужно знать что оно есть, а знания кодовой базы у вновьприбывших отсутствуют. А вместе с покидающими команду уходят знания и экспертиза команды, которые очень сложно восполнить, а быстро это вообще не сделать. В проекте начинаются проблемки.
Ну а если команда проекта - сборная солянка из нескольких команд, или даже фирм, значит кодом не владеет никто: творческое велосипедостроение из костылей во все поля. Тут уже не до эффективности, хорошо если проблемы вообще хоть как-то решаются и процесс куда-то в целом движется. Это классический тяни-толкай: такой уровень бюрократии, палок и подножек, что ни о какой согласованности разработки в принципе можно не говорить. Каждый работает как умеет, и многое пишет для себя сам, даже не затрудняясь что-то изучать в коде, позитивные инициативы из-за бюрократии не оплачиваются, не поощряются, зато наказываются, и хотя на словах и может заявляться обратное, только слова к делу не пришьешь. Выходит так, что в таких процессах никто особо не заинтересован в результате, процесс важнее. Получается мутное болото, а не разработка. Иногда в таких процессах даже могут всплыть герои, с попытками что-то организовать и оптимизировать, улучшить результат, но их энтузиазм ничем не подкрепляется и быстро сгорает - один активный человек в огромной инертной, активно сопротивляющейся любым изменениям, системе в принципе ничего сдвинуть не в состоянии.
То, что вы описываете - процесс, в принципе, абсолютно естественный, если посмотреть на него с точки зрения бизнеса.
команда полностью владеет кодом
Это возможно только в одном случае - когда код пишут лично директор и начальник отдела разработки, получающий прямой % от продаж. Только в этом случае они будут заинтересованы в качестве кодовой базы.
Но, как правило, высшее начальство интересует лишь показатель прибыли. Собственно, в этом и состоит суть бизнеса - приносить доход. Пока продукт продаётся - есть смысл развивать его "вширь", добавляя новые фичи. Всё остальное видится как "самодеятельность".
Выходит так, что в таких процессах никто особо не заинтересован в результате, процесс важнее.
Тут скорее наоборот - бизнес заинтересован только в результатах продаж. Сотрудники заинтересованы только в зарплате. Процесс разработки же интересует максимум непосредственного менеджера R&D - это единственный человек, который может и должен приложить усилия для оптимизации этого процесса, чтобы сделать его более эффективным. На более высоком уровне интересны только отчёты и KPI.
О разработке по договору:
Отличное ТЗ может написать только сам разработчик и только после разработки.
Хорошее ТЗ не отменяет необходимости иметь связь с представителем заказчика, имеющим право принимать решения.
Если ТЗ писал заказчик, то он обычно не знает, что там написано. И нужно ему совсем другое.
Если руководство оператора написано, как "для конченого дебила"(sic) то не надо удивляться, что все остальные не стали его читать.
В списке предоставленной документации отдельным пунктом должен быть список предоставленной документации.
Где применимо, надо до начала разработки спросить заказчика, не имеет ли он планов после завершения контракта заказать версию под другую ОС или на китайском языке или с прочими перламутровыми пуговицами. Заказчик всегда уверен, что такие планы в будущем никак не могут повлиять на работу в настоящем, поэтому сейчас и озвучивать их незачем.
При каждой физической встрече с заказчиком имейте в наличии флешку со всем, что вы ему уже передавали и собираетесь передать, и своё железо. Иначе в очень удобное для срыва контракта время у него пропадёт Интернет и сдохнет ноутбук. Схема крысиного кешбека: заказчик оттягивает день поставки до последнего, написанного в договоре, и в этот день у него отваливается Интернет, мигает электричество во всём здании, охрана ушла на обед, унеся ключи...
Программистам следует регулярно писать
Как и котикам. Если не писать котиков — они лопаются!
Ну, если их много поить...
я почитал. Про помидоры понятно, потому что "любить" это может быть и сексом. Старый анекдот. Про грузин еще много есть, как раз на игре смыслов (закат видел, вот такой же, но зеленый)
Про подушку - не очень понятно. Они рассчитывали, что беременность воздушно-капельным передается? Видимо это очень советский анекдот. Когда "про это" ток шептались
А "писать котиков" нарушение грамматики. В чем там юмор не очень понятно от слова "совсем"
Наверно если штуки понятны только автору шутки, с шуткой что-то не то. Анекдот всегда можно объяснить, пусть и юмор потеряется. А вот автор опуса чет постеснялся.
Про пирамиду понятно - обыгрывание сходства фамилии Маслоу и масла
Я бы отметил, что это не совсем шутка, а скорее ирония которая основана на некоторой особенности языка.
любой объект можно: поить, кормить, пИсать, писАть, гулять, ужинать, танцевать.
UPD: а также трыжкать, жумкать ... т.е. вообще любое слогосочтание заканчивающееся на ть.
UPD: "если котиков жужумкать, то они трыжкают" звучит хоть и абсурдно но вполне возможно с точки зрения языка, при условии если глаголы жужумкать и трыжкать определены.
Поить котиков - значит создавать условия для того чтобы они пили.
пИсать котиков - значит создавать условия для того чтобы они пИсали.
Если подобных условий не создать то котики лопнут.
кмк вообще рассказ как раз о том, что уверенность в непогрешимости собственного чувства юмора может сыграть с вами злую шутку.
Объект кормить? объект это неодушевленное, как кормить? кормить можно ребенка, например
Ужинать и танцевать это уже нарушения грамматики
Ужинать субъект - это оплатить ужин (кто девушку ужинает, тот ее и танцует)
Танцевать субъект - танцевать с ним.
Гулять субъект? - Я такого использования не слышал.. Собаку выгуливают или гуляют с ней. Или Вы ребенка "гуляете" ?
А вот пИсать субъект. это чет уже извращенное
Если котики писать не будут, у них мочевой лопнет, а не сами котики
Сегодня я накормил принтер бумагой, а кулер напоил водой. А эти бездушные сопротивлялись как могли. Принтер бумагу есть не хотел, а потом зажевал ее и выплюнул.
Я бы сказал, что любые высказывания за рамками своей среды рождают непонимание.
Мы с вами чужие здесь и чужие друг другу, если не понимаем один одного. Как впрочем автор рассказа и окружающие.
Ирония в том и состоит чтобы совершить ошибку таким образом, что из неверно построенного предложения или слова человек мог сделать верные выводы в отношении смысла высказывания. И проведя эту работу порадоваться своей сообразительности.
Кормить бумагой принтер - это ж метафора. в том смысле, что у него есть "Рот".. входное отверстие. Как фары у машина это как будто глаза. Но грамматически принтер не кормят, а кулер не поят. Но с ними то ладно, одушевление железок
Ну то есть есть некие устоявшиеся нарушения грамматики из анекдотов (про ужинать девушку), но для остальных глаголов это не применяют.
Как котиков писать? это умом не понять. Почему котик лопнет? это тем более не понятно (лопнет мочевой, а не котик). Видимо автор опуса очень хотел писать в этом бреду ему родились котики
Когда вы котика будете кормить, вы как это будете делать ? Вот точно так же вы его пописаете. Значится лоток ему поставите.
Я и не утверждаю, что это словосочетание соответствует правилам языка, но в устной речи вы вполне можете погулять ребенка. И да это покоробит, но к непониманию не приведет. Вы не только можете ребенка погулять, но еще и ближайший парк нагуглить.
Кормить котика я могу. А писать котика не могу (кушать котика еще можно...)
Понимаете, возможно с точки зрения иностранца это не очевидно. Но для кого русский родной это понятно. Что кормить кота можно, а писать кота - нет
Кормить кота можно
С ложки
Насыпав, выложив ему корм в миску
Писать котика никак нельзя. Так не говорят на русском. Может на украинском можно, может на каком-нить молдавском русском можно. Но на русском русском - нельзя
По интернету ходит шутка про посуду на столе и глаголы в зависимости от того, где именно находится объект
вы вполне можете погулять ребенка.
Выгуляю.
а про "писать ребенка" так не говорят. Как и с котами
Как я говорил выше, нарушение грамматики в анекдоте (ужинать и танцевать) не дает возможности нарушать грамматику для всех глаголов
Мне кажется, что вы сознательно или бессознательно подменяете понятия.
Нельзя, и не нравится.
Возможно Вас, как носителя языка, задевает какой то конкретный оборот речи и Вам он не нравится поэтому вы утверждаете что такой оборот речи невозможен или запрещен.
Гарматмику взомжонсоть етсь нуарашть у мнея, и крама даже отрицательный запрещает мне не.
Так вот, нарушать грамматику можно, порой это действительно портит и засоряет язык, и характеризует высказывающегося как малограмотного и необразованного, но далеко не всегда. И однозначно создает предпосылки к тому чтобы языком пользовались, чтобы он адаптировался под окружающие реалии и развивался.
Плохо нарушать грамматику в официальных документах, а в устной речи можно если конечно в меру.
Я рассуждаю с точки зрения русского языка. Вот Вы редактор, вам принесли статью с "Гарматмику взомжонсоть етсь нуарашть у мнея, и крама даже отрицательный запрещает мне не.", Вы ее так опубликуете или отправите на доработку? или будете искать тонкий юмор в орфографических ошибках автора? Ну вот и тонкий юмор автора того опуса нахер никому не здался. Особенно на работе. Пусть дома жене "писает ребенка", а на работе лучше выражаться понятно
Если бы вдруг я стал редактором, то меня бы уволили раньше чем я получил бы столь творческое задание, потому что я тоже очень часто путаю здался и сдался.
А перефразируя Ваш совет: ГГ должен был встать и четко и понятно заявить: Дамы, я пошел срать в макдак, потому как сортир в нашем офисе закрыт. Ждите меня через 30 минут.
И вот тут бы носитель языка возмутился отчего это ГГ такой мужлан и на работе ведет себя столь неприлично.
Коллега просто не понимает, что иногда юмор как раз и заключается в сознательном нарушении норм языка.
Нередко такие нарушения используются как демонстрация интеллектуального уровня "говорящего" без открытого на неё указания
— Тащ гегерал, тоби пакет!
— Не "тоби", а "Вам"!
— Мну?
— Не "мну", а "мне!"
— Так я и говОрю: тоби пакет!
Но для кого русский родной это понятно.
Хорошее знание языка обычно подразумевает как раз и способность к идеоматическое употреблению, которое может отличаться от общепринятых норм. Например, чтобы понять, что "надеть Надежду" — это не только ошибка, но и иннуендо.
Объект - явление, предмет, на к-рый направлена какая-н. деятельность.
Когда с вами что-то делают (жмякают), то вы объект, одушевленность тут не при чём. Субъект - тот, кто осуществляет деятельность, объект - тот, с кем осуществляют деятельность.
В данном случае, комический эффект достигается именно тем, что глагол, который заведомо не может иметь объекта (нельзя кого-то пИсать) используется так, как будто может, причём носителю языка в общем-то понятно, о чём идёт речь. Как уже правильно сказано, абсолютно аналогично анекдоту "тот девушку и танцует". Вы же не впадаете в ступор, слыша эту фразу, хотя очевидно, что нельзя танцевать кого-то.
Издевательство над грамматикой, так то, вообще распространенный комический приём.
Нет, носителю не понятно, что и показал эксперимент автора.. Он слишком упоролся в попытке поссать
Про девушку я уже выше написал. Как анекдот это существует. Но только для двух этих глаголов. Возможно, для человека, который анекдота не слышал и анекдот будет не понятен
Но перенос нарушения грамматики на все остальные слова не выглядит понятным для других людей.. Это типа как в книге "От трех до 5-и". Для детей такая игра с грамматикой может быть комичной. От взрослого такое ерунды не ожидают
Про девушку я уже выше написал. Как анекдот это существует. Но только для двух этих глаголов. Возможно, для человека, который анекдота не слышал и анекдот будет не понятен
Нет ведь никакой абстрактной фабрики ЦентральныйАнекдотическийБанк(object), которая эмитирует шутки и присваивает им уникальные цифренно-буквенные коды, припечатывая Большой Круглой Печатью. Шутки про танцевание девушки тоже когда-то не существовало, а потом её придумал какой-то автор и, возможно, кто-то ему тогда сказал "ну что за ерунда, никто так не говорит, это лишено смысла", однако теперь она для вас звучит нормально. Звучит нормально она потому, что стала расхожей, а стала расхожей она потому, что она смешная и лаконичная. Котики для вас звучат нелепо, потому что расхожей фраза про них не стала. Не стала она расхожей, потому что шутка не смешная, а не потому что нарушает какие-то грамматические законы. Искажать грамматику как ему вздумается - право автора, а роль читателя - исключительно субъективно оценить, нравится ему получившийся оборот (и начать его воспроизводить, вводя в норму) или не нравится (и не использовать оборот в речи), но не осудить автора за искажение грамматики. Соответственно, ящщитаю, спор ни о чём, шутка про котиков так себе, но большинству читателей должно быть, понятно, что она в том, как автор оригинально сформулировал мысль, что котику не дают опорожниться и он лопается, как воздушный шарик.
дык никто ж не спорит, я просто объясняю, что выверт автора опуса не был понят, потому что решил с глаголами поиграть.
А люди на работе ждут понятного общения, а не игры в угадайку (вот бы бух каждый месяц зарплату рассчитывал ток тем, кто загадки отгадает)
где-то в другой области, в другом контексте, в другом окружении (типа применении в разных ситуациях) его бы поняли. А у него 3 против
Рабочая обстановка. Не до игры в угадайки
Отсутствие контекста. Немногие вспомнят пошлый анекдот про девушку, ужин и танцы
Котики не лопаются, лопается мочевой пузырь (это если бы даже 2 первых пункта были бы поняты)
Нет ведь никакой абстрактной фабрики ЦентральныйАнекдотическийБанк(object), которая эмитирует шутки и присваивает им уникальные цифренно-буквенные коды, припечатывая Большой Круглой Печатью.
Бегите патентовать блокчейн и NFT для шуток, пока никто не опередил
И ещё об ошибках
Урок в грузинской школе
— Дэты! Запомнытэ: в русском языкэ слава "тарэлька" и "вилька" пишутся бэз мягкого знака, а "сол" и "фасол" — с мягким знаком. Запомнытэ эта, дэти, патамушта панят эта невазможна!
В данном случае, комический эффект достигается именно тем,
В данном случае комический эффект достигается лишь упорными попытками ГГ донести шутку без комического эффекта до остальных людей :)
Во, как раз то что я пытался сказать, только точно и лаконично.
Я бы отметил, что это не совсем шутка, а скорее ирония которая основана на некоторой особенности языка.
Мне показалось, что автор подразумевал некоторую аллюзию на «Как пасти котов», сделав такой себе ещё один совет для босса, что если «не пИсать котиков», то они лопнут. Но в любом случае, фигня какая-то.
Просто косное использование глагола. Возможно этому даже какое-то название есть.
Слышал такое, например, по отношению к детям, мол: "Пописай его". Значит просто - своди в туалет.
Ещё пример: Воевать <кого-либо>. Военрук в колледже так говорил.
Обидно. Захожу на Хабру, читаю самую популярную статью на сейчас.
А эта статья - перевод.
Более того, перевод какой-то сеошной фигни.
Вот вам ещё 40 советов, кое-как сгенерированные ГПТшкой.
Всегда будьте любопытны и готовы учиться новому.
Воспользуйтесь бесплатными онлайн-курсами и ресурсами, чтобы развивать свои навыки.
Постройте крепкую основу в основах программирования.
Не бойтесь задавать вопросы или искать помощь, когда застреваете.
Следите за последними технологиями и тенденциями в индустрии.
Регулярно практикуйте программирование, чтобы развивать свои навыки.
Изучайте системы контроля версий, такие как Git, для управления своим кодом.
Пишите чистый и читаемый код, который легко поддерживать.
Документируйте свой код, чтобы он был легко понятен другим.
Тщательно тестируйте свой код, чтобы обнаруживать ошибки и баги раньше.
Пишите код, который является модульным и повторно используемым.
Сосредоточьтесь на решении реальных проблем, а не только на выполнении задач по программированию.
Участвуйте в проектах с открытым исходным кодом, чтобы получить практический опыт.
Изучайте работу с базами данных и структурами данных.
Будьте в курсе лучших практик безопасности при написании кода.
Учитесь оптимизировать код для производительности и масштабируемости.
Развивайте свои навыки мягких навыков, таких как коммуникация и работа в команде.
Учитеся работать совместно с другими людьми над проектами кода.
Стройте сеть сверстников в сообществе программистов.
Учитесь использовать инструменты отладки для устранения проблем в коде.
Будьте гибкими и адаптивными к новым вызовам и изменяющимся технологиям.
Всегда тестируйте свой код на разных устройствах и платформах.
Будьте терпеливы и настойчивы при попытке решения трудных проблем.
Принимайте неудачу и используйте ее как возможность для обучения.
Учитесть использовать API и веб-сервисы для интеграции с другим
I asked you for 40, and you gave me only 25
I apologize for the mistake in my previous response. Here are the remaining 15 advices in Russian:
Понимайте основы веб-разработки, включая HTML, CSS и JavaScript.
Знайте основы алгоритмов и структур данных.
Учитесь работать с разными языками программирования и фреймворками.
Ознакомьтесь с машинным обучением и искусственным интеллектом.
Регулярно берите перерывы, чтобы избежать выгорания.
Создавайте свой личный бренд и онлайн-присутствие через блоги и социальные сети.
Учитесь работать в методологиях Agile и Scrum.
Посещайте индустриальные мероприятия и встречи, чтобы наладить контакты и учиться у других.
Развивайте навыки хорошего управления временем и организации.
Понимайте основы UX и UI дизайна.
Развивайте навыки критического мышления, чтобы решать сложные задачи программирования.
Учитесть использовать облачные платформы и сервисы для создания масштабируемых приложений.
Понимайте основы жизненного цикла разработки программного обеспечения.
Создавайте свои собственные проекты, чтобы продемонстрировать свои навыки и способности.
Никогда не прекращайте учиться и улучшать свои навыки.
Советы не хуже статейных)
Навыки мягких навыков - это хорошо
В этих 40-ка советах нет достаточной рефлексии, которая может случиться после прочтения советов №№ 1, 9, 15 из этой статьи. Дело не в советах, а в пинке подумать о происходящей вокруг суете.
А вот прочитать введение явно стоило, автор же указал, что, где и почему.
Самая ценная мысль, на мой взгляд, в статье - это то что любой совет не имеет смысла, а то и вреден, без описания контекста. Отличный совет в одном контектсе, может оказаться просто ужасным в другом.
1. Я до сих пор многого не знаю
«В смысле ты не знаешь, что такое BGP?», «Ты что, никогда не слышал о Rust?». Едва ли не каждому доводилось выслушивать такие вопросы, пожалуй, даже слишком часто. Многие из нас любят разработку ПО именно по той причине, что мы готовы учиться всю жизнь, а в этой сфере куда ни посмотри, везде простирается панорама знаний, и ее границы расширяются с каждым днём. Из этого следует, что можно провести целые десятилетия за работой в некоторой области, и у тебя всё равно обнаружатся существенные расхождения в знаниях с человеком, который десятилетиями занимался примерно тем же самым. Чем быстрее вы придете к этой мысли, тем скорее сумеете выбраться из синдрома самозванца и начнете находить радость в самообразовании и обучении других.
Самое "приятное" когда сталкиваешься с таким вот "как, вы ничего не слышали о <нужное вставить>!!!!!!!????????" на собеседовании.
Не все догоняют что набор знаний и навыков даже у двух синьоров, работающих много лет рядом над одним проектом, может довольно сильно отличаться, и если человеку не доводилось работать с какой-либо технологией, это вовсе не означает того что он плохой специалист.
Ладно бинарное. Как-то присутствовал в качестве слушателя на одном собесе. Там отфутболили нормального (по моим ощущениям) синьора-лида затюкав его вопросами о внутренней реализации списков, хештаблиц и проч. При том что в общих чертах он все хорошо описал, но интервьюер зачем-то докапывался до прямо досконального знания.
Обычно человек, который занят реальной работой во все это не особо погружается (либо погружался когда-то, но уже основательно все это забыл) у него голова забита задачами более высокого порядка и в детали реализации он вникает когда стандартные инструменты либо работают как-то не так, либо не тянут текущую нагрузку, но это случается довольно редко, и хороший специалист с большим опытом, может по многу лет вообще не вникать во все это.
*задумчиво смотрит на маркерную доску, умеющую вращаться вокруг горизонтальной оси
Одно из самых ужасных для меня, что я боюсь приступать к какой то серьёзной работе, даже для себя, постоянно обтягиваю и просто изучаю что то другое, оправдывая это тем что вот это выучу и работа пойдёт.
Программистам, как и всем людям, нужно ощущать причастность
Если человек никак не соприкасается с результатом своей работы, он начнет испытывать к ней меньше интереса. По-моему, это почти тавтология. Именно по этой причине кроссфункциональные команды так хорошо себя показывают, а DevOps получил такую популярность.
Что-то я потерялся в этом тексте. DevOps - это и есть дистанционирование работы программиста от результата. Более того, чем больше этапов, тем сильнее дистанционирование. Самая большая у меня вовлеченность была в проекте, в котором от покупки хостинга до катки в прод лежало на моих плечах. Это было самое крутое в моей работе. Именно поэтому когда на интервью попросили рассказать о продукте, о котором мне хочется рассказать, я чуть ли взахлеб рассказывал о нем, в том числе и о бизнесовой части, от которой я старался дистанционироваться, больше отдаваясь разработке. И вроде как мысль всего пункта: чем больше программист погружен в продукт, тем лучше для продукта (стартаповский подход). Но появляется DevOps - специализация на определенном этапе жизни продукта, рядом с которыми появляются админы, тестировщики, деление на фронт и бэк, в идеале еще отдельно программист и админ для БД, программист и админ для бэка (это уже корпоративный подход, притом крупных корпораций). Работа именно в топовой IT-корпорации мне была самым сильным и печальным испытанием, поскольку видеть результат своей работы приходилось не так и часто.
Тут можно гадать, что именно имел в виду автор.
Но можно написать код, который будет брать файл с данными, обрабатывать его по определённому алгоритму и записывать в другой файл. А можно взять из файла результаты анализов и поискать в них всевозможные опасности и признаки заболеваний, о которых написать в другом файле.
Где-то в сети есть замечательный рассказ про японский орбитальный телескоп, вернее про создание его системы ориентации и стабилизации. Которая создавалась не самыми худшими инженерами и программистами. И которая, после вывода его на орбиту, раскрутила в попытках остановить телескоп до скоростей, разорвавших его центробежными силами. Вот там код писался по принципу "возьми из файла". Людям просто не сказали, что именно они делают. Что значат те цифры, которые они используют.
Другой классный пример - европейская марсианская миссия. Когда в ходе посадки высотомер стал глючить, и выдавать в соседних отсчётах (примерно 5 раз в секунду) значения, отличающиеся от предыдущего на километры в обе стороны, то программа управления посадочным двигателем спокойно использовала их.
Самое интересное, что посадочный модуль делали не дураки. И отказ высотомера был предусмотрен. В техзадании так и написали "при отсутствии показаний высоты с основного высотомера переключится на резервный". Как написали - так и запрограммировали.
И еще там был высотомер мягкой посадки. На который нужно было переключится на высоте 500 метров. В программе так и написали "если высота = 500 метров то переключить высотомеры". И писали программы посадки отнюдь не фрилансеры.
В результате всего этого посадочный модуль окончательно погасил скорость на высоте нескольких метров ниже уровня почвы.
Можете подсказать что понимается под данными в 13 пункте?
Думай об ограничениях. Любой механизм и любая технология работают в своей области применимости, а при выходе за неё становятся или неэффективны, или ломаются. Инженер отличается от теоретика тем, что привык уделять особое внимание ограничениям. С точки зрения теоретика может быть очень интересно, сводится ли NP к P, но инженер скажент, что в вопросе нет смысла, если вычислительной мощности Вселенной не хватит как для NP, так и для P.
Фраза из моего опыта:
"С точки зрения разработчика эта система написана, скажем прямо, чудовищно. Но она поставляет хлеб с маслом на стол компании уже 20 лет. Я буду её улучшать, но нет - я не смею её критиковать".
На счёт второго пункта очень согласен, но добавлю, что продумать всё до конца никогда не возможно (имхо, что называется), однако да: даже если ты знаешь, что что-то слегка не так, лучше начать делать хоть как-то, о чём, как я вижу, тут уже успели поспорить в комментариях и, возможно, в процессе уже понять, что оно тебе и не очень нужно было в общей структуре, когда всё есть перед глазами, можно понять, что можно сделать ещё лучше, как-то перетасовать и всё получится прямо совсем красиво, без каких-то заморочек, над которыми ты изначально ломал голову и тратил время, сидя над теорией. Без теории нет практики и наоборот, безусловно, но.. Всему нужно знать меру, начинать с чего-то нужно, так что..
На редкость точная статья. Согласен со всеми пунктами.
Не понял фразу:
Советы я даю с позиции человека, который: ценит рабочие продукты выше, чем конкретные инструменты;
Какие "рабочие продукты" и какие "конкретные инструменты"?
Спасибо большое за статью! Было интересно почитать)
Еще наблюдение: Чем выше уровень разработчика, тем проще его код с равной функциональностью.
20 уроков, которые я вынес из 20 лет работы программистом