«Да просто повысьте цены!» — говорит компания, которая уже двадцать лет на рынке и первые годы продавала продукт за копейки, чтобы привлечь клиентов и прийти к успеху. «Нужно всё реализовать в микросервисах», — говорит компания, которая по-быстрому сколотила монолит, набрала несколько тысяч пользователей и метнулась к микросервисам, когда начались проблемы с масштабированием.
Без понимания контекста советы теряют смысл или, хуже того, приносят вред. Если бы люди из примеров выше последовали своим собственным советам в начале пути, то, вероятно, пожалели бы этом. Этой ловушки сложно избежать. Мы представляем собой кульминацию своего опыта, но при этом смотрим на него через призму настоящего.
Так что дам вам немного контекста, который породил мои советы. Первую половину своей карьеры я провел в роли программиста, работающего на различные небольшие компании и стартапы, затем ушел в консалтинг и работал на несколько очень крупных организаций. Потом создал компанию Simple Thread, которая выросла с двух сотрудников до двадцати пяти. Десять лет назад мы работали в основном с малым и средним бизнесом, сейчас среди наших клиентов есть представители и малого, и крупного бизнеса.
Советы я даю с позиции человека, который:
- почти всегда работал в составе маленьких, компактных команд с ограниченными ресурсами;
- ценит рабочие продукты выше, чем конкретные инструменты;
- постоянно начинает новые проекты, но при этом поддерживает несколько старых систем;
- ставит продуктивную работу программистов выше многих других соображений.
Приобретенный за последние двадцать лет опыт сформировал мои взгляды на разработку и привел меня к некоторым выводам – я попытался скомпоновать их в удобоваримый список, в котором вы, надеюсь, найдете что-то ценное для себя.
Перейдем к списку.
1. Я до сих пор многого не знаю
«В смысле ты не знаешь, что такое BGP?», «Ты что, никогда не слышал о Rust?». Едва ли не каждому доводилось выслушивать такие вопросы, пожалуй, даже слишком часто. Многие из нас любят разработку ПО именно по той причине, что мы готовы учиться всю жизнь, а в этой сфере куда ни посмотри, везде простирается панорама знаний, и ее границы расширяются с каждым днём. Из этого следует, что можно провести целые десятилетия за работой в некоторой области, и у тебя всё равно обнаружатся существенные расхождения в знаниях с человеком, который десятилетиями занимался примерно тем же самым. Чем быстрее вы придете к этой мысли, тем скорее сумеете выбраться из синдрома самозванца и начнете находить радость в самообразовании и обучении других.
2. Самое сложное в разработке – разрабатывать именно то, что требуется
Знаю, сейчас это уже звучит как банальность, но большинство разработчиков не соглашается с такими заявлениями из-за того, что те, как им кажется, обесценивают их усилия. Как по мне, ничего подобного. Напротив, они подчеркивают, в какой сложной, не поддающейся законам рациональности среде нам приходится работать и как это усложняет наши задачи. Можно спроектировать самый технически продвинутый продукт на свете и не найти ни одного желающего его использовать. Подобное случается часто. Проектирование по большей части завязано на том, чтобы слушать других, и зачастую нам приходится быть программистом, медиумом и антропологом одновременно. Вложения в процесс проектирования (будь это создание особой команды по UX или просто отработка собственных навыков) окупаются с лихвой. Ведь, если вы возьмете в работу не тот продукт, какой следовало, как вообще рассчитать издержки? Это обойдется гораздо дороже впустую потраченных часов программирования.
3. Лучшие программисты мыслят как проектировщики
Хорошие разработчики ПО глубоко продумывают тот пользовательский опыт, который формирует их код. Возможно, они описывают это в иных выражениях, но о чем бы ни шла речь – о внешнем API, программном API, пользовательском интерфейсе, протоколе, о любом интерфейсе вообще – хорошие разработчики прикидывают, кто будет им пользоваться, в каких целях, как именно и что будет иметь наибольшее значение для этих людей. В основе качественного пользовательского опыта лежит именно внимание к потребностям.
4. Лучший код – это отсутствие кода или хотя бы необходимости его поддерживать
Что тут скажешь, программистам без кода никуда. Попросите человека любой профессии решить какую-нибудь проблему, и он отдаст предпочтение тому способу, на котором собаку съел. Это в человеческой природе. Большинство программистов всегда будут склоняться к тому, чтобы писать код, особенно если менее техническое решение не очевидно. То же относится и к коду, не требующему поддержки. Технические команды имеют склонность изобретать велосипед, даже когда вокруг уже целая куча этих велосипедов. Тут нужно выдерживать баланс – есть много доводов в пользу доморощенных инструментов, но остерегайтесь нездорового синдрома «это не здесь придумано».
5. ПО – это не конечная цель, а способ ее достижения
Основная задача любого программиста – создавать ценность. Понимают это очень немногие, а по-настоящему проникаются идеей и вовсе единицы. Если проникнуться по-настоящему, это приведет к тому, что вы иначе будете подходить к решению проблем и иначе воспринимать свои инструменты. Если вы искренне убеждены, что продукт должен служить предполагаемому исходу, то будете действительно готовы искать «нужный инструмент для конкретной задачи». В некоторых случаях это вообще не ПО.
6. Иногда нужно прекратить затачивать косу и уже покосить что-нибудь
Есть люди, которые ныряют в проблему с головой и немедленно начинают строчить код. Есть и такие, которых тянет до бесконечности собирать информацию и впадать в аналитический паралич. Если вы из последних, поставьте себе дедлайн, и, когда он наступит, принимайтесь за проработку решений. За этим занятием вы быстро получите дополнительную информацию, что поможет в итерировании наилучшего решения.
7. Если у вас нет ясного представления о возможностях, вы не сможете толково спроектировать систему
С этим моментом мне приходится непросто теперь, когда новые обязанности уводят меня дальше и дальше от повседневных обязанностей разработчика. Держать руку на пульсе экосистемы инструментов для разработчиков – это огромный объем работы, но иначе нельзя прийти к пониманию, каков спектр возможностей. Если вы не понимаете, что в рамках некоторой экосистемы возможно и что доступно, то обнаружите, что не способны вывести разумное решение для какой бы то ни было проблемы, кроме самых примитивных. Если вкратце: остерегайтесь людей, которые уже давно не писали код, но при этом проектируют системы.
8. В конечном счете, любая система – отстой, смиритесь
У Бьёрна Страуструпа есть такая цитата:
«Существует только два вида языков: те, на которые люди жалуются, и те, которыми никто не пользуется»
Это верно и применительно к любой крупной системе. Нет никакой «правильной» архитектуры, вы никогда полностью не рассчитаетесь по техническому долгу, не спроектируете идеальный интерфейс, тесты всегда будут не поспевать. Это не повод никогда не пытаться ничего улучшить, это моя попытка дать вам другой угол обзора. Не зацикливайтесь на элегантности и безукоризненности, лучше стремитесь к непрерывному улучшению и к созданию жизнеспособной системы, с которой команде приятно работать и которая стабильно что-то дает людям.
9. Вопрос «почему?» всегда звучит слишком редко
Никогда не упускайте возможность поставить под вопрос допущения и подходы из разряда «мы так всегда делали». К вам присоединился новый сотрудник? Внимательно отслеживайте, что приводит его в недоумение и какие вопросы он задает. Поступил невразумительный запрос на новую функциональность? Убедитесь, что понимаете ее назначение и то, откуда берется такое желание. Если внятного ответа нет, продолжайте задавать вопросы, пока не разберетесь.
10. Нам нужно меньше искать 10x-программистов и больше избегать 0.1x-программистов
10x-программисты – это дурацкий миф. Сама идея, что кто-то способен за день выдать то, на что у умелого, трудолюбивого работника со схожим опытом займет две недели – чистая глупость. Видал я программистов, которые выдают тебе в десять раз больше кода, чем прочие – потом за ними приходится в десять раз дольше править. 10x-программистом можно стать только в том случае, если тебя сравнивают с 0.1x-программистами. То есть с теми, кто просиживает без дела, не интересуется обратной связью, не проводит тесты, не учитывает крайние случаи… И то, что в команду может затесаться такой вот 0.1x-программист, должно занимать нас гораздо сильнее, чем поиски мифического 10x-программиста.
11. Одно из ключевых различий между джуниором и сениором – сложившиеся мнения о том, как должно быть
Мало что беспокоит меня так, как сениор, у которого нет собственного мнения об инструментах, с которыми он работает, или подхода к разработке. Уж лучше пусть изложит взгляды, которые я буду яростно оспаривать, чем покажет полное их отсутствие. Если вы пользуетесь инструментами и не испытываете к ним целого диапазона добрых и недобрых чувств, значит, вам недостает опыта. Вам нужно изучать другие языки, библиотеки, парадигмы. Один из самых скоростных способов подтянуть навыки – активно выяснять, как ваши задачи выполняются другим набором техник и инструментов.
12. Люди на самом деле не хотят инноваций
Поговорить об инновациях люди очень любят, но на деле обычно хотят, чтоб дешево и сердито плюс с элементом новизны. Если вы выдаете что-то по-настоящему инновационное, что изменит весь порядок их действий, будьте готовы к преимущественно негативной обратной связи. Если же у вас есть вера в продукт и убеждение, что он изменит ситуацию к лучшему, настраивайтесь на длительную схватку.
13. Данные – самая важная часть вашей системы
Я повидал много систем, где основным механизмом защиты целостности данных была надежда на лучшее. В подобных системах любое отклонение с прямого пути приводит к расщеплению или загрязнению данных. В будущем работа с такими данными может обернуться сущим кошмаром. Не забывайте: ваши данные с большой долей вероятности переживут кодовую базу. Не жалейте сил на то, чтобы держать их в порядке и чистоте, это окупится в долгосрочной перспективе.
14. Ищите технологических акул
Старые технологии, которые не теряют актуальности до сих пор – это не динозавры, а акулы. Они так эффективны в решении проблем, что смогли уцелеть перед лицом резких изменений, которые то и дело происходят в мире технологий. Не выступайте против этих технологий и заменяйте их только если на то есть очень веские причины. Такие инструменты не отличаются броскостью и не вызывают энтузиазма, но успешно справляются со своей задачей и берегут вас от бессонных ночей.
15. Не путайте скромность с невежеством
На свете есть множество программистов, которые не станут высказываться, пока их не спросят. Никогда не предполагайте, что человеку, который не суёт своё мнение вам под нос, нечего добавить к обсуждению. Нередко бывает так, что именно тех, кто громче всего кричит, меньше всего стоит слушать. Разговаривайте с окружающими, просите у них совета и обратной связи. Вы об этом не пожалеете.
16. Программистам следует регулярно писать
Программистам нужно на регулярной основе вести блог или ежедневник, работать над документацией – в общем, заниматься чем-то, что будет оттачивать их навыки письменной речи. Письменное изложение помогает нам обдумывать проблемы и учит правильно доносить свои мысли до команды и даже до самого себя в будущем. Хорошая письменная речь – один из ключевых навыков, которые должен освоить любой разработчик.
17. Соблюдайте минимализм в процессах
В наши дни все стремятся перейти на Agile, но по сути, это ведь сводится к тому, чтобы делать работу небольшими порциями, выносить уроки и итерировать. Если кто-то пытается напихать в эту концепцию еще кучу всего дополнительного, то, скорее всего, хочет денег. Я не говорю, что людям не нужна подотчетность и помощь, чтобы перейти на такую схему работы, но часто ли вы слышите, как сотрудники вашей любимой технологической компании или крупного проекта с открытым кодом хвалятся своим замечательным Scrum-процессом? Внедряйте процессы по минимуму, пока не убедитесь, что нужно добавить еще что-то. Доверяйте своей команде, и она вас не подведет.
18. Программистам, как и всем людям, нужно ощущать причастность
Если человек никак не соприкасается с результатом своей работы, он начнет испытывать к ней меньше интереса. По-моему, это почти тавтология. Именно по этой причине кроссфункциональные команды так хорошо себя показывают, а DevOps получил такую популярность. Дело тут не только в передачах и неэффективных практиках, ключевым является то, что одни и те же работники ведут процесс от начала до конца и полностью отвечают за выдачу ценности. Дайте группе увлеченных людей полный контроль над проектированием, разработкой и выпуском программного продукта (да и вообще чего угодно), и результаты будут потрясающими.
19. Собеседования почти ничего не говорят о том, каким членом команды будет кандидат
Собеседования гораздо продуктивнее тратить на то, чтобы понять, что за человек перед вами и есть ли у него интерес к определенной области знания. Пытаться разведать, как он покажет себя в командной работе – бессмысленное занятие. И, уж поверьте мне, ум и эрудиция не дают никаких гарантий, что перед вами хороший командный игрок. Никто не станет сообщать вам на собеседовании, что намерен быть безответственным, жестоким, напыщенным или вечным опоздуном на всех собраниях. Некоторые утверждают, что, мол, «считывают сигналы». «Если он спрашивает об отгулах на первом собеседовании, значит, на работе вообще появляться не будет!» Но это всё чушь собачья. С такими сигналами вы просто гадаете на кофейной гуще и отказываете хорошим специалистам.
20. Всегда старайтесь сделать систему покомпактнее
С самого начала множество сил может толкать вас к тому, чтобы сделать систему масштабнее. Распределение бюджета, неспособность решить, что из функциональности урезать, желание выстроить систему «в наилучшем виде». Всё это оказывает на нас сильное давление, заставляя раздувать систему. Этому следует сопротивляться. В процессе создания системы вы узнаете столько нового, что в итоге итерируете к версии, которая будет гораздо лучше любой из тех, что вы могли бы спроектировать изначально. Почему-то многих очень сложно убедить в верности этого тезиса.
Какой была ваша история?
Ну вот вам, двадцать лет разработки, сконцентрированные в двадцати кратких мудрых советах. Буду рад, если какие-то из них вызвали у вас отклик. Также буду рад послушать, если вы захотите поделиться собственными мудрыми советами, которые вывели в процессе работы. Не стесняйтесь, оставляйте их в комментариях.
Комментарии (115)
anonymous
00.00.0000 00:00НЛО прилетело и опубликовало эту надпись здесь
PuerteMuerte
00.00.0000 00:00+31По-моему, все статьи "{itemCount} умных штук, которые я понял за {workExperienceYears} лет работы программистом" на одно лицо :)
ht-pro
00.00.0000 00:00+1И, тем не менее, они всегда набирают высокий рейтинг)...
gandjustas
00.00.0000 00:00+4Потому что из раза в раз повторяют очевидные, но от этого не менее полезные вещи.
K0styan
00.00.0000 00:00В колонке справа что-то с теми же цифрами всю прошлую (или позапрошлую?) неделю висело. Но туда не заглядывал, утверждать, что это та же статья - не берусь.
Portnov
00.00.0000 00:00+24Ожидал в конце что-нибудь вроде
Перестаньте читать статьи с банальными советами и идите писать код
...
Myclass
00.00.0000 00:00+2Да, ладно вам. Людям с 30 летним стажем в статье нет ничего нового, но своего рода рефлектирование, а может быть и переосмысление никогда не помешает. Для многих с опытом < 10 лет ничего их написанного не помешает. Хотя свой опыт им всё равно самим придётся делать.
eximus
00.00.0000 00:00+412. Люди на самом деле не хотят инноваций
Это ещё Джордано Бруно, Николай Коперник и другие учёные доказали, когда выясняли что-то новое, но заскорузлое "научное сообщество" или нравы/подходы тех времён никак не хотели мириться с приходом чего-либо непривычного в их уклад жизни.
16. Программистам следует регулярно писать
Ха! Полностью поддерживаю! Это давно известно, "кто как мыслит, тот так и излагает". А про тех, кто "ниасилел" грамотную письменную речь, есть давным-давно диагноз "дисграфия".
Старое определение
Дисграфия – это специфическое расстройство письменной речи, проявляющееся в стойких ошибках. Развивается по причине несформированности высших отделов ЦНС. Заболевание не позволяет детям овладеть грамматическими особенностями языка.
То есть, недоразвитость неких областей мозга.
Много букв о причинах, современный подход
Нарушение письма может быть обусловлено задержкой в формировании определённых функциональных систем, важных для освоения письменной речи. Такая задержка возникает в результате воздействия неблагоприятных факторов в разные периоды развития ребёнка.
К неблагоприятным факторам раннего периода можно отнести:
отягощённая беременность — хронические заболевания матери, гестоз, анемия, многоплодная беременность;
рождение ребёнка на сроке беременности до 35 недель;
перинатальная патология центральной нервной системы (ЦНС);
церебральная гипоксия (ишемия) — острое повреждение головного мозга в результате его недостаточного кровоснабжения во время беременности, родов или в течение первого месяца жизни;
родовая травма ЦНС;
инфекции ЦНС (токсоплазмоз, герпес, цитомегаловирус, краснуха);
системные метаболические нарушения (билирубиновая энцефалопатия, гипогликемия, гипокальциемия, гипо- и гипермагниемия, гипо- и гипернатриемия).
Причины, которые могут привести к дисграфии в более старшем возрасте (после 2 лет):
черепно-мозговые травмы;
нейроинфекции;
патологии внутренних органов (пиелонефрит, гастрит, пневмония, ревматизм);
нарушения сердечно-сосудистой системы;
онкология;
выраженная психологическая травма, обусловленная сложной семейной обстановкой, низким социальным статусом, конфликтами со сверстниками, одиночеством.
Эти патологические состояния приводят к астении нервной системы и могут осложнять освоение письменной речи.
Часто встречается наследственная предрасположенность к дисграфии. Кроме того сложности с письмом могут возникнуть у ребёнка, пишущего левой рукой или переученного с левой руки на правую. Нередко дисграфией страдают дети, для которых язык, на котором они учатся писать, не является родным.
Вероятность дисграфии велика при общем недоразвитии речи. Расстройство может провоцировать логоневроз (заикание и запинания в речи) и сниженный темп созревания психических функций (например, на фоне хронических болезней или социальной дезадаптации).
Сейчас дисграфия, по мнению описаний на куче сайтов медклиник, успешно лечится. Но некоторые взрослые, до сих пор, пишут безграмотно. Лично по моему скромному опыту, я не встречал классных программистов, которые органически не умели бы писать грамотно. Могут совершать ошибки при письме "на бегу, второпях", но, когда стараются, пишут все грамотно.
Но в этом пункте и про продумывание, когда описываешь словами, а не только стрелочками и/или BPMN. И вот тут тоже полностью согласен, помогает сильно.
hatman
00.00.0000 00:00У меня идет особенность, что я не умею читать вслух. Как это проявляется.
1) Я отлично читаю про себя.
2) Я более менее разговариваю (в детстве сильно заикался, однако два года прозанимался с логопедом и стало более менее).
Однако, когда я начинаю читать вслух, то все поле зрения сужается до 2-3 букв и фактически не могу читать, так как не вижу все слово. Занятия с логопедом этот баг пофиксить не смогли.
Как итог, с возрастом научился, что читаю несколько слов про себя, потом их произношу уже без чтения. И так в режиме итератора, пока все не прочитаю.
Это сказывается на граммотности моего письма, что приходится несколько раз перепроверять все, чтобы оно вышло более менее адекватным. Являюсь помидором, все окей.
В детстве из-за этого очень не любил уроки литературы и русского языка, но вывез их старанием на четверки.
WraithOW
00.00.0000 00:00+4Лично по моему скромному опыту, я не встречал классных программистов, которые органически не умели бы писать грамотно
Звучит как зависимость глобального потепления от числа пиратов. Более простое объяснение — хорошие программисты читают (или как минимум читали) много написанных хорошим языком книг/статей, а это уже транслируется в хорошую письменную речь (плюс привычка структурировать информацию, а не тяп-ляп и в продакшен).
Я это прям хорошо ощущаю — в школе залпом употреблял содержимое школьной библиотеки, писал нормально просто на автомате. Сейчас большая часть контента — либо на нерусском, либо на разговорном русском, в итоге пунктуация давно стала авторской, а спряжения регулярно сношал её рука. Приходится перечитывать всё по 10 раз, и то что-нибудь да просочится.
Racheengel
00.00.0000 00:00+1Любой проект должен стартовать с MVP. Основной функционал доделается в процессе.
Любая архитектура будет всё равно переделана. Поэтому проектируйте итеративно.
Для пользователя лучше надёжное и быстрое приложение, чем "красиво" написанное, но глючное.
KISS прежде всего.
0x131315
00.00.0000 00:00+6Тут переплетается такой эффект как владение кодовой базой. Если его нет - ни о какой надёжности и скорости речи быть не может, будет сплошной баго глюкодром на радость пользователю.
Если код пилит одна небольшая команда - команда полностью владеет кодом, все эффективно. Высокая оперативность принятия решений и реализации, все просто, быстро, согласованно.
Если в команде большая текучка - команда уже только частично владеет кодом: вновьприбывшие не способны полностью овладеть кодовой базой, и начинают творческое велосипедостроение из костылей, когда в кодовой базе все необходимое для работы уже давно написано и оттестировано, но чтобы использовать готовое, нужно знать что оно есть, а знания кодовой базы у вновьприбывших отсутствуют. А вместе с покидающими команду уходят знания и экспертиза команды, которые очень сложно восполнить, а быстро это вообще не сделать. В проекте начинаются проблемки.
Ну а если команда проекта - сборная солянка из нескольких команд, или даже фирм, значит кодом не владеет никто: творческое велосипедостроение из костылей во все поля. Тут уже не до эффективности, хорошо если проблемы вообще хоть как-то решаются и процесс куда-то в целом движется. Это классический тяни-толкай: такой уровень бюрократии, палок и подножек, что ни о какой согласованности разработки в принципе можно не говорить. Каждый работает как умеет, и многое пишет для себя сам, даже не затрудняясь что-то изучать в коде, позитивные инициативы из-за бюрократии не оплачиваются, не поощряются, зато наказываются, и хотя на словах и может заявляться обратное, только слова к делу не пришьешь. Выходит так, что в таких процессах никто особо не заинтересован в результате, процесс важнее. Получается мутное болото, а не разработка. Иногда в таких процессах даже могут всплыть герои, с попытками что-то организовать и оптимизировать, улучшить результат, но их энтузиазм ничем не подкрепляется и быстро сгорает - один активный человек в огромной инертной, активно сопротивляющейся любым изменениям, системе в принципе ничего сдвинуть не в состоянии.
Racheengel
00.00.0000 00:00То, что вы описываете - процесс, в принципе, абсолютно естественный, если посмотреть на него с точки зрения бизнеса.
команда полностью владеет кодом
Это возможно только в одном случае - когда код пишут лично директор и начальник отдела разработки, получающий прямой % от продаж. Только в этом случае они будут заинтересованы в качестве кодовой базы.
Но, как правило, высшее начальство интересует лишь показатель прибыли. Собственно, в этом и состоит суть бизнеса - приносить доход. Пока продукт продаётся - есть смысл развивать его "вширь", добавляя новые фичи. Всё остальное видится как "самодеятельность".
Выходит так, что в таких процессах никто особо не заинтересован в результате, процесс важнее.
Тут скорее наоборот - бизнес заинтересован только в результатах продаж. Сотрудники заинтересованы только в зарплате. Процесс разработки же интересует максимум непосредственного менеджера R&D - это единственный человек, который может и должен приложить усилия для оптимизации этого процесса, чтобы сделать его более эффективным. На более высоком уровне интересны только отчёты и KPI.
MountainGoat
00.00.0000 00:00+2О разработке по договору:
Отличное ТЗ может написать только сам разработчик и только после разработки.
Хорошее ТЗ не отменяет необходимости иметь связь с представителем заказчика, имеющим право принимать решения.
Если ТЗ писал заказчик, то он обычно не знает, что там написано. И нужно ему совсем другое.
Если руководство оператора написано, как "для конченого дебила"(sic) то не надо удивляться, что все остальные не стали его читать.
В списке предоставленной документации отдельным пунктом должен быть список предоставленной документации.
Где применимо, надо до начала разработки спросить заказчика, не имеет ли он планов после завершения контракта заказать версию под другую ОС или на китайском языке или с прочими перламутровыми пуговицами. Заказчик всегда уверен, что такие планы в будущем никак не могут повлиять на работу в настоящем, поэтому сейчас и озвучивать их незачем.
При каждой физической встрече с заказчиком имейте в наличии флешку со всем, что вы ему уже передавали и собираетесь передать, и своё железо. Иначе в очень удобное для срыва контракта время у него пропадёт Интернет и сдохнет ноутбук. Схема крысиного кешбека: заказчик оттягивает день поставки до последнего, написанного в договоре, и в этот день у него отваливается Интернет, мигает электричество во всём здании, охрана ушла на обед, унеся ключи...
konst90
00.00.0000 00:00Первые три пункта работают и для разработки физических устройств, особенно нестандартных. Причём чисто механических - в том числе.
Dr_Faksov
00.00.0000 00:00+1Один из законов Мерфи гласит -"Создайте программу, которой сможет пользоваться даже дурак- и только дурак захочет её пользоваться!"
Wesha
00.00.0000 00:00Программистам следует регулярно писать
Как и котикам. Если не писать котиков — они лопаются!
PuerteMuerte
00.00.0000 00:00А можете сделать то, что так и не решился сделать ГГ сего рассказа, объяснить, что такое «не пИсать котиков»? Потому что остальные шутки все понятны, хоть сами шутки стиля 90-х годов, уже и не смешные совершенно, но по крайней мере, игра слов видна, а с этой вообще непонятно. Это неудачная анаграмма от слова «пастИ», что ли?
Wesha
00.00.0000 00:00Ну, если их много поить...
vtal007
00.00.0000 00:00+1я почитал. Про помидоры понятно, потому что "любить" это может быть и сексом. Старый анекдот. Про грузин еще много есть, как раз на игре смыслов (закат видел, вот такой же, но зеленый)
Про подушку - не очень понятно. Они рассчитывали, что беременность воздушно-капельным передается? Видимо это очень советский анекдот. Когда "про это" ток шептались
А "писать котиков" нарушение грамматики. В чем там юмор не очень понятно от слова "совсем"
Наверно если штуки понятны только автору шутки, с шуткой что-то не то. Анекдот всегда можно объяснить, пусть и юмор потеряется. А вот автор опуса чет постеснялся.
Про пирамиду понятно - обыгрывание сходства фамилии Маслоу и маслаkhe404
00.00.0000 00:00+1Я бы отметил, что это не совсем шутка, а скорее ирония которая основана на некоторой особенности языка.
любой объект можно: поить, кормить, пИсать, писАть, гулять, ужинать, танцевать.
UPD: а также трыжкать, жумкать ... т.е. вообще любое слогосочтание заканчивающееся на ть.
UPD: "если котиков жужумкать, то они трыжкают" звучит хоть и абсурдно но вполне возможно с точки зрения языка, при условии если глаголы жужумкать и трыжкать определены.
Поить котиков - значит создавать условия для того чтобы они пили.
пИсать котиков - значит создавать условия для того чтобы они пИсали.
Если подобных условий не создать то котики лопнут.
кмк вообще рассказ как раз о том, что уверенность в непогрешимости собственного чувства юмора может сыграть с вами злую шутку.
vtal007
00.00.0000 00:00Объект кормить? объект это неодушевленное, как кормить? кормить можно ребенка, например
Ужинать и танцевать это уже нарушения грамматики
Ужинать субъект - это оплатить ужин (кто девушку ужинает, тот ее и танцует)
Танцевать субъект - танцевать с ним.
Гулять субъект? - Я такого использования не слышал.. Собаку выгуливают или гуляют с ней. Или Вы ребенка "гуляете" ?А вот пИсать субъект. это чет уже извращенное
Если котики писать не будут, у них мочевой лопнет, а не сами котики
khe404
00.00.0000 00:00+1Сегодня я накормил принтер бумагой, а кулер напоил водой. А эти бездушные сопротивлялись как могли. Принтер бумагу есть не хотел, а потом зажевал ее и выплюнул.
Я бы сказал, что любые высказывания за рамками своей среды рождают непонимание.
Мы с вами чужие здесь и чужие друг другу, если не понимаем один одного. Как впрочем автор рассказа и окружающие.
Ирония в том и состоит чтобы совершить ошибку таким образом, что из неверно построенного предложения или слова человек мог сделать верные выводы в отношении смысла высказывания. И проведя эту работу порадоваться своей сообразительности.
vtal007
00.00.0000 00:00+1Кормить бумагой принтер - это ж метафора. в том смысле, что у него есть "Рот".. входное отверстие. Как фары у машина это как будто глаза. Но грамматически принтер не кормят, а кулер не поят. Но с ними то ладно, одушевление железок
Ну то есть есть некие устоявшиеся нарушения грамматики из анекдотов (про ужинать девушку), но для остальных глаголов это не применяют.
Как котиков писать? это умом не понять. Почему котик лопнет? это тем более не понятно (лопнет мочевой, а не котик). Видимо автор опуса очень хотел писать в этом бреду ему родились котикиkhe404
00.00.0000 00:00Когда вы котика будете кормить, вы как это будете делать ? Вот точно так же вы его пописаете. Значится лоток ему поставите.
Я и не утверждаю, что это словосочетание соответствует правилам языка, но в устной речи вы вполне можете погулять ребенка. И да это покоробит, но к непониманию не приведет. Вы не только можете ребенка погулять, но еще и ближайший парк нагуглить.
vtal007
00.00.0000 00:00Кормить котика я могу. А писать котика не могу (кушать котика еще можно...)
Понимаете, возможно с точки зрения иностранца это не очевидно. Но для кого русский родной это понятно. Что кормить кота можно, а писать кота - нет
Кормить кота можно
С ложки
Насыпав, выложив ему корм в миску
Писать котика никак нельзя. Так не говорят на русском. Может на украинском можно, может на каком-нить молдавском русском можно. Но на русском русском - нельзя
По интернету ходит шутка про посуду на столе и глаголы в зависимости от того, где именно находится объект
вы вполне можете погулять ребенка.
Выгуляю.
а про "писать ребенка" так не говорят. Как и с котамиКак я говорил выше, нарушение грамматики в анекдоте (ужинать и танцевать) не дает возможности нарушать грамматику для всех глаголов
khe404
00.00.0000 00:00Мне кажется, что вы сознательно или бессознательно подменяете понятия.
Нельзя, и не нравится.
Возможно Вас, как носителя языка, задевает какой то конкретный оборот речи и Вам он не нравится поэтому вы утверждаете что такой оборот речи невозможен или запрещен.
Гарматмику взомжонсоть етсь нуарашть у мнея, и крама даже отрицательный запрещает мне не.
Так вот, нарушать грамматику можно, порой это действительно портит и засоряет язык, и характеризует высказывающегося как малограмотного и необразованного, но далеко не всегда. И однозначно создает предпосылки к тому чтобы языком пользовались, чтобы он адаптировался под окружающие реалии и развивался.
Плохо нарушать грамматику в официальных документах, а в устной речи можно если конечно в меру.
vtal007
00.00.0000 00:00Я рассуждаю с точки зрения русского языка. Вот Вы редактор, вам принесли статью с "Гарматмику взомжонсоть етсь нуарашть у мнея, и крама даже отрицательный запрещает мне не.", Вы ее так опубликуете или отправите на доработку? или будете искать тонкий юмор в орфографических ошибках автора? Ну вот и тонкий юмор автора того опуса нахер никому не здался. Особенно на работе. Пусть дома жене "писает ребенка", а на работе лучше выражаться понятно
khe404
00.00.0000 00:00Если бы вдруг я стал редактором, то меня бы уволили раньше чем я получил бы столь творческое задание, потому что я тоже очень часто путаю здался и сдался.
А перефразируя Ваш совет: ГГ должен был встать и четко и понятно заявить: Дамы, я пошел срать в макдак, потому как сортир в нашем офисе закрыт. Ждите меня через 30 минут.
И вот тут бы носитель языка возмутился отчего это ГГ такой мужлан и на работе ведет себя столь неприлично.
Wesha
00.00.0000 00:00+2Коллега просто не понимает, что иногда юмор как раз и заключается в сознательном нарушении норм языка.
Нередко такие нарушения используются как демонстрация интеллектуального уровня "говорящего" без открытого на неё указания
— Тащ гегерал, тоби пакет!
— Не "тоби", а "Вам"!
— Мну?
— Не "мну", а "мне!"
— Так я и говОрю: тоби пакет!
WraithOW
00.00.0000 00:00Но для кого русский родной это понятно.
Хорошее знание языка обычно подразумевает как раз и способность к идеоматическое употреблению, которое может отличаться от общепринятых норм. Например, чтобы понять, что "надеть Надежду" — это не только ошибка, но и иннуендо.
vtal007
00.00.0000 00:00именно. Хорошее чувство языка позволяет предполагать, где нарушение грамматики будет смешно и забавно, а где пошло и не смешно. Как с котиками
Wesha
00.00.0000 00:00— Где вы были, Штирлиц?
— Антенну натягивал...
"Хм... Впервые слышу такое женское имя," — подумал Борман.
PanDubls
00.00.0000 00:00+1Объект - явление, предмет, на к-рый направлена какая-н. деятельность.
Когда с вами что-то делают (жмякают), то вы объект, одушевленность тут не при чём. Субъект - тот, кто осуществляет деятельность, объект - тот, с кем осуществляют деятельность.В данном случае, комический эффект достигается именно тем, что глагол, который заведомо не может иметь объекта (нельзя кого-то пИсать) используется так, как будто может, причём носителю языка в общем-то понятно, о чём идёт речь. Как уже правильно сказано, абсолютно аналогично анекдоту "тот девушку и танцует". Вы же не впадаете в ступор, слыша эту фразу, хотя очевидно, что нельзя танцевать кого-то.
Издевательство над грамматикой, так то, вообще распространенный комический приём.
vtal007
00.00.0000 00:00Нет, носителю не понятно, что и показал эксперимент автора.. Он слишком упоролся в попытке поссать
Про девушку я уже выше написал. Как анекдот это существует. Но только для двух этих глаголов. Возможно, для человека, который анекдота не слышал и анекдот будет не понятен
Но перенос нарушения грамматики на все остальные слова не выглядит понятным для других людей.. Это типа как в книге "От трех до 5-и". Для детей такая игра с грамматикой может быть комичной. От взрослого такое ерунды не ожидаютPanDubls
00.00.0000 00:00Про девушку я уже выше написал. Как анекдот это существует. Но только для двух этих глаголов. Возможно, для человека, который анекдота не слышал и анекдот будет не понятен
Нет ведь никакой абстрактной фабрики ЦентральныйАнекдотическийБанк(object), которая эмитирует шутки и присваивает им уникальные цифренно-буквенные коды, припечатывая Большой Круглой Печатью. Шутки про танцевание девушки тоже когда-то не существовало, а потом её придумал какой-то автор и, возможно, кто-то ему тогда сказал "ну что за ерунда, никто так не говорит, это лишено смысла", однако теперь она для вас звучит нормально. Звучит нормально она потому, что стала расхожей, а стала расхожей она потому, что она смешная и лаконичная. Котики для вас звучат нелепо, потому что расхожей фраза про них не стала. Не стала она расхожей, потому что шутка не смешная, а не потому что нарушает какие-то грамматические законы. Искажать грамматику как ему вздумается - право автора, а роль читателя - исключительно субъективно оценить, нравится ему получившийся оборот (и начать его воспроизводить, вводя в норму) или не нравится (и не использовать оборот в речи), но не осудить автора за искажение грамматики. Соответственно, ящщитаю, спор ни о чём, шутка про котиков так себе, но большинству читателей должно быть, понятно, что она в том, как автор оригинально сформулировал мысль, что котику не дают опорожниться и он лопается, как воздушный шарик.
vtal007
00.00.0000 00:00дык никто ж не спорит, я просто объясняю, что выверт автора опуса не был понят, потому что решил с глаголами поиграть.
А люди на работе ждут понятного общения, а не игры в угадайку (вот бы бух каждый месяц зарплату рассчитывал ток тем, кто загадки отгадает)
где-то в другой области, в другом контексте, в другом окружении (типа применении в разных ситуациях) его бы поняли. А у него 3 противРабочая обстановка. Не до игры в угадайки
Отсутствие контекста. Немногие вспомнят пошлый анекдот про девушку, ужин и танцы
Котики не лопаются, лопается мочевой пузырь (это если бы даже 2 первых пункта были бы поняты)
tyomitch
00.00.0000 00:00+2Нет ведь никакой абстрактной фабрики ЦентральныйАнекдотическийБанк(object), которая эмитирует шутки и присваивает им уникальные цифренно-буквенные коды, припечатывая Большой Круглой Печатью.
Бегите патентовать блокчейн и NFT для шуток, пока никто не опередил
Wesha
00.00.0000 00:00И ещё об ошибках
Урок в грузинской школе
— Дэты! Запомнытэ: в русском языкэ слава "тарэлька" и "вилька" пишутся бэз мягкого знака, а "сол" и "фасол" — с мягким знаком. Запомнытэ эта, дэти, патамушта панят эта невазможна!
PuerteMuerte
00.00.0000 00:00+1В данном случае, комический эффект достигается именно тем,
В данном случае комический эффект достигается лишь упорными попытками ГГ донести шутку без комического эффекта до остальных людей :)
PuerteMuerte
00.00.0000 00:00Я бы отметил, что это не совсем шутка, а скорее ирония которая основана на некоторой особенности языка.
Мне показалось, что автор подразумевал некоторую аллюзию на «Как пасти котов», сделав такой себе ещё один совет для босса, что если «не пИсать котиков», то они лопнут. Но в любом случае, фигня какая-то.
vk220
00.00.0000 00:00Просто косное использование глагола. Возможно этому даже какое-то название есть.
Слышал такое, например, по отношению к детям, мол: "Пописай его". Значит просто - своди в туалет.
Ещё пример: Воевать <кого-либо>. Военрук в колледже так говорил.
Nurked
00.00.0000 00:00+22Обидно. Захожу на Хабру, читаю самую популярную статью на сейчас.
А эта статья - перевод.
Более того, перевод какой-то сеошной фигни.
Вот вам ещё 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 дизайна.
Развивайте навыки критического мышления, чтобы решать сложные задачи программирования.
Учитесть использовать облачные платформы и сервисы для создания масштабируемых приложений.
Понимайте основы жизненного цикла разработки программного обеспечения.
Создавайте свои собственные проекты, чтобы продемонстрировать свои навыки и способности.
Никогда не прекращайте учиться и улучшать свои навыки.
mva14
00.00.0000 00:00+1В этих 40-ка советах нет достаточной рефлексии, которая может случиться после прочтения советов №№ 1, 9, 15 из этой статьи. Дело не в советах, а в пинке подумать о происходящей вокруг суете.
vvbob
00.00.0000 00:00+4Самая ценная мысль, на мой взгляд, в статье - это то что любой совет не имеет смысла, а то и вреден, без описания контекста. Отличный совет в одном контектсе, может оказаться просто ужасным в другом.
vvbob
00.00.0000 00:001. Я до сих пор многого не знаю
«В смысле ты не знаешь, что такое BGP?», «Ты что, никогда не слышал о Rust?». Едва ли не каждому доводилось выслушивать такие вопросы, пожалуй, даже слишком часто. Многие из нас любят разработку ПО именно по той причине, что мы готовы учиться всю жизнь, а в этой сфере куда ни посмотри, везде простирается панорама знаний, и ее границы расширяются с каждым днём. Из этого следует, что можно провести целые десятилетия за работой в некоторой области, и у тебя всё равно обнаружатся существенные расхождения в знаниях с человеком, который десятилетиями занимался примерно тем же самым. Чем быстрее вы придете к этой мысли, тем скорее сумеете выбраться из синдрома самозванца и начнете находить радость в самообразовании и обучении других.
Самое "приятное" когда сталкиваешься с таким вот "как, вы ничего не слышали о <нужное вставить>!!!!!!!????????" на собеседовании.
Не все догоняют что набор знаний и навыков даже у двух синьоров, работающих много лет рядом над одним проектом, может довольно сильно отличаться, и если человеку не доводилось работать с какой-либо технологией, это вовсе не означает того что он плохой специалист.
DMGarikk
00.00.0000 00:00+3«вы что не можете на доске перевернуть бинарное дерево???!!!» ©
vvbob
00.00.0000 00:00+5Ладно бинарное. Как-то присутствовал в качестве слушателя на одном собесе. Там отфутболили нормального (по моим ощущениям) синьора-лида затюкав его вопросами о внутренней реализации списков, хештаблиц и проч. При том что в общих чертах он все хорошо описал, но интервьюер зачем-то докапывался до прямо досконального знания.
Обычно человек, который занят реальной работой во все это не особо погружается (либо погружался когда-то, но уже основательно все это забыл) у него голова забита задачами более высокого порядка и в детали реализации он вникает когда стандартные инструменты либо работают как-то не так, либо не тянут текущую нагрузку, но это случается довольно редко, и хороший специалист с большим опытом, может по многу лет вообще не вникать во все это.
K0styan
00.00.0000 00:00+2*задумчиво смотрит на маркерную доску, умеющую вращаться вокруг горизонтальной оси
Faria
00.00.0000 00:00Одно из самых ужасных для меня, что я боюсь приступать к какой то серьёзной работе, даже для себя, постоянно обтягиваю и просто изучаю что то другое, оправдывая это тем что вот это выучу и работа пойдёт.
Denius
00.00.0000 00:00Программистам, как и всем людям, нужно ощущать причастность
Если человек никак не соприкасается с результатом своей работы, он начнет испытывать к ней меньше интереса. По-моему, это почти тавтология. Именно по этой причине кроссфункциональные команды так хорошо себя показывают, а DevOps получил такую популярность.
Что-то я потерялся в этом тексте. DevOps - это и есть дистанционирование работы программиста от результата. Более того, чем больше этапов, тем сильнее дистанционирование. Самая большая у меня вовлеченность была в проекте, в котором от покупки хостинга до катки в прод лежало на моих плечах. Это было самое крутое в моей работе. Именно поэтому когда на интервью попросили рассказать о продукте, о котором мне хочется рассказать, я чуть ли взахлеб рассказывал о нем, в том числе и о бизнесовой части, от которой я старался дистанционироваться, больше отдаваясь разработке. И вроде как мысль всего пункта: чем больше программист погружен в продукт, тем лучше для продукта (стартаповский подход). Но появляется DevOps - специализация на определенном этапе жизни продукта, рядом с которыми появляются админы, тестировщики, деление на фронт и бэк, в идеале еще отдельно программист и админ для БД, программист и админ для бэка (это уже корпоративный подход, притом крупных корпораций). Работа именно в топовой IT-корпорации мне была самым сильным и печальным испытанием, поскольку видеть результат своей работы приходилось не так и часто.
Dr_Faksov
00.00.0000 00:00Тут можно гадать, что именно имел в виду автор.
Но можно написать код, который будет брать файл с данными, обрабатывать его по определённому алгоритму и записывать в другой файл. А можно взять из файла результаты анализов и поискать в них всевозможные опасности и признаки заболеваний, о которых написать в другом файле.
Где-то в сети есть замечательный рассказ про японский орбитальный телескоп, вернее про создание его системы ориентации и стабилизации. Которая создавалась не самыми худшими инженерами и программистами. И которая, после вывода его на орбиту, раскрутила в попытках остановить телескоп до скоростей, разорвавших его центробежными силами. Вот там код писался по принципу "возьми из файла". Людям просто не сказали, что именно они делают. Что значат те цифры, которые они используют.
Другой классный пример - европейская марсианская миссия. Когда в ходе посадки высотомер стал глючить, и выдавать в соседних отсчётах (примерно 5 раз в секунду) значения, отличающиеся от предыдущего на километры в обе стороны, то программа управления посадочным двигателем спокойно использовала их.
Самое интересное, что посадочный модуль делали не дураки. И отказ высотомера был предусмотрен. В техзадании так и написали "при отсутствии показаний высоты с основного высотомера переключится на резервный". Как написали - так и запрограммировали.
И еще там был высотомер мягкой посадки. На который нужно было переключится на высоте 500 метров. В программе так и написали "если высота = 500 метров то переключить высотомеры". И писали программы посадки отнюдь не фрилансеры.
В результате всего этого посадочный модуль окончательно погасил скорость на высоте нескольких метров ниже уровня почвы.
maslyaev
00.00.0000 00:00Думай об ограничениях. Любой механизм и любая технология работают в своей области применимости, а при выходе за неё становятся или неэффективны, или ломаются. Инженер отличается от теоретика тем, что привык уделять особое внимание ограничениям. С точки зрения теоретика может быть очень интересно, сводится ли NP к P, но инженер скажент, что в вопросе нет смысла, если вычислительной мощности Вселенной не хватит как для NP, так и для P.
eldog
00.00.0000 00:00Фраза из моего опыта:
"С точки зрения разработчика эта система написана, скажем прямо, чудовищно. Но она поставляет хлеб с маслом на стол компании уже 20 лет. Я буду её улучшать, но нет - я не смею её критиковать".
Freybjorn
00.00.0000 00:00На счёт второго пункта очень согласен, но добавлю, что продумать всё до конца никогда не возможно (имхо, что называется), однако да: даже если ты знаешь, что что-то слегка не так, лучше начать делать хоть как-то, о чём, как я вижу, тут уже успели поспорить в комментариях и, возможно, в процессе уже понять, что оно тебе и не очень нужно было в общей структуре, когда всё есть перед глазами, можно понять, что можно сделать ещё лучше, как-то перетасовать и всё получится прямо совсем красиво, без каких-то заморочек, над которыми ты изначально ломал голову и тратил время, сидя над теорией. Без теории нет практики и наоборот, безусловно, но.. Всему нужно знать меру, начинать с чего-то нужно, так что..
Kiever1
00.00.0000 00:00Не понял фразу:
Советы я даю с позиции человека, который: ценит рабочие продукты выше, чем конкретные инструменты;
Какие "рабочие продукты" и какие "конкретные инструменты"?
shimarulin
00.00.0000 00:00Еще наблюдение: Чем выше уровень разработчика, тем проще его код с равной функциональностью.
gybson_63
Не стоит приступать к реализации того, что не придумано до конца.
Сначала сделай как изначально придумал.
В проекте должна быть цифра N. Любая задача, предполагающая больше времени, чем N, должна быть разбита на подзадачи.
Собеседование позволяет просто проверить, что заявленное в резюме верно. Больше, чем из резюме, не узнаете.
Краткие ежедневные митинги по делу и профессионально - хорошее начало дня.
DMGarikk
в таком случае можно никогда не начать делать задачу, а бесконечно планировать, а конкурент уже выкатит mvp без половины функций и отожмет всех потенциальных клиентов
конечно это все обсуждаемо и не всегда применимо, но само по себе правило живьем я увидел только на нынешней работе и то только потому что закрытие задачи зависит от согласованного ТЗ и даже если вообще ничего не делаешь — нельзя начинать раньше — тупо не оплатят (или не согласуют или кардинально поменяют задачу)
в других компаниях, я бывало начинал делать задачу заранее чтобы к моменту когда согласуют — было понимание как оно будет работать уже по факту
OneManStudio
Задача или подзадача это кратковременная сущность. Вы же говорите о проекте в целом, что его нельзя сделать потому что невозможно продумать до конца. А вот начинать задачи просто потому что надо и ничего не планируя - такая себе затея.
BlackSCORPION
Иногда чтобы стало возможно продумать надо начинать делать. Если невозможно продумать, не возможно понять, это недостаток информации. Когда начинаешь делать эта информация появляется.
Freybjorn
Мы спорим о терминах
Соглашусь, вроде как, с большинством: да, общий план должен быть – это, как мне кажется, очевидно, но планировать и планировать, постоянно спотыкаясь о что-то, потому что в набросках так или иначе что-то с чем-то скорее всего не будет стыковаться.. Лучше всё же с чего-то, да начать и уже затем потихоньку, конечно же не дотягивая до дедлайнов работать в "ищи ошибки"
Chaos_Optima
С rnd не работает вообще. В большинстве случаев сначало пишется потом анализируется перепродумывается и переписывается и так по кругу.
druidvav
ну куда уж формошлепам до рнд, нужно же продумать заранее. а то что споткнешься обо что-то, о какие-то проблемы с продуманной концепцией или ограничения внешних зависимостей или вообще чем угодно — не подумаем. Каждый судит со своего опыта.
gybson_63
Можно быть скромнее и браться за менее амбициозные задачи :) Я не настаиваю на абсолюте, в бизнесе всегда приходится балансировать. Но вот так по-человечески, как творческой единице, лучше сначала придумать. Можно упростить немного. Не начинать задач с открытым финалом.
druidvav
я бы вообще ничего не сделал, если бы брался только за менее амбициозные задачи. невозможно вырасти как спец занимаясь только в безопасной зоне.
acsent1
А как же agile? Там же сама идеология не предполагает полного понимания.
Придумал чуть-чуть. Сделал чуть-чуть. Посмотрел, что нужно еще и тд по кругу
gybson_63
А как смотреть что нужно еще?
vkni
С учётом того, что «программа — это максимально детализированное ТЗ», программирование неправильно чуть более, чем целиком!!! :-)
DarthPadla
N, я так понимаю, вы предлагаете разбивать на |,\ и |?
gybson_63
Я не предлагаю делить N. Вы из Питера чтоль?
softi
Сначала не понял, а потом кааак понял... :)
anwender95
Можете, пожалуйста, объяснить для тех, кто в танке?
sanapad
Питер "славится" своими расчленёнками даже от самых, казалось бы, безобидных людей вроде условной "пенсионерки, убившей мужа, расчленившей его и скинувшей остатки в Неву".
Отсюда и мемы про Питер вида: "Как я рад, как я рад, что покинул Расчленинград!"
Andrey_Solomatin
Вроде врать в резюме не считается пороком, оно нужно больше для пробития HR слоя.
pbatanov
Вот эту мысль, честно говоря, не понял совсем. Следует ли из этого, что собеседование как этап избыточно, если есть другой (доверенный) источник, подтверждающий достоверность резюме?
Я лично кучу раз узнавал на собеседовании гораздо больше, чем заявлено в резюме
gybson_63
Если опыт работы соответствует резюме, то скорее всего никаких сюрпризов не будет. В среднем, на прежнем месте работы, у человека был такой же наниматель, как и вы. Это больше про техническую часть, конечно. Специалист по персоналу может сказать как человек поведет себя в коллективе, конфликтен ли, есть лидерские качества и все такое. Но это совсем другое образование и другая специальность, далекая от технарей. И я таких вообще пока не особо видел =)
pbatanov
Ну "не узнаете нового" и "не будет сюрпризов" - это все-таки немного разные утверждения, не находите? Резюме может быть банально недостаточно детальным, человек не указал там например, что работает с Х, а нам это может быть важно и мы спросим (и окажется он умеет).
gybson_63
Я исхожу из нормального хода событий, при котором на резюме без важных Х вы не отвечаете.
pbatanov
Для разных грейдов может быть важен разный набор Х, поэтому можем и ответить. + иногда доучиваем\обучаем с нуля по месту. поэтому факт знания Х может быть несущественнен с точки зрения собеседовать или нет, но как имеющийся навык может выделить человека среди других кандидатов
AVSDoom
Например что? То что человек может в лайфкодин или зазубрил 10ок ответов на базовые вопросы?
Все фейлы на собесах это скорей неумении их проходить, а не реальные знания
PuerteMuerte
Человек, который зазубрил 10к ответов на базовые вопросы, и при этом не умеет программировать в реальной жизни — это такой гипотетический случай, вероятность встретить который неотличима от нуля. Мне за четверть века работы в ИТ такие люди встречались только как контр-аргумент в спорах, почему на собеседовании якобы не нужно просить собеседуемого показать свои профессиональные навыки :)
AVSDoom
Вы не правы, сейчас все курсы "программистов" готовят именно таких "специалистов" натаскивая их именно на прохождение собесов и вранье, а не на глубокие знания, ну и опыт таким вот "программистам" никто не заложит. И 25 лет работы в ит, это типа аргумент? Можно все это время цвет у кнопак менять...
PuerteMuerte
Это же так не работает :) Можно или уметь программировать, или не уметь. Зазубрить наизусть способы решения задачек так, чтобы уметь их применять там, где спрашивают — это надо быть тоже гением, только фотографической памяти.
Типа аргумент. Не зря же сначала спрашивают про стаж, а уже потом погружаются в подробности.
AVSDoom
Всмысле не работает? Вы на собесе чего проверяете? Способность программировать чтоли? Интересно как?) Самое приближенное к реальности хто тестовые зпдания но они сейчас не в почете. Ну и основы можно и вызубрить (паттерны, принципы, типы данных, солид, другой мусор что там сейчас популярно спрашивать?) Есть куча сайтов посвещенных именно на натаскивание решения типовых задач и в реале такой разраб с нуля ничего путного не сделает т.к. опыта у него нет. Это как со строителем - умение держать молоток в руке еще делает тебя строителем. С другой стороны интроверты которые впринципе не любят обшаться и темболее доказывать кому-то свои компетенции, вобшем в людях надо разбираться и находить подходы, чтобы среди мусорных разработчиков найти достойных, если это вообще нужно компании конечно...
PuerteMuerte
Если на должности джуна — да, именно способность программировать. Потому что всё остальное как раз легко освоить и по ходу дела. Если на должности миддла, то в зависимости от "послужного списка". Если и так можно посмотреть, в каких проектах чувак участвовал и что там делал, фаззбазз у него можно не спрашивать, но если это только на словах, то да, прошу и попрограммировать малёхо.
Я, например, как раз не стесняюсь, даю тестовые задания, небольшие, которые опытный решит минут за пятнадцать, джун — в зависимости от умения гуглить и соображать.
Бывают и такие, но честно скажу, стоимость ошибки "не взять толкового интраверта", она многократно ниже стоимости ошибки "взять бестолкового кого-нибудь". И если я пропущу бриллиант только потому, что он стесняется донести свои профессиональные навыки, ну, переживу как-нибудь. Это лучше, чем если я понесу убытки на проекте потому, что не проверил навыки и взял балбеса.
VictorNS
Согласен, и даже более того и на мидла и даже и на сеньора, есль появились хоть малейшие подозрения. Потому что приходят именно такие - натасканные на прохождение собеседование и сливаются при решение простейшей задачи. Именно простейшей, никаких заданий на день и на пару часов. Только на 15 минут.
AVX
Кому как. Мне больше нравится раз в неделю, в понедельник. Обсудили, что было на прошлой неделе, что сделано, что нет, какие проблемы и т.д., обсудили планы, первоочередные задачи, что-то ещё. И хватит.
Может, у меня в какой-то день вообще нет вдохновения доделать какую-то штуку, и я займусь чем-то вроде изучения накопившихся инструкций, новых приказов по предприятию, новых уязвимостей, может наконец дочитаю эту долбаную инструкцию по пожарной безопасности... А в другой день переключусь на рабочие задачи. Считаю, специалист должен иметь определённый диапазон времени, которым он может сам распоряжаться, когда что ему делать, главное - вот задача, вот сроки - и не надо каждый день спрашивать "нучотам?".
dim111
И только так и будет покрываться техдолг. Потому что без запаса времени никто не даст проводить рефакторинг, писать метрики, документацию и тесты и вот это все. Бизнесу это не нужно. Им фичи нужны и еще вчера.
У инженеров всегда должно быть свободное время делать то что они считают важным. А не бизнес. Иначе будет беда в итоге. Слишком разное виденье проектов без понимания зачем некоторые вещи надо делать у людей без технических знаний.
По моему опыты где то 1/3 времени должны быть свободными у людей без навязывания задач.
А то сначала ставят по 5 новых фичей в неделю в задачи. А потом удивляются почему от кода кровь из глаз идет.
petuhov_k
Это если ты один на проекте и пилишь крупные задачи.
Если в команде несколько человек, и задачи разбиты на 1-3 дневные, то джун может застрять на какой-то мелочи и узнаешь ты об этом, только через неделю. Митинги нужны каждый день, но ровно в формате (done/in progress/obstacles) и проходить за 5-10 минут. Плохо когда митинги скатываются в обсуждение технических деталей и вся команда вынуждена слушать.
S_WW
Практически все проекты, которые я делал в своей жизни, я начинал не продумав их до конца. Достаточно понять, что это принципиально реализуемо.
gybson_63
А в чем проблема продумать до конца?
S_WW
Проблема во времени. Как тут уже справедливо заметили - если всё продумывать до конца, то реализации можно и не дождаться.
gybson_63
Все сделанное, сначала придумано. Это неизбежный процесс. Ни секунды не потеряете, если сначала придумаете.
markmariner
Придумать айфон "до конца" -- это придумать первый айфон или четырнадцатый?
Или можно ли приступать к разработке экрана для айфона, пока ещё не придуманы все приложения полностью?
gybson_63
Когда дело касается физических объектов, то их то уж совершенно точно невозможно запустить в производство не спроектировав до конца. Нужно подробное описание и процесса и результата.
dim111
Сразу видно человека не работавшего в производстве.
Простой пример можно посмотреть сколько раз спайсХ переделывала двигатели прежде чем запустить в серийное производство.
Скажу больше есть прототипы в любой крупной компании которые никогда в серию не запускались. А так и остались в 1-3 экземплярах
YourSupervisor
Вот по поводу кратких митингов, не соглашусь. Они наоборот отвлекают от задумок и мыслей и способствуют замедлению процесса ведущему к положительному результату, т.к. превращаются зачастую не в краткие встречи, а длинные и незаконченные.