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.