Enjoyable Tasks

During job interviews an evergreen question is “Tell me about tasks you enjoy” or in a similar vein “What were your biggest successes during the last project?”

I always found it hard to come up with a good answer on the spot, simply because I did not think about it before. Of course there are some tasks that I enjoy more than other tasks, but what elements do they have in common? And why do I enjoy these tasks? Lately I run into one of the tasks I enjoyed so much that I stayed late, even so there was no actual need or expectation to rush it. I simply wanted to work on the task.

What tasks do I enjoy?

I really like looking at a piece of code that feels overly complicated and find out what it does. Once the code reveals its actual purpose I like to contemplate about how could this purpose be made more obvious? The problems and possible answers are very divers, for instance:

• naming in the code is off. Maybe the methods do not follow the naming schema of the code base or common terms used in the language/framework. Sometimes the names are simply wrong/outdated after a refactoring. The name might imply one action, but actually executes a totally different action. So the solution is finding better names. This is easy to execute (just change it in the code) - but generally naming things is considered as a hard problem in IT.

• accidental complexity. There is no upper limit of additional steps one developer can introduce into its code. The next developer reading this code has to jump through each mental hoop and start guessing about the relevant essence. The most elegant way to solve a problem 10 years ago might be different from what is state of the art today. In the end there is a reason why programming languages and libraries evolve. The solution here is a classical refactoring: make the code easier to reason about. Possibly shorter, but do not turn it into code golf.

• domain knowledge is a hard requirement to make sense about the code. The solution is to provide some form of documentation. This might be a comment in the code, a link to an existing article or creating (and promoting) the actual documentation.

• its hard. Sometimes there is simply no other way (that I know) to solve the problem. Hard problems might require hard code. Take a look at the 1 Billion Row Challange: as soons as performance becomes your major concern, code readability has to take a backseat. The solution might be to leave it as it is. A good engineer knows when NOT to touch some piece of code.

TO BE CONTINUED….