Day in the life with Nate Leonard
A software developer and data nerd.
Nate is a software developer at Solvus Global and also doubles as an entrepreneur who enjoys tackling challenging problems and bringing value to his work. Find him on LinkedIn, Twitter, or Github.
This interview is edited for clarity.
Jacob: Tell me a bit about your day and workweek.
Nate: My workweek starts off with a sprint… You know what a sprint is? You do sprints at your job, right?
Jacob: No… *laughs*
Nate: Alright, I’ll talk like I’m explaining this to someone that doesn’t know anything about software. You know how people always say “If you’re going to teach somebody something, then just pretend like they don’t know anything”? I’ll do it like that.
Jacob: Exactly, yeah, OK sounds good.
Nate: OK, so most software companies will do a two-week sprint, but my company does a week-long sprint. And what a sprint is, is just an interval of time where you get your tasks done. When you’re working on your projects, they break things out into sprints. Like on a project it’ll be “oh this project is supposed to be 6 sprints long or this one should be 10 sprints long”. So if your sprint is two weeks long and it’s a 6 sprint long project, then it should take 12 weeks to do. Again, in my company, the sprints are one week each so a 6 sprint long project should take 6 weeks. We’ve also got marathons about every quarter, so every 12 weeks.
So my week starts off on a sprint, but I’d say that my week really starts off on Tuesday. This is because we do sprint planning on Tuesdays. The sprint planning meetings set you up with your tasks for the week. I have three planning meetings because I’m on three different projects, they’re about 15-30 minutes long. Basically we just go over where we are, where we need to be, and what tasks will get us to where we need to be, then we assign tasks to people.
For one of my projects, I often can set my own tasks unless the team lead really has something specific that they need me to do. On the other two projects, usually my team lead will just give me a task, since they have something in mind for what the weeks goal is and what they want me to do. On one of my projects, I never get to pick my tasks because the lead on that is also the lead on all of our technical projects and he tends to continuously place people exactly where they need to be. On that project, I don’t really get any flexibility, while on my other two I can often say “oh I wanna learn this new thing this week” and get a task where I work on that new thing.
After sprint planning, we’ll have under/over scoping meetings. This is to account for how many hours are available in the week to divvy up tasks to and assign hours to those tasks. What often happens is that there might not be enough tasks, so someone might say “oh I need 15 hours of tasks” or someone else might be 10 hours over on tasks. So this meeting is where we say all these things and our scrum master will go through the whole list of scoping issues and try to reassign tasks as needed. Interestingly, though, about 6 out of 10 times when someone is asked if they can offload a task to someone else, they say “no, because I’m the only person that can do that task”. This is usually because they have some special expertise. There are even times where someone will say “I have a bunch of research papers to read” and the scrum master will ask if anyone else can help with that task. And they’re like “No… I don’t think anyone else is knowledgeable about spectroscopy.” So we just let them read their research papers.
An hour or so after that we have like a “sprint planning” meeting where we’ll break tasks into sub-tasks and assign hours to them. We use Azure DevOps for that and have a board with all the tasks laid out by hours for the week. Usually it’s not until after 1 on Tuesday that I’m really able to crack down and get to researching my tasks and figuring out how I’m going to tackle everything. I don’t really get to put undivided focus on accomplishing my tasks until Wednesday, Thursday and Friday, and I still have stand-up meetings every day.
Jacob: So what do you do in a stand-up?
Nate: In a stand-up our tech lead will go over all the tasks in a project. Then we’ll go around, say what we’re doing, how the task is going, about how much time is left and how many hours it’s already been. We’ll move our tasks around on the board to track “In Progress” or “Completed” or whatever. Sometimes it’s hard because you don’t know exactly how many hours a task is really going to take. There are occasionally situations where you’ll have 30 minutes left on a task but you know the rest of that task is actually going to take you a few hours, so that can get kind of awkward. It doesn’t help that the task board is tracking your time spent on each task. If you stand up in a meeting and tell them the task is going to take another 4 hours, they’ll adjust the board but they’ll also be like “So you’re not going to get this task done this week” and it’s like “I am… it’s just not going to look how you think it’s gonna look *laughs*”.
Unfortunately it’s really hard to see right from the start that a task is going to take a while. Often it’s towards the middle or the end of a task that it becomes clear that you’re not going to finish it on time. For example, I’ve got a task using D3.js that has been a 2 or 3 sprint long task. The data in this graph is in a dictionary and it's like the keys of my dictionary are dates and values are prices of scrap metal on that date. My lead wanted a drop-down menu where you could select weekly, monthly, or yearly averages for the prices of the scrap metal. It took me a long time to get this done because each sprint I was trying something new to get it to work. I really didn’t want to write some complicated functions to break up the data by week/month/year and I knew there had to be an easier way. So I spent the first sprint thinking to myself “What is the easier way?” and trying different things. Then I spent the second sprint drying a different method and came close to fixing it, only the year averages didn’t work. Now I’ve spent this third sprint fixing the year and I actually found an even better way and got everything to work. So now I’m very happy that I’ve finally got this task sorted out and I didn’t have to write something complicated.
Jacob: Wow, that sounds rough.
Nate: Yeah, I thought getting the averages would be hard, but luckily there was a function for that in D3 already, so I thought that was cool. But then there was still the challenge of “how do I break up these data points by week, month, or year?”. So that’s what ended up being tricky. D3 has some helpful functions, it just took a lot of research and digging into the documentation to find them and to get everything to work. And so now, I’ve realized that D3 needs you to hand-feed everything for it to work. For example, I had to go into the tickers on the bottom of the graph that show the date and manually write a function to make it show weeks when the week averages are selected, months when the month averages are selected, and so on.
Oh yeah, and then every other Monday we have presentations that we give to our coworkers.
Jacob: It sounds like a lot of meetings!
Nate: Yeah, I do have a lot of meetings. I’d say between 25%-50% of my week is in meetings.
Jacob: Wow. Do you find that all of your meetings are worth having?
Nate: Yes and no. I think that because of COVID we have to schedule a lot of things that could just be conversations in person. A lot of our meetings are just “Hey are you gonna get this done?” “Yep!” “Do you know how to get this done?” “I think so!”. So we definitely do a lot of talking, it’s true.
Jacob: *laughs* Yeah, so you mentioned D3.js, what does the rest of your tech stack look like?
Nate: Well, we don’t all have the same tech stack, and the stack varies between projects. For example one project I’m on uses .NET, react.js, and C#. That project is used across a lot of other projects, I almost call it like a LEGO-software. It’s this big, malleable software for the manufacturing industry. Basically, if you have sensors in your warehouse, they should be able to talk to our software. We’ve also recently added a Python interface to that project.
Another project I’m on is using react.js, express, and node.js. The third one I’m on is using Javascript, D3.js and react.js on the front-end. On the backend it’s Python, wrapped around a .NET framework. A lot of our stuff uses .NET. There’s even another project I’m aware of, that I’m not on where they’re building some sort of a mobile app.
It’s crazy cause there’s only 6 of us on software and the company also has a bunch of people in the lab doing all sorts of stuff with chemicals and robots and such.
Jacob: Oh wow.
Nate: Yeah it’s wild, there’s a lot of diversity in the projects and we aren’t even actually in the lab, in person doing things.
Jacob: Yeah, that’s really cool. So you guys also use git I assume?
Nate: Oh yeah we use git too. I guess I should’ve said that *laughs*. Our tech lead usually manages the git pipeline. We don’t break it too much but sometimes people push stuff at the same time and we end up with merge conflicts. It’s also hard to remember when you’re not alone on a branch, cause typically we are working alone on a task and each task gets its own branch. I also tend to have a lot of stale branches.
Jacob: Yeah, I have a project at work as well where there’s, like, 12 people that push to the same repository. It’s insane.
Nate: Ugh, that’s so stressful.
Jacob: It is stressful. I have a branch I’ve been working on for months, and conflicts keep popping up every time that the master branch gets updated. So I have to go pull the master branch into my branch, then there’s a ton of merge conflicts to fix, so I’ve gotta fix all of those. Then the branch is finally caught up to the master branch.
Nate: Yeah, my tech lead has set up this whole pipeline in Azure DevOps. I don’t even know how he did this, but he set it up so we have a main branch, and for every task you get your own branch. And then every time there’s a pull request it notifies you on Slack and three people have to look over it and approve it. But once those approvals are in then the rest of the pipeline is mostly automated. Our tech lead will occasionally step in and review a PR before it gets fully merged, but other than that it’s all automated. It’s impressive because there’s three different projects, all pulling and pushing to our git setup.
Jacob: Wow that’s really cool. So do you use Docker at work or no?
Nate: We did use Docker for one project. This was on the project that talks to sensor devices. We had to use it because we needed to use a Debian OS or other Linux distribution to set up a test environment for the sensors. It was cool because my coworker built most of the system just by virtually simulating sensor devices, and then when I got a Raspberry Pi we used it to test his code and it all just worked.
Jacob: Like “woah it works!”
Nate: Yeah, exactly! It was crazy, he wrote the code on simulated sensors and it also worked on the physical sensor. But otherwise we haven’t really used Docker. So that’s pretty much our whole tech stack. I know for other projects people are using other visualization libraries like Plotly and Dash.
Jacob: Yeah, that’s impressive that his code just worked. So what’s your favorite part of your job?
Nate: Outside of working with my coworkers, it would be getting to work on new skillsets and new technologies on different projects. Right now, I’m doing a lot of frontend and visualization type stuff. I like it because it’s related to a lot of what I did during my undergraduate career. I didn’t use D3.js, but a lot of it is still data visualizations, which boils down to pretty much the same thing. Plus, if you’re someone who does visualizations, D3.js is a great tool to have in your arsenal. So I’m really happy to get to work on it. It only gets frustrating when the tasks are complicated. Like right now I’m working on a set of functions to run on top of D3.js and will making it easier to create graphs. So this sort of highlights the double-edged sword of working on a startup: It’s great to get to work on so many things, but the structure is also lacking. I’m always wondering if I’m doing something the best way it can be done or if I’ve set up a task the right way.
Jacob: Right, so, in general would you recommend working at a startup or would you encourage someone to work at a more established company?
Nate: So, it’s kind of hard for me to say because I’ve never worked at a more established place but I’ve talked to a couple people who do. I have a friend who works at Amazon and another at Microsoft. One thing I have heard from them is that they are stuck maintaining the same projects. They don’t have much variance in what they’re doing. But, once you have a place like that on your resume you can easily go to a startup. It doesn’t always work the other way around. Like if I apply to a top company, I’m still going to get put through the ringer and have to work really hard through the interviews to get picked. So I guess I’d say people should spend their time wherever suits them best. I will say though that pay at big companies beats everybody else *laughs*.
Jacob: Probably! So then would you say that a person who is like “I really want to learn about as many things as possible and I want to wear a lot of hats” is a good fit for a startup and somebody who is more like “I know exactly what I want to do and I just want to focus on that” would be a better fit for a more established company?
Nate: Yeah, I feel like that’s definitely the case. When you’re at a startup they’re definitely not gonna let you get stuck in one thing. Since the team is so small you have to do a lot of different things. Like since I’ve worked here I’ve done stuff with react.js, D3.js, traditional backend development with .NET and so on. My eventual goal here is to build myself out as a full stack developer. I’d rather get a wide skill base and be full-stack and then narrow down later on whatever I want to work on. Right now I feel like I have the ability to just get comfortable with a lot of different things. Especially with our current tech stack, like we’re always going to work with .NET, so I’ve started to become pretty familiar with it. And in general, all projects will need to connect to a database. So it’s really cool to be able to learn about these things. Plus, if I were to go work at a top company, I’d want it to be Microsoft, so I’m really happy to be doing .NET.
Jacob: Cause that’s their (Microsoft’s) framework!
Nate: Literally, I’m like awesome! Even our project management is using Microsoft’s software. So that’s nice too. Something else my friends at the big companies mention is that they like their projects are boring and they say that it took them a while to gain the trust of the senior developers on the project. That’s very different from what I went through, when I first started during my first week I was already given real tasks.
Jacob: You were already having to do stuff?
Nate: Yep, there was not any time where I was sitting down like “oh I’m just gonna fix this bug”. From the start I was given full tasks and ended up contributing a full feature to the code, so that was cool.
Jacob: That’s awesome! So another question I have for you is do you think that majoring in Computational Science prepared you well for your chosen career path?
Nate: Uh, it’s a mixed bag because I didn’t think I’d be a software developer. *laughs* Like if I had ended up in a data science job then it absolutely would have perfectly prepared me for that. It gave me a lot of experience working with Python and using the data science packages. So for me, since my job is more of a software developer job and my company is a startup, they were less concerned with the background I had. They were just happy with my personality and were confident I could pick up what I needed to.
Jacob: Yeah you can learn stuff.
Nate: Right, and so that’s how it worked out for me. So I guess in my case, no the degree wasn’t that helpful for that. But if I had ended up in data science or doing ML stuff like you, then it would have been really helpful. Honestly a regular CS degree would have been perfect for the software developer job. So for grad school I’m gonna go back and take more CS classes. And it’s crazy to me to look at those classes and realize that I’ll use them directly. Like there’s a class on software architecture and in the first two weeks of my job, my tech lead was planning out the software architecture we were going to build. But, at the end of the day, a STEM degree is a STEM degree and my degree involved coding, which was luckily the main thing my job cared about. They wanted to see projects that demonstrated my ability to code and they were confident I could learn whatever else I needed. I was a bit of a fish out of water for the first few months, but now I’ve picked up a lot of it.
Jacob: That’s really good, I guess as long as you can code, solve problems, and learn stuff, then you can probably pick up whatever else you need.
Nate: Yeah, but our boss is also interesting. Like my coworker Caleb is a ML developer, but the tech lead wants everyone on the team to be able to do full stack development. His goal is if somebody is out that’s a full stack developer, then everyone else needs to be able to step in and help. So even though Caleb focuses on ML, he’s still been working on a lot of full-stack development stuff.
Jacob: That’s kind of cool. So pretend you’ve got a college student who’s like “Hey I want to be a software developer, what should I focus on and what degree should I pursue and how should I divvy up my time to prepare for being a software developer?
Nate: Right, so I’d say… Wait, the first question is what year are they?
Jacob: Oh, let’s say they could be a freshman or a sophomore but they’ve taken an intro to programming class and they’ve taken Calculus 1 and just in general they’ve done the very basics and they’re at that point where they could go major in math or physics or computer science or engineering or whatever.
Nate: Ugh, math and physics, that’s so hard. *laughs* But, I would say that what I’d recommend assuming that they went to Florida State University (like we did) and have access to our major (Computational Science) I would still pick Computational Science, but I’d tell them to take as many courses as you can in CS. The main courses, in my experience, you need from CS are intro to programming, object oriented programming, computer architecture, software architecture and software engineering. But really I think the best advice I can give is to pick a major you’re passionate about and that gives you the opportunity to learn how to code. I’d also say that by around your junior year you should have an idea of what area you do want to go into whether it’s development or ML or whatever. Then you can start to tailor your resume towards that thing with projects and internships. I didn’t do this and wasn’t really sure what I wanted to go into. It would’ve been easier if I did. And then, if you do go that traditional software engineering route, you have to do Leetcode. Leetcode or die!
Jacob: Very good, I think that’s solid advice. So tell me a bit about your company Private Receipt and what do you do there?
Nate: OK so as you know I work for two companies, I work at Solvus Global which is my main job and the one I’ve talked about already. The other one is Private Receipt, my own entrepreneurial endeavor. Our goal is to centralize receipts for users. You should never have to go anywhere without getting your receipt digitally. We’re not only trying to provide an alternative to paper receipts, we’re also trying to provide a way for companies to do advertising while also preserving user privacy.
Jacob: Right, so it’s an app on your phone and you download your receipts onto it. Does it also extract, you know, “oh you spent $10 on pizza” and such?
Nate: Yeah, what makes our platform different is that right now the only way to get your receipt digitally is to scan a paper receipt into your phone or to input your email or phone number at the point of sale to get it. We aren’t doing either of those, we’re working on letting you hold your phone up to the point of sale like Apple Pay and download your receipt that way. The other thing is your current payment platforms don’t give you an itemized receipt, if you go to Target and spend $100 with Apple Pay, you only see the lump sum on the app, not an actual list of everything you bought. That’s not helpful if I want to know what I actually spent my money on. So I don’t think what Apple Pay does is a good replacement for a receipt. Our app is able to preserve that receipt data that tells you that you spent $2 on a gallon of milk and such. It’s color coded by category, so things like “Retail”, “Food and drinks” are all grouped by color.
Jacob: That’s pretty cool. So what do you work on, do you do the app development?
Nate: Yeah. I’m the CTO on the company. So unfortunately I have to do everything technical right now. The app is fine and communicating to the point of sale via NFC is fine, but it’s going to get more and more challenging as we get into building an ML based advertising model. My other teammates are business-focused people, so there’s not much help there.
Jacob: Wow, that all sounds really challenging. Well, I wish you the best of luck and thank you so much for letting me interview you Nate!
If you enjoyed this post, please let me know in the comments or by simply liking this post. Feel free to engage with each other and me in the comments, and if you have more questions for Nate, post them in the comment section and perhaps he will come on and answer some of them, but no guarantees! Thanks for reading.