Article List

Recently, while reading Martin Fowler’s wonderful articles on software architecture, I came across his classical book “Refactoring” which apparently has been updated and published in a second edition. I got to know about this update when watching his energizing talk at Etsy Engineering in February this year.

When I was a kid, I liked a few things. I enjoyed reading and even read with a flashlight under the blanket. My other poison was Lego kits, which I didn’t have many, but enjoyed building things a lot. Then, I fell for computers. From playing games, through deleting Windows 3.11 and formatting the hard drive, to programming with Basic and on.

It seems that my mother made me love reading by slipping in books I would love. Most of the times I recall it worked, and I would spend hours with a book.

So after reading Harry Harrison’s Stainless Steel Rat about the genius intergalactic criminal James diGriz I became obsessed with being a hacker. I didn’t really know what it would mean to be a hacker for real, but this guy seemed to be smart, cunning, adventurous, and fun.

Women loved him. He got the money and tricked the most advanced security systems and even government institutions. He was strong and courageous, full of life.

While working on one of my inspirational open-source projects, I found out that there's currently no way to observe element style changes. At least I couldn't find any mentions of library-like solutions for that. I assume that the reason for that might be the fact it's hard to understand whether or not the styles have changed.

I recently joined a developer community Dev.to. It is a really nice place where people spur discussions and ask questions that are not only related to technologies and software development but are incredibly important as well, for us, the human beings constantly looking for meaning in life. One of these questions is my favorite “What are your career goals?”.

There is a widely held opinion, which I usually support, that declarative code is "better" than imperative. It is less error-prone, usually much more eloquent and neat, and hence more maintainable. It is a good principle to follow on a day-to-day basis when you use existing declarative tools or libraries, like JS standard Array methods, or lodash, or React.

However, when it comes to deciding to either write some declarative, and therefore more generalized code, or just leave an imperative solution, I suggest thinking at least twice.

Imagine you’re writing an algorithm that performs looping over an array with any type of pointer (for or while loop, forEach, map, etc). Each iteration the pointer moves in any direction, but you never force it to come back in most cases. Why should you, after all?

This mode of manipulating data is so usual that you probably have never thought about how liable it is to causing hard-to-find bugs, which lead you towards tiresome debugging!