The post has been translated automatically. Original language: Russian
In the early 2000s, I read a lot of Joel on Software, Joel Spolsky's articles on programming, developer management, and the software business. Today, he is known as one of the creators of Stack Overflow, but back then, for us, he was primarily a Microsoft person who talked about how work really works inside a large technology company.
For us, ordinary programmers, it was almost a window into another world. We didn't see inside Microsoft, we didn't know how decisions were made there and how much the position affected technical disputes. And Joel wrote about it quite directly.
One of his articles, Two Stories, published in 2000, influenced me especially strongly.
A young developer versus a very big boss
At Microsoft, Joel worked on Excel and was responsible for the direction from which VBA later grew. At some point, his work began to be criticized by the internal Application Architecture group.
This group was led by Greg Whitten, one of the earliest Microsoft employees. That is, in terms of internal weight, he was a man of a completely different level than the young manager responsible for one part of Excel.
But Joel believed that the group was preventing his team from making the product. He argued, defended his decision, and disagreed only because he was facing a man with a much higher status.
The story ended unexpectedly. When the head of the Office found out that this group was interfering with the work of the Excel team, the group was disbanded, and its employees were distributed to other departments.
For me, it wasn't the story of the dismissal or reorganization itself that was important here.
Something else was important: in a good engineering culture, the right to make a decision should depend not only on the position, but on who is really responsible for the result and understands the subject.
I'm the boss, you're a fool
Things often worked differently for us back then.
If a person is higher in position, then his opinion automatically weighs more. Even if he understands the technical side of the issue less well.
The scheme is simple:
I'm the boss, you're a fool.
Of course, in real life, no one usually says that out loud. But the logic itself is constantly encountered.
The boss decided that the programmer was doing it.
The boss came up with the architecture — implement it.
The boss wants a new feature by Friday, which means it should be available by Friday.
And if a developer says that the solution is bad, too risky, or just doesn't work, it's sometimes perceived not as a technical opinion, but almost as insubordination.
When I read Joel's story, it contrasted very strongly with this.
I haven't fired anyone.
I had bosses too.
There were decisions that I didn't agree with. There were situations when a person's position meant much more than technical arguments.
But there has never been a beautiful story in my life in which a senior manager comes in, understands the situation, and the next day disbands the structure that prevents programmers from working.
No one was fired.
But after Joel's article, I came to a different conclusion.
I decided that I wanted to work only for myself.
Not because any boss is bad. And not because the programmer is always right.
I just realized that I don't want to build my professional life in a system where a person can have the last word just because they are higher up in the organizational chart.
I wanted to be responsible for the decisions myself—and responsible for the consequences myself.
Freedom also means responsibility.
There is a downside to this idea that is easy to forget.
When you work for yourself, it's impossible to tell.:
"I was ordered."
Or:
"That's what the boss decided."
If the architecture is bad, it's your architecture.
If the project doesn't work, it's your project.
If the client is unhappy, you can talk to them too.
This is much less convenient than it looks from the outside.
Freedom to make decisions automatically means responsibility for their outcome.
And in that sense, I think I got Joel's point right. His story wasn't that programmers should ignore the manual. She was saying that the person who was entrusted with a part of the product should be given real responsibility for it.
And responsibility without the ability to make decisions is a rather strange construct.
The boss may also be right.
As you get older, you start to look at this topic a little more calmly.
A programmer does not automatically become right just because he is a programmer.
A developer can understand the code remarkably well and at the same time have a poor understanding of the client, money, deadlines, or consequences for other departments.
The supervisor can see things that the developer simply does not know.
Therefore, it is not a question of always giving the last word to the programmer.
The question is different: What argument is used to make a decision?
If the argument sounds like "I'm the boss," it's a bad engineering argument.
If the manager explains the limitations of the business, deadlines, risks, or customer requirements, this is already the subject of a normal conversation.
And a good developer must take this aspect into account too.
And then I became the boss myself.
There is another irony here.
When you decide to work for yourself, after a while you become the person who can come to the developer and say:
"Let's do it like this."
And then Joel's story starts working against you.
It is very easy to assume that bosses only interfere in the work of large corporations. But as soon as you have your own company or team, exactly the same temptation arises.: You're the owner, so you probably know best how to make a product.
Not really.
If a person understands a particular part of the system better than you do, you need to be able to recognize it.
Otherwise, you can build your own company with exactly the culture that you once wanted to leave.
What has AI changed?
In 2026, this topic has received another dimension.
Now a new participant has appeared in the technical dispute.:
The AI said that it should be done this way.
This is a very dangerous variation of the old authority argument.
It used to be:
"That's what the boss said."
Now maybe:
"That's what ChatGPT wrote."
But AI is also not responsible for the outcome.
He can suggest an architecture, write code, choose a library, or convincingly explain why the decision seems right. But the responsibility still remains with the person who makes the decision.
Therefore, with the advent of AI, engineering culture becomes even more important.
The argument must be validated regardless of where it came from: from a programmer, a supervisor, or a language model.
Perhaps that's what Joel wrote about.
More than a quarter of a century has passed, and I still remember this story.
It's not because Microsoft once disbanded some internal group.
But because she made me think about a much more personal issue then.: Who should make decisions about my work?
My answer turned out to be quite radical.
I decided to work for myself.
Of course, it didn't save me from mistakes, conflicts, or bad decisions. It's just that they're mine now.
And, perhaps, it's more honest.
For me, the main lesson of that article by Joel today sounds like this: The right to make a decision must go hand in hand with responsibility for its consequences.
It doesn't matter who's in front of you— a programmer, a boss, a company owner, or an AI.
The phrase "I'm taller, so I'm right" doesn't work well in development.
And if you want to always have the last word, there is one fairly simple way.
Work for yourself.
В начале 2000-х я много читал Joel on Software — статьи Джоэла Спольски о программировании, управлении разработчиками и софтверном бизнесе. Сегодня его знают как одного из создателей Stack Overflow, но тогда для нас он был прежде всего человеком из Microsoft, который рассказывал, как на самом деле устроена работа внутри большой технологической компании.
Для нас, обычных программистов, это было почти окном в другой мир. Мы не видели изнутри Microsoft, не знали, как там принимаются решения и насколько сильно должность влияет на технические споры. А Джоэл писал об этом довольно прямо.
Одна из его статей — Two Stories, опубликованная в 2000 году, — повлияла на меня особенно сильно.
Молодой разработчик против очень большого начальника
В Microsoft Джоэл работал над Excel и отвечал за направление, из которого позже вырос VBA. В какой-то момент его работу начала критиковать внутренняя группа Application Architecture.
Этой группой руководил Грег Уиттен — один из самых ранних сотрудников Microsoft. То есть по внутреннему весу это был человек совсем другого уровня, чем молодой менеджер, отвечающий за одну часть Excel.
Но Джоэл считал, что группа мешает его команде делать продукт. Он спорил, отстаивал своё решение и не соглашался только потому, что перед ним человек с гораздо большим статусом.
История закончилась неожиданно. Когда руководитель Office узнал, что эта группа мешает работе Excel-команды, группу расформировали, а её сотрудников распределили по другим подразделениям.
Для меня важна здесь была не сама история увольнения или реорганизации.
Важно было другое: в хорошей инженерной культуре право принимать решение должно зависеть не только от должности, а от того, кто реально отвечает за результат и понимает предмет.
Я начальник — ты дурак
У нас тогда всё часто работало иначе.
Если человек выше по должности, значит, его мнение автоматически весит больше. Даже если он хуже понимает техническую сторону вопроса.
Схема простая:
я начальник — ты дурак.
Конечно, в реальной жизни никто обычно так вслух не говорит. Но сама логика встречается постоянно.
Начальник решил — программист делает.
Начальник придумал архитектуру — реализуй.
Начальник хочет новую функцию к пятнице — значит, она должна появиться к пятнице.
А если разработчик говорит, что решение плохое, слишком рискованное или просто не работает, это иногда воспринимается не как техническое мнение, а почти как нарушение субординации.
Когда я прочитал историю Джоэла, она очень сильно с этим контрастировала.
У меня никого не уволили
У меня тоже были начальники.
Были решения, с которыми я не соглашался. Были ситуации, когда должность человека означала гораздо больше, чем технические аргументы.
Но в моей жизни не происходило красивой истории, в которой приходит высший руководитель, разбирается в ситуации и на следующий день расформировывает структуру, мешающую программистам работать.
Никого не уволили.
Зато после статьи Джоэла я сделал другой вывод.
Я решил, что хочу работать только на себя.
Не потому, что любой начальник плохой. И не потому, что программист всегда прав.
Просто я понял, что не хочу строить свою профессиональную жизнь в системе, где последнее слово может принадлежать человеку только потому, что он находится выше в организационной схеме.
Мне хотелось самому отвечать за решения — и самому отвечать за последствия.
Свобода означает и ответственность
У этой идеи есть обратная сторона, о которой легко забыть.
Когда ты работаешь на себя, уже невозможно сказать:
«Мне приказали».
Или:
«Так решил начальник».
Если архитектура плохая — это твоя архитектура.
Если проект не работает — это твой проект.
Если клиент недоволен — разговаривать с ним тоже тебе.
Это намного менее удобно, чем кажется со стороны.
Свобода принимать решения автоматически означает ответственность за их результат.
И в этом смысле я думаю, что правильно понял мысль Джоэла. Его история была не о том, что программисты должны игнорировать руководство. Она была о том, что человеку, которому доверили часть продукта, должны дать реальную ответственность за неё.
А ответственность без возможности принимать решения — довольно странная конструкция.
Начальник тоже может быть прав
С возрастом на эту тему начинаешь смотреть немного спокойнее.
Программист не становится автоматически правым только потому, что он программист.
Разработчик может замечательно понимать код и при этом плохо понимать клиента, деньги, сроки или последствия для других подразделений.
Руководитель может видеть вещи, которых разработчик просто не знает.
Поэтому вопрос не в том, чтобы всегда отдавать последнее слово программисту.
Вопрос в другом: каким аргументом принимается решение?
Если аргумент звучит как «я начальник», это плохой инженерный аргумент.
Если руководитель объясняет ограничения бизнеса, сроки, риски или требования клиента — это уже предмет нормального разговора.
И хороший разработчик обязан учитывать эту сторону тоже.
А потом я сам стал начальником
Здесь возникает ещё одна ирония.
Когда решаешь работать на себя, через какое-то время сам становишься тем самым человеком, который может прийти к разработчику и сказать:
«А давай сделаем вот так».
И тогда история Джоэла начинает работать уже против тебя.
Очень легко считать, что начальники вмешиваются в работу только в больших корпорациях. Но как только у тебя появляется собственная компания или команда, возникает ровно то же искушение: ты владелец, значит, наверное, лучше всех знаешь, как делать продукт.
На самом деле нет.
Если человек глубже тебя разобрался в конкретной части системы, это надо уметь признать.
Иначе можно построить собственную компанию именно с той культурой, от которой когда-то хотел уйти.
Что изменил ИИ
В 2026 году эта тема получила ещё одно измерение.
Теперь в техническом споре появился новый участник:
ИИ сказал, что надо сделать так.
Это очень опасная разновидность старого аргумента авторитета.
Раньше было:
«Так сказал начальник».
Теперь может быть:
«Так написал ChatGPT».
Но ИИ тоже не несёт ответственности за результат.
Он может предложить архитектуру, написать код, выбрать библиотеку или убедительно объяснить, почему решение кажется правильным. Но ответственность всё равно остаётся у человека, который принимает решение.
Поэтому с появлением ИИ инженерная культура становится даже важнее.
Аргумент должен проверяться независимо от того, откуда он пришёл: от программиста, руководителя или языковой модели.
Возможно, Джоэл писал именно об этом
Прошло больше четверти века, а я всё ещё помню эту историю.
Не потому, что в Microsoft когда-то расформировали какую-то внутреннюю группу.
А потому, что она заставила меня тогда задуматься о гораздо более личном вопросе: кто должен принимать решения о моей работе?
Мой ответ оказался довольно радикальным.
Я решил работать на себя.
Конечно, это не избавило меня от ошибок, конфликтов или плохих решений. Просто теперь они стали моими.
И, пожалуй, это честнее.
Для меня главный урок той статьи Джоэла сегодня звучит так: право принимать решение должно идти рядом с ответственностью за его последствия.
Неважно, кто перед тобой — программист, начальник, владелец компании или ИИ.
Фраза «я выше, поэтому я прав» в разработке работает плохо.
А если ты хочешь, чтобы последнее слово всегда было за тобой, есть один довольно простой способ.
Работать на себя.
Share
