About this site
This is my personal blog and project site. I’ve started this blog to publish my opinions on software development, computer science, and electrical engineering. Most of the topics I’ll discuss will come from one of my interest areas, but I’ll occasionally post on more general-interest software topics, and non-software topics as well.
I’m a software engineer in Dallas, Texas.
I have always straddled the line between electrical and software engineering. I was a computer engineering major for a time, but I switched to electrical after the Dot Com bubble burst because I was more interested in the hardware anyway. I was only about three classes removed from my former major when I graduated, though.
My first job was at Raytheon as a sustaining engineer for a radar power supply. The modules I was primarily responsible for were the input filter (about 60% analog and 40% discrete digital), the enclosure (an aluminum box with a passive backplane and wiring harness), and the power supply controller (a MIL-STD-1750A single board computer). I spent almost four years on this program. During this time I was responsible for troubleshooting production test failures and field returns, performing Diminishing Material Supplier (DMS) activities, providing technical guidance for repair and rework of hardware, and providing technical guidance to the test engineering group when developing or modifying test plans.
The DMS activity warrants some further explanation. Being a military electronics system, our hardware was designed for a twenty year lifespan. Additionally, the development and production cycle was such that we did not finish production of the hardware until fifteen years after the first design was approved. Over this extremely long time period some of our manufacturers would decide to stop producing parts we needed. This required us to periodically evaluate new sources of out parts or, if there were none, to evaluate a replacement part and determine how it would function on our hardware. I participated in three such efforts: one to qualify the new manufacturer of our magnetic components (who bought the prior manufacturer); one to qualify a new manufacturer for our LM-series voltage comparators; and one to evaluate the new parts when our manufacturer of 1750A processors updated their manufacturing process to a smaller feature width.
I also dealt with general parts quality control issues, such as PCBs that delaminated during manufacturing. I had plenty of time in the lab diagnosing failed parts and manufacturing defects, and even some time in the Failure Analysis Lab performing detailed dissections of parts. I got to muck around in the embedded and test set code for some custom tests as well.
The most notable problem I got to work on was a six-month field failure investigation involving capacitors in our hardware that sometimes failed spectacularly. I made three trips to two customer sites in order to run tests on our hardware in the larger system, as well as designing tests at our facility that attempted to re-create the failures in controlled conditions. We never did re-create the failures or find the root cause of them, assuming there was one, but we did succeed in putting our hardware through a wringer and demonstrating many conditions that were not at fault.
After four years on this program I decided it was time for a rotation. During my tenure there I got to write some helpful software tools, in addition to working in the test code as I described above. This made me realize that I wanted to focus on firmware and embedded software development. I discussed this with my manager and department head. About this time my department head was about to transition to heading a new department in the systems engineering group that was focused on embedded algorithm development. It was intended to be staffed by a combination of electrical and software engineers. I was interested, interviewed with a few managers on a program who needed embedded algorithm engineers, and was hired by one.
I spent five years on this program, in two different areas. When I first joined they were in-between development cycles, but had a government Science and Technology (S&T) program going on with several other contractors. I became involved in this as a data analyst, maintaining the software we used to preprocess the system data and identify features that might be useful for algorithm development. I also did a little work on our proposal and algorithm development for the follow-on system. I made multiple presentations on my analysis efforts to the S&T community and wrote or co-wrote a few internal papers. I also created a web-based database system on the program intranet that catalogued all the data we had collected and the interesting features about it.
After two years in the data analysis role I wanted to get closer to the actual system development. Our larger algorithms group had a team working on the system design for our proposed follow-on, so I switched to working with that team. We had about a year until contract award and in that time I worked on improving our middleware and evaluating hardware for our production signal processor and signal processing lab. The hardware evaluation focused on choosing a primary and a backup processor architecture for our signal processor. Since our design was using commercial systems for the hardware the evauluation process consisted of buying commercial systems and running instrumented algorithm builds on each platform. We were able to do this because our core algorithms were not changing from the previous system. I found this particularly interesting because I was exposed to half a dozen different processor architecures and got to become familiar with the low-level idiosynchrasies of each. I also got to help evaluate file systems for the SAN in the signal processing lab we were building.
When we were awarded the contract I became the engineer responsible for developing the actual software for the mode I had previously been doing S&T work for. We had a proof-of-concept (POC) build to start with, but there was a significant amount of work to be done to integrate this into the larger system. I performed the requirements analysis that flowed system-level requirements down to my module, developed the designs and code for unimplemented functionality, heavily refactored the POC code, and worked with the group responsible for the overall signal processor code to ensure that my module would integrate properly into it.
During this time I was becoming increasingly disillusioned with my program and Raytheon. I was working in a DOD closed area and did not like the environment. In addition, I wanted to work on lower-level code but was funneled towards the mode I knew. I accept partial responsibility for this, as I was not as clear and confident in what I wanted to do as I should have been; we had a firmware team on the program but I did not push to be made part of it. The crux of the problem, though, is that I wanted to rotate to another program, both to get me working on firmware and to get me out of the closed area. This turned out to be a political impossibility. I was on a very large program that corporate management considered a crown jewel. It was a special access program, meaning any person being brought on needed to go through a program clearance process that was long, difficult, and potentially expensive. As a result, anyone with a program clearance was essentially unhireable outside the program.
My only way out of the situation was to leave the company. Unfortunately, because I could not discuss much detail about what I had been doing and because it was hard to translate what I could discuss to non-defense companies, I had very little success finding a new position. When I finally did, it was at Language Computer Corporation, a small NLP research and development company just up the highway. I found the subject matter very interesting, and it gave me an opportunity to stick with complex algorithm development.
I have been at LCC for about two and a half years. In that time I have been able to do a variety of things related to NLP. I wrote a research application to evaulate algorithms for authorship identification; I got to author a conference paper about a portion of the work from that effort. I adapted a language detection algorithm into a generic, profile-based n-gram classifier. I have written tools to scrape, index, and process Twitter data. I have written JNI code to interface our Java applications with the LevelDB C libraries on Linux and Windows. I have learned Hadoop and have written several Hadoop programs for preprocessing and indexing web and Twitter scrapes. Currently, I am architecting and developing a system for automatic document summarization.
In my spare time, I do engineering for fun (amongst other things). My projects hit a broad spectrum. I helped build a smoker (the big, trailered kind) and frequently cook on a smaller kamado in my backyard. I maintain this website on a custom-built server in a local datacenter. I have recently started homebrewing.
My email address is wayne at this site.