I graduated from university with a degree in Mechanical Engineering. During the interview process, while preparing for my first job after graduating, I told the interviewer that I didn’t want to be a mechanical engineer and that I wanted to play with computers for the rest of my life. That interviewer was seeking people to create a mechanical engineering software business inside Hewlett-Packard. I was one of their support engineers for the first several years.

After spending enough time as a support engineer, I asked if I could become a programmer. They were bold enough to allow me to become a programmer. However, after some years of programming, I realized I was not a great programmer but a good organizer. I decided to switch to release management and then to managing a development team.

In late 2002 or early 2003, my team learned about Extreme Programming, a methodology that encourages all production code to be written by two programmers paired together. Extreme Programming requires continuous integration. We set our goal to have "XP by 3/03" and started to create our own CI server.

In 2007 or 2008, I switched to a new company with a new project and discovered the continuous integration server that became Jenkins. I was impressed at how easy it was to deploy and manage and how well it worked.

A few companies after that, I joined CloudBees to work full-time on helping Jenkins grow.

I started using Jenkins in 2007 or 2008. I’ve been using it since then, even during the times when I worked for employers that chose another continuous integration solution.

Jenkins was easy to configure and easy to manage, especially compared to its competitors at the time. I defined jobs, modified configurations, and viewed test results from a web browser. I often found that the flexibility of Jenkins was more important to me than the specific reasons that an employer had chosen another solution. I had problems to solve and Jenkins solved those problems.

Jenkins builds my code, runs my tests, and shows the results across a wide range of systems and technologies.

I have been involved in each area of Jenkins at some point, but I’m proud of the Git and Git client plugins that I maintain. I’m also involved in the platforms and documentation SIGs, where I host the Jenkins documentation office hours (Asia).

The Improve a plugin tutorial and the 2+2+2 Java Support Plan have both felt like impactful and successful contributions. In each case, they were important to a wide group of people and they were important for an extended period of time.

Do not in believe self-imposed barriers to open source contribution. I mistakenly thought that a mere mortal, such as myself, could not possibly be of use to a successful and impressive project like Jenkins. I was wrong. Mere mortals are exactly the type of people who do amazing work in the Jenkins project. Find a topic that interests you, either professionally or personally. Find areas in the Jenkins project that are involved in that area of interest. Contribute your skills and your passion in that area. Help others do the same.

I was interested in test automation, so I wrote automated tests for the Jenkins Git plugin. As a result, I learned much more about Git, Java, and test automation.

I was interested in Git performance, so I experimented with options to improve Git performance. Through this, I learned more about Git and performance.

I was interested in operating systems and platforms, so I experimented with uncommon processors and operating systems. I learned more about operating systems, file systems, and their interactions.