Every once in a while I get asked a variation of the same question. “Viktor, how do we create a learning culture in our company?” In most cases, my answer receives a bad reception. The short version of it is to “stop doing what you’re doing, and get out of the way.”
Engineers love learning. Most of us became engineers because we like to “play” with tech. And yet, people in many organizations complain that they are not allowed to innovate and that they don’t have time to learn. If my statement that engineers are playful kind of people, lack of innovation cannot be attributed to them, so we need to look for causes somewhere else.
Any system that intends to be fully automated and self-sufficient must be capable of self-healing and self-adaptation. As a minimum, it needs to be able to monitor itself and perform certain actions both on service and infrastructure levels.
Two axes can represent the set of actions a system might execute. One group of actions be represented through the differences between infrastructure and services. The other axis can be explained by the type of activities, with self-healing on one end, and self-adaptation on the other.
Let’s face it. The systems we are creating are not perfect. Sooner or later, one of our applications will fail, one of our services will not be able to handle the increased load, one of our commits will introduce a fatal bug, a piece of hardware will break, or something entirely unexpected will happen.
How do we fight the unexpected? Most of us are trying to develop a bullet proof system. We are attempting to create what no one did before. We strive for the ultimate perfection, hoping that the result will be a system that does not have any bugs, is running on hardware that never fails, and can handle any load. Here’s a tip. There is no such thing as perfection. No one is perfect, and nothing is without fault. That does not mean that we should not strive for perfection. We should, when time and resources are provided. However, we should also embrace the inevitable, and design our systems not to be perfect, but able to recuperate from failures, and able to predict likely future. We should hope for the best but prepare for the worst.
If you are using Windows, please make sure that Git is configured to use “Checkout as-is”. This can be accomplished during the setup by selecting the second or third option from the screen depicted below. Also, if you do not have SSH installed, please make sure that [PATH_TO_GIT]\bin is added to your PATH.
This article will try to compare GitHub, GitLab and BitBucket Server (previously called Stash) installed on your own servers. Similar comparison of cloud offerings is outside the scope of this article. I won’t try to go feature by feature in some kind of a table so that you can count who has more features. I find that approach often misleading even though it’s very commonly used among companies (especially where there is a software architect around). Instead, I’ll give my opinionated view.
Google is one of the biggest, the coolest and the most profitable companies in the world. Probably the main reason for being at the top is their ability to innovate continually. According to Gopi Kallayil there are 9 core rules that drive Google’s innovative culture:
- Innovation comes from anywhere
- Focus on the user
- Aim to be ten times better
- Bet on technical insights
- Ship and iterate
- Give employees 20 percent time
- Default to open processes
- Fail well
- Have a mission that matters