Немного нюансов про офисную работу.

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

Прокомментировав пост "Офисная война: как разрешить конфликт с сотрудником" решил немного больше написать о своем собственном опыте о конфликтах в коллективах, особенно о конфликтах в таких душных порой коллективах, как мир кодеров (и прочих смузихлебах).

Немного больше - это один пример, или лайфхак, который скажет о новом человеке полнее чем любой "тест на тип личности".

Предположим (это пример из реальной жизни) попадает к вам парень, пусть будет Артемка, который должен кодить на php. Конкретно этот парень должен занятся переводом бооолшущей хрени с 7.4 на 8+.

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

А тут стоит пояснить один момент. В комментарии пришло много гуманитариев, и начали мне пихать. Вынесу это и в комментарий отдельный.
1. Ошибка абсолютно мелочная. Очевидная. Исправить ее - секунда.
2. Это код. Он коммитится. То есть видно кто что исправлял. Это значит что и я и любой с доступом увидит - была ошибка у А, Б ее исправил. Тут речь не про "настучать" или "спасти товарища". Мне интересно как думает коллега. Вот в каком направлении у него мозг - в наиболее безопасном или наиболее эффективном.

И пока суть да дело, ему подкидывают еще и сторонние таски, и один из них я разверну.
Есть код, который получив из exif снимка его геолокацию, и время, когда он был сделан, отображает когда будет рассвет и закат завтра, или в выбранную дату, где солнце сейчас (это все важно для landscape photographers), и где было солнце на момент, когда снимок был сделан.

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

Интереснее с моментом "где солнце когда был сделан снимок". Может возникнуть ситуация, что снимок был сделан уже после заката. То есть солнца нет и быть не может, и его вектор на карте не должен быть отображен. Что бы это проверить - получаем время рассвета и заката на момент снимка, на нужных координатах, с учетом часовых поясов и сверяем

if (photoDateTime > photoDatelocalSunriseMillis && photoDateTime < photoDatelocalSunsetMillis) {

И если он не между рассветом и закатом, а например позже - то просто не показываем зеленый вектор.

else { var sunInfo = ' photo was made after sunset'; }

И в моменте вычисления рассвета и заката на день снимка - ошибка. Намеренная. Перепутаны переменные - их там много и именованы они самым дурацким смузихлебным способом (например photoDateoppositeSunTimeAzimuth).

Для вычисления рассвета и заката на день снимка - на самом деле передается сегодняшняя дата. А не дата, которая была 2 года назад. И все как бы работает, но логика уже не та - если сейчас лето - то будет показано солнце для снимков сделанных в 20:00 в январе, когда солнца нет и в помине.

Вот тут я упрощаю технические моменты и перехожу к воспитательным.

Делается простая ошибка, которую легко найти, и легко исправить. И Артемка ее естественно находит. А дальше мы смотрим (я смотрю) куда он побежит.

Плохой Артемка побежит ко мне рассказать что он нашел ошибку. Был бы хвост - вилял бы.

Хороший Артемка - побежит к тому, кто сделал ошибку.

Идеальный - сам исправит. (Тут дополню - из комментариев понял что не все умеют в git - Артемка "сам предложит исправление", не сам в чужом коде что то сделает, а только укажет - тут ошибка, исправьте).

На самом деле гнать надо ссаными тряпками только того, кто ошибку не найдет. Все остальные Артемки - молодцы.

Но в коллективе надо воспитывать третьего.

2
27 комментариев