Coming from a strong C background and now working mainly as an architect closely with devs in c# I bemoan their lack of understanding of how memory, SQL, caches or networks really work. If you are making highly scalable systems (as we are) it is important to understand how a single line of linq can cause major memory churn, or that entity framework is terrible at certain things or the fact network latency matters, or your fancy cache is actually making it run slower. The key is to measure everything using something like statsd and graphite/grafana. Then poor performing code will clearly show up and the devs learn the error of their ways and improve. We all need to keep learning, don't just blindly rely on some new fancy framework to solve issues; think about it and become better
Slashdot Mirror
Coming from a strong C background and now working mainly as an architect closely with devs in c# I bemoan their lack of understanding of how memory, SQL, caches or networks really work. If you are making highly scalable systems (as we are) it is important to understand how a single line of linq can cause major memory churn, or that entity framework is terrible at certain things or the fact network latency matters, or your fancy cache is actually making it run slower. The key is to measure everything using something like statsd and graphite/grafana. Then poor performing code will clearly show up and the devs learn the error of their ways and improve. We all need to keep learning, don't just blindly rely on some new fancy framework to solve issues; think about it and become better