Америчка
Видео об Америке
Видео о карьере в ИТ
Купи Будаму пиво
My blog in English
Твитер Будама
- Here's an excellent documentary by @lgparfenov about the year 2022 in Russia and Ukraine. This video allows you to… twitter.com/i/web/status/1… 3 weeks ago
- I'll never go to the Roger Waters concert latimes.com/entertainment-… 1 month ago
- RT @McFaul: The killing in Ukraine must stop. Mr. Putin, end your invasion of Ukraine. Stop killing Ukrainians and Russians for no reas… 1 month ago
- Just ordered a brand new MacBook Pro M2 16" apple.com 2 months ago
- Today, I was organizing books. Created a shelf with the books that I either authored or co-authored. And here's one… twitter.com/i/web/status/1… 4 months ago
Америчка 
Yakov, thanks for podcast, the 1st part was cool. 🙂
2d 🙂 It was really fun to hear those discussion about DVCS vs Timemashine/Dropbox/whatever.
It looks like “starp’or” like approach. Very nice 🙂 I hope that I won’t have similar discussion w/ my teammates – I.e. convince them that DVCS is useful/pragmatic/etc.
But your interlocutor has nice “another” (against best practice) vision 😉
Спасибо за прекрасный подкаст. Когда вы собираетесь в троем , это всегда круто!
Позволю себе поделится с вами своими мыслями:
– Большие компании это здорово – корпоративная культура, бюджеты для обучения, возможность выбора проектов (не всегда, но бывает), множество опытных специалистов вокруг, карьера.
Расскажу вам, почему я не люблю большие компании. Мне пощастливилось устроится в компанию, в которой работаю сейчас – это не большая компания около 30 чел., как PM веду 3 проекта. На ключевом проекте за пол года работы мне удалось внедрить Scrum в полном объеме, с нуля. В отличие от Code & Fix который был ранее, результат позитивный и значительный – довольные программисты (им дают спокойно работать, а не грузят 10ю сверхважными тасками каждый день), а самое главное – счастливый клиент, ему больше не нужно контролировать каждый наш шаг – пообещали полностью работающий инкремент (вместо частично работающего но частого экскремента, как раньше) – сдали его в срок. Клиент занимается бизнесом, увеличивает продажи, придумывает новые фичи и богатеет. Тоесть я своей работой приношу реальную прибыль. НО для крупной компании я никто, у меня всего пол года опыта на позиции PM’а, значит я ничего не знаю и не умею. И Corporate HR’у совершенно плевать, что у меня в сумме 5+ лет управленческого опыта и 8+ в общем, с его точки зрения – это совершенно не релевантно. Крупная компания хочет соответствия формальным требованиям, ей не важно, что я не безразличный человек, увлеченный и фанатичный при выполнении поставленной задачи. Тот же пример с лучшим программистом на моём проекте. Это увлеченный программированием, человек который беспокоится о проекте и живёт тем, что-бы сделать его лучше. До прихода в нашу комапнию он имел несколько не успешных собеседований в крупных компаниях. Да он не идеален и не спец. по теоретической части (что конечно плохо), НО это человек у которого горят глаза, который работает от не от сих-до-сих, а до победы, постоянно учится и приносит своей работой огромную пользу. Я считаю его ключевым специалистом из 4-х работающий в комманде.
Вывод: Крупные компании почему-то не стараются набирать специалистов с правильным походом и работать с людьми, как с личностями. У них есть трафарет который они прикладывают ко всему входящему потоку без особого разбора. Соответственно относятся к этим компаниям и ребята туда попавшие, отвечая холодом на холодное отношение к себе и готовые за дополнительные $200 с легкостью поменять место работы уже через пол года (конечно не все, но тенденция есть).
– Представляю, как посмотрят в компании на молодого программиста, который скажет, что он предпочитает Git’у, Dropbox 🙂
– Cool’ность приносит деньги, поэтому она так приятна 🙂 во всяком случае мне. Например человеку со знанием JavaScript проще найти работу, чем со знанием Flex. Ограниченное знание Hibernate и Spring принесет больший успех на собеседовании, чем знание глубинных принципов работы JDBC. Слово Scrum легко продается клиенту и может работать даже вне зависимости от его реального наполнения (как плацебо). Cool’ность это PR, а про него вы прекрасно рассказывали в подкасте “Pimps Whores and other IT Resources”
Ещё раз спасибо за удовольствие слушать ваши подкасты. Надеюсь найти под ёлочкой, 31-го декабря, новогодний выпуск от Якова, прямиком из Нью Джерси!
Еще не слушал, но поддерживаю! 🙂
Привет, ребята. Спасибо за интересный подкаст. Хотел вам задать вопрос как начинающий тимлид.
В подкасте упоминалось, что вы в своей фирме хотите видеть бизнес ориентированных людей. С другой стороны, говорили о том, что хотели – бы видеть настроенных на карьеру и не равнодушных своей работе. Скажите пожалуйста: как это может сочетаться в одном работнике? Человек или бизнесмен, или технарь. Первый всегда ориентирован на СВОЙ бизнес, любая компания для него лишь ступень созданию оного. Причём, чаще всего безразлично что это будет за бизнес: букмеккерская контора, программирование или скажем выращивание ландышей. Лишь бы не нарушать закон и денег побольше. Соответственно, ему нет никакого смысла повышать свои знания выше определённого предела – денег то больше не дадут.
С другой стороны, технические люди действительно своей работой интересуются, но реализация какой то чисто гиковской вещи им гораздо важнее удобства/довольства конечного пользователя.
p.s. А может быть я ошибаюсь, если да, скажите пожалуйста в чём
Люди для которых реализация гиковской вещи гораздо важнее, чем удобство конечного пользователя просто опасны. От них желательно избавляться ибо они могут разрушить бизнес.
Конечно, программист или тимлид не может знать разные предметные области, но очень ценно если он является proactive и раньше клиента предвидит проблемы, которые могут возникнуть. Это – золотая черта характера и такие программисты всегда видны и всегда в цене.
Думаю каждый член команды должен быть proactive & self-motivated.
Из QA тоже может быть позитивный feedback.
Думаю QA ближе к клиенту чем DEV.
Качество подкастов растет. Поздравляю!
Учите людей и будут вам хорошие программисты.
Спасибо за подкаст.
Конечно разговор попахивает нафтолином, но тем не менее приятно было слушать, так как самому подобные мысли даже в голову не приходят. Будет, что завтра за обедом пообсуждать, хотя боюсь, что меня закидают помидорами, когда вместо mercurial буду предлагать dropbox, но я буду держаться до последнего 🙂
И ещё вопрос: так случилось, что моих подчинённых набирали без меня. Знания для разработки проекта с натяжкой имеются только у одного. Остальные учиться не очень хотят: предложение почитать что – либо в свободное от работы время воспринимают без энтузиазма.
У проекта сроки сжатые, бету нужно выкатить скоро и естественно отсутствие их знаний сказывается на скорости работы отрицательно.
Как можно стимулировать этих людей почитать нужные для работы вещи?
Предложил готовить семинары на 15 минут, естественно первым буду выступать я. Тимлид со своей стороны это предложение поддерживает, но товарищи не проявляют рвения, ссылаются на занятость.
Ты попал. Самое плохое, что может быть у программистов это нежелание учиться. Желательно уволить и взять других.
Уволить их, к сожалению, нельзя поскольку других нету. Работу работать тогда вообще некому будет
В подкасте была фраза Жванецкого “Лучше иметь дело с одним у которого все есть чем с десятью у которых ничего нет”. Опции не увольнять у Вас нет – эти люди не бесполезны, они вердны так как отвлекают Вас и не делают то что нужно для УСПЕШНОГО проекта. После того как они уволены у Вас три опции:
1. Уменьшить скоуп ( размер) проекта, взять одного/двух профессионалов за те же деньги что и предыдущая группа, убедить клиента что лучше работающий продукт без излишеств чем неработающий с большим количеством кнопок.
2. Набрать молодых программистов которые хотят учиться – проект будет завален все равно, но вы получите 50 % людей которые смогут работать дальше
3. Набрать дизайнеров и отбирать профессионалов, увеличивая время проекта/экономя деньги для того чтобы клиент оставался в проекте пока вы перестраиваете команду
Удачи,
Анатолий
Ситуация типическая. Советую первое время спать подольше и запасаться витаминами – скоро ты начнешь работать по 12 часов в день минимум и мало спать. И много нервничать. Держись 🙂
Скорее просто уволюсь/буду уволен отказавшись перерабатывать. Не вижу смысла покрывать организационные просчеты за счет здоровья. Поднапрячься чуть больше – да, но не более
Спасибо за замечательный подкаст. Сам подкаст появился как раз перед моей 3-х часовой поездкой, и у меня появилась возможность послушать умные мысли вместо просмотра голивудских фильмов во время поездки.
По поводу первой части, про деградацию программистов. Моя догадка такая, что еще 12 лет назад программирование еще не было такой уж престижной и высокооплачиваемой работой, как это сейчас.
Поэтому туда шли люди, которые владели огромным желанием заниматься такой деятельностью и не меньшим желанием совершенствовать свои навыки.
Сейчас, для многих программирование – это еще и непыльная работа, с хорошим заработком, которая обеспечивает хлеб и икоркой. Мы называем таких программистов коддерами.
Но, и те программисты, которые идейные. Которые в свободное время пишут языки программирования, которые учувствуют в известных опенсорс проектах, которые пишут программное обеспечение для чипов, которые потом вживляться дельфинам (бионика) .
Я думаю, что количество таких программистов не уменьшается.
А в общем, разработка ПО – это как коммунизм: с каждого по возможностям – каждому по потребностям. Разве не так? 😉
По второму пункту, на счет систем контроля версий, я считаю так: есть инструмент, в данном случае это git. Он предоставляет некоторые фичи, которые могут быть либо полезными либо бесполезными. Вот, например, как в примере Якова, два человека просто договорились не трогать файлы друг друга – в таком случае, гитхб может быть полностью заменен ДропБоксом + бекапами содержимого время от времени. Такая фича в дропбоксе есть и стоит не дорого.
Даже в ситуации, когда команда из нескольких человек сидит в одной комнате – вполне можно обойтись ДропБоксом. Но, для команды, которая состоит не только из людей, которые работают удаленно из разных стран, но и даже людей, которые работают из разных комнат в одном здании – использование системы контроля версии просто необходимо.
К слову, для решения проблемы взаимодействия программистов и блондинок дизайнеров и людей из бизнеса, есть такой замечательный бесплатный инструмент как SparkleShare ( http://sparkleshare.org/ ), который делает работу с git настолько же простой, как и с дропбоксом.
Хороший подкаст. Приятно слушать.
Отличный подкаст. Особенно интересно слушать Анатолия, почаще собирайтесь вместе! У меня одного такой баг, что подкасты приходят по два раза?
Походу баг с маятниковым эффектом, не всегда и не у всех.
Дослушал до конца. Буквально вчера тоже залил все проекты в дропбокс, чтобы синхронизировать между разными машинами и ОС. Одного боюсь – нечаянно удалю какой-то проект, и он удалится везде 😦 Насчет остального – я согласен с Виктором: “Все равно придется мержить”. Если вы имеете возможность не работать над одним файлом одновременно – то можна обойтись и дропбоксом. А если не имеете? Гит предоставит вам возможность смержить, а дропбокс нет. Ставить локи на файлы – слишком дорого для перформанса 🙂 Будам, я не понял, почему вы договорились с коллегой не трогать файлы друг друга? сложно мержить .doc файлы?
Ребята, в подкасте я пропустил несколько вещей для тех кто хотят исполизовать дропбокс или другой сервис встроенным версионным контролем (прошу прощения за незнание терминив на русском языке):
1. дропбокс заменяет файловую систему. НЕ ПРОГРАММИСТЫ (поддержка клиента, ответственные за спецификацию, итд) автоматически получают историю в ПОНЯТНОМ ВИДЕ и не грузятся изучением гита или СВНа. Документы должны быть в плоском формате (текст) и картинки, редакторы должны мониторть файловую систему
2. Для программиста вводится понятие чек-оут (патч в старой терминологии) – в зависимости от тима документ он копируется/перемещается в персональную/общую рабочую область. Преимущество – вы знаете над чем работают люди и можете учавствовать
3. Когда работа заканчивается надо делать чек-ин. У меня поверх “дропбокса” стоит СВН – ставьте любую систему контроля. Программистам нужны комментарии, роллбэк, и интеграция с контролем ошибок. Никто их не отменял, отменили только суету когда нет возможности показать/перестроить проект без полного чек-ина.
Я уверен что множество проектов симулируют подобный подход с разными вариантами индивидуального брэнчинга. В сформулированном минималистком подходе я старался добиться скорости и простоты.
С уважением,
Анатолий
Анатолий, а нельзя ли вообще избегать мержа после всего? Вы никогда не думали, что удобнее всего было бы работать таким же образом, как в гугло доках, гдк параллельные изменения можно видеть практически сразу, и даже комментарий оставить другому пользователю? Мне кажется это наиболее удобный путь, жаль, я нигде кроме гуглодокументов не видел реализацию подобного.
Как вы думаете?
Заранее спасибо за ответ,
Андрей
Это не деградация, это эволюция 🙂 Когда-то в своей статье “Жизненный цикл программиста” http://www.computer-museum.ru/histsoft/progr_cikl.htm Михаил Донской писал о тех же проблемах, о которых говорили вы. Цитирую конец статьи:
“В итоге профессия программиста меняет свой характер. Если раньше программисты знали свою программу досконально, то теперь в лучшем случае они умеют эффективно использовать то или иное инструментальное средство. Появились вообще странные на мой вкус термины как программисты на PHP и HTML.
Я пишу эту статью к своему 60-му дню рождения, возраст пенсионный, и, похоже, кончается не только мой жизненный цикл, но и жизненный цикл той творческой профессии, которой я занимался всю жизнь, и которая называлась профессией программиста. Сейчас профессия осталась, но, как и профессия шофера, она не требует творчества и особых знаний, а только определенных навыков. Программирование из искусства становится ремеслом, и я счастлив, что всю жизнь занимался программированием, пока это было так же интересно и почетно, как пилотировать самолеты во времена А. Экзюпери.”
Насчёт систем контроля версий… Трудно представить разработку более-менее крупного проекта командой программистов без систем контроля версий. В большом проекте не будешь договариваться с каждым о том, чтобы “не трогать” файлы друг друга. Яркий пример – разработка ядра Linux (используется Git). В случае с написанием книги: представьте, что каждую главу пишет несколько авторов одновременно. Не думаю, что Dropbox будет лучшим решением.
В распределённых системах контроля версий есть своя специфика. Если кому-то интересно, можете посмотреть видео на Youtube “Linus Torvalds on git” http://www.youtube.com/watch?v=4XpnKHJAok8
или с русскими субтитрами
Резюме: интересный подкаст, было приятно слушать умных людей.
Жаль, что нельзя редактировать свои сообщения 😦 Я бы убрал линки на видео, а то они странным образом подгружаются (часть подгружается, часть – нет). Видео Торвальдса с русскими субтитрами состоит из 8 частей (они находятся на youtube без проблем).
Требует и творчества, и знаний. То что вы описываете – если убрать дизайн, архитектуру, юзабилити, предметную область и проч. из работы.
Там да, там и получится водопроводчик.
Мы используем Vault на фирме. Я дополнительно использую mercurial на рабочей машине как аналог Time Machine. Мержить автоматически не получается, мержим при необходимости руками.
Яков, что бы ты посоветовал мне. 🙂 Мне 33 года. Пол года назад заинтересовался Java, ранее осваивал html, css и т.п. Живу на Дальнем Востоке России. Никаких тренингов по Java здесь никто не проводит, поэтому приходится учиться самостоятельно на codecademy.com, по твоей книге и т.п.
У меня учился человек из Хабаровска. Сегодня мир маленький, особенно если знаешь английский язык.
Добрый день, Яков! Недавно мне переслали ссылку на http://americhka.us. Интересно и познавательно, спасибо! Записывайтесь чаще!
Слушаю в течении месяца в обратном порядке, сейчас остановился на #293 Техническая поддержка. Тут речь шла в том числе о сайте с сериалами. Не знаю актуально ли, но хочу посоветовать следующий бесплатный сайт, посвященный профессионально переведенным сериалам http://www.lostfilm.tv.
Яков, очень интересный у вас получился выпуск, но позвольте мне не согласиться с Анатолием. Практически во всем.
Во-первых, мне понятна и близка его тяга к проверенным технологиям, но проблема тут в том, что меняются не технологии, а задачи. Он скорее всего крут во Flex и сможет быстро набросать форму с кнопками чем если делать ее тупо в html, но сейчас уже никому не нужна форма с кнопками – если необходимо вносить что-то в базу, то наверняка у заказчика уже есть windows-клиенты, erp-формочки и автоматизации, и тот же толстый flex. Основная проблема будущего – это то что этой информации слишком много и надо как-то ее визуализировать, накручивать дополнительную обработку на сервере, делать боссу управление через ipad и т.п. Самый, наверно, наглядный пример это системы для биржевой торговли – в 90-х каждая домохозяйка хотела торговать и скринсейвер со стикерами был на каждом компьютере; потом появились терминалы чтобы отслеживать сотни позиций и следить за торгами, сейчас же это никому не нужно, потому что основной объем идет через HFT и вся разработка заключается в просчитывании алгоритма в Excel и отдельной оптимизации по скорости. Большие терминалы нужны теперь только тем, кто планирует с большим горизонтом и данные уже нужны не текущее мельтешение, а тенденции, направления, циклы и т.п. на годы назад и вперед.
Поэтому можно всем рассказывать, что среду TurboPascal можно быстро написать только c TurboVision, но никому уже не нужен TurboPascal.
А по поводу version control – это очень забавно слышать, что “У нас есть люди со среднем образованием, поэтому git говно и нужен dropbox с _плагином для eclipse_”. Я очень советую посмотреть
http://nvie.com/posts/a-successful-git-branching-model/
и тулзу для этого – https://github.com/nvie/gitflow
Там очень подробно рассказывается про то, как изолировать feature и зачем это нужно. Добавить сборку всех веток feature/* на сервере CI несложная задача. И установить для QA привилегии (или vote) для merge собранной ветки в develop.
Тут надо понимать что основа git это не децентрализация ради децентрализации, а ветки. И в случае Будама было изначально неправильно договариваться о том чтобы не коммитить в одну ветку. Надо было просто для своих правок сделать ветку chapter1 например и потом для этой ветки сделать rebase (относительно основной) и merge.
Алексей,
Ты, наверное, прав, как и все опытные пользователи git. Я почитаю то, что ты предлагаешь. А пока ответь мне на вопрос (это вопрос ко всем) – мне нужно заменить электро шнур в гриле, но если головка одного шурупа обычная , крестовая, другая головка необычная – плоский паз с выпуклостью посредине, как показано на этом фото: https://americhka.files.wordpress.com/2012/12/photo-44.jpg.
Как мне открутить этот шуруп?
тут нужны специальные apple-овские отвертки
Такая специальная эппловская отвертка готовится за 1 минуту из обычной шлицевой. Как вариант, можно выкрутить “утконосами” (плоскогубцами с тонкими губками).
Зачем так сложно? Нужен кусочек стали, ножовка по металу (чтобы сделать в нём пропил посредине – получится что-то вроде буквы П) и пласкогубцы для того, чтобы было удобнее провернуть шуруп с помощью этого кусочка метала в виде буквы П. На все случаи жизни отвёрток не купишь 😉 По этому поводу есть такая шутка: слесарю нужно только два инструмента – зубило и молоток ))))
Если я знаю гит, то я и знаток по отверткам? Тонко 🙂
Это похоже для специнструмента – я бы сделал из обычной отвертки, сделав пропил
Хотя если шнур перетерся, то мне кажется можно вырезать часть и соединить прямой скруткой – будет проще
Молодец, Алексей.
Это подтверждает, что ты тоже любишь самые простые решения, а не пытаться найти готовый инструмент в интернете. Когда я задал этот вопрос Толику, он сразу-же вынул электропилу и сделал надрез в обычной отвертке. А пару месяцев назад, когда мы ужинали, а масла не оказалось, то он взбил масло из сливок: http://yakovfain.com/2012/09/10/think-out-of-the-box/. Я это к тому, что когда Толик что-то предлагает, я почти уверен, что с ним нужно будет согласиться в 80% случаев. Это, возможно, будет пахнуть нафталином и нелзя будет сказать за обедом, как заметил один мальчик, но это будет работать. 🙂
Яков, привет! Встал теперь вопрос с отелем в Трех Далинах, Франция – подскажи название отеля, все что нужено ( Ski in, Ski out и камин )
Уверен ты посоветуешь ХОРОШО
Это вопрос к агенту по путешествиям. Расскажи ему когда хочешь ехать и сколько денег хочешь потратить.
Так и не понял чем вы недовольны. git не нравится, программисты не нравятся, может пришла пора выйти из бизнеса и заняться чем-нибудь попроще 🙂
Мысли первыих лиц одной компании о деградации програмистов…
А что такое вообще фарата системз? Если розобраться, это даже и не совсем компания. Это група людей, суть деятельности которых – посредничество. Взять в некой ведущей компании в оренду на некоторое время програмиста, и перепродать его время от имени уже фараты другой компании. Вот и весь бизнес. Максимум, что вы делаете, так это отдаленно отслеживаете показатели результатов сделаной роботы. О какой вы говорите деградации. А что вы сделали для для того чтобы, они не были таковыми? Правильных програмистов нужно воспитывать и выращивать в структуре своей компании. А ожидать, что вам воспитают и отдадут не таралочьке готового грамотного програмиста, который бы практически сразу с полуслова понимал бы ваши корпоративные ценности, это неправильно.
Хотя это ваше право.
Обидеть хочешь, Андрей? Не получится. Farata Systems – это IT consulting, которая не только перепродает программистов (хотя в этом ничего плохого нет – мы даем работу людям), но и продукт свой делает в еще одном стартапе: http://www.surancebay.com и за три года уже обслуживает сотни страховых агенств практически без внешних инвестиций. Так-что все не так печально 🙂
Спасибо, было интересно
В вашем подкасте прозвучало то самое слово. С тем самым презрительным оттенком. Багофиксинг.
Такова суть вещей в нашей индустрии. Есть крутые пацаны, которые хотят “разрабатывать”. Есть дураки и чурки, которые фиксят баги.
Мне ничего не остается, кроме как написать длинный ворчливый комментарий.
Багофиксинг может происходить на стадии разработки и на стадии maintain’а. Я буду говорить об обоих одновременно.
80-90% cost любого программного обеспечения уходит на maintain. Чтобы вам там не хотелось думать.
Практика крупных аутсорсинговых компаний заключается в том, что проект сдается условным начальникам и в лучшем случае тестовой группе.
Реальные проблемы, редизайн и изменения и вообще полное понимание того, что система делать должна, а чего не должна может появиться только
после того, как конечные юзеры воспользовались системой долгое время.
Тривиальный пример, Null Pointer. Конечно, его можно на месте задушить. Но можно остановиться и подумать, откуда он вообще взялся. Часто, уже
после фикса в голову приходит мысль – а как оно вообще раньше работало? Багфиксинг может привести и к изменениям в дизайне и в архитектуре. В
любом случае, багфиксинг приводит к более глубокому пониманию и того, как работает система, как работает предметная область.
Мы ведь далеко не всегда знаем все, что наш код делает?
Многие системы, особенно аусторсные, можно описать как “куча текстовых полей”. Там безусловно много логики, много валидации. Некоторые системы
такими не являются. Если вы делаете алгоритмы, те самые алгоритмы из Computer Science, то багфиксинг становится совсем нетривиальным. Или конкурентные баги.
Бывают баги в третьих системах и библиотеках. Бывают даже хардварные баги.
Багфиксинг – это огромный неиссякаемый источник эмпирического знания. Это возможность заточить все свои скиллы, действительно понять как технология работает.
Одно из основных отличий senior-разработчика – это тысячи часов, проведенные за чтением чужого кода и исправлением багов. Это стоит очень больших денег.
P.S. Один из широко известных трюков, применимых в системах контроля версий – если нашли регрессионный баг, то берете стопку ревизий и методом деления пополам
находите кто его привел за руку и где. В процессе отсеивания можно думать о небесных пряниках. Можно ли такое с Time Machine я не знаю, я не пользовался. Если можно –
то, действительно, одному контроль версий не нужен.
То есть критически важно, чтобы одни и те же люди проходили и через development и через maintain (хоть какое-то время)
Не знаю где услышалось презрение в упоминании багфиксинга с нашей стороны. Это расхожее мнение джунов, работающих из СНГ на крупных западных клиентов. Мол, нам не дают разработку, а только maintenance and bug fixing.
По моему мнению бaг фиксинг требует таланта быстро локализовать проблеммное место и быстро починить. В больших системах это очень сложно, но багфихинг было всегда одним из самых моих любимых занятьй на всех consulting projects. Быстрое нахождение и починка сложного бага всегда давало мне самое большое удовлетворение.
Лучше всего об этом написал когда-то Eric Sink, что-то типа “I love the smell of а freshly killed bug!”
Кстати, Яков, а не считаете ли вы ошибкой начинать ознакомление с проектом для новых девелоперов с багфиксинга, как принято делать во многих компаниях у нас? Как показывает практика их фиксы все равно приходится переделывать из-за какиз-нибудь возникших ньюансов.
Не считаю. А как лучше ознакомить нового девелопера с проектом? Баг фиксинг заставляет человека не только прочесть много кода приложения, но и ознакомьться с version control system, как организован processing of tickets, continuous integration, releases.
А если их фиксы надо постоянно переделывать, то нужно таких людей увольнять или переводить на другую работу.
Спасибо! Отличный подкаст
Странно было слышать, что проще использовать dropbox, timemachine чем тот же SVN. Или я уже так привы к SVN-у, но даже сам стряпая проект, и являсь единственным коммиттером – я нахожу использование SVN-а очень удобным и полезным. На цвет и вкус, конечно, системы контроля версий разные. Чаще всего работая в компании тебе просто выдают URL и название системы контроля версий и ты не рассуждая начинаешь работать 🙂
Спасибо за интересный взгляд на версии. Сам нахожусь на перепутье для проекта 3 программистов. Отдельно править файлы не получится, ибо каждый участник в любой момент может заменить/исправить другого.
Dropbox, как система контроля ревизий – вот где настоящая деградация программистов.
Зацепила дискуссия о том, что нет систем контроля версий где можно было бы делать бранчи для каждого, потом бранчи из бранчей, их мерджить месте, смотреть какие файлы сейчас изменены и над ними работают, и т.д.
На самом деле такое есть, называется IBM Synergy. Надеюсь кому поможет знание названия для продолжения поиска и определения нужна ли такая система для его задач.
Я думаю, Яков, эта серия с тремя гиками – реально лучшее, что есть в вашем подкасте.
Когда знакомишься с какой-то областью, то видишь только маленькую часть, с которой работаешь, поэтому очень ценен взгляд людей, проработавших долго в индустрии и имеющих полную картину.
Это мне нравится в ваших подкастах. Можно послушать и быстро понять, что перспективно, а что нет, куда идти, а куда не идти.
Анатолий, похоже, действительно очень толковый программист – я не понимаю треть того, что он говорит, но из того, что слышу, понимаю, что у него очень хорошее видение общей картины.
Насчет деградации программистов.
Я занимаюсь разработкой систем АСУ и у меня постоянно разноплановые задачи возникают, похожих задач мало. Плюс еще нужно разбираться с особенностями работы “железа”.
Мне нравится то, чем занимаюсь, только не вижу перспектив в этой области.
У меня была попытка перейти в чистое ИТ, когда находился в Украине, т. к. по моей теме там работы нет вообще. Осталось ощущение некоторого разочарования, которое вы подтверждаете в подкастах.
Есть много того, чего я не понимаю: зачем нужны все эти иерархии классов и исключений, в которых крайне сложно разобраться. Зачем нужны все эти системы контроля версий и куча тулзов для автоматизации работы.
В общем-то, я всегда отлично обходился без всего этого.
Понятно, что цель у бизнеса в том, чтобы сделать программирование чем-то типа собирания конструктора по инструкции из готовых кубиков, чтобы любой человек, который прошел краткосрочные курсы сразу мог быстро сесть и что-то сваять; чтобы любого программиста можно было легко заменить на другого. Это снижает время и издержки, связанные с разработкой ПО.
Как я понимаю, современное ИТ – это клепание типовых формочек и сервисов на типовых фреймворках для банков, трейдинга и учета финансовых потоков.
Мозги там не особо нужны. Для того, чтобы попасть на собеседование нужно писать правильные слова в резюме; чтобы пройти интервью нужно говорить правильные слова и уметь проходить бестолковые тесты.
Мало кого интересует, что ты из себя представляешь, как человек и что ты можешь сделать.
Фактически, в Киеве это интересовало людей только в одной американской компании.
Если раньше программисты рассчитывали траектории движения звездолетов и баллистических ракет, то клепание типовых формочек для веба, которым занимается, наверное, до 90% всех программистов сейчас – безусловно, это деградация!
Соответственно, и спрос на мастеров своего дела маленький.
Если развить эту тему дальше, то мы придем к теме упадка западной цивилизации и, в частности, США как вершины этой цивилизации. Но это тема для отдельного долгого разговора…
Что будет, когда лопнет этот интернет-пузырь, как в начале 2000-х годов?
Что будут делать все эти программисты, которые поднялись на волне роста всяких модных фреймворков? У вас есть ответы на эти вопросы?
> Что будут делать все эти программисты, которые поднялись на волне роста всяких модных фреймворков?
Учиться, учиться, и еще раз, учиться!
Как завещал великий Ленин!
Это само собой собой. Я говорю о том, что когда сдуется опять интернет-пузырь, то у миллионов программистов не будет работы. Особенно это касается стран с дорогой рабочей силой как США и Западная Европа. Да и это уже происходит.
Последние годы в Греции и Испании безработица среди выпускников ВУЗов составляет больше 50%.
Без собственной промышленности невозможно будет обеспечить этих людей работой.