The post has been translated automatically. Original language: Russian
The word "hacker" has long been ambiguous. For the general public, this is a person who hacks into other people's systems, steals data, or circumvents security. But in the old computer culture, the meaning was different: a hacker is a person who doesn't just use the system. He wants to understand how it works, where its boundaries are, and what can be done differently.
In this sense, hacking is not a profession or a position. It's a way of thinking.
To begin with, the question is "how does it work"
It is usually enough for an ordinary user to get the result. A hacker needs not only a result, but also an understanding of the mechanism. Why does the program work this way? What's going on inside? Which parts are really needed here? Is it possible to remove half of it? Is it possible to solve the same problem easier, or is it possible to use the system differently than its author intended?
This approach is not necessarily related only to programming. It can relate to electronics, mechanics, networks, operating systems, programming languages, and generally any complex technical system. It is interesting for a person not just to use a car, but to enter into a dialogue with it: to test the boundaries, understand the device and try to change behavior.
Do not take the system device for granted
Most technologies are surrounded by a set of unspoken rules. That's how it's done. This architecture is usually chosen. This program is designed for such a task. It is better not to touch this component.
The hacker approach begins where a person ceases to consider such limitations natural. Not because he wants to destroy everything, but because he asks a simple question: why is this so?
Sometimes it turns out that the limitation is really fundamental. But sometimes it turns out that this is just a historical accident, developer convenience, or user habit. It is in such places that unexpected solutions often appear.
A beautiful solution matters
In the early hacker culture, it wasn't just a working result that was valued. It mattered how elegant the solution was. You can write a hundred lines of code, or you can understand the problem a little deeper and solve it with ten. You can add another large component, or you may find that it is enough to connect the existing parts correctly.
A good solution often seems obvious after you see it. You look at it and think: of course, that's exactly what should have been done. But this decision still had to be thought out.
In this respect, programming is similar to mathematics. A beautiful proof is valuable not only because it is true, but also because it reveals the structure of the problem itself. Similarly, a good programming technique shows that the author really understood the system.
Not complexity, but understanding
Technical culture sometimes mistakenly associates skill with complexity. The more layers, libraries, technologies, and abstractions there are, the more serious the system looks. The hacker's gaze often moves in the opposite direction.
Difficulty in itself is not an achievement. If a task can be solved more simply, a complex solution is worse because it is more difficult to keep it in mind. A good system should be clear enough for a person to visualize how it works and explain what happens when one of the parts changes.
This is especially important in large programs. When no one understands the whole system anymore, any change becomes a risk. Therefore, the pursuit of simplicity is not a decoration or a matter of taste, but a way to maintain control.
You need to love to disassemble
Hacker thinking has another important trait — an interest in other people's work. Not in the sense of criticism, but in the sense of research. How is this done? Why did the author choose this method? What happens if you change this part? Is it possible to build such a system yourself?
Therefore, the source code has a special value. The executable program shows what the system does, and the source code shows how a person thought about it. It shows solutions, compromises, limitations, and sometimes mistakes. Reading good code is like talking to its author.
Gradually, this is changing the attitude towards their own programs. You start to look not only at whether the code works, but also at how well it explains itself.
Doing it yourself is also a way to understand
There are things that are difficult to understand just by reading. You can read a lot of books about operating systems, but after trying to write a bootloader, a file system, or at least a simple command interpreter, many ideas become much clearer.
That's why hackers are so fond of creating things that already exist. At first glance, this seems pointless: why write your own editor, server, or network tool if all this has been written for a long time? But the goal is not always to create a new product. Sometimes the goal is to gain understanding.
While a person is only using a ready-made system, he knows it from the outside. When he tries to reproduce it himself, he begins to see the internal structure.
A system is a material
For the average user, the program is a ready—made item. It can be installed, configured, and used. For a hacker, a program is more like a constructor: its parts can be studied, combined, replaced, and applied to new tasks.
That's why Unix turned out to be so close to hacker culture. He did not try to foresee all the ways to use the system in advance. Instead, it provided a set of relatively simple tools that the user could connect to each other.
The same set of programs was suitable for completely different tasks. The system did not impose the only right way, but provided the material from which to build their own solutions.
A hacker doesn't have to be a great programmer.
A hacker's way of thinking does not automatically mean a high level of skill. You can be a novice programmer and already think like a hacker. Conversely, you can work as a developer for many years, but almost never be interested in what is below the level of the tools used.
It's not about the number of well-known programming languages or the speed of writing code. The main thing is curiosity and the habit of not stopping at the answer "this is how it works."
The hacker continues to ask the following question: why?
What has changed today
Modern computers are much more complex than the machines on which this culture was formed. There can now be dozens of layers between the programmer and the processor: the operating system, the runtime environment, libraries, network services, cloud platforms, and ready-made software interfaces. Now artificial intelligence has been added to them.
This makes development faster, but at the same time creates a new danger. You can build more and more complex systems, understanding less and less how they work. This is especially noticeable now, when artificial intelligence is able to write a significant part of a program based on a brief description.
Getting a working code has become easier. It is not necessary to understand the resulting system.
That's why the old hacker mindset suddenly becomes important again. It's not enough to ask artificial intelligence how to solve a problem. We need to figure out why the proposed solution works, what limitations it has, what can be removed, which parts are really needed, and whether one component can be replaced with another.
Hacking is not destruction.
Perhaps the main historical injustice to the word "hacker" is that today it is almost automatically associated with destruction. But the original culture was largely creative: to dismantle the system, understand it, change, improve, and create something new from existing parts.
Therefore, a hacker is not necessarily the one who breaks the system. More often on the contrary: this is a person who is so interested in the system that he wants to understand it more deeply than the average user needs.
It's not enough for a hacker that the system is working. He wonders why it works the way it does.
Слово «хакер» давно стало двусмысленным. Для широкой публики это человек, который взламывает чужие системы, крадёт данные или обходит защиту. Но в старой компьютерной культуре смысл был другим: хакер — это человек, которому мало просто пользоваться системой. Ему хочется понять, как она устроена, где её границы и что можно сделать иначе.
В этом смысле хакерство — не профессия и не должность. Это способ думать.
Начать с вопроса «как это работает»
Обычному пользователю обычно достаточно получить результат. Хакеру нужен не только результат, но и понимание механизма. Почему программа работает именно так? Что происходит внутри? Какие части здесь действительно необходимы? Можно ли убрать половину? Можно ли решить ту же задачу проще или использовать систему не так, как предполагал её автор?
Такой подход не обязательно связан только с программированием. Он может относиться к электронике, механике, сетям, операционным системам, языкам программирования и вообще к любой сложной технической системе. Человеку интересно не просто пользоваться машиной, а вступить с ней в диалог: проверить границы, понять устройство и попробовать изменить поведение.
Не принимать устройство системы как данность
Большинство технологий окружено набором негласных правил. Вот так принято. Вот эту архитектуру выбирают обычно. Вот эта программа предназначена для такой задачи. Вот этот компонент лучше не трогать.
Хакерский подход начинается там, где человек перестаёт считать такие ограничения естественными. Не потому, что хочет всё разрушить, а потому, что задаёт простой вопрос: почему именно так?
Иногда оказывается, что ограничение действительно фундаментальное. Но иногда выясняется, что это всего лишь историческая случайность, удобство разработчика или привычка пользователей. Именно в таких местах часто появляются неожиданные решения.
Красивое решение имеет значение
В ранней хакерской культуре ценился не только работающий результат. Имело значение, насколько решение изящно. Можно написать сто строк кода, а можно понять задачу немного глубже и решить её десятью. Можно добавить ещё один большой компонент, а можно обнаружить, что достаточно правильно соединить уже существующие части.
Хорошее решение часто кажется очевидным уже после того, как его увидел. Смотришь и думаешь: конечно, именно так и надо было сделать. Но до этого решения ещё нужно было додуматься.
В этом программирование похоже на математику. Красивое доказательство ценно не только потому, что оно верно, но и потому, что раскрывает устройство самой задачи. Так же и хороший программный приём показывает, что автор действительно понял систему.
Не сложность, а понимание
Техническая культура иногда ошибочно связывает мастерство со сложностью. Чем больше слоёв, библиотек, технологий и абстракций, тем серьёзнее выглядит система. Хакерский взгляд часто движется в противоположную сторону.
Сложность сама по себе не является достижением. Если задачу можно решить проще, сложное решение хуже уже потому, что его труднее держать в голове. Хорошая система должна быть достаточно понятной, чтобы человек мог мысленно представить её работу и объяснить, что произойдёт при изменении одной из частей.
Это особенно важно в больших программах. Когда ни один человек уже не понимает систему целиком, любое изменение превращается в риск. Поэтому стремление к простоте — не украшение и не вопрос вкуса, а способ сохранить контроль.
Нужно любить разбирать
У хакерского мышления есть ещё одна важная черта — интерес к чужой работе. Не в смысле критики, а в смысле исследования. Как это сделано? Почему автор выбрал именно такой способ? Что произойдёт, если изменить эту часть? Можно ли собрать такую систему самому?
Поэтому исходный код имеет особую ценность. Исполняемая программа показывает, что система делает, а исходный код показывает, как человек о ней думал. В нём видны решения, компромиссы, ограничения и иногда ошибки. Чтение хорошего кода похоже на разговор с его автором.
Постепенно это меняет отношение и к собственным программам. Начинаешь смотреть не только на то, работает ли код, но и на то, насколько хорошо он объясняет сам себя.
Сделать самому — тоже способ понять
Есть вещи, которые трудно понять только чтением. Можно прочитать много книг об операционных системах, но после собственной попытки написать загрузчик, файловую систему или хотя бы простой командный интерпретатор многие идеи становятся гораздо яснее.
Именно поэтому хакеры так любят создавать вещи, которые уже существуют. На первый взгляд это кажется бессмысленным: зачем писать свой редактор, сервер или сетевой инструмент, если всё это давно написано? Но цель не всегда состоит в том, чтобы создать новый продукт. Иногда цель — получить понимание.
Пока человек только пользуется готовой системой, он знает её снаружи. Когда пытается воспроизвести её сам, начинает видеть внутреннее устройство.
Система — это материал
Для обычного пользователя программа — готовый предмет. Её можно установить, настроить и использовать. Для хакера программа скорее похожа на конструктор: её части можно изучать, соединять, заменять и применять для новых задач.
Именно поэтому Unix оказался настолько близок хакерской культуре. Он не пытался заранее предусмотреть все способы использования системы. Вместо этого он давал набор относительно простых средств, которые пользователь мог соединять между собой.
Один и тот же набор программ подходил для совершенно разных задач. Система не навязывала единственный правильный путь, а предоставляла материал, из которого можно было строить собственные решения.
Хакер не обязан быть великим программистом
Хакерский способ мышления не означает автоматически высокий уровень мастерства. Можно быть начинающим программистом и уже мыслить как хакер. И наоборот, можно много лет работать разработчиком, но почти никогда не интересоваться тем, что находится ниже уровня используемых средств.
Дело не в количестве известных языков программирования и не в скорости написания кода. Главное — любопытство и привычка не останавливаться на ответе «так работает».
Хакер продолжает задавать следующий вопрос: почему?
Что изменилось сегодня
Современные компьютеры намного сложнее тех машин, на которых сформировалась эта культура. Между программистом и процессором теперь могут находиться десятки слоёв: операционная система, среда выполнения, библиотеки, сетевые службы, облачные платформы, готовые программные интерфейсы. Теперь к ним добавился ещё и искусственный интеллект.
Это делает разработку быстрее, но одновременно создаёт новую опасность. Можно строить всё более сложные системы, всё меньше понимая, как они работают. Особенно заметно это сейчас, когда искусственный интеллект способен написать значительную часть программы по краткому описанию.
Получить работающий код стало проще. Понять получившуюся систему — не обязательно.
Именно поэтому старое хакерское мышление неожиданно становится снова важным. Недостаточно спросить искусственный интеллект, как решить задачу. Нужно разобраться, почему предложенное решение работает, какие у него ограничения, что можно убрать, какие части действительно нужны и можно ли заменить один компонент другим.
Хакерство — это не разрушение
Наверное, главная историческая несправедливость по отношению к слову «хакер» состоит в том, что сегодня оно почти автоматически связано с разрушением. Но первоначальная культура была в значительной степени созидательной: разобрать систему, понять её, изменить, улучшить и создать что-то новое из уже существующих частей.
Поэтому хакер — не обязательно тот, кто ломает систему. Чаще наоборот: это человек, которому система настолько интересна, что он хочет понять её глубже, чем требуется обычному пользователю.
Хакеру недостаточно, что система работает. Ему интересно, почему она работает именно так.
Share
