This is the first post in a theoretical series, so I'll explain my idea briefly. I graduated from DeVry University in 2012 with a CIS degree and zero understanding of what a real developer did on a daily basis. The experience may be more or less preparatory at other schools, but I found that my education was highly theoretical and not very practical. Yes, I learned enough programming that I have since become a successful programming, but in retrospect, there were some gaping holes in my education that would've prepared me better for a professional life as a programming. Simple things you use every day as a developer - like source control and debugging, for example - were missing from the curriculum. So I had this idea . . . what if I just wrote about what I did each day as a developer? Like a journal for other would-be professionals to peruse as a way of understanding what developer life really looks like. And by "each day," I mean almost definitely NOT every day. But hopefully, semi-frequently at least.

One additional note of clarity. I'm writing this as a professional developer with nearly 8 years of experience at this point. It's hard for me to recall exact comprehension levels of various terms and buzz words when I was at DeVry, so please consider the comment section an AMA for this post. If there are terms you don't understand or usages that are foreign to you, please ask. I will try to clarify those as well as I can or possibly write a whole post if the topic merits it. Additionally, if you are a professional programmer with a similar (or even vastly different) experience feel free to add to this commentary in the comments section as well.

So here's what I did on February 12th, 2020.

8:15 to 10:30

I started the day with email. Pretty common for me because I dislike unread indicators, so I will often clear all notifications first thing. I had an email about an ongoing bug issue involving an integration with a third-party API. The liaison for that API had asked for example urls and payloads for some of the failures. We don't have these readily available, so I spent the first couple hours of the day deciding on the best way to get them. Obviously, I needed to modify the codebase where we make the call to this API to make them available. Long story short, I ended up just logging them to stderr because that's captured in our log files by a bash redirect on startup. Why did it take me two hours? Because what I needed to log was not readily available in the function where I needed to log it. We (often, but maybe not always) use axios for making API requests, so I knew the request payload and url were available in the error object, but I just didn't know the exact structure of that error object (and it's not really documented in their README). So I had to simulate an API request and make it fail. I use Postman as my REST client for these kinds of things. So I basically commented out code that was setting required fields, and then called my own API endpoint using Postman so that I'd get an error back from the third-party API, so that I could log it to observe its structure. This took some trial and error, but I got there in the end.

10:30 to 11

A couple other guys had a conversation about why our server was filling up, and I did some brief investigation into how we bundle code for servers (using an in-house build/deployment tool) and whether we could reduce that code. I didn't spend long on this because our devops guy found a better solution pretty quickly.

11 to 11:30

Scrum. We're an agile company, so we have scrum every morning at 11 to go through the "in progress" items (and occasionally other things). It's at 11 instead of earlier because one of the members that joins is remote and in a timezone two hours behind us, so any earlier would be difficult for him.

11:30 to 12:30

I'm in a weekly programmatic ads meeting with my boss and several relevant parties from our parent company (yield manager, project manager, etc.). I'm in this meeting because I (at least in the last year or so) have done most of the ad implementation projects, so I have the most knowledge on the topic. Usually these are shorter (30 minutes or less), but they had a lot to talk about today. We ran through the upcoming ad A/B test schedule, as well as some other outstanding items, and then we (my boss and I) were asked about our experience in the past with direct advertising. We've been with the company for over 7 years each, so we've seen a lot of things come and go, and we were able to give them ideas that they really liked, based on initiatives we'd done in the past. I may have also spent the first part of this meeting not paying attention and instead starting an A/B test in Google Optimize that needed to launch this morning.

12:30 to 4:30

After the meeting (and lunch), I spent the rest of the day getting started on a "new" project. We're breaking part of our site into a separate server/stack as part of an ongoing migration away from our old platform. I'm excited about this project for a number of reasons. First, there's always a certain energy when starting something new. It's a blank slate. There's no bad code, no work arounds, no TODOs. Plus, it's pure creativity. You're creating something out of nothing. And by nothing, I mean a whole lot of node modules. Second, usually starting something new involves learning new tools, packages, or techniques, which I really enjoy. I'm especially interested in this project because this will be our first project in React. I've written plenty of React in my own personal projects, but to this point, we'd been an Angular company. So there's lots of "new" tools that I have some experience with (React, Redux, Webpack, etc) but that I'm also using in a different context than previously.

I didn't really make that much progress on this project. I basically created the repo in Github and initialized it with some of your bog standard config files (gitignore, eslint, babel, etc.), and then started working on a webpack config. You may ask, "Why not use create-react-app?" And the answer is that I just really like to be in control of the build. Every time I've ever used create-react-app, I've ended up ejecting it because I wanted to make some change to the webpack config that create-react-app didn't support. Yeah, there are a lot of options in webpack, but having done it a few times before, it's not that hard to skim them and know pretty quickly what you'll need and what you won't. Still, I spent most of the afternoon reading documentation on things like webpack and redux because part of the onus of being the one to set up a new repo is that you're the one making some initial choices about secondary technologies (in our case, things like react-router, redux, reselect, and immutable.js), as well as organization and implementation patterns (how to structure directories, whether to use class components or function components with hooks, etc). I also did a lot of installing, as I mentioned. There are a lot of really useful modules for working with react, things like yup, normalizr, and redux-act, but also a lot of obligatory dev dependencies, including about 17 different babel plugins for compiling various ESNext proposals, as well as JSX, and react and webpack peripherals for things like hot reloading (which is seriously the best thing I've ever used). I think I basically wrapped up the installation/setup, so tomorrow morning, I'll be starting, fingers crossed, on actually writing the top level index file, and some initial application components.

And that's it! That was my day. I mean, I also played foosball. If you follow this series, you should just assume that that happens basically every day.

Thanks for reading. If this was interesting to you, consider subscribing to the RSS feed so you can keep up with the series (it's way at the top in the navbar on the right side). And again, if you have questions, or just want to chime in about your own experience, leave a comment below!