Hi class,

For this blog post I decided to choose the topic of team management. Team management. https://www.youtube.com/watch?v=BtBQdMWlpbQ. 

Anas Salman, who is a senior engineer manager at Uber, goes on to talk when meeting with a new engineer he will be very hands on with the said engineer in his career growth. When looking at growth for his engineers, Anas’ success is not if your engineer gets a promotion, but rather building skills and filling gaps in the engineers’ experience. Anas stresses a promotion is less important than doing great work, which a side effect would be a promotion.

Patrick acknowledges that people’s personalities and skills are different and vary, which as manager can sometimes be hard to find a good fit for the team. Anas agrees with this of which he has a baseline foundation of all incoming engineers/software developers. They must have a thorough understanding of the basics of coding.

Patrick begins the podcast by stating there can be a lot of processes set in place within team management, some of which can be tedious. Anas takes a different approach rather than looking at processes as simply that. As a manager, you must look at the processes and know three key aspects: to understand why it’s there, what’s the purpose, and the value. This will help your engineers not just do a process to do it, but understand it on a deeper level. 

Patrick states that as a manager, you need to have a motivated team, and sometimes it can be hard for engineers to find passion. Anas agrees with this. He says as a manager you need to align their passion with the needs of the team. This makes them more aware that this can lead to great growth in career and personal development. 

Patrick says the goal at the first meeting of the project all the way to the end of the project to his team and himself. By doing this, everyone on the team will be aligned with the shared goal. This will generate new motivation to start the project, coming up with new ideas and active discussions about how to reach the goal. 

My personal comments about this is that I like the way Anas thinks a lot about team management. If you’re in a team environment and you made a mistake and/or hit a challenge, he encourages this to happen, “Challenges are not usually bad things… I see them as gifts.” Anas says mistakes/challenges will be the accelerator for your career growth. Furthermore, he is showing his team that these are learning opportunities; I like that a lot and personally face challenges in and out of coding, by which adapting this mindset can only help me as an overall person and programmer, where simply doing will result in a greater outcome than seeking.

From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.

In this blog post, I will be talking about the various ways one can make their code reviews better. The blog that I am referencing is titled “How to Make Good Code Reviews Better” and is published on the Stack Overflow blog. The blog post outlines multiple strategies for people to improve their code reviews. These strategies include maintaining a respectful tone, offering specific and constructive feedback, and trying to focus specifically on high-impact areas. Furthermore, the importance of maintaining a balance between efficiency and thoroughness is highlighted in the blog, as balancing those two is very important if you want to ensure that reviews don’t become a barrier for your team during the development process.

I chose this blog because I thought that it would be a resourceful blog to read through, as these strategies can definitely help in the future for my professional career. This also relates to what we learned in class, as the blog heavily focuses on collaboration which can be tied back to our discussions about agile development.

This blog made me realize that code reviews should not be harsh critiques, but rather helpful conversations that provide insight on what should be improved in your code. It shouldn’t feel like a negative conversation, it should be supportive and friendly which creates a better working environment. For me, it also brings encouragement, as workers will feel more encouraged to improve upon their code if their coworkers are actively supporting them. Code reviews should be focused on the “what” and “how” rather than just listing all of the flaws of the code.

The blog also mentions how people should be reviewing for the future by providing insights that extend beyond the immediate fixes in order for the code to have better maintainability. The reviews should, of course, fix the immediate problems, but should also set up the program for better and for consistent success in the future. It should be focused on the sustainability of the code rather than just fixing all the short-term problems but not addressing how it will look in years. In general, every line of code that one writes should be written with the long-term impact of said code in mind.

Going forward, I am planning on applying these strategies of good code review in my professional career as well as my current academic career. If I am reviewing the code of a peer, I will aim to give constructive feedback that makes it feel encouraging rather than simply telling someone all the problems with their code. Doing this creates a better workplace environment where people feel comfortable with expressing their thoughts and opinions about things, creating a better team atmosphere and promoting teamwork and collaboration. I will also welcome feedback from peers about my work, as it is important to listen to the feedback of your peers, as in the end we are all working together towards a common goal.

Link: https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.

I just recently finished learning about git in a classroom setting, so every step from forking to cloning to branching and staging then committing into pushing ending with pulling. All the parts to get the gist of git, but nothing in the way of advanced use. Enter this article written by Gitlab.

As its title suggests, “15 Git tips to improve your workflow” has 15 total tips in regards to git, so lets go through some of them together.
1. Git aliases; amazing function, to think that rather than checkout, branch, or commit I could use a custom name. This is, in my opinion, great for new devs since once they grasp the concept of what a command does they can alias it to something that makes sense to them.
2. Visualizing repo status with git-prompt.sh; needs to be downloaded but definitely a useful tool for people like me who benefit from a more visual experience.
3. Command line commit comparisons; definitely more of a practical command that is helpful to see your workflow. Definitely going to be using this one to help me track what I actually worked on and might even download the Meld tool they mentioned.
4. Stashing commits; another practical command that makes sense just for a dev to know. If you have to push a sudden fix in the middle of adding a feature you can stash the changes made for the feature, commit the fix and then just pop the stash to get back all the previous work.
5. Pull frequently; nothing to add.
6. Auto-complete commands; tab to automatically finish a word is also applicable in search engine prompts as well. So useful for a new dev since if they forget the command but remember the first letter they can just flick through the commands until they find what they were looking for.
7. Set a global .gitignore; create a list of files to remove from commits and put it on the exclusion list, nice and simple.
8. Enable autosquash by default; had to look this up, apparently the squash command merges commits into one big commit. Personally not too sure of the use case so will have to test it out at a later date.
9. Delete branches locally that remote removed when fetching/pulling; as part of fetch, there is a prune attribute that will work this functionality and it just needs to be set to true.

Obviously there are 6 more tips and they are: Use Git blame more efficiently, Add an alias to check out merge requests locally, An alias of HEAD, Resetting files, The git-open plugin, and The git-extras plugin. I will not go over them here but definitely give the article a read if you are interested.

Link:
https://about.gitlab.com/blog/2020/04/07/15-git-tips-improve-workflow/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Scrum is a widely-adopted framework in software development that is designed to encourage collaboration, smart time usage, adaptability, and transparency to deliver high-quality results to customers. The methodology centers around three roles: Scrum Master, Product Owner, and the Development Team.  Each role is critical to ensuring the scrum process is effective. Together, they uphold Scrum’s core values: commitment, focus, openness, respect, and courage.

The Roles in Scrum

1. Scrum Master:
   The Scrum Master serves as the facilitator and coach, ensuring that the team will follow the Scrum principles. They steer the team away from distractions, help remove obstacles along the way, and guide the team toward self-organization and improvement. Their role is not necessarily  about managing the team but empowering it to achieve its goals effectively.
2. Product Owner:
   The Product Owner is the voice of the customer, responsible for “maximizing” the product’s potential and value. They manage the product backlog, prioritize features based on the current sprint, and provide clear requirements to the team. They act as the bridge between stakeholders and the development team, ensuring that there is a complete alignment on goals and expectations.
3. Development Team:
   The development team consists of software development professionals who collaborate to deliver increments of the product during each sprint. They are self-organizing, meaning they decide how to accomplish their tasks without intervention from the Scrum aster or product owner. This is great for fostering ownership, accountability, and for delivering high-quality work.

The Values of Scrum

Scrum is mostly made up of  five key values that the team’s behavior and decision making:

• Commitment: Teams dedicate themselves to achieving sprint goals and delivering value.
• Focus: By working on a limited set of tasks at a time, teams maintain clarity and productivity.
• Openness: Transparent communication fosters trust and ensures that challenges are addressed collaboratively.
• Respect: Team members value each other’s contributions and expertise, creating a positive and supportive work environment.
• Courage: Teams take bold steps to innovate and tackle tough problems.

Why Scrum Matters

Scrum’s structured yet flexible approach enhances collaboration, reduces waste, and drives continuous improvement. By empowering teams to adapt to change and deliver incrementally, organizations can respond more effectively to customer needs and market shifts. Whether done in software development, marketing, or other fields, Scrum’s roles and values provide an amazing foundation for the success of a company.

Resource on Scrum Management

“What is Scrum in Project Management?” is an informative video about the Scrum methodology by the work management company Wrike.  This resource informatively explains all aspects of scrum, including but not limited to: goals, roles, practices, and examples.  It also explains the idea of a “sprint” which is the current goals of the development team that they must get done before the next sprint.  Check out the video for more information on Scrum Methodology.

Link: https://www.youtube.com/watch?v=M12HSYZkrgQ

From the blog CS@Worcester – Elliot Benoit's Blog by Elliot Benoit and used with permission of the author. All other rights reserved by the author.

One of the incredibly positive aspects of the software development community is the general spirit of collaboration. This is particularly true within the open source software community. Paired with the fact that anyone can maintain a project/portfolio on GitHub, there is a lot of code out there. I would argue that this is a good […]

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

In the world of software development, effective version control and collaboration is very important. Two prominent platforms facilitating these needs are GitLab and GitHub. The article “Difference Between GitLab and GitHub” from GeeksforGeeks offers a comprehensive comparison of these platforms, highlighting their unique features and differences.

The GeeksforGeeks article delves into the distinctions between GitLab and GitHub, focusing on aspects such as:

• Continuous Integration/Continuous Deployment (CI/CD): GitLab provides built-in CI/CD capabilities, enabling seamless automation of the software development lifecycle. In contrast, GitHub requires third-party integrations to achieve similar functionality.
• Self-Hosting Options: GitLab offers a free community edition that supports self-hosting, granting users full control over their repositories. Conversely, GitHub self-hosting is available only through its paid enterprise version.
• User Permissions and Collaboration: GitLab’s free version allows for more extensive user permissions, including role-based access controls and protected branches in private repositories. GitHub imposes more restrictions in its free tier, such as limiting protected branches to public repositories and capping the number of collaborators in private repositories.

I chose this article because it provides a clear and concise comparison of GitLab and GitHub, two platforms integral to modern software development. Understanding their differences is crucial for developers and teams aiming to select a tool that aligns with their workflow and project requirements. I also chose this article because we use both platforms in class. In the beginning of the semester, if someone was to ask me what the main difference is between GitLab and GitHub. I would not be able to tell them.

The article enhanced my understanding of the operational variances between GitLab and GitHub. I learned that GitLab’s integrated CI/CD pipelines can streamline development processes by reducing reliance on external tools. This integration allows a more cohesive environment for managing code changes, testing, and deployment.

Additionally, the flexibility of self-hosting with GitLab’s free community edition offers significant advantages for organizations concerned with data privacy and security. It allows for greater control over the development environment without incurring additional costs.

The article also shed light on the importance of user permissions in collaborative projects. GitLab’s comprehensive role-based access controls in its free version facilitate better management of team contributions and code integrity. In contrast, GitHub’s restrictions in its free tier may pose challenges for larger teams or projects requiring stringent access controls.

Recognizing the importance of these platforms in the industry, I am committed to deepening my proficiency with both GitLab and GitHub. I plan to engage with comprehensive tutorials and hands-on projects to master their functionalities. By dedicating time to explore and practice with these platforms, I aim to position myself as a proficient user, ready to contribute effectively in professional settings where these tools are integral. This proactive approach will not only enhance my technical skills but also increase my employability in a competitive job market.

Sources:
Difference Between GitLab and GitHub

Citation:

“Difference between GitLab and Github.” GeeksforGeeks, GeeksforGeeks, 23 July 2024, http://www.geeksforgeeks.org/difference-between-gitlab-and-github/. 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

I will admit, learning Git is…unpleasant? A headache? Baffling? Rage-inducing? I, for one, do not enjoy trying to untangle the mess when Git goes off the rails. In fact, I have on a few different occasions decided that it would be more worth my time to redo all my work for a project/assignment than spending […]

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

The FreeCodeCamp article looks into helpful techniques for writing clean code, focusing on readability, simplicity, and naming conventions. It shows that writing clean code involves more than just making sure the code works. Using descriptive variable names, staying away from extremely complicated reasoning, and following recognized style rules are important pointers. The Medium essay supports this by going over fundamental ideas like the significance of refactoring, DRY (Don’t Repeat Yourself), and KISS (Keep It Simple, Stupid). Also, it emphasizes the human element of software development, clean code encourages teamwork and lowers technical debt. 

I chose these articles because they bring useful information into an important part of software development that is sometimes overlooked, especially with people who think they have finished code. They bring a deeper meaning to the information we learned in class about clean code and also how I should go about looking and editing any of the codes I make in the future. Another reason why I chose these articles is because they give useful knowledge about a sometimes disregarded aspect of software development. These materials show that clean code is about more than just functioning; it’s also about sustainability, readability, and future-proofing. Many developers may think their code is “finished” after it works well. These principles expand on the clean code writing lessons we acquired in class and provide a more comprehensive viewpoint on how to approach coding and editing in future projects. I found these tools to be a useful reminder of the importance of prioritizing clarity and maintainability above complicated solutions. For example, in previous classes where I needed to code, I often prioritized utility over the potential interpretation of my work. After reading these articles, I realized how important modular design and naming standards are for securing and debugging as well as group projects. 

Among the ideas that resonated deeply was “refactoring as a discipline.” Beyond just cleaning up code, refactoring provides an opportunity to reevaluate and just look over my coding another time. Refactoring provides a chance to reconsider and enhance a project’s overall structure. This viewpoint changed the way I approach coding. I now consider refactoring to be an essential step in maintaining long-term code quality rather than a tiresome task. It promotes a proactive approach to ongoing development. Going forward, I plan to integrate these principles into my coding practice. I will be more intentional about naming conventions, structuring code logically, and refactoring regularly. By doing this, I hope to create code that is not only functional but also clear, maintainable, and ready for future development.

From the blog CS@Worcester – A Bostonians Blogs by Abdulhafeedh Sotunbo and used with permission of the author. All other rights reserved by the author.