I remember when I was much younger and I first started programming, it was such an exciting thing to do. I mean nowadays I think of it as normal, but back then it was so unique, so unlike anything else I ever did. I wasn't too good at it, I'm not terribly gifted at coding to begin with. And I didn't do *that* much of it either, there were always distractions in the form of games, later internet forums and whatnot.
But it was fun to *create* something and I certainly tried a bunch of times back in high school, we even had sort of a club for it. I remember that I always wanted to create something brilliant, something really awesome. And I didn't know the first thing about it, I was clueless. So I would just sit down and start coding. Whatever came to mind that had to be done as part of my project, I started out with that. A program that encrypts files (encryption, that was a favorite theme back then)? Ok, I need to read the file first. So I would code that to begin with, reading the contents of a file, I didn't think any further at all. Then once I did that, I would start thinking what do I need next. And so on. So working in that fashion, it's no big surprise that my code wasn't of the highest standard. I didn't read any books either, I just searched for code examples and I used the help files for the IDE. (Borland Pascal had a really great integrated api doc, very handy.)
So when I started computer science in college, that was all I knew about coding. Basically just trying to put an idea into code, however it was done, just as long as it worked. And didn't take too long to do it. And didn't crash. Mission accomplished. And we did a couple of those missions, most never got completed, cause we didn't know how, some worked just fine, which was a great satisfaction, but ultimately we didn't solve too many problems doing it.
I recall that the concept of "something awesome" intuitively was that great piece of inspiration. I knew intuitively that I wanted my code to be as good as it could be, as organized and structured and all that. But I didn't know _anything_ about how it *should* be done. I didn't know any theory, any principles, guidelines, practices. I sorta started from scratch. So college really changed that point of view, I learnt what developing systems means, what it entails, what people actually do, and how. But then I had assignments and again I would try to write that great piece of code, which I had no idea how it would even be determined to be good or bad.
My concept of great programming was that good idea. It's a bit like a painter would rig up a new canvas and just sit there waiting for inspiration. How do I paint a masterpiece? I just wait for that amazing, great idea to come along. I will not settle for mediocre ones, I will ignore them, I won't compromise on this. And when that briliant idea comes to me, I'll use it and I'll paint a masterpiece. That's how I thought I could write something awesome. This, of course, is the Big Design Upfront mentality, with pretty much the worst possible starting point (ie. complete ignorance and zero experience) for actually designing something good. But I really didn't understand anything about modularity. I would think to myself that "this encryption bit should be exported to a separate file", but I had no clue about how it should be interfaced, what logic it should and shouldn't have, only that it should be separate because that "seems like a good idea". I would start a lot and end up nowhere, just fumbling in the dark.
When I did have some "great idea" about how to solve some problem, it was always rather complicated. I had such faith in my scheme. I was confident that beside solving the basic problem, I also solved other issues that other people "probably wouldn't have thought about". My first assignments in college were all like that, based on some idea of how to improve upon the "bare minimum" by making things more complicated than they had to be. And it would obscure the issue, because there was lots of unnecessary additional logic in it. I was disheartened, time after time, to learn that the simplest way of doing something was much simpler than what I had devised. But because I had this attitude, I felt it was a great achievement to write all that code.
Gradually, partly in college and partly on my own - reading articles, watching interviews and talks - I began to see how it actually works. And of course it's nothing like what I just described. For a long time, my biggest problem was not knowing where to start, what bits I would have to create. It would just seem that I had to follow that one thread of thinking, something I needed, and then take it from there. Years on, after I've been through quite a few projects, the reality of development is starting to approximate the theory that I learnt about how it's supposed to be.
I've done enough of this now to design a system, to see what the components should be, to consider different variants and see what the tradeoffs are. Nowadays I don't even start coding until I have a good mental picture of how it's going to work. And what wonderful things can be achieved with modular coding, now I actually see how separate pieces should be divided. They can be classes (in object oriented world), they can be just modules exporting functions (python, c etc.), they can be higher order functions (functional programming) and so on. But I understand how an API works, how it's meant to work.
Nowadays, I'm much more likely to find the simplest solution in the beginning. And if I don't I try to iterate my code to reach it. One basic theory about how to manage programmers is that they have great pride in their code and everyone wants their code to be in the final product. So if you remove their code because it's not necessary, they get mad. And I'm sure that's true. But, on the way to finding the optimal solution, the more code I can remove the happier I will be. Often the simplest solution is 2-3x less code than what I started out with. It's really just a matter of expressing ideas in a very clear way. When the mind is terribly foggy, that's a huge problem.
It is such a huge shift in thinking. Coding isn't some impulsive, ingenious spur of the moment scheme, it's a well defined, highly organized, methodical way of building solutions. So when I look back at how I used to think about the subject, I'm almost amazed that I had so little natural intuition about the subject, I really had no idea what it's like.
Peter Norvig said "Teach Yourself Programming in Ten Years". It's been about ten years since I started out. And I feel I'm well grounded in the basics now. Like a formula 1 driver knowing that he can start his car without choking the engine 9 times out of 10.
August 19th, 2006
