Life Software Engineering

Engineering Parenthood

Parenthood and software engineering share at least a couple of similarities. Most software engineers can relate to the experience of a project that seemingly has no end, with problems for which you cannot see the solution at the outset but which you nevertheless must solve. But when you are a new parent it is suddenly like you have two jobs with twice the demands. You cannot shortchange your child with regards to time, effort or inspiration and neither can you simply phone it in at work. Putting in the minimum effort is not why anyone sane gets into the business of writing software — we want to produce high-tech, shiny, cutting edge, cool stuff.

So therein lies the challenge: how does one keep the edges sharp when you’re sleep-deprived, juggling seriously conflicting priorities and pressed for time on all sides? I’m facing this situation now, but I don’t have an easy answer. I can only offer my guesses.

Time Management

One part of the solution is obviously time management. Maybe your time management practices are already ninja-level, but I’ve found that I need to tighten up my time management practices as much as possible, because I can no longer rely on burning the midnight oil to get me through difficult spots. That means automating as much as can be automated. It means allocating small, scheduled windows for distractions like reading random tech news on the Internet. It also means really prioritizing work and banging tasks out like a waiter in a restaurant — knowing what can be kept waiting briefly and what must be done NOW. There are all sorts of time management philosophies one can follow and tools you can use, but probably the most important thing to do is pick some method that works for you, and use it.

Cooperation

Improving your time management practices should help with handling the current set of tasks, but holding a line in the sand is never good enough with software. You must stay on top of emerging technologies, improve your skill set, experiment with different techniques, etc. In software engineering, as in many endeavors, to stand still is to become a fossil. Naturally, having a child puts your woodshedding discipline to a serious test.

If you’re lucky, the child will be a consistent sleeper and you can sneak in an hour here or there at night to get things done. You should exploit those opportunities when you can, but ultimately, you’re going to need the cooperation of your partner to make sure that you can get a chunk of time on some sort of semi-regular basis to do your extra-curricular coding. Undoubtedly you’ll need to reciprocate in kind. It is well worth it to work something out, because though one can get some things done in fits and starts, there’s no substitute for a several hour chunk of time when it comes to writing software and you’re not going to get that time without help.

Elbow Grease

The third point that I think is important is: have an extra-curricular project to work on. The main reason for this is that you need some focal point for your woodshedding efforts. You WILL have weeks when you get nothing done, when you have to put aside any extracurricular learning and development, and having a project will help you pick up the pieces when you regain some time. After all, you are a finisher by nature and you don’t like to leave projects undone (right?), so your instincts in that regard should help you follow through.

The project might revolve around some new technology you’re interested in, or a new problem domain you want to explore, or just an itch (a la Eric Raymond) that you need to scratch. Taking some training course that you can get your employer to foot the bill for is not a bad idea either. Pick something very manageable, because inevitably it will become a bigger deal than you think, and what you need now is a confidence builder, not a Herculean challenge.

The Blind Leading the Blind

So there you have it, those are my “secrets” to success. Quite obviously I’m new at this game. Perhaps I am naive and overly optimistic to think that I or anyone else can keep up the pace, but as the saying goes, shoot for the moon and maybe you’ll end up on a cloud.

Java

Ugly But Proud: the instanceof operator

Ah the unlovely instanceof operator — that poor cousin of the reflection API and redheaded stepchild of Java’s object-oriented programming model — does it have no friends in this world? Was it brought forth from the depths of James Gosling‘s mind only to instigate mass hackishness? If you’ve read almost any book on Java programming, you’ve no doubt been warned repeatedly that use of instanceof is a warning sign on the road to BAD OBJECT ORIENTED DESIGN. The accusation does have its merits. Abuse of instanceof can often be a lazy man’s stand-in for a more properly thought out use of polymorphism. But we should not be so hasty to throw stones at this humble and venerable Java language feature. instanceof is not evil, it’s simply misunderstood.

The type of example often used in warning young programmers away from instanceof goes something like this:

public void doSomething(MyClass obj) {
  if(obj instanceof MyClassDescendant1) {
    // take one path...
  } else if (obj instanceof MyClassDescendant2) {
    // take another path...
  } else if (obj instanceof MyClassDescendant3) {
    // take a third path...
  }
}

Clearly, if we had instead declared the doSomething() method as a member of MyClass and allowed subclasses to simply override the method as needed to specialize the behavior, then we could have the much cleaner:

// using a factory simply to illustrate that
// we don't know what the actual instance type is
MyClass obj = MyClassFactory().newMyClass();

// the appropriate subclass method is executed
obj.doSomething();

So one should avoid using instanceof to select behavior based on object type when polymorphism could do that in a much cleaner way. But if you’ve spent any time programming in Java, then you’ve seen that instanceof is commonly used. Often it’s abused, but sometimes it’s used with good reason. So, what are the guidelines for its proper use?

1. Use instanceof for parameter checking. For example, if you’re overriding Object.equals() in one of your own classes, a common first part of such a method is to write:

public MyClass {
  // ...
  public boolean equals(Object o1) {
    if(!(o1 instanceof MyClass)) {
      return false;
    }
    // rest of method...
  }
}

2. Use instanceof when you are obliged to program to an interface that involves objects typed as one of those empty “marker” interfaces as parameters. A perfect example can be found by looking at the javax.security.auth.callback.CallbackHandler interface. If you endeavor to implement this interface, you will quickly find yourself using instanceof, since the single parameter to the handle() method is an array of Callback objects, and Callback is an empty interface.

Projects

KeyStone v0.1 released

This is a first version, with a very functional, albeit limited, feature set. See the projects page for more information.