Coding for Others

I have recently had the chance to reflect on some of the things that I find difficult and challenging in my job vs. my coding side projects. One of the things that has jumped out to me in this reflection is how you have to change what you are thinking about when you are in your work. One of the major differences being that you are always writing code for others not just for the problem itself. On these side projects, other than simply sharpening your craft and doing the best that you can, you don't need to follow any standard or best practices to get a job done. As long as the program does what it needs to do no one will be the wiser. In these situations I would call this coding for the code. Whereas when you are in a team working on code that will likely live on for a decade or more you are still coding for the code (or for the compiler) but you also must code with the next developer in mind. With the expert code sorcerer and the newbie both in mind.

Somewhere where I believe these two coding styles can be seen so clearly is in functional programming. I don't have a lot of experience with functional programming. Some Scala and using functional programming principles in other languages (Javascript, Java, etc) however, as an only somewhat experienced functional programmer I can see this when I look at a block of functional code. There are sometimes you look at some one-liner that just perfectly massages the data in such an obvious way but also gets the job done. These are the places where you get that rush of excitement from just reading some code. Then there are other times where you hit a one-liner that might as well be written in greek (that is, unless you read greek). And then when you finally figure out what it is doing it is not obvious and you realize the developer before you probably just wrote it that way as a way to get it to one line and not writing for the next developer.

Taking this "coding for others" concept further sometimes that is the primary reason we are writing the code that we are. I'm thinking of libraries and APIs. Sure these both do have behavior but they don't do anything without someone using them. And if you don't make it easy or enjoyable to work with your API no one will use it.  I have heard a few talks on API design and it is hard to have a sure fire process because I do believe it is very problem/domain specific. However I think it all starts with having those "others" in your mind as you code.

I will end with one short example. Last week I had the opportunity to participate in a hackathon at my work. The feature my group was working on was a two-factor authentication mechanism to strap onto our current login system. After only a little research we stumbled upon a service called Authy. Given that we only had a limited number of hours to work on this the team decided this was the way to go. And, as are famous last words often said, I shared with the team that "This is going to be easy." And looking back it was but in the next hours that is not what I was thinking. Now, granted, I think Authy had a thing or two stacked against them. The main one being that they were recently bought by Twillio and it appears they had migrated over some of their APIs or at least that some of the APIs had changed. This created a confusing landscape to test out this service. Thinking that their client helper libraries would make it dead simple to integrate we started there but about 400 obscure errors later and we gave up on that for a while. Finally one of my teammates found their Github page which gave us some insight on how to properly use the client library. Still couldn't use it entirely but at least got farther without errors. Then we found some limited documentation on how to integrate with just REST calls and we tried that out and learned a little bit more how to manipulate their API which allowed us to finally use it in production mode but we still could never get a proper response in dev mode. Only after finding a random person's blog that detailed how to use their dev API that we finally got it all working. Granted, next to the Dev API key it does say, "Contact us to learn how to use this" but I shouldn't have to. It should be simple enough that I can figure it out. Your errors should be descriptive enough that I know what is wrong. They really should have had that final piece of information on their documentation not on this random persons blog. But alas we got it done and all was well. I don't mean to rip on Authy as I believe we all have made products like this and Authy definitely has made more money off their products than me so we can see who the real winner is.

All this being said I guess the punch line is how I started. When writing code remember who you are writing for and the world will be a better place.