Coder vs. Developer vs. Engineer — а какой Job Title у тебя, %username%? / Habr

Computer Scientist, Software Engineer и Coder заходят в бар.
— О, а вот и программисты! — окликает их бармен…

Я знаю людей, которые программируют уже не один десяток лет, но обижаются, когда их называют «программистами«. А по запросу Coder vs Developer vs Software Engineer в гугле находится 113 000 000 ссылок: 1 2 3 4 5 6 7 8 9 … 113 000 000. Что интересно, можно найти совершенно противоположные мнения об одном и том же. С чем-то я согласен, а с чем-то в корне нет.

Последние же несколько лет так вообще постоянно подливают масло в огонь, появляются какие-то совсем странные программисты, которые называют себя Creative Technologist, Creative Coder и Interactive Developer.

Давайте же попробуем разобраться.

А какой Job Title у тебя, %username%?

Итак, расслабьтесь, если говорить о России, то мы тут на самом деле все Инженеры-программисты (или вообще просто Программисты). Все эти непонятные тайтлы придумали где-то там, а здесь они звучат прикольно и пишутся необычно. Я вот вообще представляюсь как Lead Interactive Architect, что ничего не говорит о том, что я тут делаю.

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

Данная классификация не подразумевает какого-то абсолютного порядка и вложенности одних категорий в другие. Речь пойдет о следующих группах людей так или иначе относящихся к программированию:

• Scripter
• Coder
• Hacker
• Software Developer
• Software Engineer
• Computer Scientist
• Creative coder

Scripter

Изначально, скриптами называли небольшие программы на простых языках. Вспомним Shell scripts, Batch files, AppleScript, JavaScript, ActionScript, VBScript. Их основное применение — автоматизировать повторяющиеся однотипные задачи.

Это сейчас на JavaScript можно написать Flash IDE в браузере, но «тогда» его использование ограничивалось в основном прокруткой дурацкого текста в статусной строке. Это сейчас ActionScript 3 является полноценным ООП языком, на котором пишут enterprise приложения, но «тогда» у самого первого не было даже текстового представления, действия надо было выбирать из списка, по одному на key frame.

Но смысл, тем не менее, остался. Сейчас даже дизайнер может при определенном желании написать себе скрипты для автоматизации чего бы то ни было в своей повседневной работе. Что я, кстати, весьма приветствую. Это довольно печально, смотреть, как дизайнер, например, рисует 100 «случайных» элементов руками. А еще печальнее, когда ему приходится их все перерисовывать.

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

Иногда можно услышать в корне неправильное определение скриптинга — писать инструкции, которые парсит и выполняет другая программа. Но ведь это и есть код. Инструкции, которые выполняет что-то другое.

Coder

Кодер — это человек, который переводит из одного языка в другой. Проще говоря, инструкции на «русском матерном» преобразует в инструкции на некотором языке программирования, будь то Java, PHP, C# или какой-нибудь другой, тысячи их. Разумеется, соблюдая правила и требования пратформы и окружения, где этому коду потом выполняться.

Я сам не люблю этот термин. Когда кто-то говорит «coder», я представляю себе человека, который бездумно пишет код, главное и единственное свойство которого — он компилируется; и этот человек не в состоянии делать что-то бОльшее из-за отсутствия знаний, опыта или желания; вместо того, чтобы включить мозг и разобраться в проблеме, придумать решение, он максимум способен соединить куски кода с гугла, которые он даже не понимает как работают.

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

Yes, it is an open secret fact which Software Companies won’t say/accept — that Software Professionals specially in India are not programmers but mere coders, they are the assembly line workers. [via]

Отсюда идет ассоциация с обезьянами — Code Monkey.

Hacker

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

Сюда я отношу людей, которых можно назвать «geeks«. Конечно, это стереотип еще тот, но многие как минимум частично ему соответствуют: необщительные, с посаженным ночным сидением перед плохим монитором зрением, имеют физическое или математическое образование, знают C, используют Linux, любят копаться в исходниках и пересобирать все под себя, часто одной рукой пишут код, а в другой держат паяльник, имеют обширные знания тонкостей работы железа и софта, хорошо разбираются в низкоуровневом программировании. Их можно встретить на олимпиадах, они пишут софт для демосцены, занимаются reverse engineering разнообразных устройств, и вообще чрезвычайно умные и образованные люди.

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

Software Developer

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

• Flash Developer
• Java Developer
• .NET Developer
• …

Принято делить на категории по знаниям/опыту:

• Junior Developer
• Developer
• Senior Developer
• Lead Developer

Взяв декартово произведение этих двух списков, получим более-менее устоявшиеся подкатегории: Junior Flash Developer, Lead Java Developer, Senior .NET Developer, ну и так далее.

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

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

Существует миф, что одни разработчики в N раз более продуктивны, чем другие. Я очень рекомендую потратить час и посмотреть видео Greg Wilson — What We Actually Know About Software Development, and Why We Believe It’s True. Если вам жалко времени, то конкретно по этому поводу он говорит с 18-й минуты.

Разумеется, чем «старше» разработчик, тем больше ему нужно знать. К сожалению, у нас в институтах не учат проектированию enterprise систем (по крайней мере, в мое время не учили). Поэтому, всему приходится учиться по книжкам, у умных людей или на своих ошибках.

Необходимые знания же из области в область отличаются. Неправильно говорить, что Вася плохой разработчик, потому что он не знает чего-то. Скорее всего, он и не должен, потому что у него совсем другая область. Что можно сказать, так это, например, что Flash разработчики в основном имеют более низкий уровень общей алгоритмической подготовки, чем C++ разработчики.

Lead Developer / Team Lead

чаще всего отдаляется непосредственно от программирования и становится менеджером, поэтому нам не интересен. Есть много случаев, когда Senior Developer рос не в Lead Developer‘а, а в Super Mega Senior Developer‘а, превращаясь в ходячую энциклопедию по платформе/языку/фреймворкам — это заблуждение, что все хотят расти в менеджеров и руководить.

В небольших конторах / стартапах может быть вообще 1-2 программиста, которые цепляют себе тайтл Lead Flash Developer, а что, самый крутой девелопер тут и управляет всеми остальными 0 человеками. А потом его берут в нормальную контору джуниором. Так что это опять же не говорит ни о чем.

Software Engineer

В разговорной речи обычно употребляется с тем же смыслом, что и Software Developer. Описания

Software Developer и Software Engineer взятые с salary.com весьма абстрактны и довольно похожи. Зарплаты тоже +- одинаковы, хотя мне говорили, что люди с тайтлом Software Engineer получают больше.

По поводу значения слова Engineer в названии профессии в интернете ведутся холиворы и по сей день. Википедия говорит следующее:

Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

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

Software Engineering does not work — Real Software Engineering – Glenn Vanderburg.

А во многих странах, чтобы называть себя инженером, нужно иметь лицензию. Беднягам, приходится быть простыми Software Developer’ами.

Но тем не менее, я четко выделяю отдельную группу Software Engineer и считаю, что слово инженер по отношению к разработке софта очень даже подходит. Инженер отвечает за то, чтобы построенное им тупо не развалилось. Главное не сравнивать со строительством мостов. Люди строят мосты уже тысячи лет, а софт пишут лет 30 от силы. В конце концов, кому какое дело, если от нагрузки упадет плохо спроектированный сервис? А вот, когда дело доходит до самолетов и атомных станций, наверняка, там есть свои аттестации и лицензии. А в будущем, я надеюсь, чтобы называться Software Engineer, нужно будет сдавать экзамены и получать корочки.

Software Engineer должен обладать большим опытом и кучей теоретических знаний не только из Math, Computer Science и Software Engineering. Знание разных языков вторично. В конце концов, принципы OOP и O(n^2) во всех языках имеют одинаковый смысл. У разработчика из этой категории обычно очень большой кругозор, у американцев есть отличная поговорка: когда у тебя есть только молоток, все вокруг выглядит как гвоздь.

Поэтому меня раздражают позиции с названиями типа Java Engineer или Ruby Engineer. Инженер не может быть привязан к языку. И, черт побери, где-то была статья ровно по этому поводу, а я не могу ее найти, чтобы процитировать.

Так что нет, чаще всего Senior/Lead Developer это не Software Engineer, хотя многими своими свойствами и обязанностями они пересекаются. Другое дело, человек может быть инженером, в свободное время делать что-то на одной платформе, читать умные книжки, а (чуть не сказал днём) на работе быть загнанным в рамки другой платформы Lead’ом, и сидеть править код за бездырями, потому что платят больше. Это да.

Software Architect

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

It is actually pretty sad that in this industry you pretty much have to tack-on architect at the end of your title after a certain number of years in the industry, otherwise you lose a level of credibility and earning potential. I believe the word architect should die as applied to software, it is not necessary and often harmful. [из комментариев к статье]

Аналогии со строительством тут не работают. Знаниями, которые нужны для создания архитектуры системы, должен обладать Software Engineer или Senior Developer. Это зависит от того, делается ли архитектура в рамках какой-то платформы, или нужно разработать что-то сложное межплатформенное.

Программистам в своей работе постоянно приходится принимать те или иные архитектурные решения. Более опытным и продвинутым доверяют приложить руки к архитектуре больших проектов. Вот и все.

А вообще, архитектуризм — это клиническая болезнь. Постоянно приходится сталкиваться с людьми, которые пишут свой движок со своей супер архитектурой. Годами. Идеальный движок в вакууме тысяч абстракций, который никогда не сталкивался с практическим применением, ибо о реальный мир он разобъется как стеклянный шар о каменный пол. Сами там были…

Computer Scientist

В отличие от инженеров, которые озабочены прикладным применением конкретных знаний, ученые от CS изучают их теоретические основы. Аналогично математикам-теоретикам, которые доказывают почему те или иные формулы и алгоритмы работают в абстрактных моделях, Computer Science берет свои корни из Математики и наследует от нее методы рассуждения и доказательства теорем. Как и в остальных науках, ученые специализируются в той или иной области, например: построение и доказательство корректности алгоритмов (в куче областей), теория вычислимости, функциональное программирование, machine learning, computer vision итд.

Про ученых в последнее время в массе известно лишь из-за функционального программирования. Например, набрав какой-то рост, Scala споткнулась о собственную сложность (еще бы, The type system in Scala is Turing complete), а в Haskell никто не понимает что такое Monad.

Хотя, казалось бы «A monad is just a monoid in the category of endofunctors, what’s the problem?» [via]

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

Creative coder

В последнее время, с развитием технологий и инструментов, из скриптеров стал вырастать совершенно другой и весьма интересный класс программистов. Во многом этому способствовали Flash, Processing, Max/MSP, vvvv, JavaScript, OpenFrameworks, Cinder.

Именно из скриптеров, потому что цель изначально другая — использовать код, чтобы что-то нарисовать, оживить, изобразить, сыграть. Прийдя из художников, VJ’ев и других нетехнических областей, они стали быстро впитывать поверхностные особенности программирования и окружения, в котором приходится работать.

Человек задает вопрос «А как мне сделать вот это?». Гугл подсказывает код и как соединить разные компоненты вместе. Компоненты не обязательно софтварные, время от времени возникает необходимость использовать разное железо, например датчики через Arduino. Поэтому у Creative Coder’а в основном есть обширный запас поверхностных знаний. Но, не имея достаточной подготовки, опыта, а часто нужного склада ума, он не в состоянии сделать чуть более чем простой продукт. Потому что код сделан из копипаст и заплаток между ними.

Но тем не менее, Creative Coder’ы показывают потрясающую способность быстро собирать прототипы с вынесенными наружу параметрами. Используя различные технологии и связки между ними. В то время как Engineer будет вникать в теорию, а Developer писать фреймворк (который понадобится лишь один раз, для конкретной задачи), Creative Coder нагуглит и соберет уже рабочую программу. Которая, разумеется, предназначена для дальнейшей поддержки ровно никак, но кого это волнует?

Зачастую, креативность выражается как раз в подгонке значений этих внешних параметров — «а что будет, если здесь поставить 0.1, а тут 42?.. Класс!». Поэтому, в узких кругах существует мем «заниматься креативным кодингом», что означает на глазок подгонять какие-то параметры в коде для достижения всеобщей радости или каким-то образом иметь у себя в коде кусок, которые не понятно как работает, но поставленную цель достигает.

Creative Coder’ы с одной стороны похожи на Coder’ов: качеством кода, копипастингом, отсутствием желания разобраться в теоретических основах этого кода; с другой стороны у них есть желание развиваться, делать что-то прикольное, экспериментировать, пробовать новые вещи.

Также, их можно было бы просто назвать Junior Developer’ами и поставить точку, но, как я уже сказал, у них другая изначальная цель, а код используется, потому что с его помощью можно делать креативные вещи. Если Junior Developer углубляется в основы программирования и растет в Developer’а и дальше, то Creative Coder’у такой процесс роста не интересен. Он хочет расти засчет небольших интересных (исследовательских, одноразовых) проектов.

И вот тут я, честно говоря, не понимаю как Creative Coder работает в команде с другими разработчиками, потому что в терминах команды он Junior Developer, никак иначе. Никто ему не даст самостоятельные интересные проекты, пока он не научится правильно проектировать программы и писать код. Получается, все они работают либо в одиночку, либо с единомышленниками непрограммистами?

Тем не менее, есть примеры Creative Coder’ов, которые не стали игнорировать теорию и обладают нужным складом ума для проектирования разумных алгоритмов и вменяемого софта. Не ограниченные платформой, они подошли к Software Engineer с противоположной стороны от Software Developer и в то же время проявляют качества из категории Hacker.

Creative Technologist

В совсем последнее время можно увидеть объявления, где профессия описывается как Creative Technologist. Требования везде разные: от полудизайнера/полу-js-кодера без опыта программирования (sic!), до мастеров С++ и OpenGL.

Позиция эта выросла из необходимости digital агентств воплощать креатив в код. Соответственно, казалось бы, человек с дизайнерским мышлением и умеющий кодить был бы идеальным кандидатом на данную позицию. Но, как показывает практика, в основном, люди с дизайнерским мышлением — плохие разработчики (именно разработчики). Как-то это связано с полушариями мозга, я не медик и не психолог — мне пофиг.

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

Поэтому, у меня нет специальной категории Creative Technologist. Так себя называет либо Creative Coder, либо Software Developer/Engineer, который работает в мире digital агентств.

Interactive Developer

Человек хочет подчеркнуть, что он пишет софт, который взаимодействует с пользователем. Помимо софта для интерактивных инсталляций, Interactive в последнее время приписывают себе Flash разработчики и JS разработчики, которые экспериментируют с WebGL, Canvas и всяким более другим HTML5.

Заключение

Людям свойственно классифицировать наблюдаемые объекты по группам, часто с большой вложенностью — вспомните, например, биологию. Позднее, определив к какой группе может принадлежать конкретный объект, легко экстраполировать на него свойства этой группы.

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

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

И, если у вас до сих пор нет подобного списка, попробуйте составить свой, или возьмите этот. В будущем пригодится.

Ранги разработчиков / Habr

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

Junior Developer

• оптимист, всегда недооценивает поставленную задачу
• постоянно ощущает нехватку времени
• стесняется показать свое незнание
• постоянно наступает на грабли
• с трудом доводит проект до финальной точки
• тестер — враг — ибо находит баги
• менеджер — не воспринимается еще всерьез
• пока не ориентируется по ЗП, но если ему предложат на $50 больше в другом месте — может уйти
• рутинную работу считает сложной, но должен справляться

Developer

• пессимист, зачастую недооценивает свои силы и боится промахнуться в оценке
• всегда есть время на перекур и чашечку кофе
• не стесняется спрашивать у коллег по цеху, может даже нагло их эксплуатировать
• наступает только на грабли спрятанные в высокой траве
• скрипя зубами доводит проект до ума
• тестер — просто задолбал, хотя есть понимание, что сам налажал
• менеджер — зачем ему мои отчеты?
• уже знает свою рыночную стоимость, повышение ЗП не требует, но узнает о вакансиях на других фирмах, и иногда намекает о своей осведомленности
• если выполняемые таски и проект покажется не интересным, это негативно скажется на проекте — обычно сопровождается криками проект Г.., заказчик М…, и что Вы вообще понимаете в программировании

Senior Developer

• реалист, опираясь на свой опыт, видит «узкие» места проекта и закладывается на риски, а так же сообщает об этом менеджерам
• успевает и делать проект, и посидеть на «митингах», и еще и подсказывать коллегам
• может помочь ближнему, не стесняется сказать, что он чего-то не знает
• если и наступает на грабли — то тут два варианта:
• удачно завершенный проект — доставляет истинное удовольствие (и психологическое и материальное)
• тестер — советник в плане юзабилити
• менеджер — щит, который тоже не любит неадекватного заказчика
• хорошо знает себе цену, не стесняется требовать повышения ЗП
• прекрасно понимают, что работа может быть рутинной, но это не должно влиять на качество кода, может ворчать, но работу будет делать

Если Вы располагаете достаточным количеством ресурсов, и при этом в наличии как Junior’ы так и Senior’ы — то судьба проекта может сильно зависеть от состава команды, так что будьте внимательны:

• не стоит ставить Junior’а к зубрам программирования, если среди них нет человека способного заняться его обучением: и новичок ничему не научиться, и «зубры» будут в бешенстве
• если проект разрабатывается лишь Junior’ами — держите руку на пульсе такого проекта и купите валерьянку — себе и заказчику 😉
• не стоит садить Senior’а за проект уровня «для чайников» — проект будет сделан и сдан, вот только разработчик от скуки начнет думать о работе в другом месте

Ну и еще немного информации к размышлению:

Ошибки которые совершают разработчики, когда начинают задумываться о повышении ЗП:

1. Переоценивают себя — требовать ЗП не соответствующую Вашему уровню — это верный путь остаться без работы
2. Устраивать сыр-бор за 10% прибавку к ЗП — зачастую такое повышение можно решить без лишнего шума и криков
3. Узнать, что через дорогу платят на 100$ больше, впасть в депрессию на пару недель, и оказаться на улице, ибо повышать ЗП человеку который последнее время ничего не делает никто не будет — это очень распространенная ошибка, никогда не забивайте на работу, будьте профессионалами.
4. Считать, что в соседней конторе работа в 100 раз интересней.

Таки кросс-пост: Ранги разработчиков

Вершина, но не предел, или как стать Senior Developer

К концу статьи у вас будет список из лучших ресурсов и поэтапно расписанный путь к такой должности, как Senior Developer.

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

Люди привыкли стремиться к профессиональному росту. У каждого свои цели, но большинство из нас обязательно сойдется в главных утверждениях:

1. Мы не хотим прожить жизнь с клеймом «некомпетентный сотрудник».
2. Мы хотим, чтобы нас уважали коллеги.
3. Мы хотим чувствовать себя умными и совершенными.
4. Мы хотим быть ценными в своей отрасли.

Чтобы достичь вышеизложенных целей, нельзя просто почивать на лаврах, ожидая, что все само придет. Особенно в мире программирования, который постоянно совершенствуется, меняется, а объемы информации раздуваются с колоссальной скоростью. Поскольку все больше и больше разработчиков выходят из колледжей и буткампов, нам нужно регулярно оттачивать свои навыки.

Нет, будучи полиглотом, который знает 10 разных языков программирования и создал свою собственную версию Jarvis, вы не станете старшим разработчиком. Дело в том, что Senior Developer – это тот, кто обладает приличным багажом знаний, оказывает положительное влияние на младших сотрудников и в целом улучшает показатели эффективности своей компании. Вы можете знать все о функциональном программировании, но если при этом нет навыков продуктивного общения с командой, или ваши знания не представляют фактической ценности для конечного потребителя, вы не старший разработчик.

Задайтесь вопросом: насколько большой вклад вы привносите в свою компанию / стартап / бизнес? Старший программист может навести порядок в команде, использовать свой опыт для получения реальной выгоды и успешного взаимодействия заинтересованных сторон.

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

Главное правило – не стоять на месте. Не нужно зацикливаться на чем-то одном: расширяйте спектр возможностей, изучайте языки, СУБД, IDE, фреймворки, знакомьтесь с принципиально новыми подходами в области программирования, ведь кто знает, чем будут заниматься те же специалисты по машинному обучению через 5 лет? Все меняется, и нужно осваивать умения, позволяющие быстро адаптироваться в новых условиях.

1. Технические навыки

Старшие разработчики используют очень много «Почему» в понимании технологий:

• Почему есть эта проблема?
• Почему существует структура?
• Почему следует использовать именно такое решение?

Как программист, вы должны обладать хорошим представлением обо всех инструментах и идеях, которые могут принести пользу жизненному циклу разработки, а также выбрать инструменты, имеющие наибольший вес в рамках конкретного проекта. Senior Developer всегда задается вопросом: «Что и как можно изменить, чтобы сделать продукт лучше?»

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

Хороший пример mind mapping для JavaScript-программистов:

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

 

Если ваша специальность никак не связана с компьютерами, начните с изучения структур данных, алгоритмов и других основ. Зачем? Хоть технологии и меняются, базис остается прежним. Новичкам подойдет книга «Алгоритмы. Вводный курс». Хорошим вариантом для тех, кто знает основы, станет книга «Алгоритмические трюки для программистов», а вот профессионалы обязательно оценят «Алгоритмы. Построение и анализ».

Не обходите стороной и подкасты вроде Software Engineering Daily: они позволят вам оставаться в курсе текущих проблем и будущих перспектив всей отрасли.

2. Командные навыки

Данный аспект часто упускается из виду. Как вы работаете со своей командой? Относитесь ли вы к категории дерзких и упрямых, или же проявляете внимательность, охотно сотрудничаете и всячески поощряете членов команды? Senior Developer никому ничего не доказывает. Ему и не нужно: он сразу пишет чистый упрощенный код, а не такой, который  будет выглядеть демонстративным, но совершенно нечитабельным в глазах других программистов. Старший разработчик готов помогать другим и отвечать на все вопросы.

Социальная психология – важный инструмент, и книга «Как завоевывать друзей и оказывать влияние на людей» определенно должна занять вашу книжную полку.

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

3. Навыки клиента/пользователя

Могут ли клиенты или пользователи быть вами услышаны? Когда они что-то предлагают, вы понимаете, с какими проблемами они сталкиваются? Старший разработчик – это также внимательный слушатель, который может предложить дельные советы по решению проблем. Senior Developer отлично справляется с формированием отношений. Он понимает, что обе стороны, – и  клиент, и разработчик, – выигрывают от продуктивного взаимодействия. Прочитайте «Психологию влияния» для улучшения этого навыка.

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

4. Навыки роста

Старшие разработчики ежедневно изучают что-то новое. Это не значит, что они проводят 14 часов в день, сидя перед компьютером, читая статьи. Они более эффективны. Они всегда стараются поговорить с другими программистами, задать вопросы или изучить новые темы. Они не сосредотачиваются только на одном наборе знаний. Вы можете быть лучшим в чем-то одном, но если вы не знаете весь спектр или не понимаете, с какой проблемой столкнулись, вы уже не лучший.

Senior Developer не скажет «О, я ненавижу эту библиотеку!». Большинство людей говорят это лишь потому, что не понимают чего-то до конца. Например, не говорите: «Я ненавижу jQuery. Только плохие разработчики все еще используют jQuery». Старший разработчик скажет, что «jQuery сыграл важную роль в развитии Интернета и популярности JavaScript», и он будет прав, ведь действительно разобрался в данном вопросе.

5. Навыки собеседований

Старшие программисты на то и старшие, что могут общаться и продавать свои услуги другим. Вы можете видеть потребности своего работодателя и внушить уверенность в том, что являетесь тем, кто ему нужен. Senior Developer должен уметь принять на себя роль ведущего в проекте, а потому подача на собеседовании решает все. У американского эксперта Рамита Сетхи есть отличная статья, которая даст хороший старт. Помогут и другие полезные материалы по трудоустройству.

6. Навыки сообщества

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

Развивайте эти навыки, но помните: вам должно нравиться то, что вы делаете. Если вы не находите интересным каждый день изучать информатику и разработку программного обеспечения, вы никогда не станете старшим разработчиком, потому что у вас не будет искреннего стремления совершенствоваться. Если вы когда-либо читали книгу «Хватит мечтать, займись делом!», то понимаете, что страсть к работе должна быть чрезмерной.

Но порой настоящая страсть приходит лишь после того, как вы овладели навыком, а для этого много работали, стремясь стать опытным специалистом в своей отрасли. Поэтому обязательно начните, и, возможно, выбранный вами путь приведет к такой заветной и почитаемой должности, как Senior Developer. Дерзайте!

developer — Перевод на русский — примеры английский

На основании Вашего запроса эти примеры могут содержать грубую лексику.

На основании Вашего запроса эти примеры могут содержать разговорную лексику.

CADteam Lithuanian Authorised Autodesk dealer and developer.

CADteam — Литовский Autodesk авторизированный дилер и разработчик приложений.

To help sighted respondents find their numbers, the developer designed a graphic.

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

I’m not a developer by trade.

Well, he did… until a developer decided to tear down that building.

Его и не нашли… пока застройщик не решил снести здание.

The developer arranges the recording and collecting of reports, questions, answers and speeches.

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

The public authority must do so itself, but the developer may do so in parallel.

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

Come on, honey, I’m a developer.

Because you’re not a product developer.

Everyone though little bit skilled developer necessarily, sooner or later, creates the working environment.

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

So he did what any good developer would do, he wrote an app.

И он сделал то, что сделает любой хороший разработчик — он написал приложение.

Guy named Brian Monroe, big downtown real-estate developer, stabbed about a dozen times.

Мужчина, Брайан Монро, крупный застройщик в даунтауне, множественные удары ножом.

Clean record, prominent real estate developer in Colombia.

According to the record, it was bought by a developer six months ago.

Согласно записям, его купил застройщик 6 месяцев назад.

They said some sleazy little condo developer had snapped it up.

I don’t care if this guy’s a rich real estate developer or some psycho with a lighter.

Мне плевать, кто это парень, богатый застройщик или какой-то псих с зажигалкой.

This service desk is to be backed up by the developer as required.

В случае необходимости поддержку этой сервисной службы должен оказывать разработчик.

The organiser developer of the plan or programme must development will inform the public about of the decision made.

Разработчик плана или программы должен информировать общественность о принятом решении.

A developer can create a converter for files of a particular extension.

Разработчик может создать конвертор для файлов с определенным расширением.

All other ways are non-official and the developer of Windows Microsoft doesn’t guarantee that non-official «autoinstallers» will operate.

Все другие способы являются неофициальными и разработчик Windows компания Microsoft не гарантирует, что такие неофициальные «автоустановщики» будут работать.

West Telecom Corporation was established in 1998 as the internet telephony solutions developer.

Корпорация West Telecom была основана в 1998 году как разработчик решений в области Internet-телефонии.

developer — с английского на русский

developer — de‧vel‧op‧er [dɪˈveləpə ǁ ər] noun [countable] 1. MANUFACTURING a person or company that works on the planning and design of new products: • electric car developers • software developers 2. PROPERTY a pe …   Financial and business terms

Developer — may refer to: Software developer, one who programs computers or designs the system to match the requirements of a systems analyst Game developer, a person or business involved in game development, the process of designing and creating games In… …   Wikipedia

developer — noun builder, building entrepreneur, creator, designer, enterpriser, establisher, land developer, organizer, originator, planner, promoter associated concepts: commercial developer, residential developer Burton s Legal Thesaurus. William C.… …   Law dictionary

Developer — De*vel op*er, n. 1. One who, or that which, develops. [1913 Webster] 2. (Photog.) A chemical bath or reagent used in developing photographs. Note: By the action of the developer, the latent image on a photographic plate or film, not perceptible… …   The Collaborative International Dictionary of English

developer — [n] real estate developer builder, planner, real estate investor; concept 348 …   New thesaurus

developer — 1833, one who develops, agent noun from DEVELOP (Cf. develop). Photography use attested from 1869; meaning speculative builder is from 1938 …   Etymology dictionary

developer — {{/stl 13}}{{stl 7}}[wym. deweloper] || {{/stl 7}}deweloper {{/stl 13}}{{stl 7}}, {{/stl 7}}{{stl 8}}rz. mos I, Mc. developererze; lm M. developererzy {{/stl 8}}{{stl 7}} inwestor budowlany budujący domy mieszkalne na sprzedaż lub wynajem :… …   Langenscheidt Polski wyjaśnień

developer — [di vel′əp ər] n. a person or thing that develops; specif., a) a person who develops real estate on a speculative basis b) Photog. a chemical used to develop film, plates, etc …   English World dictionary

developer — [[t]dɪve̱ləpə(r)[/t]] developers 1) N COUNT A developer is a person or a company that buys land and builds houses, offices, shops, or factories on it, or buys existing buildings and makes them more modern. …common land which would have a high… …   English dictionary

developer — noun 1 person/company that develops land/buildings ADJECTIVE ▪ big, major ▪ local ▪ A local developer is planning to build a supermarket on the site. ▪ private ▪ …   Collocations dictionary

developer */*/ — UK [dɪˈveləpə(r)] / US [dɪˈveləpər] noun Word forms developer : singular developer plural developers 1) [countable] someone who buys land or buildings in order to put new or better buildings there and make money from them 2) [countable] someone… …   English dictionary

Специальность .NET Developer или кто такой C#/.NET разработчик

C#/.NET разработчик – это программист, который использует в своей работе технологии платформы .NET. Платформа Microsoft .NET Framework состоит из большого количества инструментов для разработки и технологий, используя которые разработчик может создавать различные типы приложений, от обычных настольных приложений и сайтов, заканчивая решениями для мобильных платформ и компьютерными играми. В основе платформы Microsoft .NET Framework лежит язык программирования C#. Именно этот язык программирования в подробностях должен освоить .NET разработчик.

Язык программирования C# более десяти лет занимает лидирующие позиции во всех рейтингах языков программирования. Так, как рынок труда активно развивается, программисты, которые хорошо знают C# и технологии .NET, являются очень востребованными. .NET разработчики способны развивать логическую последовательность команд для связи с сетями, приложениями и базами данных. От них требуется знание объектно-ориентированного проектирования и программирования с использованием систем, баз данных, а также языков программирования, которые разрабатывают программные приложения с .NET Framework. Сюда входят знания и навыки программирования на языке C#, XML и создание баз данных приложений, таких как Microsoft SQL Server.

Например, разработка интернет магазинов, форумов, онлайн сервисов, потребует знаний языка программирования, который способен реализовать полноценное взаимодействие с сайтом: организовать работу с базой данных, принять и обработать данные пользователя. Это означает, что для реализации полноценного сайта «под ключ», Вам понадобится создать не только разметку с динамическими эффектами, но и позаботиться о полноценном взаимодействии пользователя с сайтом.

Знакомство с программной платформой .NET Framework начинается с видео уроков по языку программирования С# (c sharp): С# Starter, С# Essential и С# Professional. Далее слушателю предлагается набор видео курсов, посвящённых работе с базами данных: SQL Essential, SQL Практикум, Entity Framework 5 и 6.

Только после освоения одного уровня, стоит переходить ко второму, к обучению более сложных и узконаправленных технологий. В качестве дополнительных материалов, рекомендуется просмотреть такие видео курсы: Алгоритмы и структуры данных, Рефакторинг .NET приложений, TDD (разработка через тестирование) и WCF Essential (Windows Communication Foundation). Каждый из перечисленных видео курсов направлен на расширение базовых знаний о платформе .NET Framework и составлен в полном соответствии с современными требованиями ведущих IT компаний к разработчикам программного обеспечения.

Требования к C#/.NET разработчику:

• Владение языком программирования C#
• Владение ООП
• Знание технологий работы с базами данных
• Практический опыт работы с MS SQL Server
• Навык использования Transact-SQL
• Знание Entity Framework
• Базовый уровень знаний и опыт работы с .NET Framework
• Знание технологии WCF
• Базовый уровень знаний технологии ASP.NET MVC
• Знание и умение применять средства коллективной работы, умение читать и понимать чужой код
• Английский язык на уровне чтения технической документации (углубленные знания будут преимуществом)
• Знания основ командной разработки SCRUM или Agile

C#/.NET разработчик может занимать такие должности:

C# Developer
.NET Developer
Software Engineer (C#/.NET)
.NET Team Lead
ASP.NET MVC Developer
Full Stack Developer

11 важных вещей, которые нужно знать про DevOps — часть первая / ScrumTrek corporate blog / Habr

От переводчика

В 2009 года за рубежом возникло движение, которое назвало себя DevOps. На первый взгляд это разработчики с навыками сисадминов и сисадмины с навыками разработчиков. Но на самом деле это отнюдь не так. Данное подход имеет четкие цели, философию, инструменты и методы, которые только некоторые русскоязычные компании начинают использовать. Мне кажется, что данный подход у нас незаслуженно игнорируется и мне хотелось бы рассказать об 11 вещах, которые нужно знать о DevOps, в частности:

• что такое DevOps
• каковы его ценности
• как он внедряется
• кому он приносит пользу

Надеюсь, этот текст вам понравится.

1. Что такое DevOps и откуда оно взялось?

Термином «DevOps» обычно называют возникшее профессиональное движение, которое выступает за совместные рабочие отношения между разработчиками и ИТ-подразделением, в результате получая более быстрое выполнение планируемых работ (например, высокие темпы развертывания), одновременно увеличивая надежность, стабильность, устойчивость и безопасность production-среды. Почему разработчики и ИТ-подразделения (далее для краткости админы)? Потому что, как правило, поток ценностей (value stream) находится между бизнесом (где определяются требования) и заказчиком (куда поставляется результат).

Считается, что движение DevOps зародилось в 2009 году, как объединение многочисленных смежных и взаимодополняющих сообществ: Velocity Conference, на которой особенно яркими было выступление «10 Deploys A Day» John Allspaw и Paul Hammond, подход «инфраструктура как код»(Mark Burgess и Luke Kanies),» Agile infrastructure «(Andrew Shafer) и системное администрирование в Agile (Patrick DeBois), подход Lean Startup Эрика Райса с его непрерывной интеграции, а так же широкая доступность облачных и PaaS технологий.

Один из соавторов DevOps Cookbook, Джон Уиллис, написал фантастический пост об этом событии.

2. Чем DevOps отличаются от Agile?

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

Высокие темпы развертывания приводят к тому, что перед админами накапливается большая гора задач. Clyde Logue, основатель StreamStep, говорит об этом так: «Agile сыграл важную роль в разработке для восстановлению доверия у бизнеса, но он нечаянно оставил IT Operations позади. DevOps это способ восстановления доверия ко всей ИТ-организации в целом ».

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

DevOps позволяет сформировать гораздо более непрерывный поток работы в ИТ-подраздедение. Если код не поставляется в прод, в том виде как он был разработан (например, разработчики поставляют код каждые две недели, но развертывается он только один раз в два месяца), операции по установке будут накапливаться перед админами, клиенты не получат важный функционал для себя и сам процесс установки в таком случае приводит к хаосу и дезорганизации.

DevOps, в том числе, изменяет культуру, так же как изменяет процессы и метрике разработчиков и админов. Джон Уиллис и Дэймон Эдвардс (соавторы Cookbook DevOps) подробно написали об этом здесь.

3. Чем DevOps отличается от ITIL и ITSM?

Хотя многие люди считают, что DevOps это реакция на ITIL (IT Infrastructure Library) и ITSM (IT Service Management), у меня другая точка зрения. ITIL и ITSM по-прежнему являются лучшей кодификацией бизнес-процессов, лежащих в основе ИТ подразделения, так как на самом деле описыват многие вещи, необходимые для того, чтобы ИТ команда могда работать в формате DevOps.

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

Цель DevOps не столько увеличение скорости выдачи нового функционала, сколько развертывания этого функционала в производстве, без хаоса и нарушения работы уже запущенного приложение, а так же быстрое обнаружение и исправление проблем, если они все же происходят. Это добавляет в ITIL такие пункты как настройка сервисов, управление инцидентами и проблемами.

4. Чем DevOps похоже на VisibleOps?

В соавторстве с Kevin Behr и George Spafford я написал „Visible Ops Handbook“ в 2004 году. Visible Ops является руководством по достижению трансформации к высокопроизводительным ИТ подразделениями по пути „от хорошего к великому“, и одним из ключевых понятий является понятие по ограничению и сокращению незапланированных работ.

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

5. Каковы принципы DevOps?

В DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, мы описываем лежащие в основе принципы, с помощью которых все DevOps паттерны могут быть получены с помощью подхода «Три пути». Они описывают ценности и философию, которые являются основой процессов, процедур, практик, а также обязательных шагов.

Первый Путь подчеркивает производительность всей системы в целом, в отличие от производительности отдельного звена или отдела — это может быть как большое подразделение (например, разработка или ИТ отдел) так и отдельные люди (например, разработчик, системный администратор).

В центре внимания находится все бизнес-потоки по созданию ценности, которые включены в IT. Другими словами, он начинается тогда, когда определяются основные требования (например, для бизнес или ИТ), они закончены в разработке, а затем перешли в ИТ-отдел, в которых ценность сервиса затем и доставляется заказчику в виде сервиса.

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

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

Итоги Второго Пути: понимание и реакция на всех клиентов, как внутренних так и внешних, сокращение и усиление всех петель обратной связи, и углубление знаний о среде там, где это нужно.

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

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

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

6. Области внедрения DevOps

В книге „DevOps Cookbook“, мы выделили 4 моделей внедрения DevOps:

Модель 1: Углубление процессов разработки в поставку: это включает расширение непрерывной интеграции и выпуска на боевые сервера, интеграция тестирования и информзащиты в рабочие процессы, что дает готовый к поставке код, настроенные среды, и так далее.

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

Модель 3: Объединение разработки и администрирования: состоит во включении команды разработки в цепочку разрешения проблем, назначение разработчиков на разрешение проблем на проде, а так же взаимные тренинги между разработчиками и администраторами, чтобы уменьшить количество эскалаций.

Модель 4: Включение ИТ команды в разработку: состоит во включении или тесной связью между IT и разработкой, создание многоэтапных пользовательских историй (включая развертывание, управление кодом в производстве и т.д.), и определение нефункциональных требования, которые могут быть использованы во всех проектах.

7. В чем ценность DevOps?

Я полагаю, что есть три бизнес преимущества, которые организации получают от перехода на DevOps: быстрый выход на рынок (например, сокращение времени цикла и более высокие темпы развертывания), повышение качества (например, повышение доступности, меньше сбоев и т.д.), и увеличение организационной эффективности (например, больше времени тратится на деятельность связанную с увеличением ценности продукта по сравнению с потерями, увеличение количества функционала, переданного заказчику).

Быстрое время выхода на рынок

В 2007 году в IT Process Institute, мы тестировали более 1500 ИТ организаций и пришли к выводу, что высокопроизводительные ИТ организации были в среднем на 5-7x порядков более производительными, чем их невысокопроизводительные сверстники. Они делали в 14 раз больше изменений, получая проблемы только половине случаев, при этом имея скорость исправления проблем с первого раза в 4 раза выше, а также имели в 10 раз более короткие периоды простоя. У них было в 4 раза меньше результатов повторного аудита, они в 5 раз чаще находили нарушения за счет автоматизированной системы внутреннего контроля, и в 8 раз лучше укладывались в сроки проекта.

Одной из характеристик высокопроизводительных команд состоит в том, что они уходят далеко вперед от толпы. Другими словами, лучшее становится еще лучше. Это происходит в области темпов развертывания приложения. Accenture недавно провели исследование о том, что делают интернет-компании, и Amazon пошла на рекорд, заявив, что они делают более 1000 развертываний в день, поддерживая скорость успешных изменения 99,999%!

Возможность поддержания высоких темпов развертывания (например, быстрое время цикла) трансформируется в бизнес-ценность двумя основными способами: как быстро может организация перейти от идеи к чему-то, что может быть передано заказчику и сколько экспериментов организация может проводить одновременно.

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

Высокие темпы развертывания позволяют проводить эксперимент быстро и практически непрерывно. Скотт Кук, основатель Intuit, был одним из самых ярых сторонников „безудержной инновационной культуры“ на всех уровнях организации. Один из моих любимых примеров приводится ниже:

»Каждый сотрудник [должен быть в состоянии] проводить быстрые, высоко-скоростные эксперименты… Дэн Маурер руководит нашим потребительским подразделением, в том числе запуск веб-сайта TurboTax. Когда он начинал работу над этим проектом, мы сделали около семи экспериментов за год. За счет внедрения инновационной культуры, они сейчас делают 165 экспериментов в течение трех месяцев налогового сезона. Бизнес результат? Коэффициент конверсии веб-сайта составляет до 50 процентов. Результат для сотрудников? Люди просто любят его, потому что теперь их идеи могут попасть рынок «.

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

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

Уменьшение количества потерь IT-отдела

Mike Orzen и я как-то говорили об огромных потерях в IT стриме, вызванными длительными сроками простоя, медлительной передачей работ, незапланированными работами и переделками. Для статью Michael Krigsman мы оценили, сколько полезной деятельности мы могли бы вернуть путем применения принципов DevOps.

Мы подсчитали, что если бы мы могли просто сократить вдвое количество IT потерь, а также перераспределять эти деньни таким образом, что сможем вернуться в пять раз больше чем было вложено, мы бы производили $ 3 триллионов долларов полезной деятельности в год. Это ошеломляющее количество денег и возможностей, которым мы позволяем ускользнуть из наших рук. Это 4,7 процента от ежегодного мирового ВВП, или больше, чем весь объем производства Германии.

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

Однако, существует еще другой тип потерь. Люди в большинстве ИТ-организаций часто чувствуют себя обойденными вниманием и полными разочарования. Люди чувствуют, как будто они в ловушке вечно повторяющегося фильма ужасов и беспомощны, чтобы изменить финал. Менеджмент отрекается от своей ответственности за IT, что часто приводит к бесконечным войнам между разработкой, ИТ и отделами информационной безопасности. И все становится только хуже, когда аудиторы вскрывают все это. Жизнь ИТ-специалистов часто деморализована и полна разочарований, что, как правило, приводит к чувству бессилия и наполняет стрессами, которые проникают в каждый аспект жизни.

Как люди, мы стремимся творить и ощущать, что мы является частью чего-то большого. Тем не менее, слишком часто, когда ИТ-специалисты просят у их организации поддержки, они слышат «Вы не понимаете», или еще хуже, едва прикрытое, «Вы никто».

Leave a comment Cancel reply