Untitled Coding Blog

Since 2020 was pretty much a year spent locked inside the house, eventually I was bored and didn't have much to do except to sit all day in front of a screen, I decide to try my luck at some big companies, at least to get my foot at their doorstep with some interviews. Now to apply for these companies and to actually get a semi decent chance to pass the phone interview, also known as the phone screening, you need to learn standard algorithmic stuff taught in the first years of university. This meant relearning a bit one of the most painful courses in university that I did, that "slaugthered"  many students, like "Programming and Algorithms" or "Algorithm design".  "Luckily" for me, I was stuck inside my house so I didn't really have anything better to do. I started with a book, the standard book for interviewing at these companies called "Cracking the coding interview". I pretty much finished it in around 6 weeks by reading 4-5 ...

 I haven't really written here in a long time so it's time to write some new things. These are just some random common sense things that seemed to short to write about individually but seem really interesting and useful to me or other people 1. There is nothing fixed in software development, all things vary by circumstances and time Remember the documentation that didn't seem that important when you started the project, well after a couple of years one the application has grown and become really complicated, no one actually knows everything about the application anymore. So now you really need that documentation. What happens if you suddenly need much more people to develop the application because of some explosive growth? Without documentation, new developers will just look at the application like they look at a painting. This actually happened to me. Maybe in the beginning of a project, a technology really helped you a lot but as the project grew, it started making things...

This is probably one of the most controversial things that I have written so far but I am just tired of hearing about these things and discussing these things. Other developers that I know share part of my feelings. I would rather hear more about how people built things, overcame challenges or what new interesting ideas and concepts they implemented. Those things are really interesting and innovative, not hearing about the same theoretical things over and over again. I can just read and learn those things from 100 sources on the internet. Firstly, one of the most discussed and promoted things is agile/scrum development. I think I have been through 5-8 workshops about agile development methodology. And each time, some things differed. There is no 100% standard approach to this. Everyone uses their own version of this development methodology and seem to argue a lot that their approach is right and everyone else is doing it wrong. You go to an interview, this will be one of the first 10 t...

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