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. In this article, we chat with Justin Carulli, Allvision QA Engineer. 

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

JC: I was very fortunate that my high school had a few programming classes, just BASIC and VB really. But it sparked a kind of creativity that I had yet to experience in another way, such as art or writing. So when I was deciding on a major in college, it wasn’t too difficult to choose Computer Science (my school did not have a Software Engineering program) given that software jobs seemed to be plentiful. At that point, the choice was, go to grad school and continue on the scientific path, or wedge my way into the software development world. I opted for looking for immediate work to pay off some student debt, figuring that I could reevaluate grad school in the future (though I have not seriously reconsidered that, as yet).

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

JC: I went to Allegheny College, which as mentioned previously, only offered a theory-heavy Computer Science program. It wasn’t really preparing me for software engineering per se, but it definitely gave me a great understanding of what happens in the lower layers of computing systems. I ended up landing an entry level software developer position at an Electronic Data Capture (industry term for clinical trial data) company in Pittsburgh. Working mostly on resource-constrained devices, such as PalmPilots and early-iteration Windows tablets, and coding in a proprietary scripting language, I honed core analytical development skills, albeit at the expense of learning industry-standard tooling. So this definitely set me up on the path to being a generalist as opposed to a specialist in a particular programming language.

After running out of room to grow at that company (I had been there for six years without much movement), I got an offer to be a Test Engineer at Autodesk, where they were building a QA team from scratch. At the time, I didn’t think that working on the testing side would be a long term thing, just a way to make my skillset a bit more marketable. But I didn’t realize just how big of a void there would be for test automation engineers, and how important and rewarding that this work actually was. And it is really an entirely different set of skills that you need to succeed in that type of role, so I have come to embrace it. Since then, I have chosen newer, smaller companies in search of people to build test tooling from the ground up.

Q: What does your typical day look like?

JC: I have several different types of responsibilities, and they come and go in spurts depending on the priority. Much of the time, I am running and rerunning tests, examining results, tweaking parameters; repeat. Secondly, adding new tests, building new test features, or integrating the tests with other tooling is the most invigorating for me. I try to keep the next of these tasks on my radar so it can marinate in my head for a little bit, which helps with the kickstarting process. The third main thing I do is pick up customer or demo work from time to time, where I usher data through our pipeline. As our system gets better, both from machine learning and user experience standpoints, this is gratefully becoming less time consuming. So as far as my typical day, it’s usually spent on 1-2 of those three things.

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

JC: I just finished doing a lot of groundwork to integrate our tests into Gitlab CI/CD. Modifying our test runner build scripts, writing a utility to run a job on a specific docker image, and configuring YML to run the tests. The goal is to get more automated, regular, and remote for test runs, which will help us be able to reduce investigation iteration times and keep us from having to initiate the tests manually.

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

JC: There are many skills that make a great software engineer, a lot more variety than people would think. Because most people tend to focus on the solitary, analytical skills, I would actually point out that being a great collaborator is one that is very easy to overlook. Talking with developers, designers, testers, and stakeholders about requirements, scoping, and roadblocks is a daily high-attention task.

I am a huge supporter of pair programming, and doing that effectively is a learned trait. Most written lines of code are complex enough that they deserve, at a minimum, two fully attentive brains at some point or another, anyway. So when done correctly, pair programming can be far more efficient than the write-and-review-asynchronously model. Together, at the same time, both parties get to decide on variable names, what gets outsourced to another function, what deserves a class, what should be written up as a separate story, etc. Staying on task, avoiding memory or context switch costs, and direct face-to-face communication (virtually or otherwise) pays back the double developer time many times over, in my experience.

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

JC: For most of the testing work that I do, we have decided to take a top-down approach to evaluating our system, putting priority on how the aggregated end results stack up against our expected results when running data through our pipeline. So this presents a couple of problems that more traditional automated testing, unit testing and API level testing, is able to avoid.

Firstly, we are talking about testing algorithmically complex components that run for hours at a time. So long feedback iterations and resource bottlenecking are challenges that we are actively looking to solve with CI/CD and EC2 integration.

Secondly, the evaluations themselves are not binary. That is, there is no easy pass/fail criteria to judge by, because the results both are non-deterministic and progressively changing with algorithmic improvements. Writing more and better comparisons takes both time and expertise of the algorithms themselves. In addition to that, we rely on getting information on how the results have changed since recent runs, asking what could have produced those changes, and then judging if that result is acceptable.

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

JC:I have to add the caveat that I am not heavily involved in our machine learning operations. But when I think about the future of AI, I imagine that the data collection aspects are going to be more seamlessly integrated into our lives, for better and worse. Nearly every human task is going to be harvested, which will undoubtedly result in a lot of things that are a huge benefit to humanity. But there are obviously loads of privacy and social engineering concerns that we have yet to really deal with as a society. So I believe that we need to prioritize ethics in computing, particularly in AI.

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

JC: I am a guitarist. I just bought a Strat-style guitar made by a local luthier, Buccicone Guitars. Really quality instrument that has me playing a lot more often.

I love cooking, and lately I’ve been getting more into process-oriented stuff, like smoking BBQ and building cocktails. Trying to get away from recipes and more into using your senses to cook. Things like salsa, hummus, or mixed drinks are a perfect way to practice those skills.

Books I’ve enjoyed recently: Safran Foer’s Here I Am, Johann Hari’s Stolen Focus, Neal Stephenson’s Baroque Cycle. Next: Octavia Butler’s Parable of the Sower.

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

JC: The importance of naming things in software development, and keeping functions small and single-purpose. To be very clear, I’m not saying I wasn’t taught these things, but I am answering the “learned” part of the question literally!

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

JC: Two things the Pittsburgh technology community is known for are healthcare data management and, when you think about autonomous vehicles, the Lidar scanning and photogrammetry space that Allvision is squarely within. My career path has seen me hop back and forth from these spaces so far. And these two industries could not be more different with respect to technical stack, how they are regulated, and the main drivers of the technology. So I have been exposed to as broad of a range of experiences as you can get within the software industry.

Bonus Question: Any advice for engineers in a startup?

JC: I would say be expectant of frequent, impacting changes. This works for me because I have a change-averse personality, while also realizing that change is often necessary to avoid getting too comfortable or stagnant. So being in an environment where changes can happen outside of my direct control is good for my mental health. Learning to not be scared of change is half the battle there, because sometimes this change is really negative at face value. I’ve lost two jobs in the last 5 years from a company closing and another dissolving a team. But even these types of events really help you take a step back, figure out where your career is going, and grow as a person.

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