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.

Hi class,

For this blog post I decided to choose the topic of development environments. Development environments are one of the topics that we went over this course and furthermore, it can be interesting to find out more about it on a deeper level.

The source that I have selected is a podcast episode about remote development environments, of which the link is https://www.youtube.com/watch?v=otB0qGGmDFI. Sid Palas, the host, is an avid learner and wishes to share more of everything code to the world. In this episode he interviews Pauline Narvas, head of community at Gitpod, and Chris Weichel, CTO of Gitpod. The episode covers topics from what is a remote development environment to the inner workings of it.

Sid begins the podcast by asking Pauline what Gitpod is. Pauline replies that Gitpod “is an open source developer platform that automates the provisioning of ready to code developer environments.” This simply means that the goal of Gitpod is to remove the “friction” of the developer experiences by making the development environment more collaborative, joyful, and secure, all at the same time. 

Following this section Pauline is questioned about why someone would use a remote development environment such as Gitpod, rather than using their own laptop which has all their packages, layouts, and environments all set up. She replies the whole point of Gitpod is trying to remove the dependency of an environment. Furthermore, she goes on to state that when an update occurs, most of the time the environment does not work/delays the process of coding, while Gitpod works on automating this by saving time and mental stress. Chris goes on to add that it eliminates the “it works on my machine” issue due to the fact it will work on all participating machines because being a remote development environment, everything is in the cloud. Additionally, Chris goes on to add that the environment is more secure due to the fact your work is not secured locally on your laptop, but rather a secure cloud of which they have teams dedicated to keeping your information secure.

Pauline then is asked how to form a prospering community in the development environment of being totally remote. Pauline goes on to state she joined Gitpod in July of 2021. At the time there were multiple outlets of conversations throughout developers by using GitHub, X (formally known as Twitter), Discord, and other chat applications. She realized this was not effective at all for communication, so her role was to try to streamline the community together due to the fact the community was scattered throughout multiple channels. At the time there was not a central place for the community to come together. From here, the Gitpod community was created, which has been found to be a great central hub for developers to come together. Pauline stresses that having an open outlet of discussion amongst peers is crucial to a development environment, remote or not.

Lastly, Sid addresses the security of Gitpod and what it looks like from an inner perspective. Chris states it’s a forever evolving process, but the most important key is creating a team(s) that thrives. Chris goes on to state that you must give the team enough space to act, yes, but also build a team that knows the space, is knowledgeable and drives to keep learning about the forever changing space. 

My personal comments about this is that I found this to be really insightful. Throughout the interview I felt like they were not simply just having a podcast, but talking to me as a viewer. As a fairly new programmer, I have not been exposed to the extent of Gitpod as other programers have, but what they did with Gitpod, I can see why a lot of programmers use it. Gitpod saves a lot of time in a development environment and less stress of hearing “it works on my machine”; it will work on everyone’s. Furthermore, I have been kind of intimidated by Gitpod, but after listening to this I am eager to use it more often when doing coding projects whether that’s by myself or with a team, it seems like a really great tool that I should be more involved in. 

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.

Hi class,

For this blog post I decided to choose the topic code review. Code review is one of the topics that we went over this course and furthermore, could be very beneficial for all of us to learn even more how code review is executed.

For my resource of code review I listened to a GOTO Conference talk in Berlin and here is the link to the video: https://www.youtube.com/watch?v=ly86Wq_E18o&t=142s. The video is of a man named Alejandro Lujan, who has been a software developer for more than 20 years. Alejandro goes on to state he knew code review, but not to the extent from when he got his most recent job at Shopify. It was here at Shopify his aspect of code review vastly improved. (I chose a video format because I like listening to the speaker better; I can understand said topic more with a personal connection.) 

Alejandro’s first couple months at Shopify was not what he expected. The code reviews were a lot more “harsh and intense” than what he was accustomed to. Alejandro took the code reviews very personally, thinking he is a bad coder and maybe the team does not like him. After pondering these thoughts for a couple of months, he looked at the work he was contributing and the comments were not about him, but rather his work. He quickly realized the code review at Shopify was not simply just a code review and then Alejandro went on an arch to fully understand code review.

Through the following months, he realized that great code reviews are symptoms and contributing cause of highly effective teams. From here there are two sets of people in the equation, the author(s) and the reviewer(s). From here, he would state that there are four important aspects to code review which are building the right thing to achieve an objective, building it correctly, fast, and together.

For building the right thing to achieve an objective. He goes on that from the very early stages of coding, you should show proofs; this will ensure you are on the correct path and if not, it’s an early change to fix. 

Building it correctly involves utilizing GitHub and all the features it has. Alejandro states you must label work correctly. For instance rather than using a PR use a draft PR on GitHub. Along with this, GitHub has a feature stacked PR; several PRs are reliant on each other. He states that wanting a deeper code review, this is a must rather than have all PR’s in one. He also acknowledges it’s possible to create too many small stacked PRs but still has yet to encounter this. Stacked PRs are a powerful technique and should be implemented in code reviews to help team projects. Lastly, to ensure your commits are easy and understandable.

For building it fast he states by doing the above, it’ll be faster in the long run rather than sprinting to try to get the code done all in one commit without any peer review prior. Showing proofs/feedback and using stacked PR’s on GitHub; taking it one step at a time to achieve the goal.

Building it together means you need to have a team oriented mentality. How can WE improve this thing, not how can I improve this thing. Along with this, you should provide actionable feedback to other teams, rather than “this is not great” provide a direction of how things can get better. Alejandro also acknowledges that too many people in a meeting/code review could not always be beneficial. You as the author need to question if it would be beneficial to have the feedback of everyone and have a 10 person conversation in GitHub, or rather to include two people only who are skilled in said task. If it’s more beneficial to only have a few people, make sure the results of the conversation are reflected on the PR.

Alejandro then goes on to wrap up his talk with five takeaways:

1. Keep PRs small
2. Share drafts early
3. Focus on the work, not the person
4. Offer actionable feedback
5. Pick the right people

From understanding and implementing these takeaways, the code review will be a lot more deeper in the understanding of why something is being changed and also the importance of a great code review. 

My personal comments about this is that as a developer you are always learning and will never be “done” in terms of learning. Furthermore, as a developer you must be willing to adapt quickly. Alejandro had twenty years under his belt and then coming to a new job seemingly had his world flipped upside down, but rather than being timid, he adapted. Along with this, at the beginning he was talking about taking his coworkers comments personally, which was not the case at all then after realizing this, he strived forward. I think this is a great story and has taught me that to be in this field, you must be adaptive and code review is simply not “code review” but rather steps and processes compiled to make code review.

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.

Hi class,

For this blog post I decided to choose the topic software testing. Software testing is one of the topics that we went over this course and furthermore, I hope you can have some good takeaways about how software testing is implemented out in the real world.

Before going into the summary, let me provide you with the resource that I am getting this information from. https://www.youtube.com/watch?v=PqCVDGhvEFs&t=1988s This is the link to the podcast I listened to called “Beyond Coding.” Here the host Patrick Akil, a software engineer looking to gain and share interest in coding, sits down with QA, quality assurance, engineer Augustine Uzokwe to discuss what a QA engineer does in software engineering. (I really do enjoy listening to podcasts so that’s why I have chosen a podcast format for my source.)

Patrick begins the podcast off by asking Augustine what is QA, quality assurance. Augustine replies it varies depending on the work and/or field the said QA is in, but in terms of this interview he will do this in perspective to software engineering. 

Augustine then goes onto talking about QA in software engineering. He goes on to state that yes, there is a lot of unit testing, but it is more so adapting, quick thinking, and team collaboration. He takes the approach of using broad practices such as pragmatic and being flexible. Furthermore, he goes on to state that if there’s two teams, Team A and Team B, what might work for Team A, might not work for Team B. 

He stresses this is totally okay, and acknowledges that this happens, but as a QA engineer you must find a solution fairly quickly. Not only quickly, but also find a smart solution. When a unit testing doesn’t have the correct output/run, he then goes on to state that rather than going back trying to fix everything then performing an end to end unit test, there’s a smarter approach that is better and in the long run will be quicker.

This approach is team collaboration. In the instance above, he would call all participating engineers in the code and simply talk and review the code with them. From here each engineer would have an assigned part to work on, then they would dispersed to work on their said assignment. In this time of working, Augustine stresses the QA engineer needs to take the lead and create an environment of openness amongst the fellow engineers. If one engineer has a question, they shouldn’t go searching for it online for three hours, but rather ask a fellow peer. 

Once a developer has their assignment done, it should be unit tested separately (if applicable). This is very beneficial because all the bugs can be found in that moment, then developed, rather than with an end to end test. In this time, Augustine would be spreading his knowledge of QA to the engineer so that way the engineer will slowly learn how to conduct and what to look for while on their own doing a software testing. 

Augustine states in today’s world of engineering how fast it is out there, but it is more so about “removing the waste” and improving as you go with unit tests/peer testing. Not only is this the case, but he also states that team maturity is very important and key. Furthermore, if a lot of engineers come together it doesn’t necessarily mean a quicker delivery. Engineers need to have a process in place and need to know how to properly test software, of which is where the QA engineer comes in to ensure quality over speed. 

My personal comments about this is that I like the way Augustine thinks a lot; quality over speed. Furthermore, throughout the podcast he says “win the time.” Before listening to this podcast, if I heard that statement in regards to programming I would’ve thought to write out the program as quickly as possible and then test at the end when I am “done” programming. Although after listening to the podcast, I would now think let me talk with my team, write out a plan to implement the code, code, ask questions, and unit test the code along the way. Overall, this was a very interesting listen and very insightful that could be useful to programmers of all levels; or even people wanting to implement a better structure of working on a team project.

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.