There's much to learn from the flawed processes and broken things.
As children, many of us would crack broken electronics open to see what was inside.
That’s a perfect learning way, as long as you go beyond the obvious.
I’ll show you how it works on examples from pop culture, everyday life, and my software engineering job.
At the 2021 Christmas party, I talked to many people in Evojam about values. I noticed that everyone agreed on the importance of growth. Not in the sense of size, but finding opportunities to learn. It got me thinking about how I was able to make progress last year.
Sometimes you need to know which levers to push if you want to bend a complex system to your will. The same can be said about your mind. I tend to trick myself into doing things that benefit me and the others around me.
As developers, we produce tons of code each day. We test our code, beautify it with code style scripts and finally verify using continuous integration commands, which control the integrity and cohesion of our solutions. Nevertheless, the true value of used code solution can be checked only by another developer, who knows the business domain, best practices, clean code principles and who may also have a different point of view from yours. In this article, I want to show you how code review can help you keep codebase in order and get more advantages for your team.
Have you heard about Scrum, but…? This means “we do scrum, but…” we don’t do retrospectives, don’t do daily standups, etc. Well, there’s a deep wisdom behind all the Scrum practices we give up. Be aware of the risks you create and know how to counteract them. This is a first post in a series that aims to show how you can keep the benefits of Scrum in real life.