Name: Dave Snyder
Home: Maple Valley, Washington, USAProgramming Languages: LabVIEW, C#, VB, VBA, bits of other things
Certification: CLA, CRR (Certified Rabble Rouser)
Used LabVIEW Since: 2006 - LabVIEW 8
Applications Areas: Desktop applications, cRIO, Mfg test systems, Motion control, Vision, Actor-Oriented Programming
User Groups: Seattle, WA. Portland, OR. Architect's User Group
Discussion Groups: LAVA, Actor Framework, LapDog API
Articles: approx a dozen in various states of incompletion
Books: (See my posts on the forums)
Biography:
I started programming LabVIEW in 2006 when I stumbled on the Tic Tac Toe Challenge. Intrigued, I installed a 30-day trial and coded up a contestant--Toe Jam. Toe Jam ended up finishing in the middle of the pack, but I had fun writing it. Later on that year I accepted a new position as a test engineer for Microsoft's Zune, responsible for testing the capacitive touchpad (and later the capcitive touch screen.) As part of my job, I had to create a 2-axis robotic system to precisely control an artificial finger, so naturally I turned to LabVIEW.
Over the next several years I became more experienced with LabVIEW and eventually decided I wanted to return to programming rather than be a test engineer. Around 2009 I accepted a position as a developer with the XBox Accessories team, creating test tools for the product design teams. It was while working on a complex RF testing application for XBox controllers that I discovered that, contrary to what I had read on the forums, the QSM was not the bee's knees. There were no guidelines available to users explaining how to integrate a QSM loop with other loops, what kind of commonly promoted techniques were safe or not safe, or how to refactor a QSM as it grew in complexity. Without any guidelines, our applications inevitably grew into a big ball of mud as we frantically tried to satisfy the test engineers' ever-changing requirements.
Dissatisfied with the constant grind and problems with the status quo, I started looking for smarter ways to develop software. In particular, I wanted to write software in a way in which it is not only easy to change what the software is supposed to do, but it is easy to predict what the software actually will do after the change is made. I focused on implementing code that satisfies the requirements now, not implementing code that satisfies what the requirements might be next month. I also wanted to take advantage of arguably the single biggest advantage Labview has over most text languages--cheap multithreading. Above all, I didn't ever want to code myself into a corner that was difficult to get out of.
I spent the next several years experimenting with various ideas and implementations, posting ideas on LAVA, and taking bits and pieces of what worked while discarding those things that did not. The old school Labview programmers I was working with were content to continue doing things the same way they had been, so I left Microsoft and started a consulting business while refining my techniques. Eventually I realized what I had was an agile approach to actor-oriented programming in Labview. The philosophy I took towards my coding methodology now had a name: Agile Actors. Over the past couple years I have become a vocal proponent of actor-oriented programming and have tried--with varying levels of success--to teach AOP to other developers.
A very well deserved recognition Dave. Your LAVA posts on OO design in particular have contributed significantly to my own personal understanding a growth and I thank you for that. Well Done !
Congratulations Dave! I agree with Chris Roebuck, your posts have been great and you should write a book for real. Liked your comment that for books you added "see my posts on the discussion groups":)
Welcome aboard Dave.
Thank you everyone, I appreciate it. I can see I need to edit my profile... the bio was a placeholder until I get more time to put together something real.
"you should write a book for real"
Others have suggested that too and to be perfectly honest I have thought about it, but...
On the other hand, I came very close to not graduating high school because of writing classes, and I admit there is some appeal to giving my former teachers the proverbial bird by writing a book.
Dave, I think a lot of your posts can be summed up in that you are explaining the OO programming paradigm in a way that makes sense to a functional programmer. I know many of your posts did that for me. I believe that is a large gap in the functional to OO transition, especially for LV Programmers. Many people just pick up an OO book but lack that segue. You can be the light!
Dave
I actually like the process of researching and writing, it's quite cathartic
I hated the fact you never keep the rights to the book (especially when your publisher cocks up the print quality)
You're unlikely to get time invested back directly as money, but it does push up your personal Kudos when going for jobs (Book=Expert, it doesn't actually matter that much about content)
Editors sort out your writing for you, they're scarily good at that.
You just need a brain with some original ideas and the time and energy to follow it through. A good exercise is plan out a book that you would like to read, we liked the original Motley Fool books and tried to make ours like that.
If you need any help it's here.
Steve
Steve
Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop
Okay, I was able to carve out some time to write a real bio, but I don't see any way to edit the document. Am I missing something or just stupid? (Or maybe both?)
Daklu wrote:
Am I ...just stupid?
I don't think you could be in this club if that were the case.
It is likely on Kelly's end. She needs to give you write access to the document.
Dave, please try it now.....
Thanks Kelly. It renders funny in IE 11, but it's not that big a deal.
"that I discovered that, contrary to what I had read on the forums, the QSM was not the bee's knees"
That actually explains a lot of your LAVA posts (just remember, it really isn't a state machine )
It's good to have you aboard, Dave. Much deserved.