Job: Prism.AI a computer vision SAS company

Working at Prism.AI was my first experience in a more formal software engineering position at a primarily software company. And it was luckily also a startup that would tap my prior experiences (in project management, research, and so on) and give me the ability to flex my muscles, test my metal, and learn more than I could ever imagine from the talent that surrounded me 🌈

Design Eye

Being a consumer focused software as a service company that’s trying to make computer vision approachable, product design is a super critical component. And while we do have APIs with the intent to keep in mind the developer experience, still the user interface will be the huge driving factor to quickly introducing people to what Prism.AI is capable of.

This was a very green field area where I had the opportunity and freedom to explore various possibilities for what the product could be, and I excitedly came up with so many ideas, but also many of which needed to be cut down. And this is the core problem for many companies, you could easily come up with all sorts of cool things, but it doesn’t mean the cool things actually solve problems for people. Luckily I had a good mentor who would gently correct these misconceptions (clearly cutting down someone’s idea could be brutal 😂), and told me to focus on the use cases (the actual problems) rather than hold onto shiny solutions. It’s a simple lesson to learn, but still an easy mistake for anyone to make in practice. However, if you just try to justify yourself, you’ll know what you got when your hands turn up empty.

The frontend Middleman

Now once you have the design, it’s time to put it together in the frontend, which no matter what scale your product runs at always ends up equally complicated since its totally defined by the complexity of your product, and the product grew. It went from something I could handle myself to something that required multiple collaborators for design and implementation. Also the frontend has this interesting situation of sitting between the product design and backend while having responsibility of maintaining and building the frontend. Overall, I can tell you it’s not a trivial job.

What’s interesting is that I would say the most important thing to making this work would be keeping an open-mind and Github issues.

An open-mind is vitally important in any case, you won’t have all the right answers all the time, I won’t say I did. But when you’re working on the frontend, you’ll need to listen to feedback across the organization and synthesize it together with what you can do to produce an answer. They’re going to tell you, you gotta do it this way or that way, but missing feedback means it doesn’t meet the product requirements or isn’t supported by the backend API. Sometimes what the product design people want and what the backend guys want conflict, and it’s your responsibility to coordinate and manage these conflicts. This is why I use the link in the chain analogy for the frontend, and why you need to keep an open-mind.

Now I regarding Github issues, I don’t want to live life without Github issues. We used it to keep track of all the bugs that would turn up, divy up bugs and new features for implementation, suggest various structural changes to the code to keep things cleaner, and overall concentrate the conversation. But at the same time, we’d use Github issues to communicate the bugs we found and the features we needed from the backend. And at the end, we started to bring in the design team to Github issues as well to create a single repository of everything that was happening or needed to happen.

Backend black box

Seriously often times the backend will be a black box even if you’re working on the backend. Working on the backend, which I did do a bit, can often times mean you’re just working on a tiny cog in the much bigger machine through its internal APIs. Or while I was working on the frontend side, was just working with the backend through its external APIs.

Although one particular skill whenever working with a black box is asking the important questions regarding the black box relevant to its application. This is a problem faced by anyone who doesn’t understand how something works but needs to use it anyways and needs to understand just enough of it to understand how to use it without screwing up.

Now I faced this to some degree while I was working at Genia, but I always either had some idea about how it works (my broad experience in molecular cell biology, physics, chemistry, etc) or I didn’t need tight integration with how it works (the software that processed the electrical signals into a DNA sequence was a black box I just used and never had to pay attention to).

However, with our backend something as simple as extending the range of the query from a few minutes to days can have obvious implications. Just because you can technically doesn’t mean you can. And they won’t really see the issues until they see queries choking up the servers.

The same goes for asking for features or changes that they may respond with a yes or no answer, but has an answer more complicated than you could understand.

Also unlike natural phenomenon, human constructs (software) can have a wide variety of behaviors. The same thing on the surface can be implemented in various ways with different restrictions underneath.

But Still you need to ask the right questions and understand just enough about the black box to understand how to use it. Many leaders have to do this all the time, and this was a humbling experience that made me appreciate how hard it is for them.

Another unexpected journey

When I joined I wasn’t sure how long I’d stay months maybe? Well I stayed there for two years. I shared a lot of laughs, learned and practiced a ton including a more open-mind and humility, and built a bunch of stuff including a google assistant demo that looks like it came out of sci-fi CSI movie. It was an amazing journey we shared together.