As an IT professional with more than 30 years of experience, I constantly use a huge number of different products and services—both at work and in everyday life. In recent years we can hardly imagine our lives without all these services.
Yet in the chase for optimization and other chimeras, many have begun to forget that a product is made first and foremost for its users. And the biggest mistakes lately, in my view, are atrocious user support—often hiding behind a façade of supposedly excellent customer care.
Everyone is trying to cut costs, and so they either replace help with AI bots or hand support over to cheap, incompetent specialists. In the worst case they remove any support at all (or hide it so well you’ll spend a couple of hours just trying to find it).
What’s the result? The product itself may be wonderful. But as soon as a loyal user runs into a problem, they look for help. They’re not interested in tons of articles on the subject; they want their specific problem solved. Preferably here and now.
I am sometimes asked which books I would recommend reading. For the blog, this is generally not difficult — it’s enough to open all posts with the tag “I-recommend.” But since it’s been almost five years now since I revived my blog and began writing about the books I’ve read, I decided to put together a selection of non-fiction books I’ve read during this time that fall into the category of “you must read them.”
I have already written detailed reviews of all these books, so this time I’ve selected only the very best, grouped them by topic. For each book I give only brief recommendations on why they are worth reading, but you can always open the link to the full review. I hope this will be useful to someone. So, let’s begin.
The word “producer” entered our everyday vocabulary in the former USSR around the 1990s. For many, it was associated both with a person who could turn any idea into a product and any person into a star, and at the same time with something shady. Apparently this was because many people back then had a lingering sense that any business was tied up with some kind of crime or vulgarity.
Later, however, the word no longer felt foreign in the language. In film it replaced the position of “film director” (in the sense of production management), and in many other industries the role finally came to mean what it should — someone who helps organize production as a whole, and who enables the team to create the product.
In the game industry, to which I have already devoted many years, this role exists as well. Yet to this day, few could really explain to you what exactly a producer does on a team. People still do not understand the meaning of a producer’s work, and some consider producers to be arrogant, overpaid idlers and budget-burners.
Dan Irish is an experienced game producer (the legendary Myst series was created with his participation, starting from the third installment). In 2005 he wrote the book The Game Producer’s Handbook, which is still often recommended to novice (and not only novice) producers.
Alex (Alexey) Krol describes himself as an “entrepreneur, author, lecturer, and film producer.” Judging by his LinkedIn profile, he has had an impressive career, managing multiple companies before stepping back to take on roles at lower levels. Along the way, he also worked in game development.
Recently, he has been focusing more on writing and designing concepts, particularly in the fields of gaming and NFT mechanics.
However, I only learned about his professional journey after reading his book The Theory of Castes and Roles, which is what I want to talk about here. The book has received quite high ratings across various popular bookstores and review platforms. Moreover, several of my acquaintances spoke about it with great enthusiasm. While I take online reviews with a grain of salt (even though I write them myself), recommendations from people I know usually carry more weight—though, of course, tastes may differ.
The book itself is quite short and presents a theory developed by Alex Krol himself. The core idea is simple: in this world, resources are limited, and not everyone will have enough. You are either in the role of a “slave” (at the lowest level) or you secure a place among the powerful elite, with all the accompanying benefits—high salaries, yachts, villas, and so on. But between these two extremes, there are many intermediate positions that largely determine who you are and what you are worth.
I came across Alex Exler’s post about the “What Did You Study and What Was Your Job?” flash mob (the post is in Russian). It’s a fun idea, so I decided to write about myself and also find out about others.
So, I graduated with a degree in “Computer Science” from the Faculty of Applied Mathematics and Computer Science (ФПМИ in Russian) at Belarusian State University (BSU). According to my diploma, I’m a “mathematician-systems programmer,” though I’ve always felt we leaned more towards applied programming than systems programming. But that’s what the diploma says.
Now, as for “what jobs I’ve had,” that’s much more entertaining. By “work,” I mean only activities for which I got paid. If I did something for free, it doesn’t count.
Here’s the list:
Janitor (my very first job where I earned money)—there’s a photo above, though it’s of poor quality, and I’m not in it because I was the one taking the picture. Still, you could call it our little gang of janitor-trainees back in 1987 (yes, in the fourth grade).
Electronic text typist (typed handwritten texts onto a computer).
Programmer (even before officially earning the title).
Journalist (wrote a few articles for the teen newspaper Perekhodny Vozrast (Teenage Years), for Computer Gazette, and some small pieces for sci-fi magazines).
TV scriptwriter (for the TV program Five Wonders on Belarusian television; my wife later took over the baton).
Translator of fiction books from English to Russian (I got paid for two; one was published).
Writer (I earned some pennies for my book, so it counts).
Blogger—like this blog, for instance. I’ve received a few donations for it.
And the rest is in my main profession:
Programmer
Software architect (not of buildings)
Analyst
Technical writer
Project manager
Manager at various levels
Management and process consultant (this is what I currently do, and my full professional history can be found here: https://www.linkedin.com/in/knari/)
It’s impossible not to know about Agile development nowadays. Heaven forbid someone catches you unaware—it’s practically a career-ending move. I’m joking, of course, but the fact remains: every developer and manager in IT can talk at length about how they’ve implemented Scrum, Kanban, sprints, and plenty of other fancy terms in their teams. However, in practice, it turns out that very few people actually know how to make all this work properly (and the author of these lines harbors no illusions about his own expertise, even though I’ve been working in this field for a long time). While these methodologies have been actively used for many years, it eventually became clear that in their pure form, they work well for small teams, but when applied to projects with a large number of participants, the results are less impressive. That’s when the next wave of development began, as people started thinking and experimenting with how to scale these practices.
A lot of new methodologies emerged—some faded away, while others developed through trial and error and found their use. Among them are Scrum of Scrums, LeSS, and SAFe, though there are many others as well. It’s hard to say which one is clearly the best, but SAFe has recently gained a lot of followers and seems to be leading the pack statistically. At some point, I couldn’t ignore it because every methodology has its advantages. Even if it doesn’t fully take root for you or your team, you can always borrow some elements, implement them first, then move on to the next… and so on, as long as it genuinely improves quality, transparency, and, of course, the final result.
I decided to write about Cyprus and IT. Perhaps this post will upset some people, but I’m sharing my perspective as I see it.
I’ve been meaning to write about IT on our island for a while, but recently I found an additional reason to do so. Over the past few months, I’ve noticed an odd wave of posts in various communities, like: “Looking for a job in Cyprus, currently living in Sunny Podunkville, open to opportunities,” or “Vacationing in Cyprus, skilled and talented—if anyone has work to offer, let me know.”
Alright, I’m exaggerating a little, but overall, there has indeed been a noticeable increase in queries from people who don’t live in Cyprus but have clearly read or heard somewhere that Cyprus is now a fantastic place for the IT industry. I want to explain what it’s actually like, what the advantages are, and what the downsides are.
Let’s start with the fact that IT as an industry has never really existed on the island. I moved here in 2014, and back then, the IT sector was quite uniform. Thanks to offshore regulations and British law, many Forex companies had established a strong presence here, along with a few others connected to the financial sector.
I have often heard opinions that the work of a consultant is useless and lacks prestige. Something like, “They show up, give a bunch of advice, and leave, without caring about what happens next.” Such an approach to work has always been unacceptable to me, and now that I myself work as a consultant, I want to briefly describe one type of task I have performed at the request of several CEOs, whose feedback on the results was positive.
With experience in both software development and operational management, I can take an external view of a business and evaluate different aspects of its work. As a result, analyzing existing processes—everything I can get my hands on—has proven to be in demand. (Sometimes this is called an audit, but I prefer the term “analysis” as this term has a less negative connotation.) I begin high-level examination of a company by interviewing its CEO: why they reached out, what they want to achieve, what they are dissatisfied with, and what their key products, departments, and people are. Then I compile a list of individuals and competencies that can provide insight into internal processes. It’s crucial to identify who will be available and as open as possible for discussions. During several interviews, I try to understand what the person’s work entails, what motivates them, how they interact with and perceive their colleagues, and so on. Simultaneously, I ask to join key meetings of managers and leads, simply to listen to how they discuss topics, set agendas, conduct meetings, and follow through on decisions. Of course, I also gather relevant documentation about products and processes for further study.
In game development (and software development in general), there is one discipline that, in my opinion, receives far too little attention. Yet it is extremely important and can significantly impact both the perception and the sales of a product. This is localization—the process of preparing a product for another market, which is often understood simply as translating it into another language.
I can talk quite a lot about the topic of localization in general and game localization in particular (and, if all goes well, I’ll share more separately), as I spent many years as the head of several service departments at Wargaming, including the Localization Department. This is precisely why any materials on this subject are always of interest to me.
One of my former colleagues recommended the book Game Localization, where the authors decided to take an in-depth look at this phenomenon from the perspective of a scientific approach to translation in general.
The scientific approach is both a strength and a weakness of the book. The strength lies in its thorough exploration of the topic, its study of the history of the issue, and its examination of many aspects of localization. The weakness lies in the same excessive scientific rigor: countless references to other academic works on translation, an overwhelming number of quotes from analytical studies by other authors… in short, all the hallmarks of a scholarly work that tend to be too tedious for the average reader. Such readers are usually more interested in understanding the essence of the topic rather than the various methods for preparing academic research.
The authors begin their narrative from afar, discussing the history of video games in general and their localization in particular—covering the period from the mid-1980s to roughly the present day (the book was published in 2013, and much has changed in the industry in the past eight years). They then delve into the essence of the game industry (GameDev), explaining key terminology, genres, the role of narrative elements, the industry structure, and so on.
CD Projekt continues to develop its GOG service, which began as a store for selling classic, DRM-free games. In my observation, it hasn’t managed to win the platform war against Steam, but they recently made an excellent move. Forget the platform war; they’ve chosen to target the numerous launchers from different platforms and essentially become a single aggregator for your gaming library. Steam has long been connectable via a plugin, but official integration first came with Xbox Store and now with Steam’s growing competitor, the Epic Games Store.
I fully support this initiative because they haven’t just consolidated a game library in one place; they’ve also maximized the functionality of each platform they can integrate with—friends, statuses, achievements…
They’ve even added a rating system and filtering features. With this, they are gradually moving into a different territory, suddenly competing with game databases like rawg.io and igdb.com.