Комментарии 116
> Возникает встречный вопрос: Ну а зачем тогда создавалась возможность по разрешению конфликтов?
Создавалась она с благими намерениями, но сидеть и резолвить крупный файл, который автоматически не слился из двух коммитов — то ещё удовольствие. Если есть возможность договориться с другим разработчиком и избежать этого, то будет просто замечательно.
Люди, которые меняют работу раз в несколько лет проходят естественный отбор на собеседованиях и их уровень обычно выше старожилов. Плюс кругозор из-за работы в разных областях и с разными людьми.
Я когда-то сам развлекался, ходя на собеседования пообщаться с умными и не очень людьми :)
Что надо делать? Свои проекты? Опыт? Проекты с хорошими программистами? Курсы?
Или может просто необходимо до нуля копать и рыть используемый продукт, чтобы его знать до мелочей?
Всё остальное на самом деле приложится, если голова на плечах есть. Конечно, очередного Кемпбелла из Вас с высокой долей вероятности не выдет, но ведь не это главное, верно?) И применимо это далеко не только к программированию. Просто нужно делать то, что должен делать не просто хорошо, а каждый раз пытать делать максимально хорошо, постоянно повышая собственную планку.
Если более конкретно. Курсы — лажа для неосиляторов. Вся информация на которой строятся курсы и так есть в свободном доступе(иногда за умеренную плату, которая всеравно не сравнима с платой за курсы). Сама по себе работа программиста подразумевает довольно уверенное владение навыком поиска информации, ее анализ и усвоение. Я бы даже сказал, что навык этот ключевой. Таже самая JAVA уже совсем не та, как была в мои университетские времена. Что делать? Идти на курсы, или все таки почитать интернеты и осиливать самому. Это я уже не говорю о куче смежных областей, которые приходится изучать из проекта в проект.
Свои проекты на ранних стадия по моему мнению вообще являются единственным способом обучения. Придумать проект проще простого, все мы ежедневно сталкиваемся с задачами, которые могли бы решать намного эффективней, в том числе с помощью ПО. Начинать можно с чего-то простого в духе всяких менеджеров паролей и калькуляторов. А дальше наращивать функционал пока не надоест. Как надоест — новый проект другой тематики. Лабораторные работы в универе не качать из интернета, а делать самому, несмотря на то, что 95% однокурсников пойдут по первому пути.
После того, как будет уверенность в своих силах и кажущееся понимание основ можно пойти на работу, но это довольно серьезный шаг, потому что работа может оказать совершенно противоположный ожидаемому эффект. А оценить уровень коллег на первых порах, думаю, просто невозможно. Можно найти себе «ложных авторитетов» и остаться в их болте.
Наибольшее влияние на меня, как программиста оказали именно другие программисты с которыми довелось работать. Точнее именно те, кто так же как и я любят эту работу, но намного превосходящие меня по своему уровню либо в силу большего опыта, либо интеллектуальных способностей, которые у меня, например, довольно заурядные.
Не лишним и даже очень полезным будет хотя бы на время влиться в Open-source. Во многих проектах есть сильные разработчики а коммунити не даст мержить пулл-реквесты с откровенным говном. Тратить время на ответы на вопросы на Stack Overflow тоже лишним не будет. Читать ответы тоже полезно. Общаться в «тусовке» программистов и обсуждать подходы, методологии, технологии, новинки из сферы разработки и так далее.
Эх, расписался чё-то, но надеюсь, ты прислушаешься к тому, что я написал. Если бы я это все знал раньше, наверное, я был бы намного лучше, чем есть сейчас :D
Может быть, если бы я не начинал с фриланса, мне бы обычная работа не показалась чем-то неприятным, но за несколько месяцев я твердо для себя решил, что хоть с 9 до 18 в офис и отсиживать свой оклад я точно не хочу. Может в Яндексе, Гугле и других инновационных компаниях всё иначе, и там все в одном духе работают над задачами, не поглядывая на часы и не протирают штаны, но конкретно у меня был такой опыт. Лично на меня наибольшее влияние оказали не конкретные программисты, а мануалы, статьи и разборы кейсов. Мне не нравится слушать и даже смотреть на видео/в живую разборы «как надо», я больше люблю читать это и одновременно воплощать в жизнь на тестовых примерах. Про университет вообще молчу — не было в моей местности ничего, близко связанного с веб — программированием, только прикладное программирование, которое мне не интересно. Ну и беглый просмотр предметов по всем курсам не радовал — базовые знания C/C++, история операционных систем, SQL и т.д. Так что всё очень индивидуально.
Ни о каком огоньке в глазах у сотрудников речи не шло, все работали как везде — с 9 до 18, зачастую на отвали, посматривая на часы и надеясь, что отпустят пораньше.
Хм, мне интересно работать (наверное, как и большинству) :)
Но сидеть после 18 мне не интересно.
А также приветствую, когда можно уйти пораньше (у нас вообще с графиком нету проблем).
В общем, имхо, тут вопрос скорее в правильном выборе работодателя. Многие люди попросту забывают, что не только наниматель выбирает нас, но и мы его. Более того, сейчас мы находимся в намного более выгодном положении, потому что разработчиков реально нехватает, при том почти во всём мире.
Впрочем, почти все места, куда я собеседовался, предполагают некоторый процесс ревью и контроля статей, которые я собираюсь публиковать, кода, который я собираюсь выкладывать, и так далее. Может, специфика отрасли, не знаю.
У меня такое тоже было и у себя в компании я тоже стараюсь взять это под контроль, но это же не противоречит тому, что я говорю. Я бы даже сказал, что это увеличивает мою компетентность как разработчика. Личное мое убеждение в том, что ревью — одна из немногих вещей, которая позволяет нам расти на протяжении всей карьеры. Особенно, если это делается правильно и внимательно.
Всё же проблем с этим при решении задач на рабочем оборудовании чуть больше, чем при решении задач у себя дома. В некоторых контрактах за рубежом вообще прописывается, например, что всё, что сделано на оборудовании работодателя, по умолчанию принадлежит работодателю
Это одна из причин, почему я использую только свой ноутбук в работе. В офисе только док-станция и периферия
Другая проблема, что поговаривают, что у сотрудников гугла, как правило просто нет времени на это)
https://habrahabr.ru/post/309630/
> За время и на оборудовании работодателя или на своих собственных ресурсах?
Подавляющее большинство программистов (и я в том числе) будут без заззрения совести это делать как получится, в том числе и в свободные фрагменты рабочего времени и на оборудовании работодателя. Подавляющее большинство работодателей (и я в том числе) ничего плохого по этому поводу не скажут, если это не сказывается негативно на основной работе. Объективно — мы все не роботы, а живые люди, и не можем, и не должны от звонка до звонка непрерывно копать траншеи. Мы все отвлекаемся, думаем, бывают непродуктивные дни и т.д. И нет никакой разницы, чем человек занят на перекурах между работой, изучением хаскеля или там болтовнёй на хабре. Первое, кстати, полезнее.
Возможно, для Вас это окажется новостью, но в серьёзный компаниях кое-что значат такие Трудовой кодекс РФ, СанПиН, трудовой распорядок, и прочие Законы РФ и локальные нормативные акты.
И постоянное нарушение этих норм в таких компаниях просто недопустимо, по целому ряду причин.
Я уже не говорю о том, что говорить о продуктивной работе сотрудников при постоянном их перенапряжении, вызванном регулярной переработкой, бессмысленно.
Не хотите работать — не работайте. Будто бы я вас заставляю, ей Богу.
И да, я работал в достаточно крупных международных компаниях, в том числе и всемирно известных, так что не надо мне рассказывать, как там работают. И работают в реально крутых компаниях не от звонка до звонка, поверьте.
А все остальное, что вы написали, лично для меня характеризует Вас как разработчика не очень хорошо. Но, опять таки, это просто потому, что вам, видимо не посчастливилось работать в реально классных командах, в которых есть чему и у кого поучиться. Но вот этот пункт меня аж прям расстроил:
просмотр предметов по всем курсам не радовал — базовые знания C/C++, история операционных систем, SQL и т.д
То есть вы всерьез и до сих пор, несмотря на какой-то(видимо значительный опыт) разработки считаете что это все ненужно? Да, наверное, для создание сайтов под ключ и прочих типовых интернет-магазинов это ни к чему, но веб-программирование на этом не ограничивается. Когда перед разработчиком встают серьезные задачи он должен, как минимум иметь возможность найти серьезные решения. А они далеко не всегда лежат в той плоскости, в которой мы привыкли работать. Вот тут-то и начинаешь вспоминать всякие дифуры, линейные алгебры тер.веры и прочие матаны. Я уж не говорю о том, что даже мне за свою не очень болшую практику приходилось писать расширение на C для PHP. Попробуйте поработать в компании наподобие Rocket-Internet, или какого-нибудь крупного финтех стартапа, например, всё поймете.
Я 8 лет на одном месте проработал.
Несколько раз пытался уволиться, но все заканчивалось звонком шефа и повышением зарплаты…
В последний раз поставил шефа перед фактом, что рабочее место новое уже найдено и ни под каким соусом не остаюсь, он согласился, но попытки вернуть не оставлял ещё несколько месяцев.
Условия были хорошие, но никакого профессионального роста не чувствовалось абсолютно, казалось что как программист я сдуваюсь.
Проводя собеседования разработчиков, я тут заметил одну интересную закономерность. Кандидата три за последний месяц было с несколькими пересекающимися характеристиками, как то:
— возраст 30 или больше
— соответственно продолжительный опыт работы, особенно на последнем месте (5 и больше лет)
— полное отсутствие понятия о современных популярных инструментах / фреймворках для своего языка (позиция php, junior / middle backend)
— диктаторского склада начальник на текущем (крайнем) месте работы, который упоминается каждый раз, когда я задавал вопрос «почему же вы использовали последние N лет свой велосипед X, когда для решения этой задачи, сообществом написано за эти N лет 100500 годных библиотек?»
В общем, прямо типаж наблюдаю: человек попал в какую-то конторку, там вроде бы тепло, начальник всё решает при помощи своего набора молотков десятилетней выдержки, учить новое не заставляет, за инициативу наказывает. И грустно это, т.к. сразу видно, что люди отстали от языка и сообщества на эти самые 5-10 лет. И самое печальное, что 30 лет, это тот возраст когда уже не так просто наверстать упущенное, разобраться в стеке, как скажем в 20. То есть мне лично слабо вериться, что если человек до 30 лет не состоялся как программист, то вряд ли он качественно повысит уже уровень когда либо.
А какой критерий для «состоялся как программист»?В данном контексте можно такой: «забыл про PHP, как про страшный сон» :-)
А если серьёзно, то на мой взгляд состоявшемуся программисту должно быть не суть важно какой язык или стек, он причинит проекту пользу в любом случае )))
При этом хорошим программистом я бы себя того не назвал(возможно и нынешний я не оч. хороший программист). Я бы сказал, что эти критерии каждый определяет для себя сам и найти единую точку зрения на это вряд ли возможно. И пользу проекту хороший программист принести может далеко не всегда. Иногда проекту как бы не нужна эта польза. Трудно ее приносить, когда вокруг тебя одни просиживающие штаны дядьки, сидящие на этом рабочем месте по N-дцать лет. Такому проекту хороший программист будет скорее во вред.
Так что я думаю, что человек состоялся, как программист тогда, когда он сам для себе это решил, либо это за него решило абсолютное большинство окружающий программистов. Желательно авторитетных.
Иногда проекту как бы не нужна эта польза. Трудно ее приносить, когда вокруг тебя одни просиживающие штаны дядьки, сидящие на этом рабочем месте по N-дцать лет.Так это, на мой взгляд, идеальная ситуация для проверки той самой состоятельности… Тут либо конформистское поведение возмёт верх, либо профессиональная этика. Всегда есть выбор: делать как коллеги (как начальство сказало, как «быстрее») или исходя из своего представления как должно быть. Иногда эти варианты могут и совпадать, но далеко не всегда.
Так что я думаю, что человек состоялся, как программист тогда, когда он сам для себе это решилО, это ощущение обычно бывает ещё в первый год… потом, правда, у адекватных людей проходит на значительное время )
Так это, на мой взгляд, идеальная ситуация для проверки той самой состоятельности… Тут либо конформистское поведение возмёт верх, либо профессиональная этика. Всегда есть выбор: делать как коллеги (как начальство сказало, как «быстрее») или исходя из своего представления как должно быть. Иногда эти варианты могут и совпадать, но далеко не всегда.
Это тема долгой дискуссии, но я задам простой вопрос: Зачем мне работать в таком месте, когда я могу пойти туда, где коллеги будут тянуть не назад, а вперед. В таких проектах, как правило, в итоге приходится делать работу за других людей, что само собой не допустимо. Я уж не говорю о том, что такие «коллеги» скорее свяжут тебе руки, чем позволят показать преимущества нормальных подходов. Ну и последняя пуля моей аргументации в том, что тебе все-таки нужно работать в команде. С кодом, который пишут твои коллеги. Если даже ты производишь 10% кода(что очень много для серьезных проектов), то остальные 90% кода всеравно остаются говном. А тебе приходится постоянно иметь с ним дело. Трудно производить что-то хорошее, что должно взаимодействовать с говном… Даже если это удается, то конечный результат всеравно говно, пусть и с ложкой меда. Хочет ли хороший программист быть в такой ситуации — вряд ли.
О, это ощущение обычно бывает ещё в первый год… потом, правда, у адекватных людей проходит на значительное время )
Совершенно верно, спору нет. Но это никак не противоречит тому, о чем я сказал. Понятие все-таки субъективное и одних и тех же программистов разные люди оценят по-разному. Кто-то скажет, что «этот парень чертовски хорош», а кто-то скажет обратное. И каждый найдет аргументы. Многие вообще скажут, что хороший программист это программист, который решает задачи бизнеса без оговорок на то КАК он это делает и как на длинной дистанции его решения будут удовлетворять критериям бизнеса.
А насчет проходимости — тоже верно. Я вообще думаю, что это ощущение должно появляться и проходить переодически на протяжении всей карьеры. Ты как бы преодалеваешь перевал и видишь вершину. Карабкаешься на нее, а она оказывается не вершиной, а очередным перевалом. Все мы понимаем, что нет предела совершенству) Только в программировании у тебя не просто горы с перевалами, а эскалатор, который едет в обратную от твоего направления сторону и остановки в развитии тут череваты.
Зачем мне работать в таком месте, когда я могу пойти туда, где коллеги будут тянуть не назад, а вперед.
Ну, это просто утрированный случай… На практике сложно найти работу, где все коллеги будут тянуть вперёд… Точнее, в начале карьеры несложно, но чем больше опыта, тем чаще приходится самому кого-то тянуть )))
чья идея просиживать штаны и цели тянуться никакой нету
ну, имхо, это 80% народа в любой профессии… куда ж без них?
Мой рекорд — 5 дней работы и увольнение по собственному.
Всё правильно, вот для этого и нужен испытательный срок. К сожалению, лично я всегда сталкивался с тем, что работодатель всегда рассматривает его только в свою пользу, чтобы при желании выгнать тебя с позором и без объяснений причин. При этом от тебя требуют хотя бы устных гарантий, что ты после приёма на работу быстро не уволишься. А если такие гарантии не даёшь, а наоборот говоришь, что надо сначала присмотреться, то тебя просто не берут.
— если человек вчера, условно, закончил универ, я могу допустить, что это просто junior, которому много предстоит узнать
— если передо мной 30 летний мужик, с 10 годами опыта в резюме, то похоже он не состоялся.
У первого есть шанс состоятся. У второго, имхо почти нет. Вот примерно такой смысл, вкладываю в это слово.
2. Думаю вы поняли про что я: не зная, как проверить самые главные качества кандидата (да ещё частенько путаясь, какие качества главные), проверяют те, которые легче проверить. Ну это всё равно как искать ключи под фонарём, потому что там светлее.
3. Такого списка или сценария у меня нет, я давно уже не проводил собеседования массово, тем более в ИТ. Но задача такая у нас стоит сейчас, возможно список/сценарий и появится, хотя скорее это будет целая технология поиска подходящих сотрудников и список будет лишь одим из звеньев цепи, который изолированно применять будет бессмыссленно.
4. Возможно у каждой организации будет (должен быть) свой список/технология, в зависимости от её потребностей.
Лично я просто составлял большой список вопросов разной сложности(да, для каждого проекта свой), но никогда не задавал их все. В основном, если искал кого-то на позицию выше Junior — строготехнические вопросы я почти не задавал. ИМХО, в процессе обычной живой беседы проще понять кто перед тобой, чем по каким-то вопросам конкретных реализаций. Технические вопросы использую такие, которые требуют пусть небольших, но рассуждений и ответ на которые можно вывести даже если ты их не знаешь. Все-таки нам больше важно как человек думает, а не что он знает. С Junior-разработчиками ситуация немного другая, потому что Junior по моему мнению должен быть в активной стадии обучения, а значит и память должна быть свежее. Более того, простые технические вопросы позволяют понять, насколько человеку вообще интересно программировать и что он вообще здесь делает. Очень круто, когда некоторые из них начинают вступать в дискуссию. Но, увы, все чаще и чаще, даже на позиции Senior в последнее время ко мне приходили людю, неспособные даже рассказать, в чем отличие абстрактного класса от интерфейса, что не может не печалить…
полное отсутствие понятия о… фреймворках для своего языка
Фреймворк если понадобится можно изучить. В чём проблема-то? Что такого критичного в знании/незнании новомодного фреймворка?
А обучаемость вещь такая — если мозг не тренировать на новом регулярно, то после 30, как я слышал, он эту способность теряет.
Изучить что-то не проблема, если ты постоянно этим занимаешься.
как скажем в 20
В 20 лет сложновато отстать на 10 лет.
А особенно иметь 10 лет опыта. :)
Да и новые технологии можно подтянуть, если умел пользоваться старыми. :)
Но по факту имеем разброс когда
а). человек в 20 обладает большим кол-вом актуальных познаний и минимальным опытом их применения
б). человек с 10-летним стажем имеет неактуальные знания и ноль знаний и опыта применения актуальных
И, по моему, скромному мнению, если человек (б) сам не подтянулся за всё это время, вряд ли стоит от него ждать успехов, я сделаю ставку на более молодого, в описанном случае.
Касательно области обсуждаемых знаний, я имею в виду не новомодные фреймворки, а мажорные версии языка, и мейнстримовые для сообщества парадигмы.
Хорошо, если человек о них читал сам.
б) Неактуальные знания при желании можно обновить. Просто на самом деле не многим проектам нужно что-то, кроме LAMP (если говорить о веб).
Если результат нужен здесь и сейчас, то лучше поставить на опытного с требуемым опытом (с требуемой технологией, возможно старой версии, вряд ли новая так уж сильно уехала вперед).
Если можно подождать, то можно на умеющего думать без опыта. Опыт дело наживное.
Некоторые компании берут на стажировку / стипендию, но таких мало.
А еще бы я оценивал по собственным проектам. Но тут тоже вряд ли будут сверхтехнологии.
Я стал программистом как раз потому, что захотел реализовать свой проект. :)
Главное, чтобы человек умел думать.
Умение думать тупыми тестами IQ проверять не стоит.
В 20 лет сложновато отстать на 10 лет.
А особенно иметь 10 лет опыта. :)
Мой сын попросил у меня финансирование на приобретение первых книг по программированию как раз лет в 10. И деньги не были потрачены зря: он эти книги освоил вполне успешно.
Так что к 20-ти уже имел те самые 10 лет опыта. :)
А вот где-то года через 4, если не ошибаюсь, он уже попросил меня обналичить его первые «электронные» несколько сотен долларов, полученные им за работу «по специальности». И книги уже заказывал и оплачивал сам. :)
Я был горд безмерно… :))
Всегда есть куда развиваться, можно сменить направление внутри одного большого проекта.
Главное следить что происходит вокруг в IT области а не ограничивать себя текущими задачами.
Но применять их нужно, если от них есть выгода. А не потому что все крутые перцы пишут на %framework_name% и на вас криво смотрят.
В программировании, обучение без практики, имхо, даёт ничтожный результат. Можно сказать что «знаешь о технологии», но сказать что знаешь технологию, не применив её ни разу, нельзя.
Отсюда я делаю вывод, что развитие должно в себя включать и применение на практике новых инструментов. Иначе это не развитие.
заявленные вендорами плюсы технологии, это в большинстве случаев маркетинговый булшит
Именно!
Потому обязательное требование знать фреймворки — характерный симптом некомпетентности интервьюера, желающего скрыть свою некомпетентность за крутыми понтами.
Иначе придется ждать пока человек изучит этот фреймворк. А бизнесу это не очень нужно, бизнес хочет готового специалиста.
А заявленные вендорами плюсы технологии, это в большинстве случаев маркетинговый булшит.
А я на них не ведусь :)
Фреймворки не решают моих задач.
Тут дискуссия: https://habrahabr.ru/company/mailru/blog/308788/
Отсюда я делаю вывод, что развитие должно в себя включать и применение на практике новых инструментов.
Пускай технология созреет.
Пускай другие на ней набьют шишек, а мы посмотрим. :)
Прыгать с технологии на технологию (не версию) не стоит, если нету проблемы в текущей технологии или плюсов новой. Разве начинать новые проекты.
А также на новую технологию сложнее найти специалистов.
очень важно быть выбранным в качестве руководителя проекта
Это уже проходили. Дурков нет и люди будут выбирать того, кто не будет их напрягать и чьи интересы совпадают с их интересами. Это совершенно не обязательно совпадает с интересами проекта, начальства, организации.
Я вообще суровый материалист и в эзотерическую
По-моему, вы правильно интерпретировали следствие, но почему-то поставили его на место причины.
сейчас есть более интересные дела, чем работа и каждодневное изучение того, что завтра уже устареет
в других каментах я писал, что нынешний ит на грани коллапса и скоро количество технологий будет таково, что никто толком не будет уметь пользоваться ими или точней пользоваться будут, но никто не будет понимать, как это работает вцелом
как например современный процессор или операционная система
появятся специальные люди, которые будут изучать возникшую ошибку в результате соединения готовых библиотекх и технологий в стеке, потому что те, кто пишет код не будут понимать и у них не будет времени изучать что-то новое, т.к. еще старое не осилил
быстрый рост технологий и породил это явление, когда человек не то чтобы не хочет учить новое, а у него тупо нет времени на это, потому что после 9 часов торчания в офисе надо еще час ехать домой и заниматься с семьей, пожрать и готовиться ко сну, чтобы завтра опять торчать 9 часов в офисе
— кстати наглядный пример
надо из гуглокалендаря постить записи в пейсбук
ну я знаю про их апи и решил посмотреть, нет ли библиотеки ихней и нашел в гугле
я предвидел гимор с авторизацией через ссл и так оно и случилось — 2 дня только на гугление ушло
теперь проходит, но выдает 404, хотя там тестовая консоль разработчика выдает правильный результат
и вот я имею кучу пхп файлов, плохую документацию без описаний функций библиотеки и непонятно что мне теперь с этим делать?
я вот не знаю как работает ссл, знаю что надо какой-то сертефикат, но откуда он берется в пхп — неизвестно, в мануале к библиотеке ничего не говорилось про установку сертефиката
написано только, что надо ключ создать или юзать oauth
библиотека гугла на диске занимает 24 мегабайта!!!1
что она делает? передает гет запросы и в ответ выдает джейсон и состоит из кучи разных библиотек сторонних разработчиков с гитхаба, зато ставится композером одной командой
вот как профи программист будет искать ошибку и сколько он потратит времени?
кстати насчет рс485 это не просто первый уровень отличия, там у трансивера есть вывод переключения прием/передача и работает это хоть и поверх ком порта, но есть в порт можно тупо писать и читать, то тут надо еще и управлять 3м контаком, на который повешан этот вход управления в адаптере
на днях пришли 2 адаптера усб-рс485, а я даже не знаю какой вывод там китайцы задействовали
библиотека гугла на диске занимает 24 мегабайта!!!1
Нафиг такие библиотеки:
https://habrahabr.ru/post/140581/
Они развивают псевдопрограммирование.
объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция
Верно! А потом приходят фанаты ФП и…
SVN… это тоже плохая черта, причём говорящяя много обо всех, кто его использует в проекте. Почему? Ну, использовать инструменты двадцатилетней свежести, когда есть толковые современные замены — это всё же показатель низкой квалификации.
Ну а зачем тогда создавалась возможность по разрешению конфликтов?
Конфликтов желательно избегать, а то одному не всегда понять, как его решить. С одной ветки пришло одно, с другой другое. :)
Я тоже, как начал более нормально работать с git-ом (до этом только умел add|commit|push|pull и он мне жутко не нравился, так как вся разработка была в одной ветке, мастер правили на сервере по живому) думал так.
Но если есть необходимость работать с тем же куском кода в один день, то лучше не вносить правки до того, как коллега не запушит свои коммиты и не даст зеленый сигнал.
я не штатный программист, я просто решаю ит вопросы разного характера при помощи софта и железа
оплата фиксированная и пока я думаю взять 500 евров, т.к. не знаю много это или мало за такую работу
мне нравится решать нестандартные вопросы, организовывать из кубиков, но вот конкретно код писать я не умею, хотя делаю это лет 20 наверное уже
Охохохо, мне кажется, что вы серьёзно подставились. Потому что между TCP и UDP транспортом есть небольшая, но критически важная разница в виде абстракции, которую каждый из них предлагает.
TCP — это труба из байтов. С ним всё отлично (почти), байты всегда приходят в том порядке, что отправлены и доставка гарантируется.
UDP — это негарантированная передача блобов ограниченной длины. Стоит напороться на какой-нибудь перегруженный маршрутизатор, и пакеты могут не дойти совсем. Приложение обязано быть готово к тому, что блобы придут в любом порядке, и могут не придти вообще, отправляющая сторона тоже должна быть к этому готова. Также есть куча всяких граблей вроде поддержки фрагментации пакетов в сети и MTU, которые неявно задают ограничения на передаваемый размер блоба.
Т.е. если вы пишете конечный автомат, управляемый по UDP, вы должны быть готовы к куда большему пространству подаваемых в него команд, плюс самостоятельно реализовать алгоритм переотправки застрявших на отправителе команд, итд. // да, есть библиотеки, но требования понимания, что внутри происходит это не отменяет.
N.B. это больше про людей, которые применяют stackowerflow-driven development, и не относится к людям, умеющим читать нормальную документацию перед использованием чего-либо.
И да, трудно не согласиться, " опасные" они люди
> начинающие программисты.
Эх, если бы…
Разные мелкие скрипты, которые могут мне облегчить жизнь, но не стоят вложения серьёзных усилий, или куски на ангуляре, в котором я, мягко говоря, плохо разбираюсь и неоткуда быстро взять системные знания, а задачу нужно решить.
байты всегда приходят в том порядке, что отправлены
Вернее: гарантирует целостность передаваемых данных даже если пакеты придут не в том порядке.
Что тут не так? Получаешь практический опыт, ходишь на курсы?
Квалификация коллег-программистов: ожидание и реальность