Recognizing, managing, and improving on weaknesses is a core skill that any developer should possess (or human being for that matter). Far too many times developers take themselves down the wrong path simply because they don’t realize there is a better tool for the job. I’m not just talking about operating systems, programming languages, databases, libraries either. I’m talking about everything from architectures, algorithms, prior art, to all the other items mentioned previously. What is boils down to is:

You should know when you don’t know something.

Being able to identify that your approach is suboptimal and that a better tool must exist is the first step in the right direction. For example, when working with a previous codebase (won’t name names to protect the innocent) a found a 200+ line class full of complex (stdlib and homegrown) string manipulation code. It was a huge, disgusting, untested mess that ultimate could have been replaced by a regular expression of fairly medium complexity.

After discovering the original author of this class I asked them why they chose this method instead of a regular expression. This individual’s answer left a sour taste in my mouth.

What’s a regular expression?

This wasn’t a recent graduate either, this was a developer with a few years experience who had worked on some pretty intricate systems. Instead of getting upset or attacking this developer’s work, I sat down with them, walked them through the basics of regex and helped them to identify their weakness and in end we both ended up better for the experience.

Identifying weakness can be difficult, especially when we don’t even realize they exist. It’s not exactly a skill that can be applied at a moment’s notice, it’s more of a pattern that can be recognized. There’s no specific training for learning these patterns but there are things you can do to help yourself along.

Get outside your comfort zone

Spend some time experimenting and make sure this is slightly outside your comfort zone. Are you a Ruby developer by day? Hack on some C. Do you spend your days as a Java developer? Teach yourself Closure. Don’t like programming outside of work? Build robots.

Try new things and try to see the world from a different prospective. Techniques gained by learning a new skill can sometimes be applied to your existing skillet. Learning Assembly made me a better programmer, learning Chemistry made me a better cook, learning Physics made me a better driver. Learning new things give me a clearer perspective on existing skills and helped me to identify better solutions to problems.

Local Community

Get involved in the local tech (professional and hobbyist) tech community. You’ll get to meet your peers, discuss past and present projects and problems, and share from the combined pool of experience.

I highly recommend joining a user group for a technology you don’t understand. In 2010 I started attending Pittsburgh Ruby Brigade meetings despite not knowing Ruby. Doing so was one of the best decisions I made in my career, as it introduced me to lots of amazing people, helped me get over my fear of learning new programming languages, and helped me to become a significantly stronger programmer.

It will feel overwhelming at first and no you won’t understand everything, but if you walk out of that experience knowing something you didn’t know when you walked in then it was worthwhile. That knowledge will begin to add up and eventually you’ll begin assisting other newcomers who were in the same position as you.

Online Community

Not everyone can spend their days keeping up with mailing lists, but glancing at a few Stack Exchange sites regularity can do wonders. I personally keep Programmers and StackOverflow in my bookmarks bar. It’s not always perfect but I’ve learned enough to make it worthwhile.

I try to spend 30 minutes or so a week reading about (semi-complex) problems others are having, even if they have nothing to do with my projects. Sometimes it’s a waste of time but a lot of times I end up walking away with valuable knowledge that may help me or a fellow developer down the line.

Research Failure

Learning about failure is just as important. While amusing The Daily WTF has been invaluable to me over the years. Reading about failures and anti-patterns in the tech industry has taught me to recognize warning signs for when a project is headed down the wrong path.

Remember: A facepalm a day keeps the failwhale away.

All good developers are able to get into “The Zone”. This is a state of mind where nothing matters but you and the code. Your office, your friends on IRC, even the music in your ears all cease to be and your mind is envisioning the raw logic of the problem you are trying to solve. It’s almost euphoric. That is until a nerf dart hits you in the back of the head because someone is trying to get your attention.

Honestly I find this behavior to be not only disrespectful but downright rude. Yes we’ve all been in a situation where we need to get a hold of someone and they are unresponsive, it sucks, but unless there is a serious emergency (I’m talking downtime, significant lost of income, building on fire, etc) “The Zone” should be respected. Violently disengaging someone from the work is rather disorienting and after every disengagement it makes it just a little bit more difficult to get going again.

As developers it’s our job to solve difficult problems. Every minute we spend out of “The Zone” our talents are essentially being wasted. Sure there is always “meta-work” that needs to be done (e-mail, meetings, standups, etc) but we should all do our part to keep everyone on the team productive.

In turn we as developers must show respect back. Set a timer to go off ever 25 minutes reminding us to take a break and disengage ourselves from our euphoric state (known as the pomodoro technique). Use this time to checkup on e-mail, help coworkers with problems, ask questions, take a walk, etc. Your time in “The Zone” tends to lose meaning if your coworkers never see you in any other way.

TLDR: Don’t shoot developers with nerf darts. It makes them angry.

2013 is almost here! Another year past, another year older (and maybe a tiny bit wiser). 2012 was a pretty interesting year for me professionally. Lots of ups, lots of downs, and plenty of things in between.

This year marks my first full year as a Ruby developer and it markes the first time an employer has considered me a “Senior Developer”. Thinking of myself as even remotely experienced makes my head spin. In my mind I’m still the clueless Computer Science student who is terrified of not being able to make it in the real world.

Steel City Ruby Conf was the first programming oriented conference I attended and I had a blast. While I wasn’t nearly as social as I was hoping I still got to meet a ton of great people and hear talks from some of my personal “ruby heros” like Aaron Patterson and Corey Haines. I was really looking forward to Jim Weirich’s talk but due to a pretty nasty migraine I had to leave early.

Unfortunately I no longer see former coworkers Michael Hoffman and Lauren Voswinkel on a day-to-day basis but they both moved on to bigger and better things. Michael moved to New York City to be a rockstar developer and Lauren seems to be on the “ruby hero in training” path so I wish them both the best of luck.

I made my first contribution to the Ruby Programming Language this year. Pull Request #173 was a small fix I made to the IPAddr standard library to make some job processing recover from errors a bit more effectively. My contributions are going to be included with Ruby 2.0 so it’s pretty exciting to know that programmers all over the world will be using a tiny bit of my code.

One of my goals for 2012 was to overcome some of my shyness and social anxiety, epically in a professional setting. This was a bit of a mixed bag because I still have problems talking to people I’m unfamiliar with (and accepting that I’m not clueless when it comes to programming). I was able to give 2 talks at Pittsburgh Ruby Brigade meetings this year. One on Continuous Integration and the other on Liquid Markup. The CI talk went pretty poorly but that was because I was far more unprepared than I though (a common problem of mine when speaking). When I agreed to give a talk on Liquid Markup I made it my goal to not let history repeat itself. I got some pretty brutally honest feedback on my Liquid talk but the general consensus was that my talk went well.

Moving Forward

2013 looks like it’s going to be a pretty exciting year. Work has been going well (hopefully more on that later), I have made some pretty awesome new friends, and I have a lot of renewed enthusiasm for my profession.

Goals for 2013

• Maintain a technical blog. I don’t need to post every day (or even every week) but I want to keep a record of my thoughts, successes, and failures relating to my craft.

• Remain involved with the tech community. This year saw the end of my involvement with the PHP User Group, but I became more involved with the Ruby community. I’d like to step up this involvement a bit by giving a few more talks and attending a few more conferences.

• Learn a new programming language. I’ve been working in mostly Ruby and JavaScript during my employment at Webkite. I’d like to pickup and become comfortable with a new language, I’m looking at you Go.

Thanks for reading!