Fishing for source code

August 7th, 2011 | 3 Comments »

As i’ve restarted the “Android tips and tricks” series on this blog, there’s been a lot of requests for the actual source code. It would’ve been pretty easy to reply that it could require much more time on my side to clean it up, extract to a self-contained project and get the approval. However, it wouldn’t be fair on my part since that’s not the reason.

I don’t want to perpetuate the style of copy-and-paste. I don’t want to encourage blindly taking the code written for a very specific purpose and trying to make it work in a slightly different scenario. I don’t want to implicitly condone a patchwork of code snippets that are incorporated without understanding how they work and without investing time to analyze why they are written in a certain way.

I do want to encourage creative thinking that is aligned with what the platform developers had in mind. I do want to shine the light on the various APIs that the platform has to offer. I do want to do this in an objective manner, where there is no silver bullet. I do want to show that sometimes there are multiple ways to tackle the specific problem, and that you will need to carefully weigh positive and negative sides of each one before zeroing in on the specific solution.

This is how i learn the platform. When i talk to our platform people, i don’t ask them to write the code for me, and i never begin asking to show me code samples from our other applications. I much rather prefer a conversation where we discuss potential solutions in the context of the specific problem. This not only allows me to solve the problem at hand, but also adds a couple of more techniques to my arsenal – so that next time i’ll be better equipped to solve new problems. On my own.

Somebody said that my writing is “dense”. I take it as a compliment. It is meant to be this way. It is not for skimming and finding quick one-off solutions. It is for discussing the targetted UI / UX at depth, presenting possible solutions, detailing the chosen one and defending that choice. And when i detail the chosen solution, i strive to give enough details for a determined developer to follow and reimplement it in his / her own style. If you’re looking for pre-cooked recipes, i don’t have those to offer. That’s not my style.

Related posts:

  1. Are you attached to the code that you write? What thoughts go through your mind when you look at the code that you have...
  2. IntelliJ and a very interesting interpretation of open-source I’m reading the very thorough overview of the “IDE shootout” that took place a few...
  3. Why i do open source The explosion of open-source phenomenon in the last decade has spanned hundreds of thousands of...
  4. Party Of One: Surviving A Hobby Open-Source Project Last week’s JavaOne had a separate track on open source, and there’s been a substantial...

3 Comments on “Fishing for source code”

  1. 1 Natalie said at 11:19 pm on August 7th, 2011:

    I’m glad you’ve said this, it’s good to see somebody take a stand against blind code-copying, which happens way too often. I have recently taken over from another dev on an Android app for a client and the code I inherited was very poorly constructed and full for copied code (easy to spot as the dev hadn’t even bothered applying his own coding style to it or trying to blend the copied code in).

  2. 2 bryanl said at 5:22 am on August 8th, 2011:

    I see your point. You never really learn from cargo culting other people’s code. On the other hand, you have a leg up on most people. Most of us don’t have readily access to platform engineers. I have been enjoying your posts, and hope you continue with the trend.

  3. 3 Andrew said at 7:23 am on August 10th, 2011:

    I’ve been learning Java for about one year, so take this from someone who hasn’t been developing long at all, I couldn’t agree more. Having the code there to reference is very helpful, but at the end of the day being fluent is what is important.