Comments 116
Накипело, да?
да, моё «накипело» вылилось в статью
Мне кажется, парней с SVN вы зря осуждаете.
> Возникает встречный вопрос: Ну а зачем тогда создавалась возможность по разрешению конфликтов?
Создавалась она с благими намерениями, но сидеть и резолвить крупный файл, который автоматически не слился из двух коммитов — то ещё удовольствие. Если есть возможность договориться с другим разработчиком и избежать этого, то будет просто замечательно.
> Возникает встречный вопрос: Ну а зачем тогда создавалась возможность по разрешению конфликтов?
Создавалась она с благими намерениями, но сидеть и резолвить крупный файл, который автоматически не слился из двух коммитов — то ещё удовольствие. Если есть возможность договориться с другим разработчиком и избежать этого, то будет просто замечательно.
«10-летний стаж простого просиживания штанов» обычно у тех, кто 10-15-20 лет сидит на одном месте, не меняя работы. Встречал таких.
Люди, которые меняют работу раз в несколько лет проходят естественный отбор на собеседованиях и их уровень обычно выше старожилов. Плюс кругозор из-за работы в разных областях и с разными людьми.
Я когда-то сам развлекался, ходя на собеседования пообщаться с умными и не очень людьми :)
Люди, которые меняют работу раз в несколько лет проходят естественный отбор на собеседованиях и их уровень обычно выше старожилов. Плюс кругозор из-за работы в разных областях и с разными людьми.
Я когда-то сам развлекался, ходя на собеседования пообщаться с умными и не очень людьми :)
Собственно, у меня, как у первокура и вчерашнего школьника, встает вопрос: «Как таким не стать?»
Что надо делать? Свои проекты? Опыт? Проекты с хорошими программистами? Курсы?
Или может просто необходимо до нуля копать и рыть используемый продукт, чтобы его знать до мелочей?
Что надо делать? Свои проекты? Опыт? Проекты с хорошими программистами? Курсы?
Или может просто необходимо до нуля копать и рыть используемый продукт, чтобы его знать до мелочей?
Свой проект. А лучше свой проект в компании с хорошими программистами. Остальное приложится
Я не так давно из этого вышел. Универ я не закончил, однако программировать я начал еще за несколько лет до первого курса. На втором открывал свою веб-студию, а дальше стандартный сценарий — почувствовал вкус денег и почему-то решил, что в универе меня ничему не научат и вообще все не такие крутые, как я. Конечно, со временем это прошло, хотя о том, что отчислили я не очень жалею(по целому ряду причин). Так вот, возвращаясь непосредственно к вопросу скажу, что, имхо, тут главное — неподдельный интерес к профессии. Вам либо знакомы бессонные месяца у компа с открытой IDE\текстовым редактором и блаженство от решения задачи, либо нет. Вы либо пришли за деньгами(которых, кстати, в таком случае, с большой долей вероятности будет не так много, как вы хотели), либо потому что вы тащитесь от программирования. Вы либо постоянно учитесь и развиваетесь в этом направлении, либо нет.
Всё остальное на самом деле приложится, если голова на плечах есть. Конечно, очередного Кемпбелла из Вас с высокой долей вероятности не выдет, но ведь не это главное, верно?) И применимо это далеко не только к программированию. Просто нужно делать то, что должен делать не просто хорошо, а каждый раз пытать делать максимально хорошо, постоянно повышая собственную планку.
Если более конкретно. Курсы — лажа для неосиляторов. Вся информация на которой строятся курсы и так есть в свободном доступе(иногда за умеренную плату, которая всеравно не сравнима с платой за курсы). Сама по себе работа программиста подразумевает довольно уверенное владение навыком поиска информации, ее анализ и усвоение. Я бы даже сказал, что навык этот ключевой. Таже самая JAVA уже совсем не та, как была в мои университетские времена. Что делать? Идти на курсы, или все таки почитать интернеты и осиливать самому. Это я уже не говорю о куче смежных областей, которые приходится изучать из проекта в проект.
Свои проекты на ранних стадия по моему мнению вообще являются единственным способом обучения. Придумать проект проще простого, все мы ежедневно сталкиваемся с задачами, которые могли бы решать намного эффективней, в том числе с помощью ПО. Начинать можно с чего-то простого в духе всяких менеджеров паролей и калькуляторов. А дальше наращивать функционал пока не надоест. Как надоест — новый проект другой тематики. Лабораторные работы в универе не качать из интернета, а делать самому, несмотря на то, что 95% однокурсников пойдут по первому пути.
После того, как будет уверенность в своих силах и кажущееся понимание основ можно пойти на работу, но это довольно серьезный шаг, потому что работа может оказать совершенно противоположный ожидаемому эффект. А оценить уровень коллег на первых порах, думаю, просто невозможно. Можно найти себе «ложных авторитетов» и остаться в их болте.
Наибольшее влияние на меня, как программиста оказали именно другие программисты с которыми довелось работать. Точнее именно те, кто так же как и я любят эту работу, но намного превосходящие меня по своему уровню либо в силу большего опыта, либо интеллектуальных способностей, которые у меня, например, довольно заурядные.
Не лишним и даже очень полезным будет хотя бы на время влиться в Open-source. Во многих проектах есть сильные разработчики а коммунити не даст мержить пулл-реквесты с откровенным говном. Тратить время на ответы на вопросы на Stack Overflow тоже лишним не будет. Читать ответы тоже полезно. Общаться в «тусовке» программистов и обсуждать подходы, методологии, технологии, новинки из сферы разработки и так далее.
Эх, расписался чё-то, но надеюсь, ты прислушаешься к тому, что я написал. Если бы я это все знал раньше, наверное, я был бы намного лучше, чем есть сейчас :D
Всё остальное на самом деле приложится, если голова на плечах есть. Конечно, очередного Кемпбелла из Вас с высокой долей вероятности не выдет, но ведь не это главное, верно?) И применимо это далеко не только к программированию. Просто нужно делать то, что должен делать не просто хорошо, а каждый раз пытать делать максимально хорошо, постоянно повышая собственную планку.
Если более конкретно. Курсы — лажа для неосиляторов. Вся информация на которой строятся курсы и так есть в свободном доступе(иногда за умеренную плату, которая всеравно не сравнима с платой за курсы). Сама по себе работа программиста подразумевает довольно уверенное владение навыком поиска информации, ее анализ и усвоение. Я бы даже сказал, что навык этот ключевой. Таже самая JAVA уже совсем не та, как была в мои университетские времена. Что делать? Идти на курсы, или все таки почитать интернеты и осиливать самому. Это я уже не говорю о куче смежных областей, которые приходится изучать из проекта в проект.
Свои проекты на ранних стадия по моему мнению вообще являются единственным способом обучения. Придумать проект проще простого, все мы ежедневно сталкиваемся с задачами, которые могли бы решать намного эффективней, в том числе с помощью ПО. Начинать можно с чего-то простого в духе всяких менеджеров паролей и калькуляторов. А дальше наращивать функционал пока не надоест. Как надоест — новый проект другой тематики. Лабораторные работы в универе не качать из интернета, а делать самому, несмотря на то, что 95% однокурсников пойдут по первому пути.
После того, как будет уверенность в своих силах и кажущееся понимание основ можно пойти на работу, но это довольно серьезный шаг, потому что работа может оказать совершенно противоположный ожидаемому эффект. А оценить уровень коллег на первых порах, думаю, просто невозможно. Можно найти себе «ложных авторитетов» и остаться в их болте.
Наибольшее влияние на меня, как программиста оказали именно другие программисты с которыми довелось работать. Точнее именно те, кто так же как и я любят эту работу, но намного превосходящие меня по своему уровню либо в силу большего опыта, либо интеллектуальных способностей, которые у меня, например, довольно заурядные.
Не лишним и даже очень полезным будет хотя бы на время влиться в Open-source. Во многих проектах есть сильные разработчики а коммунити не даст мержить пулл-реквесты с откровенным говном. Тратить время на ответы на вопросы на Stack Overflow тоже лишним не будет. Читать ответы тоже полезно. Общаться в «тусовке» программистов и обсуждать подходы, методологии, технологии, новинки из сферы разработки и так далее.
Эх, расписался чё-то, но надеюсь, ты прислушаешься к тому, что я написал. Если бы я это все знал раньше, наверное, я был бы намного лучше, чем есть сейчас :D
Мой опыт немного противоположный. Если под «работой» подразумевается работа в компании или студии, она у меня не сложилась — начал с фриланса, набивая руку на мелких задачах, расширяя кругозор на этих самых задачах. Потом настал определенный период, когда отсутствие регулярного и равномерного заработка удручал (в один месяц денег могло быть много, в другом — почти ничего), поэтому решил пойти на, так скажем, очную работу. Всё, конечно, зависит от конкретной компании/студии, но опыт был, так скажем, не из приятных. Ни о каком огоньке в глазах у сотрудников речи не шло, все работали как везде — с 9 до 18, зачастую на отвали, посматривая на часы и надеясь, что отпустят пораньше. От других программистов особой радости я не нахватался — у каждого свой стиль работы, свой стиль кода и свои предпочтения в средствах, и даже вялая попытка перенять что-то от них казалась сущим адом — ну не привычно и хоть ты тресни.
Может быть, если бы я не начинал с фриланса, мне бы обычная работа не показалась чем-то неприятным, но за несколько месяцев я твердо для себя решил, что хоть с 9 до 18 в офис и отсиживать свой оклад я точно не хочу. Может в Яндексе, Гугле и других инновационных компаниях всё иначе, и там все в одном духе работают над задачами, не поглядывая на часы и не протирают штаны, но конкретно у меня был такой опыт. Лично на меня наибольшее влияние оказали не конкретные программисты, а мануалы, статьи и разборы кейсов. Мне не нравится слушать и даже смотреть на видео/в живую разборы «как надо», я больше люблю читать это и одновременно воплощать в жизнь на тестовых примерах. Про университет вообще молчу — не было в моей местности ничего, близко связанного с веб — программированием, только прикладное программирование, которое мне не интересно. Ну и беглый просмотр предметов по всем курсам не радовал — базовые знания C/C++, история операционных систем, SQL и т.д. Так что всё очень индивидуально.
Может быть, если бы я не начинал с фриланса, мне бы обычная работа не показалась чем-то неприятным, но за несколько месяцев я твердо для себя решил, что хоть с 9 до 18 в офис и отсиживать свой оклад я точно не хочу. Может в Яндексе, Гугле и других инновационных компаниях всё иначе, и там все в одном духе работают над задачами, не поглядывая на часы и не протирают штаны, но конкретно у меня был такой опыт. Лично на меня наибольшее влияние оказали не конкретные программисты, а мануалы, статьи и разборы кейсов. Мне не нравится слушать и даже смотреть на видео/в живую разборы «как надо», я больше люблю читать это и одновременно воплощать в жизнь на тестовых примерах. Про университет вообще молчу — не было в моей местности ничего, близко связанного с веб — программированием, только прикладное программирование, которое мне не интересно. Ну и беглый просмотр предметов по всем курсам не радовал — базовые знания C/C++, история операционных систем, SQL и т.д. Так что всё очень индивидуально.
Ни о каком огоньке в глазах у сотрудников речи не шло, все работали как везде — с 9 до 18, зачастую на отвали, посматривая на часы и надеясь, что отпустят пораньше.
Хм, мне интересно работать (наверное, как и большинству) :)
Но сидеть после 18 мне не интересно.
А также приветствую, когда можно уйти пораньше (у нас вообще с графиком нету проблем).
Если не интересно сидеть после 18, то вам и до 18 не интересно. Программирование само по себе не зависит от времени суток :D
Может мне круглосуточно на работе сидеть?
Нет, просто не надо тогда говорить, что вам интересно. Когда человеку интересно, он не замечает ход времени. Так, люди с фонариком под одеялом зачитываются книгами ночи напролет, дргуие точно так же играют в компьютерные игры, третьи водят автомобиль. Время как будто ускоряется в разы. Иначе это не интересно, это вас просто не бесит
UFO just landed and posted this here
Наше с Вами отличие в том, что любую работу я воспринимаю как свой проект. Со всеми вытекающими, среди которых ответственность, участность и инициатива. А книги, документацию и статьи лишь часть моей работы, которую я могу выполнять и на рабочем месте. Конечно, я вас не до конца могу понять, потому что уже несколько лет в офис не хожу. Но даже когда ходил — сидеть от звонка до звонка это что-то выше моего понимания. Как минимум стоит всё доводить до логического конца. Этим наша работа отличается от работы охранника в торговом центре.
UFO just landed and posted this here
Я не пользуюсь никаким оборудованием работодателя и место на его площадях не занимаю, поэтому лично для меня этот вопрос не очень актуален. Если бы пользовался и занмиал — делал бы спокойно на рабочем месте без угрызений совести, потому что в конечном итоге это повышает мой уровень как специалиста и более того — увеличивает время доступности меня на рабочем месте на случай каких-то авралов. Электричество у нас не такое дорогое, что бы переживать, что кто-то занимается на рабочем месте своими делами, при условии, что он выполняет свою работу. Опыт Google и работы его сотрудников над своими проектами на работе как бы намекает. Поверьте, Google не те ребята, что бы принимать убыточные с точки зрения бизнеса решения по управлению кадрами.
UFO just landed and posted this here
При поступлении на работу я имею привычку внимательно читать контракт и не подписывать его, если я с чем-то не согласен. Касательно интеллектуальной собственности особенно, потому что я стараюсь, хоть и немного, но таки участвовать в Open Source и имею до кучи свои собственные проекты + довольно часто не одну работу в один момент времени. При этом я всегда максимально открыт в этом плане перед работодателем и говорю об этом на первом же собеседовании. Никаких проблем это не вызывало, кроме одного раза, но мое строгое убеждение в том, что если в глазах работодателя это является большой проблемой — мне такой наниматель не нужен. Я искренне убежден, что я, как программист, должен производить ожидаемый от меня результат. Хотя бы не меньше, чем от меня ожидают(а еще применяю стратегию «обещай меньше — делай больше»). Если работодатель ждет от меня чего-то другого, как например владение всеми правами на все продукты, которые я разрабатываю в этот период времени я считаю его рабовладельцем, а не работодателем и нам с ним не по пути. Кстати, в таких конторах, как правило, работают именно дядьки за 30, проработавшие на одном месте 5+ лет и нередко, нигде, кроме таких мест в общем-то и не работавшие.
UFO just landed and posted this here
Ну вот мой последний контракт был с релокацией за 10к километров от дома с оплатой жилья, билетов и всяких прочих расходов, тем не менее, никаких проблем в плане согласования прав на интелектуальную собственность небыло(справедливости ради скажу, что в силу некоторых причин мы прекратили сотрудничество по окончанию испытательного срока, среди которых было мое участие в другом проекте, но это не из-за самого факта, а из-за того, что я слишком много на себя взял и слишком мало сделал, т.е не справился со своими прямыми обязанностями. Но, имхо, это тоже прекрасный опыт взаимоотношений). Работодатель всегда может ограничить Вас более четко, например, если Вы работаете в сфере гостиничного бизнеса, нет никаких проблем, в том, что бы написать, что вы не можете работать на аналогичной должности в сфере гостиничного бизнеса на протяжении Вашей работы в компании и N-месяцев\лет после. Не вижу тут никаких проблем. Такие ограничения мне понятны, но ограничения наподобие: «не можете разрабатывать собственные проекты пока работаете в компании, или писать какой-то другой код на рабочей машине» кажутся мне дикими. Что плохого в том, что я во время работы в этой компании буду работать еще в сфере вторичного рынка жилья, например. Более того, у меня уже случалось так, что мои личные наработки из собственных проектов приносили существенную пользу основной работе, экономя при этом ресурсы компании. В том числе и те наработки, которыми я занимался прямо таки на рабочем месте, более того, используя рабочую инфраструктуру. Главное здесь — ничего не скрывать в этом плане от работодателя, если нужно — просить соответствующих разрешений и т.д.
В общем, имхо, тут вопрос скорее в правильном выборе работодателя. Многие люди попросту забывают, что не только наниматель выбирает нас, но и мы его. Более того, сейчас мы находимся в намного более выгодном положении, потому что разработчиков реально нехватает, при том почти во всём мире.
У меня такое тоже было и у себя в компании я тоже стараюсь взять это под контроль, но это же не противоречит тому, что я говорю. Я бы даже сказал, что это увеличивает мою компетентность как разработчика. Личное мое убеждение в том, что ревью — одна из немногих вещей, которая позволяет нам расти на протяжении всей карьеры. Особенно, если это делается правильно и внимательно.
В общем, имхо, тут вопрос скорее в правильном выборе работодателя. Многие люди попросту забывают, что не только наниматель выбирает нас, но и мы его. Более того, сейчас мы находимся в намного более выгодном положении, потому что разработчиков реально нехватает, при том почти во всём мире.
Впрочем, почти все места, куда я собеседовался, предполагают некоторый процесс ревью и контроля статей, которые я собираюсь публиковать, кода, который я собираюсь выкладывать, и так далее. Может, специфика отрасли, не знаю.
У меня такое тоже было и у себя в компании я тоже стараюсь взять это под контроль, но это же не противоречит тому, что я говорю. Я бы даже сказал, что это увеличивает мою компетентность как разработчика. Личное мое убеждение в том, что ревью — одна из немногих вещей, которая позволяет нам расти на протяжении всей карьеры. Особенно, если это делается правильно и внимательно.
Всё же проблем с этим при решении задач на рабочем оборудовании чуть больше, чем при решении задач у себя дома. В некоторых контрактах за рубежом вообще прописывается, например, что всё, что сделано на оборудовании работодателя, по умолчанию принадлежит работодателю
Это одна из причин, почему я использую только свой ноутбук в работе. В офисе только док-станция и периферия
Я лишь скажу, что результаты работы над проектами, которыми занимаются сотрудники в те 20% времени, принадлежат гуглу… :)
Я не знал об этом и если честно, пруфы как-то не гуглятся нахрапом, буду очень признателен за пруф. Я всегда думал, что Google при определенных условиях инвестирует в или купит такой проект, но пока он им не интересен(а я думаю, что им много таких проектов просто не интересны) — делай с ним что хочешь.
Другая проблема, что поговаривают, что у сотрудников гугла, как правило просто нет времени на это)
Другая проблема, что поговаривают, что у сотрудников гугла, как правило просто нет времени на это)
Ну даже если ты не можешь делать с проектом что хочешь, если он стал интересен гуглу, то это то, о чем я говорю. :)
https://habrahabr.ru/post/309630/
https://habrahabr.ru/post/309630/
> При этом вы решили, например, посмотреть в сторону хаскеля. Когда вы это будете делать?
> За время и на оборудовании работодателя или на своих собственных ресурсах?
Подавляющее большинство программистов (и я в том числе) будут без заззрения совести это делать как получится, в том числе и в свободные фрагменты рабочего времени и на оборудовании работодателя. Подавляющее большинство работодателей (и я в том числе) ничего плохого по этому поводу не скажут, если это не сказывается негативно на основной работе. Объективно — мы все не роботы, а живые люди, и не можем, и не должны от звонка до звонка непрерывно копать траншеи. Мы все отвлекаемся, думаем, бывают непродуктивные дни и т.д. И нет никакой разницы, чем человек занят на перекурах между работой, изучением хаскеля или там болтовнёй на хабре. Первое, кстати, полезнее.
> За время и на оборудовании работодателя или на своих собственных ресурсах?
Подавляющее большинство программистов (и я в том числе) будут без заззрения совести это делать как получится, в том числе и в свободные фрагменты рабочего времени и на оборудовании работодателя. Подавляющее большинство работодателей (и я в том числе) ничего плохого по этому поводу не скажут, если это не сказывается негативно на основной работе. Объективно — мы все не роботы, а живые люди, и не можем, и не должны от звонка до звонка непрерывно копать траншеи. Мы все отвлекаемся, думаем, бывают непродуктивные дни и т.д. И нет никакой разницы, чем человек занят на перекурах между работой, изучением хаскеля или там болтовнёй на хабре. Первое, кстати, полезнее.
«Конечно, я вас не до конца могу понять, потому что уже несколько лет в офис не хожу. Но даже когда ходил — сидеть от звонка до звонка это что-то выше моего понимания.»
Возможно, для Вас это окажется новостью, но в серьёзный компаниях кое-что значат такие Трудовой кодекс РФ, СанПиН, трудовой распорядок, и прочие Законы РФ и локальные нормативные акты.
И постоянное нарушение этих норм в таких компаниях просто недопустимо, по целому ряду причин.
Я уже не говорю о том, что говорить о продуктивной работе сотрудников при постоянном их перенапряжении, вызванном регулярной переработкой, бессмысленно.
Возможно, для Вас это окажется новостью, но в серьёзный компаниях кое-что значат такие Трудовой кодекс РФ, СанПиН, трудовой распорядок, и прочие Законы РФ и локальные нормативные акты.
И постоянное нарушение этих норм в таких компаниях просто недопустимо, по целому ряду причин.
Я уже не говорю о том, что говорить о продуктивной работе сотрудников при постоянном их перенапряжении, вызванном регулярной переработкой, бессмысленно.
Перенапряжение? Нарушение норм? А вы уверены, что прочитали то, о чем я говорил выше? Какое нарушение в том, что сотрудник по своей инициативе работает столько, сколько он хочет? У меня брат работает в МЧС и девушка мед. сестра, вы пойдите им про законы и нарушения расскажите.
Не хотите работать — не работайте. Будто бы я вас заставляю, ей Богу.
И да, я работал в достаточно крупных международных компаниях, в том числе и всемирно известных, так что не надо мне рассказывать, как там работают. И работают в реально крутых компаниях не от звонка до звонка, поверьте.
Не хотите работать — не работайте. Будто бы я вас заставляю, ей Богу.
И да, я работал в достаточно крупных международных компаниях, в том числе и всемирно известных, так что не надо мне рассказывать, как там работают. И работают в реально крутых компаниях не от звонка до звонка, поверьте.
UFO just landed and posted this here
маленькая поправка, что бы быть не столь категоричным добавлю, что возможно, Вам просто > 30 лет ;)
Ну, во-первых, ничего противоположного в Вашем опыте я так и не увидел. Я прямо написал, что работа может навредить, особенно на ранних этапах. Еще хочется сказать, что работа именно в веб-студии — вообще худшее, что можно придумать. Моя первая работа была именно такой и ситуация была похожей. При том я не только не видел огня в глазах, но и ясно понимал, что даже самый «крутой» разработчик в этой конторе пишет код, который кажется ужасным даже мне — стажёру. Пробыл я там всего 3 месяца и свалил в крупную компанию, которая занимается разработкой одной из крупнейших российских торговых площадок. Там то мне начали открывать глаза на разработку и кровавый enterprise. Не скажу, что это был лучший опыт в моей жизни, но один самых важных. Под влиянием других программистов я ни в коем случае не имел ввиду какие-то видео или что-то подобное и уж тем более не имел ввиду кейсы, когда показывают «как надо». Как надо на самом деле никто не знает. Я подразумевал именно общение с коллегами, обсуждение реальных рабочих задач и их решений. И обсуждение не сверху вниз, а на равных с аргументами и здоровой дискуссией. Особо круто иметь в окружении людей с которыми можно на прогулке, или за кружкой пива обсудить программирование. ОСОБЕННО крутая вещь — код-ревью и парное программирование. Мне даже довелось познать счастье код-ревью от некоторых довольно известных разработчиков. Меня обосрали с ног до головы, но именно это сделало меня намного лучше, потому что мне не просто говорили твой код говно, сделай «вот так, так и так», а аргументированно сказали почему мой код говно и отправляли переделывать. И так происходило раз 10 подряд, пока я сам не дошел до решения которое удовлетворяло и меня самого и сообщество и бизнес.
А все остальное, что вы написали, лично для меня характеризует Вас как разработчика не очень хорошо. Но, опять таки, это просто потому, что вам, видимо не посчастливилось работать в реально классных командах, в которых есть чему и у кого поучиться. Но вот этот пункт меня аж прям расстроил:
То есть вы всерьез и до сих пор, несмотря на какой-то(видимо значительный опыт) разработки считаете что это все ненужно? Да, наверное, для создание сайтов под ключ и прочих типовых интернет-магазинов это ни к чему, но веб-программирование на этом не ограничивается. Когда перед разработчиком встают серьезные задачи он должен, как минимум иметь возможность найти серьезные решения. А они далеко не всегда лежат в той плоскости, в которой мы привыкли работать. Вот тут-то и начинаешь вспоминать всякие дифуры, линейные алгебры тер.веры и прочие матаны. Я уж не говорю о том, что даже мне за свою не очень болшую практику приходилось писать расширение на C для PHP. Попробуйте поработать в компании наподобие Rocket-Internet, или какого-нибудь крупного финтех стартапа, например, всё поймете.
А все остальное, что вы написали, лично для меня характеризует Вас как разработчика не очень хорошо. Но, опять таки, это просто потому, что вам, видимо не посчастливилось работать в реально классных командах, в которых есть чему и у кого поучиться. Но вот этот пункт меня аж прям расстроил:
просмотр предметов по всем курсам не радовал — базовые знания C/C++, история операционных систем, SQL и т.д
То есть вы всерьез и до сих пор, несмотря на какой-то(видимо значительный опыт) разработки считаете что это все ненужно? Да, наверное, для создание сайтов под ключ и прочих типовых интернет-магазинов это ни к чему, но веб-программирование на этом не ограничивается. Когда перед разработчиком встают серьезные задачи он должен, как минимум иметь возможность найти серьезные решения. А они далеко не всегда лежат в той плоскости, в которой мы привыкли работать. Вот тут-то и начинаешь вспоминать всякие дифуры, линейные алгебры тер.веры и прочие матаны. Я уж не говорю о том, что даже мне за свою не очень болшую практику приходилось писать расширение на C для PHP. Попробуйте поработать в компании наподобие Rocket-Internet, или какого-нибудь крупного финтех стартапа, например, всё поймете.
Я 8 лет на одном месте проработал.
Несколько раз пытался уволиться, но все заканчивалось звонком шефа и повышением зарплаты…
В последний раз поставил шефа перед фактом, что рабочее место новое уже найдено и ни под каким соусом не остаюсь, он согласился, но попытки вернуть не оставлял ещё несколько месяцев.
Условия были хорошие, но никакого профессионального роста не чувствовалось абсолютно, казалось что как программист я сдуваюсь.
Молодец, что нашли в себе волю покинуть зону комфорта ради дальнейшего развития!
Проводя собеседования разработчиков, я тут заметил одну интересную закономерность. Кандидата три за последний месяц было с несколькими пересекающимися характеристиками, как то:
— возраст 30 или больше
— соответственно продолжительный опыт работы, особенно на последнем месте (5 и больше лет)
— полное отсутствие понятия о современных популярных инструментах / фреймворках для своего языка (позиция php, junior / middle backend)
— диктаторского склада начальник на текущем (крайнем) месте работы, который упоминается каждый раз, когда я задавал вопрос «почему же вы использовали последние N лет свой велосипед X, когда для решения этой задачи, сообществом написано за эти N лет 100500 годных библиотек?»
В общем, прямо типаж наблюдаю: человек попал в какую-то конторку, там вроде бы тепло, начальник всё решает при помощи своего набора молотков десятилетней выдержки, учить новое не заставляет, за инициативу наказывает. И грустно это, т.к. сразу видно, что люди отстали от языка и сообщества на эти самые 5-10 лет. И самое печальное, что 30 лет, это тот возраст когда уже не так просто наверстать упущенное, разобраться в стеке, как скажем в 20. То есть мне лично слабо вериться, что если человек до 30 лет не состоялся как программист, то вряд ли он качественно повысит уже уровень когда либо.
Проводя собеседования разработчиков, я тут заметил одну интересную закономерность. Кандидата три за последний месяц было с несколькими пересекающимися характеристиками, как то:
— возраст 30 или больше
— соответственно продолжительный опыт работы, особенно на последнем месте (5 и больше лет)
— полное отсутствие понятия о современных популярных инструментах / фреймворках для своего языка (позиция php, junior / middle backend)
— диктаторского склада начальник на текущем (крайнем) месте работы, который упоминается каждый раз, когда я задавал вопрос «почему же вы использовали последние N лет свой велосипед X, когда для решения этой задачи, сообществом написано за эти N лет 100500 годных библиотек?»
В общем, прямо типаж наблюдаю: человек попал в какую-то конторку, там вроде бы тепло, начальник всё решает при помощи своего набора молотков десятилетней выдержки, учить новое не заставляет, за инициативу наказывает. И грустно это, т.к. сразу видно, что люди отстали от языка и сообщества на эти самые 5-10 лет. И самое печальное, что 30 лет, это тот возраст когда уже не так просто наверстать упущенное, разобраться в стеке, как скажем в 20. То есть мне лично слабо вериться, что если человек до 30 лет не состоялся как программист, то вряд ли он качественно повысит уже уровень когда либо.
А какой критерий для «состоялся как программист»?
А какой критерий для «состоялся как программист»?В данном контексте можно такой: «забыл про PHP, как про страшный сон» :-)
А если серьёзно, то на мой взгляд состоявшемуся программисту должно быть не суть важно какой язык или стек, он причинит проекту пользу в любом случае )))
«Причинение пользы» это пять.
Не соглашусь. Мне было пофигу(и сейчас до сих пор так и есть), какой язык или стек. Начинал с Java, перекатывался в Python, потом PHP(sic!), потом NodeJS и вот теперь опять работаю в основном на PHP(было еще баловство с С++, Ruby и Haskell, но это для общего развития просто, а не для работы). Но суть в том, что та же неважность стека до меня дошла еще до того, как я даже устроился на первую работу и тогда же я уже делал свои Laba1… LabaN на разных языках, которые нам даже не преподавали.
При этом хорошим программистом я бы себя того не назвал(возможно и нынешний я не оч. хороший программист). Я бы сказал, что эти критерии каждый определяет для себя сам и найти единую точку зрения на это вряд ли возможно. И пользу проекту хороший программист принести может далеко не всегда. Иногда проекту как бы не нужна эта польза. Трудно ее приносить, когда вокруг тебя одни просиживающие штаны дядьки, сидящие на этом рабочем месте по N-дцать лет. Такому проекту хороший программист будет скорее во вред.
Так что я думаю, что человек состоялся, как программист тогда, когда он сам для себе это решил, либо это за него решило абсолютное большинство окружающий программистов. Желательно авторитетных.
При этом хорошим программистом я бы себя того не назвал(возможно и нынешний я не оч. хороший программист). Я бы сказал, что эти критерии каждый определяет для себя сам и найти единую точку зрения на это вряд ли возможно. И пользу проекту хороший программист принести может далеко не всегда. Иногда проекту как бы не нужна эта польза. Трудно ее приносить, когда вокруг тебя одни просиживающие штаны дядьки, сидящие на этом рабочем месте по N-дцать лет. Такому проекту хороший программист будет скорее во вред.
Так что я думаю, что человек состоялся, как программист тогда, когда он сам для себе это решил, либо это за него решило абсолютное большинство окружающий программистов. Желательно авторитетных.
Иногда проекту как бы не нужна эта польза. Трудно ее приносить, когда вокруг тебя одни просиживающие штаны дядьки, сидящие на этом рабочем месте по N-дцать лет.Так это, на мой взгляд, идеальная ситуация для проверки той самой состоятельности… Тут либо конформистское поведение возмёт верх, либо профессиональная этика. Всегда есть выбор: делать как коллеги (как начальство сказало, как «быстрее») или исходя из своего представления как должно быть. Иногда эти варианты могут и совпадать, но далеко не всегда.
Так что я думаю, что человек состоялся, как программист тогда, когда он сам для себе это решилО, это ощущение обычно бывает ещё в первый год… потом, правда, у адекватных людей проходит на значительное время )
Так это, на мой взгляд, идеальная ситуация для проверки той самой состоятельности… Тут либо конформистское поведение возмёт верх, либо профессиональная этика. Всегда есть выбор: делать как коллеги (как начальство сказало, как «быстрее») или исходя из своего представления как должно быть. Иногда эти варианты могут и совпадать, но далеко не всегда.
Это тема долгой дискуссии, но я задам простой вопрос: Зачем мне работать в таком месте, когда я могу пойти туда, где коллеги будут тянуть не назад, а вперед. В таких проектах, как правило, в итоге приходится делать работу за других людей, что само собой не допустимо. Я уж не говорю о том, что такие «коллеги» скорее свяжут тебе руки, чем позволят показать преимущества нормальных подходов. Ну и последняя пуля моей аргументации в том, что тебе все-таки нужно работать в команде. С кодом, который пишут твои коллеги. Если даже ты производишь 10% кода(что очень много для серьезных проектов), то остальные 90% кода всеравно остаются говном. А тебе приходится постоянно иметь с ним дело. Трудно производить что-то хорошее, что должно взаимодействовать с говном… Даже если это удается, то конечный результат всеравно говно, пусть и с ложкой меда. Хочет ли хороший программист быть в такой ситуации — вряд ли.
О, это ощущение обычно бывает ещё в первый год… потом, правда, у адекватных людей проходит на значительное время )
Совершенно верно, спору нет. Но это никак не противоречит тому, о чем я сказал. Понятие все-таки субъективное и одних и тех же программистов разные люди оценят по-разному. Кто-то скажет, что «этот парень чертовски хорош», а кто-то скажет обратное. И каждый найдет аргументы. Многие вообще скажут, что хороший программист это программист, который решает задачи бизнеса без оговорок на то КАК он это делает и как на длинной дистанции его решения будут удовлетворять критериям бизнеса.
А насчет проходимости — тоже верно. Я вообще думаю, что это ощущение должно появляться и проходить переодически на протяжении всей карьеры. Ты как бы преодалеваешь перевал и видишь вершину. Карабкаешься на нее, а она оказывается не вершиной, а очередным перевалом. Все мы понимаем, что нет предела совершенству) Только в программировании у тебя не просто горы с перевалами, а эскалатор, который едет в обратную от твоего направления сторону и остановки в развитии тут череваты.
Зачем мне работать в таком месте, когда я могу пойти туда, где коллеги будут тянуть не назад, а вперед.
Ну, это просто утрированный случай… На практике сложно найти работу, где все коллеги будут тянуть вперёд… Точнее, в начале карьеры несложно, но чем больше опыта, тем чаще приходится самому кого-то тянуть )))
Одно дло тянуть кого-то потому, что он слабее тебя, но хочет что-то делать и совершенно другое — тянуть кого-то, чья идея просиживать штаны и цели тянуться никакой нету, разговор-то об этом.
чья идея просиживать штаны и цели тянуться никакой нету
ну, имхо, это 80% народа в любой профессии… куда ж без них?
Ну хз, я имел удовольствие работать в среде других людей и даже не на одном месте. С этими тоже доводилось, но больше 3х месяцев я в таких местах не задерживался. Мой рекорд — 5 дней работы и увольнение по собственному. Когда чувствуешь, что здесь ты попросту тратишь свое время и ты можешь значительно больше, даже если будешь тупо работать один, то какой смысл оставаться на таком месте? Лично для меня при выборе работы команда занимает одно из первых мест в списке моих требований(зарплата в этом списке почти в самом конце).
Мой рекорд — 5 дней работы и увольнение по собственному.
Всё правильно, вот для этого и нужен испытательный срок. К сожалению, лично я всегда сталкивался с тем, что работодатель всегда рассматривает его только в свою пользу, чтобы при желании выгнать тебя с позором и без объяснений причин. При этом от тебя требуют хотя бы устных гарантий, что ты после приёма на работу быстро не уволишься. А если такие гарантии не даёшь, а наоборот говоришь, что надо сначала присмотреться, то тебя просто не берут.
Кстати, забавно, но в том конкретном случае я даже при приеме на работу попросил увеличить испытательный срок до 3х месяцев(это аутсорсинговая контора, я предчувствовал с самого начала, но интерес взял верх), мотивируя тем, что надо присмотреться. Самое забавное, что потом их HR умудрилась мне звонить и угрожать, что устроит мне такие проблемы, что меня больше никуда на работу не возьмут :D
Получается что «состоялся как программист» — значит работал на одном месте меньше пяти лет, в идеале менял работу настолько часто, чтобы можно было попробовать все современные решения. С учётом скорости появления новых инструментов — не более трёх лет на одном стеке. Вот такой стремительный активный специалист. Который надолго не задержится, если в компании не будет веер самых современных технологий, что могут себе позволить не все компании.
У меня небольшой чеклист, с базовыми техническими вопросами для кандидатов. Если человек претендует на позицию backend developer, и не может описать своими словами из чего состоит http запрос, или чем отличается 400 код ответа от 500, то тут в зависимости от заявленного опыта два варианта:
— если человек вчера, условно, закончил универ, я могу допустить, что это просто junior, которому много предстоит узнать
— если передо мной 30 летний мужик, с 10 годами опыта в резюме, то похоже он не состоялся.
У первого есть шанс состоятся. У второго, имхо почти нет. Вот примерно такой смысл, вкладываю в это слово.
— если человек вчера, условно, закончил универ, я могу допустить, что это просто junior, которому много предстоит узнать
— если передо мной 30 летний мужик, с 10 годами опыта в резюме, то похоже он не состоялся.
У первого есть шанс состоятся. У второго, имхо почти нет. Вот примерно такой смысл, вкладываю в это слово.
Самое забавное в том, что если спросить серьёзных профессионалов, что самое главное для backend developer'a, никто не назовёт уметь описать http запрос своими словами или знать отличие кода 400 от кода 500.
Поделитесь списком вопросов или сценарием интервью от серьёзных профессионалов? Было бы интересно.
1. Я имею в виду не профессиональных интервьюверов, а профессиональных айтишников. Синьёров там или тим лидов.
2. Думаю вы поняли про что я: не зная, как проверить самые главные качества кандидата (да ещё частенько путаясь, какие качества главные), проверяют те, которые легче проверить. Ну это всё равно как искать ключи под фонарём, потому что там светлее.
3. Такого списка или сценария у меня нет, я давно уже не проводил собеседования массово, тем более в ИТ. Но задача такая у нас стоит сейчас, возможно список/сценарий и появится, хотя скорее это будет целая технология поиска подходящих сотрудников и список будет лишь одим из звеньев цепи, который изолированно применять будет бессмыссленно.
4. Возможно у каждой организации будет (должен быть) свой список/технология, в зависимости от её потребностей.
2. Думаю вы поняли про что я: не зная, как проверить самые главные качества кандидата (да ещё частенько путаясь, какие качества главные), проверяют те, которые легче проверить. Ну это всё равно как искать ключи под фонарём, потому что там светлее.
3. Такого списка или сценария у меня нет, я давно уже не проводил собеседования массово, тем более в ИТ. Но задача такая у нас стоит сейчас, возможно список/сценарий и появится, хотя скорее это будет целая технология поиска подходящих сотрудников и список будет лишь одим из звеньев цепи, который изолированно применять будет бессмыссленно.
4. Возможно у каждой организации будет (должен быть) свой список/технология, в зависимости от её потребностей.
Не буду говорить за всех, но что такое http, чем один статус отличается от другого и из чего он состоит я знаю(хоть и PHP-обезьяна). Просто потому что вся моя работа своидится к определнной обработке запросов и отправке ответов. И основной протокол в моем случае — http. Хотя могу и про UDP рассказать и про модель OSI если уж очень невтерпеж будет. Но незнать такой базовой вещи как http, претендуя на позицию веб-разработчика это вообще какая-то дичь для меня, если честно.
Лично я просто составлял большой список вопросов разной сложности(да, для каждого проекта свой), но никогда не задавал их все. В основном, если искал кого-то на позицию выше Junior — строготехнические вопросы я почти не задавал. ИМХО, в процессе обычной живой беседы проще понять кто перед тобой, чем по каким-то вопросам конкретных реализаций. Технические вопросы использую такие, которые требуют пусть небольших, но рассуждений и ответ на которые можно вывести даже если ты их не знаешь. Все-таки нам больше важно как человек думает, а не что он знает. С Junior-разработчиками ситуация немного другая, потому что Junior по моему мнению должен быть в активной стадии обучения, а значит и память должна быть свежее. Более того, простые технические вопросы позволяют понять, насколько человеку вообще интересно программировать и что он вообще здесь делает. Очень круто, когда некоторые из них начинают вступать в дискуссию. Но, увы, все чаще и чаще, даже на позиции Senior в последнее время ко мне приходили людю, неспособные даже рассказать, в чем отличие абстрактного класса от интерфейса, что не может не печалить…
Лично я просто составлял большой список вопросов разной сложности(да, для каждого проекта свой), но никогда не задавал их все. В основном, если искал кого-то на позицию выше Junior — строготехнические вопросы я почти не задавал. ИМХО, в процессе обычной живой беседы проще понять кто перед тобой, чем по каким-то вопросам конкретных реализаций. Технические вопросы использую такие, которые требуют пусть небольших, но рассуждений и ответ на которые можно вывести даже если ты их не знаешь. Все-таки нам больше важно как человек думает, а не что он знает. С Junior-разработчиками ситуация немного другая, потому что Junior по моему мнению должен быть в активной стадии обучения, а значит и память должна быть свежее. Более того, простые технические вопросы позволяют понять, насколько человеку вообще интересно программировать и что он вообще здесь делает. Очень круто, когда некоторые из них начинают вступать в дискуссию. Но, увы, все чаще и чаще, даже на позиции Senior в последнее время ко мне приходили людю, неспособные даже рассказать, в чем отличие абстрактного класса от интерфейса, что не может не печалить…
полное отсутствие понятия о… фреймворках для своего языка
Фреймворк если понадобится можно изучить. В чём проблема-то? Что такого критичного в знании/незнании новомодного фреймворка?
В приведённых мной случаях, проблема в том, что кругозор людей ограничен одним стеком, одним рабочим процессом и маленьким парком локальных велосипедов.
А обучаемость вещь такая — если мозг не тренировать на новом регулярно, то после 30, как я слышал, он эту способность теряет.
Изучить что-то не проблема, если ты постоянно этим занимаешься.
А обучаемость вещь такая — если мозг не тренировать на новом регулярно, то после 30, как я слышал, он эту способность теряет.
Изучить что-то не проблема, если ты постоянно этим занимаешься.
Хм… Выходит, в мои 29 переквалифицироваться из сисадмина в разработчики — задача трудновыполнимая?(
как скажем в 20
В 20 лет сложновато отстать на 10 лет.
А особенно иметь 10 лет опыта. :)
Да и новые технологии можно подтянуть, если умел пользоваться старыми. :)
Не поспоришь.
Но по факту имеем разброс когда
а). человек в 20 обладает большим кол-вом актуальных познаний и минимальным опытом их применения
б). человек с 10-летним стажем имеет неактуальные знания и ноль знаний и опыта применения актуальных
И, по моему, скромному мнению, если человек (б) сам не подтянулся за всё это время, вряд ли стоит от него ждать успехов, я сделаю ставку на более молодого, в описанном случае.
Касательно области обсуждаемых знаний, я имею в виду не новомодные фреймворки, а мажорные версии языка, и мейнстримовые для сообщества парадигмы.
Но по факту имеем разброс когда
а). человек в 20 обладает большим кол-вом актуальных познаний и минимальным опытом их применения
б). человек с 10-летним стажем имеет неактуальные знания и ноль знаний и опыта применения актуальных
И, по моему, скромному мнению, если человек (б) сам не подтянулся за всё это время, вряд ли стоит от него ждать успехов, я сделаю ставку на более молодого, в описанном случае.
Касательно области обсуждаемых знаний, я имею в виду не новомодные фреймворки, а мажорные версии языка, и мейнстримовые для сообщества парадигмы.
а) Хз, но вряд ли в вузах учат актуальным технологиям :)
Хорошо, если человек о них читал сам.
б) Неактуальные знания при желании можно обновить. Просто на самом деле не многим проектам нужно что-то, кроме LAMP (если говорить о веб).
Если результат нужен здесь и сейчас, то лучше поставить на опытного с требуемым опытом (с требуемой технологией, возможно старой версии, вряд ли новая так уж сильно уехала вперед).
Если можно подождать, то можно на умеющего думать без опыта. Опыт дело наживное.
Некоторые компании берут на стажировку / стипендию, но таких мало.
А еще бы я оценивал по собственным проектам. Но тут тоже вряд ли будут сверхтехнологии.
Я стал программистом как раз потому, что захотел реализовать свой проект. :)
Главное, чтобы человек умел думать.
Умение думать тупыми тестами IQ проверять не стоит.
Хорошо, если человек о них читал сам.
б) Неактуальные знания при желании можно обновить. Просто на самом деле не многим проектам нужно что-то, кроме LAMP (если говорить о веб).
Если результат нужен здесь и сейчас, то лучше поставить на опытного с требуемым опытом (с требуемой технологией, возможно старой версии, вряд ли новая так уж сильно уехала вперед).
Если можно подождать, то можно на умеющего думать без опыта. Опыт дело наживное.
Некоторые компании берут на стажировку / стипендию, но таких мало.
А еще бы я оценивал по собственным проектам. Но тут тоже вряд ли будут сверхтехнологии.
Я стал программистом как раз потому, что захотел реализовать свой проект. :)
Главное, чтобы человек умел думать.
Умение думать тупыми тестами IQ проверять не стоит.
В 20 лет сложновато отстать на 10 лет.
А особенно иметь 10 лет опыта. :)
Мой сын попросил у меня финансирование на приобретение первых книг по программированию как раз лет в 10. И деньги не были потрачены зря: он эти книги освоил вполне успешно.
Так что к 20-ти уже имел те самые 10 лет опыта. :)
UFO just landed and posted this here
Ну, в 10 лет ему было ещё сложно зарабатывать самостоятельно. :)
А вот где-то года через 4, если не ошибаюсь, он уже попросил меня обналичить его первые «электронные» несколько сотен долларов, полученные им за работу «по специальности». И книги уже заказывал и оплачивал сам. :)
Я был горд безмерно… :))
А вот где-то года через 4, если не ошибаюсь, он уже попросил меня обналичить его первые «электронные» несколько сотен долларов, полученные им за работу «по специальности». И книги уже заказывал и оплачивал сам. :)
Я был горд безмерно… :))
А если человек стал программистом после 30?
Я работаю столько-же. За это время появились сначала юнит тесты, потом отдельный QA отдел автоматизации тестирования, CI система, переход из cvs в git, ревью кода, использование современных БД и сервисов, миграции БД, и прочее.
Всегда есть куда развиваться, можно сменить направление внутри одного большого проекта.
Главное следить что происходит вокруг в IT области а не ограничивать себя текущими задачами.
Всегда есть куда развиваться, можно сменить направление внутри одного большого проекта.
Главное следить что происходит вокруг в IT области а не ограничивать себя текущими задачами.
Хорошо когда проект / команда развивается технологически. Это и для участников большая польза — расти оставаясь на прежнем месте. Увы, не везде такое возможно, насколько я знаю.
Развиваться технологически ради самого факта новый технологий сомнительно. Должны быть плюсы от этих технологий.
То есть, Вы хотите сказать, что если на текущем месте от человека расширения кругозора не требуется (используемый стек не меняется вот уже 10 лет), то и не стоит ему, развиваться, сомнительное занятие это? Ведь в текущей ситуации (для команды, проекта) плюсов от изученных технологий не будет.
Нет, кругозор нужно расширять, иначе мы не узнаем есть ли плюсы от новых технологий.
Но применять их нужно, если от них есть выгода. А не потому что все крутые перцы пишут на %framework_name% и на вас криво смотрят.
Но применять их нужно, если от них есть выгода. А не потому что все крутые перцы пишут на %framework_name% и на вас криво смотрят.
Боюсь, что ознакомившись чисто формально, без практики, сложно овладеть технологией настолько чтобы оценить насколько она выгодна. А заявленные вендорами плюсы технологии, это в большинстве случаев маркетинговый булшит.
В программировании, обучение без практики, имхо, даёт ничтожный результат. Можно сказать что «знаешь о технологии», но сказать что знаешь технологию, не применив её ни разу, нельзя.
Отсюда я делаю вывод, что развитие должно в себя включать и применение на практике новых инструментов. Иначе это не развитие.
В программировании, обучение без практики, имхо, даёт ничтожный результат. Можно сказать что «знаешь о технологии», но сказать что знаешь технологию, не применив её ни разу, нельзя.
Отсюда я делаю вывод, что развитие должно в себя включать и применение на практике новых инструментов. Иначе это не развитие.
заявленные вендорами плюсы технологии, это в большинстве случаев маркетинговый булшит
Именно!
Потому обязательное требование знать фреймворки — характерный симптом некомпетентности интервьюера, желающего скрыть свою некомпетентность за крутыми понтами.
Обязательное требование знать фреймворки часто обозначает необходимость общаться на одном языке с той командой, которая пилит проект, завязанный на указанный в требованиях фреймворк.
Иначе придется ждать пока человек изучит этот фреймворк. А бизнесу это не очень нужно, бизнес хочет готового специалиста.
Иначе придется ждать пока человек изучит этот фреймворк. А бизнесу это не очень нужно, бизнес хочет готового специалиста.
А заявленные вендорами плюсы технологии, это в большинстве случаев маркетинговый булшит.
А я на них не ведусь :)
Фреймворки не решают моих задач.
Тут дискуссия: https://habrahabr.ru/company/mailru/blog/308788/
Отсюда я делаю вывод, что развитие должно в себя включать и применение на практике новых инструментов.
Пускай технология созреет.
Пускай другие на ней набьют шишек, а мы посмотрим. :)
Прыгать с технологии на технологию (не версию) не стоит, если нету проблемы в текущей технологии или плюсов новой. Разве начинать новые проекты.
А также на новую технологию сложнее найти специалистов.
Почему вы не захотели сами организовать себе среду для профессионального роста, ведь ваши инициативы при таких обстоятельствах имели бы высокие шансы на реализацию?
очень важно быть выбранным в качестве руководителя проекта
Это уже проходили. Дурков нет и люди будут выбирать того, кто не будет их напрягать и чьи интересы совпадают с их интересами. Это совершенно не обязательно совпадает с интересами проекта, начальства, организации.
А вот здесь не соглашусь. Поясню на примере: знаю нескольких людей, искренне верующих, что все люди лодыри и работать не любят. Ну так вот: почему-то в командах у них (сюрприз!) сплошные лодыри, которых надо подгонять.
Я вообще суровый материалист и в эзотерическуюфигню теорию о влиянии мыслей на окружающий мир не очень верю. Но в данном конкретном случае, похоже, такие эффективные менеджеры подсознательно отсеивают увлеченных своим делом людей на собеседованиях, ибо те не вписываются в их картину мироздания.
По-моему, вы правильно интерпретировали следствие, но почему-то поставили его на место причины.
Я вообще суровый материалист и в эзотерическую
По-моему, вы правильно интерпретировали следствие, но почему-то поставили его на место причины.
Суть иллюстрации в тексте статьи хорошо объясняется эффектом Даннинга-Крюгера.
в 20 лет интересно что-то мутить и глаза горят, я сам такой был
сейчас есть более интересные дела, чем работа и каждодневное изучение того, что завтра уже устареет
в других каментах я писал, что нынешний ит на грани коллапса и скоро количество технологий будет таково, что никто толком не будет уметь пользоваться ими или точней пользоваться будут, но никто не будет понимать, как это работает вцелом
как например современный процессор или операционная система
появятся специальные люди, которые будут изучать возникшую ошибку в результате соединения готовых библиотекх и технологий в стеке, потому что те, кто пишет код не будут понимать и у них не будет времени изучать что-то новое, т.к. еще старое не осилил
быстрый рост технологий и породил это явление, когда человек не то чтобы не хочет учить новое, а у него тупо нет времени на это, потому что после 9 часов торчания в офисе надо еще час ехать домой и заниматься с семьей, пожрать и готовиться ко сну, чтобы завтра опять торчать 9 часов в офисе
— кстати наглядный пример
надо из гуглокалендаря постить записи в пейсбук
ну я знаю про их апи и решил посмотреть, нет ли библиотеки ихней и нашел в гугле
я предвидел гимор с авторизацией через ссл и так оно и случилось — 2 дня только на гугление ушло
теперь проходит, но выдает 404, хотя там тестовая консоль разработчика выдает правильный результат
и вот я имею кучу пхп файлов, плохую документацию без описаний функций библиотеки и непонятно что мне теперь с этим делать?
я вот не знаю как работает ссл, знаю что надо какой-то сертефикат, но откуда он берется в пхп — неизвестно, в мануале к библиотеке ничего не говорилось про установку сертефиката
написано только, что надо ключ создать или юзать oauth
библиотека гугла на диске занимает 24 мегабайта!!!1
что она делает? передает гет запросы и в ответ выдает джейсон и состоит из кучи разных библиотек сторонних разработчиков с гитхаба, зато ставится композером одной командой
вот как профи программист будет искать ошибку и сколько он потратит времени?
кстати насчет рс485 это не просто первый уровень отличия, там у трансивера есть вывод переключения прием/передача и работает это хоть и поверх ком порта, но есть в порт можно тупо писать и читать, то тут надо еще и управлять 3м контаком, на который повешан этот вход управления в адаптере
на днях пришли 2 адаптера усб-рс485, а я даже не знаю какой вывод там китайцы задействовали
сейчас есть более интересные дела, чем работа и каждодневное изучение того, что завтра уже устареет
в других каментах я писал, что нынешний ит на грани коллапса и скоро количество технологий будет таково, что никто толком не будет уметь пользоваться ими или точней пользоваться будут, но никто не будет понимать, как это работает вцелом
как например современный процессор или операционная система
появятся специальные люди, которые будут изучать возникшую ошибку в результате соединения готовых библиотекх и технологий в стеке, потому что те, кто пишет код не будут понимать и у них не будет времени изучать что-то новое, т.к. еще старое не осилил
быстрый рост технологий и породил это явление, когда человек не то чтобы не хочет учить новое, а у него тупо нет времени на это, потому что после 9 часов торчания в офисе надо еще час ехать домой и заниматься с семьей, пожрать и готовиться ко сну, чтобы завтра опять торчать 9 часов в офисе
— кстати наглядный пример
надо из гуглокалендаря постить записи в пейсбук
ну я знаю про их апи и решил посмотреть, нет ли библиотеки ихней и нашел в гугле
я предвидел гимор с авторизацией через ссл и так оно и случилось — 2 дня только на гугление ушло
теперь проходит, но выдает 404, хотя там тестовая консоль разработчика выдает правильный результат
и вот я имею кучу пхп файлов, плохую документацию без описаний функций библиотеки и непонятно что мне теперь с этим делать?
я вот не знаю как работает ссл, знаю что надо какой-то сертефикат, но откуда он берется в пхп — неизвестно, в мануале к библиотеке ничего не говорилось про установку сертефиката
написано только, что надо ключ создать или юзать oauth
библиотека гугла на диске занимает 24 мегабайта!!!1
что она делает? передает гет запросы и в ответ выдает джейсон и состоит из кучи разных библиотек сторонних разработчиков с гитхаба, зато ставится композером одной командой
вот как профи программист будет искать ошибку и сколько он потратит времени?
кстати насчет рс485 это не просто первый уровень отличия, там у трансивера есть вывод переключения прием/передача и работает это хоть и поверх ком порта, но есть в порт можно тупо писать и читать, то тут надо еще и управлять 3м контаком, на который повешан этот вход управления в адаптере
на днях пришли 2 адаптера усб-рс485, а я даже не знаю какой вывод там китайцы задействовали
библиотека гугла на диске занимает 24 мегабайта!!!1
Нафиг такие библиотеки:
https://habrahabr.ru/post/140581/
Они развивают псевдопрограммирование.
(по ссылке:)
Верно! А потом приходят фанаты ФП и…
объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция
Верно! А потом приходят фанаты ФП и…
ну она как бы одна, а сервисов у гугла целая куча, может быть это оправдывает ее размер?
Лень смотреть либу, но читал что это ключ к очень многим сервисам гугла, просто ее решили не дробить на кусочки. Поэтому размер в какой-то степени оправдан.
С Git/Mercurial и прочими, всё становится на свои места.
SVN… это тоже плохая черта, причём говорящяя много обо всех, кто его использует в проекте. Почему? Ну, использовать инструменты двадцатилетней свежести, когда есть толковые современные замены — это всё же показатель низкой квалификации.
SVN… это тоже плохая черта, причём говорящяя много обо всех, кто его использует в проекте. Почему? Ну, использовать инструменты двадцатилетней свежести, когда есть толковые современные замены — это всё же показатель низкой квалификации.
Широкий кругозор один из признаков хорошего инженера. Большиство негативных кейсов что вы описываете как страдают его отсутствием. Но нужно понимать, что это нужно руководителю проекта, и совсем не нужно кодеру.
Кодеру не нужно, а вот программисту нужно 100%. Все-таки хороший программист отличается от плохого в том числе тем, что может выбирать правильные инструменты для решения поставленных задач, проектировать решения так, что бы они отвечали требованиям спущенным свыше, да еще и желательно предусматривать изменяемость этих самых требований. Ну и само собой — знание предметной области. Все это требует довольно широкого кругозора.
Странно, что у Вас начальник по блату :)
Ну а зачем тогда создавалась возможность по разрешению конфликтов?
Конфликтов желательно избегать, а то одному не всегда понять, как его решить. С одной ветки пришло одно, с другой другое. :)
Я тоже, как начал более нормально работать с git-ом (до этом только умел add|commit|push|pull и он мне жутко не нравился, так как вся разработка была в одной ветке, мастер правили на сервере по живому) думал так.
Но если есть необходимость работать с тем же куском кода в один день, то лучше не вносить правки до того, как коллега не запушит свои коммиты и не даст зеленый сигнал.
Весь мир движется к сервисной модели, и software development не станет исключением. Зачем постигать EIA-422, пусть и имея в бэкграунде EIA-232, т.е. тратить время, набивать шишки подводными камнями, и в итоге положить эти знания и опыт на полку, если существуют в мире люди, собаку на нём съевшие? Включая куда там очумелые китайцы контакты завели в данной конкретной модели оборудования. Все должно сводиться к тому чтобы найти такого человека, грамотно озадачить, подписать NDA, и через полчаса у вас уже все готово. Точно так же, возможно, кто-то успешно скрестил гуглокалендарь с фейсбуком буквально вчера. Посчитайте сколько надо заплатить штатному программисту [по ставке $100/h] пока он 2 дня разбирается. Безрезультатно притом. :)
«Посчитайте сколько надо заплатить штатному программисту [по ставке $100/h] пока он 2 дня разбирается. Безрезультатно притом. :)»
я не штатный программист, я просто решаю ит вопросы разного характера при помощи софта и железа
оплата фиксированная и пока я думаю взять 500 евров, т.к. не знаю много это или мало за такую работу
мне нравится решать нестандартные вопросы, организовывать из кубиков, но вот конкретно код писать я не умею, хотя делаю это лет 20 наверное уже
я не штатный программист, я просто решаю ит вопросы разного характера при помощи софта и железа
оплата фиксированная и пока я думаю взять 500 евров, т.к. не знаю много это или мало за такую работу
мне нравится решать нестандартные вопросы, организовывать из кубиков, но вот конкретно код писать я не умею, хотя делаю это лет 20 наверное уже
> Не нужно делать проблему, когда возникает задача написать программу для обмена по UDP, а вы раньше писали только обмен по TCP протоколу.
Охохохо, мне кажется, что вы серьёзно подставились. Потому что между TCP и UDP транспортом есть небольшая, но критически важная разница в виде абстракции, которую каждый из них предлагает.
TCP — это труба из байтов. С ним всё отлично (почти), байты всегда приходят в том порядке, что отправлены и доставка гарантируется.
UDP — это негарантированная передача блобов ограниченной длины. Стоит напороться на какой-нибудь перегруженный маршрутизатор, и пакеты могут не дойти совсем. Приложение обязано быть готово к тому, что блобы придут в любом порядке, и могут не придти вообще, отправляющая сторона тоже должна быть к этому готова. Также есть куча всяких граблей вроде поддержки фрагментации пакетов в сети и MTU, которые неявно задают ограничения на передаваемый размер блоба.
Т.е. если вы пишете конечный автомат, управляемый по UDP, вы должны быть готовы к куда большему пространству подаваемых в него команд, плюс самостоятельно реализовать алгоритм переотправки застрявших на отправителе команд, итд. // да, есть библиотеки, но требования понимания, что внутри происходит это не отменяет.
Охохохо, мне кажется, что вы серьёзно подставились. Потому что между TCP и UDP транспортом есть небольшая, но критически важная разница в виде абстракции, которую каждый из них предлагает.
TCP — это труба из байтов. С ним всё отлично (почти), байты всегда приходят в том порядке, что отправлены и доставка гарантируется.
UDP — это негарантированная передача блобов ограниченной длины. Стоит напороться на какой-нибудь перегруженный маршрутизатор, и пакеты могут не дойти совсем. Приложение обязано быть готово к тому, что блобы придут в любом порядке, и могут не придти вообще, отправляющая сторона тоже должна быть к этому готова. Также есть куча всяких граблей вроде поддержки фрагментации пакетов в сети и MTU, которые неявно задают ограничения на передаваемый размер блоба.
Т.е. если вы пишете конечный автомат, управляемый по UDP, вы должны быть готовы к куда большему пространству подаваемых в него команд, плюс самостоятельно реализовать алгоритм переотправки застрявших на отправителе команд, итд. // да, есть библиотеки, но требования понимания, что внутри происходит это не отменяет.
Безусловно между TCP и UDP протоколами есть разница. НО во фразе «делать проблему» имелось в виду, что некоторые даже не знают, что обмен, используя эти протоколы, в обоих случаях осуществляется по сокету. А в этом случае, я сомневаюсь, что такие люди знают о различии протоколов.
Мне кажется, что человек, который не знает что такое сокет, менее опасен, чем человек, знающий про TCP-сокеты, и бодро фигачащий точно такую же реализацию поверх UDP со словами, «ну а шо, что то — сокет, что это — сокет, оба — сокеты». Не надо так. Не знающего человека можно научить, а вот человека с уже сложившимся паттерном мышления нужно переучивать, что сложнее.
N.B. это больше про людей, которые применяют stackowerflow-driven development, и не относится к людям, умеющим читать нормальную документацию перед использованием чего-либо.
N.B. это больше про людей, которые применяют stackowerflow-driven development, и не относится к людям, умеющим читать нормальную документацию перед использованием чего-либо.
" бодро фигачащами " и уверенными в своих знаниях без прочтения документации обычно являются студенты, начинающие программисты. Ибо меньше знаешь- крепче спишь, ведь они даже и не подозревают, что дольше будут расхлебывать последствия, чем потратив время на прочтение манов и сделав как нужно.
И да, трудно не согласиться, " опасные" они люди
И да, трудно не согласиться, " опасные" они люди
> " бодро фигачащами " и уверенными в своих знаниях без прочтения документации обычно являются студенты,
> начинающие программисты.
Эх, если бы…
> начинающие программисты.
Эх, если бы…
я сам в такого опасного человека легко превращаюсь, когда пишу что-то не относящееся к моим основным компетенциям.
Разные мелкие скрипты, которые могут мне облегчить жизнь, но не стоят вложения серьёзных усилий, или куски на ангуляре, в котором я, мягко говоря, плохо разбираюсь и неоткуда быстро взять системные знания, а задачу нужно решить.
Разные мелкие скрипты, которые могут мне облегчить жизнь, но не стоят вложения серьёзных усилий, или куски на ангуляре, в котором я, мягко говоря, плохо разбираюсь и неоткуда быстро взять системные знания, а задачу нужно решить.
байты всегда приходят в том порядке, что отправлены
Вернее: гарантирует целостность передаваемых данных даже если пакеты придут не в том порядке.
«Дальнейшее саморазвитие таких людей ограничивается знаниями и навыками, получаемыми по ходу необходимости для проекта и с курсов, оплачиваемых фирмой.»
Что тут не так? Получаешь практический опыт, ходишь на курсы?
Что тут не так? Получаешь практический опыт, ходишь на курсы?
Надо просто с начальником налаживать отношения, чтобы на работу брали квалифицированных коллег. Если это не так, то на предприятии занимаются чем-то другим, скорее всего, криминалом и надо текать оттуда, пока не влип в историю.
Sign up to leave a comment.
Квалификация коллег-программистов: ожидание и реальность