коммерческая разработка что это
Это значит, что человек участвовал в разработке коммерческого продукта, того, что продается за деньги на рынке. Программирование в НИИ ради статеек, домашние поделки (в т.ч. опен-сорс форфан), таковыми не считаются.
«Фанатики опен-сорса не нужны» 🙂
Ну, смотря какие. Опыт бесплатного использования результатов труда пермиссивщиков в коммерческих проектах очень полезен.
Можно перефразировать ещё и так — готовность&способность работать на результат, в сжатые сроки, в тесном сотрудничестве с разнородной командой, под контролем со стороны менеджера.
Облик ПО (включая состав фич, глубину проработки фич, уровень качества) задают другие люди (покупатели, бизнес, аналитики, архитекторы, юзабилисты, etc) — и у тебя не должно быть психологических проблем с тем, чтобы это (чуждое лично тебе) вИдение воплощать.
Практики (code review, unit-testing, etc), инструменты (выбор ЯП и стека технологий, выбор багтрекера, выбор VCS, etc), процессы (планирование работы, отчетность о проделанной работе, и тд) задают другие люди — и у тебя не должно быть психологических проблем с тем, чтобы этим (не всегда нужным лично тебе) решениям следовать.
Гм а поддержка основного [b]продукта[/b] компании
который не продается другим компаниям
В основном это опыт работы на работе. Ну то есть то, что разработчик работал в конторе и получал за свою работу деньги. А не всякие там гранты, любительство и тд.
Ну, в ряде случае опыт опенсорс разработки тоже можно зачесть за такой опыт разработки. Скажем участие в крупных проектах мало чем отличается от коммерческой разработки и уже сравнивать приходится размер проектов, а открытость и проприетарность.
Плюс не особо там кто-то заморачивается, когда ставит такие требования. С первого взгляда они и не отличат открытый проект от закрытого.
Да, если стиль разработки предполагает постановку задач с оговоренным заранее сроков выполнения и в разработке участвует более полуинвалида.
эта рэпчик
но рассуждать слишком поздно о перспективах морального роста
всё просто с жопы босса грызи коросту
Это значит, что требуется опыт работы ныряния в говно, написанное чтобы принести прибыль вчера на коленке кучей макак, за деньги. Если это госконтора, то то что они написали ещё и работает только на бумаге или в лучшем случае на тестовом стенде.
Лучше в такую контору не ходить, там дрочат на KPI и успешность, убытки называют отрицательной или недополученной прибылью, повсюду SCRUM курильщика и AGILE курильщика, призванные не решать проблемы, а избавить менеджера от работы которую он должен делать, контора захвачена эффективным менеджером и скоро её ждёт убыточность с последующим поиском виноватых. Эффективный менеджер эффективно уйдёт сам разваливать следующую контору когда почувствует, что с этой уже всё.
Это значит что ты «поварился» в конторе, хотя бы младшим разработчиком на подхвате, которая давно разрабатывает ПО, которое продаётся на рынке не один год. И эта контора периодически выпускает обновлённую версию своего ПО.
А так, это больше значит что была ли ответственная работа. Где за код ты отвечал головой. Даже если ты писал скрипты.
повсюду SCRUM курильщика и AGILE курильщика
А где-то бывает не курильщика? Сколько не видел попыток в аджайл, везде одна херня была.
Там же где и идеальный код.
Это когда ты делаешь тяп ляп и забыл…
А еще главное не делать лишних фич, чтоб клиент пришел снова… А если фичи сами получились их надо загамачить
Вам с 
DELIRIUM нужно объединиться в стендап дуэт.
Наверное, когда разработал уже настолько, что можешь без труда спрятать банку сгущенки.
😀 Третьим будешь, а то я чёт ссыкую с ним наедине оставаться. https://youtu.be/beDWJ0bbz9I?t=165
Да тут целую труппу собрать можно из участников треда. Так, где мой клоунский грим?
😀 Можно ещё ютуб канал открыть, треды делать голосовыми и выкладывать. Тоесть очередной калиюзер пишет на лор, мы отвечаем ему и попутно всё это озвучиваем =) Будет вакханалия миллионы просмотров и будем жить на доход с просмотров =)
Идёт. Я предоставляю площадку, в виде моего ютуб канала, а вы мне за это 10% прибыли.
Мне кажется большинству из нас клоунский грим не нужен 😀 Мне так уж точно… Декорации нам будет делать torvn77 вместе со своей армией усатых друзей
Не понял, при чём тут я.
buddhist ’а возьми, он с такими шутейками и впишется прекрасно, и здоровый как мамонт, в обиду тебя не даст.
Тоже шутишь искромётно.
Спасибо, я спокоен. В одной его автарке мощььь ацкая. Победитовый монолит
Облик ПО (включая состав фич, глубину проработки фич, уровень качества) задают другие люди
Практики (code review, unit-testing, etc), инструменты (выбор ЯП и стека технологий, выбор багтрекера, выбор VCS, etc), процессы (планирование работы, отчетность о проделанной работе, и тд) задают другие люди
Вообще никак не связанные вещи. Если первое ещё можно считать признаком коммерческого продукта, да и то с натяжкой, то второе скорее будет признаком галеры, вне зависимости от того, выходит у неё коммерческий продукт или нет.
Мы знаем, что ты не гей, ты же зоофил.
А кто же тебя знает от чего ты развелся
С треда сильно хохотался, спасибо :)) Тёплый ламповый ЛОР иногда видно.
Это значит, что твой пердёж звучит уже не как «т-р-р-р-р-р», а как «п-с-с-с-с-с-».
Ну почему бесплатного? Я писал LLVM за неплохую зарплату.
Ты писал проприетарщину на основе LLVM?
Ну в том числе да. Но многое апстримилось. Ещё я на зарплате в git коммитил, всмысле в сам git. Один патч сам Линус ревьюил.
О, ещё на одной из предыдущих работ я починил багу и заапстримил фикс в reiserfs-tools. Правда с копроактивного мыла мне апстримить не разрешили, так что с личного отправлял, но делал это в рабочее время за зарплату.
Только то, что имеет непосредственное отношение к профитам конкретного бизнеса, является коммерческой разработкой. Твоя благотворительность по раздаче результатов труда, произведённых за зарплату одного капиталиста, всему миру за бесплатно, разумеется, коммерческой разработкой не является. Более того, это серьёзный звоночек нормальному капиталисту, не нанимать такого неадеквата, который будет множить на ноль выручку от вложенных в него денег.
Капиталист сам требовал определённые коммиты проводить через апстрим.
А дохрена и больше бизнесов ограничились бесплатным использованием чужого труда, без всяких апстримом. Просто ты о них не знаешь.
Сколько же бреда в этом потоке каментов от ничего не понимающих в рекрутинге раков.
Фильтруй его.
В реальности же это значит «опыт работы по какой-либо системе, предусматривающей прогнозирование сроков, в реальных условиях где эти сроки на что-нибудь влияют».
Не «на что-нибудь», а на вполне прослеживаемую потерю или прирост прибыли. Иначе можно и в каком-нибудь опесорс проекте обпрогнозироваться, в реальных условиях (есть ещё какие-то «виртуальные» условия), какие угодно технологии использовать, код ревьюить, тестировать и проч., и это таки будет влиять на много чего (на опыт участников, на наличие у них свободного времени, на готовый пример работающего ПО), но к коммерческой разработке это будет иметь отдаленное отношение.
что разработчик работал в конторе и получал за свою работу деньги
А как же фриланс? Может, между прочим, в зависимости от требований учитываться или нет — это важно.
В госконторах и военке? Там, по идее, до сих пор Waterfall…
предусматривающей прогнозирование сроков
Да ничего он не означает. Это из той же оперы что и «умение разбираться в чужом коде».
А какая разница между фрилансом и работой в офисе? Тут речь скорее про работу в коллективе. Если фриланс предполагал работу над проектами, где участвовал хотя бы ещё кто-то, то да, подходит. Если в одиночку всё делал, то подходит, но отчасти, потому что многих нюансов работы в команде не знаешь и опыта такого нет(ну или может был, от того и работаешь один:)).
То есть удалённо или нет это не играет роли. Ваш статус(ИП, самозанятый, в штате) тоже не играет роли. Хотя для некоторых компаний то, что разработчик работал только удалённо будет минусом. Но в такие конторы лучше не идти, обычно там и платят так себе и мозг съедают без остатка.
Что я хотел бы знать о коммерческой разработке до того, как попал в нее
Антон Мацышин — Junior Full Stack Developer в компании Binary Studio. В своей статье на DOU.UA он рассказал о тех аспектах коммерческой разработки, о которых узнал на собственном опыте, хотя предпочел бы узнать раньше.
Когда я начинал свою карьеру в IT, то понял, что мое представление о разработке немного отличается от реальности. Поэтому я и решил написать эту статью: чтобы люди, которые хотят попробовать себя в этой отрасли, стали немного лучше понимать, что она из себя представляет и во что нужно инвестировать свое время.
Чем разработчик отличается от человека, который просто пишет код
Для начала нужно разобраться с целями коммерческой разработки. По моему мнению, единственная ее цель — предоставлять программное обеспечение, которое помогает оптимизировать или оцифровывать процессы бизнеса. Звучит немного заумно, поэтому рассмотрим конкретный пример.
Допустим, мы решили оставить распиаренное IT уже на этапе этой длинной статьи и попробовать себя в продаже новогодних елок. Возникает вопрос обработки заказов. Можно набрать большой штат сотрудников, а можно создать приложение, в котором пользователи смогут оформить покупку сами. И тогда нам не нужно содержать отдел для обработки заказов. Мы как владельцы счастливы, ведь теперь тратим меньше, а значит, зарабатываем больше, а все из-за такого хорошего приложения.
Девелопер должен смотреть шире технических задач:
Здесь добавлю несколько ремарок. Конечно, разрабатывать по SOLID, писать оптимизированный код и быть в тренде технологий хорошему разработчику все так же необходимо. Я лишь хочу сказать, что без понимания конечного продукта даже очень хорошей технической базы будет мало. Также описанные выше обязанности частично берут на себя Project Manager и Business Analyst. Они конвертируют запросы бизнеса в конкретное ТЗ для разработчиков. Но даже в таком случае необходимость понимать предметную область и цели проекта никуда не пропадает.
Какими качествами должен обладать хороший разработчик
Исходя из задач, возложенных на разработчика, я выделяю для себя список качеств, которые помогают выполнять их хорошо.
Понимание того, чего хочет клиент
Как мы уже обсуждали, заказчик не хочет, чтобы вы писали код, он хочет, чтобы вы делали его продукт лучше. Поэтому, прежде чем засучить рукава и начать программировать, я бы сначала разобрался, какую проблему бизнеса решает функционал. Возможно, ее удастся решить, не написав и строчки кода.
Также следует помнить, что иногда клиент сам не до конца понимает, как запрашиваемая фича влияет на конечный продукт. В моей практике были случаи, когда в ходе работы я видел, что мой функционал может сломать уже существующий. Или что он уже реализован, но в другом модуле приложения. Таким моментам следует уделять особое внимание, дополнительно обсуждая их с заказчиком.
Умение презентовать свою работу
Огромную роль играет не только то, что вы делаете, но и как вы это презентуете. Совсем уж элементарный пункт, да? Из своего опыта могу сказать, что это далеко не всегда так. Если вы работали над функционалом, польза которого не видна здесь и сейчас (например, написали сервис для вызова удаленных процедур, обертку над библиотекой, интегрировали в проект новую технологию), то объяснить человеку без технического бэкграунда, зачем вы этим занимались — отдельный вид задач.
Я развил это качество в Binary Studio Academy. По ходу работы над проектом наша команда представляла свои результаты условному заказчику, который задавал много вопросов, делал замечания и вносил правки в конечный функционал. Это научило меня смотреть на задачи шире, понимать, какую пользу в итоге они принесут конечному пользователю.
Способность работать в команде
Как я считаю, одно из самых важных качеств вообще. Под ним я подразумеваю уважение к работе и подходам ваших коллег, адекватную реакцию на просьбы, умение признавать свои ошибки и правильно реагировать на ошибки других. Проще говоря, нашумевшие soft skills.
С этим пунктом мне помогла опять-таки академия, так как разработка проектов ведется в командах. Не последнюю роль сыграл и мой университет: у нас достаточно часто были лабораторки на несколько человек. Хоть звучит это и не очень впечатляюще, но при желании можно извлечь пользу и из таких занятий.
Умение разбираться в чужом коде
Даже если предположить, что вы работаете на новом проекте, вам все равно придется иметь дело с кодом коллег. А если проект разрабатывают уже несколько лет? В таком случае умение быстро разбираться в существующем функционале — огромный плюс для инженера.
Немного о hard skills
Цель разработчика — делать бизнес заказчика лучше. Если то, что вы реализовываете, не улучшит бизнес, то, скорее всего, это не нужно. Но из этого следует вопрос: а какой тогда смысл писать хороший код? Если код, написанный на коленке, дает тот же результат и приносит бизнесу ту же пользу, что и хорошо спроектированный, зачем тратить время и ресурсы попусту?
Зачем писать код по стандартам
Какую пользу разработка по стандартам несет для бизнеса? Ведь если пользы нет, то нет и смысла использовать эти стандарты.
Дело в том, что плохо написанный код невероятно тяжело поддерживать (спасибо, Капитан Очевидность). Инженеры вместо того, чтобы работать над новым функционалом, будут неделями разбираться с уже существующим, бороться с side effects и молиться, чтобы их фича не сломала половину приложения. На задачи будет выделяться намного больше времени, а время, как известно, — деньги. Вряд ли какой-либо бизнес хочет их терять.
Как научиться писать хороший код
По моему мнению, важно понимать, что качество кода растет постепенно. Не бывает такого, что сегодня вы пишете плохо, а завтра, прочитав какую-то статью/освоив новый подход, начнете писать хорошо. Это процесс долгий и непрерывный, нужно запастись терпением.
Ниже я перечислю то, что сильно помогло мне улучшить свой код:
MythBusters
Перед тем как закончить статью, я бы хотел рассказать о нескольких стереотипах, в которые верил до начала работы в IT.
Работа в большой компании = хорошая работа
Как мне кажется, один из самых распространенных мифов. Конечно, я не утверждаю, что работать в большой компании плохо. Я имею в виду, что нужно оценивать конкретные вакансии: с какими технологиями будете работать, какие будут обязанности, на какой проект вас берут и так далее. Известное имя — это не всегда гарант хорошей работы.
Вера в best practices
Когда я начинал изучать программирование, то верил, что существует подход, благодаря которому можно разрабатывать системы идеально. К сожалению, это миф. В конечном итоге все зависит от конкретной задачи, возможностей языка, особенностей проекта, сроков… Список можно продолжать долго. Как тогда определить, когда какой подход использовать? С этим поможет только практика.
Технологии ради технологий
Начинающему инженеру всегда хочется работать с новыми технологиями, и ничего плохого в этом желании нет. Пробовать новые языки, фреймворки и подходы в своих pet projects можно (и нужно) сколько угодно. Но если вы предлагаете внедрить в коммерческий проект новую технологию, то ответственным за это решение будете вы. Поэтому важно использовать не что-либо самое новое или лично вам интересное, а то, что подходит под конкретную задачу.
Еще раз подчеркну главную мысль статьи: разработчик решает в первую очередь проблемы бизнеса, а уже исходя из них технические задачи. Если вы можете помочь бизнесу, не написав ни строчки кода — сделайте это.
Изучайте новые технологии и подходы, но оценивайте критически их полезность перед тем, как интегрировать в свой проект, ведь за их использование будете ответственны вы.
Развиваясь как инженер, не стоит забывать о soft skills: они помогут в общении с коллегами и заказчиком. Недостаточно быть хорошим программистом, важно уметь работать в команде, понимать, чего хочет клиент, и уметь презентовать свою работу. Всегда помните, что обязанности разработчика выходят за рамки технических.
20 вещей, которые я узнал за 20 лет работы инженером-программистом
Наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод.
Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).
Дисклеймер от автора оригинальной статьи
Учиться на чужом опыте и ошибках очень важно, но мы часто забываем, что большинство советов имеют контекст, который далеко не всегда учитывается.
«Вам просто нужно повысить цены» — говорит компания, которая 20 лет работала в бизнесе, выставляя поначалу низкие цены для привлечения клиентов.
«Вам нужно внедрять микросервисы» — говорит компания, которая построила монолит, набрала тысячи клиентов и перешла на микросервисы, когда столкнулась с проблемами масштабирования.
Без понимания контекста советы бессмысленны или, что ещё хуже, вредны. Если бы эти компании последовали собственным рекомендациям в начале пути, они, скорее всего, навредили бы сами себе.
Для понимания контекста расскажу, откуда берутся советы в этой статье. Первую половину карьеры я работал инженером-программистом в небольших компаниях и стартапах, потом перешёл в консалтинг и работал в нескольких действительно крупных компаниях. Затем основал Simple Thread, которая выросла из команды 2 человек до 25. 10 лет назад мы работали в основном с малым и средним бизнесом, сейчас — со средним и большим.
Советы в этой статье от человека, который:
почти всегда работал в небольших командах, где приходится делать много, имея очень мало;
ценит работающие решения выше конкретных инструментов;
постоянно начинает новые проекты, но поддерживает ряд систем;
ценит производительность инженера выше большинства других критериев.
Мой опыт за последние 20 лет сформировал отношение к разработке и убедил меня в некоторых утверждениях, которые я оформил в виде списка. Надеюсь, он вам будет полезен.
1. Я все ещё многого не знаю
«Как ты можешь не знать, что такое BGP?» или «Ты никогда не слышал о Rust?» — некоторые из нас не раз слышали подобное.
Причина, по которой многие любят разработку, заключается в том, что мы учимся всю жизнь. И в создании софта есть огромные области новых знаний, которые с каждым днём только растут. Можно десяток лет работать программистом и всё равно иметь огромный пробел в знаниях по сравнению с кем-то, кто также провёл десятилетия в, казалось бы, аналогичной роли.
Чем раньше вы это поймёте, тем быстрее сможете избавиться от синдрома самозванца и с удовольствием учиться у других.
2. Самое сложное в разработке — сделать продукт, который действительно нужен
Знаю, что это уже стало клише, но многие инженеры скептически относятся к данному пункту, поскольку считают, что он обесценивает их труд. Чушь, на мой взгляд. Напротив, этот момент помогает подчеркнуть, в насколько сложной и иррациональной среде нам приходится работать, ведь именно эти аспекты так усложняют нашу деятельность.
Можно разработать самую технически впечатляющую вещь в мире, а потом никто не захочет её использовать. Такое случается постоянно. Проектирование софта часто связано со слушанием — нам приходится быть сразу инженером-программистом, экстрасенсом и антропологом.
Инвестиции в процесс проектирования (с помощью UX-специалистов или путём самообразования) принесут огромные дивиденды. Ведь как реально подсчитать стоимость разработки неправильного ПО? Это гораздо больше, чем просто потерянное время инженера.
3. Лучшие инженеры-программисты думают как дизайнеры
Великие инженеры-программисты глубоко задумываются о пользовательском опыте. Они могут не думать об этом в терминах вроде внешнего или программного API, UI, протокола или любого другого интерфейса. Великие инженеры думают о том, кто будет его использовать, почему он будет использоваться, как он будет использоваться и что важно для пользователей. Учет потребностей конечного потребителя — это залог хорошего пользовательского опыта.
4. Лучший код — это отсутствие кода или код, который не нужно поддерживать
Всё, что нужно сказать: кодеры будут кодить. Если спросить человека любой профессии, как решить ту или иную проблему, он выберет то, что у него хорошо получается. Это просто человеческая природа. Большинство инженеров-программистов всегда будут склоняться к написанию кода, особенно когда нетехническое решение не очевидно.
То же самое относится к коду, который не нужно поддерживать. Инженерные команды часто хотят изобрести колесо, когда оно уже существует. Здесь нужно соблюдать баланс, есть много причин для развития собственных разработок, но остерегайтесь токсичного синдрома «изобретено не здесь».
5. Программное обеспечение — это средство достижения цели
Основная работа любого инженера-программиста — предоставление ценности. Немногие разработчики понимают это, ещё меньше тех, кто это осознает. А ведь осознание приводит к другому способу решения проблем и другому взгляду на инструменты.
Если вы действительно верите, что выбор ПО зависит от цели, то будьте готовы найти «правильный инструмент для работы», который может и не являться софтом.
6. Иногда нужно перестать точить пилу и просто начать пилить
Некоторые сразу бросаются в проблему и начинают писать код. Другие — начинают исследовать и попадают в аналитический паралич. В таких случаях установите дедлайн и начните изучать решения. Вы гораздо быстрее узнаете что-то, когда непосредственно станете решать задачу.
7. Если у вас нет представления о границах возможного, вы не сможете спроектировать хорошую систему
С этим я часто сталкиваюсь, поскольку мои обязанности уводят меня все дальше и дальше от повседневной разработки ПО. Следить за командой разработчиков — огромный объём работы. И если вы не понимаете, на что способна ваша команда, то сможете разрабатывать решения только для самых простых проблем. И опасайтесь тех, кто давно не писал никакого кода.
8. Каждая система в конечном счёте отстой, смиритесь с этим
У Бьерна Страуструпа есть цитата: «Есть только два вида языков: те, на которые все жалуются, и те, которыми никто не пользуется». Это можно распространить и на большие системы. Не существует «правильной» архитектуры, вы никогда не закроете весь техдолг, не разработаете идеальный интерфейс, ваши тесты всегда будут слишком медленными.
Это не оправдание тому, чтобы не делать что-то лучше, а наоборот, способ дать вам перспективу. Меньше беспокойтесь об элегантности и совершенстве, стремитесь к постоянному улучшению и созданию пригодной для жизни системы, в которой вашей команде нравится работать и которая стабильно приносит пользу.
9. Никто не спрашивает «почему» в достаточной степени
Используйте любую возможность поставить под сомнение предположения и подходы, которые «всегда делались так, как надо». В команде появился новый сотрудник? Обратите внимание, где он запутался и какие вопросы задаёт. Поступила заявка на новую функцию, которая не имеет смысла? Убедитесь, что вы понимаете цель и то, что требует эту функциональность. Если не получаете чёткого ответа, продолжайте спрашивать, пока не поймёте.
10. Сосредоточьтесь на том, чтобы избежать 0,1х-программистов, а не найти 10х-программистов
10x-программист — это глупый миф. Идея о том, что кто-то может сделать за 1 день то, что не менее компетентный, трудолюбивый, и такой же опытный программист может сделать за 2 недели, глупа.
Я видел программистов, которые пишут в 10 раз больше кода, а потом вам приходится исправлять его в 10 раз дольше. Кто-то может быть 10х-программистом только в том случае, если вы сравниваете его с 0,1x-программистом — тот, кто тратит время, не просит обратной связи, не тестирует свой код, не рассматривает крайние случаи и так далее. Нужно заботиться, чтобы не допустить 0,1x-программистов в команду, а не искать мифического 10x-программиста.
11. Одно из главных отличий между сеньором и джуном — свое мнение о том, как все должно быть
Ничто не беспокоит меня больше, чем сеньор, не имеющий никакого мнения о рабочих инструментах или о том, как подходить к созданию программного обеспечения. Лучше высказать мнение, с которым я буду категорически не согласен, чем не иметь мнения вообще.
Если вы используете инструменты, но ненавидите их, вам нужно изучить больше. Попробуйте другие языки, библиотеки и парадигмы. Существует мало способов повысить уровень своих навыков быстрее, чем активный поиск того, как другие решают задачи с помощью инструментов и методов, отличных от ваших.
12. Людям не нужны инновации
Люди много говорят об инновациях, но обычно они ищут дешёвые преимущества и новизну.
Если вы действительно привносите новшества и меняете то, что людям привычно — ждите отрицательных отзывов. Но если верите в то, что делаете, и знаете, что это действительно улучшит ситуацию, приготовьтесь к долгой битве.
13. Ваши данные — самая важная часть системы
Я видел много систем, в которых целостность данных держалась в основном на надежде. Любое отклонение от идеального сценария в такой системе, и мы получаем частичные или грязные данные, а работа с такими данными в перспективе превратится в кошмар.
Важно помнить, что данные скорее всего сильно переживут вашу кодовую базу. Приложите усилия, чтобы всё хранилось в порядке, и это окупится.
14. Ищите технологических акул
Старые технологии, которые остались на плаву, — это акулы, а не динозавры. Они настолько хороши, что пережили быстрые изменения, которые постоянно происходят в мире технологий. Заменяйте их только в том случае, если у вас есть очень веская причина. Эти инструменты не будут модными и современными, но позволят выполнить работу без множества бессонных ночей.
15. Не путайте скромность с невежеством
Есть много программистов, которые не высказывают мнения, если их прямо не спросить. Если кто-то не высказывает своё мнение вам в лицо, это не значит, что ему нечего добавить. Иногда самых громких хочется слушать меньше всего.
Поговорите с окружающими, запросите фидбек и советы.
16. Программисты должны регулярно писать
Инженеры-программисты должны регулярно вести блог или дневник, писать документацию и вообще делать всё, что требует от них высокого уровня навыков письменного общения. Письмо помогает думать о проблемах и более эффективно общаться с командой. Это один из важнейших навыков, которым должен овладеть любой программист.
17. Рабочие процессы должны быть минимально энергозатратными
Сейчас все хотят быть agile, но «agile» — это создание вещей небольшими порциями, обучение, а затем итерация. Если кто-то пытается вложить в это гораздо больше, значит, он что-то продаёт. Для этого необязательно переставать помогать сотрудникам или отказываться от отчётности, но вы когда-нибудь слышали, чтобы люди из ваших любимых IT-компаний и масштабных опенсорс-проектов хвалились тем, какой у них клёвый Scrum? Процессы должны оставаться лёгкими и гибкими до тех пор, пока не появится потребность в большем. Доверьтесь своей команде, они всё сделают.
18. Инженеры-программисты, как и все люди, должны чувствовать ответственность
Если вы отвлечёте кого-то от результатов его работы, то он будет меньше заботиться о ней. Это почти тавтология и основная причина, почему кросс-функциональные команды работают хорошо, и почему DevOps стал таким популярным. Дело не только в передаче обслуживания и неэффективности, а в том, чтобы управлять всем процессом от начала до конца и нести прямую ответственность за предоставление ценности.
Дайте группе увлечённых людей полную ответственность за проектирование, создание и выпуск софта (или чего-то ещё) — произойдут удивительные вещи.
19. Собеседования не помогут определить, насколько хорошим членом команды будет человек
Собеседования лучше проводить, чтобы понять, кто такой человек и насколько он заинтересован в нужной области знаний. Пытаться выяснить, насколько хорошим членом команды он будет, — бесполезное занятие.
То, насколько человек умён или осведомлён, также не является хорошим показателем, каким членом команды он станет. Никто не скажет вам на собеседовании, что он будет ненадёжным, жёстким, напыщенным или никогда не будет приходить на собрания вовремя. Некоторые ищут «сигналы» для таких вещей, вроде «Если они спрашивают об отгулах на первом собеседовании, значит, они точно не будут ходить на миты!», но это все ерунда. Если вы опираетесь на подобное, то просто гадаете и отбрасываете хороших кандидатов.
20. Стремитесь к созданию более компактной системы
Есть много факторов, которые будут подталкивать вас к созданию большой системы. Распределение бюджета, невозможность решить, какие функции следует сократить, желание создать «лучшую версию». Все эти вещи очень сильно подталкивают к тому, чтобы сделать слишком много. Нужно бороться с этим.
В процессе разработки вы узнаете так много нового, что в результате итераций получите гораздо более крутой результат. Для многих это крайне трудно.
Ваша история
Вот и всё: 20 лет разработки программного обеспечения превратились в 20 мудрых пунктов. Если согласны или не согласны с мыслями в статье, или если есть, что добавить и чем поделиться — пишите в комментариях.