Исходная задача
Чтобы не водить вилами по воде - начнем сразу с конкретной задачи, которая имела место быть в моем личном опыте.
Итак заказчик ставит задачу: Добавить галочку "Согласовано" в документ поступление товаров.
Конечно же, перед выполнением задачи все надо обсуждать и говорить заказчику, какие есть подводные камни и хочет ли он их избежать, но я специально пропускаю это, чтобы контраст был более очевиден.
Акт 1
Программист №1: Добавляет реквизит в документ и выносит эту галочку на форму. Тратит на это 30 мин.
Программист №2: Создает документ "Согласование" + табличную часть "Товары", делает регистр накоплений "Согласование" и описывает логику заполнения табличной части. Тратит на это 10 часов.
Заказчик: Думает, что №1 - очень хороший и очень быстрый и готов ему уже сейчас платить в 2-3 раза больше, чем №2. А этот долгий №2 еще и денег просит больше.
Акт №2
Бухгалтерия закрывает период редактирования.
Программист №1: Находит тот код, который запрещает изменять документы в закрытом периоде, и переделает его так, чтобы можно было согласовать. Тут придется ему повозиться. Задача-то нетривиальная. И потратит 4 часа.
Программист №2: Ничего не делает
Заказчик: Думает, что №1 работает и хочет ему помочь, а №2 не желает помогать.
Акт №3
Проблема: Двое согласующих не хотят признавать, что это они согласовали, и валят друг на друга.
Программист №1: Добавляет реквизит "Согласовал" с типом "Справочник.Пользователи", который заполняется в его хитром алгоритме обхода закрытого периода. Тратит еще 1 час.
Программист №2: Еще а первом акте добавил реквизит "Ответственный" в свой документ и опять ничего не делает.
Заказчик: Думает, что №1 делает как удобно заказчику. Все просто и понятно и даже в списке документов можно видеть, согласовано или нет. А №2 сделал какого-то монстра и озадачивает понапрасну людей создавать еще документов.
Акт №4
Заказчик говорит: Хочу, чтобы люди, которые согласовывают, видели новые документы, которые им надо согласовать.
Программист №1: Делает обработку, форма которой раз в n секунд делает запрос по документам, у которых нет галки. Ну или ко всем документам, а потом в цикле сравнивает ТекущийПользователь и Согласовал. И обработка эта открывается ПриНачалеРаботыСистемы. Тратит на это 3 часа.
Программист №2: Делает отчет, который показывает остатки регистра накоплений из первого акта. Тратит на это 30 мин.
Заказчик: Думает, что №2 совсем не понимает, что нужно делать. А №1 молодец. Все просто и понятно.
Акт №5. Заключительный
Проблема: Часть товаров может быть согласована, а часть нет.
Программист №1: Переносит реквизиты "Согласовано" и "Согласовал" в табличную часть, в списке документов обрабатывает событие "ПриВыводеСтроки", чтобы определить согласован документ целиком или нет, переделывает алгоритм обхода даты запрета, переделывает обработку, которая открывается "ПриНачалеРаботыСистемы". Тратит на это 6 часов.
Программист №2: Ничего не делает, потому что все готово было в первом акте.
Заказчик: Начинает понимать, что №2 все предусмотрел заранее. Но реальную работу он видит у №1. Поэтому со счетом 4:1 побеждает №1
Итого
Программист №1 тратит 14,5 часов.
Программист №2 тратит 10,5 часов
Заказчик получает, казалось бы, одинаковый результат, но с №1 ему работать выгоднее, т.к. он делает "красивее" и ставка у него ниже. И заказчик еще не знает, что доработки №1 будут добавлять 15 мин. к каждому следующему обновлению конфигурации. Заказчик еще не знает, что эти доработки приведут к серьезным проблемам производительности в будущем и к блокировкам, с которыми не сможет разобраться программист №1 и опять напишет кучу подобного. И вот после всей этой кучи доработанного заказчик начнет получать ответы от программиста №1 по типу "Мы не можем вести учет в разрезе двух складов, а если доработаем - вся компания может встать, т.к. предусмотреть все места, где написано
Если Склад.Наименование = "Склад №1" Тогда
....
НЕВОЗМОЖНО!"
Вот и получается, что в глазах заказчика программист №1 - хороший, а программист №2 - плохой, а по факту получается совсем иначе.
Технический долг
Это еще один интересный момент, который не видят заказчики/работодатели.
Если коротко - технический долг это непродуманное решение, которое может приводить к негативным последствиям (как в примере выше - галочка "Согласовано")
Программисты меняют работу по разным причинам. И на их место приходят другие. У всех разная квалификация, разный опыт. И все оставляют после себя технический долг. Кто-то меньше, кто-то больше, но все. Конечно же плохие оставляют больше.
Представим ситуацию: Работало 2 программиста с низкой квалификацией, но им досталась типовая конфигурация, которую они дорабатывали на протяжении нескольких лет.
Потом на их место пришли программисты с высокой квалификацией и з/п им нужна в 2 раза больше.
50% своего времени напрямую или косвенно новые специалисты тратят на закрытие технического долга.
И тут работодатель опять попадает в эту ситуацию: Плачу больше, делают дольше.
Может получиться еще одно интересное развитие событий: с этими двумя расстанутся и возьмут опять с меньшими зарплатными ожиданиями и более низкой квалификации. Технического долга будет естественно меньше, да и не факт, что он их будет волновать. Сказали галочку - вот вам галочка. И руководство опять радо - опять видно работу программистов. А то, что в штате через несколько лет уже 10 плохих программистов, а не 2 хороших, работодателя не особо тревожит. Ведь люди работают, ставят галочки в отчетах. Все хорошо.
Злой программист
Какой он? Хороший или плохой? На самом деле он может быть как хорошим, так и плохим.
Это именно тот, который ставит галочки в отчетах и работает только в том случае, если можно галочку поставить в отчете и получить премию за это. Что происходит в коде его не волнует.
Увидел такой код:
Если ТекущаяДата() > Дата("20200101") Тогда
.....
Поменял на Дата("20210101") и знает, что в следующем году он будет востребован.
Зачастую такие программисты знают, где и что нужно поправить при возникновении какой-либо ошибки. И они за это ценятся. Ведь если они уйдут - вся компания встанет.
Но писать хороший код они не хотят, потому что боятся падения своей ценности.
Конечно его можно заменить на хорошего программиста, но процесс этот долгий и проще оставить как есть.
Выводы
Определить, хороший программист, плохой или злой, очень сложно людям, которые далеки от программирования. Если программист быстро делает Ваши хотелки и при этом стоит недорого - еще не означает, что он хороший.
И даже то, что он делает долго и стоит дорого - не означает, что он хороший.
В целом опыт конечно является показателем, но я встречал и плохих программистов с большим опытом и наоборот. Тут больше от человека зависит и от его желания делать что-то, что приносит пользу.
Как максимально точно определить, кто перед Вами на собеседовании? Попробуйте составить задачу из нескольких актов (как я описал выше) и обсудите с кандидатом каждый акт отдельно, не говоря ему о том, что впереди еще задачи. Будет ли он задавать вопросы или тупо делать - вот что важно! Хотя и это не панацея.
