Join us for our new Allvision Interview Series, where we take a few moments out of changing the AI world to talk to the people who make everything work – our engineers. Let’s chat with Seth Koterba, Allvision Principal Architect. 

Q: How did you decide to become a software engineer?

SK: When I started college, I knew very little about software or software engineering. I chose to major in the subjects I liked best in high school: math and physics. As a result, I did several independent study projects in my department’s labs and several summer internships working on things like particle accelerators, planetary physics, optical instrumentation, and other cool stuff. However, when I was in my senior year and trying to figure out what I wanted to do with my physics degree, I started to realize that I had way more interest in getting the lab equipment working and writing code to analyze the data than what the results informed us about the physical world. That’s when I realized that I should probably be thinking more about robotics, and I decided to focus in that area for grad school. When I got to grad school, I realized just how much of it relies on strong software engineering skills and that I did not have nearly enough training in that area. I really had to work hard in my first few years of grad school to develop those skills and get caught up with my peers. Today, I’m purely a software engineer and I love it. I attribute landing in this field to my post-secondary school meander through math, physics, and eventually robotics.

Q: Tell us a bit about your background, including education and previous positions.

SK: After finishing my master’s degree in robotics, I started working on my PhD, but I didn’t have a particular area or field that I wanted to focus on for my dissertation. Instead, I worked on a bunch of different projects with my advisor hoping to find something that felt like the right fit. I mostly worked on a lot of field robotics projects, many that were related to sensors and sensing capabilities, especially laser and photo sensors. One particular project led to an opportunity to do some freelance work on the side. That eventually developed into a part-time and ultimately a full-time startup business. I decided to pause my PhD work and explore entrepreneurship and ended up never going back to grad school, at least so far. I co-founded that first business, Allpoint Systems, with our current CEO, Aaron Morris, and roughly three years later we sold that business to Autodesk. I spent the next five years working with engineers at Autodesk to integrate the technology that we built at Allpoint into the software products at Autodesk. Eventually, I moved back into the startup world and joined Allvision in early 2018.

Q: What does your typical day look like?

SK: Most of my typical day is spent doing R&D work. I’m either working on an entirely new approach to extracting assets from a mountain of sensor data, or I’m trying to make an existing algorithm better or more efficient. I spend a lot of time experimenting with ideas that are based on prior knowledge and experience and writing visualization tools to help observe whether those experiments are working as expected. Eventually the experimenting evolves into new production workflows that add more capability to our platform. However, a few times a month, some new dataset presents an issue that we’ve never experienced before, and it causes our production pipeline to misbehave or even break completely. When something like this happens, usually all new development is halted to figure out what broke, why it broke, and develop a fix for it, ASAP. That’s a fire drill day, but thankfully as our system has matured, those days are becoming less and less common.

Q: Give us an example of a project or problem that you’re currently working on.

SK: Road paint extraction is a tool and algorithm that we have developed to identify painted lines on asphalt roadways. This algorithm makes several assumptions about expected line thickness, curvature, relative distance between lane lines, relative intensity between road and paint, etc. These assumptions help us minimize the false positives that can occur and are tuned to the types of environments that we’ve worked with thus far. Primarily that experience has been on highway and controlled access roads, however recently we’ve seen more interest in urban environments. These environments break a lot of the assumptions that we’ve made and have much more complexity to their painted areas. For example, crosswalks, bike lanes, parking spots, loading zones and more. I’m working on adapting our relatively mature highway road paint algorithms to handle more complexity in urban areas.

Q: What are the skills, experiences, and attributes that can contribute to being a successful software engineer?

SK: While its hard to make a list of all the skills a software engineer needs, some of the highest value skills, in my opinion, are quick and dirty prototyping, build first/optimize later, and good attention to detail.

I think one of the bigger challenges that I have is getting started on a large project. My instinct is often to put a lot of effort into planning a flexible and extensible architecture up front. While this is absolutely an important skill to have, I have found out the hard way that this can often be wasted time if you don’t have enough experience with what you’re building. Rapid prototyping is an important skill for quickly testing out ideas and exposing what you didn’t know that you didn’t know. Once you’ve turned over all the big rocks, then you can start building and planning that amazing architecture.

A similar approach is needed for optimization. Make sure the tool or algorithm works, then, if necessary, experiment to find bottlenecks, and finally target your optimization on the highest priority bottlenecks. I often see developers working hard to optimize something that only accounts for a small portion of the overall computation budget, or they spend a lot of time optimizing something that ends up getting cut from the eventual workflow.

Attention to detail can be very valuable when testing software. For me, I’ve had many experiences where I thought something was working well, and it was, except for a small anomaly that was easy to overlook. That tickle in the back of my mind that something seems off can often help make better software. When following the clues to uncover the anomaly, I often discover a class of edge cases or even an underlying flaw in the original approach that would have caused problems in the future.

Q: What are the biggest challenges that you’re currently facing?

SK: High resolution data capture of the real world is something that has been growing and expanding year over year for decades. While the approaches have begun to standardize, the industry is still young and rapidly evolving. There are constantly new collection systems being built and new applications trying to utilize the data. We are working to build a suite of tools and technologies that can work with any collection system and help add value to any application of the data. The challenge we face is embracing the nuances of each new collection system and delivering value for as many applications as possible. Fortunately, we have a strong team of engineers that are up to the task, but the pace of development in this industry certainly keeps us on our toes.

Q: What are your thoughts on the future of AI development?

SK: AI is a very powerful tool, but it’s also a poorly understood technology, even by most of the leaders that are developing and exploiting its capabilities. You throw a mountain of data at it, it churns for hours or days, and usually it learns something useful. Exactly what it learned usually is not obvious, but if it gives useful results, we often don’t care.

I expect that, over the next 5 to 10 years, researchers will find better ways for users to comprehend what an AI is learning, why it is learning it and, more importantly, how to better direct and refine its learning process. As humans find better ways to understand and guide the AI learning process, it will be become accessible to a larger pool of developers. Advances in AI accessibility stands to enable AI to become even more ubiquitous than it already is.

Q: What are your talents/interests outside of your job?

SK: I don’t really consider myself a “maker” but I definitely like to build and fix things, especially if it requires creativity. My current project is building a tabletop sized hydroponic growing station for lettuce, tomatoes, and other vegetables. I’m currently on version 3 and am constantly thinking about ways to improve it. My 3D printer and large tool collection are very helpful in my tinkering on that and other projects. The rest of my free time is mostly spent attending sports and other enrichment activities with my two kids, but I also enjoy working out at Orange Theory Fitness, playing poker with the guys, and squeezing in an hour or two of pickup basketball on the weekends.

Q: What’s one thing you wish you would have learned in your schooling that you didn’t?

SK: This was also my answer to the next question, but the highest level of formal coding/computer science that I took in college was CS102, a freshman level C++ coding class. Everything beyond that I learned through classmates, colleagues, and Google. Although I feel that I’ve developed the necessary skills to excel at what I do now, I wish that I would have taken more computer science courses to broaden my exposure to more areas of the computer science field. Computer graphics, front end development, networking and security, etc. are all things that would have been valuable to have a firmer grasp on throughout my career.

Q: Name one thing about your career path that would surprise people.

SK: Up until my late 20s, I expected that my career would somehow be heavily involved in the space industry. I have always been fascinated with space and, early in my career, I actively sought opportunities to work in that field. I interned at NASA two different times, once during undergrad and again as a grad student. I once spent two weeks in the Utah desert on a simulated Mars mission and I even applied to be an astronaut (twice!). I still hope that someday I will get to travel to space, whether it’s for my job, or (much more likely) as a tourist.

Bonus Question: Any advice for engineers in a startup?

SK: Startups are high risk and high reward; although most startups fail, so don’t bank on the reward part. I have seen a lot of former classmates and colleagues fight through disappointment and heartache after what looked like a very promising startup failed. Whether it’s an inexperienced CEO making bad decisions, an investor backing out at the last minute, or an innovative product going to market too soon, there are lots of ways for startups to fail. I recommend going into a startup knowing it could fail and maximizing your potential in two ways: 1.) Negotiate hard for equity. If you did pick (and help make) a winner, you will be well rewarded for your efforts. 2.) Hedge against the possibility of failure by taking advantage of every opportunity to learn something new. Most startups don’t have enough people and you’ll need to “wear many hats” to help your business be successful. Those opportunities to learn and do something new will make you even more valuable and marketable if you do need to jump back into the job market unexpectedly. Sometimes its intimidating to volunteer for something you’ve never done, but if you were brave enough to join a startup, you are brave enough to build a new skill.

Thank you Seth! Do you have any burning questions for our engineering team? Let us know in the comments!