Posted on

The interruptible programmer

A read a good blog post about learning to work interrupted.  Work 2.0 – the interruptible programmer.  The blogger had to learn to switch from a conventional, anti-interruption, get in ‘the mode’ then stay there for as many hours as possible, to a take frequent breaks mode due to health problems.   It was interesting since the majority of my career I’ve been exposed to the frequent interruptions style of working and have been aspiring for the non-interruptions style in order to improve throughput.

At my old job, I used to handle a plethora of queries.  Support phone calls would come through distracting me from programming.  I also used to keep my ears open for conversations about areas of the software or business I knew about so as to be able to help my colleagues avoid taking a wrong, time-consuming path as they were scoping out ideas for solutions to business / technical problems.  These too were distractions that I had to learn to shut out.

At my new job, there are still distractions but an order of magnitude less than what my old job was.  No phone on my desk, or MSN chat allowed means that the only real distractions are from my boss, some seldom queries from a fellow dev or product manager, and then emergency support queries from the business when all the other developers are away that are even more seldom.

Adjusting to this new way has been a little harder than I initially thought.  I was used to being interrupted.  The benefit of being interrupted often was that I wouldn’t get ‘locked on’ to a problem. If I was stuck, something would happen by chance to distract me so that when I came back I had pondered a way forward in the background.  It was so run of the mill that I didn’t realise how much it became part of my daily routine.

At my new job, I found I’d get stuck on a problem and then keep pondering and pondering on it without a way forward thanks to the seemingly productive ‘one thing at a time’ mentality. When faced with a hard problem, I had to learn to deliberately leave a problem be for a little while and re-employ the task switching skills I’d learnt at my previous job. Here is a crazy analogy: Work is not a sausage that you can split in half and then continue eating the other half later.  Some parts of eating the sausage wear you out, and you need to cut up into smaller chunks so you can chew through it.

The blogger however reminds me of my current boss, who I must say is exceptional at task switching in the face of constant business and colleague distractions (or at least able to do frequent task switching without complaining about loosing context).  It was good to have a working example to think about whilst reading the blog.  It seems that the best tricks to employ are, to one, not get upset that you are being distracted, and two, keep some context of what you are doing, so that when you switch you have something you’ve written down to come back to.  The blog post makes mention of GTD as well which is good to see.

Posted on

Reading Other Peoples & your own old code

Old code is hard to read.  Even your own.  Its not uncommon 6 months down the track, to experience a bit of “what was I thinking when I wrote that?”.  Its one of the first things drummed into me by senior devs at my old work.  The best way to avoid this is to make your code as easy to understand as possible and I believe to do that you need to keep your code modules small (classes & methods) so that they are easy to test. 

But as I try to work with old code bases with long methods and classes with lots of dependencies that are sometimes difficult to test, and with shrinking deadlines to do anything about them, the messages about good practices fall by the wayside.  Its refreshing to see a blog like this, Beautiful Code: A Sense of Direction, talk about the core tennets of keeping things simple, small cohesive classes and refactorings to reduce LOC in addition to a nice example at the start that I read as even your own sh—, um, crap stinks.

BTW, the article made reference to a site that I had come across previously but hadn’t bookmarked which appears to be a great resource on Design Patterns (and Antipatterns) and UML called SourceMaking.com

Posted on

Legacy Java Systems

I’ve had my fair share of working with legacy code.  I don’t think legacy code is a bad thing because its existence means it has addressed the majority of the needs of the business successfully enough to stay around.  However, as time proceeds, the business needs to change in order not to become a historic entity and so legacy apps need to be updated.  This is usually where the frustration comes in.  You have to work with older development practices and styles you may not be used to.  You also may have to source old libraries or application containers in order to get things to build and deploy. 

However, I would like to think you can make a green field out of anywhere. A lot of other people may disagree, but the legacy system does have the advantage of addressing business need that your own ‘from scratch’ green fields app may not (provided the business need is still relevant).  There was a recent article on info q: Eight Quick Ways to Improve Java Legacy Systems that talked about the following areas

  • Tip #1: Use a Profiler
  • Tip #2: Monitor Database Usage
  • Tip #3: Automate Your Build and Deployment
  • Tip #4: Automate Your Operations and Use JMX
  • Tip #5: Wrap in a Warm Blanket of Unit Tests
  • Tip #6: Kill Dead Code
  • Tip #7: Adopt a ‘compliance to building codes’ Approach
  • Tip #8: Upgrade Your JRE

I’ve used a number of these techniques, but there were some I hadn’t heard of before such as the jdbcWrapper that simply wraps your jdbc driver with a logger so you can see what part of your code executes what SQL. (Tip 2)

Using JMX to trigger cache cleanups as described in Tip 4 is a great idea.  Another useful thing I’ve seen is using scripts and creating a Javascript or Groovy console within your app so that live maintenance can be performed on production environments.

Tip 5 touches on breaking dependencies, which is what you see a lot of in the code base I use. I’d like to get to know more about how to do this

Tip 6 advised that the Emma code coverage tool can also be used to find production code that isnt run (in addition to stuff thats untested)

Tip 7 really rang true to me.  Its easier to bring in all your toys under the sun, but without a common plan, everyone will bring in their own frameworks to solve the same problem and make the app even more confusing to work with.  I like ‘toys’ (frameworks, tools, etc) but I know I can get carried away Winking smile