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
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.
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 flipside, 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.