For the last few weeks, Facebook has been ad nauseum “recommending” me some company’s blog post about server-side Swift. I was relunctant, but after seeing it pop on my news feed so many times, I clicked it and read about the experience one developer at that company went through to find out whether server-side Swift was ready for prime time. One thing was for sure: to run a very basic API endpoint, he needed to do a lot of hoop jumping. The toolchain wasn’t so easy to use out of the box and the basic things like generating random numbers or JSON parsing didn’t work. Anyways, in the end, the developer proclaims the entire process “tons of fun”.

This sounds like a very questionable idea of fun.

My usual readers would know that I’m not a huge fan of the “everything is awesome, and easy, and fun” attitude that is prevalent in some programming communities, most prominently in Ruby. A healthy attitude of a critical mind comes with a constant feeling that something is a bit “off”, inconvenient, not in its right place, could be done better. Dealing with that inconvenience is what often moves our industry forward, after all. On the contrary, being excited about the need to do anything more than writing exactly one line of code to parse JSON is, to say the least, strange. But then what is actually fun in programming? Most of our profession consists of boring routine, true, but most hackers have certain feeling that being on the forefront of things dramatically change the dynamics in what you do. Even my example with JSON parsing is fun if you’re in the business of writing state-of-the-art JSON parsers for the last eighteen years, of course, — which definitely puts you on the forefront of JSON parsing business.

How to get to that forefront? Well, first of all, it takes time. Writing parsers for all of the eighteen years may be a completely legitimate way of doing this, but there are faster ones still. Join a good team, preferrably in a good company. If this is impossible, learn how to distinguish good teams from bad ones and keep practicing that. If even this is too hard — for example, because there’s not so much information flowing in your circle about what different teams are really like — learn how to distinguish good programming books, good tutorials, good hyped technologies from bad ones. After that, what’s left is just sticking with the good.