We would fail to write bubble sort on a whiteboard… Should we be proud?

Recently there was very interesting activity on the Twitter where famous programmers just admitted they are very bad at Computer Science (CS) and other fundamental concepts and still doing very well.

Now, this is very interesting. To me, this is just another manifestation, that knowledge has a little value today. Everything can be easily Googled in a very short time. Yes, the search takes some time, but it is much more efficient than trying to learn and remember all the details of CS and technology concepts. And I also admit: I would fail to write bubble sort on a whiteboard and estimate my algorithms’ complexity while being a successful developer for more than a decade now.

But one may come to the (I believe wrong) conclusion that it is ok to be unable to estimate the algorithm’s complexity and not to understand the essence of fundamental algorithms and their complexities. Algorithms are the methods for solving problems of procedural nature while design patterns are the methods to solve software structural problems and I would argue both are the very basics of software engineering. If you do not know these methods, when you are tackling the tough problem, you basically don’t know what you don’t know. You are unable to discover that your problem can be reduced to one of those fundamental problems and there is already an elegant solution to it. I definitely see my ignorance in CS as a problem and I am currently deliberately studying algorithms :-). And also clean code, which I always enjoy learning and practicing.

Here is what John Sonmez experience was after having learned algorithms:

All of a sudden it was like I put on special glasses that let me see the world in a different light and all these problems, all these places where I was like there’s nowhere in the real world where I’m going to use algorithms in my code, bam, it was popping up everywhere. It’s like, “Whoa! Look! Oh, I recognize this. This is like a min-max problem.” Bam! All of these places I started writing really efficient, really good code because I could see the problems.

I can also see the pain when job interviewers start asking puzzles and algorithms stuff. I hate it. If you want a job you are stressed already and now you have to focus, concentrate and tackle the tough problem at the blackboard as if you would do it at your real work! Problem-solving is very creative activity and It can not be done effectively under stress because the brain actually focuses on security aspect first and foremost. I don’t know how to replace this practice, but it is total evil to me. Interviewers, please, don’t do it to us, developers, unless the job requires this type of skill and knowledge. Pretty interesting article on the related topic from Yegor Bugayenko. But since interviewers still continue asking, maybe realizing the importance of fundamentals, we should be prepared!

Hence, if you have some spare time and you have a choice either to learn some new cool JavaScript framework, which will be forgotten in few years or some of the algorithms or design patterns which will serve you throughout all your career, I believe it is better to select last option.


Знайомство з мовою програмування APL

З радістю, на запрошення компанії SimCorp Україна, знову викладатиму курс по основах APL. Цього разу вирішив записати вступне відео, щоб потенційний студент міг ознайомитися з APL і моєю манерою викладання.


What are TypeScript’s any, void, never, undefined and null types

Unlike intuitive types such as string or number, the types any, void, never, undefined and null might cause a confusion for a newbie TypeScript developer. In this post, I will share what I have learned about these types.


The simplest one is any. From the spec:

The Any type is used to represent any JavaScript value. The Any type is a supertype of all types and is assignable to and from all types. In general, in places where a type is not explicitly provided and TypeScript cannot infer one, the Any type is assumed.

So, the any is the way how so-called optional typing is implemented in TypeScript. With any you effectively switch off the type checking and working in “JavaScript mode”. It is very useful when you gradually migrate from JavaScript and have not yet figured out all types. This is one of the core TypeScript’s value propositions.

undefined, null and –strictNullChecks

From the spec:

The Null type corresponds to the similarly named JavaScript primitive type and is the type of the null literal. The Undefined type corresponds to the similarly named JavaScript primitive type and is the type of the undefined literal. The Null type is a subtype of all types, except the Undefined type. The undefined type is a subtype of all types.

So from the spec, these types are the types whose domains consist of only one value and undefined is a specialization or subtype of null. However, despite of having this specialization relationship you still can assign null to the variable of type undefined and vice versa, hence more specifically the domains of both null and undefined are two values null and undefined:

The compiler option --strictNullChecks enables strict null checking mode, which removes the null and undefined values from the domain of every type and is only assignable to themselves and any. I believe this is much simpler to understand and predict how TypeScript will behave in different situations. Strict null checks provide us with the tool to increase the code reliability and therefore I recommend to always have it switched on unless you are dealing with a huge legacy system which does not compile because of this compiler switch.


From the spec:

The Void type, referenced by the void keyword, represents the absence of a value and is used as the return type of functions with no return value. The only possible values for the Void type are null and undefined. The Void type is a subtype of the Any type and a supertype of the Null and Undefined types.

This seems to be the pretty simple type with the domain of two values null and undefined. But as we learned earlier, the same domain is defined for null and undefined types. While the need for later types is dictated by Javascript, why we need yet another type with the same domain? Well, first, with --strictNullChecks the domains become not the same and second, we want to logically differentiate between function which might return undefined in some cases and function which does not expect to return any value at all:


The never type represents the type of values that never occur. It is a bit weird, but it perfectly makes sense in cases when function never returns a value or when you write a code in the code branch which will never execute: