Sharing Lunch

My name is Jim Kimball. I am CTO at HedgeServ, a Hedge Fund Administrator in New York City. My goal is to facilitate an environment that people want to work in. This blog is a place for me to clarify thoughts and ideas and hopefully engage in discussion with other people who think about technology and organizations. I appreciate comments.
Recent Tweets @jimkimball
Posts tagged "programming"

I talk to a lot of people who ask for input on how they can get better at what they do. This is something I think about. So I want to share how I think about it and perhaps people can add comments on what works for them (since that is how *I* get better).

How can someone get better at being a programmer? I think of the following things that contribute to being “good” (with the idea that improving them makes one “better”):

  • Writing good code
  • Following a good, consistent process
  • Considering and understanding how a program is being used in production (I call this “Operational thinking”)
  • Being a helpful teammate

For now, I want to talk about how we can get better at writing code. The quality of our code directly influences everyone else in the organization. In “QSM, Vol 1” Jerry Weinberg says “Quality is value to some person”. Off the top of my head I can think of a couple ways a person might value code:

  • Other developers value code that doesn’t break the build
  • QA testers value code that has a clean interface for testing
  • Build and Release Engineers value code that is properly packaged and deploys cleanly
  • Technical Operations values code that supports options for managing production settings easily
  • Application Support values code that reports good error messages and good log messages
  • Users value code that gives them the functionality they need in a timely manner
  • Other developers value code that is easy to understand in case they need to make changes to it

I am sure there are more. The many different types of value that exist contribute to the challenge of building software. Even worse, if you try to build code to satisfy a particular person’s value, you may end up making the code worse for someone else! This leads to inevitable conversations around quality trade-offs - “If I build it the ‘right’ way, it will take longer”, “This code does what the user wants but is impossible to test”, “We are done with the code but component XXX requires manual deployment”, etc.

Attempting to address all known (and unknown!) interpretations of quality is a herculean feat. So what we do instead is try to come up with techniques and processes, which if followed, allow us to write code that delivers a consistent level of quality to known parties and provides a solid foundation for those people who have yet to give their input on the value they are looking for.

The specific code that you write has a direct impact on many notions of quality. How do you decide when you introduce a new class? How do you determine which method you should change when you need to introduce new logic? What is the best data structure for storing a particular entity? These are just a couple of the thousands of decisions that are made every time you touch source code. How do you get better at making those decisions? You read books, you search Google and you learn about techniques for doing things. You may even try those techniques as you code each day. But then you end up with different techniques and approaches sprinkled all over the code making it harder for other developers and even yourself to go back and look at something weeks or months after you wrote it.

To get better at something, you need to practice it. How do you practice coding?

One technique I’ve used is code katas. A small number of people at work have taken me up on the offer to do the bowling game code kata.

Another technique for practicing coding is something called a coderetreat. Code Retreats are focused, one-day sessions, for programmers to practice the craft of programming. You can read more about coderetreats at

We have code retreats scheduled for the 18th and 19th of this month with Corey Haines, one of the founders of this technique. Here is a link to learn about code retreats as well as some of the other interesting aspects, such as “TDD as if you meant it”, which is at

I think this is some pretty cool stuff. Let me know what you think.