Untitled Coding Blog

While digging through some standard programming principles like low coupling and high cohesion I stumbled upon the fact that they are part of a larger series of principles called "GRASP" principles. After reading a bit about them, they seem just as important if not more important than the "SOLID" principles And one particular principle from that series stuck with me: protected variations. According to this principle, variations and changes in parts of the application should be contained only in them and not trigger further changes in the application. In general terms points of inflection should be established between the parts that change and the rest of the application which act like a boundary and stop additional changes from propagating to the rest of the application. For example, one of the most common parts that might change in an application, is the data access and storage methods. For example instead of using direct sql to read and write to a database, an...

Over the last couple of months I had the opportunity to interview for one of the most revered companies for any software developer in the world which is Facebook as you have guessed from the title. It was a really unique experience and surprisingly I learned a lot about myself too. It turns out that after all these years building small and maybe some smaller medium sized applications, I have become quite passionate about those kinds of applications. Building these kind of applications allow me to have fun using things that I love the most: object oriented programming, designing functionalities and splitting them into components and using various interesting programming principles or software design principles. It turns out I am very passionate about algorithmic stuff and high performance stuff. I mean I do enjoy them from time to time, but they don't really seem that creative to me. With object oriented programming and various software design principles, you can come up with an...

This has been baking in the back of my head for quite a while now and it happened to me and the team that I am part of, at work, in the last couple of months. I think it is worth analyzing what actually happened and worth keeping the lessons learned in the back of your head all the time, especially during estimations. Now on with the story. Initially when I joined the company I currently work at, we started slowly doing work and getting to know the application with its business logic. We had a lot of doubts in the beginning. So during the estimation meetings at the beginning of a sprint, we were constantly unsure of the tasks that we had to estimate. At first glance this seems like something bad but it actually had a silver linning. That doubt kept us analyzing the tasks that we had to do more in depth. We also looked into existing code more often which helped us too. And quite often we would discover hidden issues that at first glance were not so obvious, issues like hidden depend...

Lately I was working at work with various services, maybe one or two microservices. I also worked a bit on an open source project, entity framework core. And then I remembered about pointers which I learned in the first year at university. Now you ask me, what do these things have in common? Lets start firstly with pointers. Usually in programming you can access a resource directly from the code. This resource can be a number, an integer or just about anything else. But by using pointers you don't access the resource directly. The pointer is pretty much a number that has a deeper meaning in a context. Now to access that resource, you need  to do a bit  of translation. You don't access it directly anymore in the code. You have to figure out where it points to and then see what was the last value that was assigned in the place its pointing to. Then you  know the actual value it points to.  So there is kind of jump in the normal workflow  when accessing a resou...

This post has actually been "baking" in the back of my mind for quite some time now. Initially I actually wanted to do a presentation with most of the content of this post based on some important open source project but I could not find the motivation to actually finish the presentation because it ended up being a bit complicated. Also, this post is actually the result of me interacting with a few developers at the very beginning of their careers and also seeing the behavior of various students at university. So this post will be mostly about some of the obstacles that most people face in the beginning of their careers but not only this. The first thing that comes in my mind is that people panic too fast when trying to learn something and actually stop trying, thinking and focusing on learning. I looked into this and I noticed several things. One of the most obvious thing is that people are scared of abbreviations or pompous words. And in this field you will notice them a...

This post has be "baking" in the back of my mind for quite a while now and I think it's almost done baking. I got the idea to write this post while I was working at my previous employer. There I would develop some pretty complicated functionalities that took a long time to develop with quite some effort. And after that I was frustrated because those functionalities were hardly used anywhere. So my question after that was why did we develop them anyway? After those incidents I happen to read about the release of some new mobile phone. I think it was the release of Samsung Galaxy S9. It had around 98% of the same features as the previous model, the S8, including the main functionalities used by everyone. The new functionalities were hardly used by anyone. But on the other hand it gave the consumers a reason to upgrade their phone. And it gave other consumers that were looking into buying a new phone a reason to buy a Galaxy S9 over another phone from another brand. As...

Lately I participated in a couple of interviews. During those interviews, the interviewers tried to classify me as either a medium level developer or a senior developer. That's when it occurred to me to think about the progress that I made in the past 6 years or so since I have been professionally developing commercial software. Honestly, over the course of these years I have learned to look from the perspective of other developers when writing code. Equally as important, I learned that when I have a complex problem to solve, my job isn't actually to solve that problem directly. But rather my job is to find out ways to make that complex problem more simple and then to come up with a series of simple functionalities which add up to a simple solution. This has a lot of consequence on the way I develop software. For example, if you need to develop a big application, you can think of that application as a series of smaller applications that need to collaborate together to do wh...