The more a developer gains experience, more mature his/her big picture of software architectures will be. Anyway, each single person has different attitudes and preferences and, at least, even his/her own specific problem setting mind model.
This is the most important value we can give to this beautiful job of software development, and it is probably the only aspect machines will never solve automatically. Understanding how to develop good applications and, generally, how to develop “smartly” takes precedence over the simple knowledge (even a deep one) of a language or a set of syntax specifications. As it was a spoken language, we can even know tons of words but the hardest thing (and the one that gives to the conversation the right appeal) is to mix them correctly to create elegant statements that will stay a long time in memory and communicate the right thing.
We believe C# is a great language, very much expressive and with a constant attention to the present technology. It deserves to be used extensively, from a small client application to the biggest enterprise distributed system.
In this blog post series, we do not provide the “best way” to approach a problem in C#, neither the optimal or the defects-free solution. We offer some alternatives to solve common problems, hoping that the reader, mixing all together, can reuse this knowledge to build the rocket.
As we are delivering the next posts of this series, we will update this simple outline here below: