Skip to main content

Why I am starting this blog

Lately I realized that it would be a good idea to start writing a blog about my experiences coding various stuff or analyzing the source code of various pieces of software.

So I decided to start this blog because I tend to forget what I studied over the course of the years. I feel that I missed so much not writing about these things. And surprisingly no one actually knows what I really delved into. It seems that I underestimated some of the stuff I did too, things like coding a kind of weird interpreter for C# using parts of the "Roslyn" compiler.

With this blog maybe people can see what I really do and how I really think. It can also serve as a diary to show my evolution in software engineering and programming.

So I hope you all enjoy reading this blog!

Comments

Popular posts from this blog

Some software development common sense ideas

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

Some of my realistic thoughts about technical debt

 Lately I have been kind of stumbling into a couple of issues related to technical debt, a bit more than I really wanted to so I guess it's time to write about this some things. Also, some ideas about this have been brewing in the back of my head for some time now so now is the moment to write all of it. The first thing that comes in my mind when thinking about technical debt is how big is the area affected by it. In the best of circumstances it might affect just a specific area in an application, usually a specific feature because of bad implementation, unclear requirements, various disruptions, tight deadlines or many other reasons. This kind of technical debt usually doesn't have a wide ranging negative impact because it's local to a specific area. The only concerning case it when it affects a critical feature that it used often and updated often, even by other features. On the next level, several areas of an application might be affected by some technical debt issue. Th...

Some things which are often blindly applied and followed by developers which are not always good

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