Скорее всего — это «перевод» того, как эти времена объясняют себе англичане. Тут в тексте про русский написано
«Я прочитал книгу» – какая разница, я ее прочитал только что, десять лет назад или в принципе читал?
И вот объясните мне теперь, почему кто-то за меня решил, что какая именно мне разница, когда я прочитал книгу? Скорее надо понимать, не «какая мне разница», а что по этой фразе я как раз и не могу определить точный контекст времени. Следовательно, для перевода на английский возможны несколько вариантов и все будут правильные.
Аналогично — попробуйте англичанину объяснить родовой признак? (риторический вопрос)
Лично мне хочется взять эти «объяснения» и совместить их с автором.
На работе вам платят оптом. За 8 часов 5 дней в неделю.
Но ведь я не всем подряд продаю оптом свои часы. )))
Он и несёт ответственность за задачу в целом.
Тут как договоритесь. Я менеджера «дёргаю» только в критичных случаях, когда требуется административный ресурс.
В больших фирмах ответственность бывает сильно размыта. Но я стараюсь не подводить.
С точки зрения штатного сотрудника я хотел высказать мнение по первому пункту, что штатный работник обходится дороже. Противоречие мне видится в конфликте с пунктом «Необоснованные запросы заслуживают необоснованных ставок»
что это складывается с тарифом за срочность (решение чрезвычайной ситуации в полночь обойдётся минимум в два часа с тарифом 160%, даже если займёт у меня 15 минут)
На работе бывает, что к вам прибегают и сотрудники и начальники и вот прям щас брось всё и что-то правь и никто надбавку за срочность не предлагает )))
можно написать прототип на таком языке или с использованием такого инструмента, чтобы сделать версию для производства не представлялось возможным
Сначала надо найти специалиста по такому языку. Представляю как обрадуются компании такому предложению? Особенно если после создания прототипа выяснится, что переписать его на целевом языке не получится в принципе. Дада, мы все тут обожаем делать одну и туже работу по два раза.
На такую длинную простыню ОДИН маленький отрывок кода, на основе которого делается вывод эмоционального клише?
>> Что повлияло на ваше инженерное мировоззрение?
Когда я понял, что у меня такие же руки, ноги и голова как и у людей с большими чем у меня достижениями. Дело даже не в инженерном или не инженерном мышлении. А в умении найти видение цели настолько, чтобы эта цель стала почти осязаемой, только ещё не воплощённой. Наверняка есть инженер, который умеет сочинять музыку или рисовать картины. Является ли его мышление инженерным? Пример. В чём состоит задача дирижёра? — воплотить замысел композитора.
Следовательно, есть замысел, а есть воплощение. Наверное в каждой сфере есть «инженер», который умеет перейти от замысла к воплощению. Вот как такой человек называется — не знаю. )))
Честно говоря из всех видов отношений, с которыми приходилось сталкиваться по работе, самые неприятные — это когда работу, которая вас более чем устраивала, отнимают кому-то другому, да ещё и, возможно, с повышением того чувака. Вот очень неприятно, т.к. дальнейшие перспективы — смена работы.
Может и дадут ему тимлида — значит это говорит об уровне начальника и тогда переживать не стоит, что вы у такого начальника не работаете.
В конце концов — работа — это не только ваши функции, но и люди, которые вас окружают. Тут на хабре проскакивала история, что в компании была группа программистов, в которую затесались даже те, кто не умел хорошо программировать, но были на хорошем счету, т.к. программирование — это не только кодирование. А когда людей с невысокой квалификацией к программированию поувольняло новое руководство, то и уровень качества сразу упал.
Так что самое лучшая позиция — не надо предвзято относится к человеку, пока с ним не познакомились поближе. Жизнь очень неожиданно иногда поворачивается.
Помогая бездарному человеку обмануть начальника/преподавателя, вы снижаете свою конкурентоспособность и наносите существенный ущерб обществу в целом
Это как посмотреть. В то же время вы расширяете свой рынок сбыта, потому что этот человек может снова придти к вам и принести новый заказ. По мне так натуральный субподряд. Не?
Главное, чтобы этот человек не стал сам делать что-то важное не имея соответствующей квалификации и не нанёс этим непоправимый ущерб.
По мне ваш вывод, что легализация отношений означает перевод заказчика в ранг начальника неверен. Легализация отношений означает оформление юридических документов на основании чего вам оплачены деньги с которых вы, соответственно, должны были бы заплатить налоги. Только и всего.
При желании крайним можно сделать любого. Если оценку результата работы оставить на дед-лайн, то такого сотрудника и будут делать крайним, не важно, программист это или менеджер. Поэтому думаю, что правильным будет при возникновении задержек сообщить менеджеру об этом, т.к. именно он отвечает за сроки. А если наступает дедлайн для программиста, то ему стоит обезопаситься и сказать, что он возьмётся за работу в этом режиме, если на нем не будет ответственности, за которую накажут.
Дед-лайны не наступают неожиданно. Есть конкретный человек, который заранее не поинтересовался состоянием дел.
Точно! Бить врага его же оружием. Но про это в статье ни слова. Круг замкнулся.
Собственно ничего нового я для себя в статье не прочитал. Эта проблема есть не только среди программистов. Это вообще проблема по жизни. Можно даже было бы придумать модное название — «паразитический терроризм». Так сказать в тренде «новых» веяний. По сути — это когда змея кусает себя за хвост. Палка ведь о двух концах и навешивание ярлыков работает в обе стороны.
Простите, но статья не завершена. Одним из принципов технически образованного человека является не только обнаружение проблемы, но и поиск её решения. Вы проблему обозначили, а решения не предложили никакого. Это как обсуждать, что жить хорошо, но вот непредсказуемая погода все портит.
В жизни полно людей, которые могут присесть на шею. Общения с ними не избежать, но можно ограничить, дав понять такому человеку, что паразитировать на вас не получится. Он сам отвалит, искать другого «хозяина».
Вот было бы интересно пообщаться на собеседовании с некоторыми сотрудниками компании, чтобы обсудить какую-то мою проблему, чтобы оценить степень готовности их к сотрудничеству, а заодно и их техническую подкованность. Задача ведь никогда не сообщает о своём решении, поэтому интересно посмотреть на готовность будущей компании обсуждать проблему, которая возникла у меня. Ведь рано или поздно проблема возникнет у меня при работе именно в этой компании и мне бы не хотелось остаться один на один с проблемой в ситуации, когда у начальника одни права, а у меня только обязанности.
Простите, далеко не ответ. Так, чуть холивара в «ночную смену».
сотрудник X иногда дольше делает то что Y способен сделать быстрее
Весьма субъективная вводная, т.к. никогда ни одна компания не даст одну и ту же задачу разным сотрудникам с целью посмотреть, а кто тут у нас самый быстрый? Отсюда несколько бессмыслен вопрос, сколько должны они получать по отношению к друг другу? Тут иногда даже на работу берут по непонятным критериям (ну вот прям срочно и сейчас надо взять человека и даже на тёплое место).
Если сотрудник X хочет получать больше, то пусть он пойдёт и попросит себе прибавку. А может его и сейчас всё устраивает и вы вообще зря переживаете. Ну, подумаешь, 10-15% разницы? Лично я бы начал шевелиться, если бы речь шла о разнице в 40-50%.
Подумайте, что есть ещё нематериальные стимулы, например, работать из дома? Может X-у до работы час добираться на машине и пара дней в неделю работы из дома компенсирует ему затраты на бензин? Вот вы и сэкономили на ЗП. Все довольны. )
Я бы анимированные гифки вставил, например, а то название способов аутентификации — это просто набор символов. И если читатель их ни разу не видел, то для него они так и останутся названиями.
Может быть именно с этого и стоило начать обзор? И может быть стоило немного рассказать об архитектуре протоколов, как их отлаживать, как настаивать? В статье не очень понятно в каком случае какому протоколу отдавать предпочтение. Тот же — SSO — это не только oAuth. Kerberos это же тоже SSO, только в рамках домена, чтобы пользователю не приходилось вводить пароль при подключении к каждому ресурсу. Можно ведь сделать, например, двухфакторную аутентификацию на основе kerberos. Можно сделать n-уровневую аутентификацию в принципе. Ведь читателю в принципе не понятно, а что такое уровень вообще?
То есть вы как Марфа, печетесь о многом, сначала о задачах, потом о проблемах и так по кругу
Я не вижу в этом ничего плохого. У каждого человека должны быть внутренние стопоры как в отношении делания, так и в отношении неделания.
Накидать проблем...
Всё-таки программный продукт имеет много качеств, которым надо удовлетворять — цена своего качества, цена сложности поддержки в будущем и в итоге само кодирование занимает небольшое количество времени по отношению к общему решению. Многие проблемы существуют ещё до начала написания кода. Просто вначале профессии не задумываешься об этом. Отсюда и куча холиваров, когда дискуссия превращается… превращается дискуссия… Поэтому и решения надо разделять на программные и «кодированные». (Если решение работает, какие могут быть к нему претензии? «Ты плохо спрограммировал!» — да плевать, когда работает. Если закодировано «плохо», то вопрос к менеджеру, т.к. он не описал, что значит «хорошо», чтобы кодировщик мог сам себя контролировать)
Мне в последнее время кажется, что надо разделить «программистов» на две части — кодировщиков и собственно программистов. Всё-таки странно называть одинаковым названием людей, квалификация которых зависит от языка. Знаешь JavaScript — программист. А кто не знает — не программист? А если можешь решить задачу на C# и не можешь тоже самое сделать на Java? Поэтому написать «выдающийся» кодировщик будет уместнее, т.к. он знает хитрости реализации конкретного решения на соответствующем языке (а иногда и в соответствующей виртуальной машине языка). В то время как программист не зависит от языка программирования и он принципиально решает задачу и ему тонкости языка не важны. Поэтому среди программистов будут свои выдающиеся люди, но уже с другими способностями.
Отсюда вполне логично, что можно выходить из коробки в области кодирования, а можно выходить из коробки в области программирования. И поэтому в дискуссиях на тему «эффективности» нужно видеть грань между кодированием и программированием и не предъявлять каждой из этих областей требований из другой. Именно таким образом можно избежать «накидать проблем».
Аналогично — попробуйте англичанину объяснить родовой признак? (риторический вопрос)
Лично мне хочется взять эти «объяснения» и совместить их с автором.
В больших фирмах ответственность бывает сильно размыта. Но я стараюсь не подводить.
На работе бывает, что к вам прибегают и сотрудники и начальники и вот прям щас брось всё и что-то правь и никто надбавку за срочность не предлагает )))
На такую длинную простыню ОДИН маленький отрывок кода, на основе которого делается вывод эмоционального клише?
Когда я понял, что у меня такие же руки, ноги и голова как и у людей с большими чем у меня достижениями. Дело даже не в инженерном или не инженерном мышлении. А в умении найти видение цели настолько, чтобы эта цель стала почти осязаемой, только ещё не воплощённой. Наверняка есть инженер, который умеет сочинять музыку или рисовать картины. Является ли его мышление инженерным?
Пример. В чём состоит задача дирижёра? — воплотить замысел композитора.
Следовательно, есть замысел, а есть воплощение. Наверное в каждой сфере есть «инженер», который умеет перейти от замысла к воплощению. Вот как такой человек называется — не знаю. )))
Может и дадут ему тимлида — значит это говорит об уровне начальника и тогда переживать не стоит, что вы у такого начальника не работаете.
В конце концов — работа — это не только ваши функции, но и люди, которые вас окружают. Тут на хабре проскакивала история, что в компании была группа программистов, в которую затесались даже те, кто не умел хорошо программировать, но были на хорошем счету, т.к. программирование — это не только кодирование. А когда людей с невысокой квалификацией к программированию поувольняло новое руководство, то и уровень качества сразу упал.
Так что самое лучшая позиция — не надо предвзято относится к человеку, пока с ним не познакомились поближе. Жизнь очень неожиданно иногда поворачивается.
Главное, чтобы этот человек не стал сам делать что-то важное не имея соответствующей квалификации и не нанёс этим непоправимый ущерб.
По мне ваш вывод, что легализация отношений означает перевод заказчика в ранг начальника неверен. Легализация отношений означает оформление юридических документов на основании чего вам оплачены деньги с которых вы, соответственно, должны были бы заплатить налоги. Только и всего.
Дед-лайны не наступают неожиданно. Есть конкретный человек, который заранее не поинтересовался состоянием дел.
Собственно ничего нового я для себя в статье не прочитал. Эта проблема есть не только среди программистов. Это вообще проблема по жизни. Можно даже было бы придумать модное название — «паразитический терроризм». Так сказать в тренде «новых» веяний. По сути — это когда змея кусает себя за хвост. Палка ведь о двух концах и навешивание ярлыков работает в обе стороны.
В жизни полно людей, которые могут присесть на шею. Общения с ними не избежать, но можно ограничить, дав понять такому человеку, что паразитировать на вас не получится. Он сам отвалит, искать другого «хозяина».
Весьма субъективная вводная, т.к. никогда ни одна компания не даст одну и ту же задачу разным сотрудникам с целью посмотреть, а кто тут у нас самый быстрый? Отсюда несколько бессмыслен вопрос, сколько должны они получать по отношению к друг другу? Тут иногда даже на работу берут по непонятным критериям (ну вот прям срочно и сейчас надо взять человека и даже на тёплое место).
Если сотрудник X хочет получать больше, то пусть он пойдёт и попросит себе прибавку. А может его и сейчас всё устраивает и вы вообще зря переживаете. Ну, подумаешь, 10-15% разницы? Лично я бы начал шевелиться, если бы речь шла о разнице в 40-50%.
Подумайте, что есть ещё нематериальные стимулы, например, работать из дома? Может X-у до работы час добираться на машине и пара дней в неделю работы из дома компенсирует ему затраты на бензин? Вот вы и сэкономили на ЗП. Все довольны. )
Мне в последнее время кажется, что надо разделить «программистов» на две части — кодировщиков и собственно программистов. Всё-таки странно называть одинаковым названием людей, квалификация которых зависит от языка. Знаешь JavaScript — программист. А кто не знает — не программист? А если можешь решить задачу на C# и не можешь тоже самое сделать на Java? Поэтому написать «выдающийся» кодировщик будет уместнее, т.к. он знает хитрости реализации конкретного решения на соответствующем языке (а иногда и в соответствующей виртуальной машине языка). В то время как программист не зависит от языка программирования и он принципиально решает задачу и ему тонкости языка не важны. Поэтому среди программистов будут свои выдающиеся люди, но уже с другими способностями.
Отсюда вполне логично, что можно выходить из коробки в области кодирования, а можно выходить из коробки в области программирования. И поэтому в дискуссиях на тему «эффективности» нужно видеть грань между кодированием и программированием и не предъявлять каждой из этих областей требований из другой. Именно таким образом можно избежать «накидать проблем».