February 23rd, 2022
Although this term has been enjoyable, challenging and full of learning experiences, I am happy this term is inching closer to the end. It amazes me how fast time has flown this term has it feels January 3rd was just this past week. I guess this could be thrown up as a consequence of enjoying the class so much this term I forgot about time.
I am thankful I was able to work with such well informed and flexible teammates. Each member on the team has been invaluable to our efforts and our success is in large part due to our efforts to work together like a well oiled machine. Most importantly, it has been a wonderful experience learning more about each one of them as the term has progressed. Meeting them and being able to build an application is definitely an experience I will cherish and have fond memories once my OSU days come to an end.
Lastly, I am thankful for the structure and guidance this class has offered. The instructor and TAs have been great stalwarts of the classroom and have not hesitated to help when able.
Read the post...
February 18th, 2022
A few days ago I marked my one month anniversary as a software engineer. It has been quite exciting and interesting up to this point as making a career change always comes with its challenges. Some days tend to be more exciting than others and the same goes with the tasking. Not every task I will be assigned will be fun, however I am learning and realizing that each task is an opportunity to learn and grow.
Getting more familiar with the codebase and project as a whole is going in the right direction. Participated in my first demo in the last sprint which was exciting. Was not expecting to present however the product owner was pleased and my task was closed out as a success. I am glad I am getting early exposure as I believe it will only help with my confidence.
The team I was assigned to have been great thus far. They are all very capable individuals who have not hesitated to help me out or answer a question I may have. Most importantly, they have made me feel welcomed and have significantly eased my transition into this new role.
Read the post...
February 11th, 2022
Getting involved with open source software projects is a great way to prepare yourself for a job as a software engineer. Many of you may find yourself assigned to a team or project where you will be dealing with code that was written years ago by different software engineers who all differed in logic. Thus when it comes time to improving and refactoring this code, it can be tedious.
To best prepare for a role as such and interpreting what code in a program does that was written by other people, I suggest dabbling with open source projects. It will teach you to take the time to learn what the codebase and figure out what code calls which file and such. You will be able to hone your skills and refine your methodologies by participating in these open source projects. Most importantly, the skills learned will be invaluable when you transition to a full-time role as a software engineer.
Read the post...
February 2nd, 2022
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.
Read the post...