Skip to main content

Posts

My thoughts as an experienced developer in this field.

To be honest, I would have never guessed that      I would end up saying these these things, especially jn the beginning of my career. As you become more experienced, you kind of get to see everything and you become less impressed by new things. Honestly there is some sort of repetitiveness in this field and we kind of like to reinvent the wheel quite often, because well, we become a bit too easily bored. Take for example how the web looks now, a lot of it has been borrowed from other places, mostly desktop development, especially the parts about making custom reusable components.  Or from older frameworks, like state management in the UI which actually was first properly implemented in Asp .Net Webforms, as far as I know, something like 20 years ago, where you used to have the dreaded view state.  But most likely something similar existed before that too. I was not that surprised when React adopted initially this idea. Or even less surprised when hooks where introduced that seemed a b
Recent posts

My experience joining Microsoft, one of the leading companies in the industry

 This past year I finally made a big leap in my career and joined on of the leading companies in this the software industry, it's been one of my lifelong dream to join such a company and now it happened. It's been quite a journey and I noticed a lot of things so far that I would have never imagined.  Firstly, the scale of things is something that completely blows my mind. I never thought that I would be part of tens of teams, just in my local division in geographical region. Everything is massive and scattered around the globe with hundreds of teams out there. And getting so many teams to work together is really a challenge, especially making sure that they don't constantly reinvent the wheel.  Or another very challenging aspect is the fact that no team is actually alone and depends on the work of many others teams. Here I noticed several skills that are really useful which I never though of before. One of the skills is getting the right information and reaching the r

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 thoughts after interviewing at Facebook, Google and Microsoft and failing gloriously with confusing results

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

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

Some real soft skills which are useful as a developer

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.