Day in the Life of a Software Engineer at a Startup — Fluff Free

You Might Be Shocked at What We Do

Photo By Rev 1 Ventures — Home Of Redi.Health’s Office

Personally, I feel like there is a misunderstanding about what Software Engineers do on a daily basis. If I were to pull someone off the street and ask them what they think Software Engineers do, I bet they would think we are simply coding all day. Sure some days that answer would suffice but it's rare the developers simply get all day just to put their heads down and code without interruption.

I’m writing this article from my combined experience working at two startups. One was in the process of closing their Series C when I started, I believe I was engineer 40 give or take. In the other startup which I currently work for I was the third engineer hired and the company was still in the Seed Round of funding. We are still growing and looking for some talented Frontend Engineers, local or remote!

Let’s Start the Day

My Home Office

This is where the magic happens, I usually get to my desk sometime between 8 am -10 am. My wake-up time depends on if I have any meetings in the morning and to be honest how late I was up the previous night. My toxic trait is I can code all day at work and then still tinker on side projects until 2–3 am, it's either that or video games lol.

For the purpose of this article, I'm going to start it on Monday. Each Monday we have a Coffee & Chill Engineering Kickoff. This meeting is just to see where everyone is at with their current work. This includes work that may have been from the previous sprint. Sprints are essentially a period of time in which a set amount of work is allocated to be completed. In our case, here at Redi.Health our sprints are one week. The work that we pull into a sprint is determined between the engineers and our product manager.

Time To Pull a Card

Photo By Erik Mclean on Unsplash

Well maybe not just yet but we are close I promise. Before pulling a card which essentially means grabbing a piece of work that you’re committing to finishing in that sprint. This is just a tip for any engineer but especially for Senior+ Engineers. If you notice that there are cards that have been carried from the previous sprint to this sprint, it's definitely worth reaching out to the person whos working on it and asking if they need any help. If no one needs any help, pull that card baby! From that point on its pretty heads down, once you finish that card you pull another card, and so forth.

The Rest Of The Week

The next meeting we have is our refinement, this usually falls in the middle of the week. This meeting is where we discuss upcoming work for the next sprint. This is where we call out any gotchas and or add insight to the card that adds value/context to whoever might pick up the work. These are usually pretty quick meetings for the most part.

We are a remote-first team at Redi.Health so we do most of our communication via slack. To help with the social aspect of being remote it's not uncommon for us to hop in a google hangout and pair or just hang out while we all work on our separate cards.

We utilize Rollbar for our production applications to let us know about our systems and the errors they are possibly throwing. Rollbar is connected to our slack and we have it log errors(send error messages) into a specific slack channel. Since we are a lean engineering team it's really up to everyone to pay attention to the rollbar channel and be prepared to act accordingly. In the event of a production rollbar error that is mission critical, it's up to really any engineer at the company to start troubleshooting and figuring out what's going on. For those types of errors/bugs, we usually tackle them as a team on google hangout.

Being at a startup it's also pretty common to have wrenches and pivots thrown into a sprint. The business side is constantly churning trying to land deals. Based on what's happening on the business side drives what we work on. If there's a large opportunity for the business that will drive revenue into the business, it's up to us as the engineers to figure out how to make that happen from a technical standpoint. For example, let's say mid-week a client finally signs off on a deal. We as engineers know that in order for that deal to work technically we are going to have to add x,y,z, etc to the system. The deal deadlines are month based as in they want it done a month from x date. We as engineers in this case need to be proactive and do that work ahead of time and then can go back to what we were working on previously.

To end the week Fridays we usually have our product/engineering demo day. This is a meeting mid-afternoon to demo what we have been working on this sprint. In our case, everyone in the company is invited and I don't see that changing. Hopefully, this was insightful, thanks for taking time out of your day to give this a read!

Want to Connect?Follow me on Twitter.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
DuBois

DuBois

Founding Senior Fullstack Complexity Wrangler at Redi.health with a backend preference. /dab