Software Engineering: Journal 8

Well, my Software Engineering course has come to an end. This final week was a bit stressful for me, considering that I had a lot of other personal stuff going on, and surprisingly, I felt like that there was a lot of work to be completed for the final. With that in mind, I wanted to list 5 things that I found the most important through this course:

1. Git... Git... Git! I can't begin to explain how important this tool is in today's fast paste environment. During the projects we had to work in this class, we were working in a team of 4, most of us with different schedules from the rest. Git allowed us to stay in communication while making progress without having to coordinate our schedules for meeting times every time we were going to work on the project for this class.

2. Another aspect I found very compelling is the importance of being able to communicate with others, especially those that are not from the technical background. Utilizing some of the Agile methodologies will surely benefit me in the future.

3. Before this class, I was also a bit anti having to write documentation. I found the procedure kinda tedious and boring. Now, I see the real value in this. I have recently found myself working on open source projects with not the best documentation, and it has been frustrating to say the least having to try to hunt down things.

4. Testing is another thing I think was one of the better things I learned in this course. Especially, for writing new code and shipping faster. Instead of manually testing every time I do a change, I can very quickly run my tests and have some level of assurance that the changes I'm making aren't all that bad.

5. Service architecture is also another valuable lesson from this course. Although, more importantly than service side architecture is knowing when to apply it. For example, for small projects, I would not focus on trying to future proof by planning out how to split everything into services. I would more so focus on shipping the requirements that are in the now, and then scale if I need to in the future. I think it would be more important to ship a product, compared to trying to have everything from the get go. All in all, this is just what it means to be a software engineer. Balancing the requirements considering everything from the life cycle of a project, to how much it will cost, to what is needed in the now.