Last night I posed the question “what code should I be reading to become a better .NET developer”? Frans Bouma answered (to paraphrase) “probably none, you should be learning about algorithms instead”. I’ve thought about what Frans suggested all day, and I’m not convinced that working towards being a better programmer by studying algorithms is the best way (well, not for me right now). Algorithms are certainly important, and the TOC of the book Frans suggested seems to have quite a few interesting items, but there seem to be so many things that interest me, and which I think contribute to good quality code, that algorithms are not concerned with. Things like coupling, cohesion, API and library design, patterns, the use of interfaces and inheritance, type size, testability and code documentation. Techniques for managing complexity don’t seem to have a great deal of overlap with “big-O” notation. Maybe reading the source code for larger code-bases will not help here either, I’m not sure. I will add the book Frans suggested to the stack when I can track it down. I’ll post a follow up when I’ve read it and can be more objective.
Comments
My production code did not really look like the algorithm I was re-producing. I realized that while I could write commercial everyday code, thinking and coding in an algorithmic fashion was a completely different story.
I am now beta testing my translation of APriori Market Based Analysis Algorithm to a C# Component and I feel a lot better about my ability to create working models of algorithms.
Has it made me a beter developer, in my opinion, YES.
Look at Google, take a peek under the hood, what do you see?
The first read was a nightmare, i did not understand anything, anyway because the project was demanding i did not give up. I did read it about 20 times (i am not a very clever person) and writing test/sample code (where is E&C when you need it?) for a week or so, when i finished i did some optimizations mainly for readability. The resulting code was just one page! (to be exact it was two nested loops and four or five conditional summaries ). Why did the original author describe it in 12 pages full of S(?,?)/S… ?
This chasm between "applied" mathematics and pure programming is imho the main reason what keeps software still in its infancy.
Algorithm and patterns are about basic code writing, I will never forget the recognizing of patterns I still used before reading GoF without even knowing the term for.
Books like the "pragmatic programmer" are about programmers habits. It will help you to decide which parts of your code smells and why.
Examples and reading code can’t really replace self doing. I have learned from my mistakes, there is no better teacher.
Are you unlucky with your own work, in particular m3rlin? Why? Does anybody tell you that something is missing or doesn’t work?
No? Great. I didn’t find anything I had to remove to use it in my project.
It fullfill YAGNI - and if you or I feel that something important is missing, we will expand your project, won’t we?
If I write a generator for an algorithm, are you then interested in how the code looks like? If you answer ‘yes’, do you also look at every IL the C# compiler generates for you? If you answer ‘yes’, do you also peek at the x86 asm the JIT produces when running your IL? I bet you don’t. :) And the reason why you don’t do that is probably (likely): because I trust the JIT for being efficient. Why? Because it produces A’ on input A. And B’ on input B. So what’s important is the input, not the result. The input in your software is the algorithm, the design, not the code. The code is the output.
Perhaps I wasn’t clear enough, but what I meant to say was: if you want to learn something, read the algorithm, then try to implement it and check if you’ve done it correctly. If you become very good at translating algorithms to code, you are generations ahead of any developer who thinks in code-constructs. The reason? in about 5 years more and more is done by abstract designers instead of hammering out raw code. However what stays the same is the theory that’s the foundation of what you’re producing.
You see the same with patterns: some people think patterns are holy grails and think in implementations of patterns. The biggest mistake you can make. If you don’t grasp the FULL theory behind a pattern, you’re doomed to use it in an anti-pattern scenario. Furthermore, once you understand the theory behind a pattern, you don’t need the pattern. The theory becomes a generic building block for writing/designing software.
ps: the sedgewick book was an example. There are more algorithm books, also pattern books. It’s about the theory, not the implementation, that’s tic-tac-toe after a couple of times.