Drawing from this post, five ways to get 10x:
(1) Don't write the thing in C/C++ because there memory leaks, especially in the case of exceptional conditions, are too darned easy to make. So, use some 'managed memory': Either write it yourself or get it from Java, .NET, or some such.
If you write the memory management yourself, then put in extra code to do the work twice two different ways and compare and put in code to analyze allocated memory, separately for each way of doing the work, well enough to know where the heck all the allocated memory came from and don't have leaks.
For a crucial part of some of my code, I coded it three quite different ways, ran them all, and checked them all against each other. In my production code, I'm still doing that calculation with two of the different ways checked against each other. Want at LEAST both belt and suspenders.
(2) Moreover, testing for memory leaks or other bugs in the case of exceptional conditions can be TOUGH. So, design the code so that can be quite sure don't have problems. To do this, keep it SIMPLE so that can do good desk checking. Use some well tested 'architectural components' instead of writing just lines and lines of unique code. Design the code to be easy to test. Test the heck out of it. Pretend your worst enemy wrote the code and TRY to find things wrong with it.
Document the code very explicitly on just what the heck the code is to do. Document also the obvious and the trivial. In this documentation, pay close attention to the 'corner' cases. Then in the code, for each corner case, carefully desk check the code to confirm that the corner case is handled appropriately and DOCUMENT the check. Then test the heck out of the corner cases.
E.g., if write a sort routine to sort an array, make SURE that the routine works correctly when the number of components in the array is 0, 1, and the largest integer. Then, in the case of the largest integer, make SURE that the indexing arithmetic does NOT overflow. Document all this and then test it.
(3) Many cores and, thus, often, many threads are coming quickly. Then many new, nasty bugs are also coming. Many threads WITH exceptional conditions promise new levels of nastiness. So, borrow from (2): Don't just write 'code' that appears to solve the problem. Instead, stay SIMPLE and make heavy use of solid components. It would be good if the component usage had some logical properties on which could base proofs of correctness.
(4) Divide and conquer. Just do NOT permit code to go on and on. Instead, break the architecture and the code design into relatively small, independent pieces easy to check separately.
(5) Have the code well 'instrumented', that is, report various relevant internal 'metrics', in real time. Then do some 'statistical hypothesis tests' on this data to detect ASAP the anomaly, e.g., the memory leak after the network exceptional condition. Then return to the code and, near the exceptional condition handling code, turn on MUCH more instrumentation and pray for another network problem or just inject one. In this way, narrow down the cause of the problem.
How to do the statistics? It ain't in the books! The techniques are beyond essentially all of academic computer science. So, chalk up maybe 100x right there!
Such thinking can work for projects up to about 50,000 lines of code. For a larger project, ask someone else!
The 10x is not really from typing 10x faster!
So, get 10x not just by typing the same lines 10 times faster but by typing different lines with some significant differences in the design and maybe the architecture of the software.