Maintenance of Conventions

[00:00:01]
>> So, actually, yeah let's talk about this. So, the final phase of any good convention is about maintenance, cuz over time we're gonna see conventions either fall in favor, or fall out of favor with teammates. And so, the number one thing here that I can't stress enough is that, it's really important to build emotional safety and awareness within the team.

[00:00:24]
When we have bugs and things, when people feel if they're being blamed as individuals, you'll find that it creates distrust on the team. And this will make it harder for not only conventions to be followed, but like development speed will ultimately get impacted. And so when something goes wrong, similar to like the bug question that we had earlier from testing, it's really important to find systematic solutions to what's happening.

[00:00:49]
So rather than be like, the individual did this incorrectly, we have to ask ourselves, what part of the system allow the individual to make this mistake. Because again, even just being optimistic, I still think most people don't set out to break production. They don't set out to accidentally delete the production database.

[00:01:09]
Like these are problems with the system that doesn't protect people from making these mistakes. And so, another term you might hear in the tech community or might not be just tech community but foot guns or another thing, so preventing people from shooting themselves in the foot. And so conventions do a good job of this, because it allows us to focus on the problem at hand and the repeatable pattern, rather than the individual which is important for long term.

[00:01:35]
Sort of team health and safety, when it comes to these things. And if you happen to be in the power where you are a team lead manager or some sort of leadership role, do whatever you can to protect your devs. And so this means that when things go wrong in production, like not scapegoating, not allowing.

[00:01:54]
Other departments to say like, who is the one person responsible for this? Because the moment scapegoating becomes part of a, like a culture, you basically have people who are afraid to explore and try out new ideas. And this is yeah, this is extremely dangerous for the health of an organization, and the ability to make progress.

[00:02:19]
And so, there's this principle that was popularized primarily by Toyota, it's called the jidoka principle. And so here it's basically, a productivity sort of like it's like a philosophy, and it was popularized in Toyota I think if I didn't say that earlier. And so it's a four step part, where the first piece is to discover what that abnormality is.

[00:02:41]
As I mentioned earlier, when a mistake happen not figuring out what the individual did but, what process allow that to happen. And so, this is being taken in a manufacturing sort of context. So it says, to stop the process. Now granted, most of the time you're not gonna stop development in its hole completely unlike a manufacturing line, but it is important to especially if the bug is a critical one or has a major impact.

[00:03:06]
To sometimes have in all hands, to be like, hey, we have this problem where production database got super impacted, because when we ran the test, it accidentally pointed to production instead of staging. How did this happen, right? These are the kind of things where you do wanna stop the process, because these things pay dividends in the long run, once you can figure out what's wrong.

[00:03:27]
And so as we said, so I went through some of the other steps, but the reason I'm introducing this is because the jidoka principle is primarily responsible for what has been popularized as the Andon Cord. And so, the idea here was that Toyota at the time would basically have this cord, that anyone on the floor could pull in order to stop production.

[00:03:48]
And if you think of it from an assembly line, this is super expensive. And traditionally speaking was like, no one could do it unless the manager said so. But with the Andon Cord, what they did is they said anyone on the floor, if they saw something wrong, no matter how low level they were.

[00:04:02]
They could pull the cord. And then this would kick off this process of like, why was it pulled, what happened? What went wrong? And so, when it comes to emotional safety and these sort of pieces of maintenance, I think every organization should have that Andon Cord baiscally. Regardless of whether it's the intern or the junior developer, who you might say, doesn't have as much experience with things.

[00:04:24]
If they feel there's a concern with the way things are being done, it's like the environment we wanna create a safe enough that anyone can bring that up. Because a lot of times it's the people who haven't been immersed in the process for so long, that often can get a sense of like maybe things could be better.

[00:04:40]
And so, that's why I was wanting to introduce this is because. As we think of tech culture is going forward, right? We talk a lot about different sort of like things to consider, when you're building production level view apps. But I think we all know that at the end of the day, what makes something production level and scale over time is a lot of times that, that culture that allows things to grow and whether it's new features, exploring new ideas, beyond JavaScript frameworks and those things.

[00:05:12]
And so, as all of you, for those of you who are watching. As you're thinking about growing in your career as senior developers, and how you can continue to build applications not only scale, but again, grow the team as well, these are principles I think that are often overlooked.

[00:05:32]
And it's because at the end of the day, it's not the one technique you use in view, right? It's not cause you figured out how to use scope slots, or that you figured out this one technique that's ultimately gonna make the difference. In the long term longevity of an application, or basically engineering culture.