I’m a programmer and I read a lot. I read a lot of technical blog posts, too. But the truth is that I can’t finish the most of them. Too often, the language is so hard to read, the structure is so terrible… Even if the idea behind the post is good, it’s often hard to fully appreciate it.

Let’s say you’re one those programmers who think that they have something important to tell to other programmers. However, it’s not enough to just write down your stream of conciousness. You could, of course, but the most of people will not…

When it comes to discussing the SOLID principles the first one that usually comes to mind is the Single-Responsibility Principle, or just SRP, the first letter of the acronym. It’s become so obvious, that no one really ponder it anymore, its importance is just taken for granted nowadays.

Here’s its original expression by Robert C. Martin (a.k.a Uncle Bob:)

A class should have only one reason to change.

In my early programming days I was so impressed by this simple idea, that it became my working mind set. Now it means for me much more than just “write small, testable…

W hen iOS 14 was released, it became the second iOS’s major version that supports SwiftUI. It means that, in theory, you can use it in commercial app development while supporting two last major iOS versions. Although it’s true only for the first SwiftUI version, I wanted to give it a deeper try for a number of reasons. The most obvious one is that SwiftUI and its satellite tools are considered as the future of the iOS software development.

The so-called SwiftUI 2 is more mature, not to mention it contains more useful features. And most importantly, using SwiftUI 2…

As a reputed coach and consultant James Schiel said, a lot of agile organizations instead of being truely agile just using right words. The cause of that is general misunderstanding of the idea of what the Agile method actually is. This leads to a set of mistakes in organizing software development process. In this post I tell about six ones I’ve been coming across most often and of which I think as of the most common and yet crucial.

1. Misinterpretation

People who got used to work with exhaustive requirements often interpret the word Agile wrongly. Programmers think that they are allowed…

I often notice that people don’t read much. I’ve been thinking that there’s something wrong with that. Not that those people are wrong, of course. There are just too many books out there and sometimes it’s hard to pick the right one.

I’m the opposite, I read a lot. And I can’t say that every book I’ve read is worthwhile (in my case, of course). In this post, I share a list of very remarkable ones and tell you about them in a few words. So, you’ll be able to choose the right one for you.

1. Code Complete. Not Only the Basics.

Code Complete. A Practical Handbook of Software Construction by Steve McConnell

This is one of…

There are a lot of posts about how to implement one design pattern or another. I’d like to clarify immediately that it’s not one of them. This post doesn’t explain patterns, but instead, requires reader to have some basic knowledge about them.

What I’m talking about here is my way across various design patterns to my current shelter. And the trip begins with a rather infamous one.

Model-View-Controller (MVC)

Agile practices have been arising and evolving since the 1980s. But the real impact on the new philosophy was given by the Agile Manifesto, which had taken shape by the beginning of the 2000s. A little bit of hype and everyone rushed to proclaim themselves agile. Even without thinking of whether it’s true. The emergence of frameworks such as Scrum influenced the phenomenon even more. But in fact, most of those adherents just shortened time periods (e.g. sprints) on which they had been dividing their working processes. Hence, the Mini Waterfall — it was all the same. …

I’ve always been a person who pays attention to detail. When I read someone else’s code I always notice its formatting inefficiency, inconsistency, or, sometimes, even ugliness.

The advantages of good code style have been stated many times. In a nutshell, programmers spend more time reading other people’s code than writing their own. That’s why it must be readable.

I have my own Swift code style guidelines which have been evolving since my very first line written in Swift. It stayed with me when I switched projects and it’s never failed me. …