Untitled Coding Blog

I initially posted this as a post on facebook but decided to also add it here. Warning, it contains bad language. Still, I won't change it because it suits the context really well. I repeat, it contains bad language. Take it as a bit of a joke with some truth to it. So over the course of the years, I have listened to a lot of actually bad experiences from various developers and reading between the lines I came up with the following conclusions about job descriptions and what they actually mean sometimes. Most of the time the things listed in the descriptions are alright but sometimes there is something really fishy behind the bullet points on a job description. These pretty much point the worst possible meaning behind them in a funny and sarcastic way. "Dynamic" or "agile" environment = we are disorganized as fuck so we expect you to figure out by yourself what to do, how to do it and what's important to do. Also, you have to constantly adapt yo

So lately I had to speed up the server with my colleagues at work so it could process requests faster. In our case we have a lot logic that needs to be executed which takes a bit of processing power, it's not a normal web server that just renders a simple page. There are tens of thousands of lines of code that need to be executed and not a couple of hundreds or a few thousands in the case of a normal web server. And to successfully process a request a lot of times the server needs to put the request on-hold until it receives all information about that request freeing that thread to process another request. This is the first place where performance issues can arise because of context switching. Once a request is put on-hold and after that reprocessed, all the context must be restored. This can involve loading heavy stuff from the database. Ideally you should make sure that you load the context from the database once a request is actually ready to be processed and once all the requ