Last updated on 22/02/2024
Hi, I’m Jordan Thayer, and I’m a research scientist by training. I got my PhD in 2012 from the University of New Hampshire, where I focused on Artificial Intelligence. My undergraduate degree was in Computer Science too; I got that from Rose-Hulman back in 2006. I’ve been programming things for about as long as I can remember. I think my first real exposure to programming were those library books that had ‘games’ in back that were really just entire adventure games written in quick basic printed in an appendix.
For nearly twenty years, every paying job I’ve had involved writing programs. So, what’s next might shock you as much as it shocked me. I wasn’t really a software engineer. I can definitely write programs. I can even take a problem statement and convert it into a piece of software to solve that problem. However, the program was almost always a byproduct of the work. I was writing grants, presenting new algorithms, and very occasionally rolling something promising into a product that was more a proof of concept than anything else.
I didn’t really appreciate the difference until my current employment with SEP. I’ve spent the last nine months interacting with people who are software engineers by training and trade. In that time I’ve come to think about myself as a non-traditional non-traditional developer. I have all of the formal education of a software engineer from a traditional background, and then nearly another decade of formal education on top of that. My programming experience is dominated by solo-projects in weird technologies. These projects did exactly what I needed them to do, but they’re also fragile and filled with suspect design choices. I went for five years programming for a living without issue tracking or code review.
So, I’m a non-traditional non-traditional programmer. I understand the formal backing of programming better than most. On the other hand, from a process and practice perspective, I’ve got a lot of blind spots and bad habits. So, let me tell you then from that perspective, my perspective, five things I’ve learned while working with software engineers over the course of this year.
Communication Is Difficult and Critical
I think about problems differently than most programmers I’ve met. Not better, not worse, just differently. When I’m building something with them, we have to come to a shared understanding of what we’re making and why it’s the right thing to make. Building that shared understanding of the goal and the plan is probably the single hardest part of building software in a team. When a project is small and backgrounds are similar, you can lean into some of the shared understanding that comes as part of being in the same cohort. As the scope of backgrounds, experiences, and the project grows, effective communication becomes more critical.
Backgrounds Are Extremely Varied
When I worked in labs, the background of nearly everyone I interacted with differed only in where they did their PhD and who their advisor was. How we approached work, how we wrote papers, how we presented findings, all of that was just the canvas on top of which we painted our individual stories. Those things seemed like large differences then, but in hindsight I appreciate they are no differences at all.
In a given day, I may work with people with formal education in computer science or no computer science knowledge. I work with people who are primarily concerned with the technical functioning of the product and those who are mostly concerned with how the users perceive it. Some people are in their first careers and others are on their third or fourth. This giant disparity in backgrounds helps produce well rounded and thoughtful products, but it makes communication harder and more important, as previously mentioned.
Hard Technical Problems Are Dwarfed by Hard Social Problems
My previous work focused on “Can you do this?”. No matter what we were doing, the technical hurdles were the largest hurdles we were dealing with. Now, I find that social problems are the most frequent and hardest I encounter in a given day. As I already mentioned, communication is hard. Being considerate of and valuing other peoples’ backgrounds and experiences is hard. Learning and navigating within the culture of a new team or client is hard. Being mindful of how a product will impact the user itself and as part of a larger ecosystem of products is hard. None of those are technical problems; they’re social problems that have to be addressed so that we can understand and excel at the technical work in front of us.
Proving Something Is Possible Is Barely a Start
As I said, “Can you?” was previously the start and end of the justification for my work. Knowing something was possible was the goal. When focusing more on product, “Can you?” is just the start of things. Should you? Is it reliable enough? Is it affordable? Is there a cheaper alternative? These questions immediately become critical.
Algorithms Matter, But Presentation and Interaction Matter More
Beyond questions of feasibility are questions of fit and experience. The best algorithm in the world isn’t useful if it drives a terrible user experience. As an academic, I would sometimes see a talk where user experiences and interaction were mentioned, but this was almost always as an afterthought. Software engineering flips this, and puts the user first. Software isn’t useful if it isn’t used. The way to get people to use something is to make a product that provides value to them and to make the experience of interacting with it pleasant. That second part, ease and experience of interaction, is the more important of the two.
Conclusion
As a researcher coming into the software engineering world, I was prepared for a bit of change. Even though I knew coming in values, experiences, and approaches would be different, I still experienced some culture shock because I’d failed to appreciate the magnitude of the differences. There’s nothing bad about that shock though. If your goal is to see your research impact people, getting it into their hands is one of the most reliable roads there.
On the flip-side, being exposed to different perspectives and values as part of developing software for a product has given me different lenses with which to evaluate my research. It’s good to know that a new algorithm is more performant than previous approaches. However, it’s better to be able to evaluate that in context. Specifically, the context of their ease of implementation, testing, and description. I wouldn’t have had that perspective without my experience working with software engineers.