Квалификация коллег-программистов: ожидание и реальность

«Лучшие программисты не чуть-чуть лучше хороших. Они на порядок лучше по любым меркам: концептуальное мышление, скорость, изобразительность и способность находить решения. »
– Rendall E.Stross

Наверное эта цитата хорошо отображает понятие квалифицированный программист. Но в мире не всё так прекрасно. Количество лет работы программистом не всегда прямо пропорционально наличию соответствующего опыта и знаний.


Далее рассмотрим (с жизненными примерами), на что нужно обращать внимание, чтобы приблизиться к цели стать «лучшим» программистом.

Думаю, многие когда-нибудь сталкивались с ситуацией, что старшие руководители обладают не достаточной компетенцией, чтобы вести проект. Кого-то назначают на руководящую должность, потому что становится вопрос об увольнении, а людей и так не хватает, поэтому создается новая должность с более высокой зарплатой. Я считаю, что, закончив институт (то есть в 22-23 года), мало кто может похвастаться достаточным опытом, соответствующим программисту уровня senior. А чтобы руководить другими людьми, нужна широкая осведомленность в техническом плане, и, конечно, нужно обладать качествами лидера.

Когда попадаешь в коллектив, невольно начинаешь оценивать способности окружающих, в особенности старших коллег. Это бывает полезно, если выдастся возможность самому выбрать, в чьем проекте принять участие. Итак, получив руководящую должность (минуя этап становления хорошим разработчиком, то есть почти стазу после универа), кто-то может просто решить, что всё, от него более ничего не требуется в профессиональном росте, можно довольствоваться знаниями, полученными во время учебы в универе и опытом работы в 2 года, к тому же с неполной занятостью. Дальнейшее саморазвитие таких людей ограничивается знаниями и навыками, получаемыми по ходу необходимости для проекта и с курсов, оплачиваемых фирмой. Работать с такими людьми вообще никакого желания нет. Ведь в то время, как ты прокачиваешь свои скилы, руководитель неохотно что-то изучает, когда приходится. И это в лучшем случае, а то ведь «я руководитель», поэтому напрягу кого-нибудь другого, а мне пусть перескажут в двух словах, о чем там «Война и мир». А еще наверное почти в каждом коллективе есть люди типа «OK Google», поэтому зачем париться. Ведь мотивации для поддержания и повышения профессионального уровня почти не осталось: руководящую должность получил(а), денежной мотивации соответственно тоже нет, ну о профессиональном соответствии такие люди видимо вообще не задумываются. Да и не особо-то стремятся они обучать кого-то, что собственно является их обязанностью. Помню, когда еще училась в институте, знакомый (постарше меня ) сказал, что его повысили до начальника отдела (в его 25 лет). На вопрос, сколько человек у него в подчинении, он улыбнулся. Фактически в его отделе еще 2 человека, но они не его подчиненные. Через год у этого человека ситуация не особо изменилась.

Хотелось бы обратить внимание на несколько конкретных вещей, которые упускают из вида некомпетентные старшие программисты.

Нужно знать о программах, которыми пользуетесь


Надеюсь, что у всех в компаниях используются системы контроля версий. Мы используем SVN. Один из печальных фактов, что многие не знают в общих чертах, как работают системы контроля версий, чем отличаются распределенные от централизованных систем. В некоторых проектах у нас задействована работа с базами данных (используется Postgres). И вот однажды слышу от одного товарища, что Postgres используется именно для хранения коммитов. Человек даже и не подозревает, что в SVN своя структура хранения информации. Вот сказали ему, что есть команды add, ignore, commit, update и checkout и всё, на этом его знакомство с продуктом окончено. Когда нужно просто выкачать какую-то конкретную версию проекта (без истории всех фиксаций), некоторые даже и не подозревают, что есть export (однажды я наткнулась на сборище из четырех человек, решающих этот вопрос).

Но самая нелепая ситуация складывается, когда несколько человек изменяют одни и те же файлы. И как же теперь закоммитить !? И слышишь: «Как? ты тоже что-то менял в файле x.cpp и Y.cpp? Стой пока не коммить! Кто-то один сделает это, а недостающее другой добавит». Возникает встречный вопрос: Ну а зачем тогда создавалась возможность по разрешению конфликтов? Все равно, если кто-то сделал коммит, ты сначала выкачиваешь его, а потом вносишь свои изменения. Не надо думать, что система контроля версий – это просто свалка вносимых изменений, в которой происходит присвоение версии конкретному состоянию файла/проекта. Если при попытке сделать коммит возникает конфликтная ситуация, то это не значит, что вы сделали фиксацию и проблемные файлы сохранились в системе контроля версий. Нужно понимать, какие операции выполняются в рабочей копии, а какие в репозитории. Тупо выполнять операции и считать, что произошла «магия» не нужно.

Нужно иметь представление о модели OSI/ISO


Каждый хоть как-то пересекался с какими-то понятиями из сетевой модели. Вот реальная история, в которой неосведомленность и наличие не полного понимания о некоторых вещах играет злую шутку. Как-то возникла задача работы по интерфейсам RS-422. Ну а почему бы и не взяться за это, ведь работа будет с COM портом, осталось почитать об особенностях самого стандарта RS-422. И тут у меня спрашивает один из старших программистов: «Уже был опыт работы по RS422/485 ?» Отвечаю, что нет, всё равно уже работала с последовательными портами, так что разберусь. И тут я вижу удивленное лицо человека, который начинает почему-то впаривать (для ясности: у нас до этого никто не работал с RS422), что обмен будет не по последовательному порту. То есть у него вообще нет представления, что такое стандарт физического уровня и интерфейс, используемый для осуществления обмена.

Возможно, не все за свою карьеру программистом работали с Bluetooth, pipe, share memory, RS-422, Ethernet и др. Но программист должен понимать, что если он умеет работать по последовательному порту, то сможет выполнить обмен и по Bluetooth, и по RS422, но не забываем читать документацию по особенностям стандартов. Нужно различать уровни ISO/OSI. Не нужно делать проблему (паниковать), когда возникает задача написать программу для обмена по UDP, а вы раньше писали только обмен по TCP протоколу.

Писать продукт без тестов плохо


То, что не хватает людей, продукт сопровождается уже несколько лет, а писать модульные тесты с нуля займет много времени и что нет у нас таких людей – просто оправдания. Можно же писать тесты для новых фич.

Если ты сходил(а) на какие-то курсы – ты не стал(а) хорошим специалистом по этому направлению


Как уже говорилось, большую часть новых знаний fake-руководители получают из курсов, оплачиваемых предприятием. И насколько же бывают неуместны их комментарии в беседах, с которыми вроде бы пытаются блеснуть знаниями, а на самом деле не подозревают, что собеседники очень даже в теме и городить полную ересь с умным видом было не обязательно.

Конечно этот список может продолжаться, а перечислять возникающие нелепые ситуации можно довольно долго, но я не об этом. Мне кажется, что очень важно быть выбранным в качестве руководителя проекта, чтобы Вас уважали как программиста и руководителя. Если выдается свободное время, не нужно по полдня тупо сидеть в телефоне/планшете, чтобы поиграть или посмотреть сериал. Всё знать нельзя, но в той или иной мере нужно быть просвещенным в технологиях, архитектуре и др. Ведь очень глупо выглядит, когда 2-3-летний опыт работы молодых заслоняет 10-летний стаж простого просиживания штанов. Я встречала разных программистов, и эта статья относится к меньшинству из них. Но тем ни менее помните, вы должны быть(или хотя бы стремиться быть) примером для более молодого поколения.
Поделиться публикацией

Комментарии 116

    +18
    Накипело, да?
      +2
      да, моё «накипело» вылилось в статью
        +3
        Мне кажется, парней с SVN вы зря осуждаете.
        > Возникает встречный вопрос: Ну а зачем тогда создавалась возможность по разрешению конфликтов?
        Создавалась она с благими намерениями, но сидеть и резолвить крупный файл, который автоматически не слился из двух коммитов — то ещё удовольствие. Если есть возможность договориться с другим разработчиком и избежать этого, то будет просто замечательно.
      –1
      «10-летний стаж простого просиживания штанов» обычно у тех, кто 10-15-20 лет сидит на одном месте, не меняя работы. Встречал таких.
      Люди, которые меняют работу раз в несколько лет проходят естественный отбор на собеседованиях и их уровень обычно выше старожилов. Плюс кругозор из-за работы в разных областях и с разными людьми.
      Я когда-то сам развлекался, ходя на собеседования пообщаться с умными и не очень людьми :)
        +1
        У вас прямо богатейший опыт в ваши 19 лет!(судя по профилю). Прожжённый жизнью программист)
        Я когда-то сам развлекался

        И когда же это было?)
          0
          10, а не 19
            +4
            Данный тролль очень не постоянный, его возраст меняется от его настроения)
              +5
              Странно вообще всё это. Человек правильную мысль высказал, а потом находятся люди, для которых важен виртуальный возраст в профиле. По-моему, всё верно сказал насчёт динозавров на зарплате. И у нас такие были
            0
            А Ваш опыт говорит Вам о другом? Ну тогда поделитесь, а не переходите на личности.
          0
          Собственно, у меня, как у первокура и вчерашнего школьника, встает вопрос: «Как таким не стать?»
          Что надо делать? Свои проекты? Опыт? Проекты с хорошими программистами? Курсы?
          Или может просто необходимо до нуля копать и рыть используемый продукт, чтобы его знать до мелочей?
            0
            Свой проект. А лучше свой проект в компании с хорошими программистами. Остальное приложится
              +5
              Я не так давно из этого вышел. Универ я не закончил, однако программировать я начал еще за несколько лет до первого курса. На втором открывал свою веб-студию, а дальше стандартный сценарий — почувствовал вкус денег и почему-то решил, что в универе меня ничему не научат и вообще все не такие крутые, как я. Конечно, со временем это прошло, хотя о том, что отчислили я не очень жалею(по целому ряду причин). Так вот, возвращаясь непосредственно к вопросу скажу, что, имхо, тут главное — неподдельный интерес к профессии. Вам либо знакомы бессонные месяца у компа с открытой IDE\текстовым редактором и блаженство от решения задачи, либо нет. Вы либо пришли за деньгами(которых, кстати, в таком случае, с большой долей вероятности будет не так много, как вы хотели), либо потому что вы тащитесь от программирования. Вы либо постоянно учитесь и развиваетесь в этом направлении, либо нет.
              Всё остальное на самом деле приложится, если голова на плечах есть. Конечно, очередного Кемпбелла из Вас с высокой долей вероятности не выдет, но ведь не это главное, верно?) И применимо это далеко не только к программированию. Просто нужно делать то, что должен делать не просто хорошо, а каждый раз пытать делать максимально хорошо, постоянно повышая собственную планку.

              Если более конкретно. Курсы — лажа для неосиляторов. Вся информация на которой строятся курсы и так есть в свободном доступе(иногда за умеренную плату, которая всеравно не сравнима с платой за курсы). Сама по себе работа программиста подразумевает довольно уверенное владение навыком поиска информации, ее анализ и усвоение. Я бы даже сказал, что навык этот ключевой. Таже самая JAVA уже совсем не та, как была в мои университетские времена. Что делать? Идти на курсы, или все таки почитать интернеты и осиливать самому. Это я уже не говорю о куче смежных областей, которые приходится изучать из проекта в проект.
              Свои проекты на ранних стадия по моему мнению вообще являются единственным способом обучения. Придумать проект проще простого, все мы ежедневно сталкиваемся с задачами, которые могли бы решать намного эффективней, в том числе с помощью ПО. Начинать можно с чего-то простого в духе всяких менеджеров паролей и калькуляторов. А дальше наращивать функционал пока не надоест. Как надоест — новый проект другой тематики. Лабораторные работы в универе не качать из интернета, а делать самому, несмотря на то, что 95% однокурсников пойдут по первому пути.
              После того, как будет уверенность в своих силах и кажущееся понимание основ можно пойти на работу, но это довольно серьезный шаг, потому что работа может оказать совершенно противоположный ожидаемому эффект. А оценить уровень коллег на первых порах, думаю, просто невозможно. Можно найти себе «ложных авторитетов» и остаться в их болте.

              Наибольшее влияние на меня, как программиста оказали именно другие программисты с которыми довелось работать. Точнее именно те, кто так же как и я любят эту работу, но намного превосходящие меня по своему уровню либо в силу большего опыта, либо интеллектуальных способностей, которые у меня, например, довольно заурядные.

              Не лишним и даже очень полезным будет хотя бы на время влиться в Open-source. Во многих проектах есть сильные разработчики а коммунити не даст мержить пулл-реквесты с откровенным говном. Тратить время на ответы на вопросы на Stack Overflow тоже лишним не будет. Читать ответы тоже полезно. Общаться в «тусовке» программистов и обсуждать подходы, методологии, технологии, новинки из сферы разработки и так далее.

              Эх, расписался чё-то, но надеюсь, ты прислушаешься к тому, что я написал. Если бы я это все знал раньше, наверное, я был бы намного лучше, чем есть сейчас :D
                0
                Мой опыт немного противоположный. Если под «работой» подразумевается работа в компании или студии, она у меня не сложилась — начал с фриланса, набивая руку на мелких задачах, расширяя кругозор на этих самых задачах. Потом настал определенный период, когда отсутствие регулярного и равномерного заработка удручал (в один месяц денег могло быть много, в другом — почти ничего), поэтому решил пойти на, так скажем, очную работу. Всё, конечно, зависит от конкретной компании/студии, но опыт был, так скажем, не из приятных. Ни о каком огоньке в глазах у сотрудников речи не шло, все работали как везде — с 9 до 18, зачастую на отвали, посматривая на часы и надеясь, что отпустят пораньше. От других программистов особой радости я не нахватался — у каждого свой стиль работы, свой стиль кода и свои предпочтения в средствах, и даже вялая попытка перенять что-то от них казалась сущим адом — ну не привычно и хоть ты тресни.

                Может быть, если бы я не начинал с фриланса, мне бы обычная работа не показалась чем-то неприятным, но за несколько месяцев я твердо для себя решил, что хоть с 9 до 18 в офис и отсиживать свой оклад я точно не хочу. Может в Яндексе, Гугле и других инновационных компаниях всё иначе, и там все в одном духе работают над задачами, не поглядывая на часы и не протирают штаны, но конкретно у меня был такой опыт. Лично на меня наибольшее влияние оказали не конкретные программисты, а мануалы, статьи и разборы кейсов. Мне не нравится слушать и даже смотреть на видео/в живую разборы «как надо», я больше люблю читать это и одновременно воплощать в жизнь на тестовых примерах. Про университет вообще молчу — не было в моей местности ничего, близко связанного с веб — программированием, только прикладное программирование, которое мне не интересно. Ну и беглый просмотр предметов по всем курсам не радовал — базовые знания C/C++, история операционных систем, SQL и т.д. Так что всё очень индивидуально.
                  0
                  Ни о каком огоньке в глазах у сотрудников речи не шло, все работали как везде — с 9 до 18, зачастую на отвали, посматривая на часы и надеясь, что отпустят пораньше.

                  Хм, мне интересно работать (наверное, как и большинству) :)
                  Но сидеть после 18 мне не интересно.
                  А также приветствую, когда можно уйти пораньше (у нас вообще с графиком нету проблем).
                    –3
                    Если не интересно сидеть после 18, то вам и до 18 не интересно. Программирование само по себе не зависит от времени суток :D
                      +1
                      Может мне круглосуточно на работе сидеть?
                        0
                        Нет, просто не надо тогда говорить, что вам интересно. Когда человеку интересно, он не замечает ход времени. Так, люди с фонариком под одеялом зачитываются книгами ночи напролет, дргуие точно так же играют в компьютерные игры, третьи водят автомобиль. Время как будто ускоряется в разы. Иначе это не интересно, это вас просто не бесит
                        0
                        После 18 интересно сидеть дома над своими проектами или над книгами.
                          0
                          Наше с Вами отличие в том, что любую работу я воспринимаю как свой проект. Со всеми вытекающими, среди которых ответственность, участность и инициатива. А книги, документацию и статьи лишь часть моей работы, которую я могу выполнять и на рабочем месте. Конечно, я вас не до конца могу понять, потому что уже несколько лет в офис не хожу. Но даже когда ходил — сидеть от звонка до звонка это что-то выше моего понимания. Как минимум стоит всё доводить до логического конца. Этим наша работа отличается от работы охранника в торговом центре.
                            0
                            Наше с Вами отличие в том, что любую работу я воспринимаю как свой проект. Со всеми вытекающими, среди которых ответственность, участность и инициатива.

                            Не вижу различий пока что. Я тоже любую работу воспринимаю как свой проект, просто у меня может быть более одного проекта, и не за все из них мне обязательно платят деньги.

                            Ну, представьте себе, что вы работаете над анализом текстов на человеческом языке и пишете много кода на C++. Платят вам за это, в смысле. При этом вы решили, например, посмотреть в сторону хаскеля. Когда вы это будете делать? За время и на оборудовании работодателя или на своих собственных ресурсах?

                            Или вы хотите продолжить научную работу по придуманному вами критерию выбора регрессионных моделей. Это, хоть и машинное обучение, но к тому, что вы делаете на работе, едва ли относится. Когда вы это будете делать?

                            Или вы хотите почитать, почему математическая индукция невыводима в рамках теории типов второго порядка с зависимыми типами. Это вообще никакого отношения не имеет ни к анализу текстов, ни к чему, с чем вы сталкиваетесь на работе.
                              0
                              Я не пользуюсь никаким оборудованием работодателя и место на его площадях не занимаю, поэтому лично для меня этот вопрос не очень актуален. Если бы пользовался и занмиал — делал бы спокойно на рабочем месте без угрызений совести, потому что в конечном итоге это повышает мой уровень как специалиста и более того — увеличивает время доступности меня на рабочем месте на случай каких-то авралов. Электричество у нас не такое дорогое, что бы переживать, что кто-то занимается на рабочем месте своими делами, при условии, что он выполняет свою работу. Опыт Google и работы его сотрудников над своими проектами на работе как бы намекает. Поверьте, Google не те ребята, что бы принимать убыточные с точки зрения бизнеса решения по управлению кадрами.
                                0
                                Если бы пользовался и занмиал — делал бы спокойно на рабочем месте без угрызений совести

                                А зря, нужно задуматься, как минимум, об интеллектуальной собственности. Всё же проблем с этим при решении задач на рабочем оборудовании чуть больше, чем при решении задач у себя дома. В некоторых контрактах за рубежом вообще прописывается, например, что всё, что сделано на оборудовании работодателя, по умолчанию принадлежит работодателю.

                                потому что в конечном итоге это повышает мой уровень как специалиста

                                Если это нерелевантно вашей текущей работе, то работодателю это и не важно на самом деле.

                                увеличивает время доступности меня на рабочем месте на случай каких-то авралов

                                Ну тогда, действительно, стоит круглосуточно на работе сидеть, как рекомендовали выше, и даже спать там.
                                  +1
                                  При поступлении на работу я имею привычку внимательно читать контракт и не подписывать его, если я с чем-то не согласен. Касательно интеллектуальной собственности особенно, потому что я стараюсь, хоть и немного, но таки участвовать в Open Source и имею до кучи свои собственные проекты + довольно часто не одну работу в один момент времени. При этом я всегда максимально открыт в этом плане перед работодателем и говорю об этом на первом же собеседовании. Никаких проблем это не вызывало, кроме одного раза, но мое строгое убеждение в том, что если в глазах работодателя это является большой проблемой — мне такой наниматель не нужен. Я искренне убежден, что я, как программист, должен производить ожидаемый от меня результат. Хотя бы не меньше, чем от меня ожидают(а еще применяю стратегию «обещай меньше — делай больше»). Если работодатель ждет от меня чего-то другого, как например владение всеми правами на все продукты, которые я разрабатываю в этот период времени я считаю его рабовладельцем, а не работодателем и нам с ним не по пути. Кстати, в таких конторах, как правило, работают именно дядьки за 30, проработавшие на одном месте 5+ лет и нередко, нигде, кроме таких мест в общем-то и не работавшие.
                                    0
                                    Контракт — это всегда некий компромисс. Контракт может предложить вам релокацию и соответствующую рабочую визу, например, и весьма хорошую компенсацию ценой усложнения согласования прав на прочие результаты интеллектуального труда, например.

                                    Если бы речь шла о владении всеми правами на все продукты, что я разрабатываю за время работы на данного работодателя, то да, и я бы тоже на такое не согласился, но речь-то всё-таки не об этом. Поэтому, чтобы минимизировать риски и трату интеллектуальных ресурсов на совершенно неинтересные мне правовые вещи, я выбираю просто идти домой и писать интересный мне код на своей машине.

                                    Впрочем, почти все места, куда я собеседовался, предполагают некоторый процесс ревью и контроля статей, которые я собираюсь публиковать, кода, который я собираюсь выкладывать, и так далее. Может, специфика отрасли, не знаю.
                                      0
                                      Ну вот мой последний контракт был с релокацией за 10к километров от дома с оплатой жилья, билетов и всяких прочих расходов, тем не менее, никаких проблем в плане согласования прав на интелектуальную собственность небыло(справедливости ради скажу, что в силу некоторых причин мы прекратили сотрудничество по окончанию испытательного срока, среди которых было мое участие в другом проекте, но это не из-за самого факта, а из-за того, что я слишком много на себя взял и слишком мало сделал, т.е не справился со своими прямыми обязанностями. Но, имхо, это тоже прекрасный опыт взаимоотношений). Работодатель всегда может ограничить Вас более четко, например, если Вы работаете в сфере гостиничного бизнеса, нет никаких проблем, в том, что бы написать, что вы не можете работать на аналогичной должности в сфере гостиничного бизнеса на протяжении Вашей работы в компании и N-месяцев\лет после. Не вижу тут никаких проблем. Такие ограничения мне понятны, но ограничения наподобие: «не можете разрабатывать собственные проекты пока работаете в компании, или писать какой-то другой код на рабочей машине» кажутся мне дикими. Что плохого в том, что я во время работы в этой компании буду работать еще в сфере вторичного рынка жилья, например. Более того, у меня уже случалось так, что мои личные наработки из собственных проектов приносили существенную пользу основной работе, экономя при этом ресурсы компании. В том числе и те наработки, которыми я занимался прямо таки на рабочем месте, более того, используя рабочую инфраструктуру. Главное здесь — ничего не скрывать в этом плане от работодателя, если нужно — просить соответствующих разрешений и т.д.
                                      В общем, имхо, тут вопрос скорее в правильном выборе работодателя. Многие люди попросту забывают, что не только наниматель выбирает нас, но и мы его. Более того, сейчас мы находимся в намного более выгодном положении, потому что разработчиков реально нехватает, при том почти во всём мире.

                                      Впрочем, почти все места, куда я собеседовался, предполагают некоторый процесс ревью и контроля статей, которые я собираюсь публиковать, кода, который я собираюсь выкладывать, и так далее. Может, специфика отрасли, не знаю.


                                      У меня такое тоже было и у себя в компании я тоже стараюсь взять это под контроль, но это же не противоречит тому, что я говорю. Я бы даже сказал, что это увеличивает мою компетентность как разработчика. Личное мое убеждение в том, что ревью — одна из немногих вещей, которая позволяет нам расти на протяжении всей карьеры. Особенно, если это делается правильно и внимательно.
                                        0
                                        Смотря куда релоцируют, и насколько сложно туда релоцироваться. Условно, релокация в Монголию для меня будет меньшим плюсом, чем релокация в США.

                                        Такие ограничения мне понятны, но ограничения наподобие: «не можете разрабатывать собственные проекты пока работаете в компании, или писать какой-то другой код на рабочей машине» кажутся мне дикими.

                                        А мне это кажется разумным упрощением. Возможность гонять что-то своё на рабочих машинах может быть бонусом и результатом индивидуальной договорённости с начальством, но не более.

                                        Многие люди попросту забывают, что не только наниматель выбирает нас, но и мы его.

                                        Если вы хотите, например, заводить трактор, да ещё и в какое-нибудь то же США, то так как H-1B ещё поди выиграй, нужно уже заведомо ограничивать себя теми работодателями, которые имеют зарубежные (по отношению к США) офисы.

                                        Я бы даже сказал, что это увеличивает мою компетентность как разработчика. Личное мое убеждение в том, что ревью — одна из немногих вещей, которая позволяет нам расти на протяжении всей карьеры.

                                        Так если б, это ж не code review. Это просто быстренько просмотреть статью, которую вы собрались публиковать, или проект, куда вы собрались контрибьютить, на предмет проблем с интеллектуальной собственностью. Никакого фидбека по существу от отдела по контролю за интеллектуальной собственностью для вас не окажется.
                                    0
                                    Всё же проблем с этим при решении задач на рабочем оборудовании чуть больше, чем при решении задач у себя дома. В некоторых контрактах за рубежом вообще прописывается, например, что всё, что сделано на оборудовании работодателя, по умолчанию принадлежит работодателю

                                    Это одна из причин, почему я использую только свой ноутбук в работе. В офисе только док-станция и периферия

                                      0
                                      Это если ваша компания BYOD уважает.
                                    +1
                                    Я лишь скажу, что результаты работы над проектами, которыми занимаются сотрудники в те 20% времени, принадлежат гуглу… :)
                                      0
                                      Я не знал об этом и если честно, пруфы как-то не гуглятся нахрапом, буду очень признателен за пруф. Я всегда думал, что Google при определенных условиях инвестирует в или купит такой проект, но пока он им не интересен(а я думаю, что им много таких проектов просто не интересны) — делай с ним что хочешь.
                                      Другая проблема, что поговаривают, что у сотрудников гугла, как правило просто нет времени на это)
                                        0
                                        Ну даже если ты не можешь делать с проектом что хочешь, если он стал интересен гуглу, то это то, о чем я говорю. :)

                                        https://habrahabr.ru/post/309630/
                                    +1
                                    > При этом вы решили, например, посмотреть в сторону хаскеля. Когда вы это будете делать?
                                    > За время и на оборудовании работодателя или на своих собственных ресурсах?
                                    Подавляющее большинство программистов (и я в том числе) будут без заззрения совести это делать как получится, в том числе и в свободные фрагменты рабочего времени и на оборудовании работодателя. Подавляющее большинство работодателей (и я в том числе) ничего плохого по этому поводу не скажут, если это не сказывается негативно на основной работе. Объективно — мы все не роботы, а живые люди, и не можем, и не должны от звонка до звонка непрерывно копать траншеи. Мы все отвлекаемся, думаем, бывают непродуктивные дни и т.д. И нет никакой разницы, чем человек занят на перекурах между работой, изучением хаскеля или там болтовнёй на хабре. Первое, кстати, полезнее.
                                      0
                                      Подавляющее большинство программистов (и я в том числе) будут без заззрения совести это делать как получится, в том числе и в свободные фрагменты рабочего времени и на оборудовании работодателя.

                                      А если фрагментов недостаточно для должной концентрации и потока?
                                        0
                                        Если вам чего-то для чего-то недостаточно, то очевидно же, что тогда это что-то у вас не получится. И надо пробовать что-то делать как-то иначе, если вам оно вообще нужно :)
                                          0
                                          Так о чём и речь! Если на работе фрагментов недостаточно, то вполне естественно, что охота заниматься этим дома в своё личное время, например.
                                        +1
                                        Более того, бывают дни, когда отличнейший программист может не написать ни строчки кода и ничего плохого в этом тоже нет. 7 раз отрежь, один раз отмерь применимо и в нашей работе. Конечно, в разумных пределах.
                                      0
                                      «Конечно, я вас не до конца могу понять, потому что уже несколько лет в офис не хожу. Но даже когда ходил — сидеть от звонка до звонка это что-то выше моего понимания.»

                                      Возможно, для Вас это окажется новостью, но в серьёзный компаниях кое-что значат такие Трудовой кодекс РФ, СанПиН, трудовой распорядок, и прочие Законы РФ и локальные нормативные акты.
                                      И постоянное нарушение этих норм в таких компаниях просто недопустимо, по целому ряду причин.

                                      Я уже не говорю о том, что говорить о продуктивной работе сотрудников при постоянном их перенапряжении, вызванном регулярной переработкой, бессмысленно.
                                        +1
                                        Перенапряжение? Нарушение норм? А вы уверены, что прочитали то, о чем я говорил выше? Какое нарушение в том, что сотрудник по своей инициативе работает столько, сколько он хочет? У меня брат работает в МЧС и девушка мед. сестра, вы пойдите им про законы и нарушения расскажите.
                                        Не хотите работать — не работайте. Будто бы я вас заставляю, ей Богу.
                                        И да, я работал в достаточно крупных международных компаниях, в том числе и всемирно известных, так что не надо мне рассказывать, как там работают. И работают в реально крутых компаниях не от звонка до звонка, поверьте.
                                          0
                                          Не во всех странах есть настолько регулирующий вещи в пользу работника ТК, например.
                                    –2
                                    маленькая поправка, что бы быть не столь категоричным добавлю, что возможно, Вам просто > 30 лет ;)
                                    +1
                                    Ну, во-первых, ничего противоположного в Вашем опыте я так и не увидел. Я прямо написал, что работа может навредить, особенно на ранних этапах. Еще хочется сказать, что работа именно в веб-студии — вообще худшее, что можно придумать. Моя первая работа была именно такой и ситуация была похожей. При том я не только не видел огня в глазах, но и ясно понимал, что даже самый «крутой» разработчик в этой конторе пишет код, который кажется ужасным даже мне — стажёру. Пробыл я там всего 3 месяца и свалил в крупную компанию, которая занимается разработкой одной из крупнейших российских торговых площадок. Там то мне начали открывать глаза на разработку и кровавый enterprise. Не скажу, что это был лучший опыт в моей жизни, но один самых важных. Под влиянием других программистов я ни в коем случае не имел ввиду какие-то видео или что-то подобное и уж тем более не имел ввиду кейсы, когда показывают «как надо». Как надо на самом деле никто не знает. Я подразумевал именно общение с коллегами, обсуждение реальных рабочих задач и их решений. И обсуждение не сверху вниз, а на равных с аргументами и здоровой дискуссией. Особо круто иметь в окружении людей с которыми можно на прогулке, или за кружкой пива обсудить программирование. ОСОБЕННО крутая вещь — код-ревью и парное программирование. Мне даже довелось познать счастье код-ревью от некоторых довольно известных разработчиков. Меня обосрали с ног до головы, но именно это сделало меня намного лучше, потому что мне не просто говорили твой код говно, сделай «вот так, так и так», а аргументированно сказали почему мой код говно и отправляли переделывать. И так происходило раз 10 подряд, пока я сам не дошел до решения которое удовлетворяло и меня самого и сообщество и бизнес.

                                    А все остальное, что вы написали, лично для меня характеризует Вас как разработчика не очень хорошо. Но, опять таки, это просто потому, что вам, видимо не посчастливилось работать в реально классных командах, в которых есть чему и у кого поучиться. Но вот этот пункт меня аж прям расстроил:
                                    просмотр предметов по всем курсам не радовал — базовые знания C/C++, история операционных систем, SQL и т.д


                                    То есть вы всерьез и до сих пор, несмотря на какой-то(видимо значительный опыт) разработки считаете что это все ненужно? Да, наверное, для создание сайтов под ключ и прочих типовых интернет-магазинов это ни к чему, но веб-программирование на этом не ограничивается. Когда перед разработчиком встают серьезные задачи он должен, как минимум иметь возможность найти серьезные решения. А они далеко не всегда лежат в той плоскости, в которой мы привыкли работать. Вот тут-то и начинаешь вспоминать всякие дифуры, линейные алгебры тер.веры и прочие матаны. Я уж не говорю о том, что даже мне за свою не очень болшую практику приходилось писать расширение на C для PHP. Попробуйте поработать в компании наподобие Rocket-Internet, или какого-нибудь крупного финтех стартапа, например, всё поймете.
                                +5

                                Я 8 лет на одном месте проработал.
                                Несколько раз пытался уволиться, но все заканчивалось звонком шефа и повышением зарплаты…
                                В последний раз поставил шефа перед фактом, что рабочее место новое уже найдено и ни под каким соусом не остаюсь, он согласился, но попытки вернуть не оставлял ещё несколько месяцев.
                                Условия были хорошие, но никакого профессионального роста не чувствовалось абсолютно, казалось что как программист я сдуваюсь.

                                  0
                                  Молодец, что нашли в себе волю покинуть зону комфорта ради дальнейшего развития!

                                  Проводя собеседования разработчиков, я тут заметил одну интересную закономерность. Кандидата три за последний месяц было с несколькими пересекающимися характеристиками, как то:
                                  — возраст 30 или больше
                                  — соответственно продолжительный опыт работы, особенно на последнем месте (5 и больше лет)
                                  — полное отсутствие понятия о современных популярных инструментах / фреймворках для своего языка (позиция php, junior / middle backend)
                                  — диктаторского склада начальник на текущем (крайнем) месте работы, который упоминается каждый раз, когда я задавал вопрос «почему же вы использовали последние N лет свой велосипед X, когда для решения этой задачи, сообществом написано за эти N лет 100500 годных библиотек?»

                                  В общем, прямо типаж наблюдаю: человек попал в какую-то конторку, там вроде бы тепло, начальник всё решает при помощи своего набора молотков десятилетней выдержки, учить новое не заставляет, за инициативу наказывает. И грустно это, т.к. сразу видно, что люди отстали от языка и сообщества на эти самые 5-10 лет. И самое печальное, что 30 лет, это тот возраст когда уже не так просто наверстать упущенное, разобраться в стеке, как скажем в 20. То есть мне лично слабо вериться, что если человек до 30 лет не состоялся как программист, то вряд ли он качественно повысит уже уровень когда либо.
                                    +6
                                    А какой критерий для «состоялся как программист»?
                                      0
                                      А какой критерий для «состоялся как программист»?
                                      В данном контексте можно такой: «забыл про PHP, как про страшный сон» :-)
                                      А если серьёзно, то на мой взгляд состоявшемуся программисту должно быть не суть важно какой язык или стек, он причинит проекту пользу в любом случае )))
                                        0
                                        «Причинение пользы» это пять.
                                          +3
                                          Не не, причинять можно добро, а пользу надо наносить.
                                          0
                                          Не соглашусь. Мне было пофигу(и сейчас до сих пор так и есть), какой язык или стек. Начинал с Java, перекатывался в Python, потом PHP(sic!), потом NodeJS и вот теперь опять работаю в основном на PHP(было еще баловство с С++, Ruby и Haskell, но это для общего развития просто, а не для работы). Но суть в том, что та же неважность стека до меня дошла еще до того, как я даже устроился на первую работу и тогда же я уже делал свои Laba1… LabaN на разных языках, которые нам даже не преподавали.
                                          При этом хорошим программистом я бы себя того не назвал(возможно и нынешний я не оч. хороший программист). Я бы сказал, что эти критерии каждый определяет для себя сам и найти единую точку зрения на это вряд ли возможно. И пользу проекту хороший программист принести может далеко не всегда. Иногда проекту как бы не нужна эта польза. Трудно ее приносить, когда вокруг тебя одни просиживающие штаны дядьки, сидящие на этом рабочем месте по N-дцать лет. Такому проекту хороший программист будет скорее во вред.

                                          Так что я думаю, что человек состоялся, как программист тогда, когда он сам для себе это решил, либо это за него решило абсолютное большинство окружающий программистов. Желательно авторитетных.
                                            0
                                            Иногда проекту как бы не нужна эта польза. Трудно ее приносить, когда вокруг тебя одни просиживающие штаны дядьки, сидящие на этом рабочем месте по N-дцать лет.
                                            Так это, на мой взгляд, идеальная ситуация для проверки той самой состоятельности… Тут либо конформистское поведение возмёт верх, либо профессиональная этика. Всегда есть выбор: делать как коллеги (как начальство сказало, как «быстрее») или исходя из своего представления как должно быть. Иногда эти варианты могут и совпадать, но далеко не всегда.

                                            Так что я думаю, что человек состоялся, как программист тогда, когда он сам для себе это решил
                                            О, это ощущение обычно бывает ещё в первый год… потом, правда, у адекватных людей проходит на значительное время )
                                              0
                                              Так это, на мой взгляд, идеальная ситуация для проверки той самой состоятельности… Тут либо конформистское поведение возмёт верх, либо профессиональная этика. Всегда есть выбор: делать как коллеги (как начальство сказало, как «быстрее») или исходя из своего представления как должно быть. Иногда эти варианты могут и совпадать, но далеко не всегда.


                                              Это тема долгой дискуссии, но я задам простой вопрос: Зачем мне работать в таком месте, когда я могу пойти туда, где коллеги будут тянуть не назад, а вперед. В таких проектах, как правило, в итоге приходится делать работу за других людей, что само собой не допустимо. Я уж не говорю о том, что такие «коллеги» скорее свяжут тебе руки, чем позволят показать преимущества нормальных подходов. Ну и последняя пуля моей аргументации в том, что тебе все-таки нужно работать в команде. С кодом, который пишут твои коллеги. Если даже ты производишь 10% кода(что очень много для серьезных проектов), то остальные 90% кода всеравно остаются говном. А тебе приходится постоянно иметь с ним дело. Трудно производить что-то хорошее, что должно взаимодействовать с говном… Даже если это удается, то конечный результат всеравно говно, пусть и с ложкой меда. Хочет ли хороший программист быть в такой ситуации — вряд ли.

                                              О, это ощущение обычно бывает ещё в первый год… потом, правда, у адекватных людей проходит на значительное время )


                                              Совершенно верно, спору нет. Но это никак не противоречит тому, о чем я сказал. Понятие все-таки субъективное и одних и тех же программистов разные люди оценят по-разному. Кто-то скажет, что «этот парень чертовски хорош», а кто-то скажет обратное. И каждый найдет аргументы. Многие вообще скажут, что хороший программист это программист, который решает задачи бизнеса без оговорок на то КАК он это делает и как на длинной дистанции его решения будут удовлетворять критериям бизнеса.
                                              А насчет проходимости — тоже верно. Я вообще думаю, что это ощущение должно появляться и проходить переодически на протяжении всей карьеры. Ты как бы преодалеваешь перевал и видишь вершину. Карабкаешься на нее, а она оказывается не вершиной, а очередным перевалом. Все мы понимаем, что нет предела совершенству) Только в программировании у тебя не просто горы с перевалами, а эскалатор, который едет в обратную от твоего направления сторону и остановки в развитии тут череваты.
                                                +1
                                                Зачем мне работать в таком месте, когда я могу пойти туда, где коллеги будут тянуть не назад, а вперед.

                                                Ну, это просто утрированный случай… На практике сложно найти работу, где все коллеги будут тянуть вперёд… Точнее, в начале карьеры несложно, но чем больше опыта, тем чаще приходится самому кого-то тянуть )))

                                                  0
                                                  Одно дло тянуть кого-то потому, что он слабее тебя, но хочет что-то делать и совершенно другое — тянуть кого-то, чья идея просиживать штаны и цели тянуться никакой нету, разговор-то об этом.
                                                    0
                                                    чья идея просиживать штаны и цели тянуться никакой нету

                                                    ну, имхо, это 80% народа в любой профессии… куда ж без них?

                                                      0
                                                      Ну хз, я имел удовольствие работать в среде других людей и даже не на одном месте. С этими тоже доводилось, но больше 3х месяцев я в таких местах не задерживался. Мой рекорд — 5 дней работы и увольнение по собственному. Когда чувствуешь, что здесь ты попросту тратишь свое время и ты можешь значительно больше, даже если будешь тупо работать один, то какой смысл оставаться на таком месте? Лично для меня при выборе работы команда занимает одно из первых мест в списке моих требований(зарплата в этом списке почти в самом конце).
                                                        +1
                                                        Мой рекорд — 5 дней работы и увольнение по собственному.

                                                        Всё правильно, вот для этого и нужен испытательный срок. К сожалению, лично я всегда сталкивался с тем, что работодатель всегда рассматривает его только в свою пользу, чтобы при желании выгнать тебя с позором и без объяснений причин. При этом от тебя требуют хотя бы устных гарантий, что ты после приёма на работу быстро не уволишься. А если такие гарантии не даёшь, а наоборот говоришь, что надо сначала присмотреться, то тебя просто не берут.

                                                          0
                                                          Кстати, забавно, но в том конкретном случае я даже при приеме на работу попросил увеличить испытательный срок до 3х месяцев(это аутсорсинговая контора, я предчувствовал с самого начала, но интерес взял верх), мотивируя тем, что надо присмотреться. Самое забавное, что потом их HR умудрилась мне звонить и угрожать, что устроит мне такие проблемы, что меня больше никуда на работу не возьмут :D
                                                            0

                                                            Жесть! Прям рабовладельцы, а не работодатели...

                                                              +1
                                                              Так аутсорсинг же!) Современное рабовладение в чистом виде :D
                                          +1
                                          Получается что «состоялся как программист» — значит работал на одном месте меньше пяти лет, в идеале менял работу настолько часто, чтобы можно было попробовать все современные решения. С учётом скорости появления новых инструментов — не более трёх лет на одном стеке. Вот такой стремительный активный специалист. Который надолго не задержится, если в компании не будет веер самых современных технологий, что могут себе позволить не все компании.
                                            +1
                                            Ну три года на одном месте вполне достаточно же
                                            –1
                                            У меня небольшой чеклист, с базовыми техническими вопросами для кандидатов. Если человек претендует на позицию backend developer, и не может описать своими словами из чего состоит http запрос, или чем отличается 400 код ответа от 500, то тут в зависимости от заявленного опыта два варианта:
                                            — если человек вчера, условно, закончил универ, я могу допустить, что это просто junior, которому много предстоит узнать
                                            — если передо мной 30 летний мужик, с 10 годами опыта в резюме, то похоже он не состоялся.
                                            У первого есть шанс состоятся. У второго, имхо почти нет. Вот примерно такой смысл, вкладываю в это слово.
                                              +5
                                              Самое забавное в том, что если спросить серьёзных профессионалов, что самое главное для backend developer'a, никто не назовёт уметь описать http запрос своими словами или знать отличие кода 400 от кода 500.
                                                0
                                                Поделитесь списком вопросов или сценарием интервью от серьёзных профессионалов? Было бы интересно.
                                                  +1
                                                  1. Я имею в виду не профессиональных интервьюверов, а профессиональных айтишников. Синьёров там или тим лидов.
                                                  2. Думаю вы поняли про что я: не зная, как проверить самые главные качества кандидата (да ещё частенько путаясь, какие качества главные), проверяют те, которые легче проверить. Ну это всё равно как искать ключи под фонарём, потому что там светлее.
                                                  3. Такого списка или сценария у меня нет, я давно уже не проводил собеседования массово, тем более в ИТ. Но задача такая у нас стоит сейчас, возможно список/сценарий и появится, хотя скорее это будет целая технология поиска подходящих сотрудников и список будет лишь одим из звеньев цепи, который изолированно применять будет бессмыссленно.
                                                  4. Возможно у каждой организации будет (должен быть) свой список/технология, в зависимости от её потребностей.
                                                    +3
                                                    Не буду говорить за всех, но что такое http, чем один статус отличается от другого и из чего он состоит я знаю(хоть и PHP-обезьяна). Просто потому что вся моя работа своидится к определнной обработке запросов и отправке ответов. И основной протокол в моем случае — http. Хотя могу и про UDP рассказать и про модель OSI если уж очень невтерпеж будет. Но незнать такой базовой вещи как http, претендуя на позицию веб-разработчика это вообще какая-то дичь для меня, если честно.

                                                    Лично я просто составлял большой список вопросов разной сложности(да, для каждого проекта свой), но никогда не задавал их все. В основном, если искал кого-то на позицию выше Junior — строготехнические вопросы я почти не задавал. ИМХО, в процессе обычной живой беседы проще понять кто перед тобой, чем по каким-то вопросам конкретных реализаций. Технические вопросы использую такие, которые требуют пусть небольших, но рассуждений и ответ на которые можно вывести даже если ты их не знаешь. Все-таки нам больше важно как человек думает, а не что он знает. С Junior-разработчиками ситуация немного другая, потому что Junior по моему мнению должен быть в активной стадии обучения, а значит и память должна быть свежее. Более того, простые технические вопросы позволяют понять, насколько человеку вообще интересно программировать и что он вообще здесь делает. Очень круто, когда некоторые из них начинают вступать в дискуссию. Но, увы, все чаще и чаще, даже на позиции Senior в последнее время ко мне приходили людю, неспособные даже рассказать, в чем отличие абстрактного класса от интерфейса, что не может не печалить…
                                                      +1
                                                      неспособные даже рассказать, в чем отличие абстрактного класса от интерфейса

                                                      Так в чем же отличие? :)
                                                      Мне постоянно говорят, что я неправильно отвечаю на этот вопрос :)
                                                        +1
                                                        С точки зрения PHP

                                                        Чем отличается абстрактный класс от интерфейса?
                                            +3
                                            полное отсутствие понятия о… фреймворках для своего языка

                                            Фреймворк если понадобится можно изучить. В чём проблема-то? Что такого критичного в знании/незнании новомодного фреймворка?
                                              –2
                                              В приведённых мной случаях, проблема в том, что кругозор людей ограничен одним стеком, одним рабочим процессом и маленьким парком локальных велосипедов.
                                              А обучаемость вещь такая — если мозг не тренировать на новом регулярно, то после 30, как я слышал, он эту способность теряет.
                                              Изучить что-то не проблема, если ты постоянно этим занимаешься.
                                                +6
                                                Проблема в том что слышали, а на самом деле способности и в 40 никуда не теряются, просто люди с возрастом становятся терпимее и с улыбкой смотрят на юнцов «а давайте все перепишем на фреймворке <название>». Есть проекты которые пишутся из года в год, и даже переписываются, но чаще всего инициатор сливается за пару месяцев и успешно продолжает сливать проект уже в другом месте, ну нравится им писать на самых последних фреймворках, развиваются же.
                                                  0
                                                  Получив этот Ваш ответ на почту, специально перешёл на сайт, чтобы убедиться в своём предположении о немалом числе «минусов». А тут — два «плюса»… :)

                                                  Похоже, я перестал понимать людей… :)))

                                                  P.S. И да — "+". :)
                                                  Просто взять и «плюсануть» нет возможности.
                                              0
                                              Хм… Выходит, в мои 29 переквалифицироваться из сисадмина в разработчики — задача трудновыполнимая?(
                                                –1
                                                Дело не в возрасте, как таковом, а в навыке обучаемости, который стоит поддерживать как можно дольше, чему не во всех организациях способствуют. Так что лучше по собственной инициативе всегда изучать что-то новое для себя.
                                                0
                                                как скажем в 20

                                                В 20 лет сложновато отстать на 10 лет.
                                                А особенно иметь 10 лет опыта. :)
                                                Да и новые технологии можно подтянуть, если умел пользоваться старыми. :)
                                                  0
                                                  Не поспоришь.
                                                  Но по факту имеем разброс когда
                                                  а). человек в 20 обладает большим кол-вом актуальных познаний и минимальным опытом их применения
                                                  б). человек с 10-летним стажем имеет неактуальные знания и ноль знаний и опыта применения актуальных

                                                  И, по моему, скромному мнению, если человек (б) сам не подтянулся за всё это время, вряд ли стоит от него ждать успехов, я сделаю ставку на более молодого, в описанном случае.

                                                  Касательно области обсуждаемых знаний, я имею в виду не новомодные фреймворки, а мажорные версии языка, и мейнстримовые для сообщества парадигмы.
                                                    0
                                                    а) Хз, но вряд ли в вузах учат актуальным технологиям :)
                                                    Хорошо, если человек о них читал сам.

                                                    б) Неактуальные знания при желании можно обновить. Просто на самом деле не многим проектам нужно что-то, кроме LAMP (если говорить о веб).

                                                    Если результат нужен здесь и сейчас, то лучше поставить на опытного с требуемым опытом (с требуемой технологией, возможно старой версии, вряд ли новая так уж сильно уехала вперед).
                                                    Если можно подождать, то можно на умеющего думать без опыта. Опыт дело наживное.
                                                    Некоторые компании берут на стажировку / стипендию, но таких мало.

                                                    А еще бы я оценивал по собственным проектам. Но тут тоже вряд ли будут сверхтехнологии.
                                                    Я стал программистом как раз потому, что захотел реализовать свой проект. :)
                                                    Главное, чтобы человек умел думать.
                                                    Умение думать тупыми тестами IQ проверять не стоит.
                                                    +2
                                                    В 20 лет сложновато отстать на 10 лет.
                                                    А особенно иметь 10 лет опыта. :)


                                                    Мой сын попросил у меня финансирование на приобретение первых книг по программированию как раз лет в 10. И деньги не были потрачены зря: он эти книги освоил вполне успешно.
                                                    Так что к 20-ти уже имел те самые 10 лет опыта. :)
                                                      0
                                                      Завидую. Мне почти на все книги приходилось зарабатывать.
                                                        0
                                                        Ну, в 10 лет ему было ещё сложно зарабатывать самостоятельно. :)

                                                        А вот где-то года через 4, если не ошибаюсь, он уже попросил меня обналичить его первые «электронные» несколько сотен долларов, полученные им за работу «по специальности». И книги уже заказывал и оплачивал сам. :)

                                                        Я был горд безмерно… :))
                                                    +1
                                                    А если человек стал программистом после 30?
                                                      –1
                                                      «Мёртв ещё до рождения» :))
                                                    +3
                                                    Я работаю столько-же. За это время появились сначала юнит тесты, потом отдельный QA отдел автоматизации тестирования, CI система, переход из cvs в git, ревью кода, использование современных БД и сервисов, миграции БД, и прочее.
                                                    Всегда есть куда развиваться, можно сменить направление внутри одного большого проекта.
                                                    Главное следить что происходит вокруг в IT области а не ограничивать себя текущими задачами.
                                                      0
                                                      Хорошо когда проект / команда развивается технологически. Это и для участников большая польза — расти оставаясь на прежнем месте. Увы, не везде такое возможно, насколько я знаю.
                                                        0
                                                        Развиваться технологически ради самого факта новый технологий сомнительно. Должны быть плюсы от этих технологий.
                                                          0
                                                          То есть, Вы хотите сказать, что если на текущем месте от человека расширения кругозора не требуется (используемый стек не меняется вот уже 10 лет), то и не стоит ему, развиваться, сомнительное занятие это? Ведь в текущей ситуации (для команды, проекта) плюсов от изученных технологий не будет.
                                                            0
                                                            Нет, кругозор нужно расширять, иначе мы не узнаем есть ли плюсы от новых технологий.
                                                            Но применять их нужно, если от них есть выгода. А не потому что все крутые перцы пишут на %framework_name% и на вас криво смотрят.
                                                              +1
                                                              Боюсь, что ознакомившись чисто формально, без практики, сложно овладеть технологией настолько чтобы оценить насколько она выгодна. А заявленные вендорами плюсы технологии, это в большинстве случаев маркетинговый булшит.
                                                              В программировании, обучение без практики, имхо, даёт ничтожный результат. Можно сказать что «знаешь о технологии», но сказать что знаешь технологию, не применив её ни разу, нельзя.

                                                              Отсюда я делаю вывод, что развитие должно в себя включать и применение на практике новых инструментов. Иначе это не развитие.
                                                                +1
                                                                заявленные вендорами плюсы технологии, это в большинстве случаев маркетинговый булшит

                                                                Именно!
                                                                Потому обязательное требование знать фреймворки — характерный симптом некомпетентности интервьюера, желающего скрыть свою некомпетентность за крутыми понтами.
                                                                  +1
                                                                  Обязательное требование знать фреймворки часто обозначает необходимость общаться на одном языке с той командой, которая пилит проект, завязанный на указанный в требованиях фреймворк.

                                                                  Иначе придется ждать пока человек изучит этот фреймворк. А бизнесу это не очень нужно, бизнес хочет готового специалиста.
                                                                  0
                                                                  А заявленные вендорами плюсы технологии, это в большинстве случаев маркетинговый булшит.

                                                                  А я на них не ведусь :)
                                                                  Фреймворки не решают моих задач.
                                                                  Тут дискуссия: https://habrahabr.ru/company/mailru/blog/308788/

                                                                  Отсюда я делаю вывод, что развитие должно в себя включать и применение на практике новых инструментов.

                                                                  Пускай технология созреет.
                                                                  Пускай другие на ней набьют шишек, а мы посмотрим. :)
                                                                  Прыгать с технологии на технологию (не версию) не стоит, если нету проблемы в текущей технологии или плюсов новой. Разве начинать новые проекты.
                                                                  А также на новую технологию сложнее найти специалистов.
                                                        0
                                                        Почему вы не захотели сами организовать себе среду для профессионального роста, ведь ваши инициативы при таких обстоятельствах имели бы высокие шансы на реализацию?
                                                        +1
                                                        очень важно быть выбранным в качестве руководителя проекта

                                                        Это уже проходили. Дурков нет и люди будут выбирать того, кто не будет их напрягать и чьи интересы совпадают с их интересами. Это совершенно не обязательно совпадает с интересами проекта, начальства, организации.
                                                          +1
                                                          А вот здесь не соглашусь. Поясню на примере: знаю нескольких людей, искренне верующих, что все люди лодыри и работать не любят. Ну так вот: почему-то в командах у них (сюрприз!) сплошные лодыри, которых надо подгонять.

                                                          Я вообще суровый материалист и в эзотерическую фигню теорию о влиянии мыслей на окружающий мир не очень верю. Но в данном конкретном случае, похоже, такие эффективные менеджеры подсознательно отсеивают увлеченных своим делом людей на собеседованиях, ибо те не вписываются в их картину мироздания.

                                                          По-моему, вы правильно интерпретировали следствие, но почему-то поставили его на место причины.
                                                          +1
                                                          Суть иллюстрации в тексте статьи хорошо объясняется эффектом Даннинга-Крюгера.
                                                            +2
                                                            в 20 лет интересно что-то мутить и глаза горят, я сам такой был
                                                            сейчас есть более интересные дела, чем работа и каждодневное изучение того, что завтра уже устареет

                                                            в других каментах я писал, что нынешний ит на грани коллапса и скоро количество технологий будет таково, что никто толком не будет уметь пользоваться ими или точней пользоваться будут, но никто не будет понимать, как это работает вцелом
                                                            как например современный процессор или операционная система

                                                            появятся специальные люди, которые будут изучать возникшую ошибку в результате соединения готовых библиотекх и технологий в стеке, потому что те, кто пишет код не будут понимать и у них не будет времени изучать что-то новое, т.к. еще старое не осилил

                                                            быстрый рост технологий и породил это явление, когда человек не то чтобы не хочет учить новое, а у него тупо нет времени на это, потому что после 9 часов торчания в офисе надо еще час ехать домой и заниматься с семьей, пожрать и готовиться ко сну, чтобы завтра опять торчать 9 часов в офисе
                                                            — кстати наглядный пример
                                                            надо из гуглокалендаря постить записи в пейсбук
                                                            ну я знаю про их апи и решил посмотреть, нет ли библиотеки ихней и нашел в гугле
                                                            я предвидел гимор с авторизацией через ссл и так оно и случилось — 2 дня только на гугление ушло
                                                            теперь проходит, но выдает 404, хотя там тестовая консоль разработчика выдает правильный результат
                                                            и вот я имею кучу пхп файлов, плохую документацию без описаний функций библиотеки и непонятно что мне теперь с этим делать?
                                                            я вот не знаю как работает ссл, знаю что надо какой-то сертефикат, но откуда он берется в пхп — неизвестно, в мануале к библиотеке ничего не говорилось про установку сертефиката
                                                            написано только, что надо ключ создать или юзать oauth

                                                            библиотека гугла на диске занимает 24 мегабайта!!!1
                                                            что она делает? передает гет запросы и в ответ выдает джейсон и состоит из кучи разных библиотек сторонних разработчиков с гитхаба, зато ставится композером одной командой

                                                            вот как профи программист будет искать ошибку и сколько он потратит времени?

                                                            кстати насчет рс485 это не просто первый уровень отличия, там у трансивера есть вывод переключения прием/передача и работает это хоть и поверх ком порта, но есть в порт можно тупо писать и читать, то тут надо еще и управлять 3м контаком, на который повешан этот вход управления в адаптере
                                                            на днях пришли 2 адаптера усб-рс485, а я даже не знаю какой вывод там китайцы задействовали
                                                              0
                                                              библиотека гугла на диске занимает 24 мегабайта!!!1

                                                              Нафиг такие библиотеки:
                                                              https://habrahabr.ru/post/140581/
                                                              Они развивают псевдопрограммирование.
                                                                +1
                                                                (по ссылке:)
                                                                объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция

                                                                Верно! А потом приходят фанаты ФП и…
                                                                  0
                                                                  ну она как бы одна, а сервисов у гугла целая куча, может быть это оправдывает ее размер?
                                                                  0
                                                                  Лень смотреть либу, но читал что это ключ к очень многим сервисам гугла, просто ее решили не дробить на кусочки. Поэтому размер в какой-то степени оправдан.
                                                                  0
                                                                  С Git/Mercurial и прочими, всё становится на свои места.
                                                                  SVN… это тоже плохая черта, причём говорящяя много обо всех, кто его использует в проекте. Почему? Ну, использовать инструменты двадцатилетней свежести, когда есть толковые современные замены — это всё же показатель низкой квалификации.
                                                                    0
                                                                    Широкий кругозор один из признаков хорошего инженера. Большиство негативных кейсов что вы описываете как страдают его отсутствием. Но нужно понимать, что это нужно руководителю проекта, и совсем не нужно кодеру.
                                                                      0
                                                                      Кодеру не нужно, а вот программисту нужно 100%. Все-таки хороший программист отличается от плохого в том числе тем, что может выбирать правильные инструменты для решения поставленных задач, проектировать решения так, что бы они отвечали требованиям спущенным свыше, да еще и желательно предусматривать изменяемость этих самых требований. Ну и само собой — знание предметной области. Все это требует довольно широкого кругозора.
                                                                      0
                                                                      Странно, что у Вас начальник по блату :)

                                                                        –1
                                                                        Ну а зачем тогда создавалась возможность по разрешению конфликтов?

                                                                        Конфликтов желательно избегать, а то одному не всегда понять, как его решить. С одной ветки пришло одно, с другой другое. :)

                                                                        Я тоже, как начал более нормально работать с git-ом (до этом только умел add|commit|push|pull и он мне жутко не нравился, так как вся разработка была в одной ветке, мастер правили на сервере по живому) думал так.
                                                                        Но если есть необходимость работать с тем же куском кода в один день, то лучше не вносить правки до того, как коллега не запушит свои коммиты и не даст зеленый сигнал.
                                                                          0
                                                                          Весь мир движется к сервисной модели, и software development не станет исключением. Зачем постигать EIA-422, пусть и имея в бэкграунде EIA-232, т.е. тратить время, набивать шишки подводными камнями, и в итоге положить эти знания и опыт на полку, если существуют в мире люди, собаку на нём съевшие? Включая куда там очумелые китайцы контакты завели в данной конкретной модели оборудования. Все должно сводиться к тому чтобы найти такого человека, грамотно озадачить, подписать NDA, и через полчаса у вас уже все готово. Точно так же, возможно, кто-то успешно скрестил гуглокалендарь с фейсбуком буквально вчера. Посчитайте сколько надо заплатить штатному программисту [по ставке $100/h] пока он 2 дня разбирается. Безрезультатно притом. :)
                                                                            0
                                                                            «Посчитайте сколько надо заплатить штатному программисту [по ставке $100/h] пока он 2 дня разбирается. Безрезультатно притом. :)»
                                                                            я не штатный программист, я просто решаю ит вопросы разного характера при помощи софта и железа
                                                                            оплата фиксированная и пока я думаю взять 500 евров, т.к. не знаю много это или мало за такую работу

                                                                            мне нравится решать нестандартные вопросы, организовывать из кубиков, но вот конкретно код писать я не умею, хотя делаю это лет 20 наверное уже
                                                                            0
                                                                            > Не нужно делать проблему, когда возникает задача написать программу для обмена по UDP, а вы раньше писали только обмен по TCP протоколу.

                                                                            Охохохо, мне кажется, что вы серьёзно подставились. Потому что между TCP и UDP транспортом есть небольшая, но критически важная разница в виде абстракции, которую каждый из них предлагает.
                                                                            TCP — это труба из байтов. С ним всё отлично (почти), байты всегда приходят в том порядке, что отправлены и доставка гарантируется.
                                                                            UDP — это негарантированная передача блобов ограниченной длины. Стоит напороться на какой-нибудь перегруженный маршрутизатор, и пакеты могут не дойти совсем. Приложение обязано быть готово к тому, что блобы придут в любом порядке, и могут не придти вообще, отправляющая сторона тоже должна быть к этому готова. Также есть куча всяких граблей вроде поддержки фрагментации пакетов в сети и MTU, которые неявно задают ограничения на передаваемый размер блоба.

                                                                            Т.е. если вы пишете конечный автомат, управляемый по UDP, вы должны быть готовы к куда большему пространству подаваемых в него команд, плюс самостоятельно реализовать алгоритм переотправки застрявших на отправителе команд, итд. // да, есть библиотеки, но требования понимания, что внутри происходит это не отменяет.
                                                                              0
                                                                              Безусловно между TCP и UDP протоколами есть разница. НО во фразе «делать проблему» имелось в виду, что некоторые даже не знают, что обмен, используя эти протоколы, в обоих случаях осуществляется по сокету. А в этом случае, я сомневаюсь, что такие люди знают о различии протоколов.
                                                                                0
                                                                                Мне кажется, что человек, который не знает что такое сокет, менее опасен, чем человек, знающий про TCP-сокеты, и бодро фигачащий точно такую же реализацию поверх UDP со словами, «ну а шо, что то — сокет, что это — сокет, оба — сокеты». Не надо так. Не знающего человека можно научить, а вот человека с уже сложившимся паттерном мышления нужно переучивать, что сложнее.

                                                                                N.B. это больше про людей, которые применяют stackowerflow-driven development, и не относится к людям, умеющим читать нормальную документацию перед использованием чего-либо.
                                                                                  +1
                                                                                  " бодро фигачащами " и уверенными в своих знаниях без прочтения документации обычно являются студенты, начинающие программисты. Ибо меньше знаешь- крепче спишь, ведь они даже и не подозревают, что дольше будут расхлебывать последствия, чем потратив время на прочтение манов и сделав как нужно.

                                                                                  И да, трудно не согласиться, " опасные" они люди
                                                                                    0
                                                                                    > " бодро фигачащами " и уверенными в своих знаниях без прочтения документации обычно являются студенты,
                                                                                    > начинающие программисты.
                                                                                    Эх, если бы…
                                                                                      +2
                                                                                      я сам в такого опасного человека легко превращаюсь, когда пишу что-то не относящееся к моим основным компетенциям.
                                                                                      Разные мелкие скрипты, которые могут мне облегчить жизнь, но не стоят вложения серьёзных усилий, или куски на ангуляре, в котором я, мягко говоря, плохо разбираюсь и неоткуда быстро взять системные знания, а задачу нужно решить.
                                                                                  +1
                                                                                  байты всегда приходят в том порядке, что отправлены

                                                                                  Вернее: гарантирует целостность передаваемых данных даже если пакеты придут не в том порядке.
                                                                                    0
                                                                                    Согласен с поправкой, просто хотелось сделать акцент именно на протечке абстракции сокета. В случае TCP и UDP абстракция течёт по-разному и вызывает разные проблемы.
                                                                                  0
                                                                                  «Дальнейшее саморазвитие таких людей ограничивается знаниями и навыками, получаемыми по ходу необходимости для проекта и с курсов, оплачиваемых фирмой.»
                                                                                  Что тут не так? Получаешь практический опыт, ходишь на курсы?
                                                                                    0
                                                                                    Надо просто с начальником налаживать отношения, чтобы на работу брали квалифицированных коллег. Если это не так, то на предприятии занимаются чем-то другим, скорее всего, криминалом и надо текать оттуда, пока не влип в историю.

                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                    Самое читаемое