When we work, we want feedback: do we do the expected job? Does it fail? Where does it fail? Therefore, we want to receive feedback loops from our environment that gives us useful information about how well we're doing. This is what loopy means.
Hi! My name is Julien and I'm a tech leader at BAM where we design and develop mobile apps. A part of my job is to provide a healthy environment for my fellow developers to work at their best, improve quicker and then become tech leaders themselves.
In a dynamic system we want to adapt from visible inputs to concrete actions. And to do that, we need standards.
It starts with standards
Standards are established rules in the team. They are our best guess about what a good job is. Writing and comparing with real life allow us to distinguish what is normal from what is not.
Some tips when writing down a standard, make sure you have:
- why it's important to write it down,
- what are its key points,
- what are the common mistakes we can avoid in the first place,
- and what are the concrete examples to better understand it.
With these key points in place, we'll be able to compare with the real world and adapt. In a nutshell, to be loopy.
Loopy code
Once we agree as a team to use a set of standards, we want our tools to know them. Take linters in your code for instance. Linters are scripts that find and sometimes can even fix problems automatically. They are great to provide warnings when a developer diverges from the expected code. It saves time on training, on reviewing and on debugging.
The more we use a tool, the more reliant we want it to be. If in the previous paragraph you thought “Well, in my project linters are a pain in the butt, I hate how they force me to do additional work!”; this is a clear hint you are working for your tools and not the other way around. We don't want this. We want computers to execute repetitive tasks and humans to solve problems. So gather your team and update your linter rules so nobody complains. 🤔
Loopy tests
Talking about tests. If you want to rush, don't write tests. If you want to go fast and go far, write tests.
Mental loads are real and a heavy burden. When we start automating tests of some of our code, we can discharge that cognitive load. This will lead to a freer mind and easier and more effective days.
Loopy production flow
I wrote an article about how useful it is to see the steps in the production flow. By showing the production flow, we know where we are and how good we are. We can then adapt our work/prioritization.
We then can spot and identify problems and solve them - they are called “red bins” in lean production. Displaying the problems in front of the whole team helps to highlight how they are slowing the whole process down. That way they can't be ignored and actions must be taken.
Loopy user satisfaction
The better we understand user needs, the clever we can work. There is no shame about being wrong in the first place. The most important thing is to acknowledge and adapt.
Make your tools work for you not against you
We tend to believe that a part of our job is to use specific tools and deal with its disadvantages because "we're used to it and it's always been that way". We tell ourselves: this is my job and if I fail, it'll be on me. Of course it's a bit more complex than that. In our day to day work, we all make mistakes: these ‘human errors’ are not a cause but a symptom of a deeper problem in your system. Understanding how and what causes a ‘human error’ to arise is the beginning of understanding a little bit about a complex system. And in an overly complex system, being able to adapt with feedback loops is better than being able to predict.
Shorten the loops
Your time is valuable, your focus is valuable, this is all about you and enhancing your work. The quicker you get feedback, the faster you can adapt. And the more feedback you get the more you work smarter.
This article was inspired by the Loopy tool from Nicky Case, I can only suggest you take a look!
Top comments (0)