{"id":5471,"date":"2010-03-09T06:12:15","date_gmt":"2010-03-09T06:12:15","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/bharry\/2010\/03\/09\/programming-practices-part-1-watching-from-a-distance\/"},"modified":"2018-08-14T00:20:32","modified_gmt":"2018-08-14T00:20:32","slug":"programming-practices-part-1-watching-from-a-distance","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/bharry\/programming-practices-part-1-watching-from-a-distance\/","title":{"rendered":"Programming Practices: Part 1 – Watching from a distance"},"content":{"rendered":"

I figured I’d start the series with a more abstract post about what watching me code looks like.  It was interesting to observe myself doing it because I didn’t really realize the degree to which I do some things.  If I were to summarize my overall approach to coding with a simple description, I’d call it “Annealing” – from the Encarta dictionary: “metallurgy craft transitive and intransitive verb to subject an alloy, metal, or glass to a process of heating and slow cooling to make it tougher and less brittle.”  Or in more of a software sense, “Simulated Annealing” – from Wikipedia: “a technique for searching for a solution in a space otherwise too large for “ordinary” search methods to yield results”.\nWhat does that mean?\nLet me try talking about it as a set of principles and techniques:\n1) Working code every few hours<\/strong> – I find I can’t stand to have code that is in pieces all over the floor.  I don’t ever like to be far from code that works.  My coding is defined by a sequence of “stable” points that are no more than a few hours apart.  A “stable point” is a state where all of the code compiles, it runs and it does something useful.  It may not be anywhere near doing what the ultimate application is intended to do but it does some fraction of it.  A quantum of work transitions from one stable point to the next.\nI find that as I approach a problem, I think about how I am going to build the code in bite sized chunks.  It’s kind of funny to watch but if I get a few hours into something and I’m not very close to a “stable point”, I actually get anxious.  I start getting nervous and looking for ways to stub out or cauterize parts of the application so I can get back to something I can build and hit F5 on.  I think part of this is related to why I got into programming in the first place – I’m a huge fan of the “instant gratification” that you get programming.  I can think of no other profession where you can start with nothing and in a few short hours have built something really useful.  But more practically, it’s an important way to make sure you don’t get lost in the weeds of a solution.\n2) Prove the concept<\/strong> – When I’m getting ready to leave a stable point, I find the first thing I want to do is map my path to the next stable point.  I choose some specific, containable goal – add a dialog, a menu item, move an operation to a background thread, add a control to a form, something.  Before I enter the chaos between stable points I want to prove to myself that I know how to get to the next one.  I often start, particularly if I’m working with API surface I’m unfamiliar with, by doing a rapid prototype of the core concepts that I need.  I don’t care what the code looks like. I don’t modularize anything.  I don’t worry about comments, variable names, code organization, error handling, performance, anything.  I just want to touch each of the core APIs that I need to use and prove that I can get access to the information that I need and understand roughly what I need to do with it.\nI usually get it all the way to running code and step through it in the debugger so that I can see all of the information flow and ensure that I understand all of the side effects, etc.  To a first approximation, I then throw it all away.  Sometimes, I’ll just comment out the routine(s) that I wrote and keep them around a while for reference and a source of code snippets.  I step back and conceptualize an organization of the code that feels clean and I then start writing the code “for real”.\nAt some level this might feel like a waste of time but I believe it is a huge time saver for me.  It usually doesn’t take me more than 15-20 minutes or so to explore the key concepts of the few hour leap from one stable point to the next and I often learn a ton in the process and make significant shifts in my approach as a result.  It saves me from getting an hour or two into something and realizing that some assumption I made at the beginning was invalid and I need to redo everything I just did.  I think it also helps ensure that I end up with better organized code when I’m done.\n3) Refactor, Refactor, Refactor<\/strong> – I never really realized how much I just naturally do this.  I’ll bet the net effect is that I write any given stable point to stable point quantum 2 or 3 times in the few hours I work on it.  I start with a conceptual picture of the algorithm but I don’t try to plan out everything.  I start writing the code organized in a way that feels the “cleanest” but as soon as I realize something’s not right, I refactor.  I’m constantly splitting methods, reordering code, reorganizing data structures, building abstractions, etc.  This is the main reason I started by talking about annealing – because that’s what the process feels like to me.  I keep jiggling the code, gradually reducing the temperature until all of the crystals line up just right and I have a very clean, maintainable, reusable, fast, robust, … implementation.\nI now realize that I used to do this even before “refactoring tools” were invented but I am finding some of the refactoring tools to be very useful in saving me some typing – though they have a long way to go to make me really happy.  The VS ones, at least, don’t automatically do everything I want and don’t always have the flexibility for me to control it.  Examples – Extract method often leaves me with a lot of clean up to do.<\/p>\n