How I solve those tricky technical issues

Wait, Think and Wait some more. Huh? you say. That isn’t an answer. Let me explain. A tricky issue usually doesn’t have a clear solution. Because of this fact you are likely to botch up the solution with something that is complex and hard to maintain if you try to tackle it head on right away. What do I do in this case?

Simply hack together something that works and can easily be thrown away. The last part is key you DONT want this to hang around for years. You will need to be disciplined about this. Now every couple of days I think about the problem again. I don’t work on it, I just think about it. Potential solutions etc. I also talk to people about it and see what they say. After a few days, weeks or months of this and then BAM BOOoM. The solution is clear as day and it ROX. The key to this process is that you need to gain more and more insight into the problem and the potential solution. The key phase of waiting lets the information sink in and and most of all PREVENTS wasted effort. Avoiding extra work is a HUGE productivity booster.

Let me know what you think of this method or how you handle similar issues.

 

  • http://twitter.com/bikash119 Bikash Kumar Patra

    just so awesome

  • http://blog.jessta.id.au/ Jessta

    The most important step in doing this is making sure that your hacked together solution that you expect to be able to throw away doesn’t interact with anything else that might begin to rely on it.

    If a user or a remote system interacts directly with your hacked solution you may never be able to replace it.

  • Alex

    This reminds me a lot of ‘hammock driven development’. The creator of clojure has a video on it here:
    http://clojure.blip.tv/file/4457042/