Sunday, February 8, 2015

Build something new every time

When you work on a project, think, "How can I create something so that I never have to re-write this same program again?"

For example, say you are asked to setup a process that retrieves a file from a ftp site, reads the file and updates a database. Instead of writing something that just does the job, you should try to write a generic ftp retriever, a generic file reader, and a generic database updater.

Then you data-drive every piece of the process to deliver a solution for this specific problem. When you need to work on a new (yet similar) project in the future, you just have to change the configuration and data-drive your next process.

If you follow this practice, things may initially take longer to get done. It's much harder to write generic code. It's possible that you'll never reuse this generic code again, which means you wasted your time. But I think it's more likely that if you needed to do something once, you'll need to do it again.

So, you may or may not be more productive. But I think you'd in general be happier, because writing new programs is good for you. It will force you to think and learn. You won't get bored by the tedium of doing the same thing over and over and over again ...

I guess what I am getting at is simplay another way of saying keep things DRY, and save your key strokes for something new.

Monday, February 2, 2015

The Clueless Programmer

When you start programming, you write or copy code, and there's no way you can understand how it works. You just have to accept and hope that some other programmer put enough time and energy into the language that the text you plopped into the editor will somehow magically work.

Over time, you learn more and more, and after some tipping point you begin to understand most of what you type. In the least, you can describe what would happen to your program if you modified any given line of code. So, you get to the point where you are code literate.

Being a semi-literate coder will only take you so far. At some point, you want your code to do more. You want it to perform faster, with less resources. You want it to be clear, concise, and understandable. You want to reuse it for other applications.

So you start asking yourself low level questions like "which smart pointer should I use and should I be passing it by reference?", and head in the clouds philosophical things like "who should really own this object"? Through these questions, you realize that there's a lot that you don't know.

And so, you find yourself in a familiar place, thinking that there's no way you can understand how it all works.

Lucky for you, you've been here before.