Blogging 467

Before I began my career I used to watch numerous videos on YouTube labeled “a day in the life of a software engineer” hoping to get an idea of what typical work day was like. Most videos seemed interesting considering they consisted of the person waking up at 9 am to start their day, strolling into the office to eat breakfast, a few meetings with the team before lunch and then finishing up the day back at the office to play a few games and code. Now although this seems like an awesome typical workday, which I’m sure a certain fortunate people enjoy, these videos can be more than a bit misleading unless maybe you do indeed work a major tech company.

Granted the company I work for is not a major tech company, we do have certain perks but nothing in comparison to what many of these videos lead you to believe happens on the job. First and foremost, there is no sleeping in. Stand-ups are every morning at 8:30 am so goodbye late nights. These stand-ups have been somewhat odd to adjust to considering they are everyday and lasts maybe only a few minutes. Personally, I think it would be easier if everyone on the team just posted what they were working on for the day on a shared Google document for everyone to acknowledge, however in the software engineering world we must abide by a software development framework and on this role it is Scrum, thus daily stand-ups are the norm.

With the exception of daily stand-ups the only real meetings are sprint refinements, review and retrospective. Each type of these meetings during a sprint are unique and occur only once throughout the two week sprint. Sprint refinements are what you think they are, a time to discuss tasks assigned in the sprint and the need to make any sort of refinement. Whether that is breaking down a task in two sub-tasks are allotting more time to a particular task, this is all discussed during a sprint refinement meeting. A sprint review or otherwise known as a sprint demo is an opportunity to showcase what you have been working on during the sprint. Thus the task you were assigned at the beginning of the sprint, must be complete and working to show to the product manager what you completed with the product manager making the ultimate decision to decide whether a sprint task is complete or not. At times the product manager may ask for more functionality. A sprint retrospective is an opportunity for the team, free of the product manager, to discuss internal issues, ideas and strategy. I have only attended one retrospective thus far since I began my role, but these meetings are designed to give the team an allotted time to discuss and sort out kinks or issues without management being a part of it.

The end of the day usually entails just coding or reading up on documentation. At this stage I have become more accustomed to coding as I reserve the early part of the morning prior to the standup to read on documentation, however this can take place whenever one is stuck and trying to figure out what to do. Oh and last but not least is tracking your time. Something many of those “a day in the life of software engineer” videos does not show is if you are working on multiple projects or even one, you must accurately document your time. The purpose is to allocate how much time was spent on a certain project in relation to budget.

Overall, the career switch has been adjustment and working in the corporate world has differed significantly from my previous role. However with time and experience I expect I will get better acclimated to the position and company. Landing this role was not easy, so I will continue to keep my head up as I deal with the corporate grind.