Job 3: Webmedx
After losing the job at CTi and a stressful couple of months looking, I eventually started my next job working for Webmedx. Webmedx was a medical transcription company in Pittsburgh where I finally found a lot of what I had been looking for since graduating from college. The Webmedx product allowed doctors and hospitals to dictate audio notes from patient visits, which we would then route to our team of transcriptionists. The application was built using the type of technology I wanted to start gaining experience with, and the team was small enough where I knew I would get good full stack experience. (I don't recall the term full stack being used much at the time. Single-page applications hadn't really happened yet — GMail would launch during my time at Webmedx — so I think most developers were full stack.)
The first project I remember from Webmedx was a little weird. Our transcription platform included a rich text editing component that sported a toolbar slightly reminscent of old Microsoft Word UX. This toolbar included relatively decent images, but the theory was that, even though they were small and cacheable, loading these images on every page load was taking unnecessary time, so they asked me to redo the toolbar using pure CSS styling that could be included in the page load. The buttons for bold, italic, and underline font were pretty trivial, and I figured out I could make the justification buttons work reasonably well using actual justified lines of text with 1 point font. I think I had to be a little more creative for some of the buttons, but in the end, arrived at a workable pure-CSS toolbar. (Sadly, I don't remember the results of performance testing, but I believe they were positive.)
After doing a couple of other mostly front-end projects, my manager (and Webmedx CTO) told me he wanted me to do more performance optimization, this time focusing on the database queries. I had worked on Oracle databases at a couple of earlier jobs (both PhyzBiz and CTi used Oracle) and I knew it was considered the industry leader. I was skeptical that such a well regarded database could have performance issues, but my manager recommended a book, and I started digging in. I quickly found out I had a lot to learn. Up to this point — as with many developers — I had treated SQL as a magic engine that always figured out the fastest way to get your data, but over the course of the next six months, I found out there were many limitations to what the query engine could figure out. More importantly, if you didn't have the right indexes and table structure in place to begin with, the query optimizer was helpless.
Over the course of about six months, I was able to become very familiar with the options Oracle provided for optimizing database queries. I learned about different types of joins, different types of index, and how to use the analytics and visibility tools within Oracle itself to identify which queries were responsible for the most database load. After a fair amount of research and testing, I was able to find ways to reduce our database load by about 50%. More importantly for me, I found out that I really enjoyed this type of work. In one way or another, I credit this "side project" for getting me really interested with backend development and infrastructure work.
The final major project we completed during my time at Webmedx was to integrate automated speech recognition technology (ASR) into our product. Everything up to this point had been operational, driven by human transcriptionists to do the work of converting audio to text. We wanted to automate more. One of my more senior coworkers did a lot of the work of integrating Nuance's speech recognition engine into the platform, but I was tasked with making some changes in our UI to make it more tuned towards editing text that had already been generated by ASR. The main thing I tried to do was to integrate the text editor with our audio player, so that we could highlight the relevant words as the audio played. Implementing this was a little more difficult than it seemed at first, but we eventually came up with a pretty decent system that worked pretty well for most cases.
1: Lessons I'm Learning
The first lesson I remember from Webmedx was during the job search. Most of the jobs I was applying for required J2EE experience, but since I had studied extensively and used J2EE at my prior job, I was confident I could pass technical phone screens on the subject. What I failed to account for was that, even though J2EE was a common standard, many recruiters were recruiting for experience with specific commercial J2EE servers. Without prior experience with either BEA Weblogic or IBM Websphere, I failed to get past a lot of recruiter screens. As a job seeker, there's nothing you can really do to get past this reliably, since the potential list of technologies companies may be looking for is too large to prepare for. As a hiring manager and interviewer, I've always worked to look past specific skills gaps and look for people with the right attitudes and attributes to fit into a team.
When I first saw the Webmedx UI, I thought, This is ugly, but kept my thoughts to myself because I wanted to keep the job. Our background was a pale yellow, textured image. The text was all blocky Courier text. We didn't even have a graphical designer at the company that I recall. Shortly after I started, though, the UX model was explained — make everything keyboard accessible. Everything in our UI was tab-navigable. There were keyboard shortcuts for most buttons and even text fields in the UI. The goal of the UI was not to be pretty — or even necessarily easy to learn — as long as transcriptionists didn't have to move their hands off the keyboard.