Personal vs Professional

It's been a while since I've posted here... and quite a few things have changed since then.

From a professional standpoint, the biggest change was that I switched jobs.
Why? Well, although I experienced great amounts of frustration at my previous job, there was an element of convenience there that suited my purposes - the working hours were predictable, the work itself was not too difficult, if not exciting, and it was close to home so I didn't face a commute. It seems like pretty shallow reasons to stick around at a job, but I was in the last year of my degree programme, and had a large project to finish. That job afforded me the time to get my work done, and after 3+ years of investing time in that degree, I didn't want to mess it up by not being able to complete my project.

Unfortunately, although the job was 'convenient', that convenience had a price in frustration that I was just unwilling to pay anymore - it just became too much.

And so I switched jobs.

I joined an American consulting company that was building up an office locally - a version of outsourcing that short-circuited a lot of the difficulties with outsourcing to India - the time difference, the culture and language barriers etc.

It was an eye-opening experience to go from a place where software development was seen as an after-thought to a company where they really 'got it'. Code reviews, technical design documents, tons of whiteboard space, a cupboard full of snacks.... These people really GOT IT!!

So I joined up in February, and for two months, I didn't work a single day.... after all, you couldn't call that 'work'. This was much too much fun to be 'work'. 'Work' is something to avoid and dread, right?

Unfortunately, such ecstasy didn't last.

The sad thing about the situation is that I still feel that this place is a cool place to work. I still think that more times than not, we aren't doing 'work'... we're just doing what we love, and getting paid in the process.

But, the honest truth is that the hours started to become noticeably longer. I'm not sure that things changed that much over the 8 months I've been here, but as more and more of my life disappeared between 'being at work, commuting to and from work', and 'doing work on evenings at home and on weekends', frustration started to set in. Adding to the frustration is that I am getting married next year, and preparation time was quickly slipping away - and things weren't getting any better.

So, I had to make a hard decision - one that wasn't easy, but I believe it was the right one. I decided to step away from that company - back to something that is a little more predictable, and a little less demanding.

Am I making the right choice?
One of my bosses does not think so. "I'm bailing out and passing up a great opportunity".

But, others weren't so extreme. "Each person has to do what's right for them." A fair statement. Simple, yet surprisingly profound if you really stop to consider it.

But, maybe the best advice was: "Two things must never come before 'job' - your health, and your family."

And that's how I feel. I believe that with these time commitments, it's going to be ridiculously hard to find the time to plan and prepare for a wedding. And, quite frankly, even though a wedding is only 'one day', it's a day of great significance to my bride-to-be, and hence, it's a day of great significance to me. She has been quite understanding of my work and career commitments, waiting patiently for 4 years for me to complete my degree. But she is understandably impatient to begin the next stage of our journey together, and quite frankly, so am I.


Am I a fool for making a career choice based on personal reasons? Maybe. But I'd rather be a happily married fool than a single (and lonely) success.

But that's just me.

There's more to the story, of course.... but that's for another time.

It's My Fault

There's a natural human tendency for people to want to assign blame when something goes awry. In particular, when assigned to messy code, programmers tend to blame management for not giving them the time to clean it up before being forced to work with it. At least, I am guilty of this.

But thinking about it seriously, I came to a (seemingly) obvious conclusion. I am wrong to assign blame to management. This not to say that their feature demands are reasonable given the current state of the code base. I am wrong because the quality of the code base is my responsibility. It does not matter that I was not the one to create the mess in the first place... it is my domain, and hence, my responsibility.

I should not 'ask for time' to clean up the code before proceeding on the new feature requests. The messy code is a direct hindrance to me completing my job and as such, it is my responsibility to remove that hindrance before proceeding. In essence, I don't ask for 'permission' or 'time' to clean up the code. I clean up the code before I start adding to it. Period.

That's not to say that refactoring code comes in the way of bug-fixing and feature additions. That's not to say I am some renegade who refuses to conform to the will of management. It's just the realization that management does not care about the quality of the code - they care about removal of bugs and enhancements to the system. How those things are accomplished is my job. Trying to convince them of the best way to do my job is foolish on my part, especially since they cannot appreciate the importance of code quality when it comes to modification. That's no weakness on their part... it's not their job to appreciate code quality. It's mine because I know the effect that the lack of said quality can have on the ability to do my job.

That's not to say that I plan to go guns-blazing and rewrite anything that looks sloppy. But, whenever tasked with a maintenance issue, my first step will quietly but assuredly be to clean up that area before I begin handling that issue.

It seems pretty obvious when stated like that, doesn't it? So where's the epiphany?

There's none, really - except for the sad realisation that I was taking on a battle with management over code quality that served no purpose except to handicap and frustrate me. At least I have learned my lesson, which will help me in the future.

Operational Complexity

I was reading a blog post by Paul Homer discussing complexity and containing it via encapsulation.

One important part that may be overlooked in his discussion is talking about the different types of complexity: design, implementation and operation.

The complexities of design, implementation and operation are very different from each other. I've seen a few large projects that have managed to contain the implementation complexity, only to lose it all by allowing the operational complexity to get out of hand. Each part in the process requires its own understanding to control its own special complexity. Each part has its own way of encapsulating the details.

We, as programmers, can understand design complexity - our job constantly puts use in battle against it, trying to keep it under control. Similarly, implementation complexity is usually tied to code complexity, and hence we recognise the risks and dangers of ignoring such complexity, and (hopefully), move to remove it.

However, I believe operational complexity to be completely ignored as a source of problems, which can be just as dangerous.

From my own personal experience, on joining a new programming team, and getting help from the version control manager in getting set up with the version control system, I was told "NOT TO WORK OUT OF THE WORKING DIRECTORY". That really put me on pause.
Don't work out of the working directory? Isn't that why they call it a working directory? Because you work out of it?

No, she told me. You might accidentally retrieve something from the version control system and overwrite, and hence lose what work you are currently doing.

Then, she proceeded to show me a round-about procedure of interacting with the version control system without actually working out of the working directory. (This 'procedure' involved copying stuff from one place to another, making your changes and copying them back). I was skeptical, not wanting to rock the boat, I fell inline. After all, things were always done that way.

However, after a few months of jumping through hoops just to check in my changes and losing some of those changes along the way, I had enough. The operational complexity was making life too difficult.

It turns out that the risk of losing code changes while working out of the working directory was real... because the settings in the version control client were off.

Now, a check-in, something that used to be a 10 minute affair of copy-pasting and diff-ing a number of files, is now a 20 second, stress-free affair, as it should be.

The Great Static vs Dynamic Language Debate

I was looking over some of the archives of Bruce Eckel a while ago and came across his Static vs Dynamic post comparing the two types of languages.

Again and again, the argument about Static vs Dynamic languages seems to devolve into an argument about finger typing: whether not declaring types is worth the loss of the safety net of compiler checking. This argument seems to originate particularly from the 'Static' camp since from their point of view, the real difference between static and dynamic languages is the lack of type declarations.

The sad thing is that the Static camp's focus on the argument that 'reducing the amount of typing is not worth the loss of compiler checking' always seems to coerce the dynamic language crowd into the argument that type declarations really aren't needed.

I think that is missing the whole point.

It's true that many claim that dynamic languages help reduce the amount of code you have to write to get a particular problem solved. However, this reduction in code is not because of the lack of type declarations. It's because more time than not, dynamic languages provide the programmer with more powerful abstraction techniques. From the point of view of the dynamic language 'weenies', the problem with Java (and its evil twin C#) isn't that you are forced to declare types. It's that the type system hinders your ability to create more powerful abstractions. Code blocks and list continuations and the like don't seem to be possible using the type system of these so-called static languages.

And, the fact is, that power doesn't simply come from dropping the static type system. As an example, Coldfusion is a dynamic language in the sense that you do not need type declarations. However, it sucks at creating abstractions. Thus, it isn't considered under the 'dynamic language' umbrella, even though, based on the 'Java crowd' definition of dynamic languages, it should be.

The sad thing about the whole argument is that the Java evangelists seem to forget an important point. Many of the more prominent Java developers made the switch to Ruby and Python based on first-hand experience. Although they 'knew' Java's compile-time type checking was too important to give up, their actual experience using these dynamic languages showed them to be much more productive outside of the restrictive shell that Java's type system enforces.

I guess my plea, although it may fall on deaf ears, is to simply try to code something significant in Python. Do a project using Ruby. And truly use it. Don't code Java in Ruby/Python. Try to leverage the power that the language provides. Try it yourself on just one project, and make a judgment call on real experience. And see for yourself how better abstraction capabilities lead to a better coding experience.

The Ills of Procrastination

Sometimes, procrastination can really suck your life out.

I'm sitting here trying to motivate myself to do SOMETHING, but no go. I have a bunch of work to do, but nothing doing... my brain is frozen.

I guess that happens to the best of us.


It's also the reason why I think working 'regular hours' can totally suck from a productivity standpoint. I typically work from home rather than the office, and on a day like this, if I were home, I'd just go and take a nap or relax in some way, and get to work later in the night. Of course, that luxury isn't available when at the office. You just can't 'do something else'.

So, instead, I sit here, and try to beat off the procrastination. Unfortunately it is beating back. And it hits much harder.

Converting Ruby to Java

I readily admit that my previous post about the lack of distinguishable efficiency between Ruby and Java was absolutely off-base. Completely.

I'm still working on that same simulation program that I described yesterday. Why? Although I designed the program using Ruby, I need to provide the source code in Java. I always knew this, my thought process was that I would try out the development process using Ruby, and then port the program to Java once I was completed. Which is what I attempted to do last night. Which was another 'eye-opening' experience.

It seems that my current lack of Java exposure has numbed me to the amount of cruft in a typical Java program. I started the port fairly straightforwardly... copy the Ruby code into a Java class, and change the various Ruby-specific keywords to their Java equivalents, and that should be it.

So, I begin to change def to public void/int/boolean, end to }, and removing the @ and : from instance variables and symbols respectively.

It was then I began to realise how much visual clutter Java forces on you. I needed to put the opening brace after every method definition. I needed to add opening and closing parentheses to all my method definitions AND function calls. And don't forget the dear old semi-colon after every line. Nope, we can't use the if/while/unless statement modifiers, so every one of those becomes a full-blown if statement block, complete with all its brace-y goodness.

Just making all the syntax changes was an experience... by the time I was done, my code was noticeably longer, and just seemed much more like code and less readable as a result.

But, the difference between Java and Ruby goes beyond syntax. So, the stage two of the conversion involved changing constructs such as blocks, array sorting, use of hashes etc to Java equivalents. And there was where the true differences between the languages surfaced. You see,he language you use does influence your coding style, by making certain things easier to do. Thus, the natural syntax of hashes make them extremely popular, as Rails can attest to. Of course, the Java equivalent is a huge pile of clunkiness that I don't even want to think about.

The end result is that after the straightforward conversion of standard syntax differences, I actually had to then rewrite logic for the Java version because of its lack of certain Ruby functionality.

That is to be expected, right? I mean, they are different languages after all. Some things will be easier in Ruby than in Java and vice versa, right?

Of course, so far, I've only come across things that are harder in Java than in Ruby. I've yet to find something that Java does better.....

Hmm....


PS. What has me particularly cranky is the fact that in converting some of the Ruby constructs to Java, I broke something, and I'm having a hard time figuring out what. And it's annoying me that I have to go through the same debugging process again in Java that I went through in Ruby....

Programming in Ruby

It's been a while since I've been here.... I know...

Work's been pretty hectic these last few months, and it continues to be so, but I've come to realise that you just have to make time for the things you want to do... because there will ALWAYS be things to do.


I did spend the last week working hard at a computer simulation program for my sister. It's a computer simulation of a networking link, which is actually not really relevant. The key point is that it was a fairly straightforward program... a school project-type thing, which is indicative of the scope. That is, it was a small and straightforward program.

Because of time constraints, and also because I wanted to increase my learning, I developed the program using Ruby... my first test run of Ruby development without Rails.

And I must say, it was an interesting experience.

First, the negative....

There is much talk in the Ruby space about how dynamic languages save you from having to deal with the boilerplate code that is common with static languages (i.e. variable declarations, interfaces et al).

That is very much true. However, what those dynamic language gurus fail to point out is that much of this boilerplate can be provided by the IDE. Granted, it is still visual clutter, but the actual typing is minimized. In fact, that was my biggest gripe with working in Ruby... the comparable lack of help from the IDE. Context sensitive hints are much less effective and focused in the dynamic space, which can actually make you slower compared to Java and its pals.

And of course, the automated refactoring support is much less robust, which means back to manual refactoring. Of course, the fact is that the amount of refactoring that needs to get done is much less, but when you do need an "Extract Method" command, you do miss it.

There is one benefit to the lack of variable type declarations that is not mentioned very often though....

Because a variable can hold anything, it makes variable naming extremely important. You can't infer anything from the variable type, so as the developer, the variable names have to contain all the relevant info... which makes you as the developer much more conscientious about choosing proper variable names to portray all the necessary information. This is especially important in function signatures.


Overall though, the experience was quite pleasant. For the most part, the language did stay out of my way and allowed me to think in the domain rather than in the language. And, the open class structure did prove to be useful as well (I monkeypatched the Symbol class to allow sorting of symbols with minimal effort).

I think those two are the more important features that make Ruby such a pleasant experience: - the well-thought-out standard API, and
- the open classes to enhance any standard class when it doesn't quite fit your needs.


All in all, I think Ruby will be a valuable addition to my toolkit... and is definitely a language worth exploring even outside of the magic that is Rails.