Untitled Coding Blog

I keep hearing more and more that as a software developer you still need soft skills, that soft skills are more important than technical skills and so on. But no one really has any concrete ideas about what these soft skills actually mean as a developer. Everyone just keeps talking about them but I don't see anyone actually going into details about them with concrete examples. Not to mention that a lot of people are just trying to make money out of these things and when they say that soft skills are important it is usually followed by some self advertising about their soft skills trainings. And to make matters worse, some of these preachers, pardon people, don't have a lot of experience in the development field. Some of them are not that good developers and then they say, that not only technical skills matter but also soft skills. Maybe they are not so great developers because they also don't have good enough soft skills also. Now on to the concrete part of soft skills....

Lately I had to do more presentations ranging from technical ones about various technologies to other presentation about projects that I work on or even tools that I made for developers and testers. I didn't learn a big list of things from them but rather a couple of really important things to keep in mind when doing a presentation. To begin with, as a presenter your purpose is to make people understand what you are explaining first and foremost. I have seen all too many experienced developers trying to impress the audience when presenting something. They use a lot of pompous language, terms and jargon to make things seem more complicated than they really are. This is just to feed their own ego, to send a subliminal message to the crowd over the lines of: "Look at me how good I am, I managed to understand and apply these things which sound really complicated when I tell them". Imagine if they used a more simple language and a language which is less scary and intimid...

I keep hearing all sorts of things about being a senior developer, senior software engineer and so on. I especially hear how people from new people to this field how they want to become a senior developer as soon as possible and how having "senior" in your title means everything. Or I hear a lot when a new team is formed that everyone wants as many "senior" developers on that team as possible. Fortunately, I learned these things mostly from other people's experiences. And I will be honest here, a lot of the things I will mention next in the post, I am guilty of too or used to be. In general everyone puts accent on being a "senior" something that knows a lot of technical things which impress other people but not many people put enough emphasis on being a grown up adult, a mature developer. Being a mature developer involves a lot of things, having technical knowledge is just a part of them. But it requires other skills and a specific personality too....

For the past years I have talked and interacted with a lot of developers involved in outsourcing, gathering some nasty or challenging parts of their experiences. Fortunately I didn't run into all of them, at most 2 or 3, and not the whole time. Still it takes some skills to overcome them. Firstly, when you work as a developer in outsourcing you pretty much have 2 sets of bosses and managers. One set is at your main company that pays you directly and another set is at the client for which you are actually developing software and whom signed a contract with your company to provide him with some developers, like me. We call him a client but actually there are multiple people at the client involved in the development process. There is usually a product owner that gives you the requirements, stories and things that you need to develop. Besides him, there is usually a technical person too, a technical leader that establishes the development stack. These 2 people can contradict themselv...

This has been boiling in the back of my mind for a while now. A lot of developers talk about antipatterns, patterns, good practices and bad practices. But I rarely hear about how did a bad practice get established during the development process. Or in general, how do various tendencies work during software development. Firstly I will start about features in general, in applications. Not all features are equal in an application, some of them are core part of the applications functionality. And usually these features are known by all the developers in the team, because the application can't work without them. Now imagine that a developer needs to do a new feature in the application similar a bit to a core functionality. Where will he look for ideas and inspiration about how to code the new feature? Of course in a similar core feature known by everyone. So these core features are used as reference a lot of times. Now his can be a good thing or a bad thing depending on how those fe...

Lately I started working on a new project at work. We just started laying the foundation for everything and I ran into the problem of how to assign general responsibilities to various components in the code so that we establish some sorts of patterns and standards used everywhere in the code. Some roles and functionalities were already defined, I found this really useful so I decided to write this post. I still have a lot of things to learn. Having an uniform code with a similar structure everywhere makes it really easy to understand. Also having clearly assigned roles to objects makes it easier to understand. 1. "Calculator" functionality If you have a class in which you do some kind of mathematical calculations and comparisons then you should add this in the class name. In general it encompasses some kind of mathematical formula. For example at one point I had to calculate how much fluid I had to allocate for some tubes. In general when you deal with numbers, you will...

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...