Кадр из фильма Kingsman
Уверены, в этой статье вы точно узнаете своих сотрудников, а возможно, и себя. Шведский предприниматель и разработчик Дэвид Эльбе описал восемь типов программистов, с которыми ему приходилось иметь дело за последние 10 лет работы в проектах по веб-разработке. Какие типы лучше всего объединить в команду и какой код от них ждать — читайте в переводе от Alconost Translations.
1. Агент 007
Кадр из мультфильма “Пингвины Мадагаскара”
Быстро вникает в ваши проблемы и решает их. Не очень заботится о качестве кода. Ему не придет в голову исправлять отступы в чужом коде. Если необходимо, «воспользуется скотчем».
Время от времени может писать действительно хороший код. Счастлив, когда другие люди делают рефакторинг его кода, после чего тот работает по-прежнему хорошо.
Если такой сотрудник уволится, будет трудно исправлять проблемы во всем приложении. Всегда выдает результаты быстрее, чем от него ожидают. Заказчики и менеджеры без ума от него.
Плохо срабатывается с Перфекционистом.
2. Господин 90 %
Доводит решение проблемы почти до конца, но всегда упускает что-то, без чего весь компонент бесполезен или нестабилен. Его больше волнует сам код, а не то, как будет работать конечный продукт.
Поначалу его прогресс впечатляет, так как он выполняет большое количество запланированных дел, но впоследствии наступает разочарование, когда якобы уже решенные проблемы приходится решать еще раз.
Не уживается с тестерами, но отлично соблюдает дедлайны. Объедините такого программиста в одну команду с Агентом 007. Это будет хорошая команда.
3. Любитель переписывать код
Никогда не оставит нетронутым ни одного фрагмента кода, если считает, что можно выполнить рефакторинг этого кода. Может тратить больше времени на рефакторинг несущественной части кодовой базы, чем на решение реальной проблемы.
Его код имеет лучшие в истории результаты тестирования, но всегда находится в состоянии переработки.
Если дать такому программисту существующий проект на PHP и MySQL, он начнет переписывать его на Go и базе данных, не поддерживающей SQL. И только потом он спросит, какую проблему необходимо было решить.
4. Перфекционист
Похож на Любителя переписывать код, но в отличие от него стремится сделать идеальным свой собственный код. Может тратить целые дни на задачи, которые Агент 007 решает за пару минут, но при этом готовый код будет безупречен.
Его по-настоящему раздражает чужой код. Вы вряд ли захотите, чтобы такой человек проверял результаты вашей работы.
Перфекционист никогда не может правильно оценивать время, необходимое на проект, так как совершенство не имеет временных рамок.
5. Кодер-копипастер
Получил свою работу очень давно, но понятия не имеет, что он делает. Каждый день благодарит высшие силы за бэкапы и системы управления версиями кода, потому что когда он пытается сделать что-нибудь, очень велика вероятность, что что-нибудь сломается.
Любит решать проблемы в рабочих средах, так как его локальная копия для разработки никогда не работает. Проводит половину дня на сайте Stack Overflow.
6. Экспериментатор
Постоянно пробует новые редакторы, фреймворки, средства сборки, языки программирования и клавиатуры. Он на самом деле горит желанием использовать какую-нибудь новейшую «блестящую штучку» в вашем очередном проекте. Может потратить неделю, настраивая приложение, только затем, чтобы на следующий день еще что-нибудь улучшить.
Никто ничего не знает о качестве его кода, поскольку он ничего не создает, но при этом постоянно экспериментирует с новинками.
Хорошо срабатывается с Любителем переписывать код.
7. Спагетти-кодер
Постоянно «срезает углы», чтобы соблюсти дедлайны. Вероятно, один из самых продуктивных сотрудников, так как постоянно реализует новые компоненты. После такого программиста остается недокументированный нетестированный код, в котором даже сам автор не сможет разобраться через месяц.
В долгосрочной перспективе может принести больше проблем, чем пользы, но отлично соблюдает дедлайны и быстро создает компоненты. Может загрузить все ваши секретные API-ключи в ваш опенсорсный проект на Github, потому что это самое быстрое и простое решение.
Плохо уживается с Перфекционистом, создает много работы для Любителя переписывать код.
8. Псевдокодер
Менеджер, который считает, что сможет лучше объяснить что-то сотрудникам, написав псевдокод.
if
price of beer is less than 10
then
do order drink
else
exit foobar
В действительности это выглядит так, как будто он разговаривает с ребенком: «Ой, какой милашка! Принеси мамочке вон тот красный мячик! Умница, хороший программист!»
Ну как, узнали себя в каком-то из типов?
Комментарии (82)
zenn
02.06.2015 08:59+2Прошел следующие этапы: псевдокодер, спагетти-кодер, сейчас боюсь дойти до «перфекциониста» с элементами «экспериментатора»
Frost47rus
02.06.2015 09:19+14Я думаю, все программисты в разные моменты времени и требований — это сочетания перечисленных в статье за исключением 5 и 8. Последние — не программисты.
z0rg
02.06.2015 12:52+4все программисты в разные моменты времени и требований
В точку, когда читал, нашел себя в разных типах, в разные временные отрезки и на разных проектах.
Temirkhan
02.06.2015 18:29Тут все так же, как с темпераментами, но в случае с кодом имеет хаотическое влияние техзадание)
MrEsp
02.06.2015 10:06+7Действительно, не кажется ли автору статьи, что категории в общем-то не взаимоисключающие? Например, 6 и 4 вполне могут сочетаться. Но в целом, многие категории как-то наталкивают на представления о начинающем программисте.
andvgal
02.06.2015 10:33Соглашусь. Это не сколько категории, а набор личных качеств. Некоторые категории получаются противоположными экстремумами одной шкалы измерения меры. В списке явно каких-то измерений ещё не хватает.
В идеале у разработчика должен быть баланс при начале работы с поставленной задачей, а уже исходя из ситуации динамически смещаться в ту или иную сторону по мере необходимости. Беда когда программист изначально смещён в своём подходе к решению задач, требуя пристального контроля для соблюдения сроков и качества. Это свойственно молодым и неопытным… Ну, или старым и упёртым.
mickvav
02.06.2015 20:07Я бы сказал, что авторы нащупали некоторые базисные вектора подпространства «программисты». Не все, и вероятно линейно зависимые, но попытка зачётная.
totuin
02.06.2015 10:42+1Полноценный агент 007, за что много раз получал по мозгам от Перфекциониста. Но сработались нормально. В начале задачи пытались работать по его правилам, под дедлайн возжи отдавались мне, и почти всегда успевали. Но в начале следующей задачи он матерясь в душе приводил в порядок мой код решения предыдущей задачи.
SVVer
02.06.2015 10:48Это здорово, когда 007 осознает, что он им является! Бывает что человек явно из этой категории, но признать этого не хочет, поэтому к попыткам править свой код относится очень болезненно
andvgal
02.06.2015 10:45+3Псевдокод слишком негативно освещён. Очень часто перелопачивая несколько страниц технических требований по разрабатываемым продуктам (или уже каких-то инженерных документов) требуется сжато и понятно изложить постановку задаче в issue tracker'а. Простая отсылка к документу и даже его обсуждение не всегда даёт желаемый результат и даже негативно сказывается на производительности команды, т.к. все разработчики вынуждены перечитывать весь документ (100-1000+ стр.), обновляющийся по ходу разработки, чтобы полностью понять одно конкретное требование из него.
Псевдокод позволяет более осведомлённому архитектору и менеджеру, видящих проект целиком, описать требуемую логику, которую впоследствии смогут быстро понять другие участники команды, когда будут разбираться в коде двухлетней давности.
valexey
02.06.2015 10:56+1Любит решать проблемы в рабочих средах, так как его локальная копия для разработки никогда не работает.
Не сразу понятно что за рабочие среды такие. А вот в оригинале все понятно:
Likes to fix things in production environments, because her local development copy never works.
Человек любит сразу на продакшн-серваке разработку вести (в частности)!bigfatbrowncat
02.06.2015 12:41+5Предложу осмысленный, хоть и вольный перевод: «Предпочитает вести разработку на сервере заказчика, потому что не в состоянии настроить рабочую среду у себя на машине»
Alexeyco
02.06.2015 10:58+2> Если дать такому программисту существующий проект на PHP и MySQL, он начнет переписывать его на Go и базе данных, не поддерживающей SQL.
Мы знакомы???valexey
02.06.2015 11:02+8Кстати, не понятно почему и зачем перевели NoSQL (в виде «не поддерживающей SQL»), но почему тогда и SQL не перевели? ;-)
Throwable
02.06.2015 11:42+3Перфекционист-экспериментатор. Такое возможно? :)
У меня в проекте есть копипейстер. Фраза «понятия не имеет, что он делает» просто в яблочко! К сожалению, он не проводит дни на StackOverflow. Для любой даже самой простой задачи он задаст пятьдесят вопросов, до тех пор, когда ему не объяснишь даже не как делать, а как это написать. А после этого добьет еще пятьюдесятью вопросами типа «я написал как ты сказал, а у меня вылез этот эксепшн», и копипейст стектрейса…
Archon
02.06.2015 12:03+7Зачем вы его держите? По-моему, такому человеку надо объяснить, что либо он начинает делать всё сам (с разумным привлечением помощи в оговоренных моментах), либо вы с ним прощаетесь.
Как минимум, при желании его можно превратить в человека, который будет говорить: я сейчас не знаю, как конкретно буду это делать, поэтому сначала исследую вопрос, и только потом дам оценку сроков. Но если потакать его желаниям дёргать коллег по каждой строчке кода, он будет продолжать так делать до бесконечности. Это путь наименьшего сопротивления.
Кстати, запрещать ему дёргать именно вас по пустякам бесполезно, он будет дёргать кого-то ещё, причём постарается, чтобы вы этого не видели. Посадите его поближе к себе и смотрите, как он работает.
vsb
02.06.2015 12:16+2Попробуйте найти для него работу, в которой не может возникнуть много вопросов. Часто бывают унылые куски, качество которых особо не важно, важна именно копипаста. Грамотный специалист при виде этих задач впадает в уныние (ну или начинает радостно разрабатывать Большой Фреймворк на ближайшие пару лет). А копипастеру самое то. Все вопросы решаются подсматриванием в аналогичные готовые куски.
Throwable
02.06.2015 12:41Собственно я его и посадил писать интеграционные тесты, где надо придумать большое количество данных, заполнять формы и сообщения. При всем при том, что вся инфраструктура тестинга разработана, чел не понимает даже какие случаи надо оттестировать. Весь отчет: «я попробовал запустить тест, высылаю тебе лог системы». К сожалению, решение о его присутствии в команде зависит не от меня. Он был приведен, чтобы «набираться опыта», но челу это как бы не нужно.
Archon
03.06.2015 08:59К счастью, в моих командах таких случаев не было, но со стороны я это наблюдал. Лучшее, что можно сделать — отстранить его от работы вообще, чтобы не мешался под ногами и не отвлекал других. Пусть сидит тихонько в углу, в игрушки играет. Если ему это не понравится (в чём я сомневаюсь) и он побежит жаловаться своему покровителю — объясните ему, что вы можете либо заниматься обучением дундука, не желающего учиться, либо делать свою основную работу.
worldmind
02.06.2015 11:58Слишком много пунктов, достаточно всего трёх:
1. Куятор — выдаёт быстрый результат всегда ужасного качества, тем кто не знает изнанки нравится, тем кто знает изнанку — нет
2. Потерянный хакер — знает технологии, но результат выдаёт исключительно медленно и обычно не очень хорошего качества т.к. не всегда технологии к месту и не всегда понята задача, никому не нравится.
3. Нормальный программист — пишет нормального качества код, тестирует его. Работает не быстро, но хорошо. Разработчикам нравится, желающим результата кажется что он работает медленно, особенно на фоне куятора.
остальное это уже незначительные модификации этих трёх вариантовArchon
02.06.2015 12:20+4Куятор куятору рознь. Одно дело выдать результат ужасного качества, который ещё и не решает проблему как надо, и который выгоднее было написать сразу хорошо. А другое — в кратчайшие сроки подпереть падающую стену костылём, или слепить новую функцию из говна и говна (даже не используя палки), чтобы как можно быстрее всё заработало так, как надо.
Грамотный куятор востребован и любим в двух случаях: либо когда всё уже горит, либо когда неясно, надо ли оно вообще, или этот кусок проекта покроется пылью через два дня после релиза. Это и есть «агент 007» по классификации поста.worldmind
02.06.2015 14:01нене, любовь к куятору означает что всё плохо, ничем хорошим его не оправдать, разве что сферический в вакууме случай когда куятор делает прототип, но сразу после того как становится ясно что он нужен его переписывают нормальные программисты
Archon
02.06.2015 15:30+7Вы живёте в идеальном мире, где ничего не падает по вине третьих сторон, о DDoS-атаках ваша компания знает из газет, сервера не умирают посреди ночи, а интернет-каналы всегда стабильны? Что ж, могу за вас порадоваться, потому что где-то в вашей компании сидит куятор, который любезно огораживает вас от всего этого, чтобы вы могли спать по ночам и работать по техзаданию.
Если всё уже горит прямо сейчас и каждая минута простоя влетает бизнесу в кругленькую сумму, составление подробного ТЗ, как и написание кода с покрытием тестами и код-ревью, ни до чего хорошего не доведёт.
Ну а про ваш случай… За свою жизнь я понаписал много таких прототипов. Большинство из них продержались сравнительно недолго и были переписаны после прояснения ситуации с требованиями к продукту, но есть и пара исключений, когда прототип попадал настолько в яблочко, что существенных изменений в него вносить не требовалось несколько лет. Но даже в случае одноразовых прототипов, если бы они не был написаны, этих продуктов бы вообще не было, они был бы навечно похоронены на этапе совещаний и согласований.
Хреновый код при равной стабильности и скорости работы отличается от хорошего кода только маленькой стоимостью написания и сравнительно большой стоимостью изменения. Никаких других отличий между ними нет, как бы ни было приятно многим воображать обратное.worldmind
02.06.2015 15:55-4Нене, то что произошло по вине третьих сторон легко исправляется хорошими админами и программистами (мало того, они пишут так что внешний мир редко что-то ломает), куятор для этого не нужен.
Зато куятор порождает код изменять который может практически только он, а без него стоимость будет очень высока.
pavlick
02.06.2015 12:23пятый пункт, судя по отпечаткам, даже копипастит двумя руками. Не преставляю, как можно так нажать одной рукой, чтобы остались такие отпечатки, обычно cmd нажимается боком или даже чуть-чуть ногтевой стороной большого пальца. За исключением копипастера у нас есть все типы
Ogra
02.06.2015 12:39А я нажимаю мизинцем. Как-то так и должен остаться отпечаток.
pavlick
02.06.2015 12:42именно cmd? в случае с ctrl и виндовой клавой, да, мизинец удобнее всего. Но на маковой клаве мне даже приходится прикладывать некоторое усилие, чтобы попасть мизинцем в cmd, а указательным в c/v
Ogra
02.06.2015 13:00ctrl, ага.
cmd на маковой, судя по картинке, расположен как alt на виндовой… Можно средним нажимать, а указательным — с и v, тогда получатся такие отпечатки. Но я бы тоже большим нажимал.
Sway
02.06.2015 13:04Я alt на обычной клавиатуре в комбинации Alt+V нажимаю безымянным пальцем. Отпечаток будет полный и нажимать удобно. Так что вполне правдоподобно.
bodqhrohro
02.06.2015 16:33При слепом десятипальцевом вводе разумнее нажимать Cmd/Alt большим пальцем. Остальные модификаторы — уже от клавиатуры зависит, слишком большой разброс. Про функциональные клавиши и говорить нечего, там ад и содомия, особенно на ноутбуках.
bachin
02.06.2015 13:08+1Полноценный «4. Перфекционист». Обожаю работать с «2. Господином 90%».
К сожалению, часто приходится делать «7. Спагетти-кодер», ненавижу «6. Экспериментатор», но перфекционирую и его при необходимости :)
pfemidi
02.06.2015 14:14Во, у меня почти то же самое. Правда с некоторыми отличиями: «6. Экспериментатор» никогда не делаю и с представителями такого стараюсь не связываться, но раньше довольно часто обожал (как правильно перевёл valexey тут) «Человек любит сразу на продакшн-серваке разработку вести». Ныне же при работе на заказчика я «4. Перфекционист» на все 100%. Пока не вылижу код так, чтобы «скрипел когда по нему пальцем проведёшь» считаю что работа не сделана. А когда пишу для себя, то или «1. Агент 007», или «7. Спагетти-кодер», всё равно кроме меня этот быдло-китайско-индусский код никогда никто не увидит.
Когда-то потерял собственные исходники, напрочь и без возможности восстановления. Это было давно, я был ещё молод и глуп несравненно, никаких систем контроля версий у нас в организации не использовалось, да я про такие и не знал. Бекапы тоже никто никогда не делал, было полное раздолбайство, а программу надо было поддерживать. Восстанавливать исходники времени не было и я где-то месяца полтора исправлял, добавлял или убирал функциональность в программе методом бинарного патчинга запускаемого файла в hiew. И ничего, работало. Хорошо что эту программу перестали использовать ещё до того, как я уволился, перешли на другое железо и программа стала не нужна. А то бы ух как пришлось бы попотеть тому, кто пришёл после меня. Сейчас я конечно так никогда не поступаю, бекапы и VCS наше всё! Но каким я тогда был программистом согласно приведённому списку? Такого пункта, который бы подходил, я не нашёл.Archon
02.06.2015 15:37Вы подпадали под первый пункт. Его критерий — не плохой код сам по себе, а нацеленность на решение проблем бизнеса ценой абстрагирования от процесса написания кода. Код же при этом может быть плохим (чаще всего), может быть хорошим, или же его может вообще не быть.
knagaev
02.06.2015 13:53+4Пока читал, создалось впечатление, что нормальных программистов, как типа, нет :)
Alexeyslav
02.06.2015 16:52+1Нормальные программисты вне этой классификации. Как сферические кони в вакууме.
bigfatbrowncat
02.06.2015 16:58+1Нормальные программисты, как уже было сказано, находятся посередине между озвученными крайностями.
slawter
02.06.2015 16:03Блин, я мутант, в разные периоды моей жизни на разных проектах во мне были качества практически от каждого типа, разве что кроме псевдокодера)) Как с этим теперь жить?
bigfatbrowncat
02.06.2015 16:59Радоваться. Вы — сбалансированный профессионал. Если, конечно, разные стороны в вас проявлялись в подходящие моменты.
Maverik
02.06.2015 16:56«Всякая классификация хромает» ©
Вообще, не очень удачно разделены группы. Поведение 2, 3, 4, 6, как правило, вызваны одной и той же чертой характера, поэтому почти всегда проявляются одновременно. То же самое можно сказать про пару 5, 7. Только первый и последний пункты стоят особняком.
Увы, скорее вынужден отнести себя к первой группе.bigfatbrowncat
02.06.2015 17:01Не согласен. Про себя могу сказать, что во мне больше всего 2 (увы, борюсь с этим всю жизнь), 6 нет вообще, так как люблю изучитьтехнологию до тонкости прежде, чем применять и не люблю новые, незнакомые подходы — всегда воспринимаю их с недоверием. Перфекционизм во мне развит довольно слабо, код переписываю только когда (если) перестаю в нем ориентироваться из-за запутанности.
MetaDone
02.06.2015 18:17В начале проекта — 1, если остается время — 3
До некоторых проектов пункт №3 не добрался
dyadyaSerezha
02.06.2015 18:58+1Знаю еще три типа:
9. Мастер-ломастер (в некотором смысле, крайний вариант агента 007). Абсолютно, всегда и безоговорочно считает, что он знает все, является истиной в последней инстанции и что его решение не просто самое, но единственно верное. При этом почти всегда применяет теоретические знания совершенно не к месту, «поперёк», в результате чего его решения обычно ломают систему, например по-памяти или по-времени работы. Никогда не делает выводов из своих ошибок, говоря «это не я неправильно сыграл, это все вы неправильно спели!» Умудряется за короткое время настроить против себя всех адекватных программистов, потому что постоянно открыто и резко говорит, что те делают «всё неправильно!». Обычно недолго остается в компании, но новую находит довольно легко, так как на собеседовании может свободно говорить на абстрактно-программисткие темы, не привязаные к реальным задачам.
10. Недоразумение (крайний вариант копи-пастера). Чел, попавший в программисты по недоразумению. Недоразумением остается и причина, по которой его приняли на фирму (родственник начальника?). Не знает базовых вещей и врядли узнает, потому что его мозги вообще не приспособлены для программирования. На работе искренне мучается каждый день и каждый час. Очень стыдится и боится того, что другие могут понять, что он вообще ничего не знает, но ему невдомек, что все другие давно уже это поняли. Но не уходит, предпочитая стоять «на краю пропасти», потому что хуже увольнения ничего не будет.
11. Страшила мудрый. Это больше к архитекторам или тем, кто делает дизайн системы/модуля. Был лучшим в универе, может бесконечно рассуждать про классовые диаграммы, паттерны, алгоритмы, теоремы и прочее, но слабовато знает, как это все работает на практике. Делает любой дизайн с расчетом на сто лет вперед, с максимальной гибкостью и возможностью адаптировать буквально ко всему. В результате дизайн становится просто неподъемным и рушится под своим собственным весом. Хорошо, если продукт рушится сразу. Плохо, если работает, покряхтывая от напряжения, потому что тогда он успевает наворотить столько, что приходится потом годами вычищать системы от его «гибкостей» и «степеней свободы»,vlivyur
03.06.2015 14:57Знаю 11, но только «Был лучшим в универе» не про него.
12. Динозавр — думает что знает всё про продукты версии на рубеже века и упорно применяет эти знания на актуальной версии.
Barlog
03.06.2015 10:48Я господин перфекционист-эксперементатор 90%. Как лечить?
dyadyaSerezha
03.06.2015 12:21Обычно хорошо лечится бабками. Точнее, их недаванием, если сорваны сроки. :)
Barlog
03.06.2015 12:23Тогда сроки могут стать дооооолгими. Да и 90% — это почти рабочее, отсутствие 10% не сразу и заметно.
syno
03.06.2015 12:31Еще есть «перфекцехуист» — это когда изначально хочешь сделать идеально… но и так сойдет.
Keyten
03.06.2015 12:35Может загрузить все ваши секретные API-ключи в ваш опенсорсный проект на Github, потому что это самое быстрое и простое решение.
Кроме шуток, один мой знакомый однажды так и сделал.
Обернулось взломом проекта :)
Правда, ничего особо серьёзного не было, но этот случай ему припоминается до сих пор.
DrLivesey
03.06.2015 20:50Я — Мистер 90 процентов в напряженных ситуациях, но внутренний перфекционист никогда не оставляет в покое.
sayber
09.06.2015 01:52Может быть я один такой странный, но первые 7 пунктов про меня.
В разных ситуациях и проектах подходят различные пункты.
Radegast
11.06.2015 17:27Агент 007, только постоянно форматирую отступы. И очень часто многовато думаю о том, вынести этот кусок кода в лямбду или функцию или оставить, потому что вроде только один раз копипастить придется. Но последнее время вроде всегда выношу.
А вообще список кажется довольно странным. Если последних 6 много, то индустрии наверное должно быть плохо.
k12th
Оригинал:
Это переводится как «Может закоммитить все ваши секретные API-ключи на Github».
alconost Автор
Спасибо! Поправили, сейчас все ок?
k12th
На гитхаб никто ничего не загружает. Закоммитить это именно закоммитить. Если не хотите использовать жаргонизм, напишите «сделать коммит».
darksimpson
<зануда>Ну если уж быть совсем дотошным, то запушить. Коммитят обычно все-таки в свою локальную репу, а потом уже пушат на какой-нибудь ремот</зануда> Хотя
k12th
Я согласен, это так. Но в оригинале — check in, что синоним коммита, а не пуша.
bigfatbrowncat
Есть красивый и элегантный жаргонизм «залить», не являющийся калькой с английского.
k12th
«закоммитить» — это не калька, калька была бы что-нить вроде «засовершить»:) Но «залить» — отличное слово, в самый раз!
knagaev
Вы, случайно, не четвёртый тип? ;)
k12th
2, 3, 4, 6:)
matiouchkine
`check in` — синоним именно пуша, а не коммита, потому что в распределенных репозиториях такого действия нет, оно родом из времен, когда svn было самым прогрессивным хранилищем. В svn — `check in` это push@github, commit@github это add@svn.
k12th
check-in == ci === commit
По смыслу, как уже указывали, больше подходит пуш, да.
k12th
Повторюсь, что в оригинале все-таки check-in, а не push, и по поводу этого термина все претензии к автору, а не к переводчику и тем более не ко мне.
matiouchkine
Давайте я еще раз попробую. В распределенных системах check-in отсутствует. Но термин жив. Ибо еще живы люди, которые помнят svn. Там существовал check-in (и там от был алиасом commit’а, это правда).
Применительно к github — check-in это push. Period. “Make check-in into remote git repository” переводится c английского на консольный язык как “git push”. Period.
Претензий я никаких не высказывал, не минусовал я никогда из принципиальных соображений, я лишь ответил на ваш неверный комментарий.
murr
Если уже быть совсем дотошным, то «закоммитить» родилось в среде пользователей cvs и svn. Там commit означает немедленную отправку изменений на сервер. Отсюда и путаница.