Be the worst
You know you aren’t the best programmer out there. You haven’t created an open source project in your free time. You probably haven’t even contributed a patch. You don’t go to all of the hip conferences to learn about the latest “latest and greatest” technologies. You don’t give talks at the local user group, and you don’t have a widely read blog.
But you aren’t the worst programmer either. You try to do your work well and you read a few technical books a year. You attend a user group or two when it fits in your schedule. There are a few technologies that you understand fairly well, and others on your team look to you for help in your areas of relative expertise.
The problem is, you are in a rut. You aren’t gaining skills as quickly as you were last year. You aren’t exactly thrilled about your current job, but not so dissatisfied that you want to take the chance of trading your known problems for unknown problems. What to do?
You need to be the worst. It’s time to get that job that you think you don’t qualify for, and work among developers that are all better than you. Don’t just apply for a different job, apply for the best job you can.
After I had some experience as a Java web developer, I somehow managed to get on as a consultant with Pillar Technology, which hires some of the best software developers in my area. Some of them have written technology books, they regularly speak at user groups, they contribute to (or create) open source projects, they host code-retreats, and they all live and breath code. It was obvious to me that I didn’t really belong with these guys.
To say that you will be pushed and challenged in such a situation is a truism, but it is amazing to me how much my view of the IT world changed from a relatively short time at Pillar. During that time I gained significant work experience a variety of technologies that I hadn’t used before, with opportunities to learn from real experts, and I experienced agile software development, TDD, pair programming, and continuous integration along with a team that was very committed to delivering excellent software. I also found myself spending my own time learning technologies that I wasn’t working in, like Haskell, Python, Ruby, RSpec, Git, and Vim, because there was constant conversation about new or interesting languages, technologies, and tools.
In the end, working at Pillar did not make me as good as the Pillar guys, in my view. But it gave me an opportunity to understand what great developers look like, and to see what sort of effort it takes to produce excellence. And their enthusiasm for excellence and delivering valuable software is infectious.
If you try to be the worst you might fall on your face. I had one interview with an excellent start-up in the area where it was clear that I was out of my league. I had suspected that this might be the case, but I made it through the phone screen, so I went for it. That isn’t a fun experience, and it comes at the expense of time and emotional investment, but you simply can’t know until you try. And really, if you aren’t concerned about the possibility of being exposed and embarrassed, then it is likely that you are aiming too low.
You’ll never be the best. But if you have the courage to be the worst, you may find yourself significantly better in the end.