That First Ticket

Life in any new job can mean a lot of on-the-spot learning, questions, and stumbling. As a former educator transitioning into tech, life as a brand new Software Engineer felt all the more foreign.

Some of my very first questions to myself:

• Sweet! I now have a laptop and an external monitor - oh boy, where exactly did my cursor go!?

• Why can't I stop thinking of boats whenever I hear the word Docker?

• Is this the part where everyone finds out I don't really know what I'm doing?!

Truth be told, my first few days of virtual onboarding and meeting my new team (my new team!) were a treat. New beginnings can be absolutely beautiful.

But what I really, really, really wanted to know was the answer to the very question I asked everyone else when I was job hunting:

What's a day in the life like?

A Day In The Life

It all starts with a ticket.

• Bugs and features. In my short experience thus far, I've learned that there are generally two types of tickets: bugs and features. You're either fixing or building. For my first ticket, I was fixing. I needed to prevent text from spilling outside of a button.

• A sea of code. Being brand new at your job means that each task is so much more than solving a problem. That sea of code - that's what I was swimming in. For the first few hours, I was trying to orient myself. Look at the portal (app) in the browser, inspect some elements, find said elements in the code repo. Well, try.

• Replicate. Back to the task at hand, after orienting myself a wee bit, I knew I needed to first replicate the issue. Find the button, see the text overflow, and figure out when it happens and why. Might I say, this part was a hoot!

• Find the code. Once replicated, I knew I needed to find the code for that element in the repo. Figuring out what to search for was initially a roadblock, but trial and error proved effective.

• Blank stare. I jest, but this was the moment I'd been waiting for. Me, Software Engineer Anna, at bat. After a bit of panic breathing, I thought back to the task at hand. Text, in a button, was overflowing. Overflow. Overflow properties. CSS.

• Google. Yes, folks! Yes! Now that I knew what I needed to do, I searched for CSS properties and ways to keep text inside a button and prevent overflow.

• Educated trial and error. I knew a few properties that might do the trick, but now I had to compare the standards and styles of the code base at hand.

• The other bits. Throughout that process, there were plenty of other tidbits that I picked up. When to start Docker and why it's important, how to track progress in Jira, which version of Bootstrap we use.

• Run the tests. There are tests to be run, to ensure that what I've built didn't break existing code. There will be a time and place to get into the details (the details are great!) but for now I'll say, testing really, really, really, really, REALLY matters and is a lot to get used to.

• That first PR. Once tests are passing and the commits are made and pushed, it's time to make the pull request. That gorgeous signal that you're ready for your changes to be reviewed by another team member.

The next steps vary, but here's what else happens once a PR is submitted. Someone else on the team will review it and leave comments for next steps. But don't wait for that review - keep going. Either work on a new ticket, work on any other open tickets or pair up with a teammate to review what they're working on.

And then rinse and repeat. Tickets, pairing up, testing, fixing, building - it's a beautiful process to improve what exists.

Now that I'm in it and have experienced the day-to-day life of a software engineer, it doesn't feel all that foreign to me. But while still at Flatiron or even while job hunting, it was THE thing I was most anxious to figure out.

If you're out there and want to know more about the ins and outs of a day on the job, leave a comment below! Always happy to share.

Cheers, and thanks so much for reading.