Senior Software Developer with more than 15 years of experience, including SQL Server, many years of FoxPro, and more than one year of C#. Like studying Code Complete and offbeat languages like Forth, Factor, and MSIL and feel that LINQ is the greatest thing since sliced bread, and that Functional programming will be critical to the future. I recently took a break from software development to pursue embedded development, and learned that inductance is a real mind-blower, but the Joule Thief is cool. I am now open to a variety of directions, and am becoming fairly active at a local MakerSpace called NextFAB. Making is great!
While building a complicated custom ETL engine that migrated large chunks of a database from staging to production, I developed what I consider to be an interesting and very useful development methodology that led to a particularly correct piece of software. This way of development has to do with the following question and its answer: Question – How do you debug data you don’t understand yet? The answer that I discovered combines some data analysis with the heart of an explorer and some outside-of-the-box debugging techniques as you develop, and essentially tries to implement a form of data code coverage so that we can relatively quickly trace through every unique combination of data types. And, yes, we will definitely look at some code, both C# and T-SQL. This methodology should be useful in any language, and will be more applicable the more complicated the data is. Also, this is not for just SQL or C#, but for any development platform having a decent debugger. Finally, this methodology can assist in catching those elusive intermittent bugs.