Чашка Кода

AI is our blessing, not the curse > Recently I(she/her) was talking to a Certified Aerospace Engineer, and we discussed how launching a satellite today is much harder than it was 30–50 years ago. Technology keeps evolving and becoming more complex. In the past, the C language code on a single board could be enough, whereas now we have Kubernetes, Grafana, databases, and so on... I remembered this conversation well, because I often say myself that things used to be much simpler. There was no insane number of development tools. On the one hand, they help us; on the other hand, they add complexity. It seems like that added complexity only slows everything down, but the systems we build have also become more complex. If we tried to implement a marketplace that handles 1,000 RPS using only technologies from the 70s–80s, it would likely require plenty more resources and effort. William Ross Ashby and Larry Tesler both described the relationship between the size of a system, its functionality, and its complexity. Summarizing their ideas, we can say that the functionality available to the user and the convenience of the interface lead to a proportional increase in the internal complexity of the system. So when we say that “it used to be simpler”, we should really think in terms of the functionality that was available to users. It was heavily limited or was not convenient at all! You know that my attitude toward AI is ambivalent. I have been using it for four years already, but I still do see it as just another ordinary tool. Nevertheless, building a platform for our development studio, I had to rethink my relationship with AI. Given the added complexity of modern technologies, we can no longer develop well without AI: it is a tool that removes from us part of the complexity that we ourselves introduced for the sake of user convenience. It turns out that what we now call AI is a natural response to the increased complexity of the systems we build. For me, it is still not a tool that “does everything for you”, but a tool that takes unnecessary complexity out of the work. Without the thousands of hours I spent learning new tools and technologies, I would not be able to use AI effectively at all. At the same time without AI, I would simply get stuck in the complexity of the systems we deliver. If you want to dive deep into this topic, here is some inspirational resources: William Ross Ashby: 1. An Introduction to Cybernetics, 1956 2. Requisite Variety and its Implications for the Control of Complex Systems, 1958 3. Design for a Brain, 1952 Larry Tesler: The Law of Conservation of Complexity Jon Yablonski: Laws of UX

В прошлые выходные наша команда разработки столкнулась с недоступностью серверов в Амстердаме. Изучим постмортем нашего провайдера, сделаем выводы и примем решения. Самое главное в любой ситуации нарушения договорённостей — публиковать открыто честную и своевременную информацию. В нашем случае инцидент затронул только контур разработки: у нас не было доступа к серверу с нашим GitLab. Однако другие компании пострадали сильнее, и постмортем нашего провайдера заслуживает внимания. TLDR: В Европе аномальная жара, и дата-центр FirstVDS в Амстердаме был недоступен около 55 часов. Было принято решение перенести инфраструктуру в другой дата-центр. Подробный разбор инцидента по ссылке. На мой взгляд, компания отлично справилась с инцидентом: во время недоступности сервера соответствующая информация была на статус-странице. Своевременно появился постмортем и компенсации. Главное, что были сделаны выводы и приняты соответствующие решения. Единственный момент, который мы отметили в команде: статус недоступности был указан как «частично», хотя по факту дата-центр был полностью недоступен в течение двух дней. Какие выводы мы сделали и какие решения приняли: 1. Наша команда использует сервер в Амстердаме для хостинга GitLab; мы переходим на gitlab.com. Это частично связано с инцидентом, однако главная задача — улучшить процессы разработки и снизить операционную поддержку инфраструктуры. 2. У нас не было проработанной системы публичного мониторинга доступности сервисов. Поскольку мы начали предоставлять услуги клиентам, мы добавляем контур устойчивости и мониторинга. На поддомене status будет доступна страница с текущим статусом предоставляемых сервисов.

📌 Худшее время искать работу... ...но лучшее, что бы готовиться к поиску работы! Осень — исторически лучшее время для активного поиска работы, но текущий рынок очень сложный. ➡️ Поэтому запускаю августовский интенсив по поиску работы. Что тебя ждет: - 4 часа групповых встреч - 2 часа личных консультаций - 3 месяца сопровождения - персональный разбор резюме 🔵 Бонус: гайд по всем этапам собеседований +———------------+ | ЗАПИСАТЬСЯ | +--------———----+ 💸 Цена: 10 000 рублей 30% от суммы пойдут в приют для собак.

The most important skill for an engineer It is hard to have influence without access, but access alone is never enough. When you are in a meeting where people discuss a new feature, simply being present in that discussion does not mean you can influence the decisions. So do not confuse access with influence. At the same time, influence is important. Several studies show a strong link between low control at work, especially under high demands or high responsibility, and a higher risk of burnout. Employees who are responsible for outcomes but have low impact on how work is done tend to disengage, which lead to burnout over time. For engineers this pattern is common, because they often carry high responsibility for technical decisions and system reliability, while having limited authority over deadlines, scope, or process. This combination of responsibility without control is a common burnout driver. Influence, however, requires trust. A common situation in CIS-region companies is when a manager never allows employees to make real decisions, yet still blames them when something goes wrong. This lack of shared responsibility and trust not only harms results but also puts employees’ mental health at risk. In my view, the most important skill for an engineer is the ability to build trust. The good news is that, in many cases, being a reliable engineer comes down to one simple pattern: do what you promised, in the time you agreed on. Every completed task that matches expectations increases the trust of everyone involved. Over time, if you are consistently reliable and predictable, both you and your manager are more likely to be satisfied with how decisions are made and how work is shared. If you want to dive deeper into the research behind these ideas, here are some useful papers: The Impact of Job Satisfaction on Creating a Sustainable Workplace: link The Effect of Employee Engagement on Organizational Performance: link Understanding the burnout experience: link