Статья Страх и ненависть в IT меня огорчило.
Вовсе не потому, что я разделяю чувства автора, а потому, что их разделяют многие хорошие разработчики, убивающие себя, свои проекты, индустрию и человеческий прогресс в целом.
Он помахал рукой, да? Каким бы я ни был страстным футуристом и адептом автоматизации, эта статья о вещах более приземленных, чем Светлое Будущее.
Поэтому я оставлю судьбу человечества на следующий раз.
Теперь я хочу, наконец, высказаться об огромном количестве негатива, боли, страха и ненависти, скрывающихся в недрах IT-сообщества, прикрытых небольшим теплым слоем хайпа технологий и крутых инженерных решений.
Отказ от ответственности
По своему опыту знаю, как сложно применять то, о чем мы будем говорить, в аутсорсинге, особенно на огромных проектах.Я не хочу, чтобы большинство разработчиков сейчас подумали «окей» и закрыли статью, но и переманивать я не знаю, да и обманывать не хочу.
Поэтому я вас прошу: продолжайте, не все так плохо.
Чрезмерная сложность
Автор оригинальной статьи подчеркнул очевидное: разработчик больше не контролирует, как работает его решение.Для многих это было очень комфортно, давало ощущение спокойствия и контроля.
И этот комфорт остается отправной точкой: по сей день, несмотря на переход из категории творцов в категорию ремесленников, программист все еще пытается получить удовольствие от процесса создания чего-то из ничего.
С использованием творения других людей этого удовольствия невозможно достичь, ты чувствуешь себя на высоте мозаичист который успешно подобрал камешки.
(Но мозаика – это тоже искусство, что тут плохого? Хм…).
Примите неизбежное.
Лишь избранные мифические персонажи могли создавать планеты из ничего.
Используя правильные компоненты, используя известные подходы и правильно подумав , вы сможете создать элегантную систему и получить удовольствие, сравнимое с удовольствием от «чистого» творения.
И это будет работать на любом уровне: от нового перечисления до проектирования высоконагруженных систем.
Технически все не так радужно.
И это связано с двумя вещами: временем и коллегами.
Наши решения должны удовлетворять двум критериям: затраты должны быть ниже ожидаемой среднесрочной выгоды, а затраты на поддержку должны быть ниже долгосрочной выгоды.
Поэтому при нынешних объемах разработки мы неизбежно приходим к решениям типа «мы используем этот клиент везде»: он быстрый, и вся команда умеет с ним работать.
А если клиент достаточно популярен, то и будущие члены команды смогут это сделать.
Ищите баланс между крайностями возвышенного творчества и бездушным конвейером и получайте от этого удовольствие!
Слишком много материала и интервью
Выбор идеального компонента для текущего решения маловероятен.Даже если он существует, он один из тысячи.
Каждый разработчик/команда/компания выбирает что-то для себя, учится обходить подводные камни.
и начинает требовать такого же опыта от других.
Это глупо.
Так же глупо, как цепляться за утраченный контроль над своим творением.
Каждый раз, когда я читаю очередную историю боли из интервью «они хотят знать полный список изменений в ES6», мне становится грустно.
Все, что они хотят знать, это то, подходишь ли ты для их команды.
А «они» — это мы, просто по другую сторону стола.
Мы не знаем, как об этом спросить, и не знаем, что ответить.
Разорвите этот порочный круг непонимания! Перестаньте проходить собеседования и начните искать работу, которая вам подходит. Скажите, что вы думаете.
Примите, что команда, которая вам подходит, — одна из двадцати.
Найди ее.
Перестаньте искать того, кто знает то же самое, и начните искать того, кто даст вам что-то новое.
Спросите, что для вас важно.
Примите тот факт, что, задавая вопросы на знания, вы просто создаете подробное резюме.
Найдите человека, который будет говорить с вами на одном инженерном языке и разделит ваши принципы и подходы к разработке.
ИТ-специалисты
Люди тоже.Люди разные и в то же время ксенофобские; Довольно полезная черта с точки зрения естественного отбора.
При работе в команде это не помогает, и с этим мало что можно поделать: клетчатым будет интересно вместе играть со своими игрушками, хардкорные инженеры, перекинувшись парой слов, будут вместе создавать вечные вещи.
Примите: люди разные.
Если вам нужны люди, ищите «своих».
Менеджеры, вероятно, являются источником наибольшей ненависти.
И тут мы снова попадаем в порочный круг: руководитель не хочет или не может выполнять свою работу – и поэтому мы от него отворачиваемся и делаем все сами.
Ему все равно бесполезный .
Этот вопрос уходит в
Бизнес
Многие копии были сломаны на поле битвы между бизнесом и технологиями.Не хочу повторяться, поэтому опущу большую часть контекста и перейду сразу к основной идее.
За костыли в решениях отвечает только разработчик.
Только бизнес (в лице руководителя проекта, руководителя проекта, директора и т. д.) несет ответственность за неудачи проекта.
А это требует много сил.
Научитесь рассчитывать стоимость быстрых решений.
Научитесь доказывать, что экономия в месяц сейчас приведет к перерасходу в два месяца завтра.
Или не будет. Примите тот факт, что хороший код сам по себе не решает проблем, но компании также не хотят погружаться в технические долги! Вы можете не играть в Bullshit Bingo. Называй вещи своими именами, прежде чем они доберутся до тебя и ты начнешь называть это своими именами.
красиво.
это имена.
Девелопер может себе позволить, если честно — у него нет бюджета и нет ответственности.
В крайнем случае, разработчику легко найти новую работу, где он чуть меньше боится честности.
Выскажите свое честное экспертное мнение о проблеме и ее решении, и пусть решение принимает бизнес.
И различать нежелание принимать решение и поиск решения.
Мы научили бизнес признавать, что существует быстрый взлом.
Они знают, что если мы немного поднажмем, то добьемся результатов в пять раз быстрее.
Это отказ от решения, и мы не должны мириться с таким поведением.
Менеджер в поисках решения будет декомпозировать и расставлять приоритеты, стремясь показать результат в свои сроки.
И мы обязаны в этом помочь.
Проклятие аутсорсинга Все, о чем я говорю, теряет большой смысл, когда между реальным бизнесом и разработчиком появляется структура, для которой бизнес — это сама разработка.
Естественные причинно-следственные связи серьезно страдают, когда есть сторона, для которой не важно развитие и успешное функционирование бизнеса.
Для которых имеет значение только количество ресурсов, потраченных на развитие, и чем больше, тем лучше.
И даже когда аутсорсеры позволяют разработчикам напрямую общаться с заказчиком, с другой стороны, в недрах огромной корпорации может оказаться равнодушный менеджер, безответственный и безвольный.
В свое время я просто убежал от подобной ситуации, и мне нечего посоветовать.
Разработчик должен понимать бизнес настолько, чтобы время, необходимое для формулирования вопросов и понимания ответов, было сопоставимо со временем, необходимым для поиска технического решения.
Мы больше не можем говорить: «дайте мне спецификацию, и я все сделаю», такая спецификация — почти полное решение.
Наша работа больше не заключается в перестановке байтов вручную; теперь у нас гораздо больше времени, чтобы проанализировать всю картину.
Но не стоит принимать «вот куча задач, разберись, что там и как».
Бизнес очень часто экономит время на поиске бизнес-решения, и задача разработчика — увидеть, что развивать нечего и указать на это бизнесу.
Это тяжелая работа и не для всех.
Обо мне
В 20 я сутками программировал и с удовольствием шёл на работу.В 25 лет я увидел, как все плохо, и мучился, ожидая пятницы и любимого проекта, в котором все было хорошо.
В 30 лет я с увлечением работаю.
с нетерпением жду пятниц и выходных.
Я не знаю, что будет еще через 5 лет, но надеюсь, что не разочаруюсь в своих нынешних убеждениях.
Наш регион дает нам очень многое – свободу самовыражения, развития, знаний, интересный опыт и достойные деньги.
Наш регион очень молод, это еще ремесло, и за нами нет династии ремесленников-предков.
Мы пока не знаем, как в нем работать.
Поэтому мы злимся, страдаем и выгораем.
Мое решение является презумпцией разумности.
Я больше не делаю выводы о человеке на основании его кода, писем или задач в JIRA. Более того, я стараюсь не думать плохо о том, что он говорит или делает. Ведь пока мы работаем над общим делом, и пока он прямо не сказал «Я хочу навредить проекту», он мой союзник, и вместе мы сможем сделать больше, чем в одиночку.
Пока никто не сказал, хотя некоторых коллег я иногда загоняю в этот угол :) Теги: #Карьера в IT-индустрии #выгорание #философия развития #мир — прекрасное место
-
Ведите Бизнес С Облачным Хостингом Sage 50
19 Oct, 24 -
Мобильные Карты Теперь И На Русском Языке
19 Oct, 24 -
Астротрекер На Два Ужина
19 Oct, 24
