Языки программирования для разработки игр (1/3)
Что ж, недавно писал, что обучаться линейной алгебре надо на примере работы с компьютерной графикой.
Пойдём дальше и почти всерьёз обсудим, на чём стоит писать компьютерные игры. Решил для себя сделать краткий обзор полянок, думаю, будет интересен не только мне.
Обычно берут готовый движок, из которых три явно выделяются (перечисление от более хардкорного к более лояльному пользователю): Unreal, Unity, Godot.
На фоне этих трёх мейнстримных вариантов есть плеяда ушедших на второй план и почти забытых AAA-движков (Source, Cryengine, Serious Engine, etc.), которыми пользуются те кто давно в них вложился, и россыпь indie-вариантов. Из последних произвольно выделю Game Maker, использовал его ещё в школьные годы: одна из моих поделок даже случайно попала в какой-то болгарский компьютерный журнал. Примерно ту же нишу, насколько можно понять со стороны, занимают Construct, Cocos Creator и мн. др.
Для тех, кто хочет написать что-то более-менее с нуля или не хочет бороться с типовыми конвенциями движков, остаётся использование "графических библиотек" (ну или "игровых библиотек", т.е. графика + ввод-вывод + звуки) – кода, который поверх вызовов API операционной системы и низкоуровневых библиотек создаёт весьма тонкую абстракцию, чтобы вещи типа инициализации окна или создания камеры делались в одну строку (вместо череды API-вызовов операционной системы и перемножения трёх матриц соответственно).
Библиотек этих десятки на любой вкус и цвет, среди энтузиастов последнее время популярна Raylib. Так и пишут: создана для любителей программировать и желающих на практике разобраться, как работают видеоигры. Чуть более тонкие абстракции дают библиотеки SDL, GLFW и др.
На самом низком уровне находятся графические API. Долгое время их по сути было два: OpenGL (всеплатформенный) и DirectX (Windows + XBox). Консорциум, отвечающий за разработку OpenGL, объявил, что дальше его развивать не будет и все усилия направит на развитие Vulcan. На устройствах Apple свой Metal. В целом на будущее стоит осваивать Vulcan (а на настоящее и в качестве ностальгии – OpenGL).
Все основные вспомогательные библиотеки и сами графические API имеют C-интерфейсы. Все распространённые языки программирования так или иначе могут его использовать (называется FFI, foreign function invocation). Если использовать полновесный движок, то к нему уже прилагается и свой язык (C++ для Unreal, C# для Unity, собственный GDScript для Godot). Если спускаться на уровень ниже, то выбор пошире.
Языки программирования как художественная литература: кому-то нравится, кому-то нет, но в целом между творчеством бездарных писателей и произведениями искусства разница есть. Предыдущее предложение это такой беззастенчивый дисклеймер, что сейчас пойдут категорические суждения в отношении вещей, сложно поддающихся объективной оценке.
Заранее всё же отвечу на один из типовых контр-аргументов к подобным оценкам: говорят, мол, "настоящий программист" (что-то из серии "настоящий мужик", т.е. виртуальная концепция для манипуляций наивными людьми) должен уметь пользоваться любым инструментом, и относиться к нему стоически. Кто подобное утверждает попросту лишён чувства вкуса (в данной предметной области), поэтому слушать их и вовсе не надо. В использовании хорошего языка есть и очевидные прагматические выгоды, на перечислении которых останавливаться не будем.
#programming
Что ж, недавно писал, что обучаться линейной алгебре надо на примере работы с компьютерной графикой.
Пойдём дальше и почти всерьёз обсудим, на чём стоит писать компьютерные игры. Решил для себя сделать краткий обзор полянок, думаю, будет интересен не только мне.
Обычно берут готовый движок, из которых три явно выделяются (перечисление от более хардкорного к более лояльному пользователю): Unreal, Unity, Godot.
На фоне этих трёх мейнстримных вариантов есть плеяда ушедших на второй план и почти забытых AAA-движков (Source, Cryengine, Serious Engine, etc.), которыми пользуются те кто давно в них вложился, и россыпь indie-вариантов. Из последних произвольно выделю Game Maker, использовал его ещё в школьные годы: одна из моих поделок даже случайно попала в какой-то болгарский компьютерный журнал. Примерно ту же нишу, насколько можно понять со стороны, занимают Construct, Cocos Creator и мн. др.
Для тех, кто хочет написать что-то более-менее с нуля или не хочет бороться с типовыми конвенциями движков, остаётся использование "графических библиотек" (ну или "игровых библиотек", т.е. графика + ввод-вывод + звуки) – кода, который поверх вызовов API операционной системы и низкоуровневых библиотек создаёт весьма тонкую абстракцию, чтобы вещи типа инициализации окна или создания камеры делались в одну строку (вместо череды API-вызовов операционной системы и перемножения трёх матриц соответственно).
Библиотек этих десятки на любой вкус и цвет, среди энтузиастов последнее время популярна Raylib. Так и пишут: создана для любителей программировать и желающих на практике разобраться, как работают видеоигры. Чуть более тонкие абстракции дают библиотеки SDL, GLFW и др.
На самом низком уровне находятся графические API. Долгое время их по сути было два: OpenGL (всеплатформенный) и DirectX (Windows + XBox). Консорциум, отвечающий за разработку OpenGL, объявил, что дальше его развивать не будет и все усилия направит на развитие Vulcan. На устройствах Apple свой Metal. В целом на будущее стоит осваивать Vulcan (а на настоящее и в качестве ностальгии – OpenGL).
Все основные вспомогательные библиотеки и сами графические API имеют C-интерфейсы. Все распространённые языки программирования так или иначе могут его использовать (называется FFI, foreign function invocation). Если использовать полновесный движок, то к нему уже прилагается и свой язык (C++ для Unreal, C# для Unity, собственный GDScript для Godot). Если спускаться на уровень ниже, то выбор пошире.
Языки программирования как художественная литература: кому-то нравится, кому-то нет, но в целом между творчеством бездарных писателей и произведениями искусства разница есть. Предыдущее предложение это такой беззастенчивый дисклеймер, что сейчас пойдут категорические суждения в отношении вещей, сложно поддающихся объективной оценке.
Заранее всё же отвечу на один из типовых контр-аргументов к подобным оценкам: говорят, мол, "настоящий программист" (что-то из серии "настоящий мужик", т.е. виртуальная концепция для манипуляций наивными людьми) должен уметь пользоваться любым инструментом, и относиться к нему стоически. Кто подобное утверждает попросту лишён чувства вкуса (в данной предметной области), поэтому слушать их и вовсе не надо. В использовании хорошего языка есть и очевидные прагматические выгоды, на перечислении которых останавливаться не будем.
#programming
Языки программирования для разработки игр (2/3)
Кстати, спрашивали, зачем я посты разбиваю на несколько эпизодов. Потому что Телеграм не пропускает длинный текст, а на какой-нибудь Медиум я кросс-постить не хочу, мне кажется это будет менее удобно для читателей.
Переходим к списку языков.
1. Ruby (Python, etc.). Знакомо, просто, есть удобные библиотеки (Gosu для Ruby, pygame и множество других для Python). Есть библиотеки общего назначения на любой вкус и под любую задачу. Неудобно компилировать всё в один файл, чтобы можно было легко распространять.
2. Go. Хороший язык для 1985-го года. Использует передовую новинку – сборку мусора – в остальном использует хорошо знакомый набор конструкций школьного Pascal. Примерно так, например, можно из массива выбрать все положительные числа и умножить каждое на два, получив новый массив:
3. C. Вечная классика, которая, вероятно, никогда не умрёт. "Лингва франка", который определил, например, конвенцию вызова функций, используемую повсеместно до сих пор (и нет оснований считать, что она будет в обозримой перспективе заменена чем-то радикально новым). Говорить на универсальном языке дело хорошее, вам без проблем доступен весь набор библиотек. Сам язык архаичный: полностью ручное управление памятью, отсутствие удобных функций в стандартной библиотеке и т.д.
4. C++. Крайне широко применяется в геймдеве и позволяет совместить работу и на низком уровне (ну, к примеру перекладывать вручную биты и байты) и на высоком (классы, ООП). Путь его развития был тяжёлым и тернистым, только к концу двухтысячных комитет разработчиков вдруг очнулся и осознал, что на дворе не 1985-й год, а уже 21-й век. Современных подходов и концепций туда с тех времён напихали под завязку и горшочек продолжает варить: в некотором смысле язык-антипод Go. Для иллюстрации подходит известный анекдот с панчлайном "фонарь, фонарь мне на лоб ещё прилепите!".
5. Zig, Odin. В одну кучу, т.к. без содержательной оценки. Стильно, модно, молодёжно, ориентированно в числе прочего на геймдев. Мне кажется, создатели этих языков просто не справляются с взятыми на себя задачами и какие-то базовые вещи делают ошибочно. Впрочем, не боги горшки обжигают, может быть что-нибудь и выйдет интересное из одного из них или обоих через 3-5 лет.
6. Crystal. Ruby-подобный синтаксис и отношение к пользователю ("программирование должно приносить удовольствие"), помноженный на статическую типизацию, компилирование, высокую производительность. Язык достаточно зрелый, но нет полноценной поддержки Windows.
7. Rust. Создатели языка верно поняли проблематику ручного управления памятью (вкратце: люди ошибаются), но вместо того, чтобы подойти к задаче путём разработки особо умного алгоритма, помогающего программисту не совершать ошибки, они выстроили систему костылей, которая заставляет разработчика с помощью нескольких эзотерических приёмов постоянно доказывать по-прежнему тупому компилятору, что он нигде не ошибся.
Перейдём к шорт-листу победителей.
#programming
Кстати, спрашивали, зачем я посты разбиваю на несколько эпизодов. Потому что Телеграм не пропускает длинный текст, а на какой-нибудь Медиум я кросс-постить не хочу, мне кажется это будет менее удобно для читателей.
Переходим к списку языков.
1. Ruby (Python, etc.). Знакомо, просто, есть удобные библиотеки (Gosu для Ruby, pygame и множество других для Python). Есть библиотеки общего назначения на любой вкус и под любую задачу. Неудобно компилировать всё в один файл, чтобы можно было легко распространять.
2. Go. Хороший язык для 1985-го года. Использует передовую новинку – сборку мусора – в остальном использует хорошо знакомый набор конструкций школьного Pascal. Примерно так, например, можно из массива выбрать все положительные числа и умножить каждое на два, получив новый массив:
numbers := []int{-1, 1, 2, -3, 5}
result := make([]int, 0, len(numbers))
for _, x := range numbers {
if x > 0 {
result = append(result, x*2)
}
}
Что ж, неплохо было бы для языка сорокалетней давности. В языках двадцатилетней давности уже было что-то такое:numbers = [-1, 1, 2, -3, 5]Зачем намеренно нужно пользоваться новым языком, который в момент рождения устарел на 2 поколения, я не знаю. Разработан и поддерживается Google, которому, по мнению создателя языка, этот инструмент помогает заставить не обременённых избыточными талантами выпускников вузов писать хоть как-то работающий код.
numbers.filter { |x| x > 0 }.map { |x| x * 2 }
3. C. Вечная классика, которая, вероятно, никогда не умрёт. "Лингва франка", который определил, например, конвенцию вызова функций, используемую повсеместно до сих пор (и нет оснований считать, что она будет в обозримой перспективе заменена чем-то радикально новым). Говорить на универсальном языке дело хорошее, вам без проблем доступен весь набор библиотек. Сам язык архаичный: полностью ручное управление памятью, отсутствие удобных функций в стандартной библиотеке и т.д.
4. C++. Крайне широко применяется в геймдеве и позволяет совместить работу и на низком уровне (ну, к примеру перекладывать вручную биты и байты) и на высоком (классы, ООП). Путь его развития был тяжёлым и тернистым, только к концу двухтысячных комитет разработчиков вдруг очнулся и осознал, что на дворе не 1985-й год, а уже 21-й век. Современных подходов и концепций туда с тех времён напихали под завязку и горшочек продолжает варить: в некотором смысле язык-антипод Go. Для иллюстрации подходит известный анекдот с панчлайном "фонарь, фонарь мне на лоб ещё прилепите!".
5. Zig, Odin. В одну кучу, т.к. без содержательной оценки. Стильно, модно, молодёжно, ориентированно в числе прочего на геймдев. Мне кажется, создатели этих языков просто не справляются с взятыми на себя задачами и какие-то базовые вещи делают ошибочно. Впрочем, не боги горшки обжигают, может быть что-нибудь и выйдет интересное из одного из них или обоих через 3-5 лет.
6. Crystal. Ruby-подобный синтаксис и отношение к пользователю ("программирование должно приносить удовольствие"), помноженный на статическую типизацию, компилирование, высокую производительность. Язык достаточно зрелый, но нет полноценной поддержки Windows.
7. Rust. Создатели языка верно поняли проблематику ручного управления памятью (вкратце: люди ошибаются), но вместо того, чтобы подойти к задаче путём разработки особо умного алгоритма, помогающего программисту не совершать ошибки, они выстроили систему костылей, которая заставляет разработчика с помощью нескольких эзотерических приёмов постоянно доказывать по-прежнему тупому компилятору, что он нигде не ошибся.
Перейдём к шорт-листу победителей.
#programming
Языки программирования для разработки игр (3/3)
Итак, шорт-лист победителей
A. D. Из названия ясно, что люди хотели сделать "как C/С++, только всё чтобы было лучше". У них это получилось. Доступ к низкоуровневым операциям, более-менее беспроблемная интеграция C (и даже C++) кода, в то же время человеческий синтаксис, хорошая стандартная библиотека, автоматическое управление памятью (отключаемое).
B. Nim. На что был бы похож язык, сделанный без оглядки на внешний вид всех предыдущих, но с использованием наработанного человечеством опыта разработки компиляторов? Да вот на Nim. Есть некоторые очевидные сомнительные моменты в синтаксисе, на тему которых идут вечные холивары, но не буду их даже перечислять из-за ничтожной значимости. В целом взято лучшее из всех миров: управление памятью на гибридной модели (подсчёт ссылок + сборка мусора для циклически связанных объектов; обещают вскоре что-то ещё более интересное выкатить), богатый синтаксис (с адекватным метапрограммированием), хорошая стандартная библиотека. Программисты на современных языках быстро освоятся.
Выбор между двумя вариантами сложный и вот какими соображениями определяется.
– С одной стороны, синтаксис D ограниченно совместим с синтаксисом C (некоторые фрагменты кода можно по сути копи-пастить). Дополнительно, режим ImportC позволяет напрямую использовать сишные хедеры (ну, почти напрямую, поковырять немного придётся, но писать полноценные биндинги, как во всех других языках кроме собственно C и C++, не обязательно).
– С другой стороны, Nim в целом более передовой и перспективный. На нём код получается более лаконичный, выразительный и легко поддерживаемый (на D в целом-то тоже норм, но всё же не дотягивает). Идеология "структур с методами, принимающими структуру или указатель на неё" вместо "классов" (хорошее место в Go, кстати) здесь вполне работает, удобней в обращении чем классический ООП D.
– В установке под Windows проще D. Компилятор Nim работает без нареканий, но процесс развёртывания неприятный.
И там, и там довольно развитое сообщество: форумы, чаты, энтузиасты выкладывающие библиотеки на GitHub и всё такое. У меня сложилось (может быть ошибочное, т.к. знакомство было коротким) впечатление, что в D расклад менее перспективный: пожилого создателя языка уже в каком-то неочевидном направлении начинает тянуть, а среди молодёжи повышенная концентрация, как бы сказать, странных людей.
В Nim создателем-руководителем является молодой рациональный мужик, люди вокруг без особенностей, развито русскоязычное коммьюнити (вплоть до того, что пишут плагины для компиляции под Эльбрус).
В целом фактор сообщества малозначимый, но, пожалуй, на фоне общего паритета добавляет гирьку, склоняющую чашу весов в сторону Nim.
А вообще лучше забыть про все подобные списки и писать на том, что нравится – это первейшее и главнейшее соображение.
#programming
Итак, шорт-лист победителей
A. D. Из названия ясно, что люди хотели сделать "как C/С++, только всё чтобы было лучше". У них это получилось. Доступ к низкоуровневым операциям, более-менее беспроблемная интеграция C (и даже C++) кода, в то же время человеческий синтаксис, хорошая стандартная библиотека, автоматическое управление памятью (отключаемое).
B. Nim. На что был бы похож язык, сделанный без оглядки на внешний вид всех предыдущих, но с использованием наработанного человечеством опыта разработки компиляторов? Да вот на Nim. Есть некоторые очевидные сомнительные моменты в синтаксисе, на тему которых идут вечные холивары, но не буду их даже перечислять из-за ничтожной значимости. В целом взято лучшее из всех миров: управление памятью на гибридной модели (подсчёт ссылок + сборка мусора для циклически связанных объектов; обещают вскоре что-то ещё более интересное выкатить), богатый синтаксис (с адекватным метапрограммированием), хорошая стандартная библиотека. Программисты на современных языках быстро освоятся.
Выбор между двумя вариантами сложный и вот какими соображениями определяется.
– С одной стороны, синтаксис D ограниченно совместим с синтаксисом C (некоторые фрагменты кода можно по сути копи-пастить). Дополнительно, режим ImportC позволяет напрямую использовать сишные хедеры (ну, почти напрямую, поковырять немного придётся, но писать полноценные биндинги, как во всех других языках кроме собственно C и C++, не обязательно).
– С другой стороны, Nim в целом более передовой и перспективный. На нём код получается более лаконичный, выразительный и легко поддерживаемый (на D в целом-то тоже норм, но всё же не дотягивает). Идеология "структур с методами, принимающими структуру или указатель на неё" вместо "классов" (хорошее место в Go, кстати) здесь вполне работает, удобней в обращении чем классический ООП D.
– В установке под Windows проще D. Компилятор Nim работает без нареканий, но процесс развёртывания неприятный.
И там, и там довольно развитое сообщество: форумы, чаты, энтузиасты выкладывающие библиотеки на GitHub и всё такое. У меня сложилось (может быть ошибочное, т.к. знакомство было коротким) впечатление, что в D расклад менее перспективный: пожилого создателя языка уже в каком-то неочевидном направлении начинает тянуть, а среди молодёжи повышенная концентрация, как бы сказать, странных людей.
В Nim создателем-руководителем является молодой рациональный мужик, люди вокруг без особенностей, развито русскоязычное коммьюнити (вплоть до того, что пишут плагины для компиляции под Эльбрус).
В целом фактор сообщества малозначимый, но, пожалуй, на фоне общего паритета добавляет гирьку, склоняющую чашу весов в сторону Nim.
А вообще лучше забыть про все подобные списки и писать на том, что нравится – это первейшее и главнейшее соображение.
#programming
Антирейтинг редакторов Markdown
1. Slack. Пользуясь их интерфейсом ты каждый раз представляешь, как разработчики держали в голове образ тупого менджера (скорее всего, какого-то конкретного человека среди своих инвесторов), который тем лучше себя чувствует, чем меньше видит пунктов в списке каналов и адресатов, равно кнопочек в окне редактирования. Абсолютный лидер по нелепым компромиссам интерфейса в целом и убогости markdown-редактора в частности.
2. Jira. Редактор худо-бедно работает и содержит, вроде бы, все необходимые функции, но примерно в половине случаев как-то подленько вставляет тебе палки в колёса. Отдельно, отсутствие простого и примитивного lock-а при совместном редактировании текста тикета на фоне общей всеобъятной монструозности продукта иначе как специальным издевательством сложно объяснить.
3. Telegram. Продукт, конечно, перерос сам себя, и видно что он это понимает по факту создания Telegraph. То, что функции Telegraph не интегрировали в основное приложение, а вынесли куда подальше, чтобы ими пользовалось как можно меньше людей (но формальный повод для упрёка становился при том менее обоснованным), показывает, что команда разработки с чего-то твёрдо уверена, что деньги будут делать не писатели интеллектуальных пабликов, а твиттерная масса черни с постами "вот моя новая тачка", "Байден оговорился" и "биткоин снова упал ниже $100500". На фоне развития всех этих Sponsor-ов, Boosty-ей и Patreon-ов это выглядит как "не надо денег", что, впрочем, не удивительно для организации, руководимой человеком, потратившим $150k на покупку паспорта мусорного оффшора.
К другой стороне рейтинга: самый лучший редактор Markdown, к которому даже при желании едва ли найдёшь по какому поводу придраться, конечно, в Obsidian.
#programming
1. Slack. Пользуясь их интерфейсом ты каждый раз представляешь, как разработчики держали в голове образ тупого менджера (скорее всего, какого-то конкретного человека среди своих инвесторов), который тем лучше себя чувствует, чем меньше видит пунктов в списке каналов и адресатов, равно кнопочек в окне редактирования. Абсолютный лидер по нелепым компромиссам интерфейса в целом и убогости markdown-редактора в частности.
2. Jira. Редактор худо-бедно работает и содержит, вроде бы, все необходимые функции, но примерно в половине случаев как-то подленько вставляет тебе палки в колёса. Отдельно, отсутствие простого и примитивного lock-а при совместном редактировании текста тикета на фоне общей всеобъятной монструозности продукта иначе как специальным издевательством сложно объяснить.
3. Telegram. Продукт, конечно, перерос сам себя, и видно что он это понимает по факту создания Telegraph. То, что функции Telegraph не интегрировали в основное приложение, а вынесли куда подальше, чтобы ими пользовалось как можно меньше людей (но формальный повод для упрёка становился при том менее обоснованным), показывает, что команда разработки с чего-то твёрдо уверена, что деньги будут делать не писатели интеллектуальных пабликов, а твиттерная масса черни с постами "вот моя новая тачка", "Байден оговорился" и "биткоин снова упал ниже $100500". На фоне развития всех этих Sponsor-ов, Boosty-ей и Patreon-ов это выглядит как "не надо денег", что, впрочем, не удивительно для организации, руководимой человеком, потратившим $150k на покупку паспорта мусорного оффшора.
К другой стороне рейтинга: самый лучший редактор Markdown, к которому даже при желании едва ли найдёшь по какому поводу придраться, конечно, в Obsidian.
#programming
Вкратце про лидерство (1/2)
И в обсуждениях, и в личной переписке последнее время регулярно поднимается тема управления в IT.
Часто в подобных обсуждениях употребляют слово "лидер".
Некоторое время назад в сообществе Metapractice начали разбирать заход системных инженеров на этот вопрос (среди русских программистов изрядно любителей системной инженерии). Как видно по их построениям, наши системные инженеры заимствуют как интерес именно к лидерству, так и конкретное прочтение определения и т.д. у американцев.
В США "быть" равно "убедительно казаться" (fake it, till you make it и т.д.), а лидерство, бесспорно, это навык в первую очередь демонстрации... чего-то (точнее, ряда вещей).
В одном из обсуждений предложили рассмотреть в этом контексте книгу Extreme Ownership (в сети можно найти полную версию), где лидерству во всех сферах учит буквально командир отделения морских котиков. Ну, солдат в качестве управленца в IT это анекдот, который, увы, иногда воплощается и в реальности, но не уверен, что многим хотелось бы в месте где это реализовано работать. Всё сразу понятно, но рассмотрим подробней.
Книга построена как набор армейских баек, перемежающихся не столь уж оригинальными (хотя в сумме интересными) предписаниями, мол берите ответственность за всё что с вашим отделом происходит, не привязывайте слишком уж к трудящимся (но и не отдаляйтесь чрезмерно) и т.д.
Лидерство автора, практикуемое в отношении читателя, сводится к демонстрации набора (вероятно подлинных) фотографий с автоматами и вертолётами и рассказывании армейских баек. Ну и к количеству продаж и оценке критиков, конечно. Таким образом лидерство, которое продаёт и пропагандирует автор (плюс издатель) это демонстрация превосходства:
- воина, в буквальном смысле, над офисным клерком
- самоуверенного человека над тютей
- успешного человека над неуспешным
Конструкция содержит слабое место, т.к. даже играя по предложенным правилам соревнования в "лидерстве" стоит ещё иметь в виду превосходство умного человека над глупым (или хотя бы образованного над необразованным). По понятным причинам автор на этом внимание не акцентирует.
Лидерство человека, прочитавшего книгу, над тем, кто не читал, выражается, должно быть, в демонстрации причастности к "крутым дядькам", замаскированной под демонстрацию причастности к "крутым методологиям".
При этом не стоит отрицать частной полезности конкретных рекомендаций подобной литературы: если бы они были пустыми на все 100%, а не на 80%, то продажи раскрутить и с большими бюджетами едва ли было бы возможно.
С программистами всё это напускное лидерство, конечно, работает практически никак. Я об этом писал в пятом пункте первого (т.е. поневоле программного) поста данного канала. Лидер среди программистов это человек, который лучше всех пишет код.
There is no escaping this. Это неизбежный факт, с которым стоит смириться.
Можно представить, что программисты внезапно попадут, например, в окоп, тогда лидером будет сержант морских котиков. Или во время пожара в офисе лидерство захватить может аналогично человек, к коду отношения вообще не имеющий. В таких контекстах однако и программисты не вполне будут программистами (будут играть другую роль), поэтому и говорить о таком смысла нет.
Можно, конечно, и офис превратить в аналог поля боя, тогда бывший сержант, ныне бизнес-консультант по широкому кругу вопросов, тоже вполне может захватить лидерство. Но всё же в первую очередь, как в обсуждаемой книге описано, это будет лидерство среди самих же менеджеров, востребованным специалистам (тем более программистам, по понятным причинам) это всё равно будет не особо важно (конечно, их можно запугать, но это уже не будет лидерство в описываемом смысле).
#programming #management
И в обсуждениях, и в личной переписке последнее время регулярно поднимается тема управления в IT.
Часто в подобных обсуждениях употребляют слово "лидер".
Некоторое время назад в сообществе Metapractice начали разбирать заход системных инженеров на этот вопрос (среди русских программистов изрядно любителей системной инженерии). Как видно по их построениям, наши системные инженеры заимствуют как интерес именно к лидерству, так и конкретное прочтение определения и т.д. у американцев.
В США "быть" равно "убедительно казаться" (fake it, till you make it и т.д.), а лидерство, бесспорно, это навык в первую очередь демонстрации... чего-то (точнее, ряда вещей).
В одном из обсуждений предложили рассмотреть в этом контексте книгу Extreme Ownership (в сети можно найти полную версию), где лидерству во всех сферах учит буквально командир отделения морских котиков. Ну, солдат в качестве управленца в IT это анекдот, который, увы, иногда воплощается и в реальности, но не уверен, что многим хотелось бы в месте где это реализовано работать. Всё сразу понятно, но рассмотрим подробней.
Книга построена как набор армейских баек, перемежающихся не столь уж оригинальными (хотя в сумме интересными) предписаниями, мол берите ответственность за всё что с вашим отделом происходит, не привязывайте слишком уж к трудящимся (но и не отдаляйтесь чрезмерно) и т.д.
Лидерство автора, практикуемое в отношении читателя, сводится к демонстрации набора (вероятно подлинных) фотографий с автоматами и вертолётами и рассказывании армейских баек. Ну и к количеству продаж и оценке критиков, конечно. Таким образом лидерство, которое продаёт и пропагандирует автор (плюс издатель) это демонстрация превосходства:
- воина, в буквальном смысле, над офисным клерком
- самоуверенного человека над тютей
- успешного человека над неуспешным
Конструкция содержит слабое место, т.к. даже играя по предложенным правилам соревнования в "лидерстве" стоит ещё иметь в виду превосходство умного человека над глупым (или хотя бы образованного над необразованным). По понятным причинам автор на этом внимание не акцентирует.
Лидерство человека, прочитавшего книгу, над тем, кто не читал, выражается, должно быть, в демонстрации причастности к "крутым дядькам", замаскированной под демонстрацию причастности к "крутым методологиям".
При этом не стоит отрицать частной полезности конкретных рекомендаций подобной литературы: если бы они были пустыми на все 100%, а не на 80%, то продажи раскрутить и с большими бюджетами едва ли было бы возможно.
С программистами всё это напускное лидерство, конечно, работает практически никак. Я об этом писал в пятом пункте первого (т.е. поневоле программного) поста данного канала. Лидер среди программистов это человек, который лучше всех пишет код.
There is no escaping this. Это неизбежный факт, с которым стоит смириться.
Можно представить, что программисты внезапно попадут, например, в окоп, тогда лидером будет сержант морских котиков. Или во время пожара в офисе лидерство захватить может аналогично человек, к коду отношения вообще не имеющий. В таких контекстах однако и программисты не вполне будут программистами (будут играть другую роль), поэтому и говорить о таком смысла нет.
Можно, конечно, и офис превратить в аналог поля боя, тогда бывший сержант, ныне бизнес-консультант по широкому кругу вопросов, тоже вполне может захватить лидерство. Но всё же в первую очередь, как в обсуждаемой книге описано, это будет лидерство среди самих же менеджеров, востребованным специалистам (тем более программистам, по понятным причинам) это всё равно будет не особо важно (конечно, их можно запугать, но это уже не будет лидерство в описываемом смысле).
#programming #management
Вкратце про лидерство (2/2)
Получается человеку, который хочет лидировать у программистов, требуется:
1. Либо лучше всех писать код. Это будет сильно и бесспорно.
2. Либо смещать систему оценок в область своих сильных профессиональных сторон. Так сказать лидировать на своей территории. Но чем дальше смещена от основного рабочего контекста, тем меньше остаётся контроля и менее продуктивным будет лидерство. Например, лидер программистов может утверждать себя как хороший дизайнер (и так или иначе постоянно доказывать, что дизайнеры важней программистов), или человек с учёной степенью в точных или технических науках (и так или иначе постоянно доказывать, что образование важней навыков), или ещё что-нибудь вроде того. Это будет требовать регулярных накладных расходов, но всё ещё будет работать.
3. Либо манипулировать общечеловеческими атрибутами лидерства: демонстрировать уверенность в себе, знание цели, наличие явного или скрытого плана действий, способности добывать универсально ценные ресурсы, отсутствие боязни взять на себя инициативу, взгляды поверх голов, отсутствие суеты, справедливое и равное отношение ко всем и т.п. Это будет вызывать общую лояльность команды, но вот напрямую воздействовать на ход работ уже практически не будет возможности. Как только такой лидер (о котором в обсуждаемой книге-то и пишут) переступит невидимую, но вполне чёткую черту своего уровня предметной компетентности, вся магия его харизмы превратится тут же в тыкву. Поэтому, конечно, умный лидер-харизматик такого никогда и не делает.
#programming #management
Получается человеку, который хочет лидировать у программистов, требуется:
1. Либо лучше всех писать код. Это будет сильно и бесспорно.
2. Либо смещать систему оценок в область своих сильных профессиональных сторон. Так сказать лидировать на своей территории. Но чем дальше смещена от основного рабочего контекста, тем меньше остаётся контроля и менее продуктивным будет лидерство. Например, лидер программистов может утверждать себя как хороший дизайнер (и так или иначе постоянно доказывать, что дизайнеры важней программистов), или человек с учёной степенью в точных или технических науках (и так или иначе постоянно доказывать, что образование важней навыков), или ещё что-нибудь вроде того. Это будет требовать регулярных накладных расходов, но всё ещё будет работать.
3. Либо манипулировать общечеловеческими атрибутами лидерства: демонстрировать уверенность в себе, знание цели, наличие явного или скрытого плана действий, способности добывать универсально ценные ресурсы, отсутствие боязни взять на себя инициативу, взгляды поверх голов, отсутствие суеты, справедливое и равное отношение ко всем и т.п. Это будет вызывать общую лояльность команды, но вот напрямую воздействовать на ход работ уже практически не будет возможности. Как только такой лидер (о котором в обсуждаемой книге-то и пишут) переступит невидимую, но вполне чёткую черту своего уровня предметной компетентности, вся магия его харизмы превратится тут же в тыкву. Поэтому, конечно, умный лидер-харизматик такого никогда и не делает.
#programming #management
Вкратце про лидеров - начальников - руководителей - управленцев...
В предыдущий раз поднимали тему лидеров и лидерства.
Смотря на это всё со стороны, ясно, что лидерство в целом переоценённая тема. Понятно, что прирождённым (или "самосделанным", self-made) лидерам выгодно всё к ней сводить, уж такие они, по определению, люди, но нам-то что с того.
Интересно было бы закончить предыдущее обсуждение из сообщества и хотя бы вчерне попытаться определить основные функциональные варианты "начальства".
Понятно, что реальный человек всегда будет иметь черты и того, и другого, и третьего, но всё равно интересно попробовать описать "чистые" типы.
Итак:
1. Лидер. Манипулирует первым делом "харизмой", точнее неким природным феноменом "лидерства" (человек – стайное животное), вызывающим рефлекторную лояльность. Ещё точнее это не один феномен, а набор коммуникативно-поведенческих привычек. Во вторую очередь использует превосходство в конкретной деятельности, например, в непосредственном исполнении обязанностей. Этакий Гас Фринг из Breaking Bad.
2. Начальник. Манипулирует возможностью нанимать и увольнять. По-моему здесь всё просто.
3. Руководитель. Похож на начальника, но немного другое содержание: манипулирует возможностью назначать задания, утверждать проекты, формировать отделы (группы, коллективы) и т.д.
4. Управленец. Манипулирует документацией: регламентами, приказами и т.д.
Вот, как-то так. Забавно, что со словом "неформальный" хорошо сочетается только "лидер". Остальное так себе, как какая-то короткая флуктуация может быть, а вдолгую нет. А вот "неформальный лидер" вполне устойчивой может быть штукой.
Отмечу, что по данной классификации в IT, конечно, востребованней всего именно тип управленца. Во-первых, он ближе всего по менталитету (да и по содержанию деятельности) программистам. Во-вторых, сейчас множество подходов к управлению тривиально материализуются через существующий софт: в самом деле, со всякими Джирами, Гитхабами, Хелпдесками, Скетчами и прочим все управленческие хитрости чуть ли не изоморфно отражаются на хитрости настройки соответствующего стандартного софта. Любой управленец с таким софтом должен умело обращаться, и чуть ли не любой кто умело обращается автоматически превращается в неплохого управленца.
Конечно, и лидерские качества, и прочее управленцу лишними в любом случае не будут. Кстати, выше рассмотрели разные функциональные типы начальства по отношению к подчинённым – интересно сделать раскладку по отношению к вышестоящему начальству. А потом можно всевозможные комбинации рассматривать. А потом смешанные типы. Тестов понаделать, методик, курсов сертифицированных и т.д. Поле-то непаханное! :)
#programming #management
В предыдущий раз поднимали тему лидеров и лидерства.
Смотря на это всё со стороны, ясно, что лидерство в целом переоценённая тема. Понятно, что прирождённым (или "самосделанным", self-made) лидерам выгодно всё к ней сводить, уж такие они, по определению, люди, но нам-то что с того.
Интересно было бы закончить предыдущее обсуждение из сообщества и хотя бы вчерне попытаться определить основные функциональные варианты "начальства".
Понятно, что реальный человек всегда будет иметь черты и того, и другого, и третьего, но всё равно интересно попробовать описать "чистые" типы.
Итак:
1. Лидер. Манипулирует первым делом "харизмой", точнее неким природным феноменом "лидерства" (человек – стайное животное), вызывающим рефлекторную лояльность. Ещё точнее это не один феномен, а набор коммуникативно-поведенческих привычек. Во вторую очередь использует превосходство в конкретной деятельности, например, в непосредственном исполнении обязанностей. Этакий Гас Фринг из Breaking Bad.
2. Начальник. Манипулирует возможностью нанимать и увольнять. По-моему здесь всё просто.
3. Руководитель. Похож на начальника, но немного другое содержание: манипулирует возможностью назначать задания, утверждать проекты, формировать отделы (группы, коллективы) и т.д.
4. Управленец. Манипулирует документацией: регламентами, приказами и т.д.
Вот, как-то так. Забавно, что со словом "неформальный" хорошо сочетается только "лидер". Остальное так себе, как какая-то короткая флуктуация может быть, а вдолгую нет. А вот "неформальный лидер" вполне устойчивой может быть штукой.
Отмечу, что по данной классификации в IT, конечно, востребованней всего именно тип управленца. Во-первых, он ближе всего по менталитету (да и по содержанию деятельности) программистам. Во-вторых, сейчас множество подходов к управлению тривиально материализуются через существующий софт: в самом деле, со всякими Джирами, Гитхабами, Хелпдесками, Скетчами и прочим все управленческие хитрости чуть ли не изоморфно отражаются на хитрости настройки соответствующего стандартного софта. Любой управленец с таким софтом должен умело обращаться, и чуть ли не любой кто умело обращается автоматически превращается в неплохого управленца.
Конечно, и лидерские качества, и прочее управленцу лишними в любом случае не будут. Кстати, выше рассмотрели разные функциональные типы начальства по отношению к подчинённым – интересно сделать раскладку по отношению к вышестоящему начальству. А потом можно всевозможные комбинации рассматривать. А потом смешанные типы. Тестов понаделать, методик, курсов сертифицированных и т.д. Поле-то непаханное! :)
#programming #management
Нейросети для программирования: новая сводка новостей
Ранее уже писал на эту тему, но новости продолжают поступать: гугловскую нейросеть научили решать олимпиадные задачки по программированию.
Одновременно ChatGPT демонстрирует решение широкого круга диалоговых задач. Прогресс заметный. Проблема сохранения контекста, о которой немного писал ранее, решена. Представить себе общение с современными нейросетями можно примерно как общение с Гуглом или Википедией, который при этом накапливает опыт диалога, позволяет уточнять и редактировать запрос (и ответ) ссылаясь на ходу на предыдущие реплики и имеет базовый модуль "написания коротких эссе на заданную тему". О тесте Тьюринга говорить больше не серьёзно, все шероховатости, понятно, будут в самое ближайшее время дошлифованы.
Разработчики "программистской" нейросети сразу же остроумно сами себя критикуют: мол, электричества она ест как небольшой завод, код зачастую реализует неоптимальное решение, места в конкурсах занимает не первые. Короче, люди ещё могут на что-то надеяться, но недолго.
Ну, то есть, перечисляют "количественные" недоработки, но не качественные.
Кстати, примечательно, что тема ИИ для игры в StarCraft, о котором речь шла ещё когда там Alpha Go была на пике популярности, как-то постепенно была замылена. Может быть киберспортивные лоббисты вежливо попросили разработчиков ИИ не лезть своими грязными руками в эту важнейшую область народного хозяйства?
Какие-то частные мысли по "ИИ, пишущий программы" уже изложил в предыдущем посте, радикально нового добавить и нечего. Из текущих новостей, StackOverflow (сайт вопросов и ответов на тему программирования и смежные) запретил вон публиковать ответы на вопросы, сгенерированные нейросеткой.
Далее в нескольких постах ещё на эту тему напишу несколько ремарок общего характера. Может быть и постоянной темой сделаем.
В довесок. "Впечатляющей пример" "решения задач уровня колледжа" с эпитетами вроде "челюсть отвисла" (буквальная цитата) – решение ChatGPT на 95% "теста по микробиологии". Всяк может убедиться, что для решения теста на 100% требуется посмотреть несколько серий "Доктора Хауса" и доступ к первой странице поисковой выдачи Гугла по соответствующим запросам. Интересно, по поводу рассыпавшихся по полу челюстей это они прикалываются так или всерьёз?
#programming #neuronetworks
Ранее уже писал на эту тему, но новости продолжают поступать: гугловскую нейросеть научили решать олимпиадные задачки по программированию.
Одновременно ChatGPT демонстрирует решение широкого круга диалоговых задач. Прогресс заметный. Проблема сохранения контекста, о которой немного писал ранее, решена. Представить себе общение с современными нейросетями можно примерно как общение с Гуглом или Википедией, который при этом накапливает опыт диалога, позволяет уточнять и редактировать запрос (и ответ) ссылаясь на ходу на предыдущие реплики и имеет базовый модуль "написания коротких эссе на заданную тему". О тесте Тьюринга говорить больше не серьёзно, все шероховатости, понятно, будут в самое ближайшее время дошлифованы.
Разработчики "программистской" нейросети сразу же остроумно сами себя критикуют: мол, электричества она ест как небольшой завод, код зачастую реализует неоптимальное решение, места в конкурсах занимает не первые. Короче, люди ещё могут на что-то надеяться, но недолго.
Ну, то есть, перечисляют "количественные" недоработки, но не качественные.
Кстати, примечательно, что тема ИИ для игры в StarCraft, о котором речь шла ещё когда там Alpha Go была на пике популярности, как-то постепенно была замылена. Может быть киберспортивные лоббисты вежливо попросили разработчиков ИИ не лезть своими грязными руками в эту важнейшую область народного хозяйства?
Какие-то частные мысли по "ИИ, пишущий программы" уже изложил в предыдущем посте, радикально нового добавить и нечего. Из текущих новостей, StackOverflow (сайт вопросов и ответов на тему программирования и смежные) запретил вон публиковать ответы на вопросы, сгенерированные нейросеткой.
Далее в нескольких постах ещё на эту тему напишу несколько ремарок общего характера. Может быть и постоянной темой сделаем.
В довесок. "Впечатляющей пример" "решения задач уровня колледжа" с эпитетами вроде "челюсть отвисла" (буквальная цитата) – решение ChatGPT на 95% "теста по микробиологии". Всяк может убедиться, что для решения теста на 100% требуется посмотреть несколько серий "Доктора Хауса" и доступ к первой странице поисковой выдачи Гугла по соответствующим запросам. Интересно, по поводу рассыпавшихся по полу челюстей это они прикалываются так или всерьёз?
#programming #neuronetworks
Настоящий peer-to-peer
После отмены web2.0 – т.е. эпохи универсальных протоколов, свободных форматов данных, разнообразия клиентов – наступил некоторый откат технологий. Короткий миг, когда можно было использовать, к примеру, Pidgin, разработанный open-source сообществом jabber-клиент, для того чтобы через серверы VK послать сообщения в Google Talk, канул в небытие.
Единственным надёжным средством платформо-независимого обмена сообщениями осталась электронная почта: на десятилетия казалось бы устаревший протокол, который тем не менее спокойно пережил все восхождения и низвержения парадигм. В определённом смысле эталон свободных технологий: полноцененый peer-to-peer, при котором даже частное лицо может развернуть свой сервер (с рядом проблем, но типовых и вполне решаемых) и тем самым де-факто войти в международный электронно-почтовый союз. Без заполнения единого бланка и не подписывая никаких контрактов.
Главной проблемой (с появлением дешёвой и открытой асимметричной криптографии, решившей раз и, видимо, навсегда, проблему тайны переписки и передачи ключей шифрования) в подобных системах является discovery, проблема адресации. Как отделить идентификатор пользователя от маршрута, по которому информацию к нему можно доставить?
В общем-то весь многоуровневый стек протоколов того, что мы называем интернетом, и работает для решения этой проблемы. На вершине пирамиды DNS – сервис доменных имён – вишенка на торте. Которая позволяет какой-нибудь
Вся система выглядит при взгляде сверху децентрализовано, но на земле всё упирается в конкретные подземные и подводные кабели оптоволокна. Эти кабели и есть последний бастион государственного контроля информационных потоков. Дешифровать идущую по ним информацию они уже не могут, но вот перерубить (или ограничить) – вполне.
В самом деле, сколько у нас криптовалютных токенов, которые вознаграждают участников сети за некие ресурсы (которые тратятся на пользу какому-то делу или перерабатываются в решения синтетических задач, т.е. так сказать напрямую в "понты")? Вознаграждают и за процессорную мощь, и за оперативную память, и за жёсткий диск, и даже за пропускную способность канала в интернет. Вот последнее наименее популярно и проработанно.
Понятно, что настоящий анархический интернет это не очередной клон джаббера с деривируемыми криптоключами и доменами в блокчейне. Это программа (скорее, прошивка) на мобильном телефоне, которая при попадании в радиус ближней связи с другим таким устройством обменивается небольшим количеством накопившихся сообщений. Маршрутизация опирается банально на географические координаты, типовые паттерны передвижения пользователя (настраиваемо) и его планы глобальных перелётов (под ручным контролем). За чужие доставленные сообщения пользователь получает крипто-токен, ну дальше понятно, рейтинг раздачи торрентов все понимают что такое (больше раздаёшь, меньше скачиваешь = зарабатываешь; иначе тратишь; обмен криптотокенов на любые материальные ресурсы через готовую инфраструктуру бирж, обменников и т.д.).
Выключить такое, однажды запустив, можно только физически уничтожив пользователей.
Все составные элементы технологии созданы, отработаны и годами успешно функционируют (самое "близкое к земле" звено относительно недавно – AirTag). А прошивки почему-то нет такой замечательной. Интересно, почему? Да потому же, почему нет промышленного производства военных квадрокоптеров, автопилотируемых грузовиков, и всех подобных вещей – страшно-с.
#programming
После отмены web2.0 – т.е. эпохи универсальных протоколов, свободных форматов данных, разнообразия клиентов – наступил некоторый откат технологий. Короткий миг, когда можно было использовать, к примеру, Pidgin, разработанный open-source сообществом jabber-клиент, для того чтобы через серверы VK послать сообщения в Google Talk, канул в небытие.
Единственным надёжным средством платформо-независимого обмена сообщениями осталась электронная почта: на десятилетия казалось бы устаревший протокол, который тем не менее спокойно пережил все восхождения и низвержения парадигм. В определённом смысле эталон свободных технологий: полноцененый peer-to-peer, при котором даже частное лицо может развернуть свой сервер (с рядом проблем, но типовых и вполне решаемых) и тем самым де-факто войти в международный электронно-почтовый союз. Без заполнения единого бланка и не подписывая никаких контрактов.
Главной проблемой (с появлением дешёвой и открытой асимметричной криптографии, решившей раз и, видимо, навсегда, проблему тайны переписки и передачи ключей шифрования) в подобных системах является discovery, проблема адресации. Как отделить идентификатор пользователя от маршрута, по которому информацию к нему можно доставить?
В общем-то весь многоуровневый стек протоколов того, что мы называем интернетом, и работает для решения этой проблемы. На вершине пирамиды DNS – сервис доменных имён – вишенка на торте. Которая позволяет какой-нибудь
google.com (DNS-имя) перевести в 142.250.181.110 (IP-адрес). А зная IP-адрес уже понятно как до него доставить пакет информации: на самом грубом уровне рассмотрения это работает также, как доставка бумажной почты, где каждый пункт приёма корреспонденции знает, до каких вышестоящих у него есть связь, а все корневые узлы знают как через минимальное число посредников переслать почту другому корневому узлу. Работает география планеты с наложенной не неё картой линий сообщений.Вся система выглядит при взгляде сверху децентрализовано, но на земле всё упирается в конкретные подземные и подводные кабели оптоволокна. Эти кабели и есть последний бастион государственного контроля информационных потоков. Дешифровать идущую по ним информацию они уже не могут, но вот перерубить (или ограничить) – вполне.
В самом деле, сколько у нас криптовалютных токенов, которые вознаграждают участников сети за некие ресурсы (которые тратятся на пользу какому-то делу или перерабатываются в решения синтетических задач, т.е. так сказать напрямую в "понты")? Вознаграждают и за процессорную мощь, и за оперативную память, и за жёсткий диск, и даже за пропускную способность канала в интернет. Вот последнее наименее популярно и проработанно.
Понятно, что настоящий анархический интернет это не очередной клон джаббера с деривируемыми криптоключами и доменами в блокчейне. Это программа (скорее, прошивка) на мобильном телефоне, которая при попадании в радиус ближней связи с другим таким устройством обменивается небольшим количеством накопившихся сообщений. Маршрутизация опирается банально на географические координаты, типовые паттерны передвижения пользователя (настраиваемо) и его планы глобальных перелётов (под ручным контролем). За чужие доставленные сообщения пользователь получает крипто-токен, ну дальше понятно, рейтинг раздачи торрентов все понимают что такое (больше раздаёшь, меньше скачиваешь = зарабатываешь; иначе тратишь; обмен криптотокенов на любые материальные ресурсы через готовую инфраструктуру бирж, обменников и т.д.).
Выключить такое, однажды запустив, можно только физически уничтожив пользователей.
Все составные элементы технологии созданы, отработаны и годами успешно функционируют (самое "близкое к земле" звено относительно недавно – AirTag). А прошивки почему-то нет такой замечательной. Интересно, почему? Да потому же, почему нет промышленного производства военных квадрокоптеров, автопилотируемых грузовиков, и всех подобных вещей – страшно-с.
#programming
Суть программирования
В книге Getting Real создатели Ruby on Rails описывают секрет успеха своей компании: "нанимайте хороших писателей!" (имеется в виду на должность программистов).
Научные исследования показывают, что способности к языкам более важны для программистов, чем способности к математике.
Настало время сделать финальное обобщение и прямо так сказать: программирование это способность создавать языки.
В самом благородном и парадном виде это, конечно, создание именно языков программирования. Но вообще говоря новые языки повсюду. Будь это Kubernetes со своим языком "описания того как на множестве серверов развёрнуты приложения" или ActiveRecord с языком "объявления критериев верности данных". И так далее.
Далее можно провести различие senior programmer от middle и junior. Обычно этой темы либо избегают (и это не худший вариант), либо приводят формальные критерии (количество лет опыта, перечень изученных технологий и т.п.). Понятно, что, во-первых, отличие есть. И, во-вторых, оно отнюдь не формальное, а вполне себе существенное. Но чтобы получить возможность хоть немного продвинуться в рассуждении надо зайти на формализацию этих понятий с другой стороны. Курсант военного училища это почти офицер, а прапорщик с 20 годами опыта службы никогда им не станет.
Кто-то из программистов после 5 месяцев обучения является "делающим первые шаги senior-ом". А кто-то после десяти лет опыта будет де-факто "опытным middle". Как между ними будет распределяться зарплата и прочие такие вопросы к делу отношения не имеют. Есть некое объективное различие.
Это объективное различие как раз будет связано со способностью создавать (и развивать) языки. Способный программист очень быстро ухватывает, хоть может быть и не вполне осознаёт, что дело именно в этом, после чего у него волшебным образом с каждым разом всё лучше и лучше начинает всё получаться:
– здесь он оформил адреса для страниц приложения правильно (потому что система адресов это крошечный искусственный язык, для которого надо выбрать красивую грамматику);
– здесь он не поленился дописать документацию (потому что документация это свой жанр текстов и в этом смысле тоже свой язык);
– здесь он провёл рефакторинг (отношения модулей, частей кода, друг с другом – тоже сорт "грамматики");
– здесь он выделил общую функциональность в отдельный пакет со своим DSL (это уже разработка своего языка без всяких кавычек и оговорок).
Пользуясь случаем, напоминаю, что у меня есть небольшой цикл лекций, посвящённый элементарным основам создания языков программировния :)
#programming
В книге Getting Real создатели Ruby on Rails описывают секрет успеха своей компании: "нанимайте хороших писателей!" (имеется в виду на должность программистов).
Научные исследования показывают, что способности к языкам более важны для программистов, чем способности к математике.
Настало время сделать финальное обобщение и прямо так сказать: программирование это способность создавать языки.
В самом благородном и парадном виде это, конечно, создание именно языков программирования. Но вообще говоря новые языки повсюду. Будь это Kubernetes со своим языком "описания того как на множестве серверов развёрнуты приложения" или ActiveRecord с языком "объявления критериев верности данных". И так далее.
Далее можно провести различие senior programmer от middle и junior. Обычно этой темы либо избегают (и это не худший вариант), либо приводят формальные критерии (количество лет опыта, перечень изученных технологий и т.п.). Понятно, что, во-первых, отличие есть. И, во-вторых, оно отнюдь не формальное, а вполне себе существенное. Но чтобы получить возможность хоть немного продвинуться в рассуждении надо зайти на формализацию этих понятий с другой стороны. Курсант военного училища это почти офицер, а прапорщик с 20 годами опыта службы никогда им не станет.
Кто-то из программистов после 5 месяцев обучения является "делающим первые шаги senior-ом". А кто-то после десяти лет опыта будет де-факто "опытным middle". Как между ними будет распределяться зарплата и прочие такие вопросы к делу отношения не имеют. Есть некое объективное различие.
Это объективное различие как раз будет связано со способностью создавать (и развивать) языки. Способный программист очень быстро ухватывает, хоть может быть и не вполне осознаёт, что дело именно в этом, после чего у него волшебным образом с каждым разом всё лучше и лучше начинает всё получаться:
– здесь он оформил адреса для страниц приложения правильно (потому что система адресов это крошечный искусственный язык, для которого надо выбрать красивую грамматику);
– здесь он не поленился дописать документацию (потому что документация это свой жанр текстов и в этом смысле тоже свой язык);
– здесь он провёл рефакторинг (отношения модулей, частей кода, друг с другом – тоже сорт "грамматики");
– здесь он выделил общую функциональность в отдельный пакет со своим DSL (это уже разработка своего языка без всяких кавычек и оговорок).
Пользуясь случаем, напоминаю, что у меня есть небольшой цикл лекций, посвящённый элементарным основам создания языков программировния :)
#programming