Современный термин «компьютер» происходит от латинского слова computus, обозначающего сложный процесс перевода древнееврейского лунного календаря в лунно-солнечный церковный христианский для расчета даты Пасхи.

Так что не возмущайтесь, что у вас календари сложно считаются, и часовые пояса все усложняют — это by design

Эрика Рэймонда, одного из основателей движения открытого программного обеспечения, удалили из списков рассылки, где он пытался бороться с «бюрократией», идущей вразрез с идеями открытого ПО. По его мнению уровень бюрократизации организации достиг уровня, соответствующего «третьему закону политики», предложенному писателем Робертом Конквестом: «Поведение любой бюрократической организации лучше всего понять, предположив, что она контролируется тайным заговором своих врагов».

Ни Рэймонд, ни писатель не осознают того, что бюрократизация — это цементирование идей организации, а вовсе не их саботаж. И врагов никаких нет. Есть декларируемые идеи организации и реальные. И вот они в общем случае совершенно разные. В отдельных частных случаях, конечно, могут пересекаться на некотором подмножестве, но в целом, декларируемые идеи служат для внешнего применения (связи с общественностью, привлечение людей), а реальные идеи — для выполнения обязательств организации перед её бенефициарами.

Отстранение основных идеологов свободного ПО от руля (до этого отодвинули Линуса Торвальдса и Ричарда Столлмана) означает лишь одно: алхимия выкристаллизовалась в химию и физику. Эзотерические околорелигиозные развлечения энтузиастов стали наукой, а в науке меритократам и подходу «покажи мне код» не место. Управление организациями и постановка задач науке лежат совсем не в сфере технологий, а в сфере гуманитарных направлений, поэтому управлять всем будут серые безликие «бюрократы», возможно через прослойку активистов за какие-нибудь права. Основатели движений, кто поумнее, получили золотые парашюты, ушли в околотехнологические венчурные инвестиции, а те, кто вместо образования занимался отупляющим кодированием и меритократией, не заметил за деревьями леса и стал кричать, что в ставку пробрались враги, которые вот-вот разрушат всё то, что создавалось непосильным трудом сотнями тысяч энтузиастов почти забесплатно. Программисты придумали писать код, а выгоду от кода получают непонятные облачные компании, которые никак не помогают свободному программному обеспечению.

Хотя, как это не помогают? А как же ощущение от того, что ты кому-то нужен, что ты делаешь дело полезное для общества, мира и человечества в целом? Это тоже многого стоит ;)

https://www.opennet.ru/opennews/art.shtml?num=52468

> Two virtual machines are more than enough to a startup for the first 2 to 4 years.
©

Пишу крохотный очерк о том, как я стал дисциплинированнее задарма.

Для эффективного рабочего процесса оказалось очень важно две вещи:
- планировать регулярно и честно, не кривляясь, держать перед собой отчёт по несделанному
- придерживаться плана.

Если проблема управлять собой не такая сложная (лично для меня; your mileage may vary), то что делать с взаимодействиями, непонятно. Всякие zero inbox и другое сектантство проходят быстро, оставляют лёгкое послевкусие стыда за свою конченную неизбывную безалаберность.

Я для себя смог решить вопрос с почтой вот как.

Первое: завел папки в почте (помимо входящей)
1. На эту неделю
2. На потом
3. Мониторить

Второе: проверяю рабочую почту дважды в день, утром и вечером, по простому алгоритму, который будет ниже.

Алгоритм несложный.

1.Разобрать папку "входящие". Если не требует ответа от нас, отправляем в архив (для поисков потом) или удаляем.

2. Если ответ требует меньше пяти минут, пишем его, отправляем. Тут будет нюанс @@, к которому вернёмся позже.

3. Если ответ требует подготовки, переносим его в папку "На эту неделю" или на "Потом".

4. В течение дня разбираем папку "Эта неделя" - это и есть наш коммуникационный план, отвечаем на письма, готовим работы и т.п. Если понимаем, что срочность пропала - переносим в "Потом". Если папка опустела -- просматриваем папку "Потом", переносим из нее по очереди в "Эта неделя", работаем как раньше описал.

5. Все, что мы отправляем, может требовать реакции от других или нет. Вот и нюанс @@: если не ждем реакции - отправленное письмо кидаем в архив, если ждем - кидаем его в папку "Мониторить".

6. Периодически (я раз в день, обычно вечером) просматриваем папку "Мониторить", покусываем тех, кто не отвечает нам. Таким образом ни одно поручение не остаётся забытым.

Остаеnся научиться более-менее крупные задачи вести не устно и в чатах, а в тикетах и документах, и почтой их подтверждать -- ну и все, вы великолепны.

Аутлук ещё и предложил частые действия (ответить и перенести) вынести на панель и повесить на хоткей, очень удобно.

Итого, три папки и 20-30 минут времени в день дают возможность стать почти 100% надёжным контрагентом, и не забывать задачи.

P.S. Все эти приемы -- копия практик бюрократов-делопроизводителей начала-середины XX века, никакой революции

В РФ крупная лавка (типа Ашана) покупает программиста у крупного аутсорсера (типа Епама), по ставке начиная с 5-8 тыс. руб./час и выше — потолок в каждом случае свой. Абстрактного среднего Васю, который 1+1=11, 40-60 тыс.рублей за каждый день его "работы".

Что Вася собирался сделать за сегодня за этот день?  Зарефакторить пару методов? Сделать так, чтобы в заголовке письма  шаблон проставлялся, да вынести его в настроечки, и пойти домой? Отлично поработал, оклад 25-го, несите системного аналитика, дальше не знаю, что делать, пока не напишут?

Вы бы себя такого за эти деньги у себя самого не купили, уверяю.

Ответы на накопившиеся вопросики по вчерашнему посту:

Q1. А чо так дорого??
А1. Этот бизнес так устроен. Во-первых, заказчик может платить с отсрочкой и год, и больше. Вендор, по сути, этим кредитует заказчика, причем по интересной ставке, близкой к нулю. Во-вторых, вендор берет на себя даже судебные риски: в случае, если заказчик проэтосамовался по запуску чего-то в срок, то виноватым назначат условный Accenture, который (мразь такая), не сдал ИТ-систему вовремя, вплоть до штрафов, отставок, рукоположения ряда заранее назначенных жертв "в ИТ-кловуны" (с хорошим парашютом, конечно же, на пару лет залечь на дно в Темзе в клетчатом бауле и не отсвечивать).

Q2. Значит, надо делать аутсорс?
A2. Мелкие вендоры, разумеется, доедают последнюю горбушку без соли. Ко мне в друзья в соцсетях добавляются каждую неделю поцы, которые хотят что-нибудь попродавать из разработки, по цене примерно себестоимости. Плюс у маленькой компании только один —  она может стать большой компанией, больше плюсов нет. Аутсорсом лучше заниматься в составе 300+ человек, а не 30.

Q3. А вендору не жалко так платить, почему бы не открыть свой инхаус?
A3. Средний уровень разработчика одинаков везде, хоть у вендора, хоть в инхаусе. Но свой инхаус невозможно увеличить быстро в 2 раза, а потом так же сдуть. Плюс, надо понимать, что в любом более-менее сложном проекте вендору аутсорсится тот самый менеджер среднего звена в первую очередь. Который из конторы словно прапорщик тащит даже туалетную бумагу, который не работает при любом удобном случае, через которого управлять все равно что пытаться вареную макаронину в бутылку засунуть, держа за дальний конец.

По вопросу ТЗ и того, что программисту обычно прикладную задачу не показывают, а если б показали - он бы все правильно сделал с самого начала.

Так вот, чаще всего реальную прикладную задачу от программиста нахально и подло прячут прямо в ТЗ.

ТЗ это самое лучшее место, куда от программиста задачу спрятать можно -- там очень хорошо задача прячется, редко кто из программистов в нем вообще искать пробует.

Кажется, IT-индустрия стабилизировалась и согласилась на определении, что DevOps это такой сисадмин, который хорошо выучил средства автоматизации (вариант: умеет в докер и скрипты CI). Об этом даже доклады на конференциях заявляют.

Теперь основной результат работы DevOps в 80% это  п а й п л а й н ы. Раньше разработчики и админы ругались про то, что софт нельзя собрать по инструкции, теперь — что билд в пайпланы не запихнешь.

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

Опыт найма и последующей работы с людьми показывает, что большинство из тех, кто называет себя инженерами ПО (software engineer), по факту — максимум слесари-фрезеровщики ПО (software machinist, machine-minder, technician).

Это не хорошо и не плохо, просто надо учитывать.

Сразу несколько больших российских частных компаний из финтеха и не только ведут сейчас работу над реализацией собственных глобальных систем Электронный Паспорт (ID). Все они делаются по той же технологии, что и ЕСИА - TLS и Open ID Connect на неправославном забугорном AES.

И у всех у них решение стоит под большим вопросом, потому что ФСБ и инфобезу не нравятся ни алгоритмы шифрования, ни сам принцип OIDC.

Если про алгоритмы примерно понятно (шифровать можно по разным алгоритмам), то что делать с OIDC, пока не стало понятно никому.

Подробности появятся немного позже.

Господа, есть заказ на рзработку SDK для бэка банка и для мобильных приложений финтехов.
Нужен подрядчик, который работал с российской ГОСТ-криптографией. Вариант “я работал с криптой вообще, смогу научиться с ГОСТом” не подходит, так и я могу — с такой позицией я отбор не пройду, он требует подтвержденного опыта.

Если интересно, пишите в личные сообщения.

Возникает вопрос, а что важнее всего для заказчика в разработке?

Это очень простой вопрос, и ответ очень простой. Заказчику от разработки -- неважно, внутреннему или внешнему -- важна СКОРОСТЬ. Можно усилить: по сути, больше ничего не нужно. Да даже сама разработка  (продуктовую, имею в виду) и ее приемы -- она исключительно про скорость.

Новые языки и технологии, сборка мусора? Это чтобы писать было проще, чтобы нанять побольше менее искушеннных людей и делать быстрее.

Микросервисы? Чтобы можно было взять те команды, которые есть в наличии, и писать на том, на чом умеют; сладкие сказки про масштабирование и прочий шрот уже сверху придумали, потому что по-честному такую сложную и ненадежную машинерию ни один инженер не взвалил бы на себя (вспомните soa: а теперь там на порядки больше единиц развертывания). Лучше всего микросервисы масштабируются только по одному измерению: количеству людей в разработке.

Хорошая архитектура и прочий кодинг-стайл сегодня? Это чтобы завтра можно было писать быстро и не сбавляя скорость.

Автотесты? Чтобы отлавливать ошибки ещё на этапе, когда не потребуется возвращать продукт в доработку, потому что это долго и снижает скорость.

Специализация в разработке? Ну вы поняли.

Хорошая разработка это скорость, и ничего более.  Скорость сегодня, скорость завтра, скорость когда ее ждут. Все остальное -- только топливо для этой скорости.

От всеобщего перехода на удаленную работу, наш бэкофис стал работать гораздо быстрее и надежнее. Например, счета и акты на оплату ранее могли проходить неделями; теперь это может быть сделано за пару часов.

Раньше всегда находилась причина, почему надо вернуть или прийти ногами пообщаться; теперь все общение удаленно, каждая фаза согласования стала видна всем, все стороны стремятся максимально сократить и конкретизировать взаимодействия, и естественным образом процесс выровнялся и "пошел".

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

Вопрос вовсе не в том, заслужили мы этот отдых или нет; и не в том, что планируют закрыться все заведения, парки и общественные пространства. Впереди не самое простое лето для многих.

Это личное дело каждого, и одно общее на всех. Давайте быть сильнее обстоятельств.

Хороший булшит-детектор -- наличие слова "четкий" в тексте. Четкая постановка задачи, четкий список обязанностей, четкий план работ -- эти описания сами по себе не проходят критерий, соблюдения которого требуют от других описаний

По прошествии около 10 лет, могу ответственно сказать, что переезд в столицу в долгосрочной перспективе был …ошибкой. Да, именно так. Если бы 10-12 лет назад я понимал то, что понимаю сейчас, то поступил по-другому.

Во-первых, продолжил бы работать в том же окружении и на того же заказчика (зарубежный институт исследований окружающей среды). Это был бы дауншифтинг в каком-то смысле, но только на 5 лет. 5 лет без буста в доходе скомпенсировались бы низкой стоимостью жилья и недвижимости. За эти 5 лет следовало в первую очередь установить тесные отношения с Западом и сколотить свою команду.

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

В-третьих, эта стратегия позволила бы здорово прокачать навык самостоятельно вырабатывать деньги из рынка, а не нацеливаться на продажу своих скиллов. Быть узким профессионалом — не мое, иначе я бы пошел в научные исследования.

—

Мой бывший коллега оттуда, который прошел через всё это, прошлой осенью продал свою компанию за $15М, и теперь дегустирует в FB вина и ходит на яхте 4 раза в год. Он звал меня присоединиться несколько лет назад, но было уже поздно откручивать назад по личным причинам (это в-четвертых).

Люди учатся на ошибках, умные — на ошибках других. Ваш покорный слуга еще не очень умный.

(Точные имена и названия не пишу, это не так важно).

Относительно карантина очень уместной кажется следующая цитата

Вспоминаю, что в середине двухтысячных довелось столкнуться с поистине индустриальным подходом к разработке. А конкретно, с серьезным разделением труда. Вот как это было устроено.

Проектом являлось огромное мультикомпонентное и мультисистемное десктопное приложение, над которым работали несколько сотен программистов. Разработка велась на с++, при этом была использована его особенность разделения на заголовочный файл и файл реализации.

Архитекторы и лидеры подсистем проектировали классы и компоненты, зачастую визуально на UML и достаточно подробно, вплоть до всех полей, методов, и спецификаторов доступа.

Из этих диаграмм генерировались заголовочные файлы, которые описывали классы: данные и протоколы. После генерации заголовочные файлы сотнями и тысячами поступали к разработчикам, где code monkey писали имплементации и компонентные и сценарные тесты.

Написанные компоненты и подсистемы попадали в команду интеграции (буквально 10-20 человек), которые собирали их в приложение, приложение проходило сценарные тесты, зафиксированные ошибки потом сортировались и возвращались либо в команду интеграции, либо к имплементорам.

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

К чему это я? Да вот увидел рекламу курсов "стань экспертом-разработчиком за полгода", и внезапно понял, где эти эксперты могли бы идеально вписаться.

“… а если кому-то удается на нейросетях сделать что-то хорошо работающее, то его сразу все поздравляют, потому что это правда успех” (С)