Taylor Venable's Resume

Photo of Taylor Venable

I hold a Bachelor's of Science in Computer Science from Purdue University, and am currently employed by Indiana University Purdue University Fort Wayne (IPFW) in Fort Wayne, Indiana, United States. I formerly worked at TrustBearer Labs, a small security company focused on the use of smartcards, which was acquired by VeriSign, Inc. in April 2010. VeriSign's enterprise security group was then acquired by Symantec in August 2010. In February 2011 I left Symantec for IPFW. For my own personal interests, I focus on the implementations of programming languages, but I do programming tasks in a sizable number of domains (and of varying practical application). My experience in a wide variety of programming languages across multiple major paradigms allows me to apply uncommon but successful approaches to otherwise difficult development problems.

But really, probably the most important thing about me, and the reason for all of the above, is that I just love programming. I learn some awesome language or technique, then I turn around and try to apply it whenever I can get something from it, and I get a real kick outta that! I learn new things, hack on random code, and puzzle out problems because it's all a lot of fun for me. That doesn't mean I'm not serious: on the contrary! In my mind, cool code gets the job done right, and the coolest code of all holds up under a hail of bullets without breaking a sweat. That's the sort of challenge that moves me, the aspiration to perfection, software that's innovative and indefeatable. That's my passion.

I am not currently seeking employment, but my resume is still available in PDF format.

Professional Programming Philosophy

Putting together a worthwhile product in any environment requires discipline. Businesses cannot continue to produce fragile, arcane, and "eternal beta" software. This kind of software is not worth the money that was invested in its creation. Instead, we as software engineers in general need to enhance our designs to build software that is:

Robust
Over the years, programming languages have constantly invented new features to save programmers from overlooking sources of program failures: type systems and exceptions spring immediately to mind. But while these eliminate some common mistakes, many others which are sometimes impossible to catch (integer overflow is a good example) go uncaught until runtime. It is extremely important to write fault-tolerant systems that can recover when something bad occurs, because no matter how closely you check, the "impossible" will eventually happen. When it does, the software must clean up any unintended consequences and start over from the last reliably consistent state.
Simple
The problems that we typically solve are inherently complex, especially when large systems are involved. Overwhelming complexity leads to wasted energy during development and adds flaws to the result. Software engineering has developed a variety of ways to combat this, but it is the simplest of these which can count for the most. We need to adopt a set of "best practices" for each project, vowing to conform to certain styles of coding (variable names, data structures, control flow, etc.) and most importantly to document everything from function calls to component design. Documentation should be reviewed regularly, and must not be allowed to slip out of synch with the implementation it describes.
Evolutionary
Like all life on Earth, the quiet secret to success is slow evolution. Software cannot leap ahead in bounds without absorbing the consequences of sudden new bugs. But it's easy, especially when developing for the web where deployment is a few keystrokes away, to release whatever is currently available. This is convenient and new features are always being added, but older features are never being developed and allowed to mature. Quality software is tried over an extended period, with ownership and pride being taken in the fact that the victory of every new feature is built on the attestations of countless historic ones.

These are the principles I try to pursue in my own programming. The best code that I've ever written is able to pass the most ruthless testing, but is simple enough to easily explain to somebody who has never seen it before. This success is built upon the idea of evolving software from one correct state to the next. Software that "mostly works" is no longer good enough for our industry, and as a programmer I make it my objective to utilise methods which are resilient, clear, and steady.