Category Archives: project-management

Working as a Front end developer

Now that I have heard about people’s experiences working on the back end, I was curious about people’s experiences working on the front end. Reading personal experiences taught me a lot about working on the back end. You can learn a lot and avoid mistakes by seeing others take similar paths. Also, it can prepare you for problems that you may face in the future. Mistakes are inevitable but being able to adapt or being able to recognize it and fix it goes a long way. Working on projects especially those that have to do with coding errors is always a step away. You can try to get a step ahead on these problems by seeing other people work and implementing it on your stuff. That is why I found an article about working as a front-end developer. These articles are very engaging and always give me a new perspective.

This article is written by Selim Enes who has done freelance work in the past but is currently working as a developer. When he first started he was working on small things like CSS edits until he proved himself. One of his major projects was a blog project where he had to create the display of the UI. He was involved in all operations after 2 months. When he proved to the team that his code wouldn’t crash the project he gained access to the company’s main project. The company’s main project entailed a webinar application that used technologies like WebSocket. One thing that made him know he was going in the right direction was being able to develop features like push-to-talk by himself. There are some negatives to his work with his boss being very hasty on projects. He believes all tasks are urgent and make some work very stressful. Plus with the recent economic regression, he doesn’t believe he will be able to get a raise anytime soon. He has learned to have a full-stack blog project for himself and has an e-commerce project his about to start working on. He is working while also building his portfolio outside of work.

Reading this article was very insightful. It made sense that when you first start working for a company they won’t give you the keys to everything just yet. They ease you up into it until you have gained their trust. Working on his portfolio outside of work motivated me to do the same too. You can sometimes become complacent at your job because you have a living but you shouldn’t. You should always try to improve and hope to find better opportunities elsewhere

View at Medium.com
https://medium.com/@sellimenes/1-year-experience-as-a-junior-front-end-developer-39766fad5c34

From the blog CS@Worcester – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

YAGNI

Source: https://www.geeksforgeeks.org/what-is-yagni-principle-you-arent-gonna-need-it/

This article is titled “What is YAGNI principle (You Aren’t Gonna Need IT)?” YAGNI is “a principle in software development that suggests developers should only implement features that are necessary for the current requirements and not add any additional functionality that might be needed in the future.” The reasoning for this is that if you add features that might potentially be needed in the future, there will be risk for more bugs, increased complexity, and increased times of development, thus leading to increased cost. The YAGNI principle is similar to the KISS principle (Keep It Simple, Stupid), which also advocates for simplicity, it encourages developers to avoid complexity when it isn’t necessary. Developers should follow the YAGNI principle if they wish to keep the following costs in mind: the cost of building, delay, carry, and repair. The cost of building refers to the total cost of efforts and resources implemented in the project. Building things that aren’t needed leads to increased costs overall. Cost of delay refers to missed opportunities, if you spend time on unnecessary features, the development of more important ones will inevitably be delayed. Cost of carry refers to the difficulties of having unnecessary complex features. These complexities make it difficult to work on other parts of a software project, require more time, lead to an increased cost, and overall cause harder times moving forward. Lastly, the cost of repair, or technical debt, refers to the costs associated with bugs or mistakes that occur during the development process. YAGNI is important to ensure that the development process is focused, efficient, and cost-effective. YAGNI can be implemented into your code by prioritizing communication between team members. Ensuring that necessary requirements are met, a simple plan is made, ignoring ideas that don’t meet goals or deadlines, and keeping good records of project progress will allow your team to follow the YAGNI principle. YAGNI allows for simplicity, faster development, flexibility, reduced risk, and cost savings by complementing other development principles while prioritizing unnecessary implementations.

I chose this article because I appreciate how geeksforgeeks simplifies topics within the software development community. I don’t recall this principle being explicitly mentioned in class, but we have definitely alluded to it and I thought it’d be beneficial to read about it more, considering that it is in the syllabus. It was interesting to learn that the YAGNI principle complements other software development principles, such as the KISS principle, and compiles them into a unique principle that prioritizes simplicity over complexity and more features. It embodies the idea of “less is more.” This is a great set of guidelines I’ll be sure to follow in industry because it promotes that sometimes less work isn’t a bad thing. Instead of creating a multitude of features, ensuring that the ones that are critical, and required sooner, are being developed, will still get the job done.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Takes on how to become an effective team

URL: https://www.youtube.com/watch?v=7zDX8VqvBa0

I came across another interesting podcast episode from Beyond Coding. This time, the episode I watched focused on Effective Product Teams, featuring Anne Kooijman, currently a Product Owner at Coolblue. The conversation between her and the host covered various topics related to team management and ways to build an effective product team.

The reason I chose this resource is that it provides real-world solutions to straightforward questions. The host, Patrick Akil, mentioned that he recently took on an assignment as a Project Manager. He asked many interesting questions, some of which I had myself.

A couple of specific points caught my attention, and I’d like to share them with you. The first was Anne’s perspective on what is required for a team to deliver quality work. She said, “Give them the necessary tools and the theoretical background.” I found this fascinating because you shouldn’t give developers half-baked solutions or dictate how to solve a problem. Doing so might make it harder for them to translate someone else’s idea into code. Instead, provide them with the necessary knowledge and tools to figure out solutions on their own and let them do it.

Another topic Anne discussed was how companies sometimes deviate from the core principles of Scrum and the potential outcomes of those deviations. She pointed out that there’s no issue with straying from what the “constitution” of Scrum dictates if it leads to improvements. This is intriguing because Scrum is meant to provide a framework, not a rulebook. Different teams consist of different people who may respond differently to certain changes. Personally, I imagine that I wouldn’t react well to constantly changing sprint durations.

They also discussed goal-driven teams and how having goals is essential for team effectiveness. This resonates with me, as it aligns with a practice, I adopted this semester. This isn’t meant to criticize how others manage their responsibilities but to connect the podcast’s ideas with my own experience. For the first time this semester, I decided to only consume entertainment during my free hours once all my tasks were completed. It sounds simple and cliché, but it works—just like Scrum. Teams need a singular goal, and the focus should remain on that goal.

This brings us to the final topic: timelines, and how even flexible and inconsistent timelines can be better than having none. This concept challenged something I’ve always believed—that if you’re going to do something, do it right and to the best of your abilities, or don’t do it at all. However, I realized that some flexibility in timelines is necessary to allow for adaptation and growth.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Masters in Scrum

One method I’ve encountered repeatedly in both my coursework and during discussions with peers is Agile—specifically, the Scrum framework. To better understand it, I recently read an article titled “Scrum Mastering the 3 Pillars, 5 Values, and 7 Key Principles of Agile Project Management”, which provides a clear breakdown of how Scrum works and why it’s so effective in software development. I found this resource insightful, and it’s something I can definitely apply in my future

The article explains the fundamental elements of Scrum, which include the 3 Pillars, 5 Values, and 7 Key Principles that form the foundation of this Agile framework. The 3 Pillars—Transparency, Inspection, and Adaptation—ensure that the process is open, regularly assessed, and flexible. The 5 Values—Commitment, Courage, Focus, Openness, and Respect—help create a collaborative and supportive team environment. Finally, the 7 Key Principles emphasize continuous improvement, self-organizing teams, and the importance of simplicity in problem-solving.

I selected this article because, as a beginner in computer science, I wanted to understand how project management frameworks like Scrum can be applied in real-world software development. Being new to coding and programming, I often feel overwhelmed by the amount of information and tools available. Scrum, with its structured approach, offers a clear way of organizing tasks, fostering teamwork, and ensuring that progress is continually monitored. Learning about Scrum is relevant to my future career because it’s widely used in the tech industry, particularly for software development and managing complex projects.

From reading the article, I gained a solid understanding of the core principles that make Scrum effective. The 3 pillars stood out to me, especially Transparency. As a student, I can relate to the importance of transparency in team projects where communication is key to understanding who’s doing what, when, and how. Inspection and Adaptation also made me realize how crucial it is to frequently check our progress and be willing to change course when necessary, which can save a lot of time and effort in the long run.

The 5 Values were a reminder of the importance of collaboration and maintaining a positive, respectful team environment. These values are essential, not just for Scrum but for any professional setting. I particularly appreciated the focus on Courage, which resonated with me as I’m still learning how to approach new and challenging problems in my coursework.

Finally, the 7 Key Principles reinforced the idea of simplicity and the need to avoid overcomplicating solutions, something I’ve noticed in my own work when I get caught up in trying to build complex solutions rather than focusing on what’s truly necessary.

I plan to apply the principles of Scrum, especially the importance of adaptation and simplicity, in my future projects. Whether it’s a group coding project or individual work, Scrum’s emphasis on regular inspection and continuous improvement will help me ensure that I’m always learning and adjusting as I go.

Resource:

“Scrum Mastering the 3 Pillars, 5 Values, and 7 Key Principles of Agile Project Management”

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

To Be Agile

I recently came across a blog post on LucidSpark titled What Is Agile Methodology? that explains the basics of Agile and its role in modern software development. Agile is a project management and software development approach that emphasizes flexibility, collaboration, and customer feedback. The methodology breaks down large projects into smaller, manageable chunks called sprints—usually lasting a few weeks. This approach allows teams to adapt quickly to changes, make continuous improvements, and deliver working software regularly. The blog goes on to explain the Agile Manifesto, which highlights values like individuals and interactions over processes and tools, and customer collaboration over contract negotiation.

I chose this article because it offers a clear, easy-to-understand explanation of Agile, a methodology that I’ve heard about a lot in my software engineering classes and in discussions about software projects. I wanted to learn more about it and see how it’s used in real-world development, especially since I might be using it in some of my future group projects. The post helped clarify some of the concepts I’ve learned in theory and gave me a better understanding of how Agile works in practice.

One of the most interesting takeaways from this article was the emphasis on adaptability. In traditional project management, there’s often a lot of upfront planning, but Agile is all about being able to adjust quickly to changes—whether that’s changes in customer requirements or new technologies. I realized that in software development, the ability to pivot and change direction is just as important as having a solid plan in the first place. This idea of “failing fast” and improving iteratively really resonated with me. I’ve noticed that when I work on assignments or personal projects, sometimes things don’t go as planned, and it’s frustrating to try and stick to a rigid approach. Agile’s flexibility seems like a better way to handle those situations.

Another part of the article that stood out was the focus on collaboration. Agile teams work closely together and communicate regularly, which is different from the more isolated approach I’ve seen in some projects where team members work separately and only come together at milestones. The post explained how frequent communication, daily stand-ups, and collaboration with customers can help create better products and avoid misunderstandings. This is something I want to keep in mind for group projects, especially in coding assignments where communication can make a huge difference in the quality of the work.

In my future career, I plan to apply what I’ve learned by adopting some Agile practices in my own projects. I want to be able emphasize collaboration and open communication in group assignments, which could lead to more efficient and effective teamwork.

Resource:

https://lucidspark.com/blog/what-is-agile-methodology

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Project Management

Source: https://monday.com/blog/project-management/guide-to-project-management/

The title of this blog is “What is Project Management? The Complete Guide [2024].” As seen from the title, this blog obviously describes the ins-and-outs of project management. The idea of project management is to manage projects by ensuring that they are delivered on time, within a set budget, and satisfy the needs of the stakeholders. Project management involves setting goals, scheduling, managing, monitoring, and collaboration. This is accomplished through various methodologies such as Agile, Kanban, or Scrum. This is an important field, and topic, because teams of individuals are the ones who provide the greatest projects and products to the market, and without effective leadership and problem solving, they would never come into fruition. Many different organizations employ project managers, ranging from small businesses to Fortune 500 companies. Project management is not exclusive to software engineering though, it can be seen in other sectors such as construction or marketing. “The Project Management Body of Knowledge (PMBOK Guide) defines ten key project management knowledge areas” them being: scope management, schedule management, procurement management, stakeholder management, risk management, communications management, resource management, quality management, cost management, and integration management. These are all self-explanatory from their names but are very important for being an efficient and effective project manager. There are many different tools used in this field, such as Gantt charts (used for scheduling and tracking tasks in a visual timeline), tasks lists, Kanban boards, calendars, budget trackers, mobile apps, and many others. One might ask if a project is completed and another one is about to be started, is everything created from scratch? The answer is no. Project managers use templates to fill in instructions from prior work to save time when initiating a new project. There are quite a few roles in project management, one being the project manager themself, the project sponsor, the team members, the stakeholders, the customer, the office, and the steering committee (who provides oversight). All of these individuals make the creation of projects operate smoothly.

I chose this particular post about project management because it appeared to be all-encompassing of the topic, and I was correct. After learning about Agile and Scrum methodologies in class, I was interested in learning about the importance of having a project manager in various sized companies. I can appreciate the fact that they have to communicate with stakeholders, engineers, and management in order to ensure smooth operation. Overall this material was very interesting to me because I’ve had an interest in this field for my future career. If I end up pursuing project management, this information would definitely be beneficial for performing my job appropriately. If I don’t, knowing the role of a project manager would be beneficial regardless because I’m bound to work with one regardless. Having an understanding of your coworkers’ roles at your company is important for collaboration. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

CS448 Sprint 1 – Retrospective

This past Tuesday 2/27/2024 marked the conclusion of Sprint 1 for CS448 – Capstone. My team worked generally well together and we managed to complete all of our assigned tasks as well as some extra we added during the Sprint.

During this Sprint, I was involved in addressing a few different tasks and issues:

Issue spent most time on – “Create General and Pipeline” https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/10. This issue was in the “General” (#gitlab-profile) repository and consisted of three separate parts: 

  1. Moving settings from configuration files set up for integration with Dev Containers to .gitpod.yml extensions for GitPod integration.
  2. Refactoring the ‘commands’ folder to ‘bin’ to keep up with industry standard file naming. This includes updating script paths and .gitlab-ci.yaml environment variables to refer to bin.
  3. Adding the AlexJS linter to pipelines as well as the bin/lint.sh test script file.

Also, as a part of this issue I also implemented some minor typo and similar fixes so that all linters pass for a successful integration pipeline. Originally, these were three separate issues that were combined during the Sprint.

Issue #2 – “Familiarize ourselves with GuestInfoFrontend to Understand What Goes into CheckoutGuestFrontend”

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37. This issue included all team members and was intended to prepare each of us for Sprint 2, during which we intend on tackling some front-end Epics/issues in CheckoutGuestFrontend. So, I reviewed the GuestInfoFrontend repository structure and began to strategize a possible plan of action for building out CheckoutGuestFrontend.

As mentioned, my Team added additional tasks to our Sprint Backlog during the sprint as we found we would have extra time leftover after completing our original tasks. We chose to take on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” for the Documentation and General repositories as we had already set up the settings and thereby familiarity with these repos. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12

I created our new issues; we were able to complete the task for the Documentation repo as it was relatively simple in terms of not needing to make many changes/add linters, and make some progress in the General repo but pushed the issue into Sprint 2.

Reflecting back on the sprint, there were a few things that come to mind which worked really well – as a team we scheduled out our tasks well between standups and managed to have full attendance at each. Also, when we needed to add tasks we elected to stay within the repositories we had already been working in and were somewhat familiar with, which was a good choice as switching would have likely wasted time getting familiar with the new repo, as well as wasted time for another team who would have needed to become familiar with ours. 

However, we struggled somewhat with getting used to navigating the GitLab issue board, merges, child issues etc. and sometimes it felt like some team members were in different places where a solution may not have been fully communicated to all teammates. As a team, I feel we can improve on some of our internal communication and do a better job planning out our sprints and creating something of a road map, especially as we prepare for Sprint 2 which is considerably longer than the first. Personally, I think I can improve my time management and also be a bit more involved in the process of planning out our next Sprint and creating issues with relevant descriptions and linking to organize our tasks and get a better feel of how to use GitLab to its maximum potential.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.