Kyle is joined by his former colleague Tyler McEntee, now a senior software engineer at Jona. They talk about the many hats he wears on the job and off (he once sent homemade hot sauce to testers at Stack Overflow), the guts of the gut biome evaluation system he works on, and the pleasures of a statically-typed language.
Jona provides an AI-powered gut biome test for clinicians and patients alike.
Connect with Tyler on Twitter.
[intro music plays]
Kyle Mitofsky Hello. Hello. Welcome back to We'll Be In Touch, a podcast about job interviews, career development, and software engineering. Today I'm talking to Tyler McEntee, senior software developer at Jona. Hi Tyler. How are you doing?
Tyler McEntee Well, Kyle, how are you?
KM Wonderful. Let's dive right in and maybe dive right in by going back. Tell me about yourself and how you got into tech. Like tell me your journey, how you got to where you are today.
TM Yeah. As a software developer, I kind of always knew I wanted to be in tech. Like from a young age, my mom taught computers, like Microsoft access level intro computer, intro to computers at college sort of courses. And so we always had computers around, always the nerdy kid, figure out what makes them work. And going into high school started toying around with programming, like on my own. I took a visual basic, I believe in high school we still had a course for it, and the advent of the Arduino really kind of got me into hardware as well. So I learned scripting and Python, playing around with Arduino to my friends, and then going into college, started as an electrical engineering major for one year. And then figured out, I just love writing code and so I switched to computer science and never really looked back.
KM Why don't you set the stage for where you are now today, what your current company is, big picture, what your company does, like you work at Jona. What, what's that company do? Tell me more about it. What kinda stage of growth you're in.
TM Yeah, so Jona is a microbiome health company and we sell an at-home testing kit that is a stool sample that you send to a lab. We analyze it and we have AI models that interpret your results. So generally based on the levels of certain organisms in your gut and what makes its way through your intestinal tract. And we can give you recommendations based on organism X. Have a high association to lactose digestion issues, maybe you can consider reducing that. And so as an engineer there, we're an early stage company. We only have like 11 full-time employees right now. I joined a year ago, and now we're just trying to get more customers, more providers, clinical clients, integrations. And yeah, as an engineer there, I do everything from Slack to deploying stuff on AWS, to writing product code, to everything you can think of, customer support, we do it all.
KM Already. I can see some specialization within there, right? Like I know how to write a website. I don't know about gut microbacteria or Biome. Right? Like how do you differentiate those roles within your company and which kind of track of development that needs to get done, did you kind of associate with? Or is it just free for all and everybody does a little bit of everything?
TM Thankfully, I'm not in charge of the microbiome knowledge. We have very intelligent AI engineers and annotators with varying medical degrees, postdoc, some in med school currently that handle the clinical knowledge. And then generally I specialize in product, so shipping features to customers, developing integrations, helping handoff from AI to products. So, we know how to package the results that our AI engineers come up with in a format that's consumable by our end users, who could be your mom or dad or somebody like a physician or a nutritionist trying to help somebody with a specific issue. There's a wide range of people who experience issues that are coming to us.
KM Walk me through maybe what the architecture of that is, because then there's a lot of different people or roles within the company, but you have that data stored somewhere. You need to get it to a user. Like at some point that data needs to get put into the system and tabulated, or figure out what those markers and indicators are. Just kind of using that lifecycle as an excuse to talk about the architecture of your system, where does it all go and how does it get there?
TM Yeah, it's a fun journey. So in general, like it all starts with the customer ordering a kit. Generally we ship a physical box to the client or customer. They take the sample, mail it back to our lab. The lab does a certain level of sequencing and then provides us data, the cloud over Amazon S3, and we have a bunch of event handlers that pick up that data. I pass it off to the AI model to help generate an end report. That model then can send that report back to APIs that I work on to transform the raw scientific output into a more normalized database schema so we can present certain parts of it easier, make it easier to query. They're not large by means of data that I've worked with before. Like I've worked with many gigabyte large images before, but the breadth of it is pretty impressive. There's 21,000 plus organisms in every sample, and they all have relations to different clinical knowledge. So we generally organize that in a document database. We use Mongo Atlas for handling the actual reporting data. And from there we have a varying number of web apps, complete redesign of our web app. It's written in Next.js, all in TypeScript. Various express based APIs to handle async tasks, Kron jobs, all of that stuff that then gets presented to the user in a web app. And then from there they interact with the web app, plan their diet or actions from there, and hopefully order another test in a few months to see how things change.
KM Very cool. This gives me so many different things to poke at, right? Because now that there's the architecture, I like each one of these are interesting decisions that got to this point. So even like maybe walk me through a document DB storage. This kind of makes sense, right? What? Why have 21,000 columns on a SQL table? Throw it all in one document. You don't have to join maybe to other pe this is, I want my report fetch me the entire thing for my report. Is that kind of like that's what makes NoSQL a really good fit in that case? Are there other things or other trade-offs that you guys considered?
TM Yeah, there are definitely trade-offs with using a more schema-less design, although we do have guardrails in place. So in general, like when I first joined, the first version of the app had the entire report as one document in a database, and the performance to query it was making targeted updates was a nightmare. So one of the first things I did was break that up into areas where, okay, we'll store your symptoms or what we call health concerns in a different table and your organisms that we measure. And it's not just like, okay, here's the organism. It's the organism, the level that it was measured at, descriptions about it, stuff that can change normal ranges across the population. Like, okay, so if, if I have some certain abundance as a percentage of this organism, where does that, does that mean high or low? Like what does it mean to me? And so there's a lot of contextual information that is along with that. And by breaking these up into their own documents, in their own tables. It allows us to more targetedly query for things that we need. There are times where we do need like a relational database for these things. We make it work with Mongo object ID references is one way that we can help join all these many tables together. I mean, we also use libraries like mongoose and type goose to help define like schema in code so we can adhere to what we're putting in and taking out of those documents. So if I'm writing like a version three of my report schema, I know that when it goes in and when it comes out, it matches a certain schema, where if you're not using that and maybe it's a little more freeform, you might run into issues where what you're pulling out isn't exactly what you expect. So that's where things like types really come in handy.
KM Yeah, we are not fully schemaless. There is a schema. I do expect a structure of data out. It's just not enforced. Maybe at the database layer, Mongoose like works prior to the data, it just vets it going in. But the database itself could truly, if you want, if you had right access, you could do some stuff that Mongoose isn't gonna be happy with. Right.
TM Yes, exactly. Yep. Then you get runtime errors if you're not, if you're not careful. But yeah, Mongoose is an ORM, so it helps you build models in JavaScript and query them. Do things like, instead of writing Mongo aggregation pipelines, which can be this big array of nested Json-looking instructions, you can do it more fluently with dot populate this field, dot select this field. Kind of get more into like, like a sequel-ish RM wrapper at the code level.
KM I think you mentioned this a little, you were talking to me about this beforehand. Folks are all in on TypeScript it sounds like. Front end is gonna be TypeScript React next backend, TypeScript in next. Database TypeScript via Mongoose and then maybe even the technology you use for IAC using A-W-S-C-D-K. Is TypeScript like how you are doing IAC?
TM It pretty much is top to bottom. Yeah. I mean our AI engineers use Python for everything, but yeah, even somebody who is relatively new to TypeScript, even coming into this job. Even new to React, like I had to learn a lot of stuff fly, but coming from languages like Doc, like Lexi, C Sharp and, and other statically typed things, it's just, I just love a type system and I can change and interface somewhere and know all the places in my program that I need to go update it. I love that sort of security that comes with it. There are also downsides where you are like, you know, these types match, but your local language server isn't being as operative. And so in vs code, I like to restart that like maybe 7,000 times a day at times. But, but yeah, in general I think it's a net win and also allows us to share code. It's really kind of the big win for me is having it from your infrastructure as code all the way down to your individual client components. Like we can share types, interfaces. I have a shared package that basically exports all of our database connections so I can, I don't have to stand up a new ORM in a new app and copy stuff and keep schemas in sync. Like it's all in a package, an MPM package that I can just consume.
KM I mean, another way you could architect things is have like, let's say, JavaScript on the front end, C sharp on the backend. I still need to pass information maybe between those two systems. But now I cannot have a single type or definition of a class that is the same across those without translating with them, without doing something. Do you think there are advantages to that approach or are you kind of, you're not hitting a lot of trade off here by going all in on TypeScript across the whole stack?
TM Yeah, it's, I think it is like a personal preference thing too. Like if you got started in JavaScript and are used to like the more dynamic features, like yeah, I can just be like, I just prefer this. But I just love being able to, like I said before, change one interface, like I'm renaming a field and all the way down to my front end, I know what I need to update or change and a lot of things I can just automatically apply it because we have those links between where we're using these types and these. It just comes down to, it's just familiarity when reading code as well. That really helps. It's less context switching in my mind. To have things be the same, and also we deployed as where we store everything as a big monorepo. So having one language definitely simplifies like the tooling upkeep. Making sure like, I only need to make sure I have, I support one version of TypeScript. I'm not like, okay, well we're on dot net core whatever for this and, but this thing over here, it's a little bit older, doesn't support it, so we gotta be on a different version and then you're up. Then you have to update all your CICD pipelines to make sure those have the right versions. It just simplifies everything.
KM Sure.
TM Fewer decisions to make and when you have so many things to do, fewer decisions to make just increases your speed of delivery.
KM Sure. You said recently that you were working on a project to redo the front end application for this. Can you tell me more about the parameters of that project and what your role in it was?
TM Yeah, so our old web app was a pure React single page app. It was a create React app, but pure React front end only, client side, everything interacting with an express JS backend. And it was just outdated, it had a lot of cruft. I liken it to a very good proof of concept. It helped us get launched, helped get people onboarded and as a good vehicle for getting those first few users, their input. And then beginning of this year, we had thoughts of doing just a redesign, and we thought it would be better to just completely cut over, start something new from scratch. Most of the data was staying the same. So we didn't have to change our entire pipeline, but the presentation layer being a little more interactive, a little more robust, so we needed that server side rendering. We really wanted better off controls, dealing with authorization and an SPA can be kind of a pain. You just have to inherently not trust anything. There's a lot finer grain detail that I feel like we can ship faster. Next JS is the platform that we went with for this one, and all in all, like it was a good start, a good fresh start with some new designers as well. Like we didn't have designers before, so you got what I was interpreting designs to be, which is not great. I'm not a designer. And yeah, started fresh with our own UI library, all with tail end and shadcn components and we built this nice little sort of Jona specific component that we can use across our apps.
KM You're a smallish company, right? Still, in growth phase.
TM Very small. Yeah.
KM How many other people were involved in that project? Like what was your role relative to other people? Are you doing the whole thing? Are you PRing stuff with other people, other developers, and there are other hats being worn as well, not just dev hats?
TM Yeah, there's a little bit of everything. The entire company was really on this at some level, whether it came from marketing, showing demos to people, like our CEO and head of Business traveling to present our new designs to get feedback. All the way down to, we brought on some contractors to help with that, who I actually worked with at a previous company, to help work with building out more of the front end. We hired a front end engineer as well. And so then my role was kind of like, I don't know, traffic director at some times. Me being the primary interface between the AI improvements and changes to the report schema, most backend things, deployments, anything that touches AWS kind of went through me. And then general front end work was done by a team of, at one point we had five, four contractors and a staff member who's full-time, front end. But yeah, all working together, all doing prs, reviewing each other. It was a big push over the summer to just about a week and a half ago. It kind of comes down to we all had a hand in various ways. Our director of product was like a godsend in helping keep people on task, where like our contractors are in Hungary and so then it's sometimes the handoff can be interesting. You gotta make sure everything is ready, can’t message you at two in the morning to ask like where's the API schema for this thing? So it required a lot of due diligence in preparing handoffs and reviewing and keeping up to date. But yeah, I did a little bit of everything. It was kind of a blur but a good way to get a breadth of experience, that's for sure.
KM Congrats for shipping a big launch, by the way. That's always a big grind to button up stuff and get it ready. Speaking of breadth of experience, right, you said at the top of the hour, it's like you do a little bit of everything. You do some customer support. But then it's not often that we have somebody who is a developer at a company who is both bridging customer support in one meeting, and then in the next meeting, going and talking to the CEO. Those are two very opposite sides maybe of how you interface with the company and the consumers of that company. How do you think that impacts the way that you do development and how you prioritize features? And how that kind of fits into the development strategy that you have?
TM Yeah. I find that speaking to customers has illuminated so many workflow practices in my own, like personal and professional life. Like I'm not the end user of this software. Like, yeah, I have a kit and I have taken the test and I'm interested, but I'm not a provider trying to help hundreds of people looking for answers for people who maybe have spent years of their life trying to solve. It's not just like curious people we have patients that come through that like, yeah, it's been decades for them. They're trying to find answers. One is a way to connect, like on an emotional level with people. Sometimes technology can be very frustrating. What's easy for you and me is not easy for everybody else. And so speaking to people that are either having issues or just don't know what to do can really be rewarding in that aspect. But just in general, it's like you don't generally know what your customers want unless they tell you, and it's hard to get feedback without asking for it. So just general customer support things or maybe talking with a provider who wants to join Jona but isn't sure or, yeah, everything from like, I can't remember what my password is, can you help me reset it? Like, you know, little things like that. Being on support kind of helps see where the squeaky wheels are, where you need to work on. I think it's given a lot of great ideas for what we need to work on next. And I think it's something that everybody should do because you can become divorced from the people who are actually using your software pretty easily. I would say it's pretty rare that somebody is like in my shoes, where they're doing all of these things, but that's also just where I personally like to be. I like to be able to do different stuff almost every day.
KM Very cool. Let's laser in and just look at the tiniest littlest bug, an interesting thing that you fixed in the last week. I know you're shipping a big product, but a big product is a hundred different, tiny, little annoying things or maybe fun problems to solve that had to get solved along the way. Can you think of one of them? And walk me through what the problem was and how you solved that.
TM Yeah, so with this new launch, a new feature that we added was the ability for your responses to our intake survey to directly influence the output of your report. So generally we were agnostic, so whatever was presented to us from our lab, we would show to you. But we have some things that are specific and recommendations that can be done on a BMI basis. So based on your height and weight, our recommendations can change. And so, look at some papers that we've annotated, and our AM model has, key on those things like, okay, so for subjects who have a BMI higher than X number, this going recommendation, or we noted this. And so this process is, to regenerate a report, isn't super simple. I mean it's not super slow, but it takes about a minute. And what we were doing was, we were a little bit optimistically regenerating a little bit too much, and it uses GPU resources and costs money. So a bug was essentially, as somebody was paging through their health survey, it's like four or five pages, every time they would hit the next one, it would try to regenerate a new report. And so I just was seeing through our logs after launch like, ‘oh boy, we need to fix this so we don't spend a ton of money doing this’. And so, yeah, a fix was just to be more targeted in when we actually do those regenerations. So only if it's a field in the intake that actually would markedly change your report. So putting in your name, if I just change my name or my birth date might change it, but reporting certain things like my sleep right now, my sleep quality, we don't need to regenerate for that, so let's not. So it cut down on those a lot and it was a relatively easy fix, but showed the importance of things like monitoring logs. It was an obvious outlier after launch that we were regenerating reports a little bit too often. So, I identified the fix, pushed it out like the next day, and it's been a lot quieter since.
MK What kind of extensibility do you have there? Because maybe in the future you work some feature in where sleep actually does influence the report in some way. Is there something akin to an attribute on each of those fields that say ‘this is worthy of regenerating the report’ or not?
TM Yep. That was part of the solution was to actually key in on those fields. I had an inkling when we were writing it that it would be good to do that anyway, but I figured people wouldn't be changing their intake that often. And that's what happens when you assume what your customers are gonna do, and they were changing it pretty often. So that's another case of listening to your users, whether it's via their actions and logs or monitoring or directly talking to them.
KM I also think it speaks to, there's this hard trade off between if any one computer thing is gonna take a minute and the user wants to click and see it right away, the more pre-generation you can do, the better the user experience. But when you over optimize in that direction, then maybe they didn't even click on it and all that pre-generation that was just cost and just getting ready for the user experience. So it's hard to dial that in perfectly to optimize both for cost and the ideal user experience, that they're not waiting and sitting looking at a spinner.
TM Yep. And that's also the benefit of shipping early and seeing how people use your software versus trying to theory craft about how somebody could possibly. We could have spent hours coming up with all the use cases for when something would happen and somebody would find a different way. So it's not like ruinous amounts of compute that we're wasting here. Like it's in the grand scheme of things, it's really small, but it's just noise and we don't need the noise. We don't need to be rerunning these things. And also as an avenue to introduce maybe some new things to our system, like more event based processing. So, instead of me just directly invoking our model to regenerate a report, I stood up some topics, some SNS topics in AWS and some cues filtered them by event, and then now I have this whole event bus where I can targetedly pick which events happen and get redirected where. And it's just a really nice building block for an asynchronous backend to allow me to, from a command line, send a request to generate an email to somebody without necessarily having to hit any actual API. Like I can just post a message to an SQS, some lambda function will fire off an email. And it's really useful because in these asynchronous event systems, like you will drop messages, you will lose things, it's hard. So any way that you can rebound or replay, or even targetedly rerun certain things is a real, real big boon to productivity.
KM We've mentioned a lot of AWS technologies up until this point. We've mentioned Lambda and some database stuff, and so y'all do some infrastructure as code. Can you just tell me from your, like baseline it, right, tell me what infrastructure as code is? And what maybe like the benefits or costs are to that as a concept? And then maybe we'll dive more into some specifics of how y'all are doing it.
TM So like in its essence, infrastructure as code is literally what the name implies. It's like the makeup of your services in some sort of cloud or across the internet. But the makeup of that, the instructions for how to get there, are defined in code, whether it's explicit, something like Terraform, where you have essentially YAML that describes like, ‘okay, I'm gonna create an S3 bucket’. They have their own language for permissions policies, and you can just run a command line and it'll go make that bucket, make it public or not, assign a certain user permissions. And then you don't have to actually go in and what you call ‘click ops’, go into AWS console and click create bucket and type things out. You can automate. And then getting down to the level where I use it is: today I'm using A-W-S-C-D-K, which is the cloud development kit. And it uses AWS SDKs and cloud formation, which is their own AWS syntax for making changes and describing an environment. But it interfaces that with TypeScript and so you have an entire, or Python or Java, they have a bunch of different SDKs for it. But I write TypeScript to describe how I want my systems to be deployed. So everything from networking, load balancing, down to individual lambda code functions, cron jobs, anything you could think of in the AWS ecosystem, you can write it in TypeScript and deploy it. And not only deploy it in just one environment, you can abstract things away and deploy. Like I use the same commands to deploy to any one of our environments. I could stand up a whole new instance of Jona from top to bottom in a fresh AWS account, in less than a day. And that really kind of opened my mind to the power that a developer, like an end user, your general like I'm creating crud APIs, like I can deploy this stuff. I didn't need to learn Terraform. I didn't need to become an AWS expert. It helps to really know that the cloud under the hood. I had previous jobs that I used at AWS extensively, so I had that knowledge already. But these tools really, really help with productivity and just help maintain strict adherence to whatever you want in TypeScript. So I can, I can use four loops. You can't do that necessarily in Terraform. Like I can create one instance of a database and then create a bunch of different test clients to interface with it to run jobs, without ever logging in AWS. And that's just really, really nice.
KM Yeah, I was just gonna say, so you have the full power of type. I mean, maybe for better or worse, and I don't wanna talk code too much, but it's something like import Lambda from A-W-S-S-D-K, right? I import it and now I have access to Lambda, and I can go, ‘Hey, I want new Lambda dot function’.
TM Pretty much, yep.
KM And that's as much code as we're gonna do on a podcast. But if I wanna have 10 functions and they just say, ‘function one, function two, function three’, and I put that in a loop that has an array of 10 items, I can just go initialize 10 of them. And if I had something more sophisticated I wanted to do with the sort of imperative code you can write in TypeScript, you could also deploy tons of resources that way I could do a thousand of them maybe accidentally too easily.
TM Yeah, let's say you need to provision some sort of cloud infrastructure per client. You can abstract away the things that your client only needs, and from an API create an entire new bucket for this customer, on the fly. And it's the same as the other buckets for these other customers, but they have their own one, or their own APIs, their own sets of permissions, their own data in their own accounts even. And so it just allows you to yeah, whether it's your own infrastructure or somebody else's, it's really cool. It's a really nice way to interface with cloud resources because they are so, like the breadth of AWS services is so huge and it's hard to really know to log in and navigate these menus. AWS built a console that is so hard to use that it basically created an entire industry of tooling to not have to log in to use it. And it’s incredible.
KM It is interesting when we talk about the speed of delivery, one thing that I feel like is sometimes I just feel like click ops is just, I can do it quicker navigating through and saying, going to that menu, and then it kind of gives me really nice UI for, as much as we'd like to bash AWS UI, right? It gives me a good enough UI to say, here's the property that you're setting. Here's all the options for it, right? And sometimes I've kind of held, especially for something like a hobby project where I'm just trying to get it off the ground, though that actually feels quicker. Do you feel like IAC here is, so I look at IAC as kind of the other end of maturity, that this is the opposite of a hobby project that other people need to be able to come in and know what I did yesterday or how many servers I deployed. And this is good to know. Do you feel that this stack and it structured the way it is, kind of gives you the flexibility of being able to deploy resources quickly and not take away from your speed of delivery?
TM Yeah, I think it depends on how in-depth you get and with specifically A-W-S-C-D-K, there is a learning curve, for sure, and I think sometimes the developer experience loop can be really slow at times. So there are times where I feel like I'm fighting my normal instincts to log in and do something. But, for personal stuff, there's even newer tooling that I think is even cooler that bridges that entire gap of ‘this is for serious work’ or CDK toolkits are for maybe developers turned ops people, and they don't wanna write terraform, they don't want to deal with the more like DevOpsy specific tooling. But this new framework called SST kind of turns the entire idea on its head of your application and your infrastructure being separate. It's not even just infrastructure as code, like your code is also the infrastructure. It's like a single file in your repo that describes how everything needs to be built. It's built on top of Pulumi, which is another code based CDK toolkit. Pulumi uses like actual native APIs versus using Amazon's public APIs or Google Cloud or whatever, CloudFlare. But what SST does is it also allows you to almost transparently link all these things together. So no longer, if I had a hobby project, which I do, I have a few little hobby things that I've deployed using SST. Where normally I would maybe create a React front end app and then maybe like a little Express app. Then I need to configure environment variables or something for the deployment for the React app, and then make sure they are stored somewhere secure. And so then I'm logging in and maybe I'm using parameter store or something, to store all these things, and I'm linking them together and I type one thing and I got the URL wrong and this is using an auto-generated URL blah blah blah. Literally in SST you just link my API to my front end and I can say the URL of this thing, hit SST Dev to try it out. It actually provisions infrastructure and allows you to use that dev loop instead of standing up everything locally, it actually provisions an S3 bucket or a Lambda function or an RDS database or something, anywhere. And proxies those requests through so you can actually try it out in the cloud. And then when it comes time to deploy, it is just another command. Like it's just SST deploy. And it's so hard to explain like how cool it is, having used both, like A-W-S-C-D-K. And then it basically like almost assumes that the role of the ops person is gone, dev should be responsible for everything end to end, and you can be a better developer because of it. And I agree to some cases, I'm somebody who, as all my answers have shown, I do a lot of different things. I like to try a lot of new things and I feel like anybody can kind of take on these responsibilities and have some agency in how your things get deployed. Whether it's a basic thing for making a public bulletin newsletter for my neighborhood tennis club versus a fully productionized web platform that can scale and can scale down to nothing too. It really uses serverless architectures as well. So if you're not using it, you're not being charged. And so there's some real benefits to how you architect that way.
KM You just again mentioned the breadth of programming topics that you have to go into at work, ranging from deploying infrastructure to doing some frontend stuff or backend stuff or database or interfacing with product or the CEO, or even customer support and simple like help desk tickets, right? All of those things are included. Maybe let's just think about some of the non-technical skills, but equally important skills when you are a developer, especially one in that role of time management, how do you manage your time to be able to prioritize all those things effectively? Like do you have any skills or tips or tricks there for other people or how are you doing it?
TM Man, this is a tough one because sometimes I feel like I have it all figured out, and then other times I'm like, what am I even doing like day to day? Where I had set out to do something and something else comes up, customer support maybe turns into a real bug that I need to go fix right away or whatnot. But really it comes down to, at Jona specifically, it is like a pretty, not necessarily strict, but a relatively decent adherence to the agile sort of working environment. So we're planning work for months, maybe a few weeks plus at a time. We have a pretty general idea. We factor in time for things, or things do come up like we're a young company. We can't like hand off, I don't have a QA team. I don't have customer support team. Like one of our annotators, who is reading scientific papers and annotating, is like our primary support contact. And so managing time, it’s really easy to get lost in things too. Just me personally, I get excited about writing something and I can kind of get into a rabbit hole. But having that thought in the back of your head of ‘is what I'm doing the most important thing I should be doing right now?’ And stepping away. Maybe you thought, I got this ticket done, but you know, I had a really cool idea I saw on Twitter, this really cool CSS animation for this button, and I want to go do that. It's trying to resist those urges to do things that are shiny and fun. To do things that are best for the company and your own career growth. So, I mean we're a young company. We're seed funded. So there is a risk of the company not being around, and so that is also a good motivator for like let's do stuff to help, let's help us, let's help our customers, let's do what's right every day. And really, for me, it comes down to our product owner helping keep me on track because I do have that ADHD developer brain of wanting to go chase the new shiny thing. Which comes in handy at times, like getting a wild hair and completely ripping out the auth library for our new app two days before launch and implementing a new one because I was getting frustrated. Like in the long run was the right decision, in the short term [laughter] I definitely would not have done it again, but it was the right move at the time. And yeah, it's just trusting your instincts and, as a team, aligning on what needs to be done and I think agile sort of methodology helps with that.
KM Very cool. And my last question for you is, we're getting meta here, what is your favorite question to ask in a dev interview? Say you're hiring in the near future, you have somebody come in, maybe the best question is something we've already covered today, but what's your favorite thing to ask somebody when you're interviewing them? And then also what's your answer to it? Or maybe I'll answer, I don't know, but we'll figure it out.
TM I really like, especially if I'm hiring, I guess it doesn't really matter who, but specifically like technical people. I like people that have a passion for what they do. It doesn't have to be your entire identity like, ‘oh I write code every weekend’. And I don't necessarily care about that, but I want people who take pride in what they do. So I like to ask like, what's been the most fun you've had on a project or the most proud thing you've shipped? And that usually is an open door into all sorts of questions you can get into about ‘Oh, like that's an interesting thing. Why did you choose that way?’ or ‘I would've thought maybe we could use this technology. What led you to that?’. It really opens the door and shows how people react to that, is more important than the actual answers. Like if they're like, ‘oh, cool, I get to tell them about this cool thing.’ It wasn't even like for work, like maybe I've been working in a place where I didn't enjoy what I was actually shipping, but in my spare time I ship this cool thing. So I like to ask that. And generally for me, it goes back to my first real job out of college. I was working at a manufacturing, like a rapid prototyping manufacturing company in Minneapolis, and we were just kind of essentially like frontline support c plus plus developers, like customers would upload these like part files, STL 3D models and we'd try to analyze them. Sometimes they'd break our algorithm or whatever and we'd have to do some debugging. That's essentially what I was doing day to day, debugging why this part couldn't be made. Well, there was like a homegrown cluster of computers. It's basically off the shelf Dell computers that they formed into this giant compute cluster to do map reduce operations, and any one of those computers at one point can crash and the application could crash. And a lot of times the memory dump from those would be very useful to help debug, but it was impossible to get to. It wasn't even really a task that I had, I just kind of did it on my own, of writing a service to go fetch those files, use wind debug to help get the stack trace and symbols, code symbols, to help point to lines in source where it actually failed and reasons. And then a little web app on top of it, learn.net that way. And it was just taking the agency to just like, I think this is something that we should have and I couldn't get a sign off to do it, so I just did it anyway. And it didn't hurt anybody. I didn't need to get any new services. I didn't need to request anything. It didn't cost any money to do. It just took a little bit of my time and it really saved, it saved myself dozens of hours a week probably. And in the grand scheme of a year with three or four developers doing that, like it was huge. But it just kind of showed me that you can do what you feel is right in that situation, and take the agency to kind of show what you can be a part of. And that really just jumped off into, ‘wow, I really want to be doing what I want’. And so from that point, I moved companies and found roles where I'm in these early stage companies, I really find kind of hits that niche of I'm not necessarily building from the ground up necessarily. I'm not founding a company, but I get to do a little bit of everything. So yeah, like how candidates respond to that usually shows how invested they are. And at an early stage company you need people that are really driven and really motivated. Because it's easy to get lost in a large company if you're feeling down or maybe you're just kind of lack of work and here it's apparent day to day, like right away. Like we talk to each other a lot about it. Like, ‘Hey, you feeling down, like what's going on?’. That kind of plays into that.
KM I'll also, just for fun, I'll take a stab at that.
TM Yeah. I wanna hear your answer
KM Anytime I'm asked a question about ‘what's your favorite thing’, I think it's way too hard to answer across time. Like my favorite thing ever. I think what's been my favorite thing in the last week or month? I think those are also equally interesting answers, and so there's a huge relevancy bias, and it's not shooting for the biggest thing I've ever shipped. But one of my favorite things I like shipping are things that I’m able to do as a developer that actually improve my life or make it easier in some way. And so my wife and I have a 1-year-old daughter and our daycare sends us photos every day in this app that has a web component to it. And it was our idea together, we wanted to make a collage of all of these photos over time, but they're in the app. I need to get them out of the app. And whenever I download them, they don't preserve any of the date stamps or like data in there.
TM Ah, none of the metadata.
KM Yeah, so the date is just the day I downloaded it. And so it's very hard to see, here's what she looked like in January and February or March. So, I just created a little simple, this is a need that we have, and like one brute force way to do it is just download the thing, go in, click edit, go select the right day for hundreds of days outta the year for maybe multiple photos per day. And because they have a web app, I can just go look at all of those things, inspect element, go figure out what the URL for this is. I still need, in order to be able to, from within the browser console, I can't control the file system really in a fine-grained sort of way. I can put a file there, but it just goes to the downloads folder. I can't rename it. I can't touch exif data and the original file create dates. So I wrote a little script in Csharp that goes and downloads these things, goes and sets the correct properties. Now we have all those things. And you know, writing it took like a couple hours, it wasn't a big deal, but boy did it save a bunch of time. Sometimes you write an automation script and you're about even by the end of it.
TM Yeah, yeah, exactly.
KM This was something, it felt like it, it actually saved me a bunch of time. Those are always my favorite projects to work on. Because it feels like I'm getting the value, I am the customer.
TM And the first time you run it and it works is like the greatest feeling in the world too.
KM Yeah.
TM That's the one thing too with getting into infrastructure as code, where there is still the loop of like, I didn't write the infrastructure as code. Right? And things aren't connecting. But man, the second you get that database connection on a private network and you actually like output, you're just debug printing like I should be here. And that shows up, like, man, those little hits every day. It's so nice.
KM Well, awesome. Wonderful, Tyler. If people wanna follow you or the work you're doing at Jona, where can they do that? And we'll put it in the show notes?
TM Yeah, you can check out Jona at jona.health is our website. That's primarily where you can find any information about the company. I'm @Tyler_McEntee on Twitter. Check that out there. I'll have the handle in the show notes. Thank you, Kyle. This has been fun.
KM Awesome. Well it's been great talking to you. I am Kyle Mitofsky. This is We'll Be In Touch. And Tyler, thanks for your time. We'll be in touch.
TM Thank you.