Category Archives: CS448

Find Mentors

Finding mentors is essential for aspiring software craftsmen, as they provide guidance and support in navigating the complexities of the field. Of course, software developers should strive to be hard-working and growing apprentices to eventually become masters at their craft. However, finding an ideal mentor is rare, especially in today’s world.

The process of finding mentors can be challenging, as mentors may not always be readily available or possess the desired expertise. For this reason, most real-world apprentices often seek guidance from multiple mentors with varying degrees of expertise.

Additionally, reaching out and asking for mentorship can be intimidating. However, the potential benefits far outweigh the risks, and even informal advice from experienced developers can be invaluable. Apprentices also have a role to play in mentorship by being willing to share knowledge and provide guidance to others. Passing on lessons learned from mentors contributes to personal growth and development as a craftsman.

Lastly, it is crucial that apprentices be active in approaching mentors, to learn more about them and gain their attention and help. For example, apprentices can sign up for active mailing lists related to software development, they can observe, and identify patient teachers within the community, and seek informal advice from potential mentors at conferences.

As an introvert, I often find myself struggling to take action in the networking aspect of my career, even though I realize how important it is for my success. There is a lot of fear and anxiety that comes with putting yourself out in the open and asking for help. However, if I learned one thing from my internship last summer, it is that I cannot afford to be afraid to ask questions! By asking questions and showing my weakness, yet still in a spirit of curiosity and willingness to learn, I found myself growing faster than I could have ever imagined under the mentorship of my advisor, who was patient and helped me to improve little by little.

In conclusion, mentors play a vital role in shaping the development of aspiring software craftsmen. Actively seeking mentorship and being open to providing mentorship to others are essential components of the journey toward mastery of one’s craft. By embracing mentorship, apprentices can gain valuable insights, overcome challenges, and ultimately achieve their goals in the field of software development.

From Chapter Four, “Find Mentors” in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations

Programming is automatically motivating for programmers when they have the freedom to work in their preferred manner. However, apprentices often face real-world challenges with projects that have changing demands. Such projects can be rigorous, chaotic, and frustrating, making it essential for programmers to have a constant motivation to adapt and remain resilient. While there are some days where everything flows smoothly, there are also more common days that are filled with complex and tedious tasks, particularly in money-driven programming jobs.

Motivations for programmers can vary, including financial goals, the sheer enjoyment of programming, or building a reputation through open source projects. However, relying solely on financial or reputational motivations can lead to what’s known as the “Golden Lock” phenomenon. This trap involves sticking with known skills because they’re lucrative, even if they no longer align with personal growth or interests. To combat this, an ambition for constant improvement towards mastery is vital, helping developers realize when they’re falling into these traps and guiding them to seek new challenges.

While passion for programming is valuable, it can also lead to overcommitment. For example, Marten Gustafson found himself overcommitting to projects due to his passion, resulting in project “death marches.” It’s essential to nurture this passion while maintaining a balance with other life aspects to avoid burnout.

David Wood offers a simple yet enlightening piece of advice: “Do what you love and the money will follow.” Following this advice helps developers discover that doing what they love fuels their creativity and energy, leading to greater financial rewards in the long run.

To better understand personal motivations, it is encouraged that programmers list at least fifteen motivations and then another five. This exercise helps identify motivations based on personal feelings versus external factors caused by other’s judgment and perception. By prioritizing the top five motivations and keeping them visible during challenging times, programmers can stay focused and resilient on their journey.

On a personal level, I find programming very entertaining and fascinating. But as a student, I often find that my motivation for programming can become fueled by academic reputation. One motivation could be, for example, a fear of getting a bad grade and not making the Dean’s list. While this is certainly a real feeling and truly motivates me to meet the expectations of my professors, it stops at that. Such a motivation is not to become a great programmer, but rather, to become successful in school and therefore in my career. While this way of thinking will probably get me through university, it does not guarantee me a successful career.

Programming offers intrinsic motivation, but navigating the challenges of real-world projects requires adaptive motivations. It’s crucial to balance financial goals with personal interests and ambitions for mastery. By avoiding the Golden Lock, embracing learning opportunities, and nurturing passion while maintaining balance, programmers can find long-term success and fulfillment in their careers.

From Chapter Three, “Walking the Long Road” in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective Blog

With new experience gained form Spring 1, I entered into Sprint 2 starting strong with more understanding of the basic workflow and how to navigate Thea’s Pantry on GitLab.

As a team, we all worked very well together in all stages of the sprint. There was good communication through Discord and SMS to coordinate meeting times both in person and online which shows by our ability to complete twenty-three out of the twenty-four weight we planned for the start of the semester. Because we were more used to the workflow process, we were able to spend more time together figuring out our more in-depth issues to implement button functionality to the AddInventoryFrontend project.

Some issues we ran into however, was not being able to build and run the Frontend to see how our vue file code ran. Instead, we had to rely on a vue playground which we found online to test and run our code. In addition, we were unable to access the wireframe to edit it, so the team resorted to detailing the revised wireframe through PowerPoint Presentation. These were simple issues that can be fixed in the next Sprint. As expected, we did not repeat any of the workflow mistake we had done last Sprint.

For the next sprint, we plan to have a “Workflow tips” shared document that includes all our mistakes from Sprint 1 and their solutions so that we do not make the same mistake again. For example, instead of waiting to review everything at the end, the team will review issues as they are completed. We also know to create merge requests directly from the issue, and to edit the merge request properly so that it meets all workflow requirements.

For the next sprint, we plan to continue working on the AddInventoryFrontend project. The first step before implementing the revised button wireframe would be to fix the frontend so that it can run on GitPod rather than having to rely on Docker. Then we will add code to allow the frontend to run on devmode, which makes it so that updates pass through as we work on the code rather than requiring the frontend to be rebuilt each time a change is made. After both of these are completed, then we plan to confirm that the current vue code works. Once that is confirmed and running, we will then update the frontend to reflect the revised wireframe.

This Sprint, I was not the SCRUM master, but I attended all our meetings and worked with my team to come up with solutions to our issues. I would say I am much more organized than last Sprint and am happy with the progress I and my team were able to make together.

Activity links:

GitPod Dev Environments: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/issues/9
Description: Verified that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages.

AddInventoryFrontend Redesign: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/39
Description: Created a revised wireframe for AddInventoryFrontend. The revised wireframe will be added to Thea’s Pantry GitLab in Sprint 3.

Implement Frontend Wireframe: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/45
Description: Developed the submit and cancel buttons following the basic wireframe before revision.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Art over Craft

Richard Stallman calls programming a craft rather than a fine art, focused on building useful objects rather than purely aesthetic creations. While programming can be truly elegant and beautiful, its real purpose is to solve a customer’s problem. This is what makes it a craft.

The pattern “Craft over Art”, in this sense, is all about strong relationships and delivering value to customers. It is important to prioritize customers’ needs over personal artistic expression, because true craftsmanship involves building something that is both beautiful and useful. Software should never be simply beautiful but useless artifacts.

However, there are often many demands in software development, many of which are conflicting. It is important that a developer balance these conflicting demands, for example, delivering value to customers while adhering to professional standards. This is what it means to sacrifice the beauty of code for utility.

By focusing on the craft over the art, a developer gains many benefits. A developer is able to look past doing things solely for self-satisfaction, and instead, is able to aid customers and help solve real problems for real people while honing their craft.

To apply this pattern, software developers should find an opportunity to prioritize utility over beauty throughout the day, building a habit of being aware of the tradeoffs. A developer could also reflect on past choices where they prioritized artistry over utility and suggests afterwards think about alternative choices to understand the potential outcomes. “Craft over Art” advocates for a balanced and customer-focused approach to software craftsmanship.

I particularly found this pattern very helpful, because I find myself often working to make something perfect to the point where it hinders me from getting my work done. And often, because I have spent so much time making the code “perfect”, I grow so attached to how my it looks and is running, that I struggle with the idea of refactoring it to make it function better.

Understanding the difference between craft and art will make it easier for me to see my code as something that is always changing and improving rather than something that I try to write perfectly the first try. There is always room for change, to hone my craft.

From Chapter Three, “Walking the Long Road” from Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog

Being the first sprint of the Capstone class, there was a lot for me to learn working as a team and also as an individual.

As a team, we all worked very well together in all stages of the sprint. There was good communication which helped us coordinate meeting times both online and in-person. Evidence of our synergy would be through the fact that we were able to meet our estimated 20 weight completion by the end of the sprint. I would attribute the large success of our sprint to our commitment to meeting at least once in person every week throughout the duration of Sprint 1. This allowed us to really work together as team to figure out the issues and workflow, which was brand new to us all.

However, it was not all sunshine and daisies. The team made multiple mistake along the way which had slowed us down on occasion. Two big problems for all of us was navigating GitLab and getting used to the workflow. Aside from getting lost and figuring out the UI, we were unsure at first how to post our issues and how to create branches for our changes. It was also confusing how and when to approve merge requests. We had waited for all our issues to be completed before doing the review, which created merging conflicts and caused certain pipelines that were dependent on the other issues to fail.

For the next sprint, we plan to have a “Workflow tips” shared document that includes all our mistakes from Sprint 1 and their solutions so that we do not make the same mistake again. For example, instead of waiting to review everything at the end, the team will review issues as they are completed. We also know to create merge requests directly from the issue, and to edit the merge request properly so that it meets all workflow requirements.

As for me, an individual member of the team, I acted as SCRUM master and worked to communicate with the professor for the team during meetings, preparing notes and organizing the thoughts of the team. However, I had failed in some parts to organize tasks for myself, missing one stand-up post due to negligence. Now that I have a better understanding of how the workflow and meeting dates work, I will be more prepared in the next sprint.

Activity links:

GitPod Dev Environments: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/issues/23
Description: Moved Settings and Extensions from VSCode to GitPod Dev Environments.

Add AlexJS Linter: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/issues/6
Description: Added AlexJS Linter to pipeline check.

Move `commands` to `bin`: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/issues/5
Description: Changed command folders to bin to avoid naming convention conflicts.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Expose Your Ignorance

One of the patterns addressed in Chapter 2 of Apprenticeship Patterns by Dave Hoover and Adewale Oshineye is titled “Expose your Ignorance”. It is a pattern that helps a programmer identify their weaknesses so that they can better know how to promote their personal growth.

When a company hires a software developer, they are trusting that the software developer is well suited for the job and knows what they need to know to do the job well. However, sometimes even the most experienced developer may come across an issue or technology with which they are unfamiliar.

To combat this, it is necessary to “expose your ignorance”. This does not necessarily mean to down-sell oneself by listing out all weaknesses and struggles, but rather, to be open with one’s learning progress and improvements. Being open is a road that leads to trust and reputation in any software developing team.

How does one healthily expose ignorance?

Ask questions! Learning from experienced software developers is the most direct way to becoming an experienced software developer oneself. Asking questions exposes ignorance, but it also exposes one’s ability and willingness to learn.

What happens if one does not expose ignorance?

The opposite to exposing ignorance is hiding it, and while it may save face in the short term, hiding ignorance will only stunt personal growth. This is bad for both the software developer and the team who depends on the software developer to be able to do their job well.

What are my personal experience with exposing ignorance?

When I was starting off with my research projects, I suffered from “imposter syndrome”. There was simply so much I didn’t know and had to learn to catch up and progress through my research. However, instead of hiding in my shell and trying to keep up a facade, I swallowed my pride and let my advisor know when I wasn’t understand something, or when I needed help. I had to remind myself that this fellowship is a chance for me to grow and gain experience! My advisor does not expect me to know anything and is there to help me learn.

Because I was willing to ask questions and exposed my ignorance, I was quickly able to learn and gain a deeper understand of my research project.

From this experience, I became to like being surrounded by people who know more than I do because it gives me the opportunity to learn so much. It exposes my ignorance not only to those around me, but arguably more importantly, to myself.

Seeing where I struggle pointed out clearly to me, it gives me the chance to address that weakness by doing the necessary research and practice to strengthen my understanding in an area that I would be otherwise unaware.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Introduction to Apprenticeship Patterns

The book Apprenticeship Patters: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adele Oshineye is a powerful tool for both beginner and seasoned software developers.

Hoover and Oshineye introduce software development as a craft constantly needing to be honed. The term “craft” has been widely defined and generically used throughout multiple sources. However, Hoover and Oshineye define what they mean by “software craftsmanship” using a list of values. While the list is long and descriptive, the main gist is that the craft of software development is all about improvement. There is always room for improvement, achieved through an open mind, the sharing of information and resources, and the courage to experiment and discover through process.

To help developers hone and perfect their craft, Apprenticeship Patterns contains numerous different strategies or “patterns”, helping the reader not only to grow, but to grow most effectively.

One thing that resonated the most with me was the book’s theme on the importance of having an attitude of growth. Without such an attitude, it is easy to become stuck in one’s own bubble of perceived competence and thereby losing focus on learning. I could have all the resources available to me, every book, tutorial, guide, and mentor; but if I am not open and willing to move away from my perceived area of “expertise”, my growth will surely be stunted.

In addition to the right mindset, I found chapter four very insightful, which goes into detail about how a developer also needs a healthy environment where growth is promoted. An environment that fosters learning and communication is the key difference between a struggling software developer and a thriving one. Because of this, a developer should be careful not to be too content being the biggest fish in the pond. There is always another pond with even bigger fish and more nutrients. Hoover and Oshineye emphasize repeatedly how important it is to let go of perceived competence to focus on learning. Sometimes, the best environment is one that is a little uncomfortable.

Software development is a huge field filled with so much potential. There are dozens of languages that take years to fully experience, learn, and understand. All of this — and so much more — is taught through experience and through trial and error.

In addition however, one other important tip from Hoover and Oshineye is to learn from the best of the best. They stress the benefits of reading books which are filled with the knowledge of experts in the field of software development. Reading is the most direct way to gain knowledge made possible through an open mindset and a resourceful, learning environment.

While growth and learning are important, I also think it is important to rest and enjoy the journey. The word “craft” also implies “artistry”. Therefore, I believe a software developer should not focus too much on “becoming an expert” but also to explore and appreciate the beauty of the art of software development.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye is a book covering a comprehensive overview of software testing meant to prepare the reader with the knowledge and skills necessary for working as a quality assurance tester.

In the beginning of the book, Hoover and Oshineye answer the important questions of “what” is software testing and “why” it is necessary in software development.

At the highest and most general level, software testing is a way by which a software’s quality is evaluated, estimated, and shared with stakeholders, providing an independent view of the software product. Furthermore, it is the goal of software testers to ensure that this quality meets and maintains the requirements. I found it interesting that the book mentioned the primary function of software testing to be for the stakeholders; however, it makes sense as software testing not only is needed to ensure that the program runs, but also that it runs smoothly for the user, and most definitely for its stakeholders. The best way to assure stakeholders of the product’s success is through software testing.

Chapter two of the book gives further reasoning for software testing stating that the U.S. government lost 60 billion dollars due to software defects in 2002, equating to 0.6% of the country’s gross domestic product. In a world that is so heavily dependent on technology, it becomes evident how important it is to ensure that this backbone of society remains reliably working.

So with the question of “what” and “why” out of the way, the book shifts gears into the essence of software testing. The fundamentals of software testing is split into three parts: testing basics, requirements, and test plans.

The most basic form of testing is checking expected output with the observed output based on a controlled input allowing for a clear comparison and analysis of the program’s behavior. Most patterns of software quality assurance are based on this fundamental strategy.

Before testing software, it is necessary to know what it is that needs to be tested. This is given by the software requirements. These specify exactly what it is a specific piece of software should do under certain conditions ensuring that developers know what to build and that testers know what to test. Requirements are laid out in a test plan, a collection of test cases ensuring that every requirement of a software is met.

Software testing is complex field with many moving parts. However, it all boils down to ensuring that the program works as intended, meeting all the requirements and expectations shared by stakeholders and users, which saves time and money for companies that use it effectively. It is a field of software development that I am very interested in and am excited to learn about more.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Set-Up Post | Libre Food Pantry & Thea’s Pantry

Libre Food Pantry (LFP) and Thea’s Pantry are both organizations working to provide solutions to those in need by offering alleviation in grocery and other personal needs.

The LFP is developed mainly by instructors and their students who act as LFP Shop Manager and the LFP Shop respectively. Each Shop is further divided into Teams that work to develop and improve solutions.

Shop Managers are not only in charge of their shop and are also members of the Coordinating Committees whose responsibilities are to guide the direction of LFP, represent its high-requirements, support all the Shop Managers, and when appropriate, set necessary policies.

Thea’s Pantry is partners with Libre Food Pantry which is why I found it useful to learn more about how the LFP was organized.

One thing I found interesting about Thea’s Pantry was it’s relation to the Worcester County Food Bank. The pantry sends monthly reports using the Monthly Report system, which is accessed by a Pantry Administrator who specifies the month and year to generate the respective report as a downloadable Excel file.

For this reason, it is important to create a system that is able to reliably log and store activity records of the pantry about both the guests and inventory of the pantry. That is what the collaboration between Thea’s Pantry and the LFP wish to accomplish.

Knowing these facts allows me to see more clearly what I will be contributing to through my Capstone project, as well as the connections that allow it to happen.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

The Final Sprint Retrospective

The most headway came when multiple sets of eyes were on issues. This first proved to be true when the IAM System Community of Practice was working together to establish the logout functionality and to ensure that the user sessions properly expired to prevent unauthorized modification of the database.

This also rang true when Tim Drevitch and myself were finally able to free up time and address out standing issues. As per my comment here, and his comment here, we were able to spin up a docker instance of a database and pretty quickly figure out how to start adding to the database just shy of setting up the specific documents we needed to store individual users/entries. It was three hours of troubleshooting together, researching different aspects, and then explaining them back to each other over voice chat, but we made substantial head way where there was otherwise none (despite it not being a card assigned to either of us).

While there are obvious constraints to having green undergraduate students try to develop software on a very part-time basis, it became very obvious that not all the teams were created equal. When I would meet with the IAM community of practice we would discuss what our groupmates needed of us and I would routinely report back to them that my group had made no mention of any code, functions, methods, etc that they needed from me nor intended to integrate any time soon, much to their surprise. This signals to me an overall unfamiliarity with the tech stack which is not a judgment on them, they’re doing their best given the limited amount of time in the day and the craziness of navigating online learning. That being said it was often the bottleneck within team discussions.

What was within teammate control and —seems to be the modus operandi students within the Worcester State University Computer Science Program— very unacceptable was the lack of communication. I would consistently ask teammates what they were working on and how it was going only to get no response. In fact, there was one teammate who I had never heard talk until three weeks until working with them; it’s anyone’s guess as to why, but my experience with my fellow computer science students has been largely marred by radio silence. My biggest change I would have made to the team was to force my teammates to communicate by instead of asking them “what is stopping them” in the standups, ask them “what is something they encountered that they didn’t understand while they were working”.

My personal failings in the last sprint came largely from my pivoting away from schoolwork to build out skills that would help me attain a summer internship as well as applying to said internships. I became more focused on learning the practical skills gained from sites such as Tryhackme.com and studying for the eJPT certification so that I may pursue a career in information with an emphasis in exploit development and malware reverse-engineering. My ability to engage with school work may have declined but it was a necessary sacrifice to (hopefully) make myself a more viable job candidate.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.