Writing encryption algorithms as a weekend project should generally be approached in the same way as one might approach writing aircraft control code as a weekend project:
Never use it, never distribute it in a way that someone else might mistakenly think it's a good idea to use it (so posting it on github would probably be a mistake!) and expect your implementation to have bugs you don't realize. (Even if you shove plaintext in and get the right ciphertext out doesn't mean you've found all the bugs, it gets tricky and in some cases different specific algorithmically correct implementations can have not just different performance characteristics, but different runtime security characteristics.)
Most people tend to find weekend projects more fulfilling if they have a way to put them to use. So while I don't mean to go all "this is dark arts that no one should practice uninitiated" on you, I would encourage you to stifle your tendency to find a use for any encryption code you write that isn't peer reviewed. View it as purely an artform; code never to be utilized.
This is the same advice most security researchers give to themselves and others.
I was strictly confining my comments to the implementation the poster was discussing coding up in a weekend.
The Rijndael algorithm itself is of course, very well reviewed and perhaps one of the most solid algorithms publicly available. Which is part of why it was chosen for AES. (Speed being the other factor.)
I think perhaps you misunderstood the conversation.
Algorithm design is for the math people, implementation requires a form of paranoia combined with detailed knowledge about CPUs. In many, if not all, cases you will have to look at the assembly that your compiler produces to make sure that an implementation is safe against attacks that look at the timing of calls, their cache misses that affect timing of code on other CPUs, etc. .
No, not really. The most complex math AES uses is operations in the finite field GF(256). Given that addition in a power-of-2 finite field is simply XOR, I expect any good programmer to be able to get AES.
On step 4, AddRoundKey, shouldn't e5+17 be fc, not f2? Or is AES using something other than simple 8-bit modular arithmetic? It looks like the author did the arithmetic in his/her head, and accidentally used decimal for the second digit (5 + 7 = 12, mod 10 = 2).
That's what I get for learning programming years before entering college. I forget standard mathematical notation, since I always use programming language operators (like ^) in my head. Further, I only checked the first row to make sure it was actual addition, and obviously 0xa0 + 0x04 == 0xa0 ^ 0x04.