Day In The Life Of A Software Developer At A Startup

A simple post about my day to day life in the startup world.


I thought it might be cool to do a more casual post about what my day to day looks like working at a startup. If I’m being completely honest, I’m also behind on work at the moment because I took off a day for my birthday, so I’m sort of in a rush to write this, but I committed to a post every Monday-Friday, and I’m not going to break that on week two so…here we go.

Day to day work…

If I’m going to talk about my day to day life, I may as well start with what I do every day in terms of development work. My days consist largely of writing code, I do deal with clients, administrative work like code reviews and project management, etc. but I am fortunate enough to say that 80-90% of the work I do is writing code, which is pretty much the dream. Typically when I come in, I quickly make some food from the company fridge (we get some free food like sandwich/smoothie/coffee/snack foods, etc. and yes, it’s awesome.), start a cup of coffee (most days) and check emails. Once I’ve confirmed I don’t have anything pressing to do, I either resume work from the night before, or I look through our ticketing system to see what needs done and I begin work on said tasks. If there is something pressing I let my boss know, and get working on it, or push it off to the side if more pressing things have come up.


Most clients who come to us want custom solutions to very particular problems they are having, because of this, we typically build out full on custom solutions for clients from scratch (but not always). To keep the business afloat and profitable, we often take on many projects all at once, because of this, combined with the fact that there are only 4 of us total, I often am working on anywhere from 2-4 projects either on my own, or with one other person where we each tackle one particular part of a project on our own. I’m also the Android lead for our projects solely due to the fact that I have the most experience with it, and usually I at least advise on iOS projects as well, though most of us know if fairly well.

The reason I mentioned all of this is because what it means is that usually I’m taking a project from literally zero code to full completion by myself or with minimal oversight. This is great for many reasons, I get to dictate the architecture of the thing (with some oversight of course), I get to write the entire thing myself, I get to learn from my mistakes, have a full understanding of how the thing is architected , and it letss me learn how things work at a much deeper level. The cons of this (and in a way the pros) are that if I can’t get something done, then there’s no one to ask to do it for me, it’s either I deliver or I don’t, end of discussion, especially when it comes to our Android projects. Obviously this can be a pro because it means that if I can handle that kind of stress and thrive, it means I can handle the small stuff as well and I learn a ton from the experience.


What meetings? In all seriousness, we have one single meeting a week, our weekly sprints where we decide what tasks for what project we’ll be taking on for that week. This is great because it let’s us stop being monoliths for a bit and discuss issues we’re having, things we learned, clarify or correct misunderstandings about requirements, etc. While we talk throughout the week for sure, this is a great way to get on the same page.

Project Management

We do Agile, but in a very watered down form, we don’t get super anal about it, and we don’t do all of the agile type things you might see being done in an Agile shop, and for good reason, it’s just 4 of us, why would we use a methodology meant for huge corporations and large teams for 4 people? It’s much better to use our stripped down version of it. Basically, at each sprint we discuss what tasks we want to take on, or that should be taken on, we take them out of our backlog, and put them on our lists. If we need more time for a ticket, or need more tickets, we adjust accordingly. We don’t really very often diagram out databases, project architecture, etc…I mean we do when we need to, but otherwise we don’t waste the time on it.

After hours

Our company is very good about never expecting people to work on weekends or during evenings…problem is, we all love what we do, so we do it anyway. Typically my day truly “ends” around 2 a.m. and I go back into the office usually around 10-11 the next day. This doesn’t mean I always work evenings, and I don’t always even work every day, sometimes I just take a day for r&r…but most of the time, I work 6 days a week, typically 1 weekend day, 2 days midweek at home, and I always start and finish the week at the office (so basically I work from home Tuesday Wednesday or Thursdays). Typically I get home around 5:30, spend some time with my wife, do chores, cook, whatever, and then I work on my laptop out in the living room where I can hang out with my wife. On weeks where I don’t really have work where I don’t need screen real estate (i.e. my 34 inch monitor is helpful to have), I go into the office a bit earlier so I can end the day a little sooner so I’m not neglecting my wife and my dog…I’m a good guy, I know.


I don’t actually really know why they say fin to signify the end of things, it seems odd, I’ll do some research on this now that I’m asking the question…ah, okay, fin means end in French, the more you know. Anyway, hopefully that was at least mildly entertaining…hang tight, I’ve got some more Xamarin stuff on the way…I just need to do some writing this weekend, thanks again for reading.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: