|
|
|
|
|
by nostrademons
5129 days ago
|
|
Point 2 is something I've heard Jeff Dean strongly suggest. Write microbenchmarks for all the basic operations of the "black boxes" you'll be using to build the system. That way, you can do quick back-of-the-envelope calculations to estimate the performance of the system before actually building it. You can explore the problem space much more quickly when you can simulate the important characteristics in your head instead of having to actually type them out into an editor. Point 5 is something my former manager once told me. He'd done RoboGames or something like that as a grad student, and he found that invariably, the teams that won were the ones who had built the best debugging infrastructure into their robot, so that when it didn't behave as expected, they knew exactly what was wrong. This is as much a property of the program as of the programmer. The best programs usually have debug information built into the structure of the program itself, along with an easy UI for viewing that debug info so you don't have to stare at log lines all day. Once a couple programmers start doing this and everyone else realizes how much time it saves, it becomes part of the culture of the organization, and everybody starts designing programs with an eye toward "Will I be able to figure out what's wrong if this doesn't work?" |
|