If you need to run stateful applications take a look at Service Fabric. It has it quirks but we are running it in production and we are pretty happy with it so far.
I am struggling to find what an average person with a bit of excess money that goes into saving can do when we are faced with higher than normal inflation. I was a kid when hyperinflation happened to my country in Eastern Europe and it was devastating for my family. Hopefully something like this won't happen, but then what should we do if in the next few years we are hit with inflation at the ranges of 10% to 15%? Maybe I should just accept that it is out my control and focus on my work and personal development so I can find a job in any market condition.
The “Two-And-Done” Rule resonates so much with me. When I was younger I was very passionate to argue for things to go my way when I believed that I was right. This almost cost my first job and I got a serious warning from my manager. Now I explain why I disagree with something, lay out my arguments but eventually I commit to the group decision, made by the whole team. Even though many times things don't go my way, people often come to me to listen to my controversial opinions and often times I see that they take them in consideration, which is nice.
Interesting points but I would like to add my takeout at how I see Devops and how we use Devops engineers in our organization. My previous boss came up with the definition that most closely describes Devops for me and it is the following: Devops are set of practices that increase the team velocity. And in fact Devops engineers wear many hats. The team needs to get faster their code from developer workstations to production - a Devops engineer could help set up ci/cd pipeline. We need more quality checks and gates before releasing to production - a Devops engineer could help. We need the service to handle spikes in traffic, database backups and failover operations - a Devops engineer could help. We need our infrastructure to be scripted as code, automated, immutable and easy to replicate - a Devops engineer job. Developers have a hard time localizing an issue in production - again Devops engineer could help setting up better logging and monitoring. Also it is not a job in isolation. Devops engineers work closely with the team to transfer knowledge about the tools they built and also observe what is blocking the devs from doing their job in terms of tooling. It seems like asking a lot from a single person in that role but for small teams people often do various tasks by themselves. In bigger organizations people could specialize in different roles like release engineers and SRE but I do believe that there is always a need for someone to be in the Devops role to keep track of the bigger picture and bridge the gaps between devs and operations.
Bulgaria here. I don't know if the comparison is even relevant as we don't have normal mobile data plans anymore. Most of the plans are providing 5-10 GB of data to all networks and websites and some GBs to specific websites like social media and popular ones. So for example I can have a data plan with 20 GB but after the first 10 GB I have fast internet just for facebook and whatsapp. The rest of the internet is almost not accessible as it takes ages to load.
I don't have experience with meditation so I can't comment on that but personally I have been though some very tough periods in my life, battling with depression and anxiety and what has helped me a lot during those periods is physical exercise and eating healthy food. Even better if I manage to join a group sport or activity. It is sometimes hard to find the motivation to do it, doesn't provide immediate gratification and relaxation but if I keep doing it is much more rewarding to my mental health compared to all other stuff I have tried.
We are currently working on IoT solution where we deploy many distributed computing units with leaf devices and SQLite works flawlessly to keep local state on the remote devices. There may be other solutions but this was a no-brainer for us and so far we haven't had any major issues with it.
Specific tests doesn't exactly mean "Simple" tests. It is hard to balance between the two but from my experience when people try want to write specific tests they just start writing extremely simple tests.
Another point I want to mention is that Japan was never invaded on its own territory by a foreign power and it wasn't ruled or politically influenced by outsiders for many centuries. This helps a lot to build and preserve a business.
On the contrary if you take the Balkans in Europe every few centuries the ruling power changed. First was the Roman Empire, then the Byzantine Empire, Bulgarian Empire, many other nations come to power for different periods, then the Ottomans, the Soviet Union and in the present day most of the companies and corporations in the Balkans are very proud if they have a history of 20-30 years (after the collapse of the Soviet Union)
Sadly it always includes songs that I have already liked in every radio that I make and it forces me to listen the same song over and over again until I hate it. I would like radio to suggest music that I haven't liked already...
As a person in Eastern Europe I also kind of envy this but then I remember that the cost of living here is way lower and I am leading pretty good life with the money that I make so it ain't that bad. It is better to just enjoy life instead of being constantly worried if you make enough.
I doubt there are books that could teach you critical thinking. It requires to spend lots of time observing and learning stuff, trying out possible solutions and getting meaningful feedback.
Also from my experience it helps when you stop judging people and stuff, labeling things as good or bad, black or white. Just try to understand different points of view and outcomes as they are.
I am using Azure Devops for the past couple of years and they have kind of nailed it. You have builds that do most of the CI and Releases which can be fine tuned to do complex deployments and complete the CD story. Then you can set them as a requirement for the pull request approval to the main and branch it helps to guarantee healthy trunk.
I don't agree that CI is a team problem and CD is an engineering problem. If you are following infrastructure as code principles it is everyone's problem because if you don't add how your new feature should be deployed it will break the CI and CD pipelines and you won't be able to merge it.