There are many choices that must be made during the coding process and how we arrive at those choices is important and can influence our thinking and code quality a great deal. I try to make a concentrated effort to put thought behind each of my choices and be able to explain them to myself at least and secondly to others. I keep a critical eye on my code and try my best to ask hard questions about the validity of choices in the code at all times. This kind of questioning attitude doesn’t fly well in certain circles but it’s how I was raised and I currently don’t have a good reason to turn away from it. I’m still working on how I go about communicating these ideas and encourage productive debate with others. That tends to be the most difficult part.
When I was first starting out in my career I relied a lot on the wisdom of my mentors and peers. This wasn’t a bad descision at all, learning by walking a path made by others is often the easiest way. There were certainly times when I went against the common wisdom and even if it was a dead-end, I still learned a great deal. As a newbie I spent a lot of time in ‘the shop’ trying out one new idea after another. I quickly found that once the first summit is mounted things take on a different look and one must plan their own ascent carefully.
I’m writing this post because I’m tending to forget the why behind some of the choices that I’ve made over the years in style and approach that have become habit over the years. Even though I feel that I’m well into my ascent I still find myself revisiting choices and thinking, ‘now why do I do that?’.
One small thing that just caught my attention is my habit of starting method names with an upper-case. I usually tend to do this more frequently in true object-oriented languages, Java (alghough doing this breaks standard), C#, Ruby, Python and C++ (not even in the same class of OO-ness, still there it is).
The reason that I codified this personal standard is so that I would tend to think of methods more as first class citizens in the object space. When naming methods with a lowercase they tend to be thought of more as values, parts or fields. In fact they are much more, you can think of them as classes of your program space, passing them around, storing them and transmitting them and giving them a proper name more easily promotes the semantics of this type of coding in an environment where usually only classes are capitalized. This was an early descision I made not because of style but to form a habit of something which would form a useful mental model.
Another habit which is more of a constant discipline is minimalization of all code that I create. This has absolutely nothing to do with KLOC or anything silly of that nature, in fact it runs contrary to anyone brought up in that type of coding culture.
As you ascend higher, oxygen becomes more scarce and harder to breath. You will find that code takes on a life of it’s own, sometimes spending more energy is a less effecient way to treach the top.
The code must be minimally specified, it must do what it says and no more. There are some general rules, avoid over branching, tend towards shorter code bodies. Whitespace and comments are more telling than the code they surround. On a larger scale prefer loose coupling and composition over strong interfaces and inheritance. Do not be scared of creating a small library. Prefer pull over push.
The last bit I wanted to write may be a bit controversial with some but I find that when presented two paths, one steep, rocky and trecherous and the other wide, mellow and gradual I always prefer the former. Personally in the long term I would rather look back on a lot of hard problems that were overcome it is much more satisfying for me personally and prepares me for even more technical challenges ahead.