Managing Angular · Minko Gechev's blog
Over the past couple of years, I’ve been the product lead for Angular. In this article, I’d like to share how we’ve been managing the framework. Keep in mind this content lives on my personal blog for a reason - it represents my point of view and doesn’t share a complete picture of all the processes within the team, such as people management, program management, etc. Also, that’s the second time I’m writing this article. The first time, I wanted to be as descriptive as possible and stopped writing at about thirty pages, after which I deleted the content and decided to start over. Today, I’ll keep it short with the caveat that I’ll skip some important details and keep it on a high level.
When I think of building a product, I often see it as a sequence of small steps that reach a certain global maximum. The global maximum represents the perfect product we want to build. The global maximum is a myth, though. You can think about it as a form in Plato’s Theory of Forms - there’s a perfect product that we’re aiming to approximate in the real world. To get there, we can either try to build the perfect thing with a single shot or approach the problem iteratively.
In engineering, there’s often this myth of the genius programmer. These 10x coders open their laptops and don’t talk to anyone; they just write code for a couple of years, and the result is the perfect product that everyone wants to use. The real world doesn’t always work this way, especially if we want to grow and keep a product reliable and stable over time. Software is complex and is built by teams. Team members need to communicate with each other. In addition to that, we’re building software for our customers. If we don’t talk to them, our vision will quickly become obsolete. By the time we’re done, the market will have changed; thus, this perfect product will look different.
