Whenever I’ve approached a new system the bottleneck has never been writing more code. The bottleneck has always been in understanding all the implicit assumptions baked into the system that for one reason or another are essential to its correctness. Pretending that the system and the runtime traces of the system are the specification is why there is always a shortage of programmers. It takes a particular kind of masochist to enjoy reverse engineering a black box from just poking at it with simple linear impulses. If these systems had more formal foundations then there would be no shortage because we could teach people the general formalism and let them figure out the runtime mappings.

“I think that is a huge part, a fundamental part, of my job. When you’re talking about the future, and as a designer that’s where my head is, then it’s extremely rare that I feel that I’m working in response to an articulated problem. "I could count the occasions that I’ve done that in the last 25 years on the fingers of one hand. It’s extremely rare that what we do is a response to somebody articulating a problem. By definition, you didn’t know it was a problem until you were aware of a better way of doing it. The tremendous challenge here is that when you have been solving a problem a certain way for a long time, so many things convince you that, of course, that’s the best way of doing it, not least habit. "When you have been solving a problem a certain way for a long time, the very idea that there could be a better way of doing it, can seem almost sacrilegious. It can seem extremely unlikely, so what you have to do is work by taking a leap of faith. That faith is based on the thought, ‘I’ve been here many times before and many times before we have found a better way of doing this’. And you just have to believe that’s the case and you keep on. "Sometimes, the vast majority of times, we are able to find a better way of solving a problem.”

add tests to your application that ensure the major invariants of your infrastructure.

Try to avoid human judgement whenever possible outside of the application domain. When working on an application we have to understand the business, but not every engineer in your organization can and will understand how code splitting works. And they don’t need to do that. Try to introduce these thing into your application in a way that is fine when not everybody understands them and keeps the complexity in their heads.