7:15 AM
I’ve never understood people who can wake up to their first alarm and get straight up. Their willpower frightens me. In a much more reasonable behaviour, I snooze and doze and snooze again. My ‘absolute latest’ for getting up is 7.45 am (a limit I reach every day). I leave my room to shower and almost trip over the dog who, once again, has come bounding over to greet me. It’s funny how his way of showing his love may one day break my neck. My morning routine is complete and it’s time for the train. If I’ve managed not to dawdle too much, I’ll be in time for the express – the cosmic sign of a good day ahead.
9:00 AM
I’ve survived the horde of zombies peak hour commuters and made it safely to my desk. I connect my laptop to my dock and sign in. First thing’s first: shuffle all my programs into their rightful places on my screens. Right monitor: main work screen (usually VS Code or Excel – today is a pull request day, so VS Code it is). Left monitor: support screen (usually my browser – for GitHub and SQL databases, and definitely not for googling why my code doesn’t work… I promise). Laptop screen: comms (Slack and email – they get half a screen each, sharing is caring).
9:05 AM
Coffee #1 – this is non-negotiable.
9:10 AM
Caffeinated and feeling human again, it’s time to get going. I check my calendar first – looks like I only have my daily stand-up and a catch-up with my manager today. This is good news, my day is open to get into the flow of code review. This pull request is a big one, too – 193 files changed… oof. I turn back to my inbox and start working through my unreads. They’re mostly automated emails from GitHub – I see my teammates have been leaving comments and pushing up changes already, the review has clearly begun. I open GitHub (surprise quiz: which screen?) and get myself up to speed on the changes that have happened so far. I find the comments left under the code I had contributed (which means they’re suggestions for me to implement) and organise them into ‘quick fixes’ and ‘larger reworks’. Some people swear by getting the big tasks for the day out of the way first, and that’s fine for them. Personally, I like to start off easy and build up to the meatier jobs. Pro tip: it’s important to figure out when your brain is at its juiciest, and structure yourself accordingly. Everyone is different and there’s no right or wrong approach – learn your patterns and do what works for you. I tend to be in peak form in the early afternoon, so I’ll aim to tackle the bigger comments around then. For now, let’s tick off some of the easier boxes to get the ball rolling.
9:30 AM
I decided recently that not drinking coffee past 10.00 am would make me a better person. So, this is my “yay or nay” deadline for coffee #2. Most days are “yay” days. Today is like most days. Now back to work.
12:00 PM
I am jolted from my coding flow (the most hypnotic of mental states) by a calendar reminder: it’s time for my daily stand-up. Stand-ups are brief update meetings with the team –“I’ve been working on this task. I’m blocked by this issue and need support. For the rest of the day, I’ll be doing these tasks. Etc.”. They’re pretty routine and don’t often take longer than 15 minutes. This bodes well because once it’s wrapped up, it’s lunchtime. There are many decent feeding spots around the Melbourne office, but one place has a hold over my heart (stomach*) like nowhere else: B3 bakery on Centre Place. The queue that forms without fail every day is a testament to the quality of their sandwiches. I don’t know what they do to them to make them so good, but my money is theirs.
1:00 PM
Back to the code. The morning was productive, and I managed to clear off all the small comments I needed to address on the pull request. Time to tackle the big ones. There are thankfully only a couple of these to get through. These “large reworks” are normally suggested by more senior staff (lead level and above) and are a great way to improve your own coding. Implementing elegant and efficient solutions to some of the more complex problems in your codebase is a hands-on way to pick up new techniques. While they demand a bit more effort than the quick fixes suggested in smaller comments, it’s always nice to feel like you’re sharpening your skills.
2:30 PM
I’m back out of the rabbit hole and the final suggestions have been implemented. My brain feels like it’s just done a full-body workout at the gym, but it’s good to know my code is in a better place than it was this morning. Now it’s time for the most tedious (but also most important) stage of coding: testing. Many repositories you work on will be set up with automated linting checks and unit tests. These are great for checking your code is clean and tidy, and that there are no glaring issues at face value, but testing the full functionality of your codebase requires a bit more involvement on your part. My team has been building some data asset pipelines (code that does clever stuff to make data more useful for the client). So, for me, testing involves running the pipelines a few times to make sure we get from start to finish without hitting any errors and manually checking the outputs to confirm everything looks good.
3:00 PM
Happy with testing, I push up the rest of my changes to remote for final review. In perfect timing, my work bestie arrives at my desk for a game of pool. Breaks are important – we aren’t fans of burnout at Quantium. The game was neck and neck, but I lost. This will not do. I will have my revenge.
3:30 PM
Okay, I’ll have to put a pin in revenge (for now…), because I have a check-in with my manager. The standard pleasantries are exchanged – “How’s the weather in Sydney?”, “It’s lovely, how about Melbourne?”, “I’d rather not talk about it…” – and then we get down to business. Check-ins with your manager are there to make sure you’re feeling supported in both your day-to-day work-life and also your overall career. We chat through what I’m working on currently (the infamous pull request) – it very almost there, just one or two final small edits and we should be good to go. Next, we touch base on how I’m progressing through the grad program. I’m almost at the end of my year as a graduate, so at this stage we’re making sure I’m ready for the transition to the next stage of my career. No major concerns here, I’m feeling ready and my manager agrees (always good to hear). It will be sad to rotate into a new team, but change is exciting too! The meeting is done, I make the final changes we discussed to the pull request and push them up. We should be ready for approval now.
4:30 PM
Changes look good and it’s time to merge. Simultaneously the most exciting and terrifying point of any pull request. My mouse hovers over the ‘merge’ button. I know my manager and teammates have all approved the changes, but the nerves persist. My palms are sweaty, my knees weak, arms are heavy. Fun fact: “simultaneous” is an example of a word that has every single vowel in it, but I think I’m just stalling now. 3, 2, 1… blast off. The code is merged and I can breathe again. I now have an hour or so before wrapping up for the day. Probably a good chance to get ahead and start on every tech professional’s favourite job: documentation. We’ll need to write up notes on the work we’ve done and the code we merged so other teams are able to get across it easily. This will mainly be tomorrow’s job, but I’d rather make a start now and not have ‘blank page syndrome’ tomorrow at 9.00 am.
5:30 PM
Last glance at Slack and emails and it’s time to head home. On the train home, my friend messages me to ask if I want to catch up for dinner. I made a rule for myself that I need to actually start eating the produce I buy from the supermarket. I think about the leftovers in my fridge that are about to go bad. I decide some rules are meant to be broken.
Thinking of experiencing life as a Quantium Graduate? Sign up to GradAustralia to receive job alerts for Quantium.