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.

Software Engineering: Journal 7

 Well, this will be the second to last journal for my software engineering course at CSUMB. This week, we are tasked to discuss some of the differences between the Agile process and the Plan and Document process, often referred to as Waterfall. To start, Agile is a process that doesn't really concern itself with how long something will take or how much something will the end client. Compared to Agile, the Waterfall mythology also tends to heavily rely on the the previous work that was done, to develop in a sequence like approach. Agile doesn't really do this, Agile focuses on developing in iterations that are referred to as sprints where the work that is being done is broken down into smaller pieces that don't necessary have to depend on previous work. Additionally, Agile is a mythology that revolves around evolving requirements, so in-terms of client feedback, Agile allows for me for this. Waterfall, on the other hand, focuses on have specifications upfront with a more rigorous process in changing the requirements when compared to Agile. Overall, I would say that Agile is best suited for projects that evolve over time, while Waterfall is best suited when a project will have very little change once the project is deployed.

Software Engineering: Journal 6

It is now the end of week 6 for my software engineering course. The important things that we focused on this week include the difference between monolithic and microservice architectures. I had previously heard about microservice architecture, but I hadn't really understood why it was important. After going through this week in this class, I would say that for smaller projects, monolithic architecture is better, and for bigger projects with more users, a microservice would be ideal. Overall, it was a bit of a light week for this class. I am a little sad that this class is nearly over, as I think this is going to be one of the classes in this course that I directly apply when I get into the workforce.

Software Engineering: Journal 5

 My week 5 for this intense software engineering class is coming to a close. With that in mind, I wanted to write a couple things that I learned this week that I thought were interesting. This week we mostly focused on documentation writing. This was also what I found most interesting. The fact that the Agile mythology doesn't seem to be concerned with the cost of a project when compared to the plan & document (waterfall) process really caught me off guard. This makes me wonder if Agile's history is cemented closer in startup culture instead of established enterprise culture. I say this because most of the time startups are kept alive through investments from investment firms that don't see an immediate return. This is something I definintely have to look into as I progress in this course. All in all, interesting week, with very little programming, but I got some valuable experience.